购买
下载掌阅APP,畅读海量书库
立即打开
畅读海量书库
扫码下载掌阅APP

1.3 微服务化的具体时机

微服务拆分确实会带来很多实实在在的收益,但同时在开发、测试、运维等多个方面也带来了很多挑战。特别是在业务发展初期,团队人员不多,对微服务周边技术和基础设施的积累不够,贸然采取微服务架构,不仅无法带来预期的收益,还可能严重阻碍业务的快速迭代,严重时甚至可能变成一个灾难。特别是互联网领域,业务迭代效率是第一位的,单个服务开发、测试和部署都相对简单,遇到的技术难度相对较少,如果引入微服务架构,面对的技术问题成倍增加,在技术上就需要进行大的投入,这对于追求业务快速迭代的中小团队来说得不偿失的。正常的做法是微服务改造之前,平常多进行一些微服务架构相关的技术储备,当单体服务的痛点达到一定程度,已经影响业务的正常迭代效率,才需要考虑微服务改造。

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

(1)频繁出现因为需求排队上线而延期的现象

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

(2)频繁出现代码提交冲突的现象

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

(3)频繁出现一个简单功能特性需要同时修改众多文件的场景

之前团队一个真实的例子,上线一个简单的计价需求,修改文件超过50个,结果实际上线的时候发现还有2处修改遗漏。根本原因是服务代码量太庞大,并且代码结构组织不好,各种时期的历史代码,以及一些临时添加的代码遍布各处,随着业务的长期迭代,业务逻辑耦合很深,相似的判断逻辑分散到项目的各个角落,很少有人能够掌控全部逻辑。由于不了解代码的全貌,每次修改都小心翼翼,一不小心就很容易出错。这种情况下可以考虑进行微服务改造了,不然不仅会影响业务的迭代效率,同时也给整个系统的稳定性带来诸多隐患。

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

点击中间区域
呼出菜单
上一章
目录
下一章
×