微财在构建企业级金融云服务上的探索和实践

一、金融云的背景以及存在的问题

金融行业的特殊性决定了对金融企业构建企业云服务时一定要满足企业对高稳定性和安全性的要求。传统的云服务在这两方面都不能完全满足，需要一定改进和优化才能符合金融企业的要求。微财数科之前已经有一套完整的云管理平台，但存在以下缺陷：

1. 构建类型支持少，构建速度慢。构建类型支持少，原平台只支持通用构建类型，编译阶段和构建阶段在一起，项目镜像不够精简，不支持自定义的 Dockerfile。构建性能方面表现为 Jenkins 集群白天繁忙，夜晚空闲，构建效率低。
2. 流量管理不够稳定和精细。原平台服务发现、流量管理依赖 Registrator + Etcd + Confd + Nginx 的组件组合，在持续发布的过程中，其中一个组件出问题就会导致服务的流量切换故障。并且仅支持了 Rolling（滚动）的方式去发布服务，这种发布方式缺乏精细的流量控制和管理。
3. 安全管理不规范。Web 终端开启，方便了开发人员进入容器排查服务问题，同时也带来了安全隐患，并且存在没有命令白名单和网络不隔离带来的风险。
4. 风控业务支撑不足。风控平台程序的特点是负载高、实例多、计算密集、迭代发布频繁。这种业务场景，按照普通的云平台建设是不能满足的。
5. 审计不全面。平台中构建日志只能查看最近一次构建日志，服务操作的日志简单，以及 Web 终端没有命令审计。
6. 缺乏统一的监控和告警。集群容器的监控采用 cAdvisor 采集，存储 Prometheus，使用 Grafana 可视化。同时采用 Zabbix 进行 CPU、内存、文件系统以及网络的监控，并且还有一些自定义的监控告警。总之就是依赖组件多，不好维护，不统一。

二、微财的解决方案和实践

为了提升公司云服务的可靠性和安全性，以及公司 CI/CD 的效率，我们基于 Kubernetes 构建公司新一代的云平台，逻辑架构图如下：

2.1、构建镜像

新平台构建不再依赖 Jenkins，使用构建脚本充分利用集群的大资源池构建，Build In Pod。构建完成推送镜像仓库后，构建容器销毁，做出资源释放，这样做有三个好处：

• 提高了构建效率，并发构建表现更优，解决了 Jenkins 集群白天繁忙构建效率低的问题
• 集群的资源得到充分的利用，Jenkins 的机器资源也可加入集群中
• 对平台来说，减少了一个中间件的维护

另外微服务时代，所使用的开发语言多样（Java，Golang，Python，NodeJS 等），且项目的构成也多样，比如类似 GitHub 上的开源项目，代码根目录直接就有 Dockerfile 文件的情况。我们在新的平台中支持了四种构建方式：通用构建、编译和构建分离、代码内 Dockerfile 以及自定义 Dockerfile。尤其是编译和构建分离（多阶段构建）的方式，精简了镜像，直接节约了镜像的存储成本。

2.2、流量管理

新平台不再依赖同步 Nginx 的 Upstream 做服务发现，利用 Service 资源对象来选择后端的 EndPoint。利用 Istio 的 VirtualService 资源对象来绑定 hosts 做路由转发，底层是利用 Envoy 做路由转发，性能可与 Nginx 比肩。这么做的优势是摆脱了一堆组件来实现服务发现的依赖，自从新平台上线后实现了流量管理的零故障。

同时业务驱动我们要有精细化的流量切换管理，比如金丝雀发布（灰度发布）和蓝绿发布。这两种发布方式的优点是可以快速回退版本，最大程度减少用户暴露在错误代码的时间，原生的 Kubernetes 只有 Rolling Update 的更新方式（启动对应比例或者数量的容器，销毁对应比例或者数量的容器，直到发布完成）。

所以我们基于 Istio 的流量管理实现了蓝绿发布和金丝雀发布，以金丝雀发布为例，使用 DestinationRule 定义新老版本的 Subset，然后再使用 VirtualService 控制打到新老版本的流量权重，来实现对新版服务的灰度验证，流程图如下：

2.3、安全保障

云平台的安全，关系着集群的安全、服务的安全以及数据的安全。尤其是数据的安全，在金融行业显得尤为重要，需要云平台有更严格的权限控制和操作审计，通过以下几个方面，新的云平台做到了权限控制、资源隔离、操作详细审计，兼顾效率的同时最大限度的保障了平台的安全：

