MVP的最佳架构：单体结构、SOA、微服务还是Serverless？

创造一个新产品就是风险。选择正确的体系结构是迈向成功的关键一步。如果您正在考虑单体、service-oriented、微服务和serverless无服务器体系结构，这篇博文将帮助您做出正确的选择。

单体结构

巨石是一个古老的词，指的是一块巨大的石头。尽管这个术语在今天被广泛使用，但图像在各个领域都保持不变。在软件工程中，单片模式是指单个不可分割的单元。单片软件的概念在于将应用程序的不同组件组合到单个平台上的单个程序中。通常，单片应用程序由数据库、客户端用户界面和服务器端应用程序组成。软件的所有部分都是统一的，其所有功能都在一个地方进行管理。让我们详细了解一下单片软件的结构。

单体架构适合小型团队使用，这也是许多初创公司在构建应用程序时选择这种方法的原因。С单体软件的组成部分相互关联、相互依存，这有助于软件自足。这种体系结构是构建应用程序的传统解决方案，但一些开发人员发现它已经过时。然而，我们相信在某些情况下，单体架构是一个完美的解决方案。

尽管我们在谷歌有过使用微服务的积极经验，但我们（在Scaylr）还是选择了一条单一的路线，因为拥有一台单一服务器意味着我们作为两名工程师的工作量更少。

-- Steven Czerwinski，Scaylr工程主管

为了弄清楚这个解决方案是否对你的生意有好处，让我们考虑一下它的利弊。

单体结构的优点

简化开发和部署

有很多工具可以集成以促进开发。此外，所有操作都使用一个目录执行，这使得部署更加容易。有了单片内核，开发人员不需要单独部署更改或更新，因为他们可以一次完成并节省大量时间。

减少交叉关注

大多数应用程序都依赖于大量横切关注点，如审计跟踪、日志记录、速率限制等。单片应用程序由于其单一的代码库，更容易合并这些关注点。当所有内容都在同一个应用程序中运行时，将组件连接到这些关注点会更容易。

更好的性能

如果构建得当，单体应用程序通常比基于微服务的应用程序性能更好。例如，具有微服务体系结构的应用程序可能需要对40个不同的微服务进行40个API调用才能加载每个屏幕，这显然会导致性能降低。由于共享代码和内存，单体应用程序反过来允许软件组件之间更快的通信。

单体式架构的缺点

随着时间的推移，代码库变得越来越麻烦

随着时间的推移，大多数产品的开发和范围不断扩大，其结构变得模糊。代码库开始看起来非常庞大，并且变得难以理解和修改，特别是对于新开发人员。发现副作用和依赖性也变得越来越困难。随着代码库的不断增长，质量下降，集成开发环境（IDE）过载。

难以采用新技术

如果需要在应用程序中添加一些新技术，开发人员可能会面临采用障碍。添加新技术意味着重写整个应用程序，这既昂贵又耗时。

有限的灵活性

在单片应用程序中，每一个小的更新都需要完全重新部署。因此，所有开发人员都必须等到它完成。当多个团队在同一个项目上工作时，敏捷性会大大降低。

底线

单体模型并没有过时，而且在某些情况下仍然很有效。尽管微服务在今天很流行，但一些像Etsy这样的大公司仍然保持着单体性。如果您的团队处于创建阶段，您正在构建未经验证的产品，并且您没有使用微服务的经验，那么单体软件体系结构可能是有益的。对于需要尽快启动和运行产品的初创公司来说，单体电脑是完美的选择。然而，上面提到的某些问题与单体封装一起出现。

SOA

面向服务的体系结构（SOA）是一种软件体系结构样式，指由执行所需功能的离散和松散耦合的软件代理组成的应用程序。SOA有两个主要角色：服务提供者和服务使用者。这两个角色都可以由软件代理扮演。SOA的概念在于：应用程序的设计和构建方式可以使其模块无缝集成并易于重用。

SOA的优点

服务的可重用性

