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

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

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特征平台，深度整合大数据和风控算法，提升云端特征的生成和发布。

作者简介：

周俊鹏

2018年加入微财数科，基础架构高级工程师，擅长云计算、架构设计及中间件技术，参与了公司新一代金融云平台的研发与落地，维护微财数科中间件服务。

王利明

2017年加入微财数科，基础架构高级工程师，擅长前端、云计算、架构设计及中间件技术，参与了公司多个前端项目以及基础架构中间件的研发与落地。

周正航

2012年毕业于北京信息科技大学，10年互金领域研发经验，多次互金业务创业经验。目前在微财数科负责核心中台、支付系统、资金平台、轻资产导流平台的建设以及日常工作管理。善于通过技术手段在金融领域进行突破。

来源:微信公众号:微财技术沙龙

出处:https://mp.weixin.qq.com/s/3UC_JRP37t-wMQOCZ7iuNA