《分布式服务架构原理与实践》阅读笔记

前言

  转眼间工作已经有了一年半，工作之后所做的事情与预想中的还是有较大的差距的。回想一年多以来，大多数的时间都在处理业务逻辑或是重构已有的代码，在前人的基础上修修改改，真正的技术进步并不是很大。

  做程序员这一行，还是要经常反省，时常学习的。在工作时间之外尽可能去了解一些工作接触不到的知识面。在工作的第一年，读了一些C++程序员的基础书籍，今年准备读一些更高层次的东西，比如框架，设计等，扩展一下视野。

  本篇博文记录一些笔者在阅读《分布式服务框架原理与实践》过程中一些比较经典的图示或语句。

正文

1.应用架构的演进

• MVC架构：读书时候做的大多数项目都是MVC架构，适用于业务规模小的场景。所有功能部署在同一个进程中，通过双机或者前置硬件负载均衡器来实现负载均衡。用于分离前后台逻辑是MVC架构的关键
• RPC架构 ：将核心业务和公共服务抽离供上层使用。用于提高业务复用和拆分是RPC框架的关键
• SOA架构 ：面向服务的架构，多用于企业内部，重用已有的不同的异构组件。
• 微服务架构 ：便于敏捷开发、持续交付。将服务原子化，各个微服务独自打包部署和升级，降低开发和运维成本

2.通信框架

1、关键技术点

• 长连接和短连接：长连接更节省资源
• 同步IO和异步IO：同步IO调用简单，异步IO性能高

2、可靠性设计

• 链路有效性检测：保持心跳，单向心跳双向心跳都行
• 断线重连：断线之后过段时间再重连
• 消息缓存
• 资源优雅释放

3.序列化

  序列化就是将对象序列化为字节流用于不同进程之间的通信。常见的序列化技术有谷歌的protobuf和facebook的thift，谷歌的性能更优。分布式框架应该支持扩展性，可扩展多种序列化方式。

4.协议栈

1. 可靠性设计

• 客户端连接超时
• 客户端断线重连
• 客户端重复握手保护
• 消息缓存重发，对方宕机恢复之后将宕机期间发送失败的消息重新发送
• 心跳机制

1. 协议的兼容性和可扩展性

   

5.服务路由

1.透明化路由

• 基于服务注册中心的订阅发布

• 消费者缓存服务提供者地址：即使服务注册中心宕机也不会影响消费者与生产者之间的通信

  2.负载均衡

• 随机
• 轮询
• 服务调用时延
• 一致性哈希
• 粘纸连接

2.路由规则

总的来说路由规则配置要足够灵活，支持多种配置方式，实时生效，部分生效等。

6.集群容错

1. 集群容错的场景

• 通信链路故障
• 服务端超时
• 服务端调用失败

1. 容错策略

• 失败自动切换
• 失败通知：通知上层调用者，由上层处理
• 失败缓存：缓存请求，等链路正常后再发送
• 快速失败：直接忽略异常，记录日志
• 容错策略扩展:支持可扩展，采用其他手段根据不同条件不同处理

7.其他

1. 基于注册中心的订阅发布

   

2. 分布式事务设计

   两阶段提交采用的是悲观锁策略，需要等待最慢的参与者，一旦协调者故障则整个事务就会阻塞。在分布式框架中，事务是一件很麻烦的事情。应尽量在业务层避免使用分布式事务。在大多数的业务场景中，我们可以使用最终一致性替代传统的强一致性。