滴滴七層接入平臺實踐和探索

桔妹導讀：滴滴七層接入平臺負責滴滴全公司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年分別有兩次致使全平臺故障的p一、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
滴滴技術 出品