转载本文需注明出处:微信公众号EAWorld,违者必究。
引言:
微服务等新技术在解决系统敏捷性的同时,也带来了新的问题,众多的服务被识别出来后需要有效的管理起来,内部系统与外部系统通过服务方式进行双向集成,既有服务“引进来”,也有服务“走出去”。数量和种类繁多的服务如何管理?如何在复杂的微服务系统中实现问题快速定位与恢复?
从业界发展经验和众多实际案例来看,这一系列问题都需要建立企业服务治理体系来解决,通过服务治理体系支持金融行业基础架构向微服务架构转型。
目录:
一、服务治理原则
二、服务治理体系
三、服务治理平台
一、服务治理原则
组织:建立专业的人员保障
服务治理是咨询+实施类项目,不仅仅是部署一套平台工具。为了实现服务治理的效果,需要由专业的人员参与。各个角色的职能如下:
完善的管理流程和后面的几个原则有一定的关联性,比如流程的参与者是“专业的人员”、流程环节中的相关操作,需要由平台和工具提供支撑。
技术:建立统一的技术标准
在“移动互联”和“互联网+”的时代,服务调用的次数更高,时间响应的要求更短。统一的技术标准可以减少开发时间,减少不必要的协议转换、消息转换,提高响应速度,服务治理更关注于过程管理本身。
服务治理过程中统一技术标准的意义类似于古代“车同轨,书同文”。也就是服务调用过程中涉及到诸多技术标准:接口原则、编码规范、服务规范等要统一,并且随着技术和为了提高服务开发效率和响应速度,需要制定统一的技术标准,服务治理的重点从早期的协议转换演进为服务管理。
平台:以平台支撑服务治理
企业数字化时代,产业链控制力空前强大,企业间协作越来越频繁。服务治理的平台工具必须能够承受更大的压力。
企业数字化转型之后,系统间集成越来越多,服务治理平台处于核心的枢纽位置,平台的稳定性和性能是业务运营的基础。
强大的平台要求主要体现在:高性能、可靠性、扩展性等非功能性方面!
平台工具:
系统:先解耦、再整合
现有大而全的系统犹如一张大网,错综复杂,系统边界不清晰、系统部署架构和功能架构不清晰。牵一发而动全身,项目改造难度极大、成本极高。
企业为了适应业务的发展,IT系统必须敏捷。敏捷的前提是对现有的“大饼”系统需要解耦,解耦之后业务系统由多个小系统组成,系统间边界清晰、系统间交互明了。通过解耦减低了系统演进的复杂度、提高业务创新和业务融合的速度。
需要从三个方面解决问题:
服务:自上而下和自下而上区分对待
在系统解耦和服务发现的过程中涉及到两种服务梳理方法, “自上而下”和“自下而上”两种方式各有利弊,项目实施时需要根据实际情况选择合适的服务梳理方法。只有适合实际系统改造的方法才是最好的。
多维度的服务拆分:
流程:结合企业IT管理需求设置合适的管理流程
服务治理的过程很复杂,主要因为如下方面的原因:
服务治理实现了服务的全生命周期管理,项目实施时需要根据企业管理要求制定出可落地、可执行的管理流程。清晰的定义出什么人(组织),在什么地方(平台),做什么事情(工具)。
流程管理可以是线下的,也可以借助专业的BPM平台实现。两种方案实施的成本和周期差异较大,实施方案需要根据实际情况而定。
工具:完备的管理手段
平台提供服务调用、单个服务注册、批量服务注册、报文审计、调用审计、TopN查询、报文检索、统计分析查询等功能。
通过完备的管理工具实现对服务的全生命周期管理。
服务治理平台首先满足服务集成的功能,在服务治理过程中还需要提供灵活易用的工具,实现对服务的全生命周期管理。
审计:建立独立第三方稽核
建立独立第三方稽核的含义是:
服务治理项目实施成功的关键因素是项目团队能够保持中立的立场,提供公平、公正的稽核管理。
过程:持续化的服务管理
服务上线仅仅是服务生命周期管理的开始,业务的连续性需要IT系统提供长期的稳定运行,服务治理是一个持续的工作,服务治理的过程需要专职、专业的人员,采用完善的流程,利用丰富的工具,不间断的检查技术标准和管理过程的合规性。
二、服务治理体系
服务建模
服务建模是一个收集、分析、识别的过程。
Step1: 业务需求的收集和整理。
包含特定的场景、用户群、业务目标等硬性指标,还可以包含如用户体验、较之竞争对手的一些特色等的软性指标。
Step2:业务分析。
可视化业务建模。与业务领域专家一起使用通用语言文档化整个业务过程。
Step3:识别候选业务过程需要的所有服务。
这些服务有些是新实现的,有些是已有的。有些可能是在微服务架构体系下通过API 网关调用实现的,有些可能是通过ESB调用实现的。包含:
Step4:对上一步识别的服务所使用的对象确定并可视化其状态和行为。
Step5:服务识别过程成果基于服务模型等规范的落地实现
服务识别成果与对于服务模型、元数据的对应归纳、分类和具体实现设计、编码、复用等工作
Step6:服务的发布
服务在开发、 测试、生产环境中的部署、调试和上线
Step7:服务在运行态的监控、发现与治理
元数据模型
元数据模型分为静态和运行态两类
元数据模型-静态
静态包含:按层级划分为:平台定义、系统定义、应用定义和服务定义。根据业务变化,可以在对应分类中,扩充属性。
元数据模型-运行态
运行态模型包含:应用实例、服务实例及服务流水。
模型之间的关系
我们看一下各模型之间的对应关系,首先从组织层面的隶属关系来看,一个部门可以负责多个平台,一个部门下的一个团队可以负责一个或多个系统,一个团队下的一个小组或个人可以负责一个应用和多个负责。
一个平台包含多个系统,一个系统包含多个应用,一个应用包含多个服务。应用实例是从应用定义对象的实例化。服务实例是从服务定义对象的实例化。
一个应用实例,通常会支撑提供多个服务实例。服务之间的调用,产生服务流水。
模型按照“平台-系统-应用-服务”这样的层级建立关系。
依赖关系的梳理
依赖关系有归属关系、记录依赖关系和调用依赖关系。
服务生命周期数据流和控制流
在控制流的干预下,数据流在不同的时点上呈现出不同的变化,例如婴儿只有姓名标签,没有学号标签,等他上学了才有学号。
服务生命周期中的服务治理模型的标签亦是如此,会随着所处的服务生命周期发生一些变化。
服务生命周期数据流
服务的生命周期我们定义为规划、设计/开发、测试、运行是个阶段,数据流的规范是指各类对象属性在生命周期各阶段中,哪些被赋值和初始化,哪些值会有更新。就像上面提到的人的一生的标签。
服务生命周期控制流规范
服务在整个生命周期,它的生成、交互、变更、销毁都会对周边的系统、应用、服务造成影响,那如何来评估和控制影响带来的成本压力和风险,这需要我们在关键点上加必要的控制点,这就形成了我们的控制流规范。在规范中,控制点分为两类:建议的必要流程和参考流程。必要流程即为必选,参考流程可以根据组织自身情况来选用,达成风险控制与效率的平衡。
控制流的抽象模型-RACI
RACI,是在流程应用中抽象出的业务模式,是用来明确组织过程中各个角色及其相关责任的方法,其中:
我们对于控制流的表述,是通过RACI的模型来进行的,简单来说,就是针对这条流程谁来负责、需要谁批准,有问题可以咨询谁,流程到达特定环节需要通知谁。
角色定义
服务开发团队:负责需求分析,服务的设计、开发、测试、部署、运维等具体工作的角色团队;
架构管理团队:是关于系统、服务、业务以及IT相关事项的最终决策者。负责审批微服务体系战略方向/架构、资源、成本等的管控/服务治理原则的把控等管理职能;
生产运维部:负责生产环境的部署、变更、运维、安全风险评估等工作的角色团队;
风险管理委员会:负责重要业务系统的业务相关风险评估;
业务管理团队:是关于业务需求提出、服务资金、激励分配相关事项的最终决策者。
服务新增审批流程
服务新增审批流程,由服务开发团队提出申请,经架构团队审核批准,审批通过后录入服务治理平台。
输入为业务流程分析的相关成果,服务识别相关成果,治理平台中注册的已有服务。
主要活动,评估是否有必要新增服务,并评估新增服务带来的人员、资源等成本压力。
输出为:新增服务的相关属性定义到治理平台。
服务变更审批流程
服务变更审批流程,由服务开发团队提出申请,经架构团队审核批准,审批通过后录入服务治理平台。
输入为业务流程分析的相关成果,服务识别相关成果,治理平台中注册的已有服务,以及服务之间的依赖管理。
主要活动,评估是否有必要变更服务API,是否有必要进行服务的重构,评估变更和重构带来的人员、资源等成本压力。
输出为:新增服务的相关属性定义到治理平台。
服务调用审批流程
服务调用审批流程,由服务开发团队提出申请,经架构团队审核批准,审批通过后录入服务治理平台。
输入为业务流程分析的相关成果,服务识别相关成果,治理平台中注册的已有服务。
主要活动,评估是否有必要跨系统进行服务调用,评估变更和重构带来的人员、资源等成本压力。
输出为:新增服务的相关属性定义到治理平台。
服务上线审批流程
服务上线审批流程,由服务开发团队提出申请,如系统等级为A、B则由风险管理委员会审批,其它等级经生产运维部审核批准,审批通过后录入服务治理平台。
输入为服务生成过程中的相关成果。
主要活动,评估是否具备上线条件。
输出为:新增服务的相关属性定义到治理平台。
服务销毁审批流程
服务销毁审批流程,由服务开发团队提出申请,经架构团队审批,审批通过后录入服务治理平台。
输入为服务间依赖、服务实例运行态的数据以及服务流水数据。
主要活动,评估是否具备销毁的条件,以及销毁带来的人员和资源成本压力。
输出为:新增服务的相关属性定义到治理平台。
服务治理平台与其他系统的关系
这个关系的梳理也是按生命周期这个维度来做的。
三、服务治理平台演进
服务治理平台演进阶段划分
我们参考CMMI能力成熟度模型来划分服务治理平台的演进阶段。
定义阶段
定义阶段主要打通网关,收集建立基本的服务治理模型数据。
量化阶段
量化阶段全面打通各个应用系统,全面收集度量数据进行统计分析。
优化阶段
优化阶段通过分析度量数据持续优化服务治理平台。
服务治理平台架构蓝图规划
服务治理平台按照前面划分的三个阶段逐渐建立和完善。
关于作者:黄豆,数字化金融研究院研究员,擅长系统分析和架构设计、金融三级密钥安全体系及信息安全保障、虚拟化和云计算技术、JavaEE技术;参与研发的神州商桥电子商务平台获得“全国电子商务示范单位”称号;带领团队研发的国电通云终端系统在国网多个省公司推广应用。