【读书笔记】分布式服务框架原理与实践

     当传统的MVC架构已无法满足业务平台的发展诉求的时候，一般架构团队会引入SOA中间件，包括企业集成总线ESB、流程编排引擎BPM、RPC通信框架等。考虑到RPC框架的一些需求包括：

•      依赖管理：当服务数量越来越多，服务URL配置管理非常复杂，就希望有一个注册中心管理服务的依赖关系。
•      透明路由：通过订阅发布机制，消费者只需要关心服务本身，并不需要配置具体的服务提供者，实现服务的自动发现。
•      服务治理：业务失败之后的放通处理，超时时间控制、流控操作，会有一个独立的服务治理中心，统一对集群各节点的服务做在线服务治理，提升治理效率。

 随着DevOps和docker技术的成熟发展，微服务架构也会越来越流行起来，它是敏捷开发、基础设施服务化、devops的综合产物，像AWS就是微服务的成功实践者，后续可能国内的很多大公司也会走向微服务架构。

 架构演进：传统的MVC垂直架构 -> RPC框架  -> 分布式服务框架 ->  docker + 微服务方向。

第1章节 应用架构演进

RPC框架实现的几个核心技术点如下

1. 远程服务提供者需要以某种形式提供服务调用相关信息，包括但不限于服务接口定义、数据结构、中间态服务定义文件，比如IDL文件
2. 远程代理对象：服务调用者调用的服务实际是远程服务的本地代理，对于JAVA语言，它的实现就是JDK的动态代理，通过动态代理的拦截机制将本地调用封装成远程服务调用。
3. 通信：RPC框架与具体的协议无关
4. 序列化：远程通信，需要将对象转换成二进制码流进行网络传输，不同的序列化框架支持的数据类型、包大小、异常类型及性能不同

比较流行的RPC框架：thrift,Avro-RPC,hessian,gRPC等；

RPC面临的问题：

1. 当服务越来越多的时候，服务URL配置非常困难，这个时候就需要一个注册中心，动态地注册和发现服务。消费者在本地缓存服务提供者列表、实现软负载均衡，可以降低F5等硬件负载的依赖，降硬件成本。
2. 服务间依赖关系越来越复杂，搞不清楚是A应用依赖了B应用还是依赖了C应用，这个时候就需要有一个分布式消息跟踪系统可视化展示服务调用链，用于依赖分析、业务调用梳理。防止业务服务架构腐化。
3. 服务的调用量越来越大，服务的容量问题就出来了，某一个服务需要多少机器来支撑呢，什么时候该加机器，为了解决容量规划问题，需要采集服务调用KPI数据，进行汇总和分析，通过计算得出服务部署实例数和服务器的配置规格。
4. 服务上线容易下线难，上线前的审批，下线通知，需要统一的服务生命周期管理流程，这个就是服务治理问题。需要服务框架 + 服务治理来完成，单纯的RPC解决不了。

SOA服务治理

1）分布式框架下的服务调用性能。

2）服务化架构如何支持线性扩展。

3）如何实现高效、实时的服务多维度监控

4）大规模分布式环境下的故障快速定界和定位。

5）分布式环境下海量日志在线检索、模糊查询

6）服务的流控、超时控制、服务升降级

7）服务的划分原则，如何实现最大程度的复用

关于微服务

持续交付促使我们构建更快、更可靠、更频繁的软件部署和交付能力；CI自动化构建帮助我们简化环境的创建、编译打包和部署；devops的流行促进小团队独立运作和交付。

微服务架构主要特征如下：

1. 原子服务，专注于做一件事：“高内聚，松ou 合”
2. 高密度部署：重要的服务可以独立部署进程，非核心服务可以独立打包，合设到一个进程中，服务被高密部署。
3. 敏捷交付；服务由小团队从设计、开发、测试、部署，线上治理灰度发布及上线，实现真正的devops.
4. 微自治：服务足够小，功能单一，可以独立打包、部署升级、回滚和弹性伸缩，不依赖其他服务实现局部自治。

相对于SOA架构对比，差异在：

