作者：郭洋

内容简要：

一、云原生启动背景

二、容器化落地

三、比心云平台建设

四、研发效能工具建设

五、未来展望

一、云原生启动背景

（一）云原生的理解

云原生的架构是可弹性、可管理、可观测、自动化、并且容错性比较高的一种架构。

业内普遍的一些技术体现，包括容器、微服务、声明式的API、服务网格、不可变的基础设施，还有DevOps和12因数，只要应用符合这12因数，那么它的应用架构就符合云原生的架构理念。

很多人问Docker或K8s是否算是云原生技术，我觉得这种理解比较片面，云原生更多的是一种技术和指导思想，我认为应用天生适合运行在云上，并且能够让应用运行在任意云上，这种云包括公有云、私有云和混合云。

（二）云原生的价值

接下来我将从以下三个方面谈一下我对云原生价值的理解。

在运维价值方面，首先它屏蔽了底层的基础设施和底层的异构环境，这一点是比较重要的，因为它让基础设施成为了一个比较标准化的环境。其次是管理方便和高效，如果问一个运维，管理2000台服务器和管理2000个Docker相比哪个相对简单，相信运维同学给出的答案是管理2000个容器更简单，这一点我深有体会。目前，整个比心有大概超过5000个容器，对于运维团队来说，只需要一位运维人员就能够满足日常的管理工作。

在业务价值方面，云原生具备弹性高可用，并且稳定性更高。对于K8s的这个架构来说，K8s天生就具备弹性的能力，它让我们无需在传统的ECS去构建这一块的能力，让编码更简单。其次是高可用，我们使用了K8s之后，我们的横向扩容能力以及基础设施的稳定性更高，解决故障更方便。还有就是降本，我认为降本有两个层面，不仅是基础资源的降本，还能帮助企业业务功能迭代更快，构建平台成本更低。比心在这一块做了很多工作，基础设施通过资源的压缩，已经让CPU使用率大大增加，让我基础设施的成本更低。关于业务功能迭代这一块，尤其是在做CICD这一块，让我们的整个流程更简单，构建速度更快。

在技术价值方面，首先是以K8s为基石带来的整个生态发展，现在更多的比如Service Mesh技术，边缘计算等，更多的是基于K8s进行部署。这并不是说它只能在K8s上部署，只是说以K8s的方式部署可以让我们更简单方便，它带来了整个生态的发展。第二点是技术文化氛围的沉淀，企业更容易吸引优秀的人才，这对于技术人员来说是一件重要的事情。因为很多技术人员更希望待在技术氛围好，或者是具有前沿技术优势的企业，比如在面试的时候经常会有面试者询问，公司是否有在使用容器或者K8s这类技术，因此我觉得有这一块的技术落地，能够吸引更多的人才。

（三）微服务带来的挑战

微服务带来的挑战就是在数字化时代对基础设施的弹性、时效性提出了更高的要求。

首先是应用方面，第一点就是应用的规模比较大，自从使用了微服务架构之后，我们的应用从原来的几十个已经发展到如今的六百多个应用，规模翻了好几十倍。第二点是我们在微服务落地过程中，发现资源使用率比较低。

其次在业务方面，会出现十倍流量洪峰，这对我们的稳定性或者高可用提出了更高的要求，尤其是在直播业务，有时可能因为一个活动就会导致我们的流量成十倍或者二十倍的陡增。

最后是在运维方面，服务器的数量比较多，管理成本比较高。上文提到比心的服务器数量包括容器化数量，已经达到了5000+的规模，运维管理成本较高。

二、容器化落地

（一）集群设计

接下来分享关于比心容器化落地的一些情况。

首先是集群的设计，目前比心集群设计的第一点是采用了多集群高可用部署。当时在选型的时候也是充满纠结，因为我们测试了很多，包括自建，阿里云的ACK等，最终在生产上我们选择了自建K8s加上阿里云的ACK，采用多集群的部署模式。

第二点是不同业务独立网关入口，我们每个业务会有独立的网关，流量打进来后，我们将它进行区分与分离，避免不同业务之间互相影响。

第三个是我们采用了多集群管理控制平台，比心自研了一个可靠的平台，这一点在后面会阐述。通过使用这个平台我们可以对K8s多集群进行管理调度，让我们不同的应用和任务下发到不同的集群。

