我听说单体应用才是未来

单体应用才是未来？

特斯拉在自动驾驶方面受到了一些负面报道（我有一台特斯拉，我个人认为自动驾驶这个功能需要改名）。由于驾驶员入睡，发生了多次车祸。那是自动驾驶的问题吗？我想说的是：驾驶员应该知道不能在405号高速公路上打盹（我使用特斯拉的自动驾驶功能，请相信我，我是不会睡着的）。那么，是让我们移除自动驾驶功能，还是学会正确使用它？

我们在软件架构中处于同一位置。人们沉迷于专业术语和新想法，好像他们能够解决所有问题。最近，这种趋势也出现在微服务领域，围绕微服务的使用和分解单体应用。关于这个问题已经有许多有趣的文章和对话。如果你还没有看到过，现在你正在阅读的就是我所指的对话之一。

前几天，一位非常体贴的同事告诉了我这些事（部分原因是为了通知我，另外部分则是为了骚扰我），我认为它们提出了一些非常有趣和有用的观点。要真正理解这将如何帮助或损害我们，我们不仅需要指出其中的坏处，还应该为了充分利用其中的优势提供一些指导。让我们仔细看一下这些问题。

为什么单体应用是未来？

那么，为什么有人认为我们会回到单体应用程序的技术栈呢？

单体应用是未来，因为人们试图用微服务解决的问题和现实相去甚远。 — KELSEY HIGHTOWER

我相信这是100％正确的。 “微服务”一词已被当作特效药，用于修复所有问题，从功能失调的组织到设计不良的系统。 但是，我不认为替代方法是返回到“单体应用”（旁白：不祥的音乐响起）。

我们正在处理期望与现实范式之间的矛盾。 其中大多数可以归结为以下一种：

• 服务布局方面缺乏计划
• 缺乏分布式架构的经验
• 缺乏测试和实施的时间

分布式单体模式

在"Head First Design Patterns"一书中，你可能找不到这个模式。

现在的代码库太糟糕了，然后你说“你知道我们应该怎么做？ 我们应该把它分解。 我们把它分解，并以某种方式找到一种我们从未接触过的工程规范。” 然后他们最终要做的是创建50个可部署项目，但这实际上是一个分布式的单体应用。 — KELSEY HIGHTOWER

不幸的是，这太普遍了。 "魔术药丸''使得人们陷入了思维定势：应用粒度越小越好且更快。 微服务并不能修复一个糟糕的单体应用。 如果你制作的千层面很糟糕，那么切成多少片它仍然很糟糕。

你是否有分散的整体设计？

在Hacker News上的一篇文章中,rubyn00bie指出了这些明显的迹象：

• 你把表复制到另一个数据库中，而没有将数据转换成新的结构（没有添加任何信息）。
• 如果没有Y或Z，则服务X不能正常工作，并且/或者你没有策略应对其中之一发生故障。
• 很可能无法有效地解耦不同的服务。服务X可以“容忍”服务Y的失败，但没有服务Y便无法运行。
• 你通过事件总线推送所有数据，以使服务保持“同步”。

rubyn00bie提到的一些点非常棒。在设计阶段必须考虑所有这些项目。相互依赖的服务需要 1）被组合成一个微服务或 2）使用队列模式以确保服务可以处理该项目（如果可用）3）两个系统都由另一个微服务（类似乐队中的指挥家）来调用以保证能正确处理错误，这种模式通常也被称为服务编排。

事件总线是微服务基础结构的重要组成部分。但是，我认为应该只将它们用于通知，而不是直接用来做数据同步。

如果你从单体应用转向微服务，则必须以此为契机进行重新评估和更新。很有可能，如果现在你处于这个决策点，那么你所谈论的一般是已经存在了一段时间的系统。你不能将其视为剪切和粘贴的编码练习，而必须回到第一步从头做起。

以恰当的方式分解单体应用

那么，如何在没有精神崩溃或放弃的情况下完成这项任务呢？

作充足的计划

你需要对单体应用有深入的了解。 对你而言，这可能意味着需要进行一些研究并了解你所不熟悉的方面。 你需要将其视为构建一系列独立的子系统，而不仅是被分解成大型系统。

这可能看起来并不重要，但是你对问题的认知和思维方式会产生巨大的影响。 这种观点将塑造你遇到的每一个决定。

以正确的观点实施

例如，假设你有一个作为电子商务平台的整体应用程序。你已决定打破单体应用。你有几种选择：

• 越小越好：在应用程序中找到逻辑划分点，使用它们来创建紧密连接在一起的较小的应用程序。部署这些应用并宣告胜利，你将成为微服务大师！
• 更小更智能：花时间去找到单体应用的核心功能。考虑这些是独立于生态系统而存在的单独的端到端应用程序。尝试扩展其处理更多用例的能力。部署无状态应用程序。

因此，在我们的示例中，我们可能将商品分解为多个较小的部分，即购物车，产品，订单等，在两种情况下，我们都可以选择相同的分割点，但是构建的内容将大相径庭。在一种情况下，我们将服务分开，但它们之间会紧密耦合。在第二种情况下，我们希望为每种情况创建一套完整的功能。

对于你创建的每个微服务，都要问问自己。

我可以把这个微服务放置在另一个体系结构中，而无需对其进行更改并充分利用其所有功能吗？ by 一个具备反思能力的工程师

如果你的回答是肯定的，那么你将从正确的观点出发。如果不是，则说明你的系统具有太多的耦合成分，请重新开始。

是分解也是不分解

我认为我们应该回到单体应用吗？ 不！

许多事情都遵循微服务模式，例如你的汽车。 你的汽车由多个较小的部件组成。 其中的一些组件（例如你的刹车）可用于其他汽车（就好像完全独立的微服务）。 其他组件（例如挡风玻璃）是根据你的品牌和型号特指的（例如相互依赖的微服务组件）。

其中存在微妙的平衡点，需要进行充分的规划才能正确实施。 好比任何一个好的架构设计，它永远不会固定，并且会随着时间而发展。

当你对你的架构设计按上保存键的同时，它已经无效了 by 一个聪明的架构师

一个好的微服务解决方案首先要认识到你是想要或需要做出改变而要进行改变。 如果需要，请找出原因，并避免使用天灾这样不切实际的借口。

微服务小贴士

• 微服务不仅仅是缩小规模。
• 实施成功与否取决于你事先所作的规划。
• 在网络上有大量的信息和成功的设计模式/案例可以参考。
• 以此为契机重新创建和更新服务。
• 重新评估你的基础存储和技术。
• 朋友不会允许朋友“喝了酒后再设计”软件系统。