微服务治理与API管理

发布时间：2025-11-05 11:53:11 来源：云智核 作者：应用开发

【.com快译】

引言

从管理学上说，微服务治治理的管理定义是：“将人员、流程和技术联系起来，微服务治为利益相关者创造价值。管理”如下图所示，微服务治IT治理的管理流程会与企业IT生态系统中的三个主要部分持续进行交互。

IT治理的微服务治组成

人员

这包括具有各种技能的角色，如：开发人员、管理架构师、微服务治业务分析师、管理CXO、微服务治以及参与IT服务交付过程的管理利益相关者。从需求识别到通过IT生态系统最终交付业务功能，微服务治这些不同的管理角色都会与基础流程及技术进行交互，并通过不同的微服务治权限集，来实现治理模型，进而维持稳定性、完整性和问责制。

流程

流程包括策略、标准、最佳实践、以及角色管理等。在利用技术来交付IT服务时，人员必须遵守各种流程。在微服务的网站模板语境中，流程是以单个团队为中心，通过集中式控制平台来进行控制的。

技术

主要涉及到开发、测试、部署和交付服务等实际工作。人员使用技术组件，在流程的管理下，为关键利益相关者带来价值。

可见，适当的治理模型就是要：通过问责制和透明性，向利益相关者(如：消费者、合作伙伴)交付价值。如果我们分析大多数失败的IT项目，就会发现：其中最常见的失败原因之一便是缺乏治理。

微服务与治理

从概念上说，微服务架构是指：由团队独立开发、部署和管理的软件开发实践。此类服务具有独立性，并且能够满足特定的业务目的。而微服务治理则是WordPress模板一个过程。它可以帮助人员管理微服务的开发，并将关键性成果交付给业务方。也就是说，它可以帮助企业通过既定的策略和标准，使其业务目标与微服务计划保持一致。

人们往往错误地认为：让微服务开发团队遵守各种流程和策略，可能会阻碍整体的创新和交付速度。但实际上，它是通过集中式控制平台的分布式治理，引入适当的流程顺序。而且，当组织规模不断壮大，并且需要交付100多种不同的微服务时，流程和策略的作用就更加显著了。

微服务治理和业务目标

上图展示了微服务团队、治理和业务需求三者的关键特征，以及在为微服务构建治理框架时的相互联系。

微服务团队

微服务架构允许团队在开发和交付服务时拥有自主权。他们可以选择自己的运行时、语言、亿华云工具和流程。不过，我们在确定服务需求的过程中，需要分拆现有的团队，以便他们能够独立工作。同时，这也是微服务治理的起点。通过团队的拆分，业务分析师、架构师和一些开发人员将会组成集中式的管理团队。

图片来源：https://medium.com/ibm-garage/microservices-technical-governance-f5aed10189d1

一旦确立了微服务团队，并提交了要实施的规范，他们就需要准备合适的工具、流程和技术，以满足预期的交付结果。而且，这些都需要与总体业务目标保持一致。

业务目标

微服务团队与治理控制平台的交互

不同的业务往往有着不同的目标，其中包括：企业愿景、上市时间(交付速度)、投资回报、总体拥有成本等方面。如上图所示，假设我们的企业在不同时间拥有四个不同的微服务团队，他们提供着不同类型的服务，并通过与治理控制平台的交互，确保其行为符合业务的标准和需求。也就是说，他们在开发各种服务功能时，可以根据最高质量服务的需要，针对如下方面采用不同的方法，来执行各种任务。

他们在与治理控制平台的交互过程中，持续验证方法的有效性，并通过记录以备将来的参考，进而在组织内广泛共享。

同时，治理控制平台需要通过公开API，提供用户界面，实现对如下方面的治理：

微服务治理的两种生命周期

上图是常见的两种生命周期。左侧常被用于将一个想法转化为概念，然后从一个微服务团队中分离出来，将其作为新的服务予以开发，并最终交付给使用者(consumer)。该生命周期可以用来证明微服务团队的某个想法的可行性和价值，以便团队无论使用何种技术，都能拿去重用。

右侧是一个典型的软件生命周期，其中涉及到：设计、实施、测试阶段、以及外部使用者能够访问到的开发者门户(作为托管API进行部署和发布)。据此，微服务团队可以实现CI/CD管道，并自动遍历整个生命周期。通过API与治理平台的集成，微服务能够确保在进入生产环境之前，及时跟踪每个发行版，并实时传递各种所需的管理要求。