其次想谈一下集群设计的思想，这边给团队提出了一“纵”两“横”的思想。一“纵”表示服务器配置可以纵向地扩展，这是基于阿里云的能力。

目前我们使用的服务器有一些普通ECS和神龙服务器，配置规格普遍在64C 128G或者神农的104C 384G机型。基于阿里云神龙服务器的纵向扩展能力，如果未来资源不够了，我们可以把它扩到更高规格，比如300+C 700+G的服务器资源。

两“横”的第一横是我们的K8s Node可以横向扩容，这 基于K8s本身的横向扩展能力。目前社区K8s提供的标准大概是能扩容到5000个节点，很多大厂在基于K8s优化的基础上，已经能够做到上万节点。

对于我们来说，保守估计K8s集群扩容到3000个节点是没有问题的，基于我们现在整个集群的设计，扩容10倍～20倍，在这一个横向的能力上是没有问题的。

两“横”的第二个横是K8s集群数量的增加。上文提到比心有一个自研的比心云平台，支持K8s的横向扩展能力是支持。

基于这一“纵”两“横”，我们整体K8s的扩容能力可以无限增加，未来能够支撑10倍、20倍甚至上百倍的业务发展。

（二）容器化的里程碑

下面简单聊一下比心容器化的里程碑。

目前，自建K8s集群测试环境已经在2019年3月份 100%容器化，UAT环境也在2020年9月份完成了。

生产环境目前采用的是自建和阿里云的ACK，这一点在2021年3月份已经达到了99%，剩下的1%基本是一些有状态的应用。容器化整体完成得比较好，已经全面达到99%。

UAT环境和生产环境和测试环境的跨度时间比较长，是因为我们UAT环境和生产环境是一起做的，为了保证环境的一致性，并且我们是一个个团队去推行的，所以在保障业务稳定性的前提下，整体的容器化的进度还算不错。

（三）降本

在容器化之后，整个容器化的降本达到了以下效果。

首先是在线业务的资源使用率从5%提升到20%以上，也就是整体的资源使用率之前是很低的状态，经过容器化之后达到了20%以上。

其次是成本，公有云的成本降低了25%以上，采用的技术手段主要是应用分级加混部，应用分级是对我们的应用做了4层分级，让不同级别的应用部署在不同服务器里面。而在混部方面，比如让第1级的应用和第4级的应用尽量部署在同一台服务器上。

我们认为应该保证核心应用的稳定性，原生的K8s无法支持，因为原生K8s在调度器这一块只能够识别到分配的资源，不能更好地识别到服务器或实际应用的资源使用情况。

举个例子，它不能够判断某一台ECS实际的CPU使用率是多少，在这一台ECS上应用的CPU或每一个应用的资源的大概使用情况，根据这些资源的使用情况去做很好的分布。

我们在全面容器化之后发现整体的ECS使用率不均匀，有些ECS资源使用率比较高，有些ECS资源使用率比较低，所以我们在原生调度器的基础上做了一些开发和定制，我们更希望它能结合我们内部的一些监控平台，比如Prometheus或一些其他监控平台，能拿到这些指标和数据做综合分析，然后合理做调度。

三、比心云平台建设

（一）比心云平台

下面主要分析比心云平台的建设。

比心云平台建设初心主要有两个点，第一个是让大家感受不到K8s的复杂，因为一开始我们上K8s的时候，大家的技术栈比较薄弱，对于容器化这一块，我们的初心是希望不仅让业务感受不到K8s的复杂，也让技术、运维团队感受不到K8s的复杂。

第二个初心是无需业务写一行dockerfile和yaml文件。这里比较重要的一点就是能够让我们顺利推行容器化，尽量不让业务研发团队在发版或部署过程中写dockerfile或yaml文件。可以通过比心的云平台，自动生成这些文件，然后自动化进行部署。

比心的云平台总共有九大模块，第一个模块是容器中心。容器中心的定位主要是管理多个K8s集群，对于K8s所有的Resource进行增删改查，无需让运维或业务研发通过yaml文件的方式去操作。

第二个模块是监控中心，监控中心目前主要是基础设施层，我们对ECS、容器、Pod或Deployment做资源的监控和告警。

