华泰证券：中间件全生命周期管理的实践

Posted 2021-06-08 银融时代

一、概述

开源中间件主要包含负载均衡（如nginx），消息中间件（如Kafka,Pulsar），分布式缓存（如Redis），分布式协调器（如Zookeeper），搜索引擎（如ElasticSearch）等。而中间件本身和现在比较火热的云原生概念又有着很深的联系。虽然云原生的三驾马车中没有中间件，但是中间件确是云原生的基石。中间件可以生长在物理机，虚机和容器上，DevOps编排的服务少不了对中间件的依赖，微服务本身的无状态性大多数是通过中间件的有状态性来解耦。同时为了保障业务系统的高可用，低延迟，独享等要求，中间件本身是需要支持横向扩展的，这里面不仅包含单服务的扩缩容，也包含着服务本身的可复制性。在华泰证券，我们经过将近两年的打磨，成功地打造出中间件的全生命周期管理体系，并将其全面推广到生产环境，支持多云（包括物理机，虚机，容器）。通过近乎于全自动的方式，做到少量人即可支撑起全华泰业务系统规模的能力。全生命周期行为按照时间先后顺序主要分为申请，创建，变更和运营监控，下面笔者将按照此顺序一一细细表达。

二、全生命周期体系

（一）全生命周期-申请

 中间件是为业务服务的，只有用户申请的资源才会发挥它的价值。一般情况下，申请方式主要分为两种：一种是向已存在的服务申请接入，另一种是基于业务隔离性要求申请新的中间件服务。针对第一种方式的申请必然配合有租户接入的管控。这其中依赖中间件自身的ACL能力是必不可少的，像Redis 6.x以后是支持ACL的；Kafka自身天然支持ACL，而我们为了适配华泰自身的认证体系，对其也做了部分改造。针对第二种申请方式，其实比较复杂的。因为每个中间件的差异性，我们需要为每个组件提供独立的表单，甚至由于版本的差异性，还需要为同一个组件的不同版本提供不同的表单。这显然不是我们可以接受的。经过思考，调研和可行性试验，我们选择了模板化的方式来解决这个问题。表单可基于模版来自动化创建。这块内容因为和后面的创建模块关系紧密，笔者这里先卖个关子，不做细说，在后面的模块中统一说明。

（二）全生命周期-创建

       创建属于全生命周期中比较重要的环节了。在前面说到，在创建的环节，我们是支持多云的，包括物理机，虚机和容器。其实这边统一看成虚机和容器即可，因为物理机可以等同于虚机看待。那具体怎么实现呢？
       首先来说下容器。自动化的方式往往伴随着通用化，面对众多的组件和其对应的版本，我们不可能为每一个组件做定制化适配。我们调研过fabric8，也调研过helm chart，但都被一一否决了。前者没法做到自动化新增组件的能力，而后者无法支持到自定义operator这种类型。最终经过可行性调研，我们使用了基于yaml模版的方式。

图1-1

       如图1-1所示，我们将yaml模版表和组件依赖表分离开，主要是考虑大部分组件的不同版本是可以复用同一个yaml模版，这样减少模版配置的冗余。当然这种分离也是为了全生命周期管理的扩展性提供支持。对于yaml模版的内容，我们制定了相应的规范。如果模版中存在可变量，可变量的内容需要用${my.,以}结束。如${my.password}，我们称之为这种参数为用户输入参数。my.这个前缀有一定的含义，表达的是用户自身传入的参数，因为yaml模版中的部分可变参数是不需要用户输入的，如集群本身的属性，镜像信息，或者是一些管理员要求的规范，我们称之为系统参数，以core.为前缀，在调用Kubernetes前由系统自动填充。具体示例可参见图1-2。

图1-2

       另外，刚才上文说到申请表单也是通过yaml模版来实现的。当用户申请某种组件，勾选对应的容器版本时，系统会自动获取到其对应的yaml模版，并将其解析，获取到其中的用户输入参数，以及对应的注释，默认值等。针对注释和默认值，我们也有对应的注释规范体现在yaml模版中。因这块相对简单，就不再赘述，示例也可参见图1-2。用户通过页面看到表单后，输入对应的用户输入参数，点击提交触发创建工单。待审批流完成后，系统会自动将用户输入参数和系统参数统一填充yaml模版，得到具体的yaml文件，进而触发Kubernetes的创建请求，请求容器服务的创建。因为中间件容器的创建过程比起一般的deployment类型要慢很多，通常会有一分钟以上的延迟，这边我们采取的是异步轮询来更新容器的信息，待容器服务创建成功后，将其对应的容器信息纳管到中间件体系中来进行管理。
图2

       整个处理逻辑如图2所示。我们使用yaml模版封装所有中间件所有版本的变化，yaml模版本身也支持operator这种复杂类型（当然需要你提前将你的operator注册到对应的Kubernetes集群中）。用配置封装所有变化的同时，也保证了灵活性和扩展性。这边有个小细节可能需要注意下，当kind类型为statefulsets或者Operator时，请求的url是apis开头（/ /apis/{apiVersion}/namespaces/{namespace}/{kind}s），而像secrets、services类型时则是以api开头。
       接下来谈谈虚机。有了容器的思路以后，虚机就可以复用上述的方案了。我们希望对于用户来说，无论使用虚机还是容器，看到的是相同的表单，对其屏蔽底层差异。故对于虚机，我们是使用脚本模版的思路来对其yaml模版，我们要求同一个组件同一版本的脚本模版和yaml模版中的用户输入参数一致。
       而在说明清楚整个处理过程前，我们先稍微说下脚本中心。在华泰因为DevOps体系的建立，我们提前布建了脚本中心，它通过salt纳管整体虚机和物理机资源。在脚本中心上我们提前将组件对应的脚本发布上去，并在中间件内部建立相应的映射体系，如图3。

