- 有状态服务
有状态服务是指在提供服务过程中需要维护和存储数据状态的服务，它会记录客户端的会话信息或业务数据，并在多个请求之间保持这些状态，使得后续请求可以依赖之前交互的上下文进行处理。
与无状态服务相比， 有状态服务的核心特征在于状态的持久化和依赖性：无状态服务的每个请求都是独立的，不保存任何客户端相关数据，而有状态服务则会在自身存储数据（如内存、数据库或持久化存储），处理请求时可能需要依赖历史状态信息，例如用户登录后的会话状态或订单处理中的进度。
**典型应用场景包括：**数据库系统（如 MySQL、MongoDB）、消息队列（如 Kafka、RabbitMQ）、会话存储服务（如 Redis）以及需要维护用户状态的分布式系统（如在线游戏服务器或配置中心），这些场景要求数据一致性、稳定的网络标识和持久化存储，以确保状态在实例扩容、缩容或故障转移时的可靠性。
在Kubernetes环境中， 有状态服务通常通过 StatefulSet 进行管理，以提供固定的网络标识（如主机名）和稳定的存储，支持数据库集群等有状态应用的部署需求
StatefulSet 保证了每个pod的有序启动，并在在pod启动后其标识和数据不会丢失
有状态服务管理三要素：
- 持久化存储，PVC+StorageClass，银行核心交易数据库集群
- 稳定的网络标识，Headless Service（提供服务发现和负载均衡的能力，直接暴露每个pod的ip给调用方）+StatefulSet，跨AZ部署的联机交易系统
- 有序拓扑，PodManagementPolicy策略（用于StatefulSet的pod管理策略，确保pod按照固定顺序部署和销毁），信用卡审批队列主从架构，数据库、消息队列得按顺序启动和销毁，以保证数据一致性
有状态服务对存储性能有更高的要求，所有选择合适的存储介质至关重要
- 有状态服务会话保持方案
session保持是银行业务连续性的关键保障，主要通过两种方式实现：
- 服务网格级会话黏滞：DestinationRule，BANK_SESSION_ID（基于银行会话令牌），核心是将会话路由到处理该会话的同一端点，通常采用基于http头、cookie一致性哈希，istio支持基于action user、cookie等多种哈希算法，确保相同请求发送到同一个pod里，istio支持多种负载均衡策略
- 应用级会话共享：写入redis，再做同步，将session存在redis中，确保不同节点之间无缝切换
- 零中断迁移方案：针对有状态服务的延续
SLA
- statefulSet优雅迁移：通过RollingUpdate策略和partitition参数保留至少一个旧实例，确保主从有需更替，避免服务终端
- 跨AZ故障转移
使用CSI-PDR跨区域复制存储，实现银行双活数据中心的容灾能力，确保业务连续性：数据复制、故障检测、自动切换
- 实时数据同步
Kafka Cluster（跨AZ同步）需结合Ceph RBD Block Storage的跨机房镜像复制
- 故障自愈防护体系：状态健康探测和自动化决策树
状态健康探测配置：存活探针，交易完整性检查脚本；失败阈值2；20s之后调用脚本，避开数据库（或应用）启动周期；就绪探针，通过http脚本检查是否返回200
自动化决策流程：重启pod3次失败，隔离故障节点、告警、自动引流；启动成功，检测数据一致性，启动金融级事务修复脚本
任何pod重启，必须做停止前的优雅关机，完成事务性的提交，数据一致性检查，检查完之后才能停机
- 服务网格深度集成
- 流量治理：金丝雀发布/蓝绿部署、智能路由/故障注入
- 安全管控：mTLS全链路加密、RBAC细粒度策略
- 策略执行：速率限制、服务熔断
- 可观测性：Metics指标/Trace跟踪、分布式追踪
- 服务网格功能深度解析
- 智能流量管理，VirtualService+DestinatiaonRule，核心系统灰度发布成功率上升到92%
- 零信任安全，PeerAuthentication+Authorization，满足银保监会《网络安全》Tiger4级要求
- 全链路洞察，Kiali+Grafana+Jaeger
- 弹性策略，CircuitBreaker+RateLimit，防止支付系统雪崩的熔断阈值《=0.1%