• 服务拆分粒度：SOA首要解决的是异构应用服务化，微服务强调的是服务拆分尽可能小，最好是独立的原子服务。
• 服务依赖：传统的SOA服务由于需要重用已有的资产，存在大量服务间依赖；微服务设计是服务自治，功能单一独立
• 服务规模：微服务强调的是尽可能拆分，而且会独立部署，这将导致服务急剧膨胀，对服务治理和运维带来问题
• 架构差异；微服务之后服务数量激增会引起架构质量属性的变化，ESB可能会被P2P虚拟总线替换
• 服务治理：传统基于SOA的静态治理转型为服务运行态微治理、实时生效
• 敏捷交付；服务由小团队负责微服务设计、开发、测试、部署线上运维实现devops

总结：后面看一下JAVA里面如何实现微服务的，以及我们看看在实际的工作项目中如何引入微服务架构来取代当前的架构实现。

第2章节 分布式服务框架入门

 一般大规模系统架构设计一般原则是尽可能拆分，以达到更好独立扩展与伸缩、更灵活的部署、更好的隔离和容错、更高的开发效率。具体的拆分可分横向与纵向

• 纵向拆分：依据业务特性进行拆分，不同业务模块独立部署。比如CRM可以拆分成客户域、产品域、资源域、营销管理域，将一个复杂的业务线拆分相对独立、灵活的具体能力域，由大变小，分而治之。
• 横向拆分：将核心的、公共业务拆分出来，提供服务给上层业务调用。比如登录系统、会员中心、库存中心、交易中心等.可以服务电商线、移动端等

2.1.2 关于服务治理

因为服务拆分之后越来越多的服务需要治理，防止架构会腐化。服务治理的主要诉求：

1. 生命周期管理：服务上线、服务下线。比如上线前的流程、下线的通知机制，需要规范化。
2. 服务容量规划：某个服务需要多少机器支撑，什么时候该加机器，加多少台机器，就需要采集服务调用性能，时延，成功率等综合指标，通过对历史数据进行分析，识别出来服务容量瓶颈，得到单核CPU能够支持的服务调用量。
3. 运行期治理：比如大促需要对非核心服务实现降级（比如交易环节可以对某些非核心应用降级处理）、限流（双11的时候排队）、保证核心业务运行稳定；当缓存失效，流量进DB，导致某个服务的RT陡增，这个时候需要可以做到在线调大调用超时时间，保证业务成功率；对非核心的服务降级处理，比如非核心服务挂了，可以支持在线配置把服务调用停了。
4. 服务安全：敏感数据服务化之后，如何对消费者鉴权，防止非法数据访问到（比如查询用户信息的数据，同一个接口不同的调用方希望可以拿到不同的结果有些字段是需要脱敏处理的）？相同的服务，对内与对外提供能力存在差异，服务化之后，服务的安全控制是服务治理核心功能之一。

像thrift只不过是RPC框架，并不是一个完整的分布式服务框架的所有。淘宝内部的HSF。

第3章节 通信框架

3.1 关键技术点分析

3.1.1 关于长连接与短连接 

大多数的RPC框架都推荐使用长连接进行内部通信，长连接的好处：

1）PK短连接，长连接更节省资源。可以实现多消息复用同一个链路节省资源。

2）服务化之后，本地API调用变成了远程服务调用，大量本地调用演化成了跨进程通信，网络延时成为关键指标，相对于一次简单的服务调用，链路的重建通常耗时更多

3.1.2 BIO还是NIO

在JDK1.4之前JAVA都是同步阻塞模式（BIO），所以在这一段时间里大型服务器都采用C或C++开发直接调用OS层的异步IO或AIO能力。在IO编程过程中当需要同时处理多个客户端接入请求时可以利用多线程或IO多路复用技术进行处理。IO多路复用技术通过把多个IO的阻塞复用到同一个select的阻塞上，从而使得系统在单线程的情况下可以同时处理多个客户端请求。与传统的多线程/多进程模型相比IO多路复用最大 优势就是系统开销小，系统不需要创建新的额外进程或线程。

NIO采用多路复用技术，一个多路复用器Selector可以同时轮循多个Channel由于JDK使用了epoll()代替传统的select实现，所以它并没有最大连接1024/2048的限制。这也意味着只需要一个线程负责Selector的轮循，就可以接入成千上万的客户端。

可以参考使用开源的实现Netty。它的优势如下：

• API使用简单，开发门槛低
• 功能强大，预置了多种编解码功能，支持多种主流协议
• 定制能力强，可以通过channelHandler对通信框架进行灵活扩展
• 性能高，通过与其他业界主流NIO框架相比，netty的综合性能最优
• 成熟、稳定