由于面向服务的应用程序中功能组件的自包含性和松耦合性，这些组件可以在多个应用程序中重用，而不会影响其他服务。

更好的可维护性

由于每个软件服务都是一个独立的单元，因此在不影响其他服务的情况下很容易对其进行更新和维护。例如，大型企业应用程序在进入服务时可以更容易地管理。

高可靠性

与单片方法中的大块代码相比，服务更易于调试和测试。这反过来又使基于SOA的产品更加可靠。

并行开发

由于面向服务的体系结构由层组成，它提倡开发过程中的并行性。独立服务可以并行开发并同时完成。下面，您可以看到几个开发人员是如何并行执行SOA应用程序开发的：

SOA的缺点

复杂管理

面向服务的体系结构的主要缺点是其复杂性。每项服务都必须确保及时传递消息。这些消息的数量一次可能超过一百万条，这使得管理所有服务成为一个巨大的挑战。

高投资成本

SOA开发需要大量的人力资源、技术和开发的前期投资。

超负荷

在SOA中，在一个服务与另一个服务交互之前，所有输入都经过验证。当使用多个服务时，这会增加响应时间并降低总体性能。

底线

SOA方法最适合于复杂的企业系统，如银行系统。银行系统很难进入微服务领域。但单一的方法也不利于银行系统，因为其中一部分可能会损害整个应用程序。最好的解决方案是使用SOA方法，将复杂的应用程序组织到独立的服务中。

微服务体系结构

微服务是一种面向服务的软件体系结构，它专注于构建一系列组成应用程序的自主组件。与作为单个不可分割单元构建的单一应用程序不同，微服务应用程序由多个独立组件组成，这些组件通过API粘合在一起。

微服务方法主要关注业务优先级和功能，而整体方法是围绕技术层、UI和数据库组织的。随着越来越多的企业变得敏捷并转向DevOps，微服务方法近年来已成为一种趋势。

微服务之所以重要，仅仅是因为它们以简化系统复杂性的方式增加了独特的价值。通过将系统或应用程序拆分为许多较小的部分，您可以展示减少重复、增强内聚性和降低部分之间耦合的方法，从而使整个系统部分更易于理解、更易于扩展和更改。

-- 卢卡斯·克劳斯，《微服务》的作者

有很多公司从单一的方法发展到微服务的例子。其中最著名的是Netflix、Amazon、Twitter、eBay和PayPal。为了确定微服务是否适合您的项目，让我们定义这种方法的优缺点。

微服务的优点

易于开发、测试和部署

与其他体系结构相比，微服务的最大优势在于可以独立构建、测试和部署小型单一服务。因为部署单元很小，所以它方便并加快了开发和发布。此外，一个单元的发布不受另一个未完成单元的发布的限制。最后一个好处是，随着开发人员部署部分软件，而不是整个应用程序，部署的风险降低了。

提高敏捷性

有了微服务，几个团队可以独立快速地处理他们的服务。由于微服务组件的解耦，应用程序的每个单独部分都可以独立构建。例如，您可能有一个由100人组成的团队负责整个应用程序的开发（如单体方法），或者您可以有10个由10人组成的团队为应用程序开发不同的服务。让我们从视觉上想象一下。

增加的灵活性允许开发人员在不关闭应用程序的情况下更新系统组件。此外，敏捷性提供了更安全的部署过程和改进的正常运行时间。可以根据需要添加新功能，而无需等待整个应用程序启动。

水平伸缩能力

垂直扩展（运行相同的软件但在更大的机器上）可能受到每个服务的容量的限制。但是水平扩展（在同一个池中创建更多服务）并没有限制，可以通过微服务动态运行。此外，水平缩放可以完全自动化。

微服务的缺点

复杂性

微服务的最大缺点在于其复杂性。将应用程序拆分为独立的微服务需要管理更多工件。这种类型的体系结构需要仔细的规划、巨大的努力、团队资源和技能。复杂性高的原因如下：

自动化需求增加，因为每项服务都应该测试和监控

可用工具无法处理服务依赖项

