软件架构是软件系统开发和实现的高级结构。随着软件变得越来越普及和普遍，不同的架构风格必然会演变。在这样拥挤的领域中，微服务架构获得了大量的关注和重要性。让我们深入了解微服务、它们如何通过 API 进行通信，以及 Swagger 和 SwaggerHub 等工具如何提供帮助。
什么是微服务？
微服务——也称为微服务架构——是一种架构风格，它将应用程序构建为一组松散耦合的服务集合，每个服务都实现业务能力。微服务架构能够持续交付和部署大型、复杂的应用程序。它还使组织能够随着时间的推移发展其技术栈、进行扩展并更具弹性。 微服务架构倡导将单个应用程序开发为一组松散关联的服务集合。这些单元还可以在最小化中心化的需求下，实现大型、单体应用程序的持续交付和部署。 
（图片来源：NGINX 博客）
为什么选择微服务？
要理解微服务的流行，重要的是要了解单体应用程序。任何应用程序都将由客户端界面、用于存储和处理数据的数据库以及服务器端逻辑组成。单体应用程序是作为一个单一单元构建的。在单体应用程序中，服务器端逻辑以一个单体的形式捆绑在一起，所有处理请求的逻辑都在一个进程中运行。对该系统的所有更新都将涉及部署一个新版本的服务器端应用程序。 虽然市场上有成千上万成功的基于单体的应用程序，但开发团队开始感受到这种大规模部署操作的冲击。例如，在单体应用程序中，任何小的修改都与整个变更周期相关联，而这些周期又总是相互关联的。特定功能和模块的细粒度扩展也是不可能的，因为团队必须扩展整个应用程序。 
（图片来源：martinfowler.com）
为了克服管理、更新和部署应用程序，尤其是在云上部署应用程序日益增长的复杂性，微服务架构的采用开始普及。每个微服务定义一个特定的业务功能，并且只定义与该功能相关的操作，这使得它们非常轻量和便携。微服务可以部署并在更小的宿主机中运行，并且不必使用传统架构的 RAM 和 CPU 资源。这些操作也可以根据用例使用不同的语言开发，因此一个消息板服务可以用 Ruby 构建，而将它们交付给不同用户的服务可以在 Node 上构建。 上述所有因素都促成了基于微服务的架构的大规模采用，其中最突出的例子是 Netflix。
这是 SOA 吗？
在应用程序中逻辑分离功能单元并非新概念。最常见的比较形式是微服务与面向服务架构（SOA）之间的比较。我不会对此深入探讨，但足以说明微服务和 SOA 在许多方面存在差异。SOA 在接口层面工作，旨在将功能暴露为服务接口。这些接口使得在下一代应用程序中更容易使用它们的数据和操作。SOA 的范围围绕应用程序之间的接口标准化，而微服务具有应用程序层面的范围。
微服务的缺点
与任何架构风格一样，微服务也可能存在一些缺点。一个大问题是将应用程序的整个业务能力分解为多个细粒度单元，这使得子业务单元之间的界限难以划分且棘手。定义不清的边界可能对应用程序的扩展产生负面影响。此外，在不同服务之间重用代码也可能很困难，尤其是在使用不同语言构建时。 跟踪运行各种服务的宿主机可能很繁琐，并可能导致大量混乱和资源消耗，以试图将这些各种组件协调起来。微服务架构也需要技术技能才能有效实现，对于习惯传统应用程序工程形式的开发人员来说，这是一个巨大的转变。
容器如何提供帮助？
微服务架构的采用促使人们需要克服其一些缺点。这推动了容器生态系统的兴起。容器是一种操作系统服务虚拟化的形式，它允许各种服务在资源独立的单元中运行。Linux 容器利用了内核接口。内核是操作系统的核心计算机程序，也是启动时加载的第一个程序。 
（图片来源：维基百科）
容器的配置允许多个容器共享同一个内核，同时并行运行，彼此之间完全独立。操作系统虚拟化使得代码的传输和部署效率更高，甚至比只虚拟化硬件的传统虚拟机更高。Docker是最流行的容器技术，并在很短的时间内成为数千个应用程序中使用的标准基于 Linux 内核的容器。 同一宿主机上容器之间的独立性使得部署基于不同技术和框架构建的微服务变得非常简单直接。容器的可移植性和轻量化也是微服务部署的优点。 为了解决微服务管理问题，各种容器管理系统应运而生，以便更好地管理和协调这些容器，以及配置和管理整个集群服务器。这里有一篇很棒的帖子比较了几种流行的容器管理系统。
API 的作用
我们知道微服务是构成大型应用程序的独立维护组件。我们也知道容器是部署它们的好方法。微服务和容器使用进程间通信（IPC）机制相互交互。这些交互可以是：
- 一对一：客户端请求由一个服务处理
- 一对多：客户端请求由多个服务处理
如果 IPC 机制涉及请求-响应循环，那么最常见的通信方式是 RESTful，它们几乎总是使用 HTTP/JSON API。微服务之间用作 IPC 的 API 与传统形式不同。这些 API 更具粒度。由于暴露微服务的 API 暴露细粒度数据，客户端可能需要遵循服务之间的一对多交互形式来获取所需数据。 
（图片来源：IBM developerWorks）
例如，假设您正在构建一个遵循微服务模式的电子商务网站。一个在售商品的完整信息可以通过多个服务来呈现，例如：一个服务用于暴露基本商品信息（如标题和描述），一个服务用于暴露价格，一个服务用于导出评论，等等。希望获取商品完整数据的客户端现在必须调用所有这些服务。在多设备生态系统中，不同的设备可能需要不同的数据，例如桌面应用程序可能比移动版本需要更详细的数据。
微服务的“设计优先”方法
我们已经讨论了 API 如何成为各种服务之间最常见的通信方式。为了更好地通过 API 暴露服务，这些 API 需要有一个通用接口来准确说明每个服务应该做什么。此接口是定义客户端和服务之间 SLA 的契约。OpenAPI (Swagger) 规范已成为定义此契约的标准格式，它既可人工阅读又可机器阅读，使得服务更容易有效通信并协调整个应用程序。 微服务架构主要是一种企业级趋势，因此，重要的是要优先处理暴露微服务数据的 API。许多组织已采用“设计优先”方法来构建微服务，这包括首先设计和定义微服务的接口，审查和稳定此契约，然后才实现服务。“设计优先”方法确保您的服务在任何实际开发发生之前，就符合客户端的要求。 以下是采用 API 的“设计优先”（或“API 优先”）方法的一些关键考虑因素：
上市速度
就其性质而言，微服务是内部的，旨在具有最小的计算能力和使用时间。暴露它们的 API 也是如此。因此，自动化这些 API 的设计、文档和开发以实现快速 API 交付率至关重要。Swagger 接口不仅定义了客户端和服务之间的通用 SLA，它还允许生成服务器和客户端模板以及测试用例，从而使开发和测试过程更加容易。 像 SwaggerHub 这样的专业工具，它提供了一个用于智能设计的智能 API 编辑器，以及用于加速 API 设计交付的域，可以帮助您的 API 快速推向市场。
灵活编排
我们谈到了暴露微服务的 API 是粒度化和细粒度的，这意味着客户端应用程序需要特定实体的数据时，总是可能需要调用多个 API。处理基于微服务的应用程序的数据交换复杂性是一个巨大的问题。 处理多个服务请求的解决方案是实现一个 API 网关，它可以通过单一入口点处理请求。由于网关基础 API 契约上的每个 API 都定义在 OpenAPI/Swagger 规范中，因此通过 API 网关从设计阶段高效地过渡到部署阶段变得非常容易。SwaggerHub 与 AWS、Azure 和 IBM API Connect 等 API 网关的直接集成是专为希望高效编排这些请求的组织而设计的。
负责任的设计
多个团队构建不同的服务可能很棘手。不仅管理人力资源困难，当这些团队开始开发服务接口时，情况会变得更加复杂。当多个团队定义和构建 RESTful 接口时，URL 结构、响应头和请求-响应循环对象中设计模式的分歧是非常常见的。 由于接口定义了客户端和服务如何交互，设计上的差异会导致服务开发阶段的混乱和额外开销。修复这些问题只会导致时间、金钱和人力资本形式的资源消耗。 这可以通过使用 SwaggerHub 的两个核心设计功能来克服：域（Domains）和样式验证器（Style Validator）。样式验证器确保您的 RESTful 接口符合基于您的组织要求的标准蓝图。这可能意味着确保所有接口都具有驼峰式命名操作符、在响应包中定义示例，或者在本地定义其模型。 在域中，您可以存储通用、可重用的语法，无论是模型还是请求-响应对象，这些语法可以在暴露您的微服务业务能力的多个 API 中快速引用。这使您能够对 API 样式采取更细粒度的方法，为所有暴露您服务的 RESTful 设计提供一个控制中心。域和样式验证器是 SwaggerHub 独有的功能，可确保在构建服务 IPC 时保持设计一致性和快速上市时间。
网络研讨会：将企业转型为 API 平台的经验教训
您的数字化转型工作是否正带领您的业务走向正确的方向？4 月 10 日，我们将举办一场免费网络研讨会：将企业转型为 API 平台的经验教训。本次会议将重点探讨与酒店业、贷款发放和金融科技领域的各类组织合作，开发和部署其 API 平台所学到的经验教训。这些企业将 API 优先设计、联邦治理和 API 管理层作为其整体平台战略的一部分。我们将探讨哪些方法有效、哪些无效，以及简化您的转型举措的技巧。将讨论的主题包括：
- 开发有效的 API 项目，促进内部重用和蓬勃发展的合作伙伴计划
- 实施 API 治理的技术，包括集中式与联邦式治理的探讨
- 微服务和模块化软件设计如何改变当今企业的文化
- 通过开发出色的门户和开发者支持流程来提高 API 的入驻和采用率
- 以 API 为中心的企业方法加速转型举措的技巧
立即注册 