PaaS中间件

有状态服务平台建设

作者：温玉

什么是有状态服务？本文的理解是：有状态服务是无状态服务的反概念，是指在提供服务时需要考虑先前的处理状态的一种软件架构设计；状态基于数据来承载，当前软件架构将状态数据的管理与业务逻辑解耦，独立成单独的有状态服务。

有状态服务出现的背景与原因

业务应用架构在演进过程中，为解决不同场景的问题，对业务应用程序功能进行解耦和拆分，从早起的单体应用架构逐渐演变成当前的微服务架构。

而应用架构演进时业务逻辑拆分成多个独立的模块，每个模块在运行时还会有多个副本，这些模块和副本的业务逻辑间存在数据交换，也从单体的内存方法调用演变成对服务数据的管理，而数据是有状态的。

为管理结构化的数据以及保障数据的持久化，出现了数据库软件。为解决进程间数据共享与提升性能，出现了缓存中间件；为解决服务间通信的异步问题，出现了消息中间件；以及特殊业务场景下的不同类型的数据管理中间件。

有状态服务有哪些种类？

有状态的服务体系演变到当前已经非常的复杂，解决的问题也逐渐变得聚焦专业的场景问题。按照功能场景分类的有状态服务情况大致如下（开源）：

• 关系型数据库：如 MySQL、PostgreSQL、SQLite
• 内存/缓存/KV中间件：如Redis、Memcache、Etcd
• 文档型数据库：MongoDB、Couchbase、CouchDB
• 时序数据库：InfluxDB、Prometheus、Graphite
• 图数据库：Neo4j、Aerospike、Virtuoso
• 搜索数据库：Elasticsearch、Solr
• 列存储数据库：Cassandra、HBase

图为2024年11月数据库TOP30，图片来源: db-engines.com

此外，

• 消息队列类中间件：如：Kafka、RocketMQ、RabbitMQ
• 非结构化数据管理：如：对象存储、文件存储、块存储

有状态服务的特点是什么？

这里有状态是与无状态进行对比，无状态的服务在进行扩缩容副本时不需要考虑数据问题，而有状态的服务进行扩缩容副本时需要考虑集群状态、数据同步，以及数据一致性等问题，有状态的服务管理更加的复杂。

有状态服务的特点包括：

• 高可用：有状态服务管理数据是为了持续的提供数据管理服务，需要考虑服务的高可用，不因单个副本故障影响服务访问。
• 一致性：高可用服务由多节点组成同时提供服务，节点间的数据需要保持一致性或具有关联性才能按照预期提供数据访问。
• 持久化：进程或高可用集群在重启时原有的数据需要载入，数据持久化到磁盘解决内存掉电数据易失问题。
• 专业性：每中有状态的服务都有其特殊的管理方法，稳定的服务需要专业的人员进行管理。

当前有状态服务使用和管理面临哪些痛点问题

除了有状态服务技术特点外，结合企业管理的有状态服务的种类和数量越来越多，导致了企业在管理有状态的服务时出现了一些痛难点问题。

当前有状态服务使用管理面临问题

交付效率低 。当前通过运维人员手动或编写脚本的方式进行交付部署，在大批量或紧急交付时交付效率低，对业务上线计划会产生一定的影响，且会占用大量运维人员时间。

运维管理难度大 。由于种类和数量多且专业性高，在进行监控告警、高可用、容灾备份、操作使用，以及标准化管理等方面非常复杂，细小的失误就可能导致严重的线上事故和经济损失。

硬件资源浪费严重 。大量的实例在环境和物理位置上的分散，以及资源分配按照规格或虚拟机方式造成的大量资源冗余，导致实际的有效资源使用率极低，资源浪费严重。

稳定性与安全性弱 。中间件服务除了其基本面向业务的功能使用外，还需要考虑保障其稳定性、安全性等合规的要求。由于专业技术人才短缺，导致稳定性与安全性弱。

