10分钟入门微服务架构

微服务是一种用于构建应用的架构方案。微服务架构有别于更为传统的单体式方案，可将应用拆分成多个核心功能。每个功能都被称为一项服务，可以单独构建和部署，这意味着各项服务在工作（和出现故障）时不会相互影响。

背景

第一次听说“微服务（Microservices）”这个词汇是在2016年与好友聚餐时听他说起的，当时听他描述微服务如何火爆，Spring Cloud 如何优秀，听他语气似乎对微服务及其解决方案 Spring Cloud 颇为推崇。心中颇感好奇，于是便开始去了解和学习。时间转眼已经过去3年多，这3年中对微服务也算是有了一定的了解，在工作中也实际用了起来。今天把这3年来我对微服务的一些粗浅的理解写成一篇文章，希望能帮助到阅读到这篇文章的朋友。

一、单体架构的不足

在公司初创时期，为了能够快速开发、快速拓展业务，我们一般会采用单体架构（Monolith）。这种架构实现简单、易于部署、易于维护，很适合初创团队。随着公司业务规模的逐步扩张，技术团队也逐渐趋于庞大，单体架构的劣势就逐渐显露出来。
首先，从开发流程来看主要有以下表现：

1. Git仓库过于臃肿，代码合并遭遇更多冲突，分支混乱，难以管理
2. Git仓库臃肿进而导致构建速度变慢，失败频率增加，上线变得困难
3. 臃肿的代码越来越难以理解，维护成本升高，从而需要更多的人力成本
4. 代码之间耦合严重，经常遭遇“拔出萝卜带出泥”的窘境，简直让人抓狂
5. 技术栈单一，阻碍技术创新，技术债务堆积
6. 复杂的功能需要消耗更多的资源，导致服务器压力增大，启动速度变慢
7. 由于某些原因引入的一些bug，可能导致整个系统崩溃，系统稳定性无法满足要求
8. 随着业务增长，服务访问量增加，需要不断增加服务实例数以满足业务增长的需求，无法实现按需扩展
9. 各功能模块之间随意调用，数据可以任意访问，安全性受到很大挑战

从开发流程看单体架构的不足

从架构角度来看主要有以下表现：

1. 功能模块之间耦合严重，导致代码越来越难以维护和扩展，进而使业务拓展变得困难
2. 团队边界模糊，职责不清晰，一旦出现问题，经常出现互相“甩锅”的情况
3. 随着业务的增长，数据库压力与日俱增，数据安全性变差，对数据库的相似操作可能出现在很多服务中

从架构角度看单体架构的不足

这些问题，你是不是很多都曾亲历过或者正在经历呢？是不是想想都感觉头大呢？微服务的出现给我们带来了曙光！

二、微服务架构是什么？

我们先来简单了解一下微服务架构的历史（摘抄自知乎）：

• 微服务这个概念最早是在2011年5月威尼斯的一个软件架构会议上讨论并提出的，用于描述一些作为通用架构风格的设计原则。
• 2012年3月在波克兰克拉科夫举行的33rd Degree Conference大会上，Thoughtworks首席咨询师James Lewis做了题为《Microservices - Java, the Unix Way》的演讲，这次演讲里James讨论了微服务的一些原则，例如单一服务职责、康威定律、自动扩展、DDD等等。
• 微服务架构则是由Fred George在2012年的一次技术大会上所提出，在大会的演讲中他讲解了如何分拆服务以及如何利用MQ来进行服务间的解耦，这就是最早的微服务架构雏形。
• 而后由Martin Fowler发扬光大并且在2014年发布了一篇著名的微服务文章（下文附有文章链接），这篇文章深入全面的讲解了什么是微服务架构。
• 随后，微服务架构逐渐成为一种非常流行的架构模式，一大批的技术框架和文章涌现出来，越来越多的公司借鉴和使用微服务架构相关技术。

我们一起来膜拜一下这三位大佬：

下面是 Martin Fowler 对微服务架构的定义

微服务架构风格是将单个应用程序作为一组小型服务开发的方法，每个服务程序都在自己独立的进程中运行，并通过轻量级通信机制（通常是 HTTP 资源API）进行通信。这些服务是围绕业务功能构建的，可以通过全自动部署机制独立部署。这些服务可以用不同的编程语言编写，使用不同的数据存储技术，并尽量不用集中式方式进行管理。
——Martin Fowler
原文地址：https://www.martinfowler.cn/articles/microservices.html

上文中我们用红色字体标识除了微服务架构的几个特征。

三、微服务架构带来的好处

从字面意思理解，微服务似乎就是把一个大的单体服务拆分成了多个小服务，似乎也没什么新意。如果你这么想，说明对微服务的了解还比较浅，我这里列举了一些我认为微服务能够带来的一些向好的变化：

1. 小而灵活
这应该是我们最直观的认识，微服务将一个耦合严重、难以维护的、庞大的单体服务按照业务拆分成了几个小型服务，从而使服务直接职责和边界更清晰，更加易于维护。
以我的项目为例，之前使用单体架构，每次上线都要引入几个bug，你不知道哪一处修改就影响到了别的功能，所以不得不在上线前把所有重要的功能都测试一遍，光是上线前测试差不多都要花费半天的时间。但自从采用微服务架构之后，这种情况就很少见了，只需要测试被修改或新增的功能即可，bug数量也明显减少。