不同的团队也许会在其开发生命周期中表现出不同的特征与阶段。但是，凭借着集中式控制平台，架构师可以持续比较不同的生命周期，并根据每个团队的经验，提出相应的改进建议。

微服务治理的参考架构

有了前面的基础知识，下面我们来讨论微服务治理的参考架构。

微服务治理的参考架构

技术组成

在上图中，上半部分是一个生产环境，其中部署了具有多个副本的各种微服务。为了简单起见，上图省略了诸如：安全令牌、服务网格、消息代理等组件。图中也展示了一个“历史遗留”服务，这往往是企业架构中不容忽视的部分。图中下半部分则展示了微服务在开发和测试阶段、以及运行时，所使用到的各种基础技术组件。在治理过程中，我们往往需要在“信任但验证(trust but verify)”模型中管理各种技术组件。

人员

上图也展示了人员在基于微服务的开发过程中，所扮演的具有不同权限的不同角色。例如：开发人员需要获得测试人员的批准，方可将其代码移至生产环境。因此，从最初的设计阶段，到最终的退役阶段，各个团队成员需持续与治理平台进行交互，以提供与业务目标相一致的服务，并给用户提供最佳体验。

存储与编录

一个具有多层架构的典型企业部署往往包含：后端、中间件、API、以及前端等不同类型的服务。通常，开发者门户只能将API的详细信息提供给使用者，却无法存储其他类型的服务。治理平台的主要功能就是将诸如：搜索、浏览、发现、分类、依赖关系分析之类的功能与服务，予以保存并实现复用。

服务发现

运行时的服务发现是基于微服务的自包含(self-contained)与面向服务(service-oriented)的多层架构模型中的重要部分。我们在不同的环境中，部署不同的功能服务时，往往需要更改服务的实际URL。因此，我们可以使用通用参考作为“键(key)”，通过服务发现功能，将其映射为“值(value)”，进而降低环境中服务管理的复杂性。

通过API进行交互

一些团队可能会更喜欢通过编程的方式，去访问治理的相关功能，以便自行构建自动化的管道和交付服务。对此，治理平台需要通过预定义API的方式，来公开各种必需的功能，以便团队使用基于客户端能力的OAuth2、或基本的身份验证机制，实现与平台之间的安全交互。

通过WSO2来实施微服务治理

下面，我们来看看如何使用开源软件栈--WSO2，让前面讨论的治理架构能够凭借软件工具实现“落地”。

通过WSO2来实施微服务治理

如上图所示，我们可以使用多种技术来实现不同领域的微服务，其中包括：

此外，前文提到了一些可能无法用微服务代替的“历史遗留服务”(如：SOAP、XML、SAP、FIX、JMS等)，我们可以利用如下基础工具和技术，与整个生态系统相集成，并为最终用户提供价值。

下面，我们将从设计时管理和运行时管理，两个方面探讨针对目标生态系统的治理。

设计时(Design Time)治理

如前所述，治理涉及到生命周期的管理、策略、标准、最佳实践、以及可重用性。不同的微服务团队可以拥有自己的生命周期定义、状态转移、以及用户角色。WSO2数字资产治理方案，能够让团队自定义生命周期，并将其添加到对应的服务中，以确保每个成员都会遵循那些业务所能够接受的行业最佳实践。例如，如果业界最佳实践是将开放的API规范作用在API的定义上，那么每个微服务团队都必须遵循此类标准。同时，团队也应该有权选择在开发中，将会用到的编程语言和库。

设计时治理的另一个关键方面是可重用性。WSO2治理方案通过提供存储库，以便用户检索和浏览现有的服务，进而实现重用。据此，我们不但可以减少整体的上市时间，还能够减少团队在重复性工作上浪费的时间。

在管理服务的生命周期时，我们有时需要权衡是否需要弃用某种服务。WSO2治理方案可以帮助用户分析给定的服务(或资产)对于其他类似对象的影响。

在API的开发方面，WSO2 API Manager附带有API Publisher和Developer门户，可提供对于API(和API代理)的生命周期管理和存储库功能。它能够供那些在各自交付渠道(如：移动设备或Web应用程序方式)中用到该API的内、外部开发人员的调用。通过与WSO2 API Manager的集成，WSO2数字资产治理方案可以实现在治理平台上完成API的设计，并将其推送到API的管理层。

