OTUS在11月启动了一个新的教育计划“软件架构师” ，为此，我们继续为该课程的未来学生和博客读者提供一系列出版物。
阅读第一部分
微服务架构
微服务是一种面向服务的软件体系结构，其重点是创建许多组成应用程序的独立组件。 与整体创建的单片应用程序不同，微服务应用程序由几个独立的组件组成，这些组件通过API粘合在一起。
微服务的结构与整体架构的比较微服务方法主要关注业务优先级和机会，而整体方法则围绕技术级别，用户界面和数据库进行组织。 随着越来越多的企业变得更加灵活并转向DevOps，微服务方法已成为近年来的趋势。
微服务之所以重要，仅仅是因为它们通过简化系统来增加独特的客户价值。 通过将系统或应用程序分解为许多较小的部分，您正在实现一种减少重复，增加一致性并减少各部分之间的通信的方法，这使您的系统公用部分更加易于理解，更具可伸缩性并且更易于更改。
微服务的作者Lucas Kraus
有许多公司的例子，这些公司已经从单一方法演变为微服务。 其中最著名的是Netflix，Amazon，Twitter，eBay和PayPal。 为了确定微服务是否适合您的项目，让我们确定这种方法的优缺点。
微服务的优点
易于开发，测试和部署
微服务相对于其他体系结构的最大优势是可以独立创建，测试和部署小型单个服务。 由于部署单元很小，因此使开发和发布更加容易和快捷。 另外，一个单元的发布不限于另一单元的发布，而该单元尚未完成。 最后的好处是，随着开发人员发布部分软件而非整个应用程序，部署风险得以降低。
增加灵活性
在微服务的帮助下，多个团队可以独立快速地开展服务。 由于隔离了微服务组件，因此可以独立构建应用程序的每个单独部分。 例如，您可能有一个由100个人组成的团队在整个应用程序上工作（就像在整体方法中一样），或者您可能有10个由10个人组成的团队来开发各种服务。
让我们从视觉上想象它。
更高的灵活性允许开发人员在不关闭应用程序的情况下更新系统组件。 另外，灵活性提供了更安全的部署过程并增加了正常运行时间。 可以根据需要添加新功能，而无需等待整个应用程序启动。
水平缩放的能力
垂直扩展（使用相同的软件，但在功能更强大的计算机上）可能会受到每个服务带宽的限制。 但是水平扩展（在一个池中创建更多服务）不受限制，并且可以动态地与微服务一起使用。 此外，水平缩放可以完全自动化。
微服务的缺点
难点
微服务的最大缺点是它们的复杂性。 将应用程序分为独立的微服务需要更多的控制工件。 这种类型的体系结构需要仔细的计划，巨大的努力，团队资源和技能。 高度复杂的原因如下：
- 对自动化的需求增加，因为必须检查和控制每项服务
- 可用工具不适用于服务依赖项
- 由于每个服务都有一个数据库，因此数据一致性和事务管理变得越来越困难
安全问题
在微服务应用程序中，从外部通过API进行交互的每个功能都会增加遭受攻击的可能性。 只有在创建应用程序时未采取适当的安全措施，才会发生这些攻击。
不同的编程语言
选择不同编程语言的能力是一把双刃剑。 使用不同的语言会使部署复杂化。 另外，当每个服务都以不同的语言编写时，在开发阶段之间切换程序员会更加困难。
最后
微服务很好，但不适用于所有类型的应用程序。 该模板非常适合开发应用程序和复杂的系统。 当您拥有多个经验丰富的团队并且应用程序足够复杂以将其分解为服务时，您可以考虑选择微服务架构。 当应用程序很大并且需要灵活和可扩展时，微服务体系结构将是有益的。
现在，我们可以比较这三种软件体系结构，以直观地识别它们之间的差异。
整体应用程序由相互依赖，不可分割的块组成，并且开发速度非常低。 SOA分解为较小的，适度相关的服务，并且发展缓慢。 微服务是非常小的，松散耦合的独立服务，其特征是快速开发和持续集成。
无服务器架构
无服务器架构是一种无需构建基础架构即可构建和运行应用程序和服务的云计算方法。 在无服务器应用程序中，代码执行是平台驱动的，允许开发人员部署代码而不必担心服务器的维护和维护。 实际上，无服务器并不意味着“没有服务器”。 该应用程序仍在服务器上运行，但是第三方云服务（例如AWS）完全负责这些服务器。 无服务器架构消除了对额外资源，应用程序扩展，服务器维护以及存储和数据库系统的需求。
无服务器架构包括两个概念：
- FaaS（功能即服务）是一种云计算模型，允许开发人员将部分功能上载到云中并允许这些部分独立执行
- BaaS（后端即服务）是一种云计算模型，允许开发人员外包后端方面（数据库管理，云存储，托管，用户身份验证等），以及仅编写和支持一部分外部接口。
这是无服务器结构的样子使用无服务器架构，开发人员可以专注于产品本身，而不必担心服务器管理或运行时。 这使开发人员可以专注于开发具有高可靠性和可扩展性的产品。
市场上有许多云解决方案提供商。 以下是一些领先的无服务器计算提供商：
领先的无服务器计算提供商为了确定您的项目是否需要这种类型的体系结构，让我们确定在没有服务器的情况下实现模型的优缺点。
无服务器架构的优点
易于部署
在无服务器应用程序中，开发人员无需担心基础架构。 这使他们可以专注于代码本身。 无服务器架构允许您快速部署应用程序，因为部署只需要几个小时或几天（而传统方法则需要数天或数周）。
降低成本
转向无服务器架构可降低成本。 由于不需要处理数据库，某些逻辑和服务器，因此不仅可以创建更好的代码，还可以降低成本。 当使用不带服务器的模型时，只需支付实际使用的CPU周期和内存。
增强的可扩展性
许多企业主希望他们的应用程序功能强大且可扩展，例如Google或Facebook。 无服务器计算使扩展自动且顺畅。 当负载或用户群增加时，您的应用程序将自动扩展，而不会影响性能。 无服务器应用程序可以处理大量请求，而传统应用程序会因其突然增加而过载。
无服务器架构的缺点
供应商绑定
供应商绑定描述了一种情况，您可以让供应商完全控制您的操作。 结果，业务逻辑的变化受到限制，并且从一个提供商到另一个提供商的迁移可能很困难。
不适用于长期任务。
无服务器模型不适合长时间运行。 无服务器应用程序对于实时的短流程很有用，但是如果任务耗时超过五分钟，则无服务器应用程序将需要其他FaaS功能。
最后
无服务器软件体系结构对于解决一次性任务和支持流程很有用。 它非常适合客户丰富的应用程序以及快速增长且需要无限扩展的应用程序。
最后，让我们看一下下图，找出何时选择这四种类型的体系结构中的每一种：
为您的MVP选择正确的架构具有挑战性，但是RubyGarage拥有多年的经验，可以帮助您进行选择。 本文的作者将很高兴回答您关于此主题的所有问题。