高德-福辰-高德云原生架构变革与演进

高德云原生架构变革与演进 刘金龙(福辰)高德地图-技术服务平台架构师 讲师简介 姓名 刘金龙(福辰) 职位：高德地图-高级技术专家(技术服务平台架构师)过往经历：曾就职于滴滴、360、赶集网等公司 “ 开源贡献者：RSocket-go、Reactor-go、Stable-Diffusion-webui、Stable-Diffusion-webui- Controlnet… 工作内容：负责部门架构改造和中间件&基础服务开发项目重要经历： •交易架构升级 •359行交易业务 •异地多活-交易单元化 •行业无关化架构–低代码之乐高2.0 •风控&资损 •… www.top100summit.com ” •云原生生态落地–Serverless&Mesh •稳定性保障 •… 目录 CONTENTS 01架构优化/生态&架构变革 02平台赋能/提效降本 03案例总结/由杂变简 04未来展望/云原生终局 www.top100summit.com www.top100summit.com 主题 架构优化/生态&架构变革 •Go生态 •云原生生态–Serverless&mesh(简) •架构优化升级 01 SUBJECT 生态变革-全历程 2019 高德上云，跟中间件打通，大部分服务端均为Java 我们的追求：开发快、投入少、效率高 www.top100summit.com •切云原生架构第一步 •Go&中间件生态建设 •架构升级-无关化&单元化 •… 2023 19年前，很多服务出现了性能问题，当时Go语言比较火且表现非常好，于是开始尝试用Go来开发。截止目前Go流量接近千万QPS GO&中间件生态 2019 决策：切GO，构建生态 GO优势： •性能高(cpu&内存) •编译、启动快 •体积小 目标：提效&降本 痛苦期：持续优化，各种踩坑 •完备中间件能力 •优化中间件性能 第一个目标：做加法，•最…小集完成，业务开始切GO 中间件： •Vipserver •配置管理 •RPC调用 •基础组件 •… •新的中间件需求 •… 完整GO中间件生态 •沉淀出30+中间件 •稳定性&中间件平台 www.top100summit.com 推广期：生态雏形，大量切GO •日常中间件完备性 •初具中间件平台能力(灰度、引流、压测、评估等) •开发了高德Serverless架构 大团队要求：切云原生架构,大量的Serverless架构应用涌出，本质是降低研发门槛。 为什么要投入建设Serverless生态 早期 方案 端、云一体化： •端-->云+端-->端云一体。 •云上的开发像端上一样，一套代码，两地运行。 •端云一体、产研同频。 理想目标： •新功能开发，端云无差别，端上开发的功能直接搬到云上运行。 •加快迭代效率，降低成本。 •FaaS使服务的开发变得简单。 简单：3个人搞定！ 问题 客户端体积重 耗电量非常高 产品迭代效率慢 客户端发版成本高 … 思考 早期 现在 实践 快速迭代 节约流量 客户端上云 客户端瘦身 降低耗电量 经常变动Bservice从本地部署到服务端 •Bservice是非常小的Function(FaaS) •过度：调用失败，需要能降级到本地调用 新需求在Faas端开发，提升开发迭代效率 成败的关键点在于：客户端和FaaS的接口协议定义 端云一体，一套代码，两地运行 现在 业务场景单一、量大、能降级场景 www.top100summit.com Serverless生态建设 核心：开发简单，支持多云架构 www.top100summit.com one编译/发布 网关业务灰度、业务切流 FCAPI/RPC/EventingGateway 运行态 ASIDeployment Autoscaling Couting AutoScaling Pooling Component Hsf/Tair/MetaQ/diamondproxy Broker C++/Rust/GoFaasRuntimeContainer ADaprsidecar POD eagleEyeagent SunfireAgent Runtime 用户函数包 研发态 监控大盘 压测平台 性能对比 Benchmark 灰度发布 Aone编译/发布 本地开发调试 Faas脚手架(Runtime|例子|调试…) 运维态 … 防腐 切流 全链路日志 GOC告警监控 Sentinel Sunfire大盘&监控 SLS日志收集 鹰眼全链路 研发态 效率，简单&高效研发 运行时 效率，高效研发性能，极致性能 降本，弹性调度 运维态 治理，服务管控 防腐，数据大盘+优化 灭火，快速止血，高效监控 后续AllINDapr生态，打造MultiRuntime基座(涵Mesh)，解决东西流量异构和工具治理的问题，最终融合边节点 为什么要做ServiceMesh QPS飞速增长 风险 痛点：1、故障爆炸半径大2、多一跳，带来性能瓶颈3、升级和扩展困难 云原生架构升级 www.top100summit.com 易为瓶颈&成本&效率 高德特点 落地 OnServiceMesh VS 解题 稳定 性 提效 去中心 化 隔离 降本 接口量迅速增长 业务增速 OnSDK 底层引擎多语言、多框架，对跨语言/跨框架诉求强 透明升级，⽆侵⼊业务， 让业务开发回归业务，为业务提效 采用Mecha的 S erviceMesh落地 ServiceMesh架构 未来：可控 南北流量&边缘节点 东西流量 •可以通过类似Envoy的数据面来管理 •未来自研LeapMesh(异构语言VM->Filter), 路线：由边缘工具->Gateway->Ingress •可通过部署类似Dapr的Sidecar进行通讯 （MultiRuntime工具集合） www.top100summit.com 解多语言访问中间件： 内聚在业务中的中间件访问，可下沉到Sidecar中 如TDDL的访问，基于dapr-like可在本机暴露为标准MySQL协议，nodejs/python/c++等服务就可像连接本机MySQL一样访问TDDL库等 为什么要做行业无关化架构 359行，行行不一样 www.top100summit.com 目标交易 359行 挑选 单行业验证 验证成功 规模化复制 规模扩大 精细化管理 技术支撑 新业务快速接入的能力 承接千万级订单的能力 低代码之组装式研发–行业无关化架构 面向359行行业无关化架构设计 流程引擎 1、强大的编排能力：支持串行、分支、并行、父子流等 底层引擎 库 1.通用基础组件 2.业务组件库 3.业务部件库 业务能力： 业务X：行业无元数据抽象+自定义表达 业务编排：基于业务的流程编排、服务编排。 业务域：基于元数据的业务域能力，组件能力等；核心能力： 领域能力乐高组件化+服务编排能力+BFF/BaaS扩展 协议统一+服务BFF和端BFF打通 www.top100summit.com 2、支持事件机制：定时事件（时延、时刻）、消息事件以及信号事件等 3、任务自动恢复防丢失（即使服务器重启或者无故宕机也可自动恢复）；支持租户隔离；支持针对不同的流程配置线程池大小，避免流程间相互干扰；支持自动重试和自动跳过等 4、高性能：强大的分布式调度策略确保高效的调度能力；同时核心读写操作全部基于缓存层实现；未引入任何事务，所有核心逻辑都支持幂等性保证 扩展架构，SDK&Server并存 为什么需要单元化架构359行，业务体量大，出问题受损严重 •痛点：核心业务依赖机房，无法做到真正的容灾，具备快速恢复自愈的能力 •目标：建设一种通用的交易容灾架构，让核心业务具备异地容灾(单元化)的能力，故障快速恢复的能力 •名词：异地多活 •同城双活 •伪双活的单边架构 •主库机房出问题依然会影响全量业务，灾备切换时间较长 •依然受地域资源限制和重大自然灾害影响，比如地震、电力限制 •异地冷备 •纯冷备，资源严重浪费 •日常不跑流量，不敢切流 •即使切流，没有任何预热也很难扛住 •单元封闭✅ •数据单元内闭合，读写均走当前单元 •依然受地域资源限制和重大自然灾害影响，比如地震、电力限制 •疑难杂症 •距离导致的网络时延是物理限制，不可能突破 •多次跨地域的调用会严重影响服务RT，导致用户体验严重下降 •网络时延对数据一致性是巨大挑战，要写业务多活更是难上加难 核心：快速自愈，影响面最小 www.top100summit.com 大胆假设：类似分库分表思路，业务数据需要进行分区治理(Shard)？ 异地多活之单元架构 异地多活，单元封闭 单元划分模式： ✅ •Unit：即所有读写流量在单元内完成，有异常不会影响其他单元。随时切流 •Copy：读流量走单元服务，写流量走中心服务。单元切流无异常，中心服务出问题，整体都会出问题 数据一致性： •做到演练态不丢数据，做到容灾态数据可修复等 •对于数据不一致给出确定性的结论，在真正故障时多少用户、多少订单会不一致，会造成多大的资损等 www.top100summit.com 单元化 •统一配置管控 •单元内封闭 •服务可见性 •支持压测 •支持灰度 www.top100summit.com 生态架构变革-遇到的问题 C++Runtime遇到的问题： •许多库需要源码安装，不同版本之间有冲突(解决：Docker化) •如：rsocket、folly、boost、glog、proxygen等。既要满足linux又要满足mac上的使用，否则没办法满足日常开发的需求 •中间件在c++上支持不足，很多要么没有sdk，要么不支持mac(解决：补齐缺失) •缺失异步版本的C++HttpClient且能适配Reactive的库 •镜像臃肿，下载时长问题(解决：Docker分段编译) •性能瓶颈问题(Docker拿不到真实的cpu，解决：动态计算+默认指标) •… GoRuntime遇到的问题： •链路死循环 •RSocket-go回调所在的Readloop是同步的，Runtime既做发起方又做回调方就形成了链路死循环(解决：队列分离+异步回调队列) •内存使用过多 •MONO放大，内存使用过载(解决：oneshot机制) •Playload的Bytes使用过量(解决：bytebuffer) •性能损耗较大 •Slice申请过多，扫描成本高(解决：GOGC=xxx) •Payload的Zerocopy •Payload的bytes是走的bytes池子，得确保在DoOnXXX里，如果逃逸要走一遍Clone •… RustRuntime遇到的问题： •集团中间件Rust生态缺失(解决：补齐生态缺失) Serverless-FaaS问题 架构优化： •流程链路无法超时(解决：整体timeout和分任务超时) •并发时机触发插队(解决：多维度计算插队机制) •支持分布式任务机制(解决：架构剥离，SDK&server) •支持多协议和自定义协议(解决：核心抽象支持协议，任务等自定义) •… 存储优化：(解决：组合式选择) •BoltDb：Input&OutPut较大，性能有问题 •Badger：wiskey+ttl机制，GC时候回丢失sst和vlog索引 •纯内存：无法进行任务恢复和回滚 存储模式：(解决：自定义配置) •存储中间件兼容 •MySQL协议适配 •本地磁盘存储 •本地内存存储 行业无关化架构问题 … Sequence如何改造，避免浪费：：(解决：单元不同步，流量增加会继续利用) •单元化后，Sequnce号段浪费，基本是剩余行业*步伐 单元化后，压测链路是否影响：(解决：流量染色，支持混压) •359行，单元化后，服务质量工具应如何变化最小 架构耦合，规则