权限控制

• 资源分组，各组资源隔离
• 角色的划分，细粒度的角色权限分层划分

加固 Web 终端

• Web 终端 Shell 命令审计
• 进入服务运行操作的命令白名单，屏蔽危险的命令，比如 rm 命令等
• 日志安全终端：与集群网络隔离的亲和容器的终端，仅有查看日志的功能

操作审计

• 记录详细的镜像构建操作
• 记录详细的服务发布操作
• 服务发布动作在企业微信群告警

2.4、风控服务支持

风控服务是微财数科的重点服务，服务的特点前面也提到：负载高、计算密集、实例多、迭代发布频繁等。我们的云平台为了满足风控的要求做了以下特殊策略或者改造：

在集群 Node 硬件配置不统一的背景下，对于风控负载高、计算密集的服务，如果调度到硬件配置低的机器上，可能会导致两个问题：一个是自身的延时过高，另一个是会影响到别的业务线的服务。针对这样的情况我们做了两种调度策略：

• 获取服务器的压力数据，筛选出压力相对小的机器设置更高的调度优先级。
• 服务器打标签，人工标记性能更好的新机器作为调度首选。

对于实例多、迭代频繁，我们之前依赖 Nginx 的时候，由于节点多，滚动发布的过程中服务流量密集切换会导致 Nginx 频繁 Reload，进而导致 Nginx 机器负载陡然升高，影响业务稳定。针对这种业务我们新老云平台分别做了改造：

• 老平台依然是 Nginx 做流量管理，我们使用了 ngx_http_dyups_module 这个模块，直接更新 upsteam 内存的方式避免 Nginx 频繁 Reload 的方式解决了此问题。
• 新平台使用 Kubernetes Service 对象来发现流量，可以满足对风控服务的发布要求。

2.5、统一监控告警

云原生时代 Prometheus 已经成为 Kubernetes 集群以及组件的监控标准，目前全方位的监控均采用 Prometheus 来实现，包括宿主机监控，集群监控，组件监控，降低了监控平台的维护成本。建设了告警平台，统一了告警的机制。

三、方案的效果

3.1、稳定性的提升

高可用的 Kubernetes 集群，节点故障都可实现转移，目前集群可用性达到了 99.99%，改变老平台服务发现导致流量故障率月均 1 次的问题。

3.2、安全性的提升

• 容器 Web 终端屏蔽敏感命令
• Web 终端命令审计
• 提供网格隔离的 Web 日志安全终端，只能查看日志用

3.3、效率提升

很明显的就是构建效率的提升，直接提升了服务 CI/CD 的效率，根据现有集群的统计，构建效率提升 26%。

3.4、技术支撑

• 支持了 4 种构建方式，多构建方式让平台更灵活的去创建构建，不用再强制项目去适应平台
• 实现了金丝雀发布和蓝绿发布，降低发布带来的错误或者不一致的风险
• 统一了监控告警，有统一的地方去查看监控和维护告警

3.5、风控业务支撑显著

不论是风控服务的稳定性，还是发布的流畅度都比之前好很多，大大降低了风控业务的故障率。

四、未来的思考以及下一步的规划

金融行业以及我们自身的业务形态也不是一成不变的，我们需要时刻从内外部挖掘我们的云平台的功能需求，更好的为我们金融业务服务。

4.1、与业务深度融合，继续提升稳定性

• 场景一：用户触达活动导致的流量暴增

此场景需要限流和熔断，业务也可以做，但是需要改造业务代码。新的云平台作为基础设施计划实现无代码侵入的熔断、限流以及链路追踪，从基础层面来保护我们的微服务以及系统整体的健壮性。

• 场景二：代码安全/Bug 检查

金融的场景下，安全是重中之重，目前各团队有自己的代码检查方式，我们计划把执行代码检查做到新云平台的构建流程执行之前，支持通过静态代码分析扫描来检测项目中的 Bug、代码错误和安全漏洞，及时发现问题。

4.2、构建云原生 AI 应用

为了让风控平台的开发人员更容易、更高效地在基于 Kubernetes 的容器集群环境构建 AI 系统，提高生产 AI 应用的能力。我们计划开始构建 AI 特征平台，深度整合大数据和风控算法，提升云端特征的生成和发布。

作者简介：

周俊鹏，微财数科高级工程师

李军，微财数科技术总监

王利明，微财数科高级工程师

周正杭，微财数科资深工程师