珍爱微服务底层框架演进

1. 珍爱微服务底层框架演进珍爱网网CTO / 彭万亮

2. 关于我当当网从0到1建设商家平台艺龙网推出rpc通讯框架，监控解决方案珍爱全量上云，容器化改造及双云双活落地。开源爱好者，热衷于开源技术的分享和交流。

3. 痛点 u 技术成熟度？性价比如何？ u 云原生？开源？自研？ u 如何引入到业务？精力有限旧业务很难接入尝试最终技术方案：云原生+开源+自研

4. 整体概况 • 2018年珍爱网业务规模爆发性增长，业务系统出现瓶颈。我们着重建设基础架构。在诸如服务架构、基础组件、研发流程、研发规范多维度解决问题与综合考量。 • 在长达4年的架构演进之路上，我们经历了微服务拆分、链路优化、上云、容器化、双云双活，在每个环节我们都有相应的思考，在反复地暴露问题、解决问题之后，最终沉淀出一套珍爱特色的微服务治理架构。

5. 整体概况构建一套底层框架 • 整合开源框架，结合业务二次开发 • 构建一套技术规范 • 统一技术底层

6. 背景介绍

7. 背景介绍

8. 核心心思想 1. 统一技术栈以支撑多线业务同时发展 2. 引进开源技术时须进行合理的整合与改造 3. 解决现有问题不是终点，技术架构必须要有前瞻性 1. 避免重复造轮子，合理利用开源框架和云技术 2. 避免过度引入和设计 3. 问题发现，解决问题，持续迭代

9. 基本思路路

10. 微服务拆分 u Spring Cloud+Dubbo微服务框架 u 引入API-Gateway，统一承接南北流量 u 搭建zhenai-framework，作为应用基础框架 u 引进主流开源中间件

11. 微服务框架珍爱user接口压测TPS结果 • 引入网关统一承接南北流量 • API层负责业务逻辑编排 • 抽离Provider层实现原子业务逻辑，并直接与数据层对接 • 树状调用结构

12. 微服务框架 Spring Cloud API-Gateway 路由验签 DDD unify-pay Framework 熔断/限流跨域 verify core-user 黑白名单其他领域 adapter application domain • 领域建模的设计方法让业务领域边界更清晰 infrastructure • 各业务领域实现以分层分包的方式进行代码组织，结构更清晰，更合理。 Dependencies Data Service Mysql Redis MQ ES Common Service • 在部署上，将原api层和 provider层合并在一配置中心注册中心个节点上，能提高调用开销并节省硬件资源

13. 网网关层核心心逻辑基于Spring Cloud Gateway，扩展 filter，提供： • 请求验证 • 黑白名单 • 基于sentinel的熔断限流 • 合并请求 • 重试优化 • 优雅停机 • 启动预热 • 访问日志上报

14. 合并请求网关MergeFilter在不改动原接口前提下，允许客户端对请求组合编排，将多个请求合并为一，其目的是减少页面初始化时请求数过多的问题。其功能如下： • 拆分请求：解析自定协议，将合并请求拆分为实际请求组。 • 并行执行：并行执行实际请求组，设置监听返回。 • 合并响应：改写response，以合并请求组下游服务响应。 • 降级和重试：配置超时和异常降级，并对失败请求执行重试。 • 请求监控：监控耗时差异过大的请求组，以优化编排。

15. 数据层系统稳定性和性能最关键的一环故障点占比原因数据库 70% 业务共用数据库，相互影响；数据接入层使用 Mycat存在单点问题应用 20% 应用共享物理机，未做资源隔离其它 10%

16. 数据层拆分 • 一应用一数据库是微服务治理的重要原则 • 之前未做是因为数据库管理成本较大 • 上云后使用云数据库，基础设施能力的提升，有助于快速实现目标架构

17. 去除数据中间层 • 去掉中间件Mycat，应用直连数据库 • zhenai-framework管理公共配置：分库分表算法、id 生成规则、路由工具类等

