你好，哈布尔。 OTUS 新课程现已开放报名 。 在课程开始前夕，我想和大家分享一下我的原创文章。
介绍
架构风格的选择是构建信息系统时的基本技术决策之一。 在本系列文章中，我建议分析建筑应用中最流行的建筑风格，并回答何时最优选哪种建筑风格的问题。 在演示过程中，我将尝试绘制一条逻辑链来解释架构风格从单体到微服务的发展。
有一点历史
如果你尝试问开发人员：“为什么我们需要微服务？”，你会得到各种各样的答案。 您会听说微服务提高了可扩展性，使代码更易于理解，提高了容错能力，有时您会听说它们允许您“清理代码”。 让我们回顾一下历史，了解微服务出现背后的目的。
简而言之，我们目前理解的微服务是这样产生的：2011年，James Lewis在分析各个公司的工作时，提请注意一种新的“微应用”模式的出现，该模式在加速部署服务方面优化了SOA。服务。 稍后，在 2012 年的一次架构峰会上，该模式被重新命名为微服务。 因此，引入微服务的最初目标是改善臭名昭著的问题。 上市时间.
2015 年，微服务掀起了热潮。 根据一些研究，如果没有关于微服务主题的报告，任何一次会议都是不完整的。 此外，一些会议专门讨论微服务。 如今，许多项目开始使用这种架构风格，如果项目包含大量遗留代码，那么向微服务的迁移可能正在积极进行。
尽管如此，仍有相当少数的开发人员能够定义“微服务”的概念。 但我们稍后会讨论这个......
巨石
与微服务形成鲜明对比的架构风格是单体（或一体式）。 讲述什么是单体可能没有意义，所以我会立即列出这种架构风格的缺点，这引发了架构风格的进一步发展：大小、连接性、部署、可扩展性、可靠性和刚性。 下面我建议分别看看每个缺点。
大小
巨石非常大。 而且它通常与一个非常大的数据库进行通信。 应用程序变得太大，以至于一名开发人员根本无法理解。 只有那些花费大量时间编写此代码的人才能很好地使用整体架构，而初学者会花费大量时间试图弄清楚整体架构，并且不能保证他们会弄清楚。 通常，在使用单体应用时，总会有一些“有条件”的资深人士或多或少地了解单体应用，并在一年半内击败其他新开发人员。 当然，这样的有条件的前辈是单点故障，他的离开可能会导致巨石的消亡。
连通性
巨石是一个“大泥球”，其变化可能会导致不可预测的后果。 通过在一个地方进行更改，您可能会损坏另一个地方的整体（同样的“你抓伤了耳朵，*@掉下来了”）。 这是因为整体中的组件具有非常复杂且最重要的是不明显的关系。
部署方式
由于其组件之间的复杂关系，部署整体架构是一个漫长的过程，有其自身的仪式。 这种仪式通常并不完全标准化，而是“口头”传承。
可扩展性
整体模块可能具有冲突的资源需求，需要在硬件方面做出妥协。 想象一下，您有一个由服务 A 和 B 组成的整体。服务 A 对硬盘大小有要求，而服务 B 对 RAM 有要求。 在这种情况下，安装单体应用的计算机必须支持这两种服务的要求，或者您必须手动、人为地禁用其中一项服务。
另一个例子（更经典）：服务 A 比服务 B 更受欢迎，因此您希望有 100 个服务 A 和 10 个服务 B。同样，有两个选择：要么我们部署 100 个成熟的单体，要么部署在一些单体上服务 B 必须手动禁用。
可靠性
由于所有服务都位于一起，如果单体崩溃，那么所有服务都会立即崩溃。 事实上，这可能并没有那么糟糕，至少在分布式系统中不会出现部分故障，但另一方面，由于 0.001% 用户使用的功能错误，你可能会失去所有用户您的系统的。
惯性
由于整体的规模，很难切换到新技术。 因此，留住这位前辈是一项单独的任务。 项目开始时选择的技术堆栈可能会成为阻碍产品开发的障碍。
结论
下次我们将讨论人们如何尝试通过转向组件和 SOA 来解决这些问题。
阅读更多：
来源： habr.com