听说大应用（Monoliths）是软件开发的未来？

全文共2618字，预计学习时长8分钟

大应用是未来吗？

特斯拉在自动驾驶方面经常有一些负面 道，因为司机睡着了，发生了多起撞车事故。

这是自动驾驶员的错吗？

我会说司机应该知道不要在405高速公路上打盹（但我用的是自动驾驶仪，它睡不着的）。

那么，我们是应该一起去除自动驾驶还是学会正确使用它呢？

我们在软件体系结构中处于同样的位置。人们在流行语和新的想法上跳来跳去，好像他们能解决一切问题。

最近，这个问题主要集中在微型服务的使用和分裂大应用上。关于这个问题有过一些有趣的对话。

前几天，一位非常体贴的同事提醒我注意这些问题（一部分是为了通知我，一部分是为了骚扰我），我认为这些问题提出了一些非常有趣和有效的观点。为了真正理解它们，我们不仅需要指出不好的方面，而且需要指导好的方面。让我们来看看这些。

为什么大应用是未来？

那么，为什么有人认为我们会回到单片应用程序堆栈呢？

整体是未来，因为人们试图用微服务解决的问题并不符合现实。——KELSEY HIGHTOWER

我相信这是百分百正确的。

“微服务”这个词被用作一颗神奇的药丸，可以解决一切问题，从一个功能失调的组织到一个设计糟糕的系统。但是，我不认为另一种选择是回到“大应用”（排队时响起的不祥的音乐）。

我们面对的是期望对现实的模式。其中大部分可以归结为以下几点:

· 在服务布局方面缺乏计划

· 缺乏分布式架构的经验

· 缺乏测试和执行的时间

分布式大应用模式

你可能在《头脑优先设计模式》书中找不到这个。

现在的代码库太糟糕了，你说: “你知道我们应该怎么做吗？我们应该结束它。我们要打破这种局面，找到一开始就没有的工程纪律。” 然后最终得到的是创建50个可部署的，但它实际上是一个分布式的庞然大物。——KELSEY HIGHTOWER

不幸的是，这种情况太普遍了。随着“神奇药丸”的使用，人们陷入了越小越快，就越好的思维模式。微服务无法修复一个不好的庞然大物。如果你做的千层面不好吃，不管你把它切成多少块，它还是不好吃。

你有一个分布式大应用吗？

在黑客新闻的一篇文章中，rubyn00bie指出了这些明显的迹象:

1.您正在复制表（信息），而没有将数据转换为其他数据库中的新数据（添加信息）…

2. 如果没有Y或 Z， X服务就无法正常工作，而且/或者你对如何处理其中一个服务质量的下降没有应对策略。

2.5 除此之外，很可能没有办法实现服务的有意义分离。服务X可以“容忍”服务Y的失败，但如果没有服务Y，它就无法正常工作。

3. 您将所有数据推送到一个事件总线上，以保持服务“同步”…

rubyn00bie（我喜欢这个名字）命中了一些要点。这些项目都必须在设计阶段加以考虑。相互依赖的服务需要1）在微服务中组合2）使用队列模式来确保服务可以处理项目3）两个系统都可以在微协调器后面来处理错误条件。

事件总线是微服务基础设施的重要组成部分。但是，我认为他们应该仅仅起通知作用，而不是使数据同步。

如果你从一个大应用移动到微型服务，你必须使它成为重新评估和更新的机会。如果你正处于这个决策时刻，那么很有可能你谈论的是一个已经存在了一段时间的系统。你不能把这仅仅看作是剪切粘贴代码的练习，必须要回到第一步。

正确地分解一个大应用

那么，你怎样才能在不放弃或没有精神崩溃的情况下完成这项任务呢？

计划得要比想得多

你需要对大应用有深入的了解。这可能意味着你需要研究和了解你不熟悉的方面。需要把它想象成一堆独立的子系统，而不是一个大的系统，分布在小的部分。

它可能看起来并不重要，但是你看待它的方式会产生巨大的影响。这个观点将塑造你将遇到的每一个决定。

用正确的观点实施操作

例如，假设有一个电子商务平台的整体应用程序。你已经决定分解这个大应用。你有几个选择:

· 越小越好——找到应用程序中的逻辑分支点，用它们创紧密联系起在一起的较小应用程序。部署这些然后宣称胜利，自己是一个微服务硕士！

· 越小越聪明——花点时间发现大应用的核心功能。考虑到这些是独立于生态系统的端到端应用程序。尝试扩展它处理更多用例的能力。部署一个无状态应用程序。

因此在示例中，我们可以将事物分解为多个更小的部分，运送车、产品、指令等等。在这两种情况下，我们可以选择相同的分割点，但是，我们所建立的东西将是非常不同的。一般来说，我们将分离服务，但它们之间将存在紧密联合。在第二个场景中，希望为每个应用程序创建一组完整的功能。

对于你创建的每一个微型服务，问问自己这个问题：

我是否可以将这个微型服务放在另一个架构中，而不对其进行更改，并充分利用其所有功能？——一个自我反思工程师

如果你的答案是肯定的，那么你的观点是正确的。如果没有，则说明联合太多，请重新来一遍。

分解而不是毁掉它

我们应该回到大应用吗?

不。

很多东西都遵循微服务模式，比如汽车。汽车是由多个较小的部件组成的。其中的一些组件，比如休息时间，可以用在你的车以外的车上，就像一个完全独立的微型服务器。其他组件，比如挡风玻璃，是针对制造和模型而设计的，这就像相互依赖的微服务组件。

这有一个谨慎的平衡，需要计划才能正确实施。就像任何好的架构一样，它从来不是固定的，并且会随着时间的推移而发展。

在架构图上点击保存的那一刻，它已经无效了——一个聪明的建构师

做出一个好的微服务解决方案首先要认识到，你想要或者需要它做出改变。如果需要，认识到它的原因，避免类似造成瘟疫的根本原因。

微型服务提示

· 微服务不仅仅是减小尺寸。

· 实施成功与否将取决于你投入的计划量。

· 上有大量的信息和设计模式可以成功。

· 利用这个机会重新创建并更新你的服务。

· 重新评估底层存储和技术。

· 朋友不会让朋友“喝酒然后设计”软件系统。

留言点赞关注

我们一起分享AI学习与发展的干货