单片内核与完整的微服务架构

马丁·福勒（Martin Fowler）最近发布了另一篇有关微服务的文章 ，特别是关于围绕微服务的炒作。 他指出，尽管微服务现在是一个热门话题，但它们为系统增加了不必要的复杂性，而这些复杂性对于使用具有良好模块化功能的单个整体式应用程序来说就可以正常工作。

我同意他的观点，即微服务确实会增加复杂性，特别是在操作方面，我相信微服务对于小型代码库仍然有意义。

我们不要忘记，随着时间的流逝，整体也会增加开销。 实际上，福勒在自己的文章中也指出：

但是，没有理由不能用定义良好的模块边界来制作单个整体。 至少理论上没有理由； 在实践中，似乎很容易突破模块边界，使整体结构变得既大又纠结。

要详细说明Fowler的说法，在将技术和您的团队扩展到一个代码库上时，您会遇到构建整体的问题。 如果处理不当，代码库可能会很快陷入混乱，就像微服务一样，增加了操作开销。 各种技术需要一起运行而不是单独运行，这是基于服务的方法可以解决的问题。

通过@ flomotlik，Monolith（不仅仅是微服务）会随着时间的推移增加操作开销

点击鸣叫

此外，诸如确保边界保持不变，在更大，更复杂的代码库上执行代码审查以及定期重构代码之类的整体任务也不是免费的。 构建可以运行此更大代码库的更复杂的基础结构是另一个问题。

在与我们的团队和其他团队交谈时，我已经看到了两种不同的微服务架构样式。 一种是提供服务的整体式基础架构，另一种是服务的全部内容。

具有单片内核的微服务架构

在构建了一个整体的应用程序一段时间后，将系统的几个部分移至小型服务以加强边界，加快单个测试套件的速度并使它们更易于独立扩展可能会很方便。 换句话说，尽管整体仍然保留了核心功能，但是许多部分可以外包给支持主要代码库的小型辅助服务。

主要业务逻辑将保留在核心整体中，但是诸如后台作业，通知或其他可由消息触发的小型子系统之类的事物可以移至其自己的应用程序中。

当可以通过发送用于启动作业的消息共享作业所需的所有数据时，这种散布服务的单核方法特别有效。 该服务不需要数据存储，我们基本上已经为主要应用程序设置了委派服务，该服务应易于扩展。

通过专注于驱动其他小型服务的整体主机，您可以保留整体基础结构的许多优点，而对小型服务仅需一点点维护。 通过将这些服务放入云中 ，您可以进一步限制围绕它们管理基础架构的必要性。

随着时间的流逝，这个带有附加小服务的整体可以成长为完全面向服务的体系结构。

完全面向服务的架构

整体内核与完全面向服务的方法之间的主要区别在于，没有清晰的领先代码库可以驱动其余服务。 每个服务都控制其业务功能和数据，并且它们在整个基础架构中均扮演着大致相同的角色。

在单片核心样式中，收到请求的应用程序很可能是包含模型，与数据库对话并执行最多业务功能的应用程序。 在完全面向服务的样式中，获取请求的应用程序仅联系其他服务并返回统一的响应，而不包含所有业务逻辑本身。

完全以服务为导向的体系结构构建风格似乎在以最初建立基于微服务的体系结构的最初目标的团队中更为普遍。 随着时间的流逝，单核可以发展为完全面向服务的，但该核仍保留了很长时间。

一些团队确实在很短的时间内就非常积极地将其整体核心拆分为单独的服务，但这似乎是一个例外。

从长远来看，完全面向服务的风格在扩展和基础架构组成方面可以带来巨大好处，但我确实同意Fowler的观点，即在基础架构管理方面也要涉及更多的内容。

明确定义所需的基础架构

应用程序越大，将某些部分移入服务的讨论就越多。 正如Fowler所说，微服务现在是一个非常热门的话题。 您要确保进行这些讨论时要牢记明确和共同的目标，而不仅是因为时尚。

我经常看到团队讨论未来的面向服务的体系结构，其中一些坚持使用整体核心模型，而另一些则计划完全转向面向服务。 这自然是冲突的，它给讨论带来了截然不同的期望。

您要确保先讨论基础架构的总体目标，然后再进行详细讨论。

定义您的基础架构样式，以引导有关您的微服务未来的讨论-via @flomotlik

点击鸣叫

您要保留大型核心应用程序一段时间还是尽早进入单独的服务？ 在进入有关如何分离服务的详细讨论之前，应该对此做出决定。

用单片核心之类的短语来定义您的基础架构将有助于使讨论基础化，并确保这些讨论以有针对性且成功的方式进行。 否则，您只是在浪费理论讨论的时间，而这些讨论总是很难达到结果。

结论

随着时间的流逝，单片应用程序可以变得更简单。 通过从纯粹的整体架构过渡到整体核心架构，您可以在拆分应用程序时保留这些优势。 随着时间的流逝，如果需要，您可以将其扩展为完全面向服务的体系结构。 这也限制了完全面向服务的基础架构对团队生产力的早期影响。

通过将应用程序的简单部分移至云服务中，我们可以消除维护这些小型服务的许多障碍。 为服务基础架构的增长设定特定的目标（ 例如 ，我们希望保持整体核心，但在接下来的六个月中引入一些服务）可以帮助指导团队中的讨论，是否应该分开哪些部分。 这可以帮助您的团队获得管理面向服务的体系结构的经验，同时保持较低的影响。

在评论中让我们知道您在设置微服务，拆分整体和构建基础架构方面的经验。

“单核与完整的微服务架构” –via @codeship

点击鸣叫

翻译自: https://www.javacodegeeks.com/2015/05/monolithic-core-vs-full-microservice-architecture.html