读《微服务架构设计模式》的感悟(2)

746 阅读7分钟

书接前文,这篇会先讲一下,我理解的微服务的最大优点。

最近总听几个在to B公司工作的产研朋友说,他们的研发团队已经有了几百人,但他们研发这块还总是拖业务后腿,上线delay是家常便饭,所以一方面感觉还是缺人,在大量招人,另一方面感觉系统架构太烂太老了,迭代不动了。

这种情况,把我说得一愣一愣的,因为我这几年的观点一直是,现在的技术解决方案已经做得足够健全,信息化也做得足够好,各种云生态做得也是更加完善,技术门槛已经低得不要不要的了。

详细了解了一下,才知道,他们这些公司的研发团队,之前在业务简单,工程师人数比较少的时候,一直在用纯单体应用,或者是SOA这样较大的单体应用,系统架构就一直没有动。

等到业务复杂度上来了,工程师人数也上来的时候,就开始面临几十个人改一个服务,各种代码互相篡改,代码合并的时候,各种各样的代码冲突,怎么也合并不成功,费了好大的劲,耽误了好长时间,终于合并成功了。但麻烦的还在后面,等到QA介入测试,发现各种代码的业务逻辑相互影响,bug如同雨后春笋般的被提了过来,然后开始继续改bug来互相伤害,但是bug短时间内根本没有收敛的趋势。工程师们加班加点、不眠不休、痛苦不堪地熬着,最后,最后,终于上线了,但已经延期了很久。已然是红了樱桃,绿了芭蕉,姑娘变成了少妇,儿子都有一米高。

事后技术负责人带着团队进行复盘的时候,大家达成的结论是——缺人。

其实真正的原因并不是缺人,而是,工程师数量上来了,但远没有达到1+1=2的效果。 这种场景有点像10个人挤在一个几平米的家庭厨房里面一起洗菜做饭一样,它的效率未必比配合娴熟的两个人快多少。

因此,真正的问题原因是,没有在一个适当的时机,把一个庞大的单体应用,演进为微服务架构。那么我认为,相比于单体应用,微服务的最大优点是——使工程师团队的工作情况从“并发”变成了“并行”,从而保证团队研发效率尽可能小的发生损耗,让研发团队具备横向扩容去缩短研发周期的能力。

平均每研发人员单位时间释放出的产品能力,即“研发效率”。那么按照这种定义,工程师效率最高的时候,应该是一个人开发一个单体应用的时候。不需要输出任何文档进行接口约定,不需要跟其他工程师进行思路和技术方案的对齐,没有业务代码的相互影响,也不需要解决代码合并的冲突,没有跨服务进行联调和问题排查,测试环境的搭建部署变得very easy,上线过程也是分分钟的事情。这种情况下,虽然人效高了,但研发周期太长了,上线一个大的功能,以月为维度进行排期,是任何唯快不破的互联网公司都接受不了的。而我们给研发团队加人,是希望尽量缩短研发周期,进行架构上的微服务拆分,则是为了让团队的研发效率尽量小的发生损耗。毕竟工程师还是很贵的,如果人海战术的ROI不高,导致产研成本居高不下,是绝大多数公司都承受不住的。


书中所列,微服务的其他优点:

微服务架构可以实现团队的自治

微服务本身就是一种去中心化的理念,而一旦去中心化了,那就必须实现区域自治。其中包括:技术语言自治、技术选型自治、数据结构自治、上线部署自治等,这样,工程师可以用自己最熟悉和擅长的方式进行工作。

服务可以独立扩展

书中提出了一个扩展立方体的概念,即三维可扩展模型:

图片

X轴扩展:无脑扩容服务器

Y轴扩展:按照功能进行服务拆分

Z轴扩展:在无脑扩容服务器的基础上,再通过路由字段(如:userId)决定走到哪个实例上\

此外,无论是哪种维度的扩展,微服务因为足够小,足够内聚,我们都可以去有针对性地选择适合的硬件去解决系统中的瓶颈。如:计算密集型的服务,可以增加CPU的核数提升并行能力;IO密集型的服务,我们可以把微服务对应的存储提升硬件配置;如果服务比较吃内存,可以选择高内存配置的服务器。

每个服务都相对较小并容易维护

微服务的代码量少,工程师能够更关注和聚焦自己所负责的业务功能需求,这样更容易理解和维护。但这同样是有硬币的两面性的,比如:作为上游服务,下游服务的业务逻辑和存储数据结构,对我们是透明的;作为下游服务,上游服务在什么业务场景下调用了我们,又是如何和其他数据进行聚合展示的,对我们一样是透明的;还有就是,我们的整体系统,还有多少个跟我们一样的微服务,他们的运转机制是什么样的,我们也知道得不多。就跟拼图游戏一样,切得越碎,越难拼出整幅图。那么一旦我们的需求是需要对周边系统有一些了解才能做完整技术方案和实现,我们想了解系统整体的完整运转机制和业务逻辑,就会变得更加困难。


微服务能够提升性能吗?

同事之间对这个问题,似乎争论颇多,且最终谁也没能说服谁。

我的观点是:具体case具体分析,但从通例的角度来说,微服务不能提升性能,反而性能会略有降低。

有人说,微服务拆分的时候,按照微服务的规范,把服务所属的数据库也各自拆分了,然后性能瓶颈就没有了,接口的平均响应时间也上去了。

但我觉得,这件事情的本质是,你的存储扩容了导致了性能提升,有本事你把这些拆分的库表还放在一个物理机上试试。

我们换个角度来看微服务,其实就是从以前的调用一个服务变成了多个服务来完成业务结果,从以前的本地调用变成了远程调用而已。


微服务能够提升系统可用性吗?

毫无疑问,微服务可以具备更好的容错性,但是,微服务能够提升可用性吗?

这是个非常烧脑的问题,因为维度太多,且标准也不太统一。在下一篇,我试试能否把这个问题给大家解释清楚,顺便聊下书中所说的,微服务的缺点。

未央。