云原生技术体系在寿险行业的规划和落地实践-周建华

云原生技术体系在寿险行业的落地实践 太平洋寿险/周建华 为什么要建设云原生技术体系 应用系统数量较多，主要通过三种方式建设：一是自研，二是成品采购，三是定制化开发 很多老旧系统主要靠定制化开发和成品采购，当前绝大部分系统已经转变为自研，但存量系统基数仍较大 系统间的技术架构差距很大，全面保证代码质量和可维护性难度较大 自研系统 定制化开发系统 成品采购系统 1、完全由自身科技团队设计并主导开发的系统 2、主要的代码编写往往还是外包团队参与较多 3、业务需求驱动 1、只负责需求，系统的架构设计及具体开发交由第三方公司实现 2、系统间有部分集成 1、通过供应商进行标准软件采购 2、提供专人进行系统维护 3、与其他系统集成度不高 系统架构不统一 研发流程不统一 1、架构设计语言不一致 2、架构设计标准不一致 3、对非功能需求的架构设计差异性很大 1、研发流程在各个团队的实际落地差异较大 2、自动化程度不高 交付质量不统一 平台化功能建设少 1、交付质量偏差较大 2、系统监控不完善 3、不同团队之间的差异大 1、虽然采用分层架构，但平台化的能力下沉不够 2、核心能力沉淀不足 3、公共技术组件支持能力不足 外包 外包 外包 外包 外包 外包 外包 外包 外包 外包 外包 外包 外包 外包 外包 外包 外包 外包 开发人力属于是外包密集型，具体编码工作以外包为主，管理和沟通的复杂性很高 系统开发由业务方”散点式“需求驱动，缺乏体系化的架构规划 项目团队 职场A 职场B 职场C 外包 外包 项目经理 架构师 项目团队 职场A 职场B 职场C 外包 外包 项目经理 业务对于需求上线时间要求很高，导致开发团队没有足够的时间来进行系统优化和质量保障 项目团队 开发 职场A 职场B 职场C 项目经理 架构师 外包 外包 目标定义 灵活的研发模式 标准化研发工艺 VS 优点： 开发团队自由度高 便于快速外部技术引入 缺点： 不同团队的交付结果偏差大 对团队的技术能力要求很高团队沟通成本高 优点： 结果偏差小，可复制。 降低错误率和风险。 容易产生共识，协同作业更加顺畅。 缺点： 需要严格管控，需要投入一定管理成本 需要一定的培训成本 有时候可能牺牲创新速度 形成一套标准化的架构设计语言、一个标准化的服务开发平台以及一套标准化交付流水线 一套架构设计语言 一个开发平台：让应用专注业务代码 一套交付流水线：自动化软件交付 1、形成统一的架构设计方法论和设计语言，提升架构设计和管理的规范化和标准化水平。 2、降低架构治理的难度，形成标准化的企业架构视图。 1、应用系统代码聚焦于业务逻辑开发 2、将服务治理、高可用能力、可运维性、可观测能力等通用基础能力下沉至PaaS平台 3、通过标准化应用开发脚手架的建设，快速开发上层业务应用 1、以自动化为最终目标，逐步减少流程中人工处理的环节，形成端到端的自动化交付工艺 2、针对业务特性，形成稳敏双态的流水线，适应于两种不同交付需求 应用 应用 应用 应用 服务治理框架 容器平台 分布式中间件 分布式数据库 应用开发脚手架 TDSQL OB PaaS IaaS 架构蓝图建设为架构蓝图的规划和建设提供体系化的支撑，为重点业务和创新业务提供加速突破所需的可配置、可复用、可组合的核心业务能力应用服务 寿险新一代稳敏兼顾的云原生技术体系 一个开发平台一套交付流水线 通过剥离和沉淀通用基础技术能力构建自动化的端到端的现代化交付构建现代化开发平台，大力提升业流水线，逐步替代人工处理环节，务应用的响应速度和交付质量满足太保各类型业务的交付需求 一套架构设计语言形成寿险统一的企业架构元模型和方法论，规范企业架构相关活动，提高企业架构规划、演进和治理的效率和效果人员能力建设构建满足生产体系能力要求的胜任力模型，体系化评估和提升参与人员和团队的能力，保障应用系统生产体系的持续完善和演进 架构蓝图演进方向 基于云原生技术体系架构，结合太保寿险实际情况，建设符合太保寿险实际情况的稳敏兼顾的云原生研发体系来支撑“两个一”所要求的战略目标。形成太保寿险的云原生能力成熟度模型做为体系建设的依据，评估和指导规划和实施，确保整个建设过程的全面 性、有效性和先进性。 技术架构演进方向 部署发布服务注册服务容错服务治理 应用云原生 应用运维架构设计开发构建测试管理 企业架构框架和组织能力提升方向 资源管理运维保障研发测试应用服务 技术架构云原生 云原生体系能力模型 安全云原生* 应用安全基础架构安全基础设施安全研发运营安全 运维安全 以云原生能力成熟度模型（技术架构、应用）作为输入，结合金融行业的特殊性及寿险技术体系总体目标，对模型进行调整，制定适合寿险的云原生成熟度评估模型。 云原生成熟度评估模型-技术架构云原生 云原生成熟度评估模型-应用云原生 寿险云原生成熟度评估模型 根据“一个开发平台”、“一条流水线”的总体规划，对技术架构模型进行调整。 能力域 建设领域 开发平台关键维度 流水线关键维度 资源管理域 计算环境 √ × 网络环境 × × 存储环境 × × 融合调度 √ × 维保障域 基础运维 √ × 可观测 √ × 高可用 √ × 研发测试域 应用研发 × √ 应用测试 × √ 应用服务域 应用中间件 √ × 应用治理 √ × 应用编排部署 × × 根据“一个开发平台”、“一条流水线”的总体规划，对业务应用模型进行调整。 能力域 建设领域 开发平台关键维度 流水线关键维度 基础设施域 基础设施资源 √ × 基础设施运维 √ × 应用研发域 架构设计 √ × 开发构建 × √ 测试管理 × √ 部署发布 × √ 服务治理域 注册发现 √ × 流量管理 √ × 服务容错 √ × 服务降级 √ × 故障注入 × × 链路追踪 √ × 应用监控 √ × 日志管理 √ × 配置管理 × √ 一个开发平台相关 交付流水线相关 两个都相关 云原生技术架构评估模型共包括6个能力域、11个建设领域、40个过程项。 结合“一个开发平台、一套交付流水线”的目标，开发平台涉及7个建设领域、23个建设领域。交付流水线涉及4个建设领域、17个过程项。其中“部署分发”过程项两者均有涉及 资源管理域 运维保障域 研发测试域 应用服务域 应用开发域 服务治理域 计算资源 融合调度 基础运维 可观测性 高可用 研发支撑 测试支撑 应用中间件 架构设计 服务治理 配置管理 资源及运行时管理 调度机制 自动化程度 日志 应用高可用 版本管理 测试分层策略 共享化 架构设计 注册发现 配置管理 托管程度 监控告警 监测指标 容灾备份 部署与发布模式 代码质量管理 服务化 流量管理 弹性能力 链路追踪 组件服务化 部署流水线 数据变更管理 开发能力 服务容错 部署分发 环境管理 度量指标 服务降级 变更管理 度量驱动改进 链路跟踪 构建实践 应用监控 持续集成 日志管理 研发需求管理 现状及差距分析 （1）一个开发平台 01 02 03 04 弹性可伸缩 1、资源100%容器化 2、容器及服务节点按需扩容，提高资源使用率 3、资源扩容自动化，减少人工操作，提升突发流量场景的响应能力 系统可观测 1、建立统一的监控管理体系 2、丰富监控维度和监控指标 3、监控数据分角色管理 服务可治理 1、完善微服务治理体系 a.完善应用限流策略 b.完善应用降级策略 c.完善应用扩缩容策略 能力可共享 1、沉淀标准化方案：将服务治理体系沉淀至云原生平台，如服务限流等 2、沉淀非业务能力组件：通用能力沉淀至云原生平台，如弹性能力、可观测能力、灰度能力。 计算资源 服务治理 应用中间件 融合调度 基础运维 高可用可观测性 *详细评估表见后 任务调度 分布式缓存 分布式数据库 消息队列 微服务网关 PaaS服务组件 应用弹性 流量限流 熔断降级 服务注册发现 应用弹性&服务治理 AutoScaling IaaS层（多云环境） 容器编排 容器管理 存储管理 镜像仓库 容器平台 云原生可观测体系 打造云原生监控体系，提升运维效率 指标 链路 日志 系统层 CPU 内存 磁盘 I/O 网络层 API网关 Nginx F5 微服务网关 中间件 数据库 消息队列 缓存 。。。 应用层 系统日志 业务埋点 APM 。。。 覆盖全链路的对象观测 服务发现 负载均衡熔断限流 负载均衡 熔断 限流 服务发现 SDK模式 Sidecar模式 应用应用应用应用 限流 熔断 负载均衡 服务发现 业务逻辑 SDK 业务逻辑 限流 熔断 负载均衡 服务发现 业务逻辑 Sidecar 业务逻辑 统一PaaS平台 营销展业系统 核心业务系统 ... APIGW TSF DevOps SLB PaaS服务 Kafka RabbitMQ TDMQ TMF KMS 对象存储 数据库 Redis *已具备 *未具备 日志中心 监控告警 认证鉴权 ... 云原生底座 K8S容器编排 容器网络 资源管理接口 IaaS接口 信创/X86 计算 存储 网络 平台化能力 。。。。 业务核心关键能力2 业务核心关键能力1 寿险业务应用 IaaS基础资源 统一底座、统一账户、统一运维、统一监控、按需扩展 （2）一条交付流水线 “一套交付流水线”总体目标 01020304 自动化一体化数据化智能化 协同公司各开发团队，建立统一持续交付流程与规范，自动化研发过程，减少人工参环节，打破部门壁垒，提升需求交付能力 聚焦研发过程，打通全流程工具链，形成一体化企业级Devops平台，提升IT持续研发、集成、交付、部署能力 建立完善的研发管理度量体系，实现研发过程“端到端”监控，实现需求、功能点、代码、质量、成品、环境的全过程追溯能力。 通过数据智能技术在DevOps体系中的运用，利用自动化代替重复性的工作，进一步提升软件工程师的工作效率和体验 ”一条流水线“差距分析总结 部署与发布 测试管理 配置管理 度量与反馈 环境管理 CI/CD 优化系统发布模式，实现自动化发布，并支持灰度发布 4 明确研发标准，并将标准下沉至研发平台，减少团队间的沟通成本，降低平台的使用门槛，提升团队间的协同效率 3 简化研发审批流程，减少研发过程中的审批环节；明确各角色职责，减少不必要的沟通成本。 2 提升研发自动化程度，减少人工参与环节，提升标准化程度；提升研发工具间的集成，提升需求交付能力 1 建设目标一：提升研发流程自动化 建设目标二：工具链整合，平台一体化 多平台 CD CI PaaS 测试平台 云平台 一站式平台 协同平台 建设目标三：建立完善的研发效能度量体系 平均需求交付周期需求吞吐量 完成计划率 平均开发交付周期平均测试交付周期 交付效率 1、从端到端的交付效率、交付质量、交付能力三个维度定义度量指标体系。 变更频率变更前置时间变更失败率缺陷修复时长 。。。。 交付质量 2、指标体系包括需求、开发、持续集成、 测试、发布等关键环节 3、兼顾过程和结果的度量。 交付能力 代码提交频率测试自动化率持续集成时间自动化部署率部署时长 。。。。 建设路径 建设领域建设主题建设项 云原生成熟度模型对于云原生能力的二次拆解，和云原生能力相比粒度适中，可操作性更强 缩小对应建设领域的重要建设方向，一个改进主题可以提升多个建设领域 基于建设主题的分解的可执行的云原生能力提升活动，每个举措可以落地为具体的、可执行的项目 10个8个30+个 通过提升资源池化 提升应用弹性能力，降低平台TCO 价值 ✓提升业务支撑能力，缩短应对突发流量的响应时间 ✓降低资源成本和运维成本 ✓统一底座，降低迁移成本 应用迁移量 资源利用率 扩容时间 100% 60% 30s 资源调度 提升研发效能管理能力，覆盖完整的软件研