关于数据库:滴滴七层接入平台实践和探索

8次阅读

共计 5488 个字符,预计需要花费 14 分钟才能阅读完成。

桔妹导读: 滴滴七层接入平台负责滴滴全公司 http 东西向和南北向流量的接入,其申请峰值 qps 数百万,日申请量数千亿,接入域名数千个、接入服务数千个、转发规定数万个,其稳固高效的运行对于保障滴滴业务至关重要。本文将次要介绍七层接入平台在服务治理和稳定性建设上的实际,同时也分享其在云原生畛域一些摸索和布局。

1. 详情

从 2014 年底诞生至今,滴滴七层接入平台服务规模如下:

  • 负责全公司 http 申请东西向和南北向的流量接入和治理,波及多个事业部。
  • 申请峰值 qps 数百万,日申请量数千亿,接入域名数千个、接入服务数千个、转发规定数万个。

千亿级的流量转发规模不仅对系统本身的稳定性和性能提出了极大的挑战,业务对接入平台也提出了更高的冀望:除了本身稳定性和性能外,平台要进一步赋能和助力业务稳定性和效力的晋升,具体体现在:

  • 本身稳定性

    可用性 99.99%

  • 本身性能

    均匀转发延时 <1ms

  • 稳定性赋能

    作为 http 服务对立的技术底座和稳定性能力规模化重要抓手,输入各种稳定性根底能力赋能到业务稳定性的建设和晋升。

  • 效力赋能

    开掘痛点,进步研发 / 运维 / 测试全生命周期的效力。

通过 5 年的继续迭代和演进,滴滴 7 层接入平台整体架构如下:整体上分为数据面和管制面两局部:

数据面:
基于开源 nginx 建设,提供高稳固、高性能、多协定、平安的流量接入和服务治理。

管制面:

  • 接入和配置变更: 自研配置变更平台,用户能够通过配置变更实现域名或服务的接入,并配置丰盛的规定和策略。
  • 可察看性: 申请数据联动滴滴监控体系,提供面向全公司的 http 服务细粒度和多维度监控以及监控大盘。
  • 服务治理: 服务治理联动滴滴公司级别 911 预案平台、放火平台,提供体验对立的预案治理和故障注入操作能力。
  • 服务发现: 服务发现联动滴滴对立名字服务 DSI(Didi Service Information),提供稳固、实时的服务发现能力。
  • 平安防控: 平安防控联动公司 WAF 零碎,对滴滴全公司应用层平安进行保驾护航。

本文将从以下三个方面进行滴滴七层接入平台的实际和摸索介绍:「服务治理能力建设」、「稳定性建设」和「云原生时代接入平台摸索」。

2. 服务治理能力建设

咱们将从以下几个方面进行服务治理能力介绍:「服务发现」、「预案能力」和「可察看性」。

服务发现

通过调研,社区罕用的 upstream 动静更新计划有 4 个:

以上计划均不能齐全满足咱们的需要,参考计划 3 和计划 4,咱们从新设计了 nginx upstream 动静更新模块,兼顾了稳定性、性能和可维护性,反对全公司 http 服务的服务发现,波及数千个服务,特点如下:

  • 采纳增量更新 upstream server 机制
  • 提供基于 HTTP Restful API 的轻量 upstream reload 接口,实现对 upstream 的动静变更
  • 齐全兼容现有配置形式
  • 对配置进行长久化

同时通过接入平台的服务发现实际,咱们形象出公司级名字服务 DSI(Didi Service Information),DSI 通过 open api,除了接入平台外,公司服务发现 SDK DiSF、四层代理 DGW、容器平台、部署零碎等零碎也曾经全副和 DSI 进行了买通联动,造成了公司基于 DSI 的对立服务发现体系,同时基于这套服务发现体系,也陆续孵化出一些稳定性工作的平台和能力,比方主动哨兵压测平台进行子系统容量准确评估和预警,比方对业务通明的无损公布机制等。

预案能力

咱们基于接入引擎建设了 http 服务对立的限流、切流、故障注入等底层服务治理能力,并且和公司级 911 预案平台、放火平台买通联动,提供对立和易用的操作界面供用户应用,具体包含:

  • 多维度限流能力、限流阈值主动举荐能力、限流阈值自适应能力,目前曾经成为公司稳定性保障的重要抓手
  • 多维度切流能力,在滴滴专快异地多活、子系统切流和业务上云灰度中起到了重要的作用
  • 基于接口粒度的错误率和延时故障注入能力,曾经开始陆续在强弱依赖验证、预案有效性验证等场景中发挥作用。

可察看性

作为流量门户,接入平台通过输入申请规范数据并买通 SRM 服务可察看性零碎,对公司 http 流量的可察看性起到了重要作用。

3. 稳定性建设 

七层接入平台作为公司的超一级服务,对稳定性有着极高的要求,如果接入平台呈现稳定性故障,很有可能导致滴滴全平台业务不可用,对公司带来微小的经济和品牌损失。除了建设稳定性根底能力外,咱们还从以下 3 个方面重点进行七层接入平台的稳定性建设:「归零危险防控」、「接入引擎架构降级」和「配置变更危险防控」。

