《分布式服务框架原理与实践》——第5章协议栈阅读笔记
《分布式服务框架原理与实践》——第5章协议栈阅读笔记
杨武兵 发表于1年前
《分布式服务框架原理与实践》——第5章协议栈阅读笔记
  • 发表于 1年前
  • 阅读 184
  • 收藏 10
  • 点赞 0
  • 评论 2

腾讯云 十分钟定制你的第一个小程序>>>   

摘要: 分布式服务框架的基础是RPC,RPC的协议栈是最重要的组成部分,那么一个分布式服务框架的RPC协议栈该如何进行设计呢?本章讲作者的经验分享给了大家,本文将读该章内容后的收获分享出来。

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

关键技术决策

是否支持多协议

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

公用协议和私有协议

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

集成开源还是自研

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

功能设计

通讯模型

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

协议消息定义

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

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

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

可靠性设计

  1. 客户端连接超时。超时设置非常关键,它能够避免过长浪费系统资源,比如连接、线程等资源;还有一点是业务层的需要,需要有超时机制,客户端对于请求响应的时间有要求。
  2. 客户端重连机制。网络是不稳定的,尤其是互联网更是可靠性较低,因此网络协议的设计要针对这种不稳定性做好处理,当连接被中断后,客户端检测到之后要做自动重连,但是重连间隔不能太频繁,否则会浪费过多资源。
  3. 消息缓存重发。NIO框架例如netty都缓冲机制,将消息的发送先写入缓冲区,然后再会异步发送到网络上去,因此当链路发生中断的情况下要重新发送缓冲区中的消息,另外还要考虑缓冲区溢出的风险,当缓冲区溢出则抛出异常,不能客户端发送成功。
  4. 心跳机制。凌晨业务低谷时,当大量链接处于闲置后,大量链接将因为超时或者其它网络因素断开,则当业务量上来的时候会出现大量连接失效的问题,还有一些软件可能检测不到链接断开的假链接的情况,这些都需要增加合适的链接检测机制,通过在链接空闲的时间定期发送一个心跳包,当n各周期没有收到响应,则可以认为链接是无效的,则断开重连。

安全性设计

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

  1. 企业内网开放内部系统其它模块调用服务,通常不需要安全认证和SSL/TLS传输。因为完全是自己调用自己,则完全是可信任的。
  2. 企业内网开放外部系统其它模块调用服务,通常需要通过安全认证(比如在SOA管控平台上申请调用的appId和秘药),但是不需要SSL/TLS传输,因为企业内部的系统大体上是可信任的,但是为了防止未授权的服务误调用,要么造成业务风险,要么给系统增加调用压力,形成技术风险,我们增加一个申请授权的流程,让服务提供者评估业务和技术风险后再开放其调用。
  3. 开放给企业外部第三方系统调用,则需要认证和SSL/TLS协议传输,要增加最高标准的安全控制。因为第三方具有很高的不确定性,完全不可信,还有控制第三方系统的调用频次,细粒度的权限控制,还要防止第三方系统的各种网络攻击等等。

 

 

共有 人打赏支持
杨武兵
粉丝 192
博文 56
码字总数 123254
作品 1
评论 (2)
大风厂蔡成功
拍板很好
杨武兵

引用来自“_eechen”的评论

拍板很好
没明白啥意思?你是指排版吗?呵呵。
×
杨武兵
如果觉得我的文章对您有用,请随意打赏。您的支持将鼓励我继续创作!
* 金额(元)
¥1 ¥5 ¥10 ¥20 其他金额
打赏人
留言
* 支付类型
微信扫码支付
打赏金额:
已支付成功
打赏金额: