T∕IAC 45-2022 保险行业应用开发的微服务架构成熟度模型

《T∕IAC 45-2022 保险行业应用开发的微服务架构成熟度模型》由会员分享，可在线阅读，更多相关《T∕IAC 45-2022 保险行业应用开发的微服务架构成熟度模型（10页珍藏版）》请在金锄头文库上搜索。

1、ICS 35.100.05, 35.240.40L 79，A 11IAC中 国 保 险 行 业 协 会 标 准T/IAC 45-2022保险行业应用开发的微服务架构成熟度模型Maturity model of micro service architecture for application development in insurance industry2022-01-13 发布2022-04-13 实施中 国 保 险 行 业 协 会发 布T/IAC 45-2022目 次前言II引言III1 范围12 规范性引用文件13 术语和定义14 成熟度模型概述25 落实程度要求26 应用成效要求

2、37 架构技术能力要求48 安全保障要求6I T/IAC 45-2022前 言本文件按照GB/T 1.12020标准化工作导则 第1部分：标准化文件的结构和起草规则的规定起草。 本文件由中国保险行业协会提出并归口。 本文件起草单位：中国信息通信研究院、中国太平洋保险（集团）股份有限公司、中国人民财产保险股份有限公司、中国人寿保险股份有限公司、安心财产保险有限责任公司、中国再保险（集团）股份有限公司、阳光保险集团股份有限公司、泰康保险集团股份有限公司、华为技术有限公司、深圳市腾讯计算机系统有限公司、北京青云科技股份有限公司、云栈科技（北京）有限公司、杭州数梦工场科技有限公司、新华三技术有限公司。

3、 本文件主要起草人：栗蔚、郭雪、卫斌、孔松、丰隽玮、欧创新、杨猛、王龙涛、袁红、冯键、成宇、尹琛、黄建坤、白阳、赵华、蒋增增、武献雨、傅帅、张春源、杜建伟、万晓兰。 II T/IAC 45-2022引言为建立保险行业微服务架构评价体系，衡量保险行业微服务技术发展水平，推动微服务技术快速弹性扩容缩容、高可用等特性在保险行业的深入应用，本文件对保险行业微服务架构成熟度模型进行定义， 主要包括落实程度、应用成效、架构技术能力和安全保障四个方面。 III T/IAC 45-2022保险行业应用开发的微服务架构成熟度模型1 范围本文件规定了保险行业的微服务架构成熟度模型，具体包括四方面：落实程度、应用成

4、效、架构技术能力和安全保障。 本文件适用于保险行业云服务科技公司或保险业科技部门应用微服务架构进行评估和定级等工作。 2 规范性引用文件下列文件中的内容通过文中的规范性引用而构成本文件必不可少的条款。其中，注日期的引用文件， 仅该日期对应的版本适用于本文件；不注日期的引用文件，其最新版本（包括所有的修改单）适用于本 文件。 GB/T 32400-2015 信息技术 云计算 概览与词汇 GA/T 1390.2-2017 信息安全技术 网络安全等级保护基本要求 第 2 部分：云计算安全扩展要求ISO/IEC TS 23167:2020 Information technology - Cloud

5、computing - Common technologies and techniques 3 术语和定义下列术语和定义适用于本文件。 3.1微服务 microservice可独立部署的人工制品，提供实现应用程序的特定功能部分的服务。 来源：ISO/IEC TS 23167:2020，3.15 3.2微服务架构 microservice architecture将应用程序分为一系列微服务的设计方法。 来源：ISO/IEC TS 23167:2020，3.16 3.3微服务平台 micro-service platform提供帮助应用实现微服务化的云服务框架及基础平台，能够快速实现微服务注册、

6、发现、治理等功能。 3.4微服务应用 micro-service application1 基于微服务架构模式，依托于微服务平台开发、运行的一组服务构成的业务应用。 4 成熟度模型概述面向保险行业的微服务成熟度模型从四个维度进行衡量： a) 落实程度：保险行业内微服务在信息系统的使用覆盖率， b) 应用成效：微服务架构在提高效率、重复利用等方面的应用成效， c) 架构技术能力：微服务架构的技术能力水平， d) 安全保障：微服务架构安全保障能力水平。 每个指标从弱到强的要求分为基础级、增强级和先进级。落实程度、应用成效、架构技术能力和安全保障四个方面的各项指标为某一级，则评定微服务架构为相应级别

7、，成熟度分级划分见表1。 表 1 微服务架构成熟度等级划分 微服务架构成熟度等级划分 基础级 在企业内构建微服务架构。有项目实施，初步的微服务能力，初步支撑微服务的基础设施平台。 如选择相对独立的一块业务采用或在非核心项目中实施微服务；已考虑标准化和规范化的框架和流程；松耦合架构；建成日志、监控、告警等基础组件，但基础设施环境还不完善；未形成应用为中心的微服务管理；采用虚拟机或容器化部署。 增强级 在企业内构建微服务架构，部分微服务能够企业级通用。有多个微服务项目并行推进， 微服务基础设施平台和基础组件建设和完善中。 逐步对单体应用进行功能分解，形成独立自治的微服务：公共功能被提取出来形成基础

