直播回顾｜论道原生：云原生时代的中间件

“

在基础软件领域，中间件与操作系统、数据库并列为三大基础软件。中间件 (Middleware) 是处于操作系统和应用程序之间的一大类软件的统称，主要管理计算资源和网络通信，可以通过屏蔽底层的技术细节，让应用程序开发更简单。

中间件技术的发展方向是：聚焦消除信息孤岛，推动无边界信息流，支撑开放、动态、多变的互联网环境中的复杂应用系统，实现对分布于互联网之上的各种自治信息资源 (计算资源、数据资源、服务资源、软件资源) 的简单、标准、快速、灵活、可信、高效能及低成本的集成、协同和综合利用，提高组织的 IT 基础设施的业务敏捷性，降低总体运维成本，促进 IT 与业务之间的匹配。

云原生本质上是一种云操作系统技术，正在各个领域拓展着新的边界，云原生与中间件的结合，又有哪些机会与挑战呢？

6 月 13 日的论道原生直播间，「DaoCloud 道客」携手 StreamNative，共同分享了云原生时代，中间件在消息、日志、数据库场景下的挑战与解决方案，并对 “云原生时代，中间件如何演进” 话题，进行了圆桌讨论。

01 Apache Pulsar云原生统一消息流平台

StreamNative 联合创始人翟佳，是 Apache Pulsar 和 Apache BookKeeper 的项目管理委员会成员，为国内引进国际开源基金会顶级项目 Apache Pulsar ，并成功创建、运营本地开发者社区，拥有深厚且先进的云原生消息中间件技术背景。他以 Apache Pulsar 为切入口，结合实时数据的使用场景，分享了企业级的云原生数据流平台建设经验。

Pulsar 诞生于 2012 年，在 2016 年开源，2018 年毕业成为顶级项目，同年被 InfoWorld 评为最佳开源软件。其原生适配云原生架构，拥有丰富的企业级功能，从一众消息中间件产品中脱颖而出。再加上商业化公司 StreamNative 的支持和推广，让 Plusar 成功走出社区，在企业落地，并吸引了大批开发者加入社区、参与贡献。StreamNative 在 2020 年 8 月推出了第一个 Plusar 商业化产品，现有 50 多家付费客户，主要集中在金融、 IT 互联网和先进制造业。

Apache Pulsar 有四大特点，在云原生化上，Pulsar 的云原生架构，完全实现存算分离、服务层和存储层的节点对等等功能，可独立扩展、灵活扩容、快速容错，在云上能够保证更好的可用性和弹性。在消息数据领域的不同需求方面，Pulsar 通过一个专有的数据存储层，满足了在 MQ场景里，强一致性及灵活的消费模式诉求，同时也满足了在 kafka 场景里，高带宽诉求。

图源：

https://jack-vanlightly.com/sketches/2018/10/2/kafka-vs-pulsar-rebalancing-sketch

同时，在统一性方面上，Pulsar 拥有统一的消费模型。通过存储引擎 Apache BookKeeper 实现消息传递的高可用、低延迟；每一个 topic可以选择不同消费模式、订阅组等灵活的消费模型；融合和解析其他协议，让 kafka 的应用不用迁移，直接切换到 Pulsar 的平台，进行统一的消息存储，降低用户成本。此外，Pulsar 还可以对计算数据进行统一的存储。在企业级产品方向上，Pulsar 拥有以下特性：大集群/多租户/百万 Topic 支持、跨地域复制、云原生化等优势，吸引了众多用户。

有了这些特性，Pulsar 的使用场景也得到了进一步扩展。例如，在腾讯计费平台 (千亿级在线支付平台) 的应用中，是一个典型的关键数据分发和存储场景，Pulsar 可以提供快速的、数据持久化的能力，支撑各个平台突发的洪峰，保证数据层面高可靠性、高一致性，保障平台的流畅性、可用性，提供「异地多活」的服务，确保性能层面的高稳定性。

案例详情：

https://mp.weixin.qq.com/s/Qa4uzyOEuAX66pMWWz_Yjg

同时，Pulsar 在金融级企业总线、可靠跨地域复制：多地多中心、实时数仓等方面的场景应用中，都有着卓越的表现。

02 云原生下如何构建日志平台

「DaoCloud 道客」运维开发专家徐龙驹，分享了云原生技术的演进、云原生场景下中间件的运维、云原生中间件在日志场景下的使用等内容。