运行时(Runtime)治理

运行时治理通过API来处理服务与治理平台的运行时交互，以发现平台上的目标资产。例如，在使用WSO2 EI开发的典型集成中，我们可以将端点的名称指定为诸如“HospitalEP”之类的固定值。不过，该值的实际URL会根据不同环境(如：DEV、UAT、PROD)而有所差异。治理平台可以实现端点名称到URL的运行时映射，并解析URL的存储值。此功能通常被称为“服务发现”，也就是说，运行时通过调用管理平台，来发现服务的实际URL。

此外，治理平台还会公开一组REST API，并以编程的方式执行各种由设计时治理所产生的功能。这些API能够让微服务团队将自动化部署，与治理平台的生命周期管理相集成。值得注意的是，在将特定的服务部署到生产环境之前，我们需要进行人工检查，以确保符合“信任但验证”的策略。

当服务发生更改时，运行时治理需要向相关各方发送实时通知(如：电子邮件等)。例如，如果服务从实现状态过渡到了发布状态，那么平台就会自动通知用户(或前一个版本的用户)，以便用户能够立刻从中受益。同理，如果资产被删除，此类通知也能让相关人员及时采取安全措施。

治理平台的安全性

治理的一个关键方面是：平台上目标资产(或服务)的安全性。我们既可以将用户信息保持在LDAP和AD之类的企业级用户存储库中，也可以将其连接到治理平台的自有数据库上，并根据微服务团队的需求和公司的整体要求，定义角色并分配相应的权限集。例如：具有开发者角色的用户无法将服务的生命周期，从实现状态更改为发布状态，而必须由具有产品经理角色的用户，在验证了必要的详细信息之后，方可执行此类操作。同样，如果需要在逻辑上隔离不同业务部门之间的资产，那么我们也可以创建多个租户，并赋权他们维护各自的资源库，而不会受到其他团队的干扰。

微服务治理和API管理

目前，业界在微服务治理方面的一个最大误解是认为：API管理平台可以通过其API发布工具和开发者门户来治理微服务。而事实上，只有当某个后端微服务团队决定利用API管理平台，将其微服务公开给其他组件上时，平台才会开始使用那些与API有关的生命周期、标准和策略，与微服务进行交互。也就是说，它无法提供在API开发之前所需的管理功能。对此，人们倾向于将平台扩展到API生命周期之外，含括后端微服务的“设计”、“审阅”、“实施”等阶段。

不过，即使在API平台上公开了所有微服务，这些平台也无法处理有关微服务开发的治理问题(API代理部分除外)。对此，最好的解决方案是：在微服务治理平台和API管理平台之间架起一座桥梁，让API管理成为微服务治理的扩展。

微服务治理和API管理的集成

如上图所示，微服务治理捕获了独立于API开发的周期过程。在一个瀑布式的开发模型中，微服务团队会负责微服务的实现和API的开发。这样很好地促进了两者的“桥接”。

在大多数情况下，当定义了API接口后，微服务开发和API开发这两项任务就可以并行开展，而无需相互等待了。这就是我们经常听到的所谓“API优先(API first)”的开发方法。如上图所示，架构师将定义API并作为生命周期的初始输出，然后分拆给两个微服务团队，分别进行后端实现的开发，以及API创建等相关活动。

此外，API管理平台通常会在微服务之外创建API代理，并向运行时架构添加另一个组件。当然，并非每个微服务都需要如此。微服务团队使用诸如服务网格之类的技术，让其微服务的内部已经具有了QoS，而且只需要将其元数据发布给其他用户，因此无需在现有的服务上，引入任何其他的运行时。此外，API管理平台也无法使用诸如依赖关系分析等功能，来识别给定服务与生态系统中其他部分的关系，毕竟它只关注特定的API及其相关的端点。

API管理和微服务治理

如上图所示，API管理平台在微服务开发流程上为治理平台提供了补充，实现了对微服务架构的端到端治理，进而通过流程的管控优势，为企业和使用者带来实际价值。

参考文献

【原标题】Microservices Governance and API Management (作者: Chanaka Fernando)

【译稿，合作站点转载请注明原文译者和出处为.com】

相关文章