由于每个服务都有一个数据库，因此数据一致性和事务管理变得更加困难

安全问题

在微服务应用程序中，通过API进行外部通信的每个功能都会增加攻击的机会。只有在构建应用程序时未实施适当的安全措施，这些攻击才会发生。

不同的编程语言

选择不同编程语言的能力是一件事的两个方面。使用不同的语言会使部署更加困难。此外，如果每个服务都是用不同的语言编写的，那么在开发阶段之间切换程序员就比较困难。

底线

微服务很好，但并非适用于所有类型的应用程序。这种模式对于不断发展的应用程序和复杂系统非常有效。考虑当你有多个有经验的团队时，选择一个微服务架构，当应用程序足够复杂的时候，将其分解成服务。当应用程序很大并且需要灵活和可扩展时，微服务是有益的。

现在我们可以比较这三种软件架构，以直观地定义它们之间的差异。

单体应用程序由相互依存、不可分割的单元组成，开发速度非常低。SOA被分解为更小、适度耦合的服务，其特点是开发缓慢。微服务是非常小的、松散耦合的独立服务，具有快速持续开发的特点。

Serverless无服务器体系结构

Serverless无服务器架构是一种云计算方法，用于构建和运行应用程序和服务，无需基础设施管理。在无服务器应用程序中，代码执行由服务器管理，允许开发人员部署代码，而无需担心服务器维护和资源调配。事实上，serverless并不意味着“没有服务器”。应用程序仍在服务器上运行，但像AWS这样的第三方云服务对这些服务器承担全部责任。无服务器体系结构消除了对额外资源、应用程序扩展、服务器维护以及数据库和存储系统的需要。

Serverless体系结构包含两个概念：

• FaaS（Function as a Service）——一种云计算模型，允许开发者将功能上传到云，并让这些功能独立执行
• BaaS（后端即服务）–一种云计算模型，允许开发人员将后端方面（数据库管理、云存储、托管、用户身份验证等）外包，只编写和维护前端部分

使用Serverless无服务器体系结构时，开发人员可以专注于产品本身，而不用担心服务器管理或执行环境。这使开发人员能够专注于开发具有高可靠性和可扩展性的产品。

市场上有很多云供应商。以下是一些顶级Serverless计算提供商：

为了知道这种体系结构类型是否是您的项目所需要的，让我们定义实现无服务器模型的优点和缺点。

Serverless体系结构的优点

易于部署

在无服务器应用程序中，开发人员不需要担心基础设施。这使他们能够专注于代码本身。无服务器架构允许您以极快的速度启动应用程序，因为部署只需数小时或数天（与传统方法的数天或数周相比）。

降低成本

无服务器服务可以降低成本。因为您不需要处理数据库、一些逻辑和服务器，所以您不仅可以创建更高质量的代码，还可以节省开支。使用无服务器模式时，您只需按实际使用的CPU周期和内存收费。

增强的可扩展性

许多企业主希望他们的应用程序像谷歌或Facebook一样具有影响力和可扩展性。无服务器计算实现了自动无缝扩展。您的应用程序将随着负载或用户群的增加而自动扩展，而不会影响性能。无服务器应用程序可以处理大量请求，而传统应用程序将被突然增加的请求所淹没。

Serverless架构的缺点

厂商锁定

供应商锁定描述了当您让供应商完全控制您的操作时的情况。因此，对业务逻辑的更改是有限的，从一个供应商到另一个供应商的迁移可能具有挑战性。

不适用于长期任务

无服务器模式不适合长期运行。无服务器应用程序适用于短时间的实时进程，但如果任务耗时超过五分钟，则无服务器应用程序将需要额外的FaaS功能。

底线

Serverless软件体系结构有利于完成一次性任务和辅助过程。它适用于客户端密集型应用程序和快速增长且需要无限扩展的应用程序。

最后，让我们看下图，了解何时选择这四种体系结构类型：

原文地址：https://rubygarage.org/blog/monolith-soa-microservices-serverless