应用架构演进
这里的架构演进应该是从服务化的角度来说，应该说随着业务发展，应用规模扩大，系统的一些公共服务就会抽取出来，独立开发，部署，维护，用来解决并发，扩展，维护的问题。
传统垂直架构
有的地方也叫单体应用，以mvc模式开发：
- 所有应用代码统一打包，代码所有接口本地api调用，很少存在远程服务调用;
- 单机或主备，应用做集群部署；
- DB主从等。
这种并没有什么不好，发展初期大多是这样，体量没那么大，也不需要考虑高并发大流量可扩展性什么的，简单粗暴，解决业务需求就好，活下去才能活的更好。
但是必须明白这种简单架构存在的一些问题：
1. 业务不断发展，功能逐渐增多，应用的开发维护成本变高，部署效率降低，随便改个代码，编译一次十几分钟就浪费了。悲剧，我们有个系统才开发3年，就碰到这种情况，一次打包编译部署，13分钟结束。
2. 不同的人负责不同的部分，一些通用代码、公共代码就各写各的，不能复用，如果只是util还好，但是一些外部服务的都有重复，那就happy了（不过这种情况的出现，不一定是架构问题，更多可能是管理）；
3. 不断地上新需求，不断地改代码，有时测试不到位，指定哪里埋了bug，上生产后系统就down了，牵一发而动全身；
4. 可维护性，可靠性，扩展性变差。
既然有这些问题，就要解决啊，业务就会提要求，你要解决啊，要不然影响我业务发展，影响我ipo上市啊，苦逼的码农开始干活了。
不提应用的拆分主从那些手段，但从拆分后应用交互看，原来的本地api交互变成的远程api的调用，这里就出现了rpc，当然也有走esb，webservice。其实拆分后挺麻烦的，光一个分布式事务就能折腾死人。
RPC架构
Remote Procedure Call，远程方法调用，屏蔽底层实现细节，像调用本地方法一样调用远程服务。
上个作者的图：
背景
应用从集中式走向分布式
随着业务的发展导致功能的增多，传统的架构模式开发，测试，部署整个流程变长，效率变低，后台服务的压力变大，只能通过硬件扩容来暂时缓解压力，但解决不了根本性问题：
- 应用规模变大，开发维护成本变高，部署效率降低；
- 代码复用：原来是本地api调用，导致一些公用功能可能是按需开发，不统一，随意等问题；
- 交付面临困难：主要是业务变得复杂，新增修改测试变得困难，拉长整个流程。
通用法宝：拆分，大系统拆小系统，独立扩展和伸缩。
- 纵向：分业务模块；
- 横向：提炼核心功能，公共业务；
需要服务治理
大拆小，核心服务提炼后，服务的数量变多，而且需要一些运行态的管控，这时候就需要服务治理：
- 服务生命周期管理；
- 服务容量规划；
- 运行期治理；
- 服务安全。
服务框架介绍
Dubbo
阿里开源的Dubbo应该是业界分布式服务框架最出名的了吧，看过公司的rpc框架，Dubbo的扩展性比我们的好的多了，我们的框架每次升级，改动都很多，改天要看下Dubbo的源码了解了解扩展性。
HSF
淘宝的体量决定了他对极致性能的追求，HSF跨机房特性挺牛。
Coral Service
这个没听说过，孤陋寡闻了。
细化了下：
性能
分布式的，面试会问，用池子的话讲就是，知识点啊。
服务治理
技术点
- 长连接：主要是链路的创建过程到最后的关闭，耗时耗资源；每次调用都要创建的话，调用时延的问题，很可能链路创建的耗时比代码真正执行时长还多；
- BIO还是NIO：主要是线程模型的选择，推荐篇文章 IO – 同步，异步，阻塞，非阻塞 （亡羊补牢篇）；
- 自研还是使用开源NIO框架：一般来说还是使用开源吧，技术成熟，社区支持，现在netty和mina使用较多了吧。
服务提供者和消费者之间采用单链路，长连接通信，链路创建流程：
1. 客户端发送握手请求，携带节点ID等认证信息；
2. 服务端校验：节点ID有效性，重复登录，ip地址黑白名单等，通过后，返回握手应答信息；
3. 链路建立后，客户端发送业务消息；
4. 客户端服务端心跳维持链路；
5. 服务端退出时，关闭连接，客户端感知连接关闭，关闭客户端连接。
协议消息定义
通过attachment兼容了扩展性。作者还讲了将消息头的通用序列化和消息体的自定义序列化，看需求吧，我们公司的框架没做这部分支持，做了简化，将消息头和消息体统一封装，然后再加一个序列化方式组成一条消息发送。
安全性设计
- 内部的，不一定需要认证，也有基于系统，域名，ip的黑白名单，安全认证的；
- 外部开发平台的话，基于秘钥认证；
服务路由
服务路由指的是服务提供者集群部署，消费端如何从服务列表中选择合适的服务提供者提供服务进行调用。
透明化路由
- 基于zk的服务注册中心的发布订阅；
- 消费者本地缓存服务提供者列表，注册中心宕机后，不影响已有的使用，只是影响新服务的注册和老服务的下线。
负载均衡
- 随机
- 轮循
- 服务调用时延
- 一致性Hash
- 有个一致性hash算法，挺有意思的，redis的客户端shard用的
这图不错，关系很清晰。
- 失败自动切换（Failover）：
- 调用失败后切换链路调用；
- 服务提供者的防重；
- 重试次数和超时时间的设置。
- 失败通知（FailBack）：失败后直接返回，由消费端自行处理；
- 失败缓存（Failcache）：主要是失败后，缓存重试重发，注意：
- 缓存时间、缓存数量；
- 缓存淘汰算法；
- 定时重试的周期T、重试次数；
- 快速失败（Failfast）：失败不处理，记录日志分析，可用于大促期间，对非核心业务的容错。
容错策略扩展
- 容错接口的开放；
- 屏蔽底层细节，用户自定义；
- 支持扩展。
其实还有一点，感觉也挺重要，就是支持容错后本地mcok。调用失败后的链路切换和快速失败肯定要支持，缓存重发可以不用。
