下载掌阅APP，畅读海量书库
立即打开
微服务拆分确实会带来很多实实在在的收益，但同时在开发、测试、运维等多个方面也带来了很多挑战。特别是在业务发展初期，团队人员不多，对微服务周边技术和基础设施的积累不够，贸然采取微服务架构，不仅无法带来预期的收益，还可能严重阻碍业务的快速迭代，严重时甚至可能变成一个灾难。特别是互联网领域，业务迭代效率是第一位的，单个服务开发、测试和部署都相对简单，遇到的技术难度相对较少，如果引入微服务架构，面对的技术问题成倍增加，在技术上就需要进行大的投入，这对于追求业务快速迭代的中小团队来说得不偿失的。正常的做法是微服务改造之前，平常多进行一些微服务架构相关的技术储备，当单体服务的痛点达到一定程度，已经影响业务的正常迭代效率，才需要考虑微服务改造。
架构和技术都是为了业务服务的，因为评估微服务拆分时机，也需要从业务角度出发，而不是从技术角度进行评估。如果当前架构出现如下影响业务快速发展的场景时，可以考虑进行微服务改造。
单个服务下，为了保证线上服务的稳定性，同时更好地监控上线特性的业务效果，不少研发团队都会制定相应的制度，需要上线的人提前提出申请，串行排队上线，如果经常出现因为排队等待而影响到业务的快速迭代，就需要考虑进行微服务拆分了，微服务拆分后，大家可以独享服务的上线窗口，加快并行开发的效率。
单体服务下，多人同时在修改同一服务的代码，随着业务越来越复杂，团队的人越来越多，大家平常都在自己的分支上进行开发，分支代码合入主线时，很容易出现merge冲突的现象，或者解决merge冲突时出现代码合入错误。这时就需要考虑是否可以通过微服务拆分提高并行开发的效率，同时减少出错的概率。
之前团队一个真实的例子，上线一个简单的计价需求，修改文件超过50个，结果实际上线的时候发现还有2处修改遗漏。根本原因是服务代码量太庞大，并且代码结构组织不好，各种时期的历史代码，以及一些临时添加的代码遍布各处，随着业务的长期迭代，业务逻辑耦合很深，相似的判断逻辑分散到项目的各个角落，很少有人能够掌控全部逻辑。由于不了解代码的全貌，每次修改都小心翼翼，一不小心就很容易出错。这种情况下可以考虑进行微服务改造了，不然不仅会影响业务的迭代效率，同时也给整个系统的稳定性带来诸多隐患。
微服务的一大收益是解决业务高并发时带来的问题。高并发场景下，随着业务的快速发展，流量变化很快，对业务的容量评估和快速扩容提出了很高的要求，采用微服务架构拆分业务，不同的业务场景可以独自进行容量评估和扩容，比较灵活，同时可以大大节约成本。因此不少同学认为业务高并发也是微服务的一个重要拆分时机，对此我有不同的看法。对于快速成长的业务，业务迭代效率永远是第一位的，其次才是业务稳定性，成本一般在业务发展到一定阶段，业务成熟并且模式比较固定的时候才会提到一定的高度，成本问题一般情况下不足以成为微服务拆分的一个充分条件。