2018 年初，淘寶開始嘗試進行整個架構更新（代号Tango：Taobao Architecture Next GeneratiOn），經過近一年的探索，實作了全面異步化，這一架構更新在部分應用中取得了 40% 以上的性能提升，同時也為後續的回壓推進打下了基礎。負責該項架構更新的是淘寶技術專家許澤彬，在 2018 領域驅動設計中國峰會上做了《淘寶應用架構更新——反應式架構的探索與實踐》的分享，InfoQ 也趁此機會對他進行了采訪，了解了更多細節。
2018 領域驅動設計中國峰會 (DDD2018) 是 ThoughtWorks 發起的技術會議，旨在給國内的 DDD 實踐者們提供一個互相交流、分享自己團隊的成功經驗的機會的平台。
許澤彬是淘寶技術專家，目前負責淘寶應用架構更新。曾參與淘寶使用者增長設施與平台建設，負責過分布式調用鍊跟蹤架構和系統“鷹眼”，曾經是阿裡分布式資料庫中美異地機房資料同步的核心開發，也是阿裡旗下開源項目 otter 和 canal 的核心開發者。
淘寶此次架構更新，重點在于将同步的架構改為異步，面向流的開發，以便為後續的回壓方案打下基礎， 這裡所說的回壓方案要解決的問題是：應用在突發流量下的穩定性保證，以及最大化提升資源使用率。許澤彬将其稱為反應式架構。
經過近一年的推進，反應式架構已經在生産環境落地，在 2018 年雙 11 萬億級大規模處理量下，架構更新對多個核心應用進行了驗證落地，取得了超出預期的效果：其中『猜你喜歡』應用上限 QPS 提升 96%，即隻需一半的機器就能支撐現有業務；而另一核心應用『我的淘寶』實際線上 響應時間下降了 40% 以上，意味着使用者可以更快得到響應。在淘寶内部，這僅僅是回壓——突發流量下的穩定性以及最大化提升資源使用率方案 —— 剛剛邁出的第一步。
1 什麼是反應式架構
反應式架構裡的反應式，就是 Reactive，國内對這個詞的翻譯并不統一，有的叫響應式，有的叫反應式。許澤彬認為，這裡将其稱為反應式更為準确，響應式更多用于前端的界面中，對應的英文是 Responsive。
反應式架構與一般架構相比，其反應展現在：
- 第一個，對使用者有反應，對使用者有反應我們才說響應，一般我們說的響應，基本上都說得針對跟使用者來互動。
- 第二個，要對失敗有反應，應用失敗了系統不能無動于衷，等着它挂掉，要有反應。
- 第三個，要對容量和壓力變化有所反應，比如說淘寶的秒殺，系統需要反應來保證對使用者的響應性，再如那個當流量降下來，将系統縮容，可以節約成本，這也是一種反應。
- 第四個，對輸入有反應，響應系統的輸入，也可以叫做消息驅動。
要做到反應式，需要做到三點：
- 适應性，也就是發生失敗能恢複回來，無論是系統、網絡、代碼出現了問題都能恢複。
- 彈性，這點主要是應對流量的變化，彈性的前提是做到可伸縮性 Scalability，從軟體設計上，要做到去中心化；同時，在運作時，要感覺節點目前的系統負載，将壓力往上遊進行回報，做到系統可以感覺鍊路級别的節點壓力，使得系統可以針對整體壓力進行有目的地擴容縮容。這樣才能夠做到真正的彈性，根據系統負載進行擴容或縮容，這也是淘寶的回壓方案在後續所需要支撐的場景。
- 消息驅動，有了消息驅動才能比較好的做到上面兩個點。在反應式架構裡，以前這點叫做事件驅動，後來改為消息驅動，消息驅動強調無阻塞、無 callback，是以不會有線程挂在那裡，不會有持續的資源消耗。同時，事件驅動或消息驅動都是異步化，而異步化會将作業系統中的隊列情況顯式地提升到了應用層，使得應用層可以顯式根據隊列的情況來進行壓力負載的感覺，這對于淘寶後續的回壓方案非常重要，而要做到這點，就需要異步了。
反應式架構中的核心概念是“流”，流就是面向資料的順序串行執行的一系列操作組合，它同傳統的程式設計相比，将業務邏輯導緻資料改變，變成了操作改變資料，反過來影響業務邏輯的改變。面向流程式設計就是面向資料程式設計。
面向流的開發的優勢主要展現在：
- 提供大量強大的操作符，包括建立、過濾、轉換等。聲明式表達比過程式程式設計更加完備、進階、快捷。
- 在并發控制方面，不同的流之間無依賴，通過切換 Scheduler 就可以自動多流并發，而業務按照語義編寫，可以更友好的并發控制，更優的維護性和性能。
- 更高的資源使用率。通過更少的上下文切換、更低的競争，可以降低負載，提升資源的有效使用率。
- 流可以加強分布式架構的治理能力。流引用可被遠端化，進而實作系統級的流式貫通，而流提供的更好的回壓、三角模式透傳，以及天然的截面程式設計能力等，可以給架構治理提供更好的幫助。目前淘寶正在推進回壓的方案，就是為了給系統在穩定性和資源使用率上提供更進階的治理手段。
2 淘寶反應式架構實踐
淘寶之是以要做架構更新，是因為現有架構存在一系列問題：
- 同步等待造成資源浪費，現有的同步模型線程多負載高，導緻資源使用率較低。
- 架構的并行度有限，無法實作純業務依賴并發，微服務化讓問題更加凸顯，服務增加造成響應時間累積。
- 而響應時間累積又帶來一些連鎖反應，包括為了降低響應時間而過早的引入 cache，每個服務都需要設定逾時來解決長時間無響應問題，而這些帶來維護成本的提升，也提高了業務實作的複雜度。
- 同時，在應用系統無事先準備的情況下，面對突發大流量時，很容易被打挂，造成穩定性問題，導緻使用者體驗嚴重下降。
而經過調研後，淘寶架構團隊認為使用反應式架構是目前可行的一個方案。原因包括，Java 8 已經逐漸普及，因為它包含對 Lambda 的支援，這讓開發者對 Lambda 的接受度大大提高；同時 Reactive 相關的業務架構在業界已有成熟的實作，RxJava 已經廣泛在大小公司中應用；最後，包括 Java 9（引入 Reactive Sreams 規範 API）、Spring 5（引入 Reactor/WebFlux）、Spring Boot 2 都開始擁抱 Reactive，說明反應式程式設計的确是趨勢。
整個方案對業務架構的更新主要包括程式設計架構、中間件，以及業務方的更新。中間件的更新，包括服務架構（RPC）、網關、緩存、消息（MQ）、DB（JDBC）、限流元件、分布式跟蹤系統、移動端 Rx 架構。
這其中值得注意的包括，對服務架構的更新，流式實作将在 Dubbo 3 中放出；DB 中的異步內建使用 Ali JVM 協程或用線程池實作；移動端為了支撐已有的 iOS 應用，淘寶開發了 AliRxObjc 并即将開源。
最後，改造後的架構如圖：
3 實施反應式架構的難點
反應式架構在各個子產品上基本都有成熟的方案，除了個别領域如資料庫，基本沒有特别的瓶頸。實施反應式架構的難點主要在于工程師的思維轉換，因為之前工程師主要使用同步式的思維寫程式，突然要換成以流的方式編寫，思維必須要做轉換。
是以，要做到全面異步化，組織必須從上到下全力支援。淘寶的做法是，成立虛拟小組，在每個業務線裡挑選能力比較強的同學統一進行異步式的教育訓練和指導，之後由他們在團隊内部推廣。
同時，要讓業務方有動力去做異步化的改造，需要讓他們認識到這麼做的好處，是以異步化改造首先要做出一些标杆性的成績出來。這中間的政策包括選擇面臨瓶頸的地方，業務邏輯簡單的， 以及業務壓力不大的應用來進行試點，一旦做出成績，就可以給其它團隊以信心和動力。
4 淘寶反應式架構更新後續規劃
目前，淘寶的異步化改造在技術上已經大部分完成，後續的規劃主要包括：
- 回壓的實作
- 分布式上下遊的關聯回壓，解決高并發壓力下的響應時間、有效請求數、系統自恢複、鍊路短闆自發現等問題，解決系統在突發流量下的穩定性問題，以及提高資源使用率。
- 自适應回壓解決靜态配置無法應對系統波動變化問題
- 實作全異步 / 流式為核心的服務架構，讓業務方做到異步優先；
- 考慮引入 Kotlin 協程，它的異步設計符合過程式的程式設計習慣。
淘寶的回壓方案，目前正在推進和實施的過程當中，後續也将會有更多Tango的經驗分享出來，歡迎關注。