第三个模块是日志中心，日志中心经过了两个版本的迭代，第一个是ERK平台，因为我们当时的日志规模量很大，每天是几十T的增量。在使用ERK平台的时候，我们对资源的使用成本比较高。因为我们大家都知道用ES，尤其是日志量大的时候，而且我们采用了固态硬盘，所以SSD在这一块成本较高。数据量大的时候，可能偶尔会出现一些因为性能问题导致日志丢失，基于这个原因，最后我们选型了阿里云的SRS，它在这一块的表现不错。再结合我们自己开发了一些UI的界面，对接到比心云平台，让业务人员或运维团队能更好地查询日志、分析日志。

第四个模块是发布中心，这在下文会详细介绍，因为它的定位主要是针对整个服务的发版或部署。

第五个模块是CMDB, 这方面我们给团队定了一个指标，就是尽量保证数据的准确性和完整性。因为我们一直觉得CMDB是技术配置信息的管理，这方面的数据准确性比较重要。我们以前CMDB在使用过一段时间之后，发现CMDB的一些信息和数据的准确度不是那么高，会影响上层应用或上层业务的使用。这一点我们是基于应用出发，尽量让每个应用都能自己管理资源。第二点是结合自动化，然后可以自动化地通过监控平台或一些其他的运维平台，收集到以应用为维度的一些关联关系或配置信息，然后去做实时同步。

第六个模块是应用管理，通过应用管理，我们能够让业务或每个团队的负责人做管理的应用，比如通过应用管理配置应用的成员、权限或一些发版的策略，甚至能够看到应用容器Pod状态。

第七个模块是消息中心，我们提供了统一化的消息接口，能够对业务提供比如发送钉钉、打电话或发短信。

第八个模块是云商管理，因为比心使用多个公有云的资源，比如阿里云、腾讯云等，针对这些云，我们做了一些资源管理以及账单分析。

第九个模块是权限中心，权限中心也是我们对业务提供的中心化权限管控，对接各个业务的后台管理系统，能够方便地为业务团队提供权限管控能力。

（二）监控中心

下面聊一下我们监控中心的架构。

上文提到监控中心主要是针对基础设施，所以一开始选型就用了Prometheus。大家都知道在业内里面Prometheus既有它的优势，也有一些不足之处，比如Prometheus天生就不具备横向扩展能力，对于存储也没有很好的解决方案。

其次，我们针对一些数据做了整合，然后进行统一显示。我们的方案是采用一些开源的方案。比如说我们用Thanos进行日志数据的收集和处理，比如一天以内的数据保留在本地磁盘，让它有更好的性能查询。对于一天以上的数据，我们保存在阿里云的OSS里，可以让成本更低。并且采用Thanos的Query功能，还可以做统一化的查询，也就是说我们不需要关心指标在哪一套Prometheus集群里面，通过统一化的数据整合，能够做快速查询。

在配置层，我们开发了一个叫rule-engine的组件，能够通过API的形式很好地配置如告警规则，达到一个什么样的阈值然后告警，或是把这些告警分发给谁。传统Prometheus用的方法是让大家写大量的yaml文件，我们这里相当于屏蔽了这一块，然后以API的形式去提供这方面的能力，并且通过上层的UI，让运维团队通过可视化的一个界面，更好地配置这些。

告警层我们自己开发了一个叫cloud-monitor的告警组件，因为我们已经舍弃了Prometheus的Alertmanager，因为我们觉得它无法满足多元化的需求，所以我们自研了组件cloud-monitor，通过这个组件进行告警，不仅可以通过钉钉、短信或电话的方式告警，还能做一些分级，发送到不同的业务人员或不同团队。

（三）HPA开发

关于HPA的开发，我们的初衷是由于原生HPA支持的指标比较单一，不能很好地适配各种业务场景，比如它原生指标可能只支持CPU和内存，其他指标比如一些业务形态指标，它无法很好支持。因此，我们在开源的基础上去适配对接了一些业务平台，比如现在已经能够做到定时扩缩容，还能够根据QPS、熔断、限流指标做一些扩缩容。

