从SOA治理到微服务治理，对整体框架构建的再思考

　　今天谈下微服务治理方面的内容，对于微服务治理是整个企业微服务架构转型和微服务建设实施中一个关键内容，很多企业在转型过程中各自技术工具虽然采用了最新的微服务开发框架环境，治理平台等，但是实际上微服务整个从需求，设计到上线运行全是一种混乱状态，其中关键还是微服务治理出现了问题。
　　对于微服务治理，很多人一谈这个这个最容易想到的就是类似SpringCLoud开发框架，类似Istio的微服务治理平台，或者就是一堆的微服务标准规范，技术规范体系。实际上微服务治理的内容却是远远不止这么一点。从IT治理和SOA治理谈起
　　治理确定谁负责制定决策，需要制定什么决策，以及使决策制定保持一致的决策。治理不同于管理。治理规划需要制定什么决策，而管理是制定和实施决策的过程。治理重在建立决策，而管理重在贯彻执行决策。
　　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建设与交付、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 的 SOA Governance and Management Method (SGMM) 是一个完整的流程，用于执行 SOA 治理生命周期，将治理应用于 SOA 生命周期。SGMM 包括四个阶段：计划——确定治理的重点。定义——定义 SOA 治理模型。启用——实现 SOA 治理模型。度量——改进 SOA 治理模型。
　　在该治理框架中核心还是围绕服务全面生命周期管理，关键内容包括：服务定义（服务的范围、接口和边界）服务部署生命周期（各个生命周期阶段）服务版本治理（包括兼容性）服务迁移（启用和退役）服务注册中心（依赖关系）服务消息模型（规范数据模型）服务监视（进行问题确定）服务所有权（企业组织）服务测试（重复测试）服务安全（包括可接受的保护范围）
　　对于SOA治理本身，我实际上在前面很多文章都已经谈到过，应该是包括了SOA建设前周期和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等级服务的高可用性。
　　其三就是服务的状态管理，这个也相对重要，服务如何从定义设计状态到上线运行，对于上线运行的服务如何进行下线处理等，这些应该遵循什么样的原则，对于服务下线如何进行影响分析，遵循什么样的下线流程，如何进行例行检查以分析潜在可能下线的服务等，这些也必须提前约定并制定规范流程。
　　最后还有一点就是服务的安全管理，如何保证服务运行的安全，服务如何进行访问授权，对于有特别要求的服务如何进行传输安全，数据安全控制，如何进行数据加密处理那么具体的加密和解密规则约定是如何的。对于接入的服务，在哪些场景下必须启用哪些类别的安全控制。这些也属于我们必须考虑的问题。微服务治理概述
　　在谈微服务治理的时候，首先还是需要重新回顾下微服务的概念。
　　微服务是指可以在＂自己的程序＂中运行，并通过＂轻量级设备与HTTP型API进行沟通＂。
　　其中关键在于该服务可以在自己的程序中运行。通过这一点我们就可以将服务公开与微服务架构（在现有系统中分布一个API）区分开来。在服务公开中，许多服务都可以被内部独立进程所限制。如果其中任何一个服务需要增加某种功能，那么就必须缩小进程范围。在微服务架构中，只需要在特定的某种服务中增加所需功能，而不影响整体进程。
　　注意，当我们经常谈服务的时候，很容易直接想到的就是类似WS，Rest API等服务接口，因为在SOA架构概念里面服务即特指这些服务接口。
　　而在微服务架构下，特别要注意微服务不是简单的Http Rest API接口。也就是说微服务本身包括了拆分后的微服务模块，微服务模块提供的API两个部分内容。
　　即微服务 = 微服务模块 + 微服务API接口
　　也正是这个原因，我们才看到微服务治理不能简单地和SOA治理做等同。比如将微服务治理简单理解为类似SOA架构下的Http Rest API接口或RPC接口的管控治理。一个完整的微服务治理应该同时包括了传统的软件开发全生命周期管理+接口服务全生命周期管理的内容。
　　只是原来的软件系统开发变成了一个个拆分后的微服务模块开发。
　　微服务治理框架
　　对于微服务治理，如果我们用这个关键字进行搜索，搜索到的内容主要包括两个部分。类似Springcloud，Istio，治理平台等软件框架平台内容类似服务限流熔断，服务链监控，安全，日志，SLA管理等内容
　　当然这两个部分内容本身没有错。但是现在容易造成的误解的就是将对微服务架构平台上线后的微服务运行管控，监控分析理解为完整的微服务治理内容。而实际上我们看到微服务治理的范畴远远超过这个理解。
　　也就是说软件治理框架仅仅是工具或平台，是执行你制定的策略用地。那么治理本身的关键是制订策略，而不是策略究竟是人来执行，还是软件工具平台来执行。
　　我们举一个简单的例子来说明下。
　　对于治理平台提供了服务限流熔断的功能，比如并发数大于1万次就进行限流，我们也很容易将该规则配置到治理平台。但是实际治理的关键是制定一个策略，即我们针对不同的业务场景，服务类型，服务SLA重要性要求，应该如何去制订合理的限流策略。
　　不清楚基于什么规则制订策略，在平台上胡乱配置，反而是起到副作用。
　　再比如你的治理平台同时提供了服务集成，消息集成和大文件集成能力，这个是治理平台本身的功能。但是针对不同的业务集成需求，如何制订服务集成类型，这就是典型的服务治理要考虑的内容。否则服务实现类型不对，服务定义颗粒度不对，都导致服务运行效率，质量出问题。
　　这也正是前面强调的，管理治理工具平台不难，难得是基于什么原则去管理。微服务治理体系架构和实践
　　上面这本书是我最近购买和阅读的一本书，差不多读到了一半，很多地方有启发，而且里面很多做法实际和我们实施SOA集成大项目中的，SOA治理管控做法一致。
　　对于这本书的内容，我后面还会单独整理笔记。
　　从这本书，可以看到作者对微服务治理的理解包括了度量，管控，管理几个关键方面，并基于三位一体的思路实现一个微服务治理的闭环。
　　而里面涉及到的关键就是微服务度量体系的建设，服务监控管理（限流，熔断，降级，安全）和服务链监控。其中服务度量涉及到服务开发，测试，运维，上线运行各阶段的度量；对于服务管控本书也涉及到微服务全生命周期的管控。
　　在该书给出了微服务治理和微服务管理之间的关系如下:
　　从中可以看到度量在整个微服务治理中起到要给关键作用，即通过度量来实现整个治理和管理过程的闭环，其次是实现治理规范和准则的持续优化和改进。
　　网上有一篇文章大家可以参考：
　　http://www.uml.org.cn/wfw/201908013.asp?artid=22256
　　在该书里面给出了一个治理，管理，度量三位一体的微服务治理整体架构。
　　从图中可以看到，微服务的治理既要进行线上的治理，也要进行线下的治理，通过线上线下两大维度进行治理指标的采集，并把它汇总到数据仓库中，进行统一的度量和分析。
　　这些度量指标中，有相当一部分线上的性能及异常指标会被转化为运维事件，一旦触发我们预先设置的阈值，就会被进一步转化成＂管控指令＂，并通过调度中心下发，进行服务的弹性伸缩、扩容缩容操作，或者进行服务的限流、降级、容错、路由调整等管控操作。
　　另外一部分度量指标，包括架构、开发、测试、运维、过程协作效率等指标会通过治理委员会（泛指，治理成员的集合）进行人为的深入分析，并制定出治理决策，这些治理决策会通过相关的管理措施进行落地。重新思考微服务治理框架
　　基于前面内容，这两天重新思考了下微服务治理和治理框架。
　　对于微服务治理在前面已经谈到了实际上包括了微服务模块本书和微服务API接口治理两个方面的内容，而不能简单理解为API接口的治理。因此微服务治理应该进一步融入IT治理和SOA治理两个部分的内容。
　　如果重新给微服务治理一个定义，应该如下：
　　微服务治理是针对企业组织和业务目标，制订一套标准的管理，业务，技术，过程规范体系，实现微服务从需求，设计，开发上线，运行，下线的全生命周期管理能力。同时构建一套完整的度量指标体系，通过实时的日志和性能数据采集，持续的监控服务运行监控状态，并执行相应的限流，预警等管控策略，以确保微服务的持续健康，可靠和高效运行。
　　基于这个，可以理解为整个治理框架应该包括三方面内容：设计态：如何进行微服务分析和设计，模块拆分，接口设计运行态：如何构建度量分析体系，实现微服务监控，确保微服务健康运行规范类：构建一套完整的覆盖管理，业务，技术，过程支撑的规范体系工具类：基于上面治理要求，选择可行的技术平台或工具进行支撑
　　以上就是一个微服务治理本书应该包括的全面内容。从这个里面也可以看到微服务治理平台或开发框架实际上仅仅占了微服务治理的一部分内容，而不是全部。
　　微服务治理概括来说，实际上关键包括两个部分。
　　即在微服务需求和设计期是如何进行微服务拆分，接口颗粒度设计；在运行期是如何基于度量体系进行监控并形成闭环持续优化改进。
　　基于以上思考，对微服务治理整体框架进行重构如下：
　　该图基本围绕微服务全生命周期管理和基于服务度量体系的持续运维监控两个方面展开，对于一些二级的内容在该图暂时无法展开，比如常说的服务版本管理，服务依赖分析是微服务治理的要给关键内容，暂时在该图没有体现。
　　在运行期还有一个关键思维的转变就是不是简单的发生问题故障后的运维治理，而是应该基于监控预警分析下的主动的技术运营和SLA服务等级提升。