2015 年，CNCF 成立，吹动云原生的星火，迅速席卷 IT 世界的各个领域。当这把火烧到中间件运维场景时，带来了什么化学反应呢？传统模式下的中间件部署方式很多，因为每个运维团队都有自己的规范，同时非虚拟化场景下的部署也存在差异，增加了部署的难度和复杂度。而云原生场景下，主要有三种部署方式，yaml、helm、operator。Yaml 部署方式固定、部署简单、易用；Helm 支持组件的生命周期管理、模板定义、钩子机制、编排部署、幂等性等，并提供测试框架；Operator 是 Kubernetes 的扩展软件，本质就是封装特定组件的运维知识和经验，帮助管理复杂的有状态应用，实现自动化、智能化、运维和开发一体化。

在云原生场景下的中间件部署，越来越高级，功能也越来丰富，那么如何融入具体的使用场景呢？通过云原生场景下的日志平台构建，来一起了解下。

日常处理线上问题分为三个阶段，首先通过监控发现问题，然后在 Trace 上定位问题模块，最后通过日志查找关键变量、错误代码、代码路径，这样一条路径来解决问题，其中日志发挥着重要作用。同时，随着技术的演进，日志系统从单服务，发展到分布式服务，再到现在的容器、微服务，体量呈指数级上升，日志的分析需求也发生了变化，传统的架构在大规模服务场景下，无法进行自动扩容，系统架构急需升级。云原生架构弹性、敏捷、开放的特性，让日志平台焕然一新。

云原生下的日志采集方式主要有以下四种：

1. 使用节点级日志代理，日志代理需要在每个节点上运行，通常以 DaemonSet 方式运行，容器内应用必须是标准输出，对业务无侵入性；

2. 如果第一种方式在具体场景应用下不够灵活的话，可以创建一个带有单独日志记录代理的 sidecar，将代理程序专门配置与具体的应用程序一起运行；

3. 从应用中直接暴露日志目录，业务中集成 SDK 直接写入日志到远端，比如 java 程序可以使用 log4j2 转换日志格式并发送到远端；

4. 类似传统方式的容器外采集，将宿主机的目录挂载为容器的日志目录，然后在宿主机上收集，但不包括 kubernetes 元数据信息。

对比来说，Sidecar 的采集方式，只采集 Pod 内日志，隔离性较好，出现问题的几率较小，但是 Sidecar Pod 出现问题时，会影响业务 pod，占用资源也较大。而 DaemonSet 无侵入式采集，不影响业务 pod，资源占用较小，但是节点所有 Pod 都需采集，隔离性较差，节点 pod 数量大增时，出现问题的几率较大。

鉴于当前云原生技术优势明显，同时也存在一些需要改进的地方，因此在构建平台时，根据不同的场景，需要搭配不同的技术，进行日志采集，然后通过统一的日志分析进行展示。

03 MySQL 上云的一些思考和实践

「DaoCloud 道客」运维中间件开发工程师李国志，分享内容聚焦三个方面：MySQL 为什么要上云，怎么上云，还需要做哪些工作？

传统云下的数据库架构，容易造成资源分配不均，总体利用率偏低，有的资源又容易超卖，并且资源监控如果出现漏监，容易造成资源浪费，其次网络带宽容易出现集中满载情况，此外，当分配给 MySQL 实例的资源不足时，会严重影响 MySQL 性能。

K8s 作为容器编排的事实标准，是云原生的核心技术。MySQL 上云后，基于 K8s 可以统一多部门的复杂运维架构，提高资源利用率，降低企业成本支出，如：存储成本、内存成本、CPU 成本等，天然支持高可用、负载均衡、自动化运维等。面对这么多的优势诱惑，是不是想要马不停蹄地上云？

然而 MySQL 的上云还有一些挑战和困难，比如：数据的迁移、数据完整性的保证、运维工具的完善、数据安全等。这时，可以分步骤分条件多维度去评估:

非核心业务的数据库->核心业务的数据库
增量数据库业务->存量数据库业务
小流量数据业务->大流量数据业务
时效性比较低的数据库 (日志等)->时效性比较高的数据库 (用户中心，钱包系统等)
架构简单的数据库 (主从模式)->架构复杂的数据库 (mgr 模式)
数据量小的数据库->数据量大的数据库

