Summary

旧系统拆分时机

编译、部署困难

对于网站开发工程师而言，打包构建一个巨型应用是一件痛快的事情。或许仅修改了一行代码，执行构建命令后，构建耗时久，好不容易构建完成，发现编译失败，得重新来过。

代码分支管理困难

复用的代码模块有多个团队共同维护修改，代码merge的时候总会发生冲突。代码merge一般在网站发布的时候，和发布等问题互相纠结，顾此失彼，每次发布都要半夜三更。

数据库连接耗尽

巨型的应用、大量的访问，必然需要将这个应用部署在一个大规模的服务器集群上，应用与数据库的连接通常使用数据库连接池，以每个应用10个连接计，一个数百台服务器集群的应用将需要在数据库上创建数千个连接，数据库服务器上，每个连接都会占用一些昂贵的系统资源，以至于数据库缺乏足够的系统资源进行一般的数据操作。

新增业务困难

想要在一个已如乱麻般系统中增加新业务，维护就功能，难度可想而知。

一脚踩进去，发现全是雷，什么都不敢碰。新工程师入职半年，依旧无法接受业务，因为不知水有多深。

于是出现怪现象：熟悉产品的“老人”忙的要死，加班加点干活；不熟悉产品的新人一帮忙就出乱，跟着加班加点；整个项目组热火朝天，加班加点，产品却依旧经常出故障，新功能迟迟无法上线。

旧系统拆分思路或原则

纵向拆分

将一个大应用拆分为多个小应用，如果新增业务较为独立，那么就直接将其设计部署为一个独立的应用系统。

横向拆分

将复用的业务拆分出来，独立部署为微服务，新增业务只需要调用这些微服务即可快速搭建一个应用系统。



微服务框架需求

1、失效转移（FailOver）

对于大型网站的微服务而言，即使是很少访问的简单服务，也需要集群部署，同时微服务框架还需要支持服务提供者的失效转移机制，以实现服务高可用。

2、负载均衡

对于集群部署的服务提供者，服务请求者可以使用加权轮询等手段访问，使服务提供者集群实现负载均衡。

3、高效的远程通信

对于大型网站，核心服务每天的调用次数会达到数以亿计，如果没有高效的远程通信手段，服务调用可能会成为整个系统性能的瓶颈。

4、对应用最少侵入

网站技术是为业务服务的，是否使用微服务需要根据业务发展规划，微服务也需要渐进式的演化，甚至会出现反复，即使用了微服务后又退回到集中式部署，微服务框架需要支持这种渐进式演化和反复。当然服务模块本身需要支持可集中式部署，也可分部署式部署。

5、版本管理

为了应对快速变化的需求，服务版本升级不可避免，如果仅仅是服务实现升级，那么这种升级对服务请求者而言是透明的，无需关注。但是如果服务的访问接口发生变化，就需要服务请求者和服务提供者同时升级才不会导致服务调用失败。企业应用系统可以申请停机维护，同时升级接口，而网站服务不可能中断，需要服务提供者先升级接口，并同时提供历史版本的服务供请求者调用，当请求者访问接口升级后才可以关闭历史版本服务。

最重要的是需求

Needs---> Values---> Principles--->Practices--->Tools