归零危险防控

咱们总结接入平台次要的归零危险为:代码变更异样、容量有余、外网高可用能力欠缺、运维误操作 4 类,相干应答措施别离为:

代码变更: 技术上全副采纳公司代码变更危险防控机制的最严规范强制管制,流程上要求变更必须要跨天实现,至多经验早晚两个顶峰。

容量有余: 制订了疾速扩容技术计划,目前正在尝试通过对接入引擎容器化进步弹性伸缩能力。

外网高可用能力 :通过 httpdns 进行流量切换和自建 / 非自建进口调度能力进行外网止损能力建设。

运维误操作 :所有高风险运维操作必须 double check 和分级、运维操作隔离域性能的利用。

接入引擎降级

最开始咱们应用的接入引擎是 tengine,版本为 2.1.0,公布于 2014 年 12 月,tengine 基于的 nginx 版本是 1.6.2,2014 年 4 月公布,到 2018 年,咱们陆续发现一些接入引擎的稳定性问题,次要体现在以下 3 方面:

  • 一些暗藏较深的 bug 不断在接入引擎上呈现,修复老本和危险都较高,而最新的 nginx 曾经全副修复。
  • 一些新的需要在 tengine1.6.2 的架构下曾经很难持续演进和倒退,比方动静 upstream 反对、一致性 hash 算法反对服务发现等,团队的研发效率和零碎的可扩展性都无奈失去更好的满足,最终也会体现在稳定性危险上。
  • 一些稳定性能力晋升的性能在最新 nginx 版本下曾经失去了反对,比方 worker_shutdown_timeout 和 reuseport 指令等,而咱们还没有方法间接应用。

为了彻底解决这 3 个方面的稳定性危险,咱们将接入引擎从 2014 年的 tengine 胜利降级到 2018 年的 nginx,同时进行了很多优化工作,次要收益如下:

  • 修复了 8 个重要性能性能 bug,其中 5 个在线上曾经产生 
  • 进行了 15 项重要性能改良和优化,其中 5 个曾经在线上触发问题。
  • 解决了公布更新时局部实例流量抖动,重大时甚至 cpu 掉底的问题
  • 解决了一致性 hash 算法在实例调权时全副接入引擎吞吐降落,业务激烈抖动和报警的问题 
  • 创新性解决了 srww 算法在有哨兵场景下进行压测或者公布更新时服务激烈抖动,重大时甚至 cpu 掉底的问题,相干 patch 正在整顿中,打算提交给 nginx 官网社区,后续也会整顿文章对外分享。

除了稳定性收益外,引擎降级新增了 6 个业务强需要的性能和 5 个业务有预期的性能,久远看对接入引擎长期演进也奠定了良好的稳定性和扩展性根底。

配置变更危险防控

接入平台在 2016 和 2017 年别离有两次导致全平台故障的 p1、p2(公司事变等级,最高 p1)事变,起因全副为配置变更引起,接入平台的配置形容能力过于弱小和灵便,在提供丰盛灵便能力的同时不可避免会带来稳定性的隐患,因而配置变更的危险防控能力就作为稳定性保障的重中之重,咱们设计实现了接入平台配置变更平台海姆,平台形象和束缚了接入引擎配置模型,同时将代码部署的危险防控能力全副复用到配置变更零碎上,配置变更危险失去了较好的防控,再也没有呈现过因为配置变更导致的 p2+ 故障。海姆平台的次要危险防控特点如下:

  • 预防能力:

    配置模型的形象和束缚

    配置语法检查和语义查看能力

    配置强制 review 性能

    配置分级公布性能(反对不同服务配置并行公布)

    配置强制 double check 性能

  • 发现能力:

    配置变更零碎买通危险防控体系,服务有异样会主动进行危险提醒和变更拦挡。

  • 止损能力:

    配置常态回滚和疾速回滚能力

4. 云原生时代接入平台摸索 

多协定反对

多协定反对是云原生接入平台十分重要的一个能力,业内支流的数据面 sidecar envoy/linkerd2-proxy/mosn 等都具备多协定反对的能力,而滴滴东西向流量最宽泛应用的协定就是 http 和 thrift。

2019 年随着接入平台对 http 协定流量治理和服务治理实际的成熟和 thrift 协定对立高效服务治理的迫切性,咱们启动了接入引擎反对 thrift 协定的专项研发攻坚工作,目前曾经在金融业务线进行了多个模块的落地,帮忙业务解决了服务优雅公布、可察看性等痛点, 最近 Nginx 官网社区也曾经认可承受咱们的代码作为第三方模块,目前正在开源筹备中,thrift 接入引擎具备如下的特点:

  • 通用 thrift 编解码器:

    反对多种序列化协定,包含 TBinaryProtocol、TcompactProtocol

    反对多种传输层协定,包含 Tsocket、TFramedTransport

    协定编解码无需 IDL

    模块化设计,很好的可扩展性

    编解码器提供通用接口,非 nginx 绑定,能够集成到其它代理中应用

    基于树的灵便高效 IDL 字段 Setter 和 Getter(Doing)

  • 模块化设计:

    转发能力模块化,可作为独立的第三方模块集成到 nginx。

  • 简略易用:

    配置模型根本同 http,简略易上手

  • 功能强大:

    和 http 打平的服务治理能力,包含可察看性、限流、路由等

  • 高性能:

    多过程异步无阻塞的编解码和申请转发模型

接入引擎 mesh 化

在集中式接入引擎诞生的 5 年多工夫内,其继续在流量治理和服务治理上对业务稳定性保障进行赋能,随着云原生时代的到来和服务治理逐渐进入深水区,集中式接入平台面临着新的挑战:

1. 极致的稳定性要求

集中式接入引擎始终有 3 个无奈回避的稳定性隐患

① 多业务共享集群:

互相可能有影响:尽管通过稳定性机制建设的欠缺,近 3 年来没有因而带来稳定性事变,但共享集群的危险始终没有彻底铲除,尤其在一些新性能开发和利用实际时始终如履薄冰,比方针对某个服务申请进行故障注入时实践上依然可能对其它业务线带来影响。

② 鲁棒性较弱:

业务对接入引擎延时十分敏感(毫秒级要求),数万 qps 下接入引擎有时单机甚至单过程延时抖动就会对敏感业务带来较大影响,甚至触发业务线一级报警,运维同学承当着微小的心理压力。

③ 容量边界的不确定性:

七层接入平台前往往还有一个四层接入代理,通过 vip 提供给业务方应用,二者对容量的精准评估和疾速的弹性伸缩能力都有很高的要求,否则很有可能存在雪崩的归零危险。

2. 极致的运维效率

①接入引擎和业务服务生命周期不同,整个接入体验不好,效率较低。

② 转发规定的保护老本很高

以上 2 点导致服务治理能难以较低的老本进行规模化落地,咱们正在联结业务团队、弹性云和研发云团队做接入引擎 mesh 化的摸索工作,mesh 化后以上的挑战将会失去很大水平的化解,目前正在仿真环境将接入引擎 mesh 化到客户端侧解决流量闭环的问题。

5. 总结

通过 5 年多的倒退和演进,滴滴七层接入平台在稳定性能力建设、服务治理能力建设、云原生接入的摸索获得了一些停顿:

规模化的服务治理能力

  • 反对公司全公司 http 服务限流预案 400+、限流接口 2400+、切流预案 400+。
  • 持全公司 http 服务的服务发现,波及数千个服务。
  • 反对全公司 http 服务可察看性能力建设,包含规范监控和细粒度多维度监控。

一级的稳定性保障能力

零碎可用性 >99.99%,转发延时 <1ms,间断 3 年没有对业务可用性带来影响。

云原生接入引擎摸索

  • 实现接入引擎多协定的反对。
  • 实现接入引擎 mesh 化摸索,并买通相干管制面,行将在业务试点上线。

6. 将来瞻望

云原生接入引擎

云原生时代曾经降临,咱们置信在可见的将来,就像 TCP/IP 协定栈或者 SDN 一样,接入引擎肯定会形象出更通用的应用层流量治理和服务治理能力,作为 sidecar 下沉并固化在整个基础设施中,在屏蔽滴滴异构架构、异构技术栈、多语言、多协定业务特点进行规模化服务治理和将业务逻辑和根底施设解耦中施展重大作用。

多模微服务治理

因为多 BU、历史包袱、业务技术栈偏向的特点,将来的利用架构必然不可避免异构化,即便如此,接入引擎 mesh 化也不是银弹,它在很长时间内会须要和传统基于 SDK 的服务治理和基于集中式接入平台的服务治理造成合力、组合补位,以一套组合拳的形式独特保障滴滴全平台的稳定性,晋升运维 / 研发 / 测试的效力。

一站式七层接入平台

从用户角度看,七层接入平台目前的定位依然是一个专家系统,服务的用户次要是有着丰盛运维教训的 SRE,不论是接入引擎例行变更需要、问题剖析定位还是服务治理能力赋能,业务 RD 更多状况下依然须要寻求 SRE 的反对和帮忙,这带来大量的沟通老本,进一步升高了整体业务交付效率,咱们冀望打造一个体验敌对的一站式七层接入平台,业务 RD 和 SRE 都能够自助在平台上实现所有接入引擎相干工作,进步研发和运维的生产力。

团队介绍

滴滴云平台事业群服务中间件团队负责为公司提供对立的七层流量接入和服务治理基础设施,通过多年的技术积淀,团队在微服务框架、云原生服务治理、网络协议、拜访品质、负载平衡、代理技术等畛域积攒了丰盛的教训,咱们始终致力于构建稳固、高效、易用、通用的流量接入和服务治理平台,相干产品和平台在滴滴均有大规模的实际利用和落地。

作者介绍

滴滴服务中间件团队负责人,多年高并发、高吞吐零碎设计研发经验,在微服务治理和稳定性建设畛域有较丰盛的教训,对云原生技术感兴趣,曾就任于百度,从事对立接入零碎研发和运维工作。

延长浏览

内容编辑 | Teeo
分割咱们 | DiDiTech@didiglobal.com

滴滴技术 出品

正文完
 0