GIAC 大会丨蚂蚁金服于雨 :管中窥豹,谈 2021 云原生技术发展及未来趋势
- 作者简介 -
于雨(github @AlexStocks),dubbogo 社区负责人,一个有十一年服务端基础架构和中间件研发一线工作经验的程序员。
陆续参与和改进过 Redis/Pika/Pika-Port/etcd/Muduo/Dubbo/dubbo-go/Sentinel-go 等知名项目,目前在蚂蚁集团可信原生技术部大规模 k8s 集群调度团队从事容器编排工作,参与维护全球规模最大的 Kubernetes 生产集群之一,致力于打造规模化、金融级、可信的云原生基础设施。
- 前言 -
本人有幸担任了 2021 年 GIAC 会议云原生专场的出品人兼讲师,组织了前后四个场子的演讲,在这个过程中个人同时作为听众从这些同行的演讲中学到了很多非常有用的知识。本文算是对 2021 GIAC 云原生专场的侧记,管中窥豹,以观 2021 年云原生技术发展现状及未来一段时间内的趋势。
亚马逊的资深技术专家黄帅的《一个云原生服务的爆炸半径治理》 快手基础架构中心服务网格负责人姜涛的《快手中间件 Mesh 化实践》 Tetrate 可观测性工程师柯振旭的《使用 SkyWalking 监控 Kubernetes 事件》 本人以 Dubbogo 社区负责人出品的《Dubbogo 3.0:Dubbo 在云原生时代的基石》
- 云原生服务的爆炸半径 -

服务粒度适中 微服务的服务粒度并不是拆分的越细越好。如果服务粒度过细,会导致服务数量过多,其第一个后果就是导致一个组织内几乎无人能搞清楚服务整体逻辑的来龙去脉,增加维护人员的负担:大家只敢小修小补无人敢做出大幅度的优化改进。 服务粒度过细的第二个后果是造成整体微服务单元体指数级增加,造成容器编排部署成本上升。适中的服务粒度要兼顾架构体系的进化与部署成本的降低。
充分隔离 进行服务编排时,获取数据中心的电源和网络拓扑信息,保证强相关系统之间部署做到“不远”且“不近”。 “不近”是指同一个服务的副本不在使用同一个电源的同一个机柜部署,也不在使用了同一个网络平面的 Azone 内部署。“不远”是指部署距离不能太远,例如多副本可以同城多 IDC 部署。使用这两个原则兼顾性能与系统可靠性。
随机分区 所谓的随机分区这块,其实质就是在混合服务请求,保证某个服务的请求可以走多通道【队列】,保证在某些通道挂掉的情况下不影响某个服务的请求处理,应用随机分区技术,将用户打散在多个 Cell 中,大幅度降低爆炸半径。 与 K8s APF 公平限流算法中的洗牌分片(Shuffle Sharding)颇为相似。
混沌工程 通过持续内化的混沌工程实践,提前踩雷,尽量减少“故障点”,提升系统可靠性。
- 使用 SkyWalking 监控 Kubernetes 事件 -



- 快手中间件 Mesh 化实践 -


统一运维,提高可观测性与稳定性,进行故障注入和流量录制等; 对 Envoy 等做了二次开发,只传输变更的数据、按需获取,解决单实例服务数过多的问题; 对协议栈和序列化协议做了大量的优化; 实施了面向失败设计,Service Mesh 可以 fallback 为直连模式。
成本问题:复杂环境下的统一部署与运维。 复杂度问题:规模大、性能要求高、策略复杂。 落地推广:对业务来说不是强需求。
首先务必保证系统稳定性,不急于铺开业务量; 搭车公司重大项目,积极参与业务架构升级; 基于 WASM 扩展性,与业务共建; 选取典型落地场景,树立标杆项目。

- Dubbogo 3.0:Dubbo 在云原生时代的基石 -

机器规格:大规模服务下机器规格难免异构【如受超卖影响】,即使同规格机器老化速度也不一样; 服务拓扑复杂:分布式服务拓扑结构在不断进化; 服务流量不均衡:有洪峰有波谷; 依赖的上游服务能力不确定性:缓存/db 能力实时变化。

limit 一段时间内的 qps 上限。 rt_noload 一段时间窗口内的 RT 最小值。 rt 一段时间内的平均 RT,或者可直接取值 P50 RT。
- 场外 -

评论