淘寶應用柔性架構的探索

導讀：隨着淘寶業務的飛速發展，微服務架構在持續演進的過程當中，也受到了愈來愈多的挑戰：如同步模型帶來的資源利用率有限、依賴調用併發度有限、下游故障引起應用自身出問題；又如靜態限流隨着業務代碼的演進、依賴拓撲的變化、部署環境的調整，而形成過期引發的穩定性隱患等挑戰。

ArchSummit（全球架構師峯會）上淘寶高級技術專家——澤彬分享了爲應對這些挑戰，淘寶基礎服務在淘系架構升級上（代號 Tango ：Taobao Architecture Next GeneratiOn ）對這些問題的認識以及讓應用面對突發問題時更具柔性（應用柔性架構）的一些探索。

Reactive 全異步化

當前咱們的微服務主要是基於同步的調用模型，帶來了以下挑戰：

• 同步等待形成應用資源利用率很難進一步提高
• 併發度有限，技術實現沒法作到業務理想程度的併發，致使 RT 增長
• 下游出現問題會致使應用自己出現問題（如應用等待下游響應的線程會被長時間阻塞）

爲此，咱們引入了基於 Reactive 編程模型，以全異步、可編排的能力，來應對上述挑戰：

• 經過全異步化使得資源利用率/性能進一步提高
• 經過全異步化，編排能力，使對外調用的請求併發可以突破原有併發線程的限制，作到極致併發
• 經過全異步化能力，使得應用在等待依賴響應的耦合資源從線程變成了回調對象，讓下游出問題時對應用自身的影響變得十分有限，從而提高了應用自己的穩定性。

基於 Reactive 全異步的解決方案打通了全棧，使得應用可以進行全異步化升級。淘寶的一核心推薦應用，在上線後 QPS 上漲了 90%+，另外一核心應用，上線後 RT 也降低了 40%。

關注穩定性

在全異步化解決方案落地的同時，咱們也在持續關注着穩定性。業務規模不斷的增長，對穩定性的挑戰也在變得愈來愈大。儘管咱們對穩定性很是重視，但有時仍是不免因一些錯誤的判斷而致使了穩定性問題。

好比，在某次大型活動中，咱們的收穫地址出現了一些短暫不可用問題；又好比，在另外一次大型聯歡活動中，咱們的登陸系統也出現了短暫的不可用問題。這兩個經典的案例，都是在咱們對應用的容量、活動的流量預估上出現了失誤而致使的問題。

雖然經過限流，咱們能夠大幅度提高應用在流量方面的穩定性，但經過上述兩個案例，以及業務的不斷實踐，咱們認爲，只使用靜態限流，系統仍是會由於一些不肯定性因素而帶來穩定性上的隱患和風險。

由不肯定性而引起的問題

限流是保護應用穩定性的有力武器，應用在正確預估自身容量和外部流量的狀況下，藉助限流能夠保護應用自身不被流量打垮，從而提升自身的穩定性，淘寶這麼多年的活動，限流都起到了功不可沒的穩定性做用。

隨着微服務數量的增加，咱們發現應用在使用靜態限流時，也帶來了一些穩定性的隱患 —— 靜態限流 與 不斷演進的應用之間存在着時間上的不匹配。換句話說，應用一旦設置了限流，只要應用不斷的發展，靜態限流就有可能面臨着過期的風險。形成過期隱患和風險的因素主要包括：

一、業務演進/依賴變化引發的不肯定性

業務一直在發展，咱們的應用代碼也一直在變化，頗有可能昨天剛剛設置過的限流 QPS，在今天應用一發布，就已經不適用了。就算應用自己不發佈，應用自身依賴的後端服務的拓撲不停的變化，也會引起應用可以承受的 QPS 發生變化，帶來不肯定性

二、流量模型發生變化引發的不肯定性

應用和服務一般包含多種方法調用，每種方法調用消耗的系統資源都不一樣，這要求在對應用壓測時的流量模型要足夠的合理準確，才能找到有效的限流值，然而業務的流量模型每每也是在不斷的變化，這也會爲應用的 QPS 評估帶來不肯定性。

三、不一樣容器實例容量引發的不肯定性

隨着運維環境和方法愈來愈複雜，交付給業務的容器，也變得不肯定，如咱們的混部、CPU Sharing 。同時，同一應用的不一樣容器，極可能會有不一樣的容量，如同一個應用的不一樣容器，壓出來的基線 QPS 都極可能有很大的差別。底層機器資源的不肯定性，也爲應用限流QPS 評估帶來了不肯定性

所以，針對應用的限流閾值設置，應用開發就會很糾結：

• 若是設置的限流閾值偏保守（偏低），那麼：有的機器資源使用率上不去，浪費機器，形成成本升高問題。
• 若是設置的限流閾值偏樂觀（偏高），那麼：有的機器尚未達到限流閾值，就會被壓垮，形成穩定性問題。

上述的不肯定性，也是咱們在大型活動前，進行封網的緣由之一。

應用柔性架構升級

