微服务治理与API管理

引言

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

专注于为中小企业提供成都网站制作、网站建设服务,电脑端+手机端+微信端的三站合一,更高效的管理,为中小企业蛟河免费做网站提供优质的服务。我们立足成都，凝聚了一批互联网行业人才，有力地推动了上1000家企业的稳健成长，帮助中小企业通过网站建设实现规模扩充和转变。

IT治理的组成

人员

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

流程

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

技术

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

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

微服务与治理

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

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

微服务治理和业务目标

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

微服务团队

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

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

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

业务目标

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

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

• 编程语言/运行时。
• 发布策略。
• 交付生命周期。
• 源代码管理工具。
• 团队成员数。
• 服务类别。

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

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

• 生命周期管理 — 每个团队可以有自己的不同生命周期阶段(stages)、过渡(transitions)、以及各自的角色。这些细节将通过治理控制平台被捕获和治理。同时，此类交互既可以是手动的，也可以通过治理层所公开的API来实现。
• 服务存储库和可重用性 — 当团队使用基于域的设计，来开发新的微服务时，需要仔细研究现有的微服务集，以避免在功能上的重叠，以及重复分配资源。治理层的服务存储库可以实现可重用性，并提高系统的整体效率。
• 标准/政策 - 尽管每个团队都可以决定技术、发布模型、生命周期，但是我们应当采用一种通用的机制，来通过标准和政策，去定义开发过程的各个方面。例如：如果需要在组织级别上获得诸如HIPPA、FEDRAMP之类的认证，那么所有不同的团队都必须遵守该标准。
• 最佳实践 - 在生命周期中，团队有责任根据自己的技术选择，在治理级别上发布这些最佳实践，以切合业务目标。
• 依赖关系分析 — 随着业务的持续蓬勃发展，企业会将越来越多的微服务添加到其生态系统中。在此，依赖关系分析可以帮助我们可视化各种资产类型之间的复杂依赖关系，其中包括：微服务团队、服务URL、角色、以及其他资源等。
• 监控/审计 — 微服务团队需要通过治理平台的审核和监控机制，来对失败的项目进行回顾，进而从错误中总结学习。

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

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

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

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

微服务治理的参考架构

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

微服务治理的参考架构

技术组成

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

人员

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

存储与编录

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

服务发现

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

通过API进行交互

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

通过WSO2来实施微服务治理

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

通过WSO2来实施微服务治理

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

• 前端应用程序 – Javascript、React、Angular
• API网关 — WSO2 API Manager、Microgateway
• 集成服务 — WSO2 Enterprise Integrator、Micro Integrator
• 后端业务服务 - Spring Boot、Golang、.Net
• API开发者门户 — WSO2 API Manager开发者门户

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

• 基础架构 – AWS、Azure、VM或物理硬件
• 容器运行时 – Docker、rkt
• 语言运行时 — JDK、.Net框架、Node
• 持续集成工具 – Jenkins、TravisCI，、CircleCI
• 源代码管理工具 – GitHub、GitLab
• 测试自动化工具 – Selenium、Newman、SOAPUI
• 设计/实施工具 – IDE、VSCode

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

设计时(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管理平台在微服务开发流程上为治理平台提供了补充，实现了对微服务架构的端到端治理，进而通过流程的管控优势，为企业和使用者带来实际价值。

参考文献

• https://www.wipro.com/blogs/dr-gopala-krishna-behara/microservices-governance/
• https://www.leanix.net/cn/blog/microservices-governance
• https://dzone.com/articles/efficient-enterprise-microservice-governance
• https://wso2.com/whitepapers/microservices-in-practice-key-architectural-concepts-of-an-msa/
• https://medium.com/ibm-garage/microservices-technical-governance-f5aed10189d1

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

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

分享标题：微服务治理与API管理
分享地址：http://www.shufengxianlan.com/qtweb/news1/501501.html

网站建设、网络推广公司-创新互联，是专注品牌与效果的网站制作，网络营销seo公司；服务项目有等

广告

声明：本网站发布的内容（图片、视频和文字）以用户投稿、用户转载内容为主，如果涉及侵权请尽快告知，我们将会在第一时间删除。文章观点不代表本网站立场，如需处理请联系客服。电话：028-86922220；邮箱：631063699@qq.com。内容未经允许不得转载，或转载时需注明来源： 创新互联