介绍
选择建筑风格是构建信息系统的基本技术解决方案之一。在本系列文章中，我建议分析建筑应用程序中最流行的建筑风格，并回答何时是最喜欢的建筑风格的问题。在此过程中，我将尝试画出一条逻辑链，该逻辑链解释从整体式到微服务式的建筑风格的发展。
一点历史
如果您尝试向开发人员提出问题：“为什么我们需要微服务？”，那么您将获得各种答案。您会听到微服务改善了可伸缩性，使您的代码更易于理解，提高了容错能力，有时您会听到它们允许您“清理代码”。让我们回到历史上来了解微服务出现的目的是什么。
简而言之，按照我们目前的理解，微服务的出现如下：2011年，詹姆斯·刘易斯（James Lewis）分析了多家公司的工作后，提请人们注意一种新的“微应用”模式的出现，该模式可以在加速服务部署方面优化SOA。不久之后的2012年，在架构峰会上，该模式被重命名为微服务。因此，引入微服务的最初目标是缩短臭名昭著的上市时间。
2015年，微服务正处于“炒作热潮”中。根据一些研究，如果不讨论微服务这个话题，任何会议都是不完整的。此外，一些会议专门针对微服务。如今，许多项目开始使用这种体系结构样式，并且如果项目包含大量的旧代码，那么很可能会积极地进行向微服务的迁移。
尽管有上述所有内容，但仍有许多开发人员可以定义“微服务”一词。但是我们稍后再讨论...
整体式
与微服务相比，架构风格是整体的（或多合一的）。分辨什么是整体可能没有任何意义，所以我将立即列出这种架构样式的缺点，这些缺点引发了架构样式的进一步发展：大小，一致性，部署，可伸缩性，可靠性和惯性。下面，我建议分别了解每个缺点。
规模
整体非常大。而且他通常与一个非常大的数据库进行通信。该应用程序太大了，一个开发人员根本无法理解。只有那些花了很多时间在这段代码后面的人才能与巨石一起工作，而初学者会花很多时间试图弄清巨石，而不是他们会弄清楚它的事实。通常，在使用整体时，总会有一些“有条件的”资深人士或多或少地了解整体，并给其他新开发人员打了一年半。当然，这样的有条件的前辈是单点失败，而他的离开会导致整体的死亡。
连通性
整体是一个“大泥球”，其中的变化可能导致不可预测的后果。通过在一个位置进行更改，您可以在另一个位置损坏整体组件（相同的“抓挠我的耳朵，* @掉下”）。这是由于整体中的组件具有非常复杂的关系，最重要的是，没有明显的关系。
部署方式
由于组件之间的复杂关系，部署整体是一个漫长的过程，需要有自己的习惯。这种仪式通常没有完全标准化，并通过口耳相传。
可扩展性
整体模块可能具有冲突的资源要求，这需要在硬件方面进行折衷。想象一下，您的整体由服务A和B组成。服务A对硬盘的大小有要求，而服务B对RAM的有要求。在这种情况下，要么安装了整体的计算机必须支持这两项服务的要求，要么您将不得不手动禁用其中一项服务。
另一个示例（更经典）：服务A比服务B受欢迎得多，因此您希望服务A为100，服务B为10。同样，有两个选择：我们部署100个成熟的整体组件，或在某些组件上部署则必须手动禁用服务B。
可靠性
由于所有服务都在一起，因此如果整体式设备掉落，则所有服务会同时掉落。实际上，这可能还算不错，至少在分布式系统中不会出现部分故障，但是另一方面，由于0.001％用户使用的功能存在错误，您可能会失去系统的所有用户。
惯性
由于整体的大小，很难切换到新技术。结果，留住该有条件的前辈是一项单独的任务。在项目开始时选择的技术堆栈可能会成为阻碍产品开发的障碍。
结论
下次，我们将讨论人们如何通过转向组件和SOA来解决这些问题。
阅读更多：