写点什么

改造微服务的时机

  • 2022 年 10 月 06 日
    四川
  • 本文字数:974 字

    阅读完需:约 3 分钟

改造微服务的时机

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


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


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

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

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

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

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

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

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


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

发布于: 刚刚阅读数: 5
用户头像

InfoQ签约作者 2018.11.30 加入

热爱生活,收藏美好,专注技术,持续成长

评论

发布
暂无评论
改造微服务的时机_微服务_穿过生命散发芬芳_InfoQ写作社区