珍爱微服务底层框架演进_彭万亮

珍爱微服务底层框架演进总结

背景介绍

• 业务增长与架构挑战：2018年珍爱网业务规模爆发性增长，导致系统出现瓶颈，需着重建设基础架构，解决服务架构、基础组件、研发流程等多维度问题。
• 核心思想：
  • 统一技术栈支撑多线业务发展。
  • 引进开源技术时需合理整合与改造。
  • 技术架构需具备前瞻性，避免重复造轮子，持续迭代。

基本思路

• 微服务框架：
  • 采用Spring Cloud+Dubbo框架，引入API-Gateway统一承接南北流量，搭建zhenai-framework作为应用基础框架，引入主流开源中间件。
  • 领域建模设计方法使业务领域边界更清晰，以分层分包方式组织代码，部署上合并API层和Provider层以节省资源。
• 网关层：
  • 基于Spring Cloud Gateway扩展Filter，提供请求验证、黑白名单、熔断限流、合并请求、重试优化等功能。
  • 合并请求：允许客户端将多个请求合并为一，减少页面初始化时的请求数量，功能包括拆分请求、并行执行、合并响应、降级重试和请求监控。

数据层

• 问题与拆分：
  • 原因：70%故障来自数据库（业务共用数据库相互影响；Mycat单点问题），20%来自应用（共享物理机未隔离）。
  • 方案：上云后采用云数据库，实现“一应用一数据库”原则。
• 去除数据中间层：
  • 去除Mycat，应用直连数据库，zhenai-framework管理公共配置（分库分表算法、ID生成规则等）。
  • 开发Sharding配置刷新/同步功能，支持大表拆分、多分片键、HintManager手动控制等，优化表META信息加载速度。

全链路优雅停机

• 问题：服务重启时流量控制与预热时间难以平衡。
• 解决方案：
  • 启动时间均衡算法：最后启动的实例承担大部分流量。
  • 启动时间加权算法：滚动重启全程均衡各实例流量。

研发流程

• 问题：资源隔离不充分、并行需求联调测试困难、部署流程人工参与多、多环境管理复杂。
• 解决方案：
  • 构建zhenai-framework简化流程，减少业务方感知。
  • 容器化插件zhenai-dockerx-plugin：
    • 检查分支、k8s ns。
    • 使用zhenai-dockerx-base镜像构建。
    • 生成k8s deploy/svc yaml。
    • 自动部署启动。
    • 多环境管理、组件管理。
  • 插件发布流程：全流程封装，自动触发任务，简化开发人员感知。
  • 单元化：
    • 网关与底层单元化。
    • 业务单元化，相互隔离。
    • Framework为基础框架，中间件/平台软隔离。

双云双活

• 目标：提升服务稳定性与数据安全性。
• 实现：
  • 应用双活/数据灾备，流量不跨云。
  • 基础框架支持，减少应用感知。
  • 中间件支持双云模式。

架构演进之路

• 2018：微服务拆分（业务快速发展，需求迭代）。
• 2019：数据层改造（上云后托管基础设施，助力微服务架构实现）。
• 2020：容器化与DevOps（与微服务架构相辅相成）。
• 2021：双云双活（进一步提升服务稳定性与数据安全性）。
• 2022：云原生（尝试下一代微服务治理架构）。

架构演进核心

• 暴露缺陷：业务持续发展暴露设计缺陷或出现更好的解决方案。
• 解决问题：针对各类问题点专项攻坚。
• 架构升级：上升到框架层面的调整。