桔妹導讀：滴滴七層接入平臺負責滴滴全公司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
滴滴技術 出品