18. 去除数据中间层修改连接刷新方式开发Sharding配置刷新/同步功能使用sharding做大表拆分 • • • • • • • • • • • • • • 支持一表多分片键支持HintManager上下文的手动控制模式支持分片键值为不等式的路由支持配置文件中的数据库密码加密支持高级MYSQL语法如GROUP_CONCAT 支持分片key非大小写敏感支持执行SQL的线程池可配置新增Sharding-proxy功能：用户权限控制、route、explain、动态刷新配置优化表META信息加载速度，单库上千张表时由10分钟缩短至1分钟以内修复默认数据源定位错误问题，动态刷新配置时，本地route结果缓存未更新问题修复单节点时limit可能出现Integer.MAX_VALUE的问题修复字符串分片的SELECT语句的异常修复部分配置不生效问题，如connectionInitSqls/testWhileIdle 修复物理连接被多次初始化问题

19. 进一一步减少异常

20. 全链路优雅停机

21. 服务重启流量控制预热时间⻓长 VS 滚动重启时，时间线将会拉得很⻓长；并且在某些场景(如k8s roll restart)下滚动重启的时间间隔不不可控预热时间短 JVM预热、本地缓存等都需要时间，太短会导致CPU飙升、响应变慢都不不好启动时间均衡算法，最后启动的实例例将承担大大部分流量量启动时间加权算法，滚动重启全程均衡各实例例流量量

22. 回顾

23. 字节码增强 • Agent使用Java字节码无侵入式采集http访问日志， dubbo访问日志，业务日志，通过UDP上报到 collector服务器 • collector服务器将数据分别写入kafka、es、HBase

24. redis封装借鉴了MyBatis Mapper的思想，在定义的时候先声明存储结构和存储对象类型

25. web层

26. 研发流程 u 资源隔离不充分 u 并行需求联调/测试困难 u 部署流程过多人为参与 u 多套环境难于管理

27. 研发流程构建整个过程伴随着对zhenai-framework的修改，减少了业务方的感知；助于我们快速进行推广落地 zhenai-framework

28. 容器化插件 zhenai-dockerx-plugin是maven 插件，使应用透明接入docker、 k8s。其功能： • 检查：分支检查、k8s ns检查 • 打镜像：使用zhenai-dockerx- base作为基础docker镜像 • 构造编排yaml：模拟模板渲染出 k8s deploy/svc的yaml • 部署启动：调用k8s接口部署 • 多环境管理：编排文件区分环境 • 组件管理：根据mvn参数判定是否部署对应组件，如nginx，主要用在开发、测试环境

29. 插件发布流程

30. 需求隔离测试

31. 发布流程简化 • 全流程封装，自动触发或简单命令触发各类任务 • 开发人员只需少量感知，极大提升需求上线效率

32. 单元化 • 容器部署隔离 • 依赖存储隔离 • 配置中心区分配置项 • 注册中心正确路由

33. 网关与底层单元化 • 网关作为流量入口首先实现单元化 • 通用的底层服务也有单元化的需求

34. 业务单元化 • 组建业务单元，相互隔离 • 业务单元内的app也可实现单元化 • Framework是基础框架 • 中间件/平台进行软隔离

35. 回顾

36. 双云双活 u 双活是高可用的延伸 u 应用双活/数据灾备 u 流量不跨云 u 基础框架支持，减少应用感知

37. 底层架构适配双云双活 • zhenai-framework 封装数据接入，与适配中间件 • 中间件支持双云模式

38. 双云优势

39. 整体回顾服务拆分治理数据层 zhenai- framework 容器化与 devops 云云双活

40. 架构演进核心暴露缺陷业务持续发展，架构持续迭代暴露设计缺陷；或业务出现更好的解决方案解决问题针对各类问题点专项攻坚架构演进架构升级上升到框架层面的调整

41. 架构演进之路 2018 数据层改造托管基础设施，助力 2019 于更好地实现微服务架构双云双活进一步提升服务稳定 2021 性与数据安全性云原生 2022 尝试下一代微服务治理架构微服务拆分业务快速发展，需求持续迭代，服务拆分不得不做 2020 容器化与DevOps 与微服务架构相辅相成

42.

43.