【.com速译】简介从管理的角度，治理的定义是：“连接人、流程和技术，为利益相关者创造价值”。如下图所示，IT治理流程不断与企业IT生态系统的三个主要组件进行交互。IT治理的组成部分这包括具有各种技能组合的角色，例如：开发人员、架构师、业务分析师、CXO以及参与IT服务交付流程的利益相关者。从需求识别到通过IT生态系统最终交付业务功能，这些不同的角色将与底层流程和技术交互，并通过不同的权限集实施治理模型，以保持稳定性、完整性和问责制。流程流程包括政策、标准、最佳实践和角色管理。在利用技术提供IT服务时，人们必须遵循各种流程。在微服务的背景下，流程以单个团队为中心，并通过集中控制平台进行控制。技术主要涉及开发、测试、部署和交付服务的实际工作。人们使用由流程管理的技术组件来为关键利益相关者提供价值。可以看出，适当的治理模型是通过问责制和透明度向利益相关者（例如，消费者、合作伙伴）交付价值。如果我们分析大多数失败的IT项目，失败的最常见原因之一是缺乏治理。微服务和治理从概念上讲，微服务架构是指由团队独立开发、部署和管理的软件开发实践。此类服务是独立的，服务于特定的业务目的。微服务治理是一个过程。它可以帮助人们管理微服务的开发，并将关键结果交付给业务方。也就是说，它可以帮助组织通过既定的策略和标准使他们的业务目标与微服务计划保持一致。有一个普遍的误解，认为让微服务开发团队遵守各种流程和政策会阻碍整体创新和交付速度。但实际上，它是通过集中控制平台进行分布式治理，引入适当的流程顺序。而且，当组织规模扩大并需要交付100种不同的微服务时，流程和策略的作用就更加重要。微服务治理和业务目标上图显示了微服务团队、治理和业务需求的主要特征，以及它们在构建微服务治理框架时的相互关系。微服务团队微服务架构允许团队在开发和交付服务方面拥有自主权。他们可以选择自己的运行时、语言、工具和流程。但是，在确定服务需求的过程中，我们需要将现有的团队打散，让他们独立工作。同时，这也是微服务治理的出发点。通过团队拆分，业务分析师、架构师和部分开发人员将组成一个集中管理的团队。图片来源：https://medium.com/ibm-garage/microservices-technical-governance-f5aed10189d1一旦微服务团队成立并提交实施规范，他们需要准备适当的工具、流程和技术以满足预期交付结果。而且，这些需要与总体业务目标保持一致。业务目标微服务团队与治理控制平台的交互不同的业务往往有不同的目标，包括：企业愿景、上市时间（交付速度）、投资回报率、总拥有成本等。如上图所示，假设我们的企业在不同的时间有四个不同的微服务团队，他们提供不同类型的服务，并与治理控制平台交互，确保他们的行为符合业务的标准和需求。也就是说，他们在开发各种服务功能时，可以根据对以下几个方面最优质服务的需求，采用不同的方法来完成各种任务。编程语言/运行时。发布策略。交付生命周期。源代码管理工具。团队成员人数。服务类型。他们与治理控制平台的交互不断验证该方法的有效性，并通过记录它以供将来参考在整个组织中广泛共享。同时，治理控制平台需要暴露API并提供用户界面以实现以下方面的治理：生命周期管理——每个团队可以有自己不同的生命周期阶段、过渡和自己的角色。这些细节将通过治理控制平台进行捕获和治理。同时，此类交互可以是手动的，也可以通过治理层公开的API进行。服务存储库和可重用性——当团队使用基于域的设计开发新的微服务时，他们需要仔细研究现有的微服务集，以避免功能重叠和资源重复分配。治理层的服务存储库支持可重用性并提高系统的整体效率。标准/策略——虽然每个团队都可以决定技术、发布模型和生命周期，但应该有一个通用机制来通过标准和策略定义开发过程的所有方面。例如：如果组织级别需要HIPPA、FEDRAMP等认证，那么所有不同的团队都必须遵守该标准。最佳实践——在生命周期中，团队有责任根据他们的技术选择在治理级别发布这些最佳实践，以与业务目标保持一致。依赖分析——随着业务的不断发展，企业向其生态系统中添加了越来越多的微服务。在这里，依赖分析帮助我们可视化各种资产类型之间的复杂依赖关系，包括：微服务团队、服务URL、角色和其他资源。监控/审计——微服务团队需要通过治理平台的审查和监控机制来审查失败的项目，然后从错误中吸取教训。微服务治理的两种生命周期上图展示了两种常见的生命周期。左边经常用来把一个想法变成一个概念，然后从一个微服务团队中分离出来，开发成一个新的服务，最后交付给消费者。这个生命周期可以用来证明微服务团队的想法的可行性和价值，这样无论团队使用什么技术，它都可以被重用。右侧是典型的软件生命周期，涉及：设计、实施、测试阶段，以及可供外部消费者访问的开发人员门户（作为托管API部署和发布）。相应地，微服务团队可以实现CI/CD管道并自动遍历整个生命周期。通过API和治理平台的集成，微服务可以确保在进入生产环境之前及时跟踪每个发布并实时沟通各种所需的管理需求。不同的团队在其开发生命周期中可能表现出不同的特征和阶段。然而，通过集中控制平面，架构师可以不断比较不同的生命周期，并根据每个团队的经验提出改进建议。微服务治理的参考架构有了前面的基础知识，我们来探讨一下微服务治理的参考架构。微服务治理参考架构的技术构成如上图所示。上半部分是生产环境，部署了各种多副本的微服务。为简单起见，上图省略了安全令牌、服务网格、消息代理等组件。该图还显示了“遗留”服务，这通常是企业架构中不可忽视的部分。图的下半部分展示了微服务在开发和测试阶段以及运行时使用的各种基础技术组件。在治理过程中，我们经常需要以“信任但验证”的模型来管理各种技术组件。人员上图也展示了人员在基于微服务的开发过程中不同权限扮演的不同角色。例如：开发人员在将代码移至生产环境之前需要得到测试人员的批准。因此，从最初的设计阶段到最后的退役阶段，每个团队成员都需要与治理平台持续交互，提供与业务目标一致的服务，为用户提供最佳体验。存储和编目具有多层架构的典型企业部署通常包括不同类型的服务，例如后端、中间件、API和前端。通常，开发人员门户只能向消费者提供API详细信息，而不能存储其他类型的服务。治理平台的主要功能是保存和复用搜索、浏览、发现、分类、依赖分析等功能和服务。服务发现运行时的服务发现是基于微服务的自包含和面向服务的多层架构模型的重要组成部分。当我们在不同的环境中部署不同的功能服务时，往往需要更改服务的实际URL。因此，我们可以将一个共同的引用作为“键”，通过服务发现功能将其映射为一个“值”，从而降低环境中服务管理的复杂度。通过API进行交互有些团队可能更喜欢以编程方式访问与治理相关的功能，以便构建自动化管道并自行交付服务。对此，治理平台需要通过预定义的API来暴露各种必要的功能，以便团队可以使用基于客户端能力的OAuth2或基本的认证机制来实现与平台的安全交互。通过WSO2实现微服务治理接下来我们就来看看如何使用开源软件栈——WSO2，让上面讨论的治理结构可以用软件工具“落地”。通过WSO2实现微服务治理如上图所示，我们可以在不同领域使用多种技术实现微服务，包括：前端应用——Javascript、React、AngularAPI网关——WSO2APIManager、MicrogatewayIntegrationservices——WSO2EnterpriseIntegrator,MicroIntegratorBackendBusinessServices-SpringBoot,Golang,.NetAPIDeveloperPortal-WSO2APIManagerDeveloperPortal另外，上一篇文章提到了一些可能无法被微服务取代的“遗留服务”（比如：SOAP，XML、SAP、FIX、JMS等），我们可以使用以下基础工具和技术与整个生态系统进行整合，为终端用户提供价值。基础设施–AWS、Azure、VM或物理硬件容器运行时–Docker、rkt语言运行时–JDK、.NetFramework、Node持续集成工具–Jenkins、TravisCI、CircleCI源代码管理工具–GitHub、GitLab测试自动化工具–Selenium、Newman,SOAPUI设计/实现工具——IDE、VSCode接下来，我们将从设计时管理和运行时管理两个方面来讨论目标生态系统的治理。设计时治理如前所述，治理涉及生命周期管理、策略、标准、最佳实践和可重用性。不同的微服务团队可以有自己的生命周期定义、状态转换和用户角色。WSO2数字资产治理解决方案允许团队自定义生命周期并将其添加到相应的服务中，以确保每个成员都遵循那些业务可接受的行业最佳实践。例如，如果行业最佳实践是将开放API规范应用于API的定义，那么每个微服务团队都必须遵循此类标准。同时，团队也应该有权选择在开发过程中使用的编程语言和库。设计时治理的另一个关键方面是可重用性。WSO2治理解决方案通过为用户提供一个存储库来检索和浏览现有服务来实现重用。这样一来，我们不仅可以减少整体的上市时间，还可以减少团队在重复性任务上浪费的时间。在管理服务的生命周期时，我们有时需要权衡是否需要弃用服务。WSO2治理解决方案可以帮助用户分析给定服务（或资产）对其他类似对象的影响。在API开发方面，WSO2APIManager带有APIPublisher和Developer门户，它们为API（和API代理）提供生命周期管理和存储库功能。它可以由在各自的交付渠道（例如，移动设备或Web应用程序方法）中使用API的内部和外部开发人员调用。通过与WSO2APIManager的集成，WSO2数字资产治理解决方案可以在治理平台上完成API设计，并推送到API管理层。RuntimeGovernanceRuntime治理通过API处理服务与治理平台之间的运行时交互，发现平台上的目标资产。例如，在使用WSO2EI开发的典型集成中，我们可以将端点的名称指定为固定值，例如“HospitalEP”。但是这个值的实际URL会根据不同的环境（如：DEV、UAT、PROD）而有所不同。治理平台可以实现端点名称到URL的运行时映射，并解析URL的存储值。这个特性通常被称为“服务发现”，即运行时通过调用管理平台来发现服务的实际URL。此外，治理平台公开了一组RESTAPI，并以编程方式执行设计时治理产生的各种功能。这些API使微服务团队能够将自动化部署与治理平台的生命周期管理相集成。值得注意的是，在将特定服务部署到生产环境之前，我们需要执行手动检查以确保符合“信任但验证”政策。当服务发生变化时，运行时治理需要向相关方发送实时通知（例如电子邮件等）。例如，如果一个服务从已实现状态转变为已发布状态，平台会自动通知用户（或之前版本的用户），让用户立即受益。同样，如果资产被删除，这样的通知将使相关人员能够及时采取安全措施。治理平台安全治理的一个关键方面是：平台上目标资产（或服务）的安全性。我们既可以将用户信息保存在LDAP、AD等企业级用户存储库中，也可以接入治理平台自身的数据库，根据微服务团队的需求和公司的整体需求定义角色，并分配合适的权限集。例如，具有开发人员角色的用户无法更改服务从实施到发布的生命周期，但具有产品经理角色的用户必须在执行此操作之前验证必要的细节。同样，如果需要对不同业务单元之间的资产进行逻辑隔离，那么我们也可以创建多个租户，授权他们维护自己的资源库，不受其他团队的干扰。微服务治理和API管理目前，业界对微服务治理的最大误解之一是API管理平台可以通过其API发布工具和开发人员门户来治理微服务。事实上，只有当后端微服务团队决定使用API管理平台将其微服务暴露给其他组件时，该平台才会开始使用与API相关的那些生命周期、标准和策略。互动。也就是说，它没有提供API开发之前所需要的管理功能。对此，人们倾向于将平台扩展到API生命周期之外，包括后端微服务的“设计”、“审核”、“实施”等阶段。然而，即使所有的微服务都暴露在一个API平台上，这些平台也无法处理微服务开发的治理问题（API代理部分除外）。对此，最好的解决方案是：在微服务治理平台和API管理平台之间架起一座桥梁，让API管理成为微服务治理的延伸。微服务治理与API管理的融合如上图所示，微服务治理捕获了一个独立于API开发的循环过程。在瀑布式开发模型中，微服务团队负责微服务的实现和API的开发。这样方便了两者的“桥接”。大多数情况下，当定义好API接口后，微服务开发和API开发这两项工作就可以并行进行，不需要互相等待。这就是我们经常听到的所谓“APIfirst”的开发方式。如上图所示，架构师将API定义为生命周期的初始输出，然后将其拆分为两个微服务团队，分别开发后端实现和API创建等相关活动。此外，API管理平台通常会在微服务之外创建API代理，并向运行时架构添加另一个组件。当然，并不是每个微服务都需要这样。微服务团队使用ServiceMesh等技术，使其微服务内部已经具备了QoS，只需要将其元数据发布给其他用户即可，无需在现有服务时间内引入任何其他运行时。此外，API管理平台无法使用依赖性分析等功能来识别给定服务与生态系统其他部分的关系。毕竟，它只关注特定的API及其关联的端点。API管理与微服务治理如上图所示，API管理平台在微服务开发过程中提供了对治理平台的补充，实现了微服务架构端到端的治理，通过流程控制的优势，提供服务，为企业和用户带来真正的价值。参考资料https://www.wipro.com/blogs/dr-gopala-krishna-behara/microservices-governance/https://www.leanix.net/en/blog/microservices-governancehttps://dzone.com/文章/高效企业微服务治理https://wso2.com/whitepapers/microservices-in-practice-key-architectural-concepts-of-an-msa/https://medium.com/ibm-garage/微服务-technical-governance-f5aed10189d1【原标题】MicroservicesGovernanceandAPIManagement（作者：ChanakaFernando）【翻译稿件，合作站点转载请注明原译者和出处.com】
