软件架构是用于开发和实现软件系统的高级结构。随着软件越来越普及和普遍，不同的架构风格必然会演变。在如此拥挤的街道上，微服务架构已经获得了大量的关注和相关性。让我们深入了解更多关于微服务、它们如何通过 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 的两个核心设计功能来克服：域和样式验证器。样式验证器可确保您的 RESTful 接口符合基于您的组织要求的标准蓝图。这可能意味着确保所有接口都具有驼峰式运算符，响应数据包中定义的示例，或者在本地定义其模型。 在域中，您可以存储通用的、可重用的语法，无论是模型还是请求-响应对象，这些语法都可以在多个公开您的微服务业务能力的 API 中快速引用。这使您可以对 API 样式采用更精细的方法，为所有公开您服务的 RESTful 设计提供一个控制中心。域和样式验证器是 SwaggerHub 独有的，可确保在构建您的服务 IPC 时设计一致性和快速上市时间。
网络研讨会：将企业转型为 API 平台的经验教训
您的数字化转型工作是否正在将您的业务引向正确的方向？4 月 10 日，我们将举办免费网络研讨会：将企业转型为 API 平台的经验教训。本次会议重点介绍在酒店、贷款发起和金融科技等各个组织中开发和部署其 API 平台的经验教训。这些企业实施了 API 优先设计、联合治理和 API 管理层，作为其整体平台战略的一部分。我们将探讨哪些有效，哪些无效，以及简化您的转型计划的技巧。将讨论的主题
- 开发有效的 API 计划，以促进内部重用和蓬勃发展的合作伙伴计划
- 实施 API 治理的技术，包括对集中式和联合式治理的探索
- 微服务和模块化软件设计如何改变当今企业的文化
- 通过开发出色的门户和开发人员支持流程来提高 API 的入职和采用率
- 使用以 API 为中心的企业方法加速您的转型计划的技巧
立即注册 