首先进行个简单的介绍：
东软医保云应用管理平台，这个名字比较长，所以我们内部起了个代号，即 Code Name —— CHAMP，
意为：Cloud Native Healthcare Security Application Management Platform，
是一个 面向多云微服务架构新医保应用的 / 云原生应用管理平台，
之后我会简称为云平台或 CHAMP。
再来介绍一下 面向多云微服务架构新医保应用：
2018 年国家医保局挂牌，随即便启动了新医保系统的建设。在系统建设初期，即确立了新医保应用要以分布式微服务架构为基础，同时适配多云环境。
新医保系统的发布版本，也会同时提供阿里云版、腾讯云版和开源版三套版本。
在国家医保局信息系统的建设中，核心业务区搭建在了阿里云上，公共服务区搭建在腾讯云上，
并明确要求，各地医保采用开源产品时，其稳定性、可管理性、性能等，要由承建商保证。
CHAMP 的目标，就是为新医保应用开源版本，提供稳定、高效、可管理的云平台运行环境。
云平台面对的难点，包括：
- 新医保应用面向云，但不云原生 —— 在国家局，以及目前各省市的医保项目建设中，均是以云平台提供中间件服务，和应用部署虚拟机的方式进行建设。
- 医保应用部署方案复杂 —— 据不完全统计，某个项目下发的部署包内包含的部署包、部署手册、数据库脚本，变更记录等文件共计 7k 余份，200+ GB
- 在基数巨大的配置文件中，每个文件里还涉及大量需要调整的内容，比如有些服务间的 HTTP 调用是通过 ip 进行的
- 国家局对新医保系统的云平台，明确提出了数据中台的需求，要求云平台包含分布式数据库，及大数据相关工具
为解决这些问题，我们的 CHAMP 具备如下特色：
- 云原生 —— 对照 CNCF 发布的云原生路线图，CHAMP 覆盖了所有主要内容
- 医保应用容器化 —— 使用下发的开源部署包进行镜像构建，使新医保应用能够以镜像的形式进行部署和分发
- 医保服务整合 —— 发布形式基于 Helm Chart，配置中的服务地址以域名方式进行设置，由 k8s coredns 负责解析，简化部署及配置变更
- 提供一站式解决方案 —— 包括 IaaS 层基础设施、PaaS 层支撑服务和数据中台、SaaS 层业务中台及子系统，其中分布式数据库以与三方数据库厂商合作的形式进行集成，大数据部分集成了公司内部的 SaCa 系列相关产品
对比公有云提供商，如阿里云、腾讯云、华为云等，我们的 CHAMP 在行业属性、性价比以及售后服务上具有绝对优势；
对比传统 IT 厂商，如创智和宇云和银海云平台，我们的云平台同时提供基于容器和虚拟机的部署模式，
并且在 网关、大数据相关服务上，有丰富的公司级产品作为支撑。
接下来我们看一下具体的场景和分析。
国家医保一张图中，明确划分了医保系统的分层模型，以及各组件、服务、系统所在的位置。
医保系统的约束，包括下发版本具有强弱约束和基础约束，以及整个系统由多个厂商共同建设。
医保系统对云平台的要求，包括：
- 满足医保分布式云架构设计要求
- 提供分布式服务支撑
- 实现服务和资源的统一管理和分配
- 保障业务的平稳运行和可持续发展
在这样的一个场景下，包括前期咨询团队与用户的沟通，我们得出用户最大的痛点 ——
国家局仅验证过阿里云和腾讯云，但
公有云提供商解决方案造价起步点高，私有云与公有云是两个团队，服务质量较难保证，缺少医保行业经验。
如何破题？带来我们的分析
首先，东软的优势：
在 IDC 中国今年发布的中国医疗保障信息系统市场份额报告中，东软集团以 27.9% 的份额，市场占有率第一，
东软的行业经验、服务质量，以及今年所有参与的医保项目中没有延期上线的东软速度，
均是东软集团在医保领域积累下来的优势。
其次，云原生的优势，包括：
- 不绑定专有设备，可充分利旧，资源利用率高
- 相比虚拟机或系统镜像，容器镜像具有更高的部署及启动效率
- 健康检查、滚动更新、弹性伸缩、容器调度等原生特性，更有助于保障应用的高可用性
- 服务网格，边车模式，无侵入式为应用赋能，提供链路跟踪、流量治理、灰度发布等高阶特性
- 容器相对于虚拟机，具有更高的安全性
所以我们认为，结合东软集团与云原生技术的优势，我们能够为用户创造价值。
破题之后，我们来看下如何解题，即 —— 设计。
技术架构方面，以 Kubernetes 为根基，整合分布式数据库、数据治理、报表及数据可视化相关产品，提供医保系统所必需的支撑服务，
建设应用商店、监控告警及持续集成等上层应用。
总体架构分为平台管理中心和应用管理中心，分别面向不同角色的用户。
医保系统的部署，分为公共服务区和核心业务区，两个区域之间设有网闸，需通过服务网关进行通信。
资源规划方面，更多的考虑弹性，而不是一步到位，可充分利用已有设备，并且将计算资源和存储资源分别规划。
服务部署时，可采用应用商店形式，选择预置应用进行快速部署，方便快捷；
也可使用精心设计的应用管理功能，贴合传统模式部署习惯，降低上手门槛；
在易用性方面，也进行了大量的设计，如配置文件格式校验、多服务批量调整配置，和历史容器监控等。
安全方面：
- 提供了基于 RBAC 的区分可使用权限及可分配权限的授权机制
- 配有租户隔离、网络隔离、应用隔离三种隔离手段
- 通过安全上下文，可以控制容器的准入策略
此外，还会利用工具，对集群中部署的应用是否符合 NSA/CISA 发布的 k8s 加固指南要求进行扫描。
运维方面：
- 提供了四个维度的可观测性，包括基于业务概览的应用可观测性、中间件可观测性、集群可观测性和计算资源可观测性
- 通过多副本、负载均衡及滚动更新等策略，满足医保系统高可用性要求
- 引入健康检查机制，为应用提供自愈能力，轻松应对应用自身故障、容器故障、集群节点故障
- 应用的弹性伸缩，能有效应对业务洪峰的冲击；云原生应用的横向扩展能力及资源池的可扩展性，可满足业务的持续发展需求
- 监控告警可有效监控应用状态及集群状态，在物理资源使用率达到阈值时，可触发告警通知，预防事故的发生
为了实现上述设计，在工程和过程领域，我们也进行了一些实践。
云平台在制作过程中，采用了 Scrum 结合 KANBAN 的敏捷开发模式。
包含三个角色：Product Owner、Scrum Master、开发团队；
两周一个 Sprint，Sprint 开始时进行目标沟通及任务分解，中间过程中通过每日站会及时跟踪进度、排除阻碍性问题；
结束时进行复盘及回顾，总结不足，并在之后的迭代中进行改善。
看板的使用，为物理看板和电子看板相结合：物理看板跟踪总体目标达成情况，电子看板侧重任务分解及每个 WBS 的状态。
电子看板的每个横向泳道，对应每轮迭代的目标，纵向分为 To-Do、Doing、To verify 和 Done 四个状态。
这是我们 DevOps 的整体流程：以 git 为中心，秉承 Everything as code 的原则，使用配置库管理系统的配置，
并由 CD 工具负责监听配置的变更，进而同步到部署环境中。
开发过程中，采用 git 分支开发模型的一个最佳实践，设有稳定的 master/develop 分支，以及不同作用的临时分支。
所有代码通过 MergeRequest 的形式进行提交，由 MR 触发静态代码检查、自动化测试及 Code Review；
稳定分支触发构建，包括打包、构建镜像、发布制品及更新配置库。
通过 CNCF 的 ArgoCD 持续交付项目，实现配置库内的应用清单与应用运行时的同步。
此外，云平台引入了开源产品 Reloader 来实现配置中心的配置热更新功能，Reloader 以控制器模式工作，通过监控配置变化，触发应用的滚动更新。
云平台的性能，也是我们重点关注的内容。在项目结项前，我们对比使用 CHAMP 部署及采用传统方式部署的相同业务系统的性能表现，
得出 TPS 损耗在 5% 以内，可以满足业务系统需求的结论。
在实际医保项目上线前的压测中，联网结算综合场景，90% 的业务请求，300 并发响应时间在 2s 以内，500 并发在 3s 以内。
今年 9 月份，我们的云平台迎来了第一个地市级医保项目 —— 临沂市医疗保障信息平台。
项目的建设范围包括云平台，以及医保核心业务和公共服务。
临沂拥有 1kw 人口，是山东省人口规模最大的地市，
在临沂，我们的云平台分为两个区域部署（公服区及核心区），60个节点，共计运行 1k+ 容器。
我们还规划了云平台的发展路线图，计划在明年继续迭代云平台 2.0 版本，并扩展行业线，对非医保行业应用提供更多适配。
最后进行一些简单的演示。
