簡介： 隨着阿里淘寶業務和機器規模的不斷增長，系統穩定性和機器資源利用率方面受到的挑戰越來越大，如何解決以上問題？ArchSummit（全球架構師峯會）上淘寶高級技術專家——澤彬爲您分享~
作者|許澤彬（澤彬）
出品|阿里巴巴新零售淘系技術部
導讀：隨着淘寶業務的飛速發展，微服務架構在持續演進的過程中，也受到了越來越多的挑戰：如同步模型帶來的資源利用率有限、依賴調用併發度有限、下游故障引發應用自身出問題；又如靜態限流隨着業務代碼的演進、依賴拓撲的變化、部署環境的調整，而造成過時引起的穩定性隱患等挑戰。
ArchSummit（全球架構師峯會）上淘寶高級技術專家——澤彬分享了爲應對這些挑戰，淘寶基礎服務在淘系架構升級上（代號 Tango ：Taobao Architecture Next GeneratiOn ）對這些問題的認識以及讓應用面對突發問題時更具柔性（應用柔性架構）的一些探索。
Reactive 全異步化
當前我們的微服務主要是基於同步的調用模型，帶來了如下挑戰：
- 同步等待造成應用資源利用率很難進一步提升
- 併發度有限，技術實現無法做到業務理想程度的併發，導致 RT 增加
- 下游出現問題會導致應用本身出現問題（如應用等待下游響應的線程會被長時間阻塞）
爲此，我們引入了基於 Reactive 編程模型，以全異步、可編排的能力，來應對上述挑戰：
- 通過全異步化使得資源利用率/性能進一步提升
- 通過全異步化，編排能力，使對外調用的請求併發能夠突破原有併發線程的限制，做到極致併發
- 通過全異步化能力，使得應用在等待依賴響應的耦合資源從線程變成了回調對象，讓下游出問題時對應用自身的影響變得十分有限，從而提升了應用本身的穩定性。
基於 Reactive 全異步的解決方案打通了全棧，使得應用能夠進行全異步化升級。淘寶的一核心推薦應用，在上線後 QPS 上漲了 90%+，另一核心應用，上線後 RT 也下降了 40%。
關注穩定性
在全異步化解決方案落地的同時，我們也在持續關注着穩定性。業務規模不斷的增加，對穩定性的挑戰也在變得越來越大。儘管我們對穩定性非常重視，但有時還是難免因一些錯誤的判斷而導致了穩定性問題。
比如，在某次大型活動中，我們的收穫地址出現了一些短暫不可用問題；又比如，在另一次大型聯歡活動中，我們的登錄系統也出現了短暫的不可用問題。這兩個經典的案例，都是在我們對應用的容量、活動的流量預估上出現了失誤而導致的問題。
雖然通過限流，我們可以大幅度提升應用在流量方面的穩定性，但通過上述兩個案例，以及業務的不斷實踐，我們認爲，只使用靜態限流，系統還是會因爲一些不確定性因素而帶來穩定性上的隱患和風險。
由不確定性而引發的問題
限流是保護應用穩定性的有力武器，應用在正確預估自身容量和外部流量的情況下，藉助限流可以保護應用自身不被流量打垮，從而提高自身的穩定性，淘寶這麼多年的活動，限流都起到了功不可沒的穩定性作用。
隨着微服務數量的增長，我們發現應用在使用靜態限流時，也帶來了一些穩定性的隱患 —— 靜態限流 與 不斷演進的應用之間存在着時間上的不匹配。換句話說，應用一旦設置了限流，只要應用不斷的發展，靜態限流就有可能面臨着過時的風險。造成過時隱患和風險的因素主要包括：
1、業務演進/依賴變化引起的不確定性
業務一直在發展，我們的應用代碼也一直在變化，很有可能昨天剛剛設置過的限流 QPS，在今天應用一發布，就已經不適用了。就算應用本身不發佈，應用自身依賴的後端服務的拓撲不停的變化，也會引發應用能夠承受的 QPS 發生變化，帶來不確定性
2、流量模型發生變化引起的不確定性
應用和服務通常包含多種方法調用，每種方法調用消耗的系統資源都不同，這要求在對應用壓測時的流量模型要足夠的合理準確，才能找到有效的限流值，然而業務的流量模型往往也是在不斷的變化，這也會爲應用的 QPS 評估帶來不確定性。
3、不同容器實例容量引起的不確定性
隨着運維環境和方法越來越複雜，交付給業務的容器，也變得不確定，如我們的混部、CPU Sharing 。同時，同一應用的不同容器，很可能會有不同的容量，如同一個應用的不同容器，壓出來的基線 QPS 都很可能有很大的差異。底層機器資源的不確定性，也爲應用限流QPS 評估帶來了不確定性
因此，針對應用的限流閾值設置，應用開發就會很糾結：
- 如果設置的限流閾值偏保守（偏低），那麼：有的機器資源使用率上不去，浪費機器，造成成本升高問題。
- 如果設置的限流閾值偏樂觀（偏高），那麼：有的機器還沒有達到限流閾值，就會被壓垮，造成穩定性問題。
上述的不確定性，也是我們在大型活動前，進行封網的原因之一。
應用柔性架構升級
面對着如此多的不確定性，我們希望我們的應用本身能夠具有一些『柔性』的特徵，使得在面對不確定的場景突然出現時，應用仍能夠承受這些變化，就像太極一樣，能夠做到以柔克剛。我們認爲，應用架構要做到柔性，至少需要有以下特徵（針對應用柔性架構的特徵，我們也在持續的探索中）：
1、故障容忍
- 如使用隔離進行解決。阿里的異地多活單元方案，可以隔離地區出現的問題；微服務化提升了研發效率，同時也隔離了其他獨立鏈路出現的問題；而我們提出的全異步化解決方案，也增加了上游對下游出問題時的隔離作用。
2、過載保護
- 如使用自適應負載調節進行解決。來應對由於流量容量預估不準而帶來的穩定性問題。
爲解決上述提到的不確定性帶來的應用過載隱患問題，我們引入了自適應負載調節來升級應用的過載保護能力，解決應用過載的穩定性隱患。
自適應負載調節
通過自適應負載調節來應對上述不確定性，使得應用能夠就地實時的評估自身負載，讓接受的 QPS 與處理能力同步，防止限流評估出錯而導致的穩定性問題和資源利用率問題；同時，在應用接收到超高壓時，單機壓垮的 QPS 可提到更高。從而能夠應對更高的突發流量，加固應用自身的穩定性。
整個方案的主要由兩部分構成：
1、與應用整合的負反饋組件
- 在應用的入口設置一個負反饋組件，根據應用自身的負載情況，對進入的請求進行針對性的攔截
- 爲了適用更多業務，此組件還支持服務權重，優先拒絕權重低的服務，使得在過載時，資源能夠儘量往權重高的服務傾斜。
2、組件本身的快速迭代機制
- 爲了讓方案本身能夠在不同的場景下有效，我們從很多不同的維度展開，組合成多個場景，再通過自動化的場景壓測，來快速進行算法在不同場景下的效果評估和改進，從而提升整個方案的迭代演進速度。
最終，整個方案沉澱了自適應負載調節的自動迭代平臺，迭代出基於 CPU 的自動控制算法。
上線案例
淘寶某核心業務的應用，在一次大型活動壓測中的效果得到驗證：在某個機房的機器數比預期少 22.2% 的情況下，抗住了 130% 的壓測流量。按照以往雙十一的壓測經驗，在少這麼多機器的情況下，這個機房的應用扛不住如此大的流量。
另一核心應用，由於擔心不確定性原因，靜態限流值設置的偏保守，在接入自適應負載調節後，限流值可以進一步提升，使得服務的有效 QPS 提升了 230%，同時應用的壓垮 QPS 提升了 3 倍，在壓測大流量過後，秒級恢復，迅速提供正常服務（原需 6 分鐘+ ）。
應用柔性架構升級 - 後續展望
爲了讓應用更具高可用，我們從故障的角度，圍繞着從故障發生前的預防能力，到故障誘因發生中的防禦能力，再到故障發生時的恢復能力，來打造應用的高可用能力，進行應用的柔性架構升級。
同時，針對自適應負載調節，目前的策略爲就地拒絕，提高了穩定性，但仍有穩定性風險，後續我們需更進一步豐富策略，如結合集團的中間件產品，進行快速擴容/縮容操作；應用向上遊反饋壓力，使得壓力從上游杜絕（分佈式回壓）等。同時，爲了在應用的依賴出現問題時，仍能夠有柔性能力，我們也會針對同步模型的應用，引入自適應的隔離/熔斷能力，使得應用下游出現問題時，不會影響到應用本身。
應用高可用關注的是應用自身，除了應用高可用，我們也在積極推進淘系業務整體的高可用能力，比如在站點出現問題時，我們如何做到以最快的速度切換流量，恢復業務，最終提升整個淘系的高可用。更多關於應用高可用、淘系業務高可用的理解和落地，我們在持續地探索。
加入我們
歡迎加入淘寶基礎平臺基礎服務團隊，團隊成員大牛雲集，有阿里移動中間件的創始人員、Dubbo核心成員、更有一羣熱愛技術，期望用技術推動業務的小夥伴。
淘寶基礎平臺基礎服務團隊，推進淘系（淘寶、天貓等）架構升級（代號Tango），致力於爲淘系、整個集團提供基礎核心能力、產品與解決方案：
- 業務高可用的解決方案與核心能力（應用高可用：爲業務提供自適應的限流、隔離與熔斷的柔性高可用解決方案，站點高可用：故障自愈、多機房與異地容災與快速切流恢復）
- 新一代的業務研發模式FaaS（一站式函數研發Gaia平臺）
- 下一代網絡協議QUIC實現與落地
- 移動中間件（API網關MTop、接入層AServer、消息/推送、配置中心等等）
期待一起參與加入淘系基礎平臺的建設~
簡歷投遞至：哲良 [email protected] （基礎平臺基礎服務- 基礎架構Leader）
更多技術乾貨，關注微信公衆號「淘寶技術」
想看原文章內容：點擊這裏
原文出處：阿里雲大學開發者社區
