微效劳“很香”，它有许多优势，比如更快的开发、更好的可扩展性、更小的独立团队等等。但是，很多团队却在微效劳上步履维艰，没有很好应用其优势。缘由究竟是什么？这是本文作者试图回答的。

过去几年，我对推进数字化转型的多家产品团队停止了架构审查。我发现：大少数团队都是遵照微效劳架构来构建产品。更快的开发、更好的可扩展性、更小的独立团队、独立部署和运用正确的技术来完成任务等等，这些优势让他们有充足的理由采用微效劳架构。

但是，我常常发现：很多团队在微效劳上步履维艰。他们并未充沛应用微效劳的优势。为什么许多团队在微效劳之路上“步履维艰”？这是我试图回答的。

假设你是微效劳新手，我引荐你阅读 Martin Fowler 关于微效劳的文章。

https://martinfowler.com/articles/microservices.html

这篇文章阐释了何为微效劳架构：

微效劳架构的作风是一种将单个运用顺序开发成一套小型效劳的办法，每个运用顺序都在本人的进程中运转，并与轻量级机制（通常是 HTTP 资源 API）停止通讯。这些效劳是围绕业务功用而构建的，并且可以由完全自动化的部署机制来独立部署。这些效劳只要最低限制的集中管理，可以用不同的编程言语编写，并运用不同的数据存储技术。

1. 管理层低估开发微效劳的复杂性

我曾与许多十分看好微效劳的客户一同协作过。对他们来说，微效劳就是处置他们一切成绩的“灵丹妙药”。

当讨论逐渐深化，我发现：大少数团队及其管理层都低估了微效劳开发的复杂性。

要开发微效劳，开发人员需求一个高效的本地环境设置。

随着系统中效劳数量末尾添加，在一台机器上运转运用顺序的子集变得越来越困难。特别是当你运用消耗较多内存的言语（如 Java）构建运用顺序时，更是如此。

下面是与本地开发设置相关的要点：

1.本地开发的第一个重要方面是要有一个好的开发机器。

我发现，大少数组织想要运用一切最新的、最先进的技术，但却不想交流掉蹩脚的 Windows 开发机器。开发人员受限于他们的开发机器。我曾见过开发人员运用 VDI 映像或配置交叉的机器来构建基于微效劳的系统。这不只降低了他们的任务效率，而且让他们无法完全投入任务。运用蹩脚的开发机器带来的反作用就是，开发人员无法失掉快速反应。假设知道了必须等数分钟才能运转集成测试套件，那么你就不会编写更多的集成测试套件，以免让你更痛苦。蹩脚的开发机器将会招致蹩脚的开发实际。

2.一旦你为开发人员装备了适宜的开发机器，那么下一步就是确保一切效劳都运用构建工具。

你应该能在一台新机器上构建整个运用顺序，而不需求停止太多配置。依据我在微效劳方面的阅历，运用能构建整个运用顺序的根构建脚本也会有所协助。

3.下一个要点是要让开发人员能轻松地在他们的系统上运转运用顺序的各个部分。在配置了一切端口和卷的状况下，你应该运用多个 docker-compose 文件来提供不同效劳。

4.接上去，假设你运用的是相似于 Kubernetes 的容器编排工具，那么你应该投资相似于 Telepresence 这样的工具，以便轻松调试 Kubernetes 集群中的运用顺序。

假设组织对微效劳开发的复杂性缺乏了解，那么团队速度将会随着时间的推移而下降。

2. 没有将库和工具更新到最新版

我发现一个新的平台曾经成为一种遗产。团队没有确保依赖项是最新的版本，或许将像数据库这样的工具晋级到最新版本。

因此，两年前末尾的现代化改造，如今曾经背负长达数月的技术债。

几年前，许多团队末尾将 Spring Cloud Netflix OSS 项目用于微效劳。他们运用像 Kubernetes 这样的容器编排工具，但是由于是从 Netflix OSS 末尾的，所以他们没有运用 Kubernetes 提供的一切功用。当 Kubernetes 内置了效劳发现时，他们依然运用 Eureka 作为效劳发现。

此外，经过相似 Istio 这样的效劳网格，你可以摆脱 Netflix OSS 提供的大部分效劳。这有助于降低复杂性，并将许多“横向关注点”（cross cutting concerns）转移到平台上。

需求记住的另一点是，要使一切效劳的依赖项版本保持同步。

最近，我在协助一个客户，它运用 Spring Boot 来构建微效劳。在过去两年，他们曾经构建了 20 多个 Spring Boot 效劳。在其环境中，他们运用的 Spring Boot 版本从 1.5 到 2.1 不等。这意味着一旦有人设置他们的机器时，他们必须下载多个版本的 Spring Boot。

此外，他们还缺乏自 1.5 版本以来在 Spring Boot 中所做的许多改良。

建议是，组织应该在其积压中为这些晋级创立技术债务项。这些技术债务项应作为架构委员会会议的一部分加以讨论，并活期予以处置。在我的上一个项目中，我们每三个月设置为期一周的 sprint，将一切依赖项更新到最新版本。

3. 应用共享效劳促进本地开发

由于本地开发状况不佳，大少数团队末尾依赖于共享环境来取得关键效劳。开发人员机器中的第一件事就是数据库。大少数年轻的开发人员并没无看法到基于共享数据库的开发是“罪恶的”。

下面，是我在共享数据库中看到的主要成绩：

团队成员必须树立一个任务的社会契约，以避免最后写入者胜出（Last write wins，LWW）成绩。一个开发人员可以删除其他开发人员为他们任务编写的数据。这种任务方式既痛苦又容易失败，迟早会影响整个团队。

开发人员惧怕实验，由于他们的任务会影响其他团队成员。我们都知道，更好的学习办法是实验和快速反应。有了共享数据库，就可以停止实验。我们需求停止实验，以提出数据库形式，并执行义务，如功用调优之类。

另一个反作用就是，很难独自测试更改。你的集成测试将变得不牢靠，从而进一步降低开发速度。

共享数据库必须像宠物一样看待，由于你不希望它出现不分歧和不可预测的形状。你能够会遇到这样一种场景，开发人员希望在表是空的时分测试边缘状况，但其他开发人员需求一个表来记载。

只要共享数据库拥有系统任务所需的一切数据。随着时间推移，团队成员失掉了更改的可追溯性，因此没有人知道，他们该如何在他们的机器上复制相反的设置。独一的办法是获取残缺的数据库转储并运用它。

假设未衔接到网络，就很难展开任务。这种状况通常发作在你通勤时间过长或乘飞机的时分。

数据库只是共享效劳的一个示例，但它也可以是音讯队列、集中缓存（如 Redis）或任何其他效劳可以发作改动的效劳。

(责任编辑：admin)