图3

       虚机的自动化部署同容器差异不大，无外乎获取对应的脚本模版，填充后执行。但其中有两部分是存在差异的。第一部分是虚机IP的获取。众所周知，容器的地址是由Kubernetes统一分配的，但是虚机则不然，虚机需要我们的系统提前获取到对应的IP地址，而这里我们使用CMDB来获取相应的IP信息；另一部分则是虚机缺失容器中operator这种的编排能力，当遇到像Redis Cluster这种有状态且需要编排的集群服务时，是需要部分定制化工作的。在这里面，我们的做法是中间件整体层面抽离出一层通用层，我们称之为core层。如果有定制化的编排工作，由每一个中间件自身微服务层来完成，而core层不会做这种定制化的事情。
 

图4

       具体流程图见图4所示。因为物理机的处理方式等同于虚机，这边就不再赘述。

（三）全生命周期-变更

       全生命周期中变更主要针对单服务本身的扩缩容，参数修改和服务下线。本质是都是调用yaml模版或脚本模版执行，这里面就不展开说明，具体流程参见全生命周期-创建模块。

（四）全生命周期-运营监控

       这边要重点说一下运营监控环节。就跟很多游戏一样，满级后才是开始。同理，中间件服务创建后也才是开始，后面还有一系列的运营监控的工作需要承接。关于这块，之前我们调研过很多外部产品，每每做到这就会戛然而止了。但是在金融行业内，中间件太过重要，对于其的运营监控也要格外注意。
       那我们如何实现自动化管控的呢？在前文的铺垫中，我们得到无论是创建还是变更后的中间件集群信息数据都是纳管在中间件平台内的。我们针对每种组件提供一种collector远程采集器，这种采集器会自动获取和更新对应的其纳管的中间件服务信息，通过对应纳管的中间件服务对外暴露的接口实时采集监控指标（如Kafka的JMX指标，Redis的info/cluster指标），并将其发送到Kafka中，由华泰统一的APM平台进行采集，存储和告警。具体告警配置示例如图5。

图5

       这边的collector其实是借鉴了Prometheus中的exporter，但是没有直接使用，是因为其并不能完全满足我们的需求。首先，我们需要collector和中间件平台联动，当中间件服务新增，销毁或者发生变更后这边可以自动感知，不需要人工干预；其次collector中除了收集指标以外，还承载了心跳探活，额外的指标收集（如QPS加工计算，Kafka依赖的Zookeeper上信息收集）等一些基础告警能力；另外collector中打印的ERROR日志会自动被收集到APM平台触发告警，这些都是exporter不具备的。最后还有一点，华泰中间件是存在多云异地场景，collector需要一定的线程池管理能力和指标采集时延的要求。
       对于指标上报的格式我们是有严格限制，要保证采集数据进入时序数据库后是可以做到自由的聚合。
       其中有两个关键的字段，subsysno和extno，用于标识出具体的集群和节点。这样我们在运营报表展示的时候可以通过模版来灵活的适配。
       说到这里，就引出了下个话题，我们如何做到运营报表的自动化。我们采用的是grafana，通过grafana模版来实现。我们为每种组件提供若干个模版，用户在中间件平台上查看，系统在跳转grafana面板时会把对应的id带上，展示出其对应的内容。如图6和图7

图6

图7

       这里另外补充一点，一般情况下，运营报表中的时间范围如果选取过长，如一个月、半年这种，将会出现加载响应慢，甚至超时失败的情况。针对这块，我们在APM中也做了优化。后端时序数据库我们的指标主要采用ElasticSearch进行存储，指标存储时借鉴Kylin的预聚合思路，指标不仅会存储原始数据，也会存储其在不同粒度的聚合值（如按一分钟粒度聚合后存储到一分钟的索引中）。我们在grafana数据源配置的是ElasticSearch网关的地址，它会基于用户选择的时间范围智能地选择对应的查询索引，从而达到秒级的查询效果。后续如果有机会，这块也可以展开细说。

三、总结

       至此，中间件全生命周期的思路就已和大家介绍完毕。随着业务的不断发展，中间件在华泰的规模已经越来越大，并且已经进入往全面自服务自运营方向转换的赛道上。而全生命周期的纳管能力也成为其达到这个要求的核心能力，我们也会致力将此做全做厚。未来中间件不仅需要支持多云，还需要支持异地，支持对多地域进行纳管，打造真正意思上融为一体的集权管理系统。另外我们也会在租户管理和安全管理方面做进一步的尝试和研究，在全生命周期的体系下引入更多的组件来满足业务，建全整个中间件体系，同时也会以用户视角出发提供更多的自服务能力，降低用户的接入门槛，提升服务质量。

谷正亮 / 余奇 / 任良成 / 赵岩 / 徐文涛 / 赵一文 / 华泰证券股份有限公司 

（来自：上交所技术服务）