应用间的通信

主要有两种：
HTTP vs RPC

• 两大配方的主角就是SpringCloud和Dubbo
• Dubbo是个RPC框架，而SpringCloud的目标是微服务架构下的一站式解决方案
• SpringCloud微服务架构下， 微服务之间使用HTTP restful的方式， HTTP restful的方式本身轻量易用， 适用性强，可以很容易的跨语言，跨平台，或者与已有的系统交互
• Dubbo本身的定位就是个RPC框架， 基于Dubbo开发的应用还是要依赖周边的平台和生态；
• SpringCloud没出来之前， Double在国内应用得相当广泛

SpringCloud中服务间两种restful调用方式

• RestTemplate
• Fein

RestTemplate

举例：
要在订单微服务里面调用商品微服务里面的查询商品

1. 在商品服务里面，加一个Controller，叫做“ServerController”，供其他服务调用
2. 在订单服务里面写一个Controller，叫做“ClientController”，调用商品服务里面的接口

使用Template的第一种获取方（直接使用restTemplate，url写死）

这种方式的缺点：

• url是写死的，对方的地址可能不知道
• 对方服务如果有两台，就牵扯到负载均衡

使用Template的第二种获取方式（利用LoadBalancerClient获取url）

其实第二种方式就是弥补第一种方式写死url带来的诸多不便
使用LoadBalancerClient对象，的choose方法， 传入服务名，动态地取到url所需的各种信息

使用Template的第三种获取方式（利用@LoadBalanced，可在restTemplate里使用服务名）

写一个config包，把restTemplate作为一个Bean配置上去

负载均衡器Ribbion

之前有说过Eureka是客户端发现的方式，它的均衡是软负载， 也就是客户端会向服务器例如EurekaServer拉取已注册的可用服务信息，然后根据负载均衡策略直接命中某台服务器发送请求。
这整个过程都是在服务器端发起的，并不需要服务器的参与。
SpringCloud客户端负载均衡就是Ribbion组件，它是基于netfix Ribbion实现的, 通过SpringCloud的封装, 可以轻松面向服务的rest风格请求, 自动转换成客户端负载均衡服务调用

以下都是用到了Ribbion

• RestTemplate
• Feign
• Zuul
  上面使用的@Balanced注解用的就是Ribbion组件

Ribbion实现软负载核心有三点

• 服务发现(依据服务的名字, 把该服务下的实例都找出来)
• 服务选择规则(如何从多个服务中选择有效的服务)
• 服务监听(检测失效的服务, 做到高效剔除)

Ribbion的主要组件有

• ServerList
• IRule
• ServerListFilter

流程

首先, 通过ServerList获取所有可用的服务列表
然后, 通过ServerListFilter过滤掉一部分服务地址
最后, 剩下的地址通过IRule选择一个实例作为最终目标结果