从单体到微服务：架构入门基础知识

这是一张图片，展示的内容请参考给出的链接。

你好，亲爱的读者！嘿，如果你正在读这篇文章，想必你已经对互联网的工作原理有了一定的了解，你也自己搞定了一些事情，所以，干得不错！

下一步的重要一步是理解一些现有的模式和架构怎么做。这不仅会使你的软件构建更加一致，而且也会更加稳固，比如从扩展性到维护性。

这篇文章会聊聊两种最受欢迎的软件架构：单体架构和微服务架构（以及介于两者之间的其他一些重要的概念）。

像往常一样，我们有很多讨论关于哪个更好，而答案一如既往地相同：没有一招鲜吃遍天的方法，要学会何时何地使用每个工具，以及如何在这两者间灵活切换，才能成为一个理智的技术达人。

这里有一个图片链接：

如果你不熟悉，单体架构是一种设计软件应用程序的传统方式。在这种方式下，应用程序被设计为一个单一的整体，我们通常称它为单体，其中软件组件互相联系且彼此依赖。

这种架构的特点是单一的代码库（通常使用MVC模式,即“模型-视图-控制器”），共享的数据库，并且通常只有一个部署实例。

优点

单体应用通常更容易开发，尤其是在较小的项目或团队中。因为这些不同的部分都位于同一个地方，所以它们之间的交互也变得简单直接——这意味着通常会有较少的 API 调用，也不需要费心处理数据，以便让一切正常运行。

就部署来说，通常也更简单。因为你只需要部署一个单元，一部署好，一切就会正常运行，无需再额外操心。

当我们谈论调试时，通常会比较简单，因为整个应用程序在一个单一的模块或环境中运行（这通常意味着你不必在多个应用程序之间切换查找问题）。端到端测试也可以更容易进行，并且可以顺利地贯穿整个流程或过程。

不足

随着应用的扩大，一些问题开始浮现。第一个挑战是组织上——因为所有东西都在同一个地方，维护大型应用及其所有相关上下文变得非常困难（当然，有一些方法可以提前规划——比如模块化单体，但快速开发的应用程序通常没有被充分考虑这些）。

第二个是缩放问题。由于整个应用程序都在一个单一的单元内，这意味着应用程序中特定资源密集的点将和其他应用程序部分共享相同的资源。这通常意味着，缩放将会比单纯增加服务器性能或用其他技术重写相应部分要复杂得多。

现在，单体架构的通用替代方式是微服务架构。这是一种将单个应用程序拆分为多个小型服务（这就是“微”字的由来）的方式。每个服务都在自己的进程中运行，并通过轻量级机制与其他服务通信，以保持整个系统运行顺利。这些服务通常可以独立开发、部署和扩展规模。每个服务通常都有自己的数据库，并通过规范的API与其他服务通信。

它也有自己的一套组织方法（有很多著名的书籍专门讨论），其中最常见的一种是DDD（领域驱动设计）。

优势

第一个也是最明显的一点是规模。微服务可以独立地进行扩展或缩放，这使得在整个应用程序中的资源利用更加高效。由于所有内容都需要作为黑盒互相通信，这种架构还提供了在不同服务中选择技术的灵活性，因此在技术选择上更加自由。

第二个要点是，当我们谈论大型应用时，微服务代码的复杂性被分散到各个微服务中。这通常意味着，如果某个微服务有问题，可以简单地指派团队中的一个新成员去检查一下——这个错误可能存在的地方本来就不多。

一些缺点

首先，让所有这些东西正常地通信和交互其实是个大挑战。工程师可能要花很多时间来找出为什么Kafka的消息没有送达，或解决其他各种奇怪的问题。管理这一切、他们的基础设施和部署可能非常棘手。

第二个问题是代码上下文更分割——这在理解代码库时是好事，但在了解产品时却可能会让人头疼——代码在5个文件中更容易理解，而在5个不同的应用中则要困难得多。

最后一个问题是微服务的一个缺点，即延迟问题。如果它们没有被正确设计，职责分离和预期的速度提升可能无法实现，现在需要增加许多不同的调用来让它们相互沟通。

等等

有时，当人们创造新事物时，他们也会尝试解决这些问题，而这正是Encore的特性之一——Encore正是这篇文章的赞助商。

对我来说，我觉得最棒的一点是，你也不用太担心不同微服务之间的通信问题了（https://encore.dev/docs/ts/primitives/api-calls）。这真是个好主意——你几乎能享受到和操作单体应用差不多的开发体验，同时还拥有微服务的所有扩展能力。

例如，你可以通过简单地导入它，在一个服务里调用另一个服务。

- 服务内部的其他服务调用

也有很多功能可以让多个服务的部署过程变得更简单，让这个过程变得更容易。他们真的在努力实现两全其美，让部署变得既高效又稳定，让开发者和运维人员都能受益。如果你能去查看一下并给他们点个赞就太好了！

⚡ 星 encore 闪电

在选择架构时，你可以考虑应用的增长潜力、团队规模以及产品的实际复杂度。

你的应用越简单，你就能更多地从单体架构中受益。如果你不确定，最安全的选择是采用单体——你可以以后再拆分它们，但将它们重新组合起来是很困难的（如果你仍然不确定，这里有一篇很好的文章可以参考：先单体后微服务架构）

随着复杂性的增加，你可能希望将单体式应用拆分成多个微服务，因此，让我们聊一聊如何将单体式应用转换成一系列微服务架构。

如何把单体架构迁移到微服务架构

从单体迁移到微服务架构有几种方法。我们快速过一下这些方法。

• Greenfield 替换：从头开始构建事物——不受之前工作的束缚，在某些情况下可能非常有益。当然，这里存在许多潜在的问题（需要多长时间？用户要忍受多久？等等）。
• Brownfield 替换：新架构应该与现有的软件共存着。当我们谈论 Brownfield 替换时，与旧的或有问题的软件共存可能会带来很多麻烦和痛苦。一个有趣的解决方法是使用 Strangler Fig 模式（绞杀藤模式），我们将逐步将旧代码包裹起来，一点点地将其重定向到新代码，最终淘汰掉旧代码。这使得过渡更加平滑，也降低了风险。

通常来说，我们将按照以下步骤来做。

1. 确定现有应用程序内的明确边界。
2. 逐步提取服务，从不太重要的组件开始。
3. 将新功能实现为独立的服务。
4. 重构现有代码以支持新的架构。
5. 确保在迁移过程中充分测试和监控 → 没有什么比盲目修改应用程序更困难的了

嘿！哇，我们经历了一段挺长的旅程。我们讨论了两种主要的架构方法：传统的单块架构（简单直接，但随着它变大，挑战也越来越多）和微服务架构（灵活且可扩展，但要管理起来复杂多了）。

我希望你现在能够做出决定（或者至少有一种很好的感觉）来面对你接下来要做的选择，但是，记住：没有“一刀切的方法”——如果你要开始一件新的事情，先从单一应用开始试试，如果不是，那就再好好想想！

总而言之，选择适合工作的正确工具很重要。理解这些模式将帮助你针对具体需求做出更好的决策。而且要知道：你随时可以更改——只需确保你有坚实的计划来应对这种转变。