该如系统化的解决有状态服务问题？

系统性的解决有状态服务各种技术和管理问题的最佳实践是建设有状态服务管理平台（或者PAAS中间件平台），通过平台化的方法像使用公有云产品一样使用有状态产品服务。

有状态的服务的管理平台主要功能分为生命周期管理、运维中心、中间件市场，以及高可用容灾能力建设，此外还可能会涉及一些计费相关的功能，但是在企业内部建设时，计费能建设是投入产出比较低的功能，一般情况下建设的优先级不高。

生命周期管理：主要面向使用者（业务方运维人员），对中间件的创建、变更、删除等的基本管理功能，以及一些配置管理、数据库、Topic管理、索引管理、认证信息等管理功能。

运维中心：主要面向平台运维人员，便于进行运维管理，比如数据上云、实例迁移、故障发现与恢复、监控告警，以及备份恢复等功能。

中间件市场：中间件市场主要扩展整个平台的产品模块种类，可扩展的架构能够更好的兼容企业和平台长期的发展。

高可用容灾：解决对稳定连续性要求较高的业务场景，在成本与高可用程度间评估平衡来进行建设。如金融业务，一般会考虑建设同城双活、两地三中心架构。

建设PAAS平台的价值

建设有状态服务管理平台之所以会成为最佳实践，核心是它很好的解决了企业传统管理的痛点问题，给各个团队带来实实在在的帮助。

面向业务，提高交付效率，聚焦业务价值。 中间件云化和自动化供给，交付统一版本、统一能力的中间件，解决中间件获取流程长，以及配置不合理、容量瓶颈、中间件故障导致的开发进度阻塞的情况。

面向运维，实现统一管控，便捷高效管理。 将企业的中间件进行平台集中化的统一管理，解决中间件种类多、集群数量多、版本不收敛、安全隐患无法有效治理，运维和兜底难度高、升级动静大等问题。

面向管理，建设合规中间件服务，降本增效。 建设自主可控、安全、稳定的中间件服务。形成面向业务系统的视图，解决难以统计资源消耗和评估成本的问题，快速发现资源利用率低的中间件集群。

关键技术

新一代的有状态服务管理平台推荐基于云原生技术体系进行建设，云原生基础的容器云平台在前面章节已经详细介绍，这里不再进行展开。

Operator

在 Kubernetes 中，对无状态的服务通过 Deployment 进行管理，对有状态的服务通过 StatefulSet 管理，但是 StatefulSet 在管理有状态的服务时仍然具有很多的局限，如：

• 部署一套完整的集群涉及多个镜像服务，同一个服务在不同节点有配置差异，服务之间有配置上的关联，并且服务启动时也有顺序的依赖，需要对这些部署动作进行管理控制。
• WEB控制台需要管理数据库、Topic、索引等功能，需要有对应的 API ，以及对应的运维操作能力。
• 集群状态变迁时，需要能够实施监控、并根据运维经验进行可控的运维操作变更，自动恢复集群健康状态的运维管理。
• 其他特殊的运维管理动作都基于期望页面控制，减少甚至避免通过命令行操作管理。

这些问题导致 Kubernetes 原生 StatefulSet 管理的有状态服务时能力不足，导致有状态服务缺乏稳定性和灵活性，在生产环境中运行具有较大的风险。

Operator 理念是将运维知识融入软件代码中，通过与 Kubernetes 概念和 API 进行原生集成，在 Kubernetes 集群内运行的软件中实现并自动化常见的 Day-1（安装、配置等）和 Day-2（reload配置、更新、备份、故障转移、恢复等）活动。 operatorframework.io

主流的有状态服务均已经有其对应的 Operator 部署版本，如 RocketMQ Operator。企业在进行有状态服务云原生化设计时，建议优先参考社区的 Operator 实现。

存储管理

