分布式服务框架诞生背景

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

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

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

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

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

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