改造微服务的三个时机

在业务发展初期，团队人员不多，对微服务周边技术和基础设施的积累不够，贸然采取微服务架构，不仅无法带来预期的收益，还可能严重阻碍业务的快速迭代，严重时甚至可能变成一个灾难。

正常的做法是微服务改造之前，平常多进行一些微服务架构相关的技术储备，当单体服务的痛点达到一定程度，已经影响业务的正常迭代效率，才需要考虑微服务改造。

架构和技术都是为了业务服务的，因为评估微服务拆分时机，也需要从业务角度出发，而不是从技术角度进行评估。如果当前架构出现如下影响业务快速发展的场景时，可以考虑进行微服务改造。

1、频繁出现因为需求排队上线而延期

单个服务下，为了保证线上服务的稳定性，同时更好地监控上线特性的业务效果，不少研发团队都会制定相应的制度，需要上线的人提前提出申请，串行排队上线，如果经常出现因为排队等待而影响到业务的快速迭代，就需要考虑进行微服务拆分了，微服务拆分后，大家可以独享服务的上线窗口，加快并行开发的效率。

2、频繁出现代码提交冲突

单体服务下，多人同时在修改同一服务的代码，随着业务越来越复杂，团队的人越来越多，大家平常都在自己的分支上进行开发，分支代码合入主线时，很容易出现 merge 冲突的现象，或者解决 merge 冲突时出现代码合入错误。这时就需要考虑是否可以通过微服务拆分提高并行开发的效率，同时减少出错的概率。

3、频繁出现一个简单功能特性需要同时修改众多文件

服务代码量太庞大，并且代码结构组织不好，各种时期的历史代码，以及一些临时添加的代码遍布各处，随着业务的长期迭代，业务逻辑耦合很深，相似的判断逻辑分散到项目的各个角落，很少有人能够掌控全部逻辑。由于不了解代码的全貌，每次修改都小心翼翼，一不小心就很容易出错。这种情况下可以考虑进行微服务改造了，不然不仅会影响业务的迭代效率，同时也给整个系统的稳定性带来诸多隐患。

微服务的一大收益是解决业务高并发时带来的问题。高并发场景下，随着业务的快速发展，流量变化很快，对业务的容量评估和快速扩容提出了很高的要求，采用微服务架构拆分业务，不同的业务场景可以独自进行容量评估和扩容，比较灵活，同时可以大大节约成本。对于快速成长的业务，业务迭代效率永远是第一位的，其次才是业务稳定性，成本一般在业务发展到一定阶段，业务成熟并且模式比较固定的时候才会提到一定的高度，成本问题一般情况下不足以成为微服务拆分的一个充分条件。