有状态服务的核心是由于数据是有状态，在进行服务管理过程中考虑的核心也是数据的管理。在 Kubernetes 中管理有状态服务数据持久化有几种方式：

• EmptyDir：数据存储的生命周期与 POD 相同，如果删除 POD，则可能会丢失数据。在高可用集群中，单个节点故障时可以自动恢复，但是如果是机房掉电同时故障，可能由于节点恢复顺序问题导致所有POD都被重建，这时持久化的数据就会全部丢失。
• HostPath：这种方式将节点的磁盘空间挂载到POD中，可以解决 EmptyDir 的数据丢失问题，但是在多个副本同时故障时，具体如 POD-0 调度的节点不固定，在重建时节点上可能没有原有的数据；即使调度到有数据的节点，其中的数据可能是 POD-1 的而不是自己原来的数据。且还有无法控制配额等其他问题。
• 本地LocalPV存储：本地 LocalPV 存储是推荐的一种的存储方式，具有高性能、可控制等优点。但是，开源的 LocalPV 调度器可能无法满足一些易用性的场景，完善的功能需要进行增强，如可以通过 LVM 控制空间配额；通过 PV 与 POD 绑定让 POD-0 只能调度到 NODE0 机器上，即使机器故障也不迁移 POD0；
• 网络PVC存储：网络 PVC 存储也是一种推荐的方式，他在管理上比 Local PV 更适合有状态服务的数据管理，但是性能有较大的损失。如果有性能好、网络带宽和质量高、磁盘IO性能不敏感的场景可以考虑使用这种方式。

所以，在管理有状态服务时，一般会在 本地LocalPV存储 和 网络PVC存储 中进行评估选择。

访问方式

在有状态服务的集群服务搭建完成后，如果业务也在同一个集群中时，可以通过 K8s 内的 Servcie 域名的方式进行访问。

结合经验，实际上企业建设有状态服务管理平台时，业务服务不一定都完成了容器化改造，以及一些不同网络区域的业务访问等问题，导致需要考虑向 Kubernetes 集群外暴露地址提供服务。

一般有以下几种方案选择：

• 通过 BPG 等方式将 Kubernetes Pod 网络与业务环境网络打平。 这种方案理解上简单，但实际落地比较困难。一般 Kuberentes 部署使用 Calico-IPIP 方案时是一个独立的 Overlay 网络，换成 Calico-BPG 方案时需要考虑网络设备支持情况、合规与流程规范、安全等问题，实际落地困难较大。
• 通过 NodePort 的方式。 这种方式比较主流，有状态服务地址和端口通过 NodePort Servcie 暴露后，在集群外通过机器 IP + 端口的方式就可以访问。但是这种方式也有一定的缺点，比如节点可能下线导致IP变动，高可用入口依赖客户端支持多地址访问，服务端口数量有限制，在云 VPC 环境中需要进行特殊处理。
• **通过 Loadbalancer 代理。**这种方式是另外一种推荐的方式，还可以在 LB 上做一些安全白名单、限流等功能。但是原生的 Loadbalaner 方式对一些需要二次通信的服务支持不友好，需要进行改造。比如 RocketMQ 通过 Nameserver 进行连接后，实际读写数据的是 Nameserver 返回的 Broker 地址；其他还有 Redis Sentinel 模式。

在提供有状态服务访问时，快速高效的方式是通过 Nodeport 方式，如果有一定的研发能力 Loadbalaner 是理想的选择。

观测监控

可观测性是通过检查系统输出来理解系统内部状态的能力。 在软件系统中能够通过检查遥测数据（包括链路、指标和日志数据）来理解系统的内部状态。

日志、追踪、度量的目标与结合图 图片来源 peter.bourgon.org

当前主流的可观测基于 OpenTelemetry 理念进行建设，OpenTelemetry 是一个可观测性框架和工具包， 旨在创建和管理遥测数据，如链路、指标和日志。OpenTelemetry 是供应商和工具无关的，这意味着它可以与各种可观测性后端一起使用， 包括 Jaeger 和 Prometheus 这类开源工具以及商业化产品。