我们采用的开源工具主要是KEDA,然后基于开源工具的基础上，我们做了大量的二开，并且做了一个可视化的UI界面，对接到我们的的云平台上，让运维团队或业务团队能够更好地做一些配置或管理工作。并且我们还支持批量配置，比如我们能够很好地配置在某一个NameSpace下所有Deployment指标。

（四）Warm Up

Warm Up是为了解决我们业务上的痛点，因为我们基本上使用的都是Dubbo服务, Dubbo的服务本身天然具备 Warm Up的功能。

当然,我们也有一些外部服务，比如这些外部服务在流量涌入的情况下，尤其是在服务发版或服务重启时，请求大量涌入，可能会造成服务GC，导致出现超时。基于这个痛点，我们云原生平台团队开发了Warm Up的这样一个Controller，可以根据Pod的状态控制SLB流量的进入，尤其是在发版的时候，我们通过Pod状态信息，慢慢调整SLB流量比例，比如可以按时间维度，这些配置都可以通过yaml文件进行，比如每15秒进入5%的流量，从而解决流量大量涌入，可能会造成服务GC的情况。

目前这个已经在平台通过测试，我们也在慢慢上手使用它。

（五）GPU服务器容器化、平台化

下面跟大家聊一下我们关于GPU服务器的容器化、平台化。

我们是从2021年年初开始去做这个事情，从2020年开始我们所有的业务容器化已经做得差不多了，所以就开始探索GPU这个方面。

我们没有做这一块之前，整体使用GPU的服务器资源是共用的，并且隔离性比较差，基本上都是手动部署，没有使用一些自动化的工具，并且没有标准，技术栈比较多样性，比如可能一些算法的框架用了比较多，生产基本上是单节点没有高可用。大家都知道像GPU这种服务器本身成本比较高，所以我们在以前的ECS上没有去做一些高可用的部署。

基于以上痛点，我们做了一些 GPU容器化的探索，主要使用了阿里CGPU的一些技术,解决抢占GPU资源，提升了资源使用率。

我们将一张卡，比如利用阿里云的CGPU技术可以分成多份，并且使用容器化技术做到很好的资源隔离和限制。第二个就是把它通过我们的云平台做到了自动化和平台化，让任务训练或部署通过云平台可以自动化迭代，大幅提高开发人员的效率。

第三个是支持了分布式任务的部署和调度。

最后一个是整个技术栈可以做到标准化、统一化，让业务人员可以更方便省心地使用底层的基础设施资源。

（六）Flink容器化的演进

下面分享关于Flink容器化的演进。

一开始比心整个大数据平台的技术栈比较多样化，我们有自建的Hadoop集群，也有阿里的一些OTPs之类的，我们从2019年开始慢慢探索Flink的使用。

当时，我们使用的Flink有一个阿里云半托管的，还有一个自建的，主要是用了筛选模式。这个模式的缺点主要是资源使用率不高，因为我们当时基本上是先准备好资源。

举个例子，我们一开始使用的是100C 400G的资源，在使用过程中，我们看到整体的资源使用率比较低，因为无论使用不使用，它已经申请在那里因此从2020年开始，我们开始使用Native/Session的这种Flink模式，希望能够结合阿里云ECI弹性资源，提升资源使用率。

比如在计算的过程中，在某个时间段我们不需要这么多资源，就可以把这些资源释放，也就是做到按量使用按需付费，这是我们整体Flink平台的演进。

四、研发效能工具建设

（一）研发效能

下面介绍比心研发效能工具的建设。

面向云原生的开发运维协同方式

这里主要是面向云原生的开发运维协同方式。比心在这方面经历了好几次的迭代，从最开始使用GitLab CI/CD，后面我们使用Jenkins，再到现在自研了一个比心的研发效能平台，也就是上文提到的比心云平台里发布任务模块，我们从需求出发，打通了整个需求的管理系统，并且能够自动更新需求信息。

在开发阶段，我们可以做到自动代码检测，让业务人员直接做一些Code Review功能，还能做自动合并分支，并且支持多种语言。比如，内部有Python、Java等。

在测试阶段，自动化对接了接口测试的平台，还有一些单元测试平台，当然这些平台可能由其他团队提供。

在发布阶段，可以做到发布流程审批，并且能够自动发布网关。由于我们自研了一套网关系统，因此可以在发版过程中自动做网关部署。

