微服务要凉了？
这里是Z哥的个人公众号
每周五11：45 按时送达
当然了，也会时不时加个餐～
我的第「147」篇原创敬上
大家好，我是Z哥。
如果你是做技术的话，不知道是否有注意到，从19年下半年开始，一些技术媒体开始报道一些公司在“去微服务”（最早应该是InfoQ在2019年8月23日发的一篇）。
近期这类信息被报道的频繁度进一步增加。 这不，最近陆续又有一些国外公司宣布退出微服务架构的迭代路线，逐渐将一些小粒度的服务进行合并成一个更大粒度的服务，甚至还发明了一个新的名词——「 宏服务（macroservices） 」。其中不乏像Uber这样的体量的大公司。
当然了，可能你会觉得服务的合并就像员工的“合并”一样，Uber这不是正在节约成本裁员么。服务合并也好比是“裁员”，当然对降低成本有好处。
理是这么个理，但是这恰恰也说明了我们需要重新审视一下微服务的价值，到底对系统是不是真的适用？还是之前钱太多，多招点人、多烧掉点钱？
对于微服务本身的立场，我在之前的《 istio回归「单体应用」对我们的启发 》已经聊过了，这里就不多说了。这次我主要想通过最新想到的一种方式来帮你判断当下的服务化拆分是否合理。
首先，你可以问自己两个问题先。这两个问题也代表了两个不同的维度，后面会将这两个维度组合起来看。
问题1：当前系统拆分的服务颗粒度是小、大还是中等？
为了避免纠结到底是小还是大，所以多放了一个中等的选项。毕竟「中等」是中国文化博大精深的「中庸思想」的体现，还是很符合我们国情的。
那么具体怎么判断呢？我的建议是，你分析一下当前系统中的所有功能操作，如果大部分操作都只经过三个（含）以下的服务即可完成，颗粒度算大。六个（含）以下算中等，九个（含）以上算小）
问题2：每个月产生的bug中有多少比例是技术性的问题导致的。比如，所依赖的后端服务不稳定导致的bug这种就算。代码逻辑写错了、代码写的不严谨这类不管是不是微服务都会发生的情况就不算。
最终，如果技术原因导致的bug占总数小于等于10%，那么还不错，大于10%小于等于20%算中等，大于20%算严重。大家应该都明白，技术性问题的占比越大，越意味着技术不但没有起到支撑业务、推动业务的作用，反而在帮倒忙。
然后，我们将这两个维度组合起来形成这样的一个象限图。
你可以对照一下，如果当前系统处于绿色区间，那么说明你们团队目前可以比较好的hold住当前系统，可以保持不变。如果当前的系统处于黄色的区间，那么得小心了，随着规模的继续发展或者时间的推移会有大概率进入红色的区间。一旦进入红色区间，其实微服务起到的反而是拖累作用了，不管原因是什么。
可能你会有2个疑问，为什么右下角空了一块出来，以及为什么颗粒度小的情况下没有黄色。
我来一个一个解答。
首先，右下角空出来的那块意味着，如果你的系统颗粒度还是比较大的，但是技术性的bug却很多。只能说项目本身质量太差了，需补补底子，这与个微不微服务已经关系不大了。提升一下运维能力、架构设计能力等等，
其次，为什么「10%～20%」+「颗粒度小」是绿色。我自己做架构设计相关的工作有4、5年，作为过来人的经验，如果一个操作背后依赖9个以上的服务，其实项目的稳定性是非常难保证的。要么索性就失控了，每天要忙着救火；要么就是整个团队的平均水平不错，没什么明显的短板而且人员数量也比较充足。
因为每多一个服务，复杂度不是累加的，是指数级的增加。所以在这个层次，技术性的bug有所提高是正常的。但也正因为如此，一旦bug的数量超过某个阈值，系统的稳定性会快速走低，会隔三差五的出问题。
当然，以上的观点与我所参与的项目、团队有比较大的相关性。所以具体的数值可能比较主观，但是思路上还是值得你参考的。
好了，总结一下。
这篇呢，Z哥和你分享了我对系统微服务拆分的是否合理的一个新的观点，通过两个维度来判断， 颗粒度大小和技术性bug的占比 。通过这两个维度所组合而成的不同情况，可以判断当下的微服务做的如何。
希望对你有所启发。
技术再好，切勿贪杯。如果宏服务的风刮起来，不知道还会有多少企业去追呢？
推荐阅读：
-
真的是计划赶不上变化吗？
-
人在职场，表达似水
原创不易，如果你觉得这篇文章还不错，就「 在看 」或者「 分享 」一下吧。鼓励我的创作 ：）
如果你有关于软件架构、分布式系统、产品、运营的困惑
可以试试点击「 阅读原文 」
正文到此结束
热门推荐
相关文章
近期评论
-
文章和留言都翻到11页了 没有OOM
-
-
朋友，翻页到11页，及以后，会出现OOM，无法访问
-
-
搞个gitee的项目
-
-
版本号是多少，你可以下载哪个代码仓库，jdk选1.8 直接跑就行
-
-
-
Loading...
![[HBLOG]公众号](https://www.liuhaihua.cn/img/qrcode_gzh.jpg)
