OTUS在11月启动了一个新的教育计划“ Software Architect” ，与此相关的是，我们为该课程的未来学生和博客读者准备了一系列出版物。
创造新产品总是有风险的。 选择正确的架构是成功道路上的重要一步。 如果您在整体的，面向服务的，微服务和无服务器的体系结构之间进行选择，那么本文将帮助您做出正确的选择。
整体架构
巨石是一个古老的词，表示一个巨大的石块。 尽管该术语在今天已被广泛使用，但在所有领域中人们的看法都是相同的。 在软件工程中，整体模型是指单个不可分割的单元。 整体软件的概念是将应用程序的各个组件组合到同一平台上的一个程序中。 通常，单片应用程序由数据库，客户端用户界面和服务器应用程序组成。 该软件的所有部分都是统一的，其所有功能都集中在一个地方。 让我们详细看一下整体软件的结构。
整体式体系结构对于小组来说很方便，因此许多初创公司在创建应用程序时都会选择这种方法。 整体软件的组件是相互连接和相互依赖的，这有助于软件实现自给自足。 该体系结构是用于构建应用程序的传统解决方案，但是一些开发人员发现它已过时。 但是，我们认为在某些情况下单片架构是理想的解决方案。
尽管我们在Google上使用微服务的经验非常丰富，但我们（在Scaylr）还是走了一条整体路线，因为拥有一台整体服务器意味着我们两名工程师的工作量减少了。
Scaylr设计主管Stephen Cherwinski
要了解此解决方案是否适合您的业务，让我们看一下它的优缺点。
整体架构的优势
简化开发和部署
您可以集成许多工具来促进开发。 此外，所有操作都在一个目录中执行，从而简化了部署。 由于采用了单片内核，开发人员无需立即部署更改或更新，因为他们可以立即进行部署并节省大量时间。
跨领域问题更少
大多数应用程序依赖于许多跨组件的任务，例如审计跟踪，日志记录，速度限制等。由于其通用的代码库，单片应用程序更容易考虑这些问题。 当一切都在一个应用程序中运行时，将组件连接到这些任务会更容易。
最佳表现
正确组装后，单片应用程序通常比基于微服务的应用程序生产力更高。 例如，具有微服务体系结构的应用程序可能需要对40个不同的微服务进行40个API调用，以加载每个屏幕，这显然会导致性能下降。 反过来，由于通用代码和内存，单片应用程序可在软件组件之间提供更快的通信。
整体架构的缺点
随着时间的推移，代码库变得很繁琐
随着时间的流逝，大多数产品继续开发和扩展，其结构也变得模糊。 代码库开始显得非常庞大，并且变得难以理解和更改，尤其是对于新开发人员而言。 寻找副作用和成瘾也变得越来越困难。 随着代码库的增长，质量会下降，IDE会变得过载。
难以引进新技术
如果您需要在应用程序中添加一些新技术，则开发人员可能会遇到实施障碍。 添加新技术意味着重写整个应用程序，这既昂贵又耗时。
灵活性有限
在整体应用程序中，每个次要更新都需要完全重新部署。 因此，所有开发人员都必须等待，直到完成。 当多个团队在同一个项目上工作时，灵活性可能会大大降低。
最后
整体模型并不是过时的，在某些情况下，它仍然可以很好地工作。 尽管微服务如今很流行，但一些大型公司（例如Etsy）仍然是单一的。 如果您的团队处于起步阶段，创建的产品未经验证并且没有微服务经验，那么单片软件的体系结构可能会很有用。 对于需要尽快使产品投入运营的初创企业而言，整体式产品是理想的选择。 但是，上面提到的一些问题与单片式架构紧密相关。
SOA
面向服务的体系结构（SOA）是一种软件体系结构，涉及模块化应用程序，该应用程序由执行特定功能的离散和松散耦合的软件代理组成。 SOA将组件分为两个主要角色：服务提供者和使用者。 这两个角色都可以由软件代理扮演。 SOA的概念是这样的：可以以易于集成其模块并且可以轻松重用的方式来设计和构建应用程序。
SOA的优点
重用服务
由于面向服务的应用程序中功能组件的自主和松散耦合的性质，这些组件可以在多个应用程序中重用，而不会影响其他服务。
轻盈伴随
由于每个软件服务都是一个独立的单元，因此很容易更新和维护而不会影响其他服务。 例如，大型企业应用程序分解为服务后，将更易于管理。
更高的可靠性
与庞大的代码块相比，服务更容易调试和测试，就像在整体中一样。 反过来，这使基于SOA的产品更加可靠。
并行开发
因为面向服务的体系结构是分层的，所以它在开发过程中支持并发。 可以并行开发并同时完成独立服务。
SOA的缺点
管理困难
面向服务的体系结构的主要缺点是其复杂性。 每个服务应提供及时的消息传递。 这些消息一次的数量可能超过一百万，这使得管理所有服务变得困难。
投资成本高
SOA开发需要对人力资源，技术和开发进行大量的前期投资。
额外负荷
在SOA中，所有输入在一个服务与另一服务交互之前都经过验证。 当使用多种服务时，这会增加响应时间并降低整体性能。
最后
SOA最适合于银行等复杂的企业系统。 银行系统很难划分为微服务。 但是，整体方法也不适合银行系统，因为其中一部分可能损坏整个应用程序。 最好的解决方案是使用SOA方法并将复杂的应用程序组织到隔离的独立服务中。
至此，翻译的第一部分结束了，在第二部分中我们将讨论微服务和无服务器架构。