我们的研发效能主要几个阶段，第一个是需求，第二个是测试，第三个是UAT第四个是生产，第五个是验证，最后一个是完成。我们每个环境的流水线，主要有几个阶段，第一个是拉取基础信息，比如把代码拉下来，然后会做发布检测，这个检测主要包括是否需要发布网关，是否符合发布规则，如果开启了自动合并功能，我们会把代码做自动合并，如果没有，会跳到下一步代码检测。

在代码检测会做一些比如说静态代码扫描，然后或者是做一些SQL的审核。下一个阶段是编译，编译之后会判断是否需要编译网关，如果不需要就直接进入打包镜像。我们会把打包好的镜像直接发到镜像仓库里，最后通过平台自动化拉取部署，这就是整个流水线的完整阶段。

通过发布中心，大幅提升了整个研发的迭代效率。

五、未来展望

最后一个就是说做一个对技术做一个未来的展望。

首先是K8s，我们希望能够做到多集群调度，屏蔽底层的K8s时，虽然目前比心的云平台能够管理多个K8s集群，但是这远远不够，目前仅仅是做到了让业务感知不到底层有多少K8s集群，以及每个应用部署在哪套K8s集群上，但运维团队或云原生平台其实还是能够感知到。

并且，我们希望整个K8s集群能够无限横向扩展，比如我们现在用二套或者三套，希望未来可能有五套或者十套，并且随着K8s集群的增加，能够让所有的人员感觉不到应用部署在哪套K8s上，并且当应用出现问题的时候，能够自动做切换做调度，这也是我们对于未来平台建设的一个诉求。

第二个是中间件容器化，因为目前我们业务的容器化基本完成，对于中间件的容器化，这是我们对于未来的一个展望。因为对于中间件管理,大家都知道做有状态的服务，它对于底层存储的性能要求比较高，目前业内没有一个很好的解决方案。其次是我们有没有达到这个阶段，比如Kafka集群有没有上到一定的规模，在集群规模比较小的情况下，其实还是没有必要做的。因为随着中间件资源规模的增加,我们希望未来能够在这方面更好的赋能业务，比如做到中间件资源弹性，让运维部署这些中间件集群时能够更加方便。

第二个方面是大数据，我们一直以来都想做一个一站式的大数据容器平台，因为我们现在大数据的技术栈还是挺多，上文提到我们可能有Flink、Spark、Hadoop等资源。我们希望通过一个平台能够把这些资源做整合，做自动化的处理，更好地提供给业务团队使用，包括未来大数据平台或底层基础设施，我们希望尽量能够做到统一化和标准化。

下面一个就是离线和在线的一个混部，因为我们现在对于资源使用率，我们现在刚才也说了，我们现在做到了20%以上，希望我们希望未来能够去做到30%或者40%。

其次是离/在线混部，这个技术对于我们来说也是未来的一个大方向，我们希望通过这些能够让使用技术资源的成本更低，比如把一些大数据离线任务能够和在线业务部署在一起，或采用晚高峰分离，从而达到降本的效果。

第三点是关于存算分离，最近业内比较火的一个词叫数据库，包括很多一线的大厂其实都在做这个事情，我们这边也在探索。我们希望通过数据库这个理念或者架构，可以将数据做到统一化，因为我们目前的数据是分散的，并且对于整个数据的存储，随着规模增加，成本越来越高。我们希望通过数据库做到我们底层资源，比如使用OSS这种更低廉的存储工具，更好地支撑我们的业务，让我们的计算资源能够无限横向扩展。

最后想跟大家聊一下Mesh化，我个人从2018年初就开始关注这一块的技术。当时技术还不是很成熟，我们公司采用的是Spring Cloud的架构，对于传统的比如Spring Cloud也好，Dubbo也好，这种代码的耦合性比较重，而Service Mesh可以更好做到从业务代码和非功能需求代码的剥离，然后让整个业务、应用迭代更快更清亮。

Service Mesh在服务治理方面已经做了很多工作，比如服务发现、服务配置、熔断、限流，还支持AB测试，灰度等功能。我们希望能够使用Service Mesh，把基础设施做厚中间件做薄，让业务更好地迭代，让业务不需要关心这些，比如中间件这一层的一个架构，在发版的时候让业务无感知。