Monoliths 的分类

在过去的几年中，我们发表了很多有关于微服务的文章，包括对各种反模式的介绍、它们与 monoliths 的关系以及微服务架构的发展趋势等内容。虽然许多开发者是从零开始使用微服务搭建应用程序，但有许多人都会选择用它来帮助分解遗留的 monolithic 应用程序。过去我们采访过很多人他们在相关领域的经验，最近 Derek C. Ashmore 提出了分类 monoiths 的想法，在下面的文章中我们将讨论如何将其分解为多个管理组件，并可能会实现为微服务。

monolith 这个应用程序过于庞大，我们无法有效管理它。想要改善和修复它代价很高。改变到 monoliths 通常会带来意想不到的后果，比如说你在修复一些部分的时候，另外的一部分就被破坏了。要想管理好 monoliths 必须充分了解技术栈，因此它不能像其他的新技术一样简单地发展和成熟。由于 monolith 很庞大，它的代码很难理解，所以新的开发者要学习太多的相关知识，其代价很昂贵并且非常费时。同样的特性也让公司想将其外包变得不太可能。

所以让我们一起来看看 Derek 所定义的分类，他强调这些特性适用于所有的简单 monolithic 应用程序。在一开始，他介绍了“功能过于花哨的 web 应用程序”：

这类 monolith 特定于 web 应用程序。由于新功能的加入，它变得越来越大、越来越复杂。此外，其中的一些新功能在刚开始设计应用程序的时候并没有考虑进来。因此，这些新的功能的加入非常尴尬，它们不符合最初的应用程序设计。通常我们没有时间和预算在应用程序设计中加入方便维护和支持的新功能。这往往会给技术债务中附加不必要的耦合。

在这一类中 Derek 讨论了几个常见的问题和影响，比如说添加新功能可能会让整个应用程序变得更复杂：

新功能不仅仅只影响了用户界面，它还影响了支持这个界面和底层数据库的服务器端代码。通常服务器端代码和数据库与用户界面紧密耦合，并“假定”目前的业务流程是由界面实现的。

同样，大多数 monolitic 应用程序不能测量或者追踪特定功能的使用：

因此，一旦功能实现了就永远不会移除。移除不用的或者是不常使用的功能似乎逻辑上看起来非常合理，因为这些代码会增加系统复杂度，会对新功能的添加造成负面影响。可悲的是，由于这样做的优势很难衡量，在大多数组织中很难申请到去除功能的预算。

下一种 monolith 的类型是“数据存储扼杀”：

尽管数据库（关系型和非关系型）已经存在了很长一段时间，许多组织的数据库设计能力还远远不够。因此你得到的往往是面向过程的数据存储结构。就是说基于过程的数据存储结构现在由数据库支持的应用程序实现。

Christian Posta 最近提出，数据是微服务中最难处理的部分，Derek 同意这也是 monoliths 的驱动因素之一，并将它们分离。如他所说，重构数据库比重构应用程序代码更难并且会花费更多时间：

任何数据库重构发生的同时还需要支持现有的代码。同样，任何数据库重构还需要转换一些数据的类型。代码的存在状态是非常短暂的，它只在运行时间存在。数据库状态是永恒的。对数据库的改变必须包括将存储在其中的数据也改成新的格式。

根据 Derek 的经验，重构数据库比重构代码风险更大，由于当发现重构数据库发生错误的时候，返回原状态非常复杂，与此同时还要兼顾在重构发生之后输入的新数据不会丢失。在大多数的组织中，丢失数据并不会给予考虑。

Derek 所述的最后一个分类是“过度设计的原始码组件”，Derek 说开发者有时候会“感到无聊，找一些更有趣的事情来做”，而不仅仅是完成手头的任务。这就带来了一些连锁反应，当原来的开发者离开之后，维护代码就会变得更困难，因为一些复杂的代码仅仅存在原来开发者的脑中。

这些就是迄今为止 Derek 对 monoliths 的所有分类。在未来，他打算在博文中展示它们如何可以分解成为更多可以管理的组件或是应用程序。到那时，我们也会跟踪报道后续的文章。

查看英文原文： Categories of Monoliths