高可用与容灾

高可用与容灾核心目标是保障有状态服务的稳定性、连续性，以及数据有效性能，常见的量化指标是 SLA、RTO、RPO、MTTR 等。 任何企业在 SLA 上的承诺都是相对保守的，基本不会存在 100% 的 SLA 承诺。之所以无法达到 100% 不故障，是因为企业会在 SLA 和投入成本上会进行平衡性评估，更高的 SLA 需要更高的成本来支撑。

提升 SLA 的策略除了减少产品 BUG 外，在运行环境上需要考虑一定的故障域。

如上故障域示意图涵盖了城市地址位置的范围，极端情况下还会考虑国家级的故障场景，比如战争可能会使一个国家消亡。

解决故障域问题可以通过建设软件服务的高可用能力来体现

一般情况下，企业会进行 Level1 基本的高可用建设，即在一个机房内建设多副本高可用的有状态服务集群，保障任意一个节点故障时不影响集群的正常运行。同时，还会提供数据的备份恢复功能，来解决特殊情况下数据有效性。

更高级别的高可用能力，需要投入更多的IT资源和建设更加强大的IT人才团队。其实，有时候即便服务真的挂了，影响也范围也就是用户体验下降、赔偿、领导不高兴或者上层组织处罚之类的，这些影响与冗余的硬件和人力成本相比，领导的理性决策大概率是“挂就挂了吧”。

安全

安全是企业生产经营过程中必须要重点关注的问题，有状态服务的安全涉及多个环节，任意一个环节出现薄弱就可能会导致安全隐患。这里不讨论由于业务漏洞导致的有状态服务安全问题，这个问题需要业务系统设计上解决，有状态服务平台可以提供的是极端情况下数据基于备份进行回滚的能力。

解决有状态的服务自身安全最简单，也是最有收益的方法是“只在内网运行”，最好是只有用他的业务才能访问。

但实际情况是不同的企业内网的范围大小可能不一样，内网也可能不一定的安全，所以有状态服务在安全上还是需要进行一定的安全设计。

安全设计需要考虑整个软件生命周期的各个环节，在后续的“安全”专题中会详细展开说明。

运营

良好的运营管理能够让企业长期健康的发展，特别是对于有状态服务这种专业性较强的技术领域尤为重要。有状态服务的运营目标是：不断提升平台能力，持续赋能有状态服务管理平台用户。因此，在进行运营规划也是从平台服务提供侧和平台服务使用侧的供需两方面考量。

• 在服务提供侧，有状态服务管理平台的运营需要维系调动有状态服务管理平台的能力建设参与者，不断引导将先进技术、可复用能力沉淀在有状态服务管理平台上；
• 在服务使用侧，有状态服务管理平台的运营要维系平台的用户，不断降低用户认知和使用门槛，让用户能持续地使用平台能力，快速构建应用，释放业务价值。

从有状态服务管理平台和用户两侧来看，运营都要针对生命周期的各个阶段，尽力推动价值往下一个阶段流转。有状态服务管理平台生命周期：规划-建设-推广-评估（PDCA），其中推广对应到用户的有状态服务管理平台接触。

对于运营的体系化建设方案，在后续的“运营”专题中会详细展开说明。

总结

有状态的服务是软件架构演进的产物，它支撑当今分布式微服务软件架构状态数据管理。由于其丰富种类与较强的专业性导致了企业在进行管理时带来诸多挑战，而解决这些挑战的最佳实践就是建设企业统一公共的有状态服务管理平台。

有状态服务管理平台的建设同样具有一定的挑战，却是个解决问题的正确方向，持续的运营让平台逐渐的成熟与完善，进而帮助企业更好的降本增效，支撑企业长期的可持续发展。