8、公用微服务组件，如日志、监控、认证、权限等，所有应用共用一套基础公共组件； 进行公司级的业务梳理，选择相对核心的系统来分解实现微服务，如客户、账户、资金、订单、积分、消息等多个微服务，其他单体应用的数据和功能逐步合并到这些微服务，开始建设企业的服务中台，基于这些微服务快速构建业务应用。 先进级 在企业内构建微服务架构，部分微服务能够行业级通用。主要微服务已经构建，基础设施平台和基础组件已逐渐成熟，建立起企业的服务中台体系。 企业数据已完成融合并治理，企业数据通过唯一数据源提供。以业务为核心，支持新业务应用的快速响应和构建，大部分业务应用通过服务编排可以实现。服务中台成为与其他企业交互的主角，安

9、全、认证、权限、转换、过滤、分发、处理等中台能力支撑起不同合作伙伴的业务互连需求。 5 落实程度要求5.1 微服务核心业务系统使用率本指标考察保险行业内核心业务系统的使用率。微服务技术掌握度的计算方式，见式（1）。 （1） 式中： P1 - 微服务技术在核心业务系统使用率； A - 使用微服务的核心业务系统数量； B - 核心业务系统总数量。 a) 核心业务系统总数大于 30 个的保险企业的微服务核心业务系统使用率参考标准见表 2。 表 2 微服务核心业务系统使用率参考标准 微服务核心业务系统使用率参考标准 基础级 增强级 先进级 不低于 30% 不低于 50% 不低于 80% b) 核心业务

10、系统总数小于等于 30 个的保险企业的微服务核心业务系统使用率参考标准见表 3。 表 3 微服务核心业务系统使用率参考标准 微服务核心业务系统使用率参考标准 基础级 增强级 先进级 不低于 9 个 不低于 15 个 不低于 24 个 6 应用成效要求6.1 效率提升成效本指标考察保险行业微服务架构对开发、测试、运维等整个生命周期的效率提升。参考标准见表4。效率提升比的计算方法公式，见式（2）。 （2） 式中： P2 - 效率提升比； A - 微服务架构效率：抽样一定体量的需求的平均耗时，耗时以需求提出为计算起点，发布上线为计算终点； B - 传统模式效率：传统模式下，抽样一定体量需求的平均耗时

11、。 表 4 微服务架构效率提升成效参考标准 微服务架构效率提升成效参考标准 基础级 增强级 先进级 不低于 50% 不低于 70% 不低于 90% 6.2 服务复用率本指标考察保险行业实现微服务架构应用系统过程中，逐步积累形成具有行业/领域特征的业务公共服务的能力，参考标准见表5。 一级微服务：该类微服务可以供行业/领域使用，既使用方涉及保险行业外部用户。二级微服务：该类微服务暂无法供行业/领域使用，但已经供核心系统使用。 三级微服务：该类微服务被公司内多个非核心系统使用。 注：微服务被使用指使用方通过调用该微服务满足自己的相应需求，使用方可感知到微服务接口。使用基于微服务构建的系统不在考察范

12、围内。 微服务使用率的计算方式，见式（3）： （3） 式中： P3 微服务使用率； A - 一级微服务个数； B - 二级微服务个数； C - 三级微服务个数； D - 微服务总个数。 表 5 微服务复用率参考标准 微服务复用率参考标准 基础级 增强级 先进级 10%P320% 20% P330% 30% P350% 7 架构技术能力要求7.1 基础级技术能力要求基础级微服务架构应满足面向保险行业的微服务架构技术能力要求中第6到第10章所有要求，在此基础上，还应满足以下要求。 7.1.1 开发与测试本项要求包括： a) 应制定微服务规范流程，包括但不限于开发规范、测试规范、部署规范等； b)

13、应使用市场上开放、主流的技术标准微服务架构。 7.1.2 部署与配置应采用物理机、虚拟机或者容器进行部署。 7.1.3 基础设施与组件应具备基本的告警组件：支持关键指标的监控，包括硬件资源使用率、数据库连接状态、API健康检测状态等。 7.2 增强级技术能力要求增强级微服务架构应满足基础级微服务架构的所有要求，在此基础上，还应满足以下要求。 7.2.1 开发与测试本项要求包括： a) 微服务开发：服务提供者与消费者解耦，双方基于接口进行契约开发。 1) 应支持对接口变更频度进行严格管控； 2) 应采用接口变更主动通知机制，变更接口的消费者能够及时得知接口的变更； 3) 应采用在线文档，接口文档

14、、开发手册等文档在线形式，确保文档更新及时。 b) 微服务测试：除采用常规的单元测试等测试方式，还应重点采用契约测试。 1) 测试解耦：应支持服务提供者和消费者的解耦，可以在没有提供者实现的情况下进行消费者的测试； 2) 应支持基于消费者业务逻辑，驱动生成契约文件。 7.2.2 部署与配置本项要求包括： a) 持续构建。 1) 应支持结构化的构建脚本，定期自动构建； 2) 构建环境和工具应有专门的人员负责； 3) 构建环境配置应标准化，有独立的构建资源池。 b) 持续集成。 1) 应至少每天集成一次； 2) 应具备专门的持续集成团队； 3) 代码集成应作为软件交付中的一个独立阶段； 4) 集成问题