1章：应用架构演进¶
1.1 传统垂直应用架构¶
LAMP + Mysql (读写分离) 与 MVC 缺陷： - 开发和维护成本高，部署效率下降 - 团队协作效率差，代码重复率搞 - 可靠性变差 - 维护和定制困难，代码牵一发而动全身 - 新功能上线周期变长
1.2 RPC 架构¶
RPC： remote producedure call - 需要提供某种形式提供服务调用相关信息，接口定义，数据格式等 - 远程代理对象 - 通信 - 序列化：将对象转成二进制码流进行网络传输
主流 rpc 框架： - Apache Thrift - Hadoop 子项目 Avro-RPC - Google 基于 HTTP/2 ProtoBuf gRPC
难以解决服务治理问题
1.3 SOA 服务化架构¶
SOA 是一种粗粒度、松耦合的以服务为中心的架构，接口之间通过定义明确的协议和接口进行通信 一般原则： - 服务可复用 - 服务共享一个标准契约 - 服务是松耦合的：功能相对独立，不依赖其他服务的独立功能提供者 - 服务是底层逻辑的抽象：暴露的契约才对外可见 - 服务是可组合，可编排的 - 服务是自治的：不依赖其他服务 - 服务是无状态的 - 服务是可被自动发现的
1.4 微服务架构¶
主要特征： - 原子服务，专注于做一件事 - 高密度部署 - 敏捷交付：devops - 微自治：局部自治
2章：分布式服务框架入门¶
对应用进行服务化
2.1 分布式服务框架诞生背景¶
服务治理主要诉求： - 生命周期管理 - 服务容量规划 - 运行期治理 - 服务安全
- 阿里 Dubbo
- 淘宝 HSF
2.3 分布式服务框架设计¶
通常架构抽象为三层： - rpc 层：包括通信框架、序列和反序列化、用于屏蔽底层通信协议细节和序列方式差异的 - filter chain 层：服务调用职责链。负载均衡、性能统计、通知机制、失败重发等 - sevice 层：将服务提供者的接口封装成远程服务调用
从功能角度看： - 服务注册中心：服务发布和通知 - 服务治理中心:服务治理接口和服务 portal，运维人员可以通过服务治理portal 对服务的运行状态、历史数据、 健康度、调用关系等可视化
功能特性： - 服务订阅发布 - 服务路由 - 集群容错 - 服务调用 - 多协议 - 序列化方式 - 统一配置
性能特性：高性能、低时延、性能线性增长
可靠性：服务注册中心、清除单点故障、链路健壮性
服务治理：运行状态监控、监控、生命周期管理、故障定位、服务安全
3章：通信框架¶
关键技术点： - 长链接还是短链接：通常用长连接 - 同步异步：高并发使用非阻塞模式
服务端设计： - 提供上层 api - 可扩展的编解码插件 - 提供拦截面
客户端设计：
可靠性： - 链路有效性：心跳检测：tcp 层、协议层、应用层 - 断链重连机制： - 消息缓存重发： - 资源释放：
性能设计： - 性能差三宗罪：网络传输方式（同步异步）、序列化方式、线程模型 - 通信性能三原则：传输、协议、线程
4章：序列化与反序列化¶
- 序列化（encode）：将对象序列化成字节数组，用于网络传输、持久化等
- 反序列化（decode）：把从网络、磁盘等读取的字节数组还原成原始对象（副本），以方便后续的业务逻辑操作。
功能设计： - 功能丰富度：数据结构支持 - 跨语言支持： - 兼容性：接口兼容、业务逻辑兼容、数据兼容性。前向兼容性 - 性能：序列化之后码流大小、序列化、反序列化速度、资源占用cpu、内存
5章：协议栈¶
可以扩展，但是未必一定要支持多协议 分布式服务框架默认使用性能更高、扩展性更好的私有协议（二进制）进行通信。对于部分需要和外部对接的服务，可以用http等公有协议。
协议描述了分布式服务框架的通信契约，序列化和反序列化框架用于对象和二进制数组之间的相互转换
6章：服务路由¶
透明化路由原则 基于服务注册中心的订阅发布：ZooKeeper 消费者缓存服务提供者地址。注册中心主动将变更内容推送给消费者。后者动态刷新本地缓存的服务路由表。
负载均衡： - 随机：缺点是碰撞概率高、不均匀 - 轮询: 累积请求问题 - 服务调用时延：根据时延调整权重，防止消息堆积。计算每个服务提供者调用时延和平均时延差值 - 一致性哈希：相同参数请求总是发送到同一个提供者。一个宕机基于虚拟节点平摊到其他提供者 - 粘滞连接：尽可能让客户端总是向同一个服务提供者发起调用服务，除非其宕机，再连接另一台。很少用
本地路由优先策略： - injvm - innative: 通信流量走本地网卡魂环
路由规则： 条件路由规则 脚本路由规则
路由定制策略； - 灰度升级 - 服务故障、业务高峰导流 - 业务相关定制需求
配置化路由: - 本地策略 - 统一注册管理 - 动态下发
7章：集群容错¶
集群容错场景： - 通信链路故障 - 服务端超时 - 服务端调用失败
容错策略： - 失败自动切换（failover）：rpc 调用异常时，重新选路，查找下一个可用的服务提供者。 - 场景：读取操作（幂等）； - 失败通知（failback）：rpc 异常通知给消费者，消费者捕获异常后后续处理。 - 失败缓存（failcache）： - 服务有状态路由，必须定点发送到指定的服务提供者。服务不可用时，服务框架将消息缓存，等待周期T重新发送，直到服务提供者能正常处理 - 对时延要求不敏感的服务。先缓存，再等待，最后重试（自动恢复模式） - 快速失败(failfast): 调用异常后，直接忽略，然后记录日志
8章：服务调用¶
误区： - NIO 就是异步服务 - 服务调用天生就是同步的。oneway模式（只有请求没有应答）。请求-应答模式
服务调用方式： - 同步服务调用。调用方需要设置超时时间 - 异步服务调用。Future-Listener 机制，支持主动获取和被动异步回调通知两种模式。 - 并行服务调用。逻辑上没有相互依赖关系（执行顺序无要求）；长流程。原理：一次同时发起多个服务调用，再利用 future 等主动等待获取结果，进行结果汇聚
9章：服务注册中心¶
避免硬编码地址信息 几个概念： - 服务提供者：发布服务的服务提供方，通常是一个普通的 java 实现类 - 服务消费者：调用远程服务的消费方，可能是个简单的客户端 - 服务注册中心：分布式服务框架的目录服务器。特点： - 高 HA。支持数据持久化、支持集群 - 数据一致性问题。所有客户端应该看到同一份数据，不能出现读或者写数据不一致 - 数据变更主动推送。当注册中心的数据发生变更时（增加、删除、修改）需要能及时将变化的数据通知客户端
关键功能特性设计： - 支持对等集群 - 提供 crud 接口 - 安全加固。链路安全性（客户端安全认证）和数据安全性（对服务注册中心的数据权限控制） - 订阅发布机制 - 可靠性
基于 ZooKeeper 的服务注册中心设计: - 服务订阅发布流程 - 服务健康状态检测 - 对等集群防止单点故障：ZooKeeper通常由2n+1 台 Server 组成 - 变更通知机制