应用架构演进

这里的架构演进应该是从服务化的角度来说，应该说随着业务发展，应用规模扩大，系统的一些公共服务就会抽取出来，独立开发，部署，维护，用来解决并发，扩展，维护的问题。

传统垂直架构

有的地方也叫单体应用，以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）：调用失败后切换链路调用；服务提供者的防重；重试次数和超时时间的设置。失败通知（FailBack）：失败后直接返回，由消费端自行处理；失败缓存（Failcache）：主要是失败后，缓存重试重发，注意：缓存时间、缓存数量；缓存淘汰算法；定时重试的周期T、重试次数；快速失败（Failfast）：失败不处理，记录日志分析，可用于大促期间，对非核心业务的容错。

容错策略扩展

容错接口的开放；屏蔽底层细节，用户自定义；支持扩展。

其实还有一点，感觉也挺重要，就是支持容错后本地mcok。调用失败后的链路切换和快速失败肯定要支持，缓存重发可以不用。