小而灵活带来的另一个好处就是：对可替代性的优化。有时候我们会被交接一些之前与自己完全无关的服务，而这些服务中有些部分设计不合理，经常出问题。我们想要重新设计，却因为各种功能直接严重耦合，而经常陷入“牵一发而动全身”、“拔出萝卜带出泥”的窘境。如果这些服务采用了微服务架构，每个服务重写的成本比较低，我们就可以果断对其进行重新设计和开发，从而实现快速替代。

小而灵活

2.技术异构性
针对不同的应用场景选用合适的实现技术是架构设计中一个很重要的工作。就拿开发语言来举例，PHP的优点是使用方便、易于上手、开发速度快，比较适合做管理网站开发；Java功能强大、安全性高，更适合于后端服务开发；而Python因其灵活性高、第三方类库完善，在机器学习、网络爬虫、自动化运维等领域都有比较广泛的应用。

采用微服务架构，我们就可以在不同的服务中使用最适合该服务的技术，从而创造更大的价值。而单体架构在这方面就明显不够灵活。

选用合适的开发语言

另外，我们在系统中的不同部分也可以使用不同的数据存储技术。

选用合适的数据库

还有很重要的一点，如果我们采用了微服务架构，每个服务的开发成本都比较小，我们就可以在按照需求在少部分服务中采用新技术，更小成本地试错，更快地实现技术升级，避免技术债务越级越厚。

3.故障隔离
如果很多人都开发和维护同一个单体服务的话，我们无法保证这些人的技术水平都是很高的，所做的技术方案都是合理的，所写的代码都是严谨的。可能某个人的粗心大意，写了一段不合理的代码，导致了一次“内存泄漏”就使所有功能务陷于崩溃。

而采用微服务架构，就可以显著降低这个风险。即便出现这样的情况，也只是其中一个服务受到影响，而一般不会使所有功能陷于瘫痪。

故障隔离

4.按需伸缩
“节省成本就是创造价值”。
庞大的单体服务只能作为一个整体进行扩展。即使系统中只有一小部分存在性能问题，也需要对整个服务进行扩展。如果使用较小的多个服务，则可以只对需要扩展的服务进行扩展，这样就可以把那些不需要扩展的服务运行在更小的、性能稍差的硬件上。
以下图电商网站中常见的三个功能为例，如果我们采用微服务架构，将三个功能拆分成三个服务，按照各自业务增长量设置服务实例数，就可以实现按需伸缩，从而实现更高的资源使用率，进而节省成本。

按需伸缩

5.简化部署
在有几百万行的单块应用程序中（据说某知名数据库产品的代码库中有2500w行C代码，经常为员工所诟病），即使只修改了一行代码，也需要重新部署整个应用程序才能够发布该变更。这种部署的影响很大、风险很高，因此相关干系人不敢轻易做程序部署。于是在实际操作中，部署的频率就会变得很低。这意味着在两次发布之间我们对软件做了很多功能增强，但直到最后一刻才把这些大量的变更一次性发布到生产环境。这时，另外一个问题就显现出来：两次发布之间的差异越大，出错的可能性就越大！

在微服务架构中，各个服务的部署都是独立的，这样就可以更快地对特定部分的代码进行部署。如果真出现问题，也只会影响到一个服务，并且容易回滚。并且，我们也可以借助Jenkins、GitHub等工具实现自动化的持续集成（CI）和持续发布（CD），从而简化发布流程，提升发布效率。

CI/CD

6.与组织架构相匹配
我们可以按照业务对服务和团队进行拆分，设计出两者互相匹配的组织架构，避免出现过大的代码库，从而获得理想的团队大小和生产力，也可以避免异地团队的出现，降低团队之间的沟通成本。

与组织架构相匹配

7.灵活的组合
我们可以实现已有功能的重复利用，只需要进行简单的调用就能组合成新的功能。比如，我们为浏览器端实现了相应的后端接口，当我们需要在微信小程序或App端使用这些功能时，就可以直接复用原有的接口，只需要开发前端页面即可。

image.png

8.安全
单体架构一般是采用方法调用的形式来实现功能的复用，而方法调用经常是无法保证数据的安全性的（比如我们不想把用户密码暴露给公司的所有员工）。而在微服务架构中，由于各服务之间通过接口互相调用，我们可以采用HTTPS或其它接口鉴权机制来提升数据的安全性。

身份认证和接口鉴权

四、小结

今天和大家一起学习了微服务架构的定义，以及微服务架构相对于单体架构的一些优势。但这并不是说微服务架构就是一个完美无缺的解决方案，在各方面都能碾压单体架构，相反，单体架构也有其使用场景及存在的合理性。
就像硬币存在正反两面，今天之所以我们看到了微服务这么多优势而没看到其不足，是因为我只展示给了大家硬币的正面而已。微服务架构并不是银弹，它所带来的技术复杂性和实现成本也是不容忽视的，这些问题我们会在下一节与大家一起探讨。

五、推荐阅读

1. ThoughtWorks洞见——微服务
2. 云原生架构下微服务最佳实践-如何拆分微服务架构
3. 寻根溯源：微服务模式发展简史
4. Microservices—a definition of this new architectural term
5. Martin Fowler谈微服务的优缺点
6. SOA和微服务架构的区别
7. 微服务架构的优势与不足
8. 关于分布式事务、两阶段提交协议、三阶提交协议

最后，再向大家推荐一本书《微服务架构设计》，该书不但详细地阐述了微服务的基本概念，而且还深入探究了如何对自治服务进行建模、集成、测试、部署和监控。是目前我所接触的讲述微服务理论最优秀的一本书，希望能给大家带来一些收获。

微服务设计