Medium 的微服务架构

Posted 2021-04-14 Node地下铁

Microservice 架构的目标是帮助工程团队更快、更安全、更高质量地交付产品。通过解耦的服务，团队能够在对系统的其余部分影响最小的情况下，进行快速迭代。

在 Medium，我们的技术栈始于 2012 年庞大的 Node.js 应用后端。我们已经建立了几个附属服务，但我们还没有制定采用微服架构系统的战略。随着系统变得更加复杂和团队的壮大，我们在 2018年初迁移到了微服务架构。在这篇文章中，我们希望分享我们的经验，有效地做到这一点，避免微服务综合征。

微服务架构是什么？

首先，让我们花点时间来思考一下微服务架构是什么，不是什么。“微服务” 是那些超载和混乱的软件工程趋势之一。在 Medium，我们认为：

在微服务架构中，多个松散耦合的服务一起工作。每一项服务都集中在一个单一的目标上，并且相关的行为和数据具有很高的凝聚力。

此定义包括三个微服务设计原则:

1. 目的单一 —— 每个服务都应该专注于一个单一的目的，并做好它。

2. 松耦合 —— 公共服务对彼此知之甚少。更改一个服务不应要求更改其他服务。服务之间只能通过公共服务接口进行通信。

3. 高内聚 —— 每个服务都将所有相关行为和数据封装在一起。如果我们需要建立一个新功能，所有的变化都应该局限在一个单一的服务。

当我们设计微服务时，我们应该遵守这三个设计原则，这是实现微服务架构全部潜力的唯一方式。缺少其中任何一个将成为反模式。

如果没有单一的目的，每个微服务最终会做太多的事情，成长为多个“一体化”服务。我们付出了操作成本但不会得到微服务架构的全部好处。

如果没有松耦合，一个服务的变化会影响其他服务，所以我们无法快速安全地发布变化，这是微服务架构的核心优势。更重要的是，紧密耦合导致的问题可能是灾难性的，例如，数据不一致，甚至数据丢失。

如果没有高内聚，我们最终会形成一个分布式的一体化系统 —— 必须同时修改、部署一系列混乱的服务，才能实现一个单独的功能。因为多个服务复杂性和成本，有时甚至跨多个团队协作，分布式一体化系统往往比一体化的中心系统更糟糕。

同时，也很重要的一点是要认识到微服务不是什么:

1. 微服务不是一种有少量代码行或执行 “微” 任务的服务。这个误解来源于 “微服务” 这个名字。微服务架构的目标是不要有尽可能多的小服务。只要满足上述三个原则，服务就可能是复杂的、大量的。

2. 微型服务并不是一直采用新技术建立的服务。尽管微服务架构允许团队更容易测试新技术，但它不是微服务架构的首要目标。只要团队从分离的服务中获益，就可以使用完全相同的技术堆栈构建新服务。

3. 一个微服务不是一个必须从头开始构建的服务。如果您已经拥有了一个架构良好的整体应用程序，那么请避免养成从头开始构建每个新服务的习惯。可能会有机会直接从整体服务中提取逻辑。同样，以上三个原则仍然应该坚守。

为什么现在要做？

在 Medium，当我们做出大的产品或工程决策时，我们总是会问 “为什么是现在” 这个问题。“为什么？” 是一个普通的问题，但它假设我们有无限的人，时间和资源，这是一个危险的假设。当你想到 “为什么是现在？” 时，你突然有了更多的约束 —— 对当前工作的影响，机会成本，分心的开销等等。这个问题可以帮助我们更好地划分优先级。

我们现在需要采用微服务的原因是，我们一体化的 Node.js 应用在很多方面已经成为一个瓶颈。

首先，最紧迫和最重要的瓶颈是它的性能。计算量大、 I/O 量大的任务不适合 Node.js。我们一直在逐步改进一体化应用程序，但事实证明这是无效的。其较低的性能使我们无法提供更好的产品，而不会让已经非常慢的应用程序慢得多。

第二，一体化的应用的一个重要而又有些迫切的瓶颈是它减慢了产品的开发。由于所有的工程师在一体化的应用程序中建立功能，他们往往是紧密耦合的。我们不能灵活地改变系统的一部分，因为它也会影响其他部分。我们也害怕做出巨大的改变，因为影响太大，有时很难预测。整个应用程序是作为一个整体来部署的，所以如果由于一个错误的提交而导致部署停滞，那么所有其他的更改，即使它们完美地工作，也不能外出。相比之下，微服务架构允许团队更快地运送、学习和迭代。他们可以专注于他们正在构建的功能，从复杂系统的其余部分解耦。变化可以更快地到达生产。他们有安全地尝试大变化的灵活性。

在我们新的微服务体系结构中，一个小时内就可以进行生产更改，工程师不必担心它会如何影响系统的其他部分。团队还探索了在开发中安全使用生产数据的方法。因为我们的工程团队的成长，这些都是特别重要的。

第三，一体化的应用使得系统很难扩展特定任务或隔离不同类型任务的资源关切。使用一体化的整体应用程序，我们必须扩大和减少整个系统的资源需求更多的任务，即使这意味着系统是过度配置其他更简单的任务。为了缓解这些问题，我们将不同类型的请求分离到 Node.js 进程。他们在一定程度上起作用，但不会成规模，也是因为这些微版本的一体化服务是紧密耦合的。

最后但并非最不重要的，一个重要的和即将成为紧急的瓶颈是，它阻止我们尝试新技术。微服务架构的一个主要优势是，每个服务都可以使用不同的技术堆栈构建，并与不同的技术集成。这使我们能够为这项工作挑选最好的工具，更重要的是，以快速和安全的方式进行这项工作。

微服务策略

采用微服务架构不是一个小事情。它可能出错，导致降低了工程效率。在本节中，我们将分享在通过初期帮助我们的七项战略:

1. 创造价值明确的新服务

2. 一体化持久存储被认为是有害

3. 解耦 “构建服务” 和 “运行服务”

4. 全面和一致的可观测性

5. 并不是所有的新服务都需要从头开始

6. 敬畏故障，因为他们会发生

7. 从第一天就避免出现 “微服务综合症”

想具体了解这些策略，赶快点击 「阅读原文」去学习吧。

内容翻译自原文，如有不妥，敬请谅解。

原文在 Medium，请自备梯子。