分布式服务框架诞生背景

一、应用从集中是走向分布式

       随着业务的发展，应用的功能越来越多，打包、部署和新特性上线周期也变得越来越困难，大流量、高并发的用户访问对服务器的压力越来越大，我们只能通过不断的增加硬件的方式来满足应用的快速响应和高的吞吐量，如图：

       通过新增硬件的方式对应用进行扩容，可以暂时顶住高峰期大并发对系统的冲击，但是仍有一些棘手问题无法通过扩容来解决，如：

       1）业务不断的发展，应用规模越来越大，大型复杂应用的开发维护成本高，部署效率降低，应用数量膨胀，数据库连接数持续增高。

       2）代码很难复用，由于公共模块都是进程内部的本地API调用，开发站经常会按需开发，导致大量功能类似甚至相同的API被重复开发，一旦设计公共模块的变更，所有重复的实现都需要重新修改、编译、测试，尤其是测试，会工作量很大，即便有些团队会有专门的公共模块开发小组，但复用的代码往往会由多个开发小组共同出人维护，代码merge和分支管理很难做好。       

       3）敏捷持续交付面临巨大挑战，想要在一个架构师都无法理顺的巨大复杂的业务中新增或者修改一个功能，难度很大。业务模块之间循环依赖，重复API定义和开发，不合理的调用、冗长复杂的业务流程对新特性的上线简直是噩梦。新需求功能开发后，测试人员需要对新功能的影响点、配置修改等做综合分析，决定是否做回归测试以及圈定测试的范围。这样的团队无疑效率低下。

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

       具体的拆分策略大致分为：横向拆分和纵向拆分：

       1）纵向拆分：通过对业务进行梳理，根据业务的特性把应用拆开，不同的业务模块独立部署，例如一个crm系统可以分为客户域、产品域、资源域、营销管理域等拆分，将复杂的业务线拆分成相对独立、灵活的具体能力域、分而治之，如图：

       2）横向拆分：将核心的、公共的业务拆分出来，通过分布式服务框架对业务进行服务化，消费者通过标准的契约来消费这些服务。服务提供者独立打包、部署和演进，与消费者解耦，业务横向拆分后，如图：

二、服务治理很迫切

       使用web服务框架或者RPC框架对业务进行拆分后，随着服务数量的增加，急需一个服务治理框架用来有效的管理服务，提升服务运行期间的质量，防止服务代码架构腐化。

       服务治理的主要目标如下：

       1）生命周期管理：服务上线随意，线上服务鱼龙混杂，上线容易下线难。服务上线前的审批、测试、发布流程和服务下线通知机制需要规范化。

       2）服务容量规划：随着业务的发展，服务调用量越来越大，服务的容量问题逐渐暴露，某个服务需要多少机器支撑、什么时候该加机器、加多少台、需要什么样的配置？需要通过采集服务调用性能、时间延迟、成功率、资源占用率