Why “微服务架构”

Posted 2021-04-14 罗说数字化

微服务架构有哪些优势劣势？

要谈优势，就一定要有对比，我们可以尝试着从两个维度来对比。

一、微服务架构与单体架构的对比

序号	对比点	微服务架构	单体架构	结论
1	上手难度	API 接口调用	数据库共享或本地程序调用	单体架构胜
2.1	开发效率（简单项目）	早期设计和沟通的工作量加大，随着项目规模和时间的推移，效率变化不大	早期工作量小，随着项目规模和时间的推移，效率大幅度下降	单体架构胜
2.2	开发效率（复杂项目）	早期设计和沟通的工作量加大，随着项目规模和时间的推移，效率变化不大	早期工作量小，随着项目规模和时间的推移，效率大幅度下降	微服务架构胜
3	系统设计（高内聚低耦合）	每个业务单独包装成一个微服务，数据和代码都从物理上隔离开来，实现高内聚低耦合相对容易	以包的形式对代码进行模块划分，控制得当即可实现高内聚。但最终都是在数据层面将整个系统耦合在一起	微服务架构胜
4	系统设计（扩展性）	独立开发新模块，通过 API 与现有模块交互	在现有系统上修改，与现存业务逻辑高度耦合	微服务架构胜
5	需求变更响应速度	各个微服务组件独立变更，容易实施敏捷开发方法	需要了解整个系统才可以正确修改，容易导致不相关模块的意外失败	微服务架构胜
6	系统升级效率	各个微服务组件独立升级，上手和开发效率高，影响面小	需要了解整个系统才可以正确修改，容易导致不相关模块的意外失败	微服务架构胜
7	运维效率	大系统被拆分为多个小系统，部署和运维难度加大，但可以利用 DevOps 等方式将运维工作自动化	简单直接	单体架构胜
8	知识积累	微服务组件可以在新项目中直接复用，包括前端页面	一般以共享库的形式复用后台代码	微服务架构胜
9.1	硬件需求（简单项目）	一个系统需部署多个微服务，需要启动多个运行容器	整个系统只需要一个运行容器	单体架构胜
9.2	硬件需求（高要求项目）	按需为不同业务模块伸缩资源节点	为整个系统分配资源，导致冗余	微服务架构胜
10.1	项目成本（简单系统）	项目早期和后期，成本变化曲线平缓	项目早期成本低，后期成本大	单体架构胜
10.2	项目成本（复杂系统）	项目早期和后期，成本变化曲线平缓	项目早期成本低，后期成本大	微服务架构胜
11	非功能需求	为单独的微服务按需调优，甚至更换实现方式和程序语言	为整个系统调优，牵一发而动全身	微服务架构胜
12	职责、成就感	拥有明确的职责划分，主人翁意识和成就感加强，容易形成自组织型团队	职责不明确，容易产生扯皮行为	微服务架构胜
13	风险	大系统被拆分为小系统，风险可被控制在小系统内，但也引入了各小系统之间的交互风险	系统是一个整体，一荣俱荣，一损俱损	微服务架构胜

结论:

对于简单项目来说，单体架构 5 胜 8 败。（优势项：开发效率、上手难度、运维效率、硬件需求、项目成本；劣势项：系统设计（高内聚低耦合）、系统设计（扩展性）、需求变更响应速度、系统升级效率、知识积累、非功能需求、职责、成就感、风险）

对于复杂项目来说，单体架构 2 胜 11 败。（优势项：上手难度、运维效率；劣势项：硬件需求、项目成本、开发效率、系统设计（高内聚低耦合）、系统设计（扩展性）、需求变更响应速度、系统升级效率、知识积累、非功能需求、职责、成就感、风险；）

二、微服务与共享库的对比

注：这里以使用方自行安装微服务为场景来比较。这里的共享库指的是像 Java 中的公共 jar 依赖。

序号	对比点	微服务	共享库	结论
1	易用性	整体安装 + API 调用	共享库引用 + 本地调用	平手
2	程序耦合度	微服务为完整的业务逻辑单元，通过 API 的形式为其它模块提供服务	在使用方的源代码中引用共享库的类和方法	平手
3	版本升级	单独升级，其它模块无感知	修改源代码，升级使用方的代码版本，例如 pom.xml, build.gradle	微服务架构胜
4	Bug 修复	单独升级，自动生效  修改源代码，升级使用方的代码版本，例如 pom.xml, build.gradle	微服务架构胜
5	非功能需求	为单独的微服务优化或扩缩容；在需求更高的情况下，可以重新设计或使用不同的程序语言	为整个业务系统优化或扩缩容，共享库的程序语言必须和业务系统的程序语言相同	微服务架构胜
6	复用程度	可以复用从前端页面到后台数据库的整个业务逻辑和代码	可以复用后台代码和数据库，但程序语言需要和业务系统保持一致	微服务架构胜

总体来说，微服务架构有如下优和劣：

什么场景需要用微服务架构？

看了上面的比较，微服务架构可以说是以压倒性的优势胜过单体架构和共享库，会让人产生一种错觉，微服务架构就是软件开发中的银弹。

但是，正如大家所了解的，软件研发是一个系统工程，它没有银弹，不能够一招鲜吃遍天。正如当年的 CMMI 和敏捷方法一样，敏捷虽好，但它不一定能适用于所有的场景，它对组织环境、团队氛围、沟通方式、技术能力这些都是有一些要求的，如果用不好，反而会带来一些负面影响。

那么，我们什么时候需要采用微服务呢？从我个人的经验来看，我认为有三种场景可以考虑使用微服务。

1. 规模大（团队超过 10 人）

2. 业务复杂度高（系统超过 5 个子模块）

3. 需要长期演进（项目开发和维护周期超过半年）

企业什么时候引入微服务架构？

横轴是复杂度，纵轴是生产效率。从生产效率的角度来讲，在两条曲线的交叉点之前，单体架构是占优势的，过了交叉点之后，单体架构的生产效率将大幅度下降。

企业根据自身业务发展情况选择合适的切入时间，将有利于后续的发展。