《分布式服务框架原理与实践》——第5章协议栈阅读笔记

本章没有非常详细的讲解协议实现细节，而是重点讲作者自己的协议设计一些关键点和实践经验。对于我们设计实现自己的协议还是很多借鉴意义的，我们的设计实现应该参考它。

关键技术决策

是否支持多协议

最为正确的答案都肯定不是绝对的，都是根据实际需求而定。但是从现有的这些分布式服务框架来看，一个通用的服务框架，往往是支持多协议的，比如dubbo，它能够支持觉大多数RPC协议，而且还能够自行扩展；而专用的服务框架，往往支持一种或者少量的协议，这样的好处是减少了开发者的配置量，也降低了用户误用的可能性，Montan和JSF（京东内部使用的）等框架就只默认支持一种协议，当谈它们也都支持扩展协议。

公用协议和私有协议

公用协议往往成熟度非常高，通用性很强，也支持多语言，能够很好地与内部现有系统，第三方外部系统做做集成，它是有自己的使用场景的，比如REST和WebService等；私有协议往往是企业根据自己的需求全新设计的，能够在更好地满足某种特定使用场景的需求，比如能够具有更高的性能，更多的功能特性等，比如dubbo协议等，而当前流行的分布式架构，微服务架构，在这种架构下将系统拆分得粒度特别小，因而势必将增加了很多次的内部网络调用，因而产生了对高性能的RPC协议的需求，这也往往是它的使用场景的，因此服务框架往往也是两种协议都要支持的。

集成开源还是自研

开源还是自研永远是个问题，原则当然是能用开源的当然直接集成开源，成本低，成熟度高，不要重复发明轮子的告诫都告诉我们不要重新开发完全一样的东西；当没有开源的符合需求的选择时，我们可能会选择自研，但是不要忘记了要学习和借鉴开源协议实现，因为即使是重新实现，它与开源的设计与实现还是存在非常多相同部分的，而这些我们如果不去借鉴，一定会增加很多没有必要的成本，要走很多弯路的。

功能设计

通讯模型

短链接还是长链接的选择，双向通讯还是单向通讯，同步还是异步通讯，这些都是要支持的，它们都能够适用于不同的使用场景。

协议消息定义

协议消息一般设计为消息头和消息体，消息头存放通用字段和用户扩展字段，消息体则存放消息内容。



设计协议要考虑到以后协议升降后的向前兼容性，升级新的协议版本后要尽可能兼容老版本的协议，只要才不需要强制各终端要求版本升级，另外协议支持扩展型，所以实践经验是协议中要定义下面两个信息。

消息头第一个字段定义为版本号。这样方便识别消息的协议版本。

消息头最后一个字段定义为Map类型的扩展字段。这样方便服务框架本身或者用户扩展消息头。

可靠性设计

客户端连接超时。超时设置非常关键，它能够避免过长浪费系统资源，比如连接、线程等资源；还有一点是业务层的需要，需要有超时机制，客户端对于请求响应的时间有要求。

客户端重连机制。网络是不稳定的，尤其是互联网更是可靠性较低，因此网络协议的设计要针对这种不稳定性做好处理，当连接被中断后，客户端检测到之后要做自动重连，但是重连间隔不能太频繁，否则会浪费过多资源。

消息缓存重发。NIO框架例如netty都缓冲机制，将消息的发送先写入缓冲区，然后再会异步发送到网络上去，因此当链路发生中断的情况下要重新发送缓冲区中的消息，另外还要考虑缓冲区溢出的风险，当缓冲区溢出则抛出异常，不能客户端发送成功。

心跳机制。凌晨业务低谷时，当大量链接处于闲置后，大量链接将因为超时或者其它网络因素断开，则当业务量上来的时候会出现大量连接失效的问题，还有一些软件可能检测不到链接断开的假链接的情况，这些都需要增加合适的链接检测机制，通过在链接空闲的时间定期发送一个心跳包，当n各周期没有收到响应，则可以认为链接是无效的，则断开重连。

安全性设计

安全与运行性能，安全与开发运维效率等都存在着矛盾，那么我们在设计中如何平衡这样的矛盾体呢？本书给出了作者的一些建议。它将RPC协议的使用场景分为三个，针对不同的场景选择不同的安全策略。

企业内网开放内部系统其它模块调用服务，通常不需要安全认证和SSL/TLS传输。因为完全是自己调用自己，则完全是可信任的。

企业内网开放外部系统其它模块调用服务，通常需要通过安全认证（比如在SOA管控平台上申请调用的appId和秘药），但是不需要SSL/TLS传输，因为企业内部的系统大体上是可信任的，但是为了防止未授权的服务误调用，要么造成业务风险，要么给系统增加调用压力，形成技术风险，我们增加一个申请授权的流程，让服务提供者评估业务和技术风险后再开放其调用。

开放给企业外部第三方系统调用，则需要认证和SSL/TLS协议传输，要增加最高标准的安全控制。因为第三方具有很高的不确定性，完全不可信，还有控制第三方系统的调用频次，细粒度的权限控制，还要防止第三方系统的各种网络攻击等等。