Cloud Native Healthcare Security

原文地址：https://alphahinex.github.io/2021/10/24/champ/

champ

---

description: "面向多云微服务架构新医保应用的 / 云原生应用管理平台"
date: 2021.10.24 10:24
categories:
- Cloud Native
tags: [Champ, K8s, Cloud]
keywords: Champ, Cloud Native, 医保

---

首先进行个简单的介绍：

东软医保云应用管理平台，这个名字比较长，所以我们内部起了个代号，即 Code Name —— CHAMP，
意为：Cloud Native Healthcare Security Application Management Platform，
是一个 面向多云微服务架构新医保应用的 / 云原生应用管理平台，
之后我会简称为云平台或 CHAMP。

再来介绍一下 面向多云微服务架构新医保应用：
2018 年国家医保局挂牌，随即便启动了新医保系统的建设。在系统建设初期，即确立了新医保应用要以分布式微服务架构为基础，同时适配多云环境。
新医保系统的发布版本，也会同时提供阿里云版、腾讯云版和开源版三套版本。
在国家医保局信息系统的建设中，核心业务区搭建在了阿里云上，公共服务区搭建在腾讯云上，
并明确要求，各地医保采用开源产品时，其稳定性、可管理性、性能等，要由承建商保证。

CHAMP 的目标，就是为新医保应用开源版本，提供稳定、高效、可管理的云平台运行环境。

云平台面对的难点，包括：

1. 新医保应用面向云，但不云原生 —— 在国家局，以及目前各省市的医保项目建设中，均是以云平台提供中间件服务，和应用部署虚拟机的方式进行建设。
2. 医保应用部署方案复杂 —— 据不完全统计，某个项目下发的部署包内包含的部署包、部署手册、数据库脚本，变更记录等文件共计 7k 余份，200+ GB
3. 在基数巨大的配置文件中，每个文件里还涉及大量需要调整的内容，比如有些服务间的 HTTP 调用是通过 ip 进行的
4. 国家局对新医保系统的云平台，明确提出了数据中台的需求，要求云平台包含分布式数据库，及大数据相关工具

为解决这些问题，我们的 CHAMP 具备如下特色：

1. 云原生 —— 对照 CNCF 发布的云原生路线图，CHAMP 覆盖了所有主要内容
2. 医保应用容器化 —— 使用下发的开源部署包进行镜像构建，使新医保应用能够以镜像的形式进行部署和分发
3. 医保服务整合 —— 发布形式基于 Helm Chart，配置中的服务地址以域名方式进行设置，由 k8s coredns 负责解析，简化部署及配置变更
4. 提供一站式解决方案 —— 包括 IaaS 层基础设施、PaaS 层支撑服务和数据中台、SaaS 层业务中台及子系统，其中分布式数据库以与三方数据库厂商合作的形式进行集成，大数据部分集成了公司内部的 SaCa 系列相关产品

对比公有云提供商，如阿里云、腾讯云、华为云等，我们的 CHAMP 在行业属性、性价比以及售后服务上具有绝对优势；
对比传统 IT 厂商，如创智和宇云和银海云平台，我们的云平台同时提供基于容器和虚拟机的部署模式，
并且在 网关、大数据相关服务上，有丰富的公司级产品作为支撑。

接下来我们看一下具体的场景和分析。

国家医保一张图中，明确划分了医保系统的分层模型，以及各组件、服务、系统所在的位置。

医保系统的约束，包括下发版本具有强弱约束和基础约束，以及整个系统由多个厂商共同建设。

医保系统对云平台的要求，包括：

1. 满足医保分布式云架构设计要求
2. 提供分布式服务支撑
3. 实现服务和资源的统一管理和分配
4. 保障业务的平稳运行和可持续发展

在这样的一个场景下，包括前期咨询团队与用户的沟通，我们得出用户最大的痛点 ——
国家局仅验证过阿里云和腾讯云，但
公有云提供商解决方案造价起步点高，私有云与公有云是两个团队，服务质量较难保证，缺少医保行业经验。

如何破题？带来我们的分析

首先，东软的优势：
在 IDC 中国今年发布的中国医疗保障信息系统市场份额报告中，东软集团以 27.9% 的份额，市场占有率第一，
东软的行业经验、服务质量，以及今年所有参与的医保项目中没有延期上线的东软速度，
均是东软集团在医保领域积累下来的优势。

其次，云原生的优势，包括：

1. 不绑定专有设备，可充分利旧，资源利用率高
2. 相比虚拟机或系统镜像，容器镜像具有更高的部署及启动效率
3. 健康检查、滚动更新、弹性伸缩、容器调度等原生特性，更有助于保障应用的高可用性
4. 服务网格，边车模式，无侵入式为应用赋能，提供链路跟踪、流量治理、灰度发布等高阶特性
5. 容器相对于虚拟机，具有更高的安全性

所以我们认为，结合东软集团与云原生技术的优势，我们能够为用户创造价值。

破题之后，我们来看下如何解题，即 —— 设计。

技术架构方面，以 Kubernetes 为根基，整合分布式数据库、数据治理、报表及数据可视化相关产品，提供医保系统所必需的支撑服务，
建设应用商店、监控告警及持续集成等上层应用。

总体架构分为平台管理中心和应用管理中心，分别面向不同角色的用户。

医保系统的部署，分为公共服务区和核心业务区，两个区域之间设有网闸，需通过服务网关进行通信。

资源规划方面，更多的考虑弹性，而不是一步到位，可充分利用已有设备，并且将计算资源和存储资源分别规划。

服务部署时，可采用应用商店形式，选择预置应用进行快速部署，方便快捷；
也可使用精心设计的应用管理功能，贴合传统模式部署习惯，降低上手门槛；
在易用性方面，也进行了大量的设计，如配置文件格式校验、多服务批量调整配置，和历史容器监控等。

安全方面：

1. 提供了基于 RBAC 的区分可使用权限及可分配权限的授权机制
2. 配有租户隔离、网络隔离、应用隔离三种隔离手段
3. 通过安全上下文，可以控制容器的准入策略
   此外，还会利用工具，对集群中部署的应用是否符合 NSA/CISA 发布的 k8s 加固指南要求进行扫描。

运维方面：

1. 提供了四个维度的可观测性，包括基于业务概览的应用可观测性、中间件可观测性、集群可观测性和计算资源可观测性
2. 通过多副本、负载均衡及滚动更新等策略，满足医保系统高可用性要求
3. 引入健康检查机制，为应用提供自愈能力，轻松应对应用自身故障、容器故障、集群节点故障
4. 应用的弹性伸缩，能有效应对业务洪峰的冲击；云原生应用的横向扩展能力及资源池的可扩展性，可满足业务的持续发展需求
5. 监控告警可有效监控应用状态及集群状态，在物理资源使用率达到阈值时，可触发告警通知，预防事故的发生

为了实现上述设计，在工程和过程领域，我们也进行了一些实践。

云平台在制作过程中，采用了 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 版本，并扩展行业线，对非医保行业应用提供更多适配。

最后进行一些简单的演示。