关于中间件:云原生时代中间件应该如何-进化

云原生热度继续攀升，这一趋势也延长了到中间件畛域。借助云原生技术，中间件正在解决了本身的弹性、韧性、运维、交付等问题。同时，开发者应用中间件形式也越来越云原生化。

那么，在云原生时代，中间件应该如何实现本人的技术“进化”呢？5 月 30 日，网易数帆云原生首席架构师冯常健做客《极客有约》，与咱们一起探讨了这一话题。以下内容依据直播内容整顿，并做了不扭转原意的删减，残缺内容 [[可点击查看回放视频]](https://www.infoq.cn/video/Zq…)

6 月 22 日 19:00-20:30，数字化根底软件自主翻新分享周・中间件技术论坛，3 位专家解读云原生中间件高稳固、高性能、高可用实际，欢送关注：多元共生 连贯新机 – 2022 网易数帆数字化根底软件自主翻新分享周

中间件为什么要云化

Q：冯老师 12 年退出网易，曾经有十多年的研发教训。您是什么时候开始关注云原生的？

A：我大略做了十多年的开发和架构设计工作，比拟侥幸的是，我正好残缺地赶上了云原生从萌芽、倒退，再到目前逐步成熟，在生产环境里能够大规模翻新落地的整个过程。在 2014 年的时候，Kubernetes1.0 版本还没有进去，咱们就基于 Docker、Kubernetes 开发容器云平台。目前，我在公司外面也始终在做云原生相干的微服务、容器化、服务网格、中间件以及 DevOps 等云原生工程大规模落地实际方面的事件。

Q：您感觉，云原生从最开始到当初产生了哪些重大进展？

A：最直观的感触还是云原生对研发运维过程产生了很大的影响。5、6 年前，DevOps 还没有太多比拟具体的落地门路，更多还是在强调 DevOps 开发运维一体化的理念。随着云原生各项技术的倒退，大家缓缓发现 DevOps 理念提倡的麻利、灵便和疾速，都能够通过云原生技术落地。能够说，云原生技术真正重塑了企业开发和运维的整个过程。

Q：那中间件云化的必要性体现在哪里？

A：首先，云的基本特色就是具备资源弹性，能够应答突发性的流量稳定，而弹性的背地就是资源的池化，即把所有的计算、网络、存储等做成一个资源池，咱们能够充沛地调度，来晋升资源利用率。

第二方面，我感觉自动化运维方面是绕不过来的。在传统畛域，如果不做云化和平台化，依照咱们的工程教训，通过脚本或半自动化形式能够搞定三五十个集群。但当数量达到互联网业务常见的三五百个集群规模后，传统脚本或半自动化形式是很难掌控这么多实例稳固运行的。云化的必要性在于，它能够很好地解决自动化运维的问题。

第三方面，标准化也是云化必要性的一个体现。如果不思考云原生化，咱们实际上会面临特地多的版本，特地是中间件畛域，同一个中间件的选型会有很多版本，另外还有很多不同的部署架构，自动化各方面能力也难以对立。

而云化就意味着绝对标准化，有助于技术栈的对立。咱们能够把整个技术栈聚焦到少数几个选型上，还能够进一步做企业级的技术规范化，大家约定应用某个版本后会便于后续的保护和对立降级。

还有一点，云化意味着中间件服务供应形式的变动。规模化组织里，微服务架构除了利用外，还须要缓存、音讯队列等中间件。这样的中间件要做微服务，首先要申请流程，如果运维团队和业务团队不是一个老本核心，还须要提前做容量布局、采购计划等等。这个过程波及了多方大量的流程性交互。

云化的中间件平台提供了一个技术中台，或者说是一个门户，能够自主申请，通过一些必要的审批之后，各业务部门本人能够按需采纳，大大缩短了流程，使整个资源管控效率更高。

Q：什么样的中间件能够称之为云原生的中间件？

A：我认为运行在 K8s 下面，用 K8s 原生的形式设计架构的中间件服务，就是云原生的中间件。

Q：云原生中间件和本地 PaaS 中间件之间是否有实质上的不同？

A：差别起源是云原生中间件基于 K8s。中间件的很多根底能力都下沉到了 K8s，大量惯例的高频运维操作都被形象成 K8s 下面一个个资源的定义，运维人员常常碰到的扩缩容、迁徙、重建、故障复原等高频动作都能够通过 kubectl 或其余对应的白屏化操作对立操作，极大升高了运维门槛和工作量，这是标准化带来的一个益处。

另外，因为有 Kubernetes 这一层形象，云原生中间件人造能够做跨云或者跨异构基础设施的部署交互，所以用户体验能够在整个过程中放弃完全一致。也就是说，在云计算时代，咱们能够抉择不同的国内外支流云厂商，把中间件服务齐全跑在云上，而且能够随时迁徙。这些实践上就是基于 Kubernetes 这一层的解耦。

中间件的云化门路

Q：云原生中间件的技术栈次要涵盖了哪些？又如何通过对企业倒退起到降本增效的作用？

A：咱们整个技术栈次要基于 K8s 以及 K8s 下面的框架，比方 Operator 等。

对于怎么降本增效，其实就是效率和老本的问题。效率上，更多是在流程和自动化两个方面晋升。咱们能够做很多自动化、故障根因剖析、故障治愈，甚至能够做提前故障感知、稳定性巡检等事件。

老本也是云计算始终以来的问题。云计算始终在提降本增效，但多年实际下来发现，用了云计算当前老本反而处于不可控的情况。我认为，企业还是要更精细化去管控、正当地应用资源。

Q：你们外部会对云原生的中间件进行分类吗？

A：会有，次要还是按状态去分，即有状态和无状态。咱们说负责负载平衡的，如 Nginx、API 网关，属于无状态的中间件，像音讯缓存这种就是弱状态的中间件。

Q：对于有状态的中间件，比方 Kafka，它们的云原生门路是什么的？其中的难点又是什么？

A：云原生中间件是构建在 K8s 上面的定义，中间件包含自身的运行时、像 Redis 这样的引擎，以及配套的管控零碎。我感觉它们云化的次要门路次要包含通用的技术框架和一些差异化的管控流程这两个方面。

目前，K8s 上治理有状态的支流计划就 Operator 框架及其托管平台 OLM，负责管控中间件集群的生命周期，这个过程中也会波及到 K8s 上像 CPU 内存、磁盘网络这样的资源管理调度。此外，中间件对立拜访路口的问题也十分重要。这须要联合企业里简单的网络架构，波及集群内外的拜访，须要思考很多细节。

接下来，咱们还要做绝对高级一点的能力，比方自动化的弹性扩缩容、实例迁徙、一些动静的配置下发等，来实现更高层次的高可用等个性，最初还会波及到配套相干的可观测性方面的内容。

生命周期治理、调度、拜访形式，以及可观测性这些都是通用的，即 Kafka、Redis 等其余各种中间件都绕不开的这些设计。

此外，还有一些差异化的管控流程。“差异化”意味着须要在通用的根底框架上来实现不同的资源依赖治理。比方各种中间件，有些是磁盘密集型的，有些是内存密集型，有些是网络密集型，那么不同中间件对不同的资源就有不同的要求，也就须要不同的技术计划。

另外，中间件高可用的计划也是形形色色的，即它们的集群拓扑治理形式不一样，比方 Kafka 依赖 ZK 的治理集群，绝对比拟容易自动化，而 Redis 须要在整个集群启动之后再进行角色调配的，相对来说管控面就会重一些。

整体来说，还是通过一些通用的技术框架和差异化治理去实现各个品类中间件的云化。

运维之难

Q：轻舟有专门的运维稳定性管控产品，为什么会做专门运维产品？运维难点体现在哪些方面？

A：云原生中间件的劣势在于重塑了技术供应形式，但如果稳定性问题不解决，就无奈体现出这个劣势。中间件运维须要耗费很大的精力。影响稳定性的因素十分多，我举几个例子后大家可能会十分能了解。

比方典型的资源水位问题，咱们很难去做容量布局。资源水位的危险大略有两类，一类是实时流量带来的带宽危险，像 CPU、磁盘 IOPS、网卡带宽等；还有一种是逐渐增长和沉积的容量型危险，次要体现在磁盘空间和内存水位，影响容量相干的危险很多，比方利用的业务流量、中间件外在的撑持机制等。

中间件都是多正本的集群，一个挂了后往往会有本身重建的过程，但重建过程会给残余的一些存活节点带来负载压力，这个时候它们很不可控，有时甚至会放大。当初一个节点挂了后要先复原，这个节点复原过程中会从存活的节点拉数据，这就会对资源水位造成影响，进而引发其余问题。其余比方像均衡性、热点资源，硬件故障、配置参数异样等都会引起稳定性问题。

咱们方才说网易数帆专门的稳定性管控产品是咱们运维团队十多年教训的积淀，为用户提供监控告警、稳定性容量、日常排障等方面的服务。另外，咱们也试着建设一种稳定性的改良循环。思路就是发现问题、剖析整改，而后再把积淀的教训加到规定引擎里来，防止下次产生同样的问题，如此循环上来，逐渐将企业的运维教训积淀到平台里。中间件的稳定性治理须要十分资深的人和教训，咱们心愿这个平台能够把这部分教训固化下来。

Q：看到敌人问，一人多岗的小公司如何做运维？

A：我感觉这样的企业反而更有必要去做云原生的转型。因为当初各种各样的中间件都有各自的利用场景和善于解决问题的畛域。所以运维人员每天都要学习业务侧提交的对中间件的需要。

Redis、Kafka 都是很常见的中间件，还有一些比方图数据库或者时序数据库，有时候也会被归到中间件的畛域里来。对没有多少运维人员的小公司或者是“一人多搞”这样的公司来说，运维反而很容易失控，后果就是不再提供这些中间件，呈现技术选型受限问题。

那么，有这么一套中间件平台有什么益处？咱们后面讲到的云化必要性或者说云原生中间件的基本特色，其中一条就是足够的标准化。所有运维人员的必要技能是了解 K8s、了解申明式 API、了解 CRD 对资源定义，这样无论是 Kafka 还是 Redis，运维人员的学习门路、技术了解等方面都是统一的。比方，Kafka 和 Redis 的扩容操作都能够申明为一个同样的 CR，这样哪怕有十个中间件，他们都能够用简直同样的运维形式去应答。

这就是云原生很大的一个劣势，它能够解耦，将很多技术细节积淀到 Operator 里。对运维人员来说，工作界面就是一个 K8s 的命令行，有助于解放他们的生产力。

中间件云化的技术选型

Q：轻舟具体什么时候开始做云原生中间件的？

A：咱们做云化中间件比拟早。整个网易互联网业务从 2012 年就开始做公有云，过后是基于 OpenStack 提供云主机、网络、硬盘，同时基于 OpenStack 的虚拟化环境提供基于虚拟机的 PaaS 中间件。所以，我认为真正做云化中间件是从 2012 年就开始了，咱们大略用了一两年的工夫把网易 95% 的互联网业务迁徙到了云平台上，并应用咱们的云主机和一些云化的中间件。

14、15 年左右，网易进入了云原生阶段。咱们开始尝试做无状态利用的容器化，让团体的一些无状态业务跑在 K8s 下面，还做服务网格。到了 19 年左右，企业该容器化的根本都实现了容器化，大量的外围业务都在服务网格平台上运行。

从 18 年下半年开始，咱们开始真正意义上基于 Operator 做云原生的中间件。通过三年多工夫，逐渐建设了一些深度的产品能力，咱们从晚期专一中间件生命周期治理，即创立、删除、扩缩容等能力，缓缓倒退到当初更多地去思考做多机房、多集群的高可用，以及国产化异构软硬件平台的适配等。

去年年初，咱们逐渐做方才提到的稳定性巡检产品化，另外也开始做“两地三核心”以及多活能力的建设。当初咱们曾经通过了生命周期治理阶段，缓缓做更加深度的能力。

Q：咱们当初是全副的业务都上云吗？

A：咱们互联网业务基本上都是云化，无状态利用全副容器化，有状态的目前在缓缓迁徙。像音讯队列、缓存这样的可能会快一些，数据库类的相对来说会慢一些。

Q：前边您提到了很屡次 Operator 框架，为什么过后会抉择这个框架？企业如何去做技术选型？

A：K8s 上的利用交付有两种形式，一种是基于 Helm，另一种就是基于 Operator。

Helm 更多适宜一些无状态利用，它依赖 K8s 原生资源控制器去保障各项 K8s 资源的自愈、扩缩容能力，但管控能力比拟弱，不能保障 K8s 原生资源之间的关联性。比方咱们在做中间件的时候，波及到某个 Pod 上面的一些状态变动相互之间是有依赖的，就是说某个 Pod 会依赖另外一个 Pod 的后果，我须要把这个信息注入到对应的 Kubernetes 里去，这其中有一些简单的业务逻辑，这是 Helm 控制器搞不定的。

另外就是基于 Operator 用户可自定义资源的治理形式。如果咱们当初把 Kubernetes 了解成硬件下面的一个分布式操作系统，Operator 就是在这个操作系统下面开发云原生利用的一套框架，它比拟适宜做中间件利用，或者说有状态利用。

中间件有两个外围特色，一是状态，这个状态体现为存储、网络 IP 等；还有就是中间件集群之间各个正本都是有关系的，比方 Redis 两个正本之间有主从关系，这样就不能把他们两个同等对待。Operator 是一种封装了一些特定畛域的运维常识教训的形象，能够自定义做很多事件，抉择用 Operator+CRD 的形式治理中间件是十分匹配的。

Q：随着业务规模不断扩大，云原生的中间件如何保障本身的高性能和高稳固？

A：这个也是很多企业把有状态利用容器化时的一个顾虑，性能和稳定性是中间件最看重的。能够说下咱们在这方面的具体思路和解决办法。

在性能方面，首先会波及到负载平衡，能够把更多分布式解决能力利用起来，须要一些负载平衡组件、代理组件。还有就是思考弹性的疾速扩容，能够是一种程度扩大或晋升整个集群性能容量的形式。另外，如果对 IO 或磁盘要求特地高的话，能够思考用更加高性能的本地盘形式。当然最重要的，能够对中间件在云原生场景上面做一些参数级的调优。这些都是咱们晋升性能的一些计划。

稳定性方面也有很多形式。一种是利用稳定性巡检平台，能够更正当地应用整个平台的资源，确保资源水位放弃衰弱的状态。另外，咱们采纳了一些像 Operator 这样的自动化开发框架，使中间件能够有治愈能力，并配和一些可观测性形式和混沌工程。如果咱们把这些故障都能无效地解决，那大家对这个零碎就会比拟释怀。

Q：整个云原生框架是越来越简单的，大家当初都越来越关注可观测性。目前业内在可观测性方面倒退得如何？

A：可观测性也是大家先有各自的规范，一些支流厂商主导，缓缓再在基层社区造成共识，进而产生新的业界规范。

当初，很多形形色色的利用在可观测性方向的指标、链路、日志都遵循社区规范。比方，链路方面有 OpenTelemetry 这样的社区规范，目前整个社区向好。大量开源的云原生软件都会号称至多遵循这样的社区关系规范。这样大家不必太思考兼容性和互操作性方面的问题。目前来说，曾经倒退到这个阶段了。

Q：网易数帆在可观测行上做了哪些摸索？

A：咱们本人也做了一个一体化监控的可观测性产品。微服务的场景须要以利用为核心，咱们须要把散落在各个组件里利用的各种指标和信息收集起来，在一个屏幕上有逻辑地显示进去。

所以，咱们通过一些语言数据系统，把监控零碎和各子产品，比如说服务框架、服务网格、波及流量入口的一些 API 网关，以及中间件的日志、链路等数据全副汇聚在这个立体化监控平台上，而后将数据买通。

数据对立采集是第一步，上面还有很多设想空间，比方能够做进一步的根因剖析。以前的根因剖析可能仅在某个纬度，比方货色流量调用、南北流量调用，或者某个中间件。当初，根因定位过程可能串联起整个过程。比方拜访慢了能够间接定位到容器层或者更往下的网络内存等。

另外，咱们在一些小的畛域，比方日志畛域，也做了很多事件。咱们以前也用了 Fluentd 等开源的日志采集工具，但在一些大规模的互联网场景下，性能还是不够，像日志丢了很难查出来这个日志到底有没有采集上来、丢没丢。因为痛点一样，所以咱们跟中国工商银行联结共建，公布了开源日志采集软件 Loggie。

落地实际

Q：网易目前落地了哪些中间件的云化？

A：在咱们团体的互联网业务中，Redis、Kafka、RocketMQ、ES、ZK 这些曾经落地，MySQL 这块也在推动落地。下面几个绝对比拟成熟，新业务也大都会应用云原生。

Q：之前看到介绍说，网易云音乐在引入了轻舟中间件的 Redis 后，老本节约了 30% 以上。具体都做了哪些工作来达到这个成果？

A：首先咱们在 2012 年后做了一个基于 KVM 虚拟化的 PaaS 中间件服务，到前面利用容器化后，相比虚拟化开销人造就有 10% 以上的老本节俭。

其次，咱们研发了一个在 K8s 上的管控零碎，次要负责离在线业务混部。比方在水位较低的时候，把音乐典型的转码等离线计算服务调度到 Redis 上。通过零碎混部可能把资源利用率进步到 60% 以上，而个别状况下可能是百分之一二十，甚至更少。当然还有其余的混部尝试，比方将 Redis 和其余中间件混部等。

第三方面就是资源超售，这也是云平台根本都会做的事件，就是对 K8s 进行资源超售，比方正当设计 requests 与 limit 的超售比等，尽量把测试环境里数据实例密度提上来。咱们线上和线下的整个利用规模大略 1：1 左右，咱们对线下做了更加极其些的操作。

Q：云原生的中间件更适宜在哪些场景下利用？

A：其实，云原生中间件就是对传统中间件的代替。比方缓存类中间件就是数据缓存、须要快速访问的场景，音讯队列类中间件就是用于解耦、削峰填谷场景，API 网关就是用在流量平衡的场景。在场景方面，没有说云原生特地适宜、传统中间件不适宜的，只不过本地化 PaaS 或者传统中间件，曾经不适应当初微服务架构的一些要求了，这些就可能须要云原生中间件去提供。

比方金融行业都须要做多活架构，服务框架具备这样的性能了，但中间件数据库无奈反对，这就没方法持续推动整个架构倒退，逼着你肯定要用云原生化的中间件去撑持它的云化架构。

Q：整个落地过程中会面对哪些艰难或者挑战？

A：从业界来看，要么自研，要么内部洽购，或者两个联合。网易次要还是自主开发为主。自研必定基于开源的技术框架等，但没有开源社区会真正为稳定性兜底，也很少有业余的反对，可能都是靠大家价值观或技术激情驱动，个别企业的个性化需要不见得能响应。总的来说，还是场景化水平比拟低，企业级管控能力比拟弱。这些都是基于开源做自主开发可能会碰到的，企业要点对点地解决这些高可用、稳定性和大规模利用等问题。

外采是一个很快捷的门路，但这块的艰难次要是洽购方没有造成对中间件残缺的掌控能力，毕竟是里面买来的，不足掌控的技术能力。这种时候，培训是很重要的，须要确保可能对这个产品日常应用。

归根到底，还是须要人了。自研也好，或者外采也好，就都须要懂云原生、懂 K8s 的技术人才，去构建整个生态。

Q：须要开发人员去了解业务吗？

A：中间件的开发是须要的，了解业务后能力更好的设计，因为你的货色设计进去是给他人用的，甚至给业务人员应用的。

然而这里能够从两方面了解。一方面是要了解企业的 IT 流程，比方理解各种各样技术平台各自的定位、不同平台之间的职能到底是什么、边界在哪里、平台间是怎么协同的。

另一方面就是理解一些业务场景下的最佳实际。为撑持大规模利用须要积淀一些最佳实际，这时就须要中间件开发人员了解业务的应用形式。比方 API 网关的业务流量模型是什么样的、流量趋势是随机的还是固定的，Kafka 或 Redis 对数据分片、性能、扩展性和高可用的要求，都会波及到固有架构和它依赖资源的选型，咱们只有理解了它的业务类型，能力做出正当的评估。比方在做异地多活或者单元化架构的时候，对于一些不重要的业务，就没必要做简单的架构，同城架构就能够。我感觉这些都须要了解业的，很难说有一种很通用的协定能够在所有场景应用。

Q：汪源老师曾在分享中示意，同样一个中间件，基于 K8s 研发代码量减少了 50% 到 80%。这是如何做到的？

A：我感觉这可能是咱们最早基于 Operator 或者容器化去做中间件带来的最直观的一个收益。

过后，咱们基于 KVM 虚拟机的 PaaS 中间件也好几个团队，方才列举了大略六七个这样的中间件是六七个团队去做的，所有人都要去了解中间件的整个管控过程，尤其是高可用、容灾方面的。整个管控过程是短少这种形象的、代码也很难复用，使得研发效率比拟低，一个中间件 PaaS 服务从开始的立项、开发、测试到上线，大略须要两三个月，这还是比拟快的，还不包含企业级的能力，如计费计量、权限管制、资源池等。

咱们用了 Operator 框架当前，代码量减少可能是最终后果，那咱们过程中做了哪些事件？后面讲过，Operator 能够分为通用部署和差异化部署，通用局部体现在设计规范上，包含设计准则、最佳实际、CRD 响应设计。

那时候，咱们大量转型到用 Golang 作为开发语言，就是用的 Operator SDK 作为开发框架，遵循申明式 API 设计规范。所以咱们从设计规范、开发标准、部署标准、运维标准、测试标准等研发过程中的各种标准，以及线上稳定性治理、对中间件的高可用要求等方面，去制订规范和束缚，最终后果就是有 50% 以上代码量的缩小。

做云原生中间件不肯定是为了缩小代码量，但这的确是个副产品。咱们过后做第一代 PaaS 中间件大略是五六万行代码，容器化当前大略只有两万行左右。其余也相似，Kafka 原先大略是五万行，起初是两万多行。

将来倒退

Q：云原生中间件将来还有哪些想象力？

A：当初大家对中间件的定义都有本人的了解，但我认为一些有状态利用都是能够云原生化的，包含当初看比拟过期的一些中间件。

举个例子，咱们团体在应用一个晚期的缓存中间件 Memcached，可能在很多业务看来它是一个曾经快要被淘汰的中间件，然而在咱们的某个业务外面它还被一些利用大量应用，因为它在一些特定场景中还有很多利用。咱们基于 Operator 的 SDK 框架疾速实现了对 Memcached 的 Operator，用云原生化的 Memcached 代替。

咱们真正开始基于 K8s 去做这些标准化的能力，包含后面说到的各种各样标准，开发和实现代替是很快的。如果咱们没有这样的框架积淀和技术储备，这些可能就是历史负债，下又下不掉，甚至有些可能都没法替换，还须要有人继续保护。咱们把这些看起来快要过期的中间件云原生化，同时花很小的老本就能够对立保护。

这只是举个例子，我想说的是，很多有状态的中间件都能够通过云原生化的形式来晋升运维效率。

当然对应的还有一个老本的劣势。当初私有云 IaaS 在资源层面的竞争曾经十分强烈，有各种同质化的利用，毛利非常低。相同，PaaS 中间件是有比拟大的利润空间的，它会想尽办法让业务用它的 PaaS 服务。如果关注老本，人们会在私有云的 IaaS 上自建中间件平台，这相对来说整个老本就会低很多。因为大家都是基于规范的 K8s 底座，所以这件事件就比拟可行。

Q：将来，轻舟在中间件云化方面有哪些布局？

A：技术方面，咱们跟进了云原生，咱们的多集群、多活等都还在继续建设中。尽管咱们有很多技术层面的积攒，但还须要在产品层面进一步做场景化验证。整个业界都一样，都在继续进化。

另外，对于大家当初提的比拟多的中间件的网格化，尽管目前还没有特地理论的生产场景需要，但它描述的愿景确是十分美妙：进一步晋升开发效率和运维效率，咱们也会继续关注。

此外，咱们心愿能够实现更多撑持微服务架构中间件的云原生化。对于开源凋谢的技术栈，咱们心愿可能实现对外围中间件的国产化代替，除了网易本人的互联网场景外，心愿能在金融、制作、能源等各个行业做技术输入。

6 月 22 日 19:00-20:30，数字化根底软件自主翻新分享周・中间件技术论坛，3 位专家解读云原生中间件高稳固、高性能、高可用实际，欢送关注：多元共生 连贯新机 -2022 网易数帆数字化根底软件自主翻新分享周

本文转载自 InfoQ：云原生时代，中间件应该如何“进化”？