今天我们就来说说微服务治理的内容。微服务治理是整个企业微服务架构改造和微服务建设落地的关键内容。很多企业虽然在转型过程中在各自的技术工具中采用了最新的微服务开发框架环境和治理平台，但实际上，微服务从需求、设计到上线运行都处于混乱状态，关键是微服务治理的出现。问题。对于微服务治理，很多人一说到这里，最容易想到的就是类似SpringCLoud的开发框架，类似Istio的微服务治理平台，或者一堆微服务标准规范和技术规范体系。其实微服务治理的内容远不止于此。从IT治理和SOA治理谈起治理决定了谁负责决策，需要做出什么决策，以及什么使它们保持一致。治理不同于管理。治理计划需要做出哪些决策，而管理是制定和执行决策的过程。治理侧重于制定决策，而管理侧重于执行决策。ITGovernanceITGovernance是指对IT的治理；也就是说，将治理应用到IT组织及其人员、流程和信息中以提供指导，以便这些资产支持业务需求。IT治理是描述企业或政府是否采用有效机制，使IT应用能够完成组织赋予其的使命，平衡信息化过程中的风险，确保组织战略目标实现的过程。目标。其使命是使IT与业务目标保持一致，促进业务发展，实现收入最大化，合理利用IT资源，妥善管理IT相关风险。下图为山东省软件测评中心总结的IT治理总体框架，描述了IT治理的起点、IT治理的关键要素、IT治理的对象、IT治理的最佳实践。IT治理的目的是有效地将IT与组织的业务集成。出发点是组织的发展战略。从组织的发展战略出发，遵循组织的风险和内控体系，制定相应的信息化建设和运行管理机制。IT治理的关键涵盖IT组织、IT战略、IT架构、IT基础设施、业务需求、IT投资、信息安全等，主要决定“做什么决策？谁做决策？如何做决策？”如何监控和评估“决策”。整个IT建设生命周期是IT治理的对象，包括IT组织与规划、IT建设与交付、IT运维、IT评估与优化。国际最佳实践IT治理基于各对象治理的成熟方法论和工具，包括CobiT、ITIL、ISO27001、Prince2等。对于Cobit，目前在很多IT治理框架规范和企业IT治理水平评价标准中都有使用。Cobit信息系统审计与控制协会于1996年公布，是国际公认的安全与信息技术管理与控制的权威标准，将IT流程、IT资源与企业战略与目标（指南）联系起来，形成一个三维的建筑学。在目前的Cobit5流程规范框架中，更加强调企业组织、业务和技术之间的平衡，帮助企业更好地构建内部IT，创造更多的商业价值。Cobit5使IT能够对整个企业进行整体治理和管理，负责整个端到端业务和IT功能领域，同时考虑内部和外部利益相关者的IT相关利益。在之前的IT项目咨询规划中，我们基本上也是使用Cobit标准框架来构建企业内部的IT治理框架规范。SOA治理SOA治理是IT治理的一种专门化，它将关键的IT治理决策置于服务组件、服务和业务流程的生命周期上下文中。SOA治理有效地管理生命周期，这是一个关键目标。SOA治理侧重于服务生命周期的各个方面，例如：规划、发布、发现、版本控制、管理和安全性。SOA治理通常比IT治理更重要。一个核心原因是传统的SOA架构解决了多个业务系统之间的接口服务基础和复用问题，往往涉及多个开发人员、多个业务部门、多个流程之间的协作。这就需要制定严格的标准和规范来管理和实施。例如，在SOA项目实施过程中，经常听到接口管理混乱，接口实现标准不统一，接口版本混乱，接口没有退出或下线机制，接口无法复用，无法分析有多少消费者在调用某个接口。等等都是前期SOA治理体系不完善造成的。对于SOA治理，IBM给出了完整的生命周期，即：IBM的SOAGovernanceandManagementMethod（SGMM）是实现SOA治理生命周期并将治理应用于SOA生命周期的完整过程。SGMM包括四个阶段：规划-确定治理优先级。定义-定义SOA治理模型。已启用-实施SOA治理模型。指标-改进SOA治理模型。这个治理框架的核心是服务的全面生命周期管理，主要内容包括：服务定义（服务范围、接口和边界）服务部署生命周期（每个生命周期阶段）服务版本治理（包括兼容性）服务迁移（启用和退役）服务注册（依赖）服务消息模型（规范数据模型）服务监控（用于问题确定）服务所有权（企业组织）服务测试（重复测试）服务安全（包括可接受的保护范围）对于SOA治理本身，其实我在之前的很多篇文章里都讲过，应该包括两个部分：pre-SOA的构建周期和post-SOA的运维周期。前期覆盖SOA实施全生命周期，后期覆盖SOA运维监控全过程。从目前主流的DevOps方法论来看，两者本身应该是融合的。下面是我原先给出的SOA治理管控体系结构图：垂直覆盖SOA从设计、开发、测试、部署、运维、监控的全生命周期管理。同时从业务、服务、支持三个流程领域横向扩展。也就是你有了SOA治理之后，你就知道做任何事情应该遵循什么规则，这是其中之一。第二，当出现问题需要做决定的时候，大家都知道应该按照什么样的决策过程来做决定。一是涉及业务系统、集成商、甲方信息化、事业部组织；第二，涉及到技术标准和流程，不仅仅是规范，还有流程，比如服务接入流程和消费流程，接口问题分析和解决流程等。在整个SOA服务生命周期管理中，你执行的所有内容都有有章可循，这就是SOA治理。SOA治理不仅是后期的服务运维、SLA管理等，还包括上述从服务识别、定义、设计、开发、测试、部署、上线的SOA全生命周期管理规范和流程。在SOA运维阶段，谈到SOA治理，首先要看到常规IT治理和ITIL的内容，SOA的实施和建设也需要完全遵守。这里最重要的点是：一个是服务变更和版本管理，上线后如何变更服务，如何分析服务变更的影响，变更是升级大版本还是小版本，包括服务之后版本升级，如何兼容老业务系统版本等等，都必须提前制定规范和流程，同时制定变更分析方法。否则，会导致后续服务线上版本混乱，出现难以管理的情况。二是服务SLA管理，如何制定服务SLA等级，资源受限时如何根据服务优先级控制服务流，对于高SLA等级和冗余的服务如何保证更高的服务可用性和高性能等等。SOA服务监控，业务告警如何与业务运行实例紧密结合，业务SLA等级，这些也需要在前期制定规范和标准。一个好的SLA管理和监控运维系统的核心目标是保证SOA平台的高可用和高性能，在资源受限的情况下保证高SLA级别服务的高可用。三是服务状态管理，也是比较重要的。服务上线的设计状态如何定义，上线的服务如何下线等等，应该遵循什么原则，对下线影响服务的分析，遵循什么样的下线流程，如何进行进行例行检查，分析潜在下线服务等，这些也必须事先商定，并建立标准化流程。最后一点是服务的安全管理，如何保证服务运行的安全，如何授权访问服务，如何对有特殊需求的服务进行传输安全，数据安全控制，如何加密数据。那么具体的加解密规则是什么协议。对于接入的服务，在哪些场景需要启用哪些类型的安全控制。这些也是我们必须考虑的问题。微服务治理概述谈及微服务治理，首先需要回顾一下微服务的概念。微服务意味着它们可以在“自己的程序”中运行，并通过“轻量级设备”与HTTPAPI进行通信。关键是服务可以运行在自己的程序中。通过这个我们可以区分服务暴露和微服务架构（在现有系统中分发一个API）。在服务公开中，许多服务可以被内部独立进程所限制。如果这些服务中的任何一个需要添加某种功能，则必须缩小流程的范围。在微服务架构中，只需要在特定服务中添加需要的功能，而不影响整体流程。注意，我们经常说到服务，很容易直接想到WS、RestAPI等服务接口，因为在SOA架构的概念中，服务就是指这些服务接口。在微服务架构中，尤其需要注意的是，微服务并不是简单的HttpRestAPI接口。也就是说，微服务本身包括拆分的微服务模块和微服务模块提供的API。即微服务=微服务模块+微服务API接口也是我们看到微服务治理不能简单等同于SOA治理的原因。undefined其中，服务度量涉及服务开发、测试、运维、上线运行的度量；对于服务管控，本书还涉及微服务全生命周期的管控。本书中给出了微服务治理与微服务管理的关系：从中可以看出，度量在整个微服务治理中起着关键作用，即实现了整个治理和管理过程的闭环通过测量。二是实现治理规范和指引的不断优化和完善。网上有一篇文章可以参考：http://www.uml.org.cn/wfw/201908013.asp?artid=22256这本书给出了治理、管理、度量的三位一体。微服务治理的整体架构。从图中可以看出，微服务的治理需要线上和线下同时治理。通过线上线下两个维度收集治理指标，汇总到数据仓库执行。统一测量和分析。在这些衡量指标中，有相当一部分在线性能和异常指标会转化为运维事件。一旦我们预先设置的阈值被触发，就会进一步转化为“控制指令”，由调度中心下发，对服务进行弹性伸缩、扩缩容操作，或者限流、降级、故障等控制操作服务的容忍度和路由调整。另一部分衡量指标，包括架构、开发、测试、运维、流程协同效率等指标，将通过治理委员会（泛指治理成员的集合）进行人工分析，做出治理决策.这些治理决策将通过相关管理措施得到实施。重新思考微服务治理框架基于前面的内容，这两天重新思考了微服务治理和治理框架。至于微服务治理，前面已经提到了，其实包括微服务模块书和微服务API接口治理两个方面，不能简单理解为API接口的治理。因此，微服务治理应该进一步融入IT治理和SOA治理两部分。如果我们重新定义微服务治理，应该是这样的：微服务治理就是针对企业组织和业务目标，制定一套标准的管理、业务、技术、流程规范体系，实现微服务从需求、设计、开发、线上、运营、线下全生命周期管理能力。同时，构建一套完整的衡量指标体系，通过实时日志和性能数据采集，持续监控服务运行监控状态，并实施相应的限流、预警等控制策略，确保持续健康、可靠和微服务运行的效率。基于此，可以理解整个治理框架应该包括三个方面：设计态：如何分析设计微服务、模块拆分、接口设计运行态：如何构建度量分析体系，实现微服务监控，并确保微服务的健康运行规范类：构建一套完整的涵盖管理、业务、技术、流程支撑的规范体系工具类：基于以上治理需求，选择可行的技术平台或工具进行支撑以上是一个全面的微服务治理书籍，应包含内容。从这里也可以看出，微服务治理平台或者说开发框架其实只占了微服务治理的一部分内容，而不是全部。综上所述，微服务治理实际上包括两个关键部分。即在微服务需求和设计阶段如何拆分微服务和接口粒度设计；如何基于测量系统进行监控，并在运行期间形成持续优化和改进的闭环。基于以上考虑，重构微服务治理的整体框架如下：这张图基本围绕微服务生命周期管理和基于服务度量体系的持续运维监控两个方面展开。无法扩展，比如常说的服务版本管理，服务依赖分析是微服务治理的重点内容，暂时没有在这张图中体现出来。运维期思维的另一个关键转变是，不再是简单的问题发生后的运维管理，而是基于监控预警分析的主动技术运维和SLA服务水平提升。
