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功能
- 發現能力：
配置變更系統打通風險防控體系，服務有異常會自動進行風險提示和變更攔截。
圖7.配置變更風險提示和攔截
- 止損能力：
配置常態回滾和快速回滾能力
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都可以自助在平臺上完成所有接入引擎相關工作，提高研發和運維的生產力。
作者介紹：
李炳毅，滴滴高級專家工程師
本文轉載自公衆號滴滴技術（ID：didi_tech）。
原文鏈接：