二、服务治理体系
服务建模
服务建模是一个收集、分析、识别的过程。
：业务需求的收集和整理。
包含特定的场景、用户群、业务目标等硬性指标，还可以包含如用户体验、较之竞争对手的一些特色等的软性指标。
：业务分析。
可视化业务建模。与业务领域专家一起使用通用语言文档化整个业务过程。
：识别候选业务过程需要的所有服务。
这些服务有些是新实现的，有些是已有的。有些可能是在微服务架构体系下通过网关调用实现的，有些可能是通过调用实现的。包含：
. 原子的（单步的）；
. 组合好的（多步的，操作类流程，有无工作流皆可）
. 已有的虚拟服务流程（如：承保、核保、风险指标或登记的计算）
. 基础设施（如：邮件通知、短信通知、在系统中生成一条代办事项）
：对上一步识别的服务所使用的对象确定并可视化其状态和行为。
：服务识别过程成果基于服务模型等规范的落地实现
服务识别成果与对于服务模型、元数据的对应归纳、分类和具体实现设计、编码、复用等工作
：服务的发布
服务在开发、测试、生产环境中的部署、调试和上线
：服务在运行态的监控、发现与治理
元数据模型
元数据模型分为静态和运行态两类
元数据模型－静态
静态包含：按层级划分为：平台定义、系统定义、应用定义和服务定义。根据业务变化，可以在对应分类中，扩充属性。
元数据模型－运行态
运行态模型包含：应用实例、服务实例及服务流水。
模型之间的关系
我们看一下各模型之间的对应关系，首先从组织层面的隶属关系来看，一个部门可以负责多个平台，一个部门下的一个团队可以负责一个或多个系统，一个团队下的一个小组或个人可以负责一个应用或多个应用。
一个平台包含多个系统，一个系统包含多个应用，一个应用包含多个服务。应用实例是应用定义对象的实例化。服务实例是服务定义对象的实例化。
一个应用实例，通常会支撑提供多个服务实例。服务之间的调用，产生服务流水。
模型按照“平台－系统－应用－服务”这样的层级建立关系。
依赖关系的梳理
依赖关系有归属关系、记录依赖关系和调用依赖关系。
服务生命周期数据流和控制流
在控制流的干预下，数据流在不同的时点上呈现出不同的变化，例如婴儿只有姓名标签，没有学号标签，等他上学了才有学号。
服务生命周期中的服务治理模型的标签亦是如此，会随着所处的服务生命周期发生一些变化。
服务生命周期数据流
服务的生命周期我们定义为规划、设计／开发、测试、运行四个阶段，数据流的规范是指各类对象属性在生命周期各阶段中，哪些被赋值和初始化，哪些值会有更新。就像上面提到的人的一生的标签。
. 在规划阶段根据业务需求，平台、系统、应用和服务都将对划分、归口、相关定义类的数据进行初始化，对于平台和系统，生命周期和分布式架构相关属性也会有值。
. 在设计／开发阶段，系统、应用和服务将被具体实现，所以这三类的几乎所有属性都将被初始化。
. 在测试阶段，应用和服务将被实例化，实例将从定义对象中继承大部分属性，并且动态更新自己的运行态属性。
. 在运行阶段，应用和服务实例只是换到了生产环境运行，同样实例将从定义对象中继承大部分属性，并且动态更新自己的运行态属性。
服务生命周期控制流规范
服务在整个生命周期，它的生成、交互、变更、销毁都会对周边的系统、应用、服务造成影响，那如何来评估和控制影响带来的成本压力和风险？这需要我们在关键点上加必要的控制点，这就形成了我们的控制流规范。在规范中，控制点分为两类：建议的必要流程和参考流程。必要流程即为必选，参考流程可以根据组织自身情况来选用，达成风险控制与效率的平衡。
控制流的抽象模型-
，是在流程应用中抽象出的业务模式，是用来明确组织过程中各个角色及其相关责任的方法，其中：
• 谁负责（=），即负责执行任务的角色，他／她具体负责操控项目、解决问题
• 谁批准（=），即对任务负全责的角色，只有经他／她同意或签署之后，项目才能得以进行
• 咨询谁（=），拥有完成项目所需的信息或能力的人员
• 通知谁（=），即应及时被通知结果的人员，却不必向他／她咨询、征求意见
我们对于控制流的表述，是通过的模型来进行的，简单来说，就是针对这条流程谁来负责、需要谁批准，有问题可以咨询谁，流程到达特定环节需要通知谁。
角色定义
服务开发团队：负责需求分析，服务的设计、开发、测试、部署、运维等具体工作的角色团队；
架构管理团队：是关于系统、服务、业务以及相关事项的最终决策者。负责审批微服务体系战略方向／架构、资源、成本等的管控／服务治理原则的把控等管理职能；
生产运维部：负责生产环境的部署、变更、运维、安全风险评估等工作的角色团队；
风险管理委员会：负责重要业务系统的业务相关风险评估；
业务管理团队：是关于业务需求提出、服务资金、激励分配相关事项的最终决策者。
服务新增审批流程
服务新增审批流程，由服务开发团队提出申请，经架构团队审核批准，审批通过后录入服务治理平台。
输入为业务流程分析的相关成果，服务识别相关成果，治理平台中注册的已有服务。
主要活动，评估是否有必要新增服务，并评估新增服务带来的人员、资源等成本压力。
输出为：新增服务的相关属性定义到治理平台。
服务变更审批流程
服务变更审批流程，由服务开发团队提出申请，经架构团队审核批准，审批通过后录入服务治理平台。
输入为业务流程分析的相关成果，服务识别相关成果，治理平台中注册的已有服务，以及服务之间的依赖管理。
主要活动，评估是否有必要变更服务，是否有必要进行服务的重构，评估变更和重构带来的人员、资源等成本压力。
输出为：新增服务的相关属性定义到治理平台。
服务调用审批流程
服务调用审批流程，由服务开发团队提出申请，经架构团队审核批准，审批通过后录入服务治理平台。
输入为业务流程分析的相关成果，服务识别相关成果，治理平台中注册的已有服务。
主要活动，评估是否有必要跨系统进行服务调用，评估变更和重构带来的人员、资源等成本压力。
输出为：新增服务的相关属性定义到治理平台。
服务上线审批流程
服务上线审批流程，由服务开发团队提出申请，如系统等级为、则由风险管理委员会审批，其它等级经生产运维部审核批准，审批通过后录入服务治理平台。
输入为服务生成过程中的相关成果。
主要活动，评估是否具备上线条件。
输出为：新增服务的相关属性定义到治理平台。
服务销毁审批流程
服务销毁审批流程，由服务开发团队提出申请，经架构团队审批，审批通过后录入服务治理平台。
输入为服务间依赖、服务实例运行态的数据以及服务流水数据。
主要活动，评估是否具备销毁的条件，以及销毁带来的人员和资源成本压力。
输出为：新增服务的相关属性定义到治理平台。
服务治理平台与其他系统的关系
这个关系的梳理也是按生命周期这个维度来做的。