这里的架构演进应该是从服务化的角度来说，应该说随着业务发展，应用规模扩大，系统的一些公共服务就会抽取出来，独立开发，部署，维护，用来解决并发，扩展，维护的问题。
传统垂直架构
有的地方也叫单体应用，以mvc模式开发：
- 所有应用代码统一打包，代码所有接口本地api调用，很少存在远程服务调用; 单机或主备，应用做集群部署； DB主从等。
这种并没有什么不好，发展初期大多是这样，体量没那么大，也不需要考虑高并发大流量可扩展性什么的，简单粗暴，解决业务需求就好，活下去才能活的更好。
但是必须明白这种简单架构存在的一些问题：
1. 业务不断发展，功能逐渐增多，应用的开发维护成本变高，部署效率降低，随便改个代码，编译一次十几分钟就浪费了。悲剧，我们有个系统才开发3年，就碰到这种情况，一次打包编译部署，13分钟结束。
2. 不同的人负责不同的部分，一些通用代码、公共代码就各写各的，不能复用，如果只是util还好，但是一些外部服务的都有重复，那就happy了（不过这种情况的出现，不一定是架构问题，更多可能是管理）；
3. 不断地上新需求，不断地改代码，有时测试不到位，指定哪里埋了bug，上生产后系统就down了，牵一发而动全身；
4. 可维护性，可靠性，扩展性变差。
既然有这些问题，就要解决啊，业务就会提要求，你要解决啊，要不然影响我业务发展，影响我ipo上市啊，苦逼的码农开始干活了。
不提应用的拆分主从那些手段，但从拆分后应用交互看，原来的本地api交互变成的远程api的调用，这里就出现了rpc，当然也有走esb，webservice。其实拆分后挺麻烦的，光一个分布式事务就能折腾死人。
RPC架构
Remote Procedure Call，远程方法调用，屏蔽底层实现细节，像调用本地方法一样调用远程服务。
上个作者的图：
这个图对于大多数rpc框架通用，实现的几个技术点：
1. 服务提供者发布服务：服务接口定义，数据结构，服务提供者信息等；
2. 客户端远程调用：通常是使用jdk的代码代理拦截；
3. 底层通信：现在应该更多是使用netty吧，当然也有走支持http的；
4. 序列化：关注序列化反序列性能，xml，json，hessiaon，pb，protostuff，kryo等；
作者给了个socket实现简单demo，来实现远程调用，说明上面几个技术点。
常用的rpc框架
1. Thrift；
2. Hadoop的Avro-RPC;
3. Hessian；
4. gRPC;
单论rpc的话，没太多可说的，可是如果加上服务治理，那复杂度就几何倍数增长了。服务治理里面东西太多了，动态注册，动态发现，服务管控，调用链分析等等问题这些问题，单凭rpc框架解决不了，所以现在常用的说的服务化框架，通常指的是rpc+服务治理2个点。
SOA服务化架构
感觉soa架构应该是在rpc之前出现，用来解决异构系统的交互，通常的实现是通过ESB，WSDL来处理。其粒度通常来说是比较粗的。也存在服务治理方面的问题。
微服务
MSA也是一种服务化架构风格，正流行ing，服务划分
1. 原子服务，粒度细；
2. 独立部署，主要是容器；
分享篇文章：云栖肥侠的文章 微服务（Microservice）那点事 。
MSA与SOA的对比：
- 服务拆分粒度：soa首要解决的是异构系统的服务化，微服务专注服务的拆分，原子服务； 服务依赖：soa主要处理已有系统，重用已有的资产，存在大量服务间依赖，微服务强调服务自治，原子性，避免依赖耦合的产生； 服务规模：soa服务粒度大，大多数将多个服务合并打包，因此服务实例数有限，微服务强调自治，服务独立部署，导致规模膨胀，对服务治理有挑战； 架构差异：微服务通常是去中心化的，soa通常是基于ESB的； 服务治理：微服务的动态治理，实时管控，而soa通常是静态配置治理； 交付：微服务的小团队作战。
感觉在有了docker后，微服务这个概念突然火了起来，总结就是微服务+容器+DevOps。
分布式服务框架入门背景
应用从集中式走向分布式
随着业务的发展导致功能的增多，传统的架构模式开发，测试，部署整个流程变长，效率变低，后台服务的压力变大，只能通过硬件扩容来暂时缓解压力，但解决不了根本性问题：
- 应用规模变大，开发维护成本变高，部署效率降低； 代码复用：原来是本地api调用，导致一些公用功能可能是按需开发，不统一，随意等问题； 交付面临困难：主要是业务变得复杂，新增修改测试变得困难，拉长整个流程。
通用法宝：拆分，大系统拆小系统，独立扩展和伸缩。
- 纵向：分业务模块； 横向：提炼核心功能，公共业务；
需要服务治理
大拆小，核心服务提炼后，服务的数量变多，而且需要一些运行态的管控，这时候就需要服务治理：
- 服务生命周期管理； 服务容量规划； 运行期治理； 服务安全。
服务框架介绍
Dubbo
阿里开源的Dubbo应该是业界分布式服务框架最出名的了吧，看过公司的rpc框架，Dubbo的扩展性比我们的好的多了，我们的框架每次升级，改动都很多，改天要看下Dubbo的源码了解了解扩展性。
HSF
淘宝的体量决定了他对极致性能的追求，HSF跨机房特性挺牛。
Coral Service
这个没听说过，孤陋寡闻了。
框架设计
架构原理
万变不离其中，这张图可以概括rpc的一些通用原理：
细化了下：
- rpc层：底层的通讯框架，通讯协议，序列化和反序列化； 服务发布订阅； 服务治理；
功能
性能
可靠性
分布式的，面试会问，用池子的话讲就是，知识点啊。
服务治理
通讯框架技术点
- 长连接：主要是链路的创建过程到最后的关闭，耗时耗资源；每次调用都要创建的话，调用时延的问题，很可能链路创建的耗时比代码真正执行时长还多； BIO还是NIO：主要是线程模型的选择，推荐篇文章 IO – 同步，异步，阻塞，非阻塞 （亡羊补牢篇）； 自研还是使用开源NIO框架：一般来说还是使用开源吧，技术成熟，社区支持，现在netty和mina使用较多了吧。
在功能设计方面，作者基于netty给了demo服务端和客户端的代码，个人理解：
1. 通用性api；
2. 扩展性，封装底层，提供上层接口，隔离协议和底层通讯；
可靠性设计
谈分布式系统必谈可靠性。
链路有效性
通过心跳来确认双方c、s存活，保证链路可用，心跳检测机制分为3个层面：
1. tcp层面，即tcp的keep-alive，作用于整个tcp协议栈；
2. 协议层的心跳检测，主要存在于长连接协议中，例如smpp协议；
3. 应用层的心跳，业务双方的定时发送心跳消息；
第2个没听说过，常用的是1,3。一般使用netty的话用的是netty的读写空闲来实现心跳。
断连
不管因为网络挂了还是服务端宕机，还是心跳超时什么的，导致链路不可用关闭，这时候就需要链路重连，需要注意的一点就是短连后，不要立即重连，留时间给系统释放资源，可以scheduler处理。
消息缓存重发
底层消息不会立即发送（也会导致半包粘包），断链后，导致消息丢失，看有无业务需求，有就支持断链后消息重发。
资源释放
主要是断链后，一定要保证资源销毁和释放，当然也包括一些线程池，内存等的释放。
性能设计
性能差的三宗罪
对于底层通讯框架来说，主要是下面几个：
1. 通讯模型的选择，主要是阻塞非阻塞那些东西；
2. 序列化反序列化（后面有章单讲序列化）；
3. 线程模型，主要是服务端选择什么样的线程模型来处理消息。
通信性能三原则
既然有上面的3个问题，那就针对这些做优化了：
- 传输：BIONIOAIO的选择； 选择自定义协议栈，便于优化； 服务端线程模型，单线程处理还是线程池，线程池是一个，还是分优先级，Reactor还是其他什么的。
高性能之道这节作者讲了netty的优势。
序列化与反序列化也就是通常所说的编码、解码。通常的通讯框架会提供编解码的接口，也会内置一些常用的序列化反序列化工具支持。
与通讯框架和协议的关系，感觉可以理解为：通讯框架是通道，其上跑的码流数据是利用各种序列化编码后的各种协议。
功能设计
各种序列化框架需要考虑的主要有：
序列化框架本身的功能的丰富，支持的数据类型； 多语言的支持； 兼容性，往大了说：- 服务接口的前后兼容； 协议的兼容； 支持的数据类型的兼容。
- 序列化后码流大小； 序列化的速度； 序列化的资源占用。
在扩展性这节，作者讲了netty的对序列化的一些内置支持，但实际开发中，一般不太会使用这些东西，都会提供序列化反序列接口，自行扩展定义，所以扩展性特重要。
常用的序列化，xml，json，hessian，kryo，pb，ps，看需求需要支持那种，具体可以搜索各序列化的性能和压缩后大小。
协议栈这一章最主要的是讲了自定义协议栈的设计，已经交互的过程，其他讲的可靠性设计什么的跟之前通讯框架一章有重复。
通信模型
服务提供者和消费者之间采用单链路，长连接通信，链路创建流程：
1. 客户端发送握手请求，携带节点ID等认证信息；
2. 服务端校验：节点ID有效性，重复登录，ip地址黑白名单等，通过后，返回握手应答信息；
3. 链路建立后，客户端发送业务消息；
4. 客户端服务端心跳维持链路；
5. 服务端退出时，关闭连接，客户端感知连接关闭，关闭客户端连接。
协议消息定义
通过attachment兼容了扩展性。作者还讲了将消息头的通用序列化和消息体的自定义序列化，看需求吧，我们公司的框架没做这部分支持，做了简化，将消息头和消息体统一封装，然后再加一个序列化方式组成一条消息发送。
安全性设计
- 内部的，不一定需要认证，也有基于系统，域名，ip的黑白名单，安全认证的； 外部开发平台的话，基于秘钥认证；
服务路由指的是服务提供者集群部署，消费端如何从服务列表中选择合适的服务提供者提供服务进行调用。
透明化路由
- 基于zk的服务注册中心的发布订阅； 消费者本地缓存服务提供者列表，注册中心宕机后，不影响已有的使用，只是影响新服务的注册和老服务的下线。
负载均衡
随机 轮循 服务调用时延 一致性Hash- 有个一致性hash算法，挺有意思的，redis的客户端shard用的
- 这个应该不太常用，服务提供者多数无状态，一旦有状态，不利于扩展
这些都是点对点的连接，负载均衡大多会在客户端执行，有种场景会取决于服务端负载，就是服务端服务配置的是域名。
本地路由优先策略
injvm：jvm也提供了消费端的服务，可以改成优先本jvm，对于消费端来说，不需关注提供者； innative：injvm比较少，多得是可能是这种，一个物理机部署多个虚拟机，或者一个容器部署多个服务提供者，消费者不需远程调用，本机，本地或本机房优先。路由规则
除了上面提供的各种路由负载均衡，还容许自定义路由规则:
– 条件路由：主要是通过条件表达式来实现；
– 脚本路由：通过脚本解析实现。
其实应该还有一种客户端通过代码自定义路由选择。这些主要是为了扩展性。
路由策略定制
自定义路由场景：
1. 灰度；
2. 引流；
路由策略：
1. 框架提供接口扩展；
2. 配置平台提供路由脚本配置；
配置化路由
- 本地配置：包括服务提供者和消费者，全局配置3种； 注册中心：路由策略统一注册到服务注册中心，集中化管理； 动态下发：配置后动态下发各服务消费端。
指的是服务调用失败后，根据容错策略进行自动容错处理。
集群容错场景
通信链路故障：- 通信过程中，对方宕机导致链路中断； 解码失败等原因Rest掉链接； 消费者read-write socketchannel发生IOException导致链路中断； 网络闪断故障； 交换机异常导致链路中断； 长时间Full GC导致；
- 服务端没有及时从网络读取客户端请求消息，导致消息阻塞； 服务端业务处理超时； 服务端长时间Full GC；
- 服务端解码失败； 服务端流控； 服务端队列积压； 访问权限校验失败； 违反SLA策略； 其他系统异常；
业务执行异常不属于服务端异常。
容错策略
这图不错，关系很清晰。
失败自动切换（Failover）：- 调用失败后切换链路调用； 服务提供者的防重； 重试次数和超时时间的设置。
- 缓存时间、缓存数量； 缓存淘汰算法； 定时重试的周期T、重试次数；
容错策略扩展
- 容错接口的开放； 屏蔽底层细节，用户自定义； 支持扩展。
其实还有一点，感觉也挺重要，就是支持容错后本地mcok。调用失败后的链路切换和快速失败肯定要支持，缓存重发可以不用。