微服务架构核心(二)- 微服务的利与弊

不知道你有没有这样的感受,新系统在前期调研架构的时候,大家都希望优先选择微服务架构,好像一个系统不是微服务架构就OUT了一样。

但是真正的架构设计,并不是哪个架构流行就选哪个,那是要遵循简单、合适、扩展的原则。

所以在选择微服务架构之前,我们应该仔细衡量它的利与弊,分析微服务架构究竟能为系统带来什么优势,同时又会新增哪些挑战。

强模块化边界

模块化一直是软件设计中的一个重要原则,有了模块化,我们才可以做到高内聚、低耦合。

实现模块化的方式很多,可以是一个类,也可以是一个独立的组件。

微服务架构则将模块化上升到一个更高的层次,以服务的形式的实现。

服务与服务之间采用远程调用的方式进行交互,这样它们之间没有干扰和冲突,边界非常清晰。

可独立部署

由于服务之间是互相独立的,因此一个服务的变更并需不要其它服务配合,变更完成之后就可以单独测试、发布。

例如我们需要给用户信息加字段,只需要修改用户服务,其它的服务并无感知。而单体架构就要麻烦很多,即使是变更一个小功能点,也需要发布整个系统。

基于这个特性,微服务架构功能迭代的速度币单体架构更快、更灵活。

技术多样性

由于微服务不是集中式管理,所以不同服务的技术团队,可以基于自身技术特点或者服务的业务特性选择完全不同的技术栈。

比如有的团队更熟悉Java,那么他们可以选择Java做为开发语言,另一个团队更熟悉Python,则可以用Python来开发。

再比如数据存储量大的服务使用HBase存储数据,而数据量小的服务使用MySQL。

丰富的技术多样性给了技术团队更多的选择,可以将当前服务的功能发挥到最大化。

研发复杂性

微服务的特点是服务众多,并且实现技术多样,这样带来的挑战就是增加了研发人员的理解和学习成本。

一个单体架构系统,技术栈是统一的,而且系统架构简单,就只有单体应用的几个节点,研发人员理解起来非常容易。

但是一个微服务架构的系统,服务模块可能有几十个,模块之间又存在错综复杂的调用关系,能弄清楚服务之间的关系已经很不容易了,如果是一个人维护多个不同技术栈的服务,那么技术学习的成本也很高。

最终一致性

微服务架构是一种分布式系统架构,对于任何分布式系统而言,数据的最终一致性都是一个绕不过去的坎。

要么在最终一致性上做妥协,由强一致性变为弱一致性。要么使用复杂的设计实现最终一致性,但是开发的成本也会因此提升。

运维复杂性

微服务对于运维在部署、监控、扩展、管理等方面都提出了更高的挑战。

例如服务增多以后,不可能还是手工一个个部署,必须要借助自动化工具批量操作。

追查问题的难度也变高了,一个问题可能涉及多个服务的层层调用,如果没有一个好的链路追踪以及日志查看工具,即使是简单的问题,追查起来也会非常耗时耗力。

总结

最后用一张表格来总结微服务的利与弊。

强模块化边界 研发复杂性
可独立部署 最终一致性
技术多样性 运维复杂性
上篇微服务架构核心(三)- 微服务技术架构体系
下篇微服务架构核心(一)- 什么是微服务