关于通信中间件的思考

企业内部业务的快速发展，势必导致业务的解耦合，进行物理上或者是逻辑上的切分，目前来说，一般存在以下四种形式。

1. 同一个服务器不同端口
2. 同一个服务器跨虚拟机或者是跨Docker容器
3. 跨服务器同一内网
4. 跨服务器跨网络

因此，要实现项目之间的通信，远程的调用显得十分重要。
目前主要的四种实现方式有：

1. spring cloud的RESTful
   基于Http协议，按照Rest风格的开发模式。对外建议使用。
2. 消息队列
   以牺牲实时性为代价做到削峰处理。
3. WebSocket
   WebSocket是一个应用层协议，是一个全双工通信。
4. RPC系列
   RPC的优势是性能好，不需要Http的三次握手。目前主要的框架有JMI、gRPC、Thrift、Dubbo、Motan（微博版Dubbo）、HSF、Hetty 、rpcx等等。

spring cloud的RESTful
spring cloud 为开发人员提供了快速构建分布式系统的一些工具，包括配置管理、服务发现、断路器、路由、微代理、事件总线、全局锁、决策竞选、分布式会话等等。

springClound架构图.png

Spring Cloud Config：配置管理开发工具包，可以让你把配置放到远程服务器，目前支持本地存储、Git以及Subversion。
Spring Cloud Bus：事件、消息总线，用于在集群（例如，配置变化事件）中传播状态变化，可与Spring Cloud Config联合实现热部署。
Spring Cloud Netflix：针对多种Netflix组件提供的开发工具包，其中包括Eureka、Hystrix、Zuul、Archaius等。
Netflix Eureka：云端负载均衡，一个基于 REST 的服务，用于定位服务，以实现云端的负载均衡和中间层服务器的故障转移。
Netflix Hystrix：容错管理工具，旨在通过控制服务和第三方库的节点,从而对延迟和故障提供更强大的容错能力。
Netflix Zuul：边缘服务工具，是提供动态路由，监控，弹性，安全等的边缘服务。
Netflix Archaius：配置管理API，包含一系列配置管理API，提供动态类型化属性、线程安全配置操作、轮询框架、回调机制等功能。
Spring Cloud for Cloud Foundry：通过Oauth2协议绑定服务到CloudFoundry，CloudFoundry是VMware推出的开源PaaS云平台。
Spring Cloud Sleuth：日志收集工具包，封装了Dapper,Zipkin和HTrace操作。
Spring Cloud Data Flow：大数据操作工具，通过命令行方式操作数据流。
Spring Cloud Security：安全工具包，为你的应用程序添加安全控制，主要是指OAuth2。
Spring Cloud Consul：封装了Consul操作，consul是一个服务发现与配置工具，与Docker容器可以无缝集成。
Spring Cloud Zookeeper：操作Zookeeper的工具包，用于使用zookeeper方式的服务注册和发现。
Spring Cloud Stream：数据流操作开发包，封装了与Redis,Rabbit、Kafka等发送接收消息。
Spring Cloud CLI：基于 Spring Boot CLI，可以让你以命令行方式快速建立云组件。

消息队列
待续。。。

WebSocket
待续。。。

RPC系列

RPC.png

1、 客户端(Client)：服务调用方
2、 客户端存根(Client Stub)：存放服务端地址信息，将客户端的请求参数打包成网络消息，再通过网络发送给服务方
3、 服务端存根(Server Stub)：接受客户端发送过来的消息并解包，再调用本地服务
4、 服务端(Server)：真正的服务提供者。

调用时序图.png

1、 服务调用方（client）调用以本地调用方式调用服务；
2、 client stub接收到调用后负责将方法、参数等组装成能够进行网络传输的消息体；在Java里就是序列化的过程

3、 client stub找到服务地址，并将消息通过网络发送到服务端；
4、 server stub收到消息后进行解码,在Java里就是反序列化的过程；
5、 server stub根据解码结果调用本地的服务；
6、 本地服务执行处理逻辑；
7、 本地服务将结果返回给server stub；
8、 server stub将返回结果打包成消息，Java里的序列化；
9、 server stub将打包后的消息通过网络并发送至消费方
10、 client stub接收到消息，并进行解码, Java里的反序列化；
11、 服务调用方（client）得到最终结果。
RPC框架的目标就是把2-10步封装起来，把调用、编码/解码的过程封装起来，让用户像调用本地服务一样的调用远程服务。要做到对客户端（调用方）透明化服务， RPC框架需要考虑解决如下问题：
1、 服务端提供的服务如何发布，客户端如何发现服务；
2、 如何对请求对象和返回结果进行序列化和反序列化；
3、 如何更高效进行网络通信。

到目前位置，RPC的原理大致清楚，但是有些知识点还是不明白，比如说，为什么RPC不需要三次握手了。这里我们来看看HSF 目前ali内部使用的中间件源码。
待续。。。

参考文献
https://blog.csdn.net/dongnaosenlu/article/details/76998419
https://www.cnblogs.com/xiaojunbo/p/7090742.html