面對着如此多的不肯定性，咱們但願咱們的應用自己可以具備一些『柔性』的特徵，使得在面對不肯定的場景忽然出現時，應用仍可以承受這些變化，就像太極同樣，可以作到以柔克剛。咱們認爲，應用架構要作到柔性，至少須要有如下特徵（針對應用柔性架構的特徵，咱們也在持續的探索中）：

一、故障容忍

• 如使用隔離進行解決。阿里的異地多活單元方案，能夠隔離地區出現的問題；微服務化提高了研發效率，同時也隔離了其餘獨立鏈路出現的問題；而咱們提出的全異步化解決方案，也增長了上游對下游出問題時的隔離做用。

二、過載保護

• 如使用自適應負載調節進行解決。來應對因爲流量容量預估不許而帶來的穩定性問題。

爲解決上述提到的不肯定性帶來的應用過載隱患問題，咱們引入了自適應負載調節來升級應用的過載保護能力，解決應用過載的穩定性隱患。

自適應負載調節

經過自適應負載調節來應對上述不肯定性，使得應用可以就地實時的評估自身負載，讓接受的 QPS 與處理能力同步，防止限流評估出錯而致使的穩定性問題和資源利用率問題；同時，在應用接收到超高壓時，單機壓垮的 QPS 可提到更高。從而可以應對更高的突發流量，加固應用自身的穩定性。

整個方案的主要由兩部分構成：

一、與應用整合的負反饋組件

• 在應用的入口設置一個負反饋組件，根據應用自身的負載狀況，對進入的請求進行鍼對性的攔截
• 爲了適用更多業務，此組件還支持服務權重，優先拒絕權重低的服務，使得在過載時，資源可以儘可能往權重高的服務傾斜。

二、組件自己的快速迭代機制

• 爲了讓方案自己可以在不一樣的場景下有效，咱們從不少不一樣的維度展開，組合成多個場景，再經過自動化的場景壓測，來快速進行算法在不一樣場景下的效果評估和改進，從而提高整個方案的迭代演進速度。

最終，整個方案沉澱了自適應負載調節的自動迭代平臺，迭代出基於 CPU 的自動控制算法。

上線案例

淘寶某核心業務的應用，在一次大型活動壓測中的效果獲得驗證：在某個機房的機器數比預期少 22.2% 的狀況下，抗住了 130% 的壓測流量。按照以往雙十一的壓測經驗，在少這麼多機器的狀況下，這個機房的應用扛不住如此大的流量。

另外一核心應用，因爲擔憂不肯定性緣由，靜態限流值設置的偏保守，在接入自適應負載調節後，限流值能夠進一步提高，使得服務的有效 QPS 提高了 230%，同時應用的壓垮 QPS 提高了 3 倍，在壓測大流量事後，秒級恢復，迅速提供正常服務（原需 6 分鐘+ ）。

應用柔性架構升級 - 後續展望

爲了讓應用更具高可用，咱們從故障的角度，圍繞着從故障發生前的預防能力，到故障誘因發生中的防護能力，再到故障發生時的恢復能力，來打造應用的高可用能力，進行應用的柔性架構升級。

同時，針對自適應負載調節，目前的策略爲就地拒絕，提升了穩定性，但仍有穩定性風險，後續咱們需更進一步豐富策略，如結合集團的中間件產品，進行快速擴容/縮容操做；應用向上遊反饋壓力，使得壓力從上游杜絕（分佈式回壓）等。同時，爲了在應用的依賴出現問題時，仍可以有柔性能力，咱們也會針對同步模型的應用，引入自適應的隔離/熔斷能力，使得應用下游出現問題時，不會影響到應用自己。

應用高可用關注的是應用自身，除了應用高可用，咱們也在積極推動淘系業務總體的高可用能力，好比在站點出現問題時，咱們如何作到以最快的速度切換流量，恢復業務，最終提高整個淘系的高可用。更多關於應用高可用、淘系業務高可用的理解和落地，咱們在持續地探索。

加入咱們

歡迎加入淘寶基礎平臺基礎服務團隊，團隊成員大牛雲集，有阿里移動中間件的創始人員、Dubbo核心成員、更有一羣熱愛技術，指望用技術推進業務的小夥伴。

淘寶基礎平臺基礎服務團隊，推動淘系（淘寶、天貓等）架構升級（代號Tango），致力於爲淘系、整個集團提供基礎核心能力、產品與解決方案：

• 業務高可用的解決方案與核心能力（應用高可用：爲業務提供自適應的限流、隔離與熔斷的柔性高可用解決方案，站點高可用：故障自愈、多機房與異地容災與快速切流恢復）
• 新一代的業務研發模式FaaS（一站式函數研發Gaia平臺）
• 下一代網絡協議QUIC實現與落地
• 移動中間件（API網關MTop、接入層AServer、消息/推送、配置中心等等）

期待一塊兒參與加入淘系基礎平臺的建設~

簡歷投遞至：哲良 ding.lid@alibaba-inc.com （基礎平臺基礎服務- 基礎架構Leader）

---

本文做者：許澤彬（澤彬）

閱讀原文

本文爲雲棲社區原創內容，未經容許不得轉載。