架构师训练营第十周总结

微服务目的：通过拆分，将模块独立部署，解决巨无霸应用系统带来的编译，部署后相互干扰的困扰。对不同业务分开管理，合理利用数据库资源，且减少增加新业务对旧业务的影响。

Dubbo 架构主要包括三个组成部分：服务消费者服务器，服务注册中心服务器，服务提供者服务器。

1、服务消费者提供服务时，需要找到对应的服务，如果不在本地，则远程到其他服务器上区找所需服务；

2、服务消费者想远程找到自己需要的服务所在的服务器，需要到注册服务中心查找自己所需的服务在哪台服务器上；

3、注册服务中心里面放着不同服务器提供的服务。这些服务由服务提供者上的容器主动提供；

4、服务提供者服务器中的各种服务，在容器启动。当消费者服务器的请求来了后，选出对应的服务响应并返回。

这样，消费者那边就拿到了自己所需要的结果。

微服务落地的顺序是：业务，付出的代价，原则，时间，方法（工具）。其中业务最重要，业务决定了业务边界和依赖，这样可以把不同的业务分开，避免业务耦合，从而拒绝巨无霸系统的出现。

RPC 协议实现原理

点击下载

本地方法 client fun <-->本地存根 client stub <-->本地 sockets <-远程->服务端 sockets<-->服务端存根 serverstub<-->服务端方法 server fun

应用层通讯协议包含：

网络通信协议：TCP、UDP      // 保证网络通信可靠性高效性，http 用于应用层，TCP 用于传输层 ，UDP 比 TCP 可靠性差一些

编码传输协议：二进制、文本  // 二进制性能高于文本，json 比 Xml 性能高。本地和服务端的编码协议要统一

私有协议的目的：充分利用通讯协议中的每个字段，减少冗余数据传输。最大程度满足性能要求

常见协议   //变长协议比较常见

点击下载

点击下载

dubbo 协议

前 16 个字节协议头，后面是协议体

协议头： magic code(2 字节) 。第 16 个比特请求响应标志，第 17 个比特表示双工通信，第 18 个比特表示事件（心跳检测不包括内容），19~23 比特表示序列化器的编号（最多 32 个数据），24~31 比特表示响应状态

8 字节记录 RPC 请求 ID（避免队头阻塞，请求和响应是同一个 ID，请求时把 ID 放入 map 中，有回应后在 map 中找对应 ID），4 个字节记录 body 长度（Data length）,16 字节后记录包括版本号，服务名（类路径），服务版本，方法名（类中的方法），参数类型，参数值，附件。