根据业务的实际情况和上云的紧急、必要程度等，进行优先度排序，一般优先选择非核心业务的数据库，增量数据库业务或小流量的数据业务进行迁移。

此外，运维需要掌握一定的 K8s 运维技能，同时转换一下运维思路，传统手动的备份、迁移、备份恢复等技能，可以转换成对应 operator 的能力，结合一定的异构工具，演绎出更多运维工具，比如实时备份数据库、实时归档等。

总结一下，架构和运维是相辅相成的，架构的呈现方式和运维工具的使用具备一定的因果关系。反之，运维工具的丰富也会促使架构更加丰富多元化。上 K8s 是一种大趋势，会衍生出新的运维方式，而新的运维方式也在探索和演进中。

04 圆桌讨论中间件为什么要云原生化？

翟佳：云原生是一个重要的趋势，已经成为了大家的共识，很多 IT 产品将「云原生」作为了产品的重要特点。因为它满足了用户的期待：更好的弹性、更好的扩展性、更高的一致性，还有安全性和可观测性等，帮助用户更加透明高效地构建和运行相关业务系统。这投射到我们公司所做的，中间件的消息和流这个方向，也是非常一致的。

徐龙驹：云原生为什么会被热捧？首先，它对底层资源的利用更加的精细化，提升了资源利用率，可以让中间件的运行实现自动扩缩容；并且，能实现健康自愈，降低人工运维成本和压力；同时，非常地灵活，可以部署在任意云平台上。

中间件云原生化会面临哪些挑战？

王豪：第一，是在使用方式层面，云原生化只是第一步，之后如何有效结合云原生的优势特性，使其发挥出超越传统方式的效果是一个挑战。第二，是在运维的维度上，新的工具给运维人员提出了新的挑战，学习如何正确有效地使用需要一个过程。第三，是在重要数据的可靠性层面，像数据库、消息队列、各种大数据的组件等各种有状态的中间件，云原生化之后如何保障数据的可靠性和安全性，如何通过有效的运维手段，实现对这些中间件数据的全面监控和管理，这对底层支撑平台的存储管理能力提出了更高的要求。

李国志：主要有 5 个方面的挑战：1. 数据迁移方面，是不是都要云原生化？已有的数据怎么办？2. 云上云下自由迁移，中间件不适合经常启停，需要保持持续稳定的运行，出现容灾的时候，如何保障云上云下的顺畅迁移？3. 中间件的支撑能力上云以后，能不能满足存储、网络等方面的性能要求？4. 如何保证数据在迁移过程中的完整性？5. 运维工具是否完善？

云原生中间件如何解决存储问题？

翟佳：从消息中间件的角度来说，也需要提供存储服务，通过直接利用云原生的一些开源项目能力，如：Apache BookKeeper，加上我们积累的专业技术能力，结合相应的使用场景进行适配整合，嵌入产品的技术架构，让用户在使用产品的时候能不用考虑底层复杂的技术逻辑。

李国志：我们推荐采用开源存储项目 HwameiStor 本地分布式存储系统，该系统支持高可用、多副本、低延迟，并且有一个灵活的交互协议，能降低数据丢失的可能性，读写能力比较好，可以满足不同中间件的不同需求，在服务中断时能快速恢复。

云原生中间件应用场景有哪些？

翟佳：从消息中间件来说，主要有：削峰填谷、系统解耦、异步处理等，还有一些更广泛的应用场景，可能会从用户的使用需求中诞生，技术和场景本身是相互促进和影响的。

王豪：主要四个方面，1. 自动化运维方面，快速地部署、自动化的故障处理；2. 快速响应业务需求，自动化扩展；3. 能够异构纳管，实现统一交付；4. 信创领域，云原生中间件的封装能力，降低了信创应用的交互成本，减轻了运维压力。

徐龙驹：从运维角度去看，1. 友好扩容集群的吞吐能力，支持动态扩容存储；2. 动态感知能力，提前预警占用内存，实现自动扩容和数据的持久化。

李国志：补充一个点，云原生可以实现构建统一的中间件生命周期管理平台，也可以节约系统的资源，提高资源的利用率，然后降低企业的存储成本、CPU成本、内存成本等。

更多技术详情，可观看回放了解，并为大家提供直播回放和演讲 PPT。

以及点我一起技术交流。

在此感谢大家的积极参与，我们将继续为大家带来更多更好的内容。

本次活动的纪念品将陆续寄出，希望大家每期都能有所收获，我们下期再会。