2018年初，淘寶開始嘗試對整體架構進行升級，經過近一年的探索，實現了全面異步化，這一架構升級在部分應用中取得了40%以上的性能提升，同時也爲後續的回壓推進打下了基礎。負責該項架構升級的是淘寶技術專家許澤彬，他在2018領域驅動設計中國峯會上做了《淘寶應用架構升級——反應式架構的探索與實踐》的分享，InfoQ也趁此機會對他進行了採訪，瞭解了更多細節。
2018領域驅動設計中國峯會(DDD2018)是ThoughtWorks發起的技術會議，旨在給國內的DDD實踐者們提供一個互相交流、分享自己團隊的成功經驗的機會的平臺。
許澤彬是淘寶技術專家，目前負責淘寶應用架構升級。曾參與淘寶用戶增長設施與平臺建設，負責過分佈式調用鏈跟蹤框架和系統“鷹眼”，曾經是阿里分佈式數據庫中美異地機房數據同步的核心開發，也是阿里旗下開源項目otter和canal的核心開發者。
淘寶此次架構升級，重點在於將同步的架構改爲異步、面向流的開發，以便爲後續的回壓方案打下基礎， 這裏所說的回壓方案要解決的問題是：應用在突發流量下的穩定性保證，以及最大化提升資源利用率。 許澤彬將其稱爲反應式架構。
經過近一年的推進，反應式架構已經在生產環境落地，在2018年雙11萬億級大規模處理量下，架構升級對多個核心應用進行了驗證落地，取得了超出預期的效果：
- 其中『猜你喜歡』應用上限 QPS 提升96%，即只需一半的機器就能支撐現有業務；
- 而另一核心應用『我的淘寶』實際線上響應時間下降了 40% 以上，意味着用戶可以更快得到響應。
在淘寶內部，這僅僅是回壓——突發流量下的穩定性以及最大化提升資源利用率方案 —— 剛剛邁出的第一步。
什麼是反應式架構
反應式架構裏的反應式，就是Reactive，國內對這個詞的翻譯並不統一，有的叫響應式，有的叫反應式。許澤彬認爲，這裏將其稱爲反應式更爲準確，響應式更多用於前端的界面中，對應的英文是Responsive。
反應式架構與一般架構相比，其反應體現在：
第一個，對用戶有反應，對用戶有反應我們才說響應，一般我們說的響應，基本上都說得針對跟用戶來交互。
第二個，要對失敗有反應，應用失敗了系統不能無動於衷，等着它掛掉，要有反應。
第三個，要對容量和壓力變化有所反應，比如說淘寶的秒殺，系統需要反應來保證對用戶的響應性，再如那個當流量降下來，將系統縮容，可以節約成本，這也是一種反應。
第四個，對輸入有反應，響應系統的輸入，也可以叫做消息驅動。
要做到反應式，需要做到三點：
- 適應性，也就是發生失敗能恢復回來，無論是系統、網絡、代碼出現了問題都能恢復。
- 彈性，這點主要是應對流量的變化，彈性的前提是做到可伸縮性Scalability，從軟件設計上，要做到去中心化；同時，在運行時，要感知節點當前的系統負載，將壓力往上游進行反饋，做到系統可以感知鏈路級別的節點壓力，使得系統可以針對整體壓力進行有目的地擴容縮容。這樣才能夠做到真正的彈性，根據系統負載進行擴容或縮容，這也是淘寶的回壓方案在後續所需要支撐的場景。
- 消息驅動，有了消息驅動才能比較好的做到上面兩個點。在反應式架構裏，以前這點叫做事件驅動，後來改爲消息驅動，消息驅動強調無阻塞、無callback，所以不會有線程掛在那裏，不會有持續的資源消耗。同時，事件驅動或消息驅動都是異步化，而異步化會將操作系統中的隊列情況顯式地提升到了應用層，使得應用層可以顯式根據隊列的情況來進行壓力負載的感知，這對於淘寶後續的回壓方案非常重要，而要做到這點，就需要異步了。
反應式架構中的核心概念是“流”，流就是面向數據的順序串行執行的一系列操作組合，它同傳統的編程相比，將業務邏輯導致數據改變，變成了操作改變數據，反過來影響業務邏輯的改變。面向流編程就是面向數據編程。
面向流的開發的優勢主要體現在：
- 提供大量強大的操作符，包括創建、過濾、轉換等。聲明式表達比過程式編程更加完備、高級、快捷。
- 在併發控制方面，不同的流之間無依賴，通過切換Scheduler就可以自動多流併發，而業務按照語義編寫，可以更友好的併發控制，更優的維護性和性能。
- 更高的資源利用率。通過更少的上下文切換、更低的競爭，可以降低負載，提升資源的有效利用率。
- 流可以加強分佈式架構的治理能力。流引用可被遠程化，從而實現系統級的流式貫通，而流提供的更好的回壓、三角模式透傳，以及天然的截面編程能力等，可以給架構治理提供更好的幫助。目前淘寶正在推進回壓的方案，就是爲了給系統在穩定性和資源利用率上提供更高級的治理手段。
淘寶反應式架構實踐
淘寶之所以要做架構升級，是因爲現有架構存在一系列問題：
- 同步等待造成資源浪費，現有的同步模型線程多負載高，導致資源利用率較低。
- 架構的並行度有限，無法實現純業務依賴併發，微服務化讓問題更加凸顯，服務增加造成響應時間累積。
- 而響應時間累積又帶來一些連鎖反應，包括爲了降低響應時間而過早的引入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並即將開源。
最後，改造後的架構如圖：
實施反應式架構的難點
反應式架構在各個模塊上基本都有成熟的方案，除了個別領域如數據庫，基本沒有特別的瓶頸。實施反應式架構的難點主要在於工程師的思維轉換，因爲之前工程師主要使用同步式的思維寫程序，突然要換成以流的方式編寫，思維必須要做轉換。
因此，要做到全面異步化，組織必須從上到下全力支持。淘寶的做法是，成立虛擬小組，在每個業務線裏挑選能力比較強的同學統一進行異步式的培訓和指導，之後由他們在團隊內部推廣。
同時，要讓業務方有動力去做異步化的改造，需要讓他們認識到這麼做的好處，因此異步化改造首先要做出一些標杆性的成績出來。這中間的策略包括選擇面臨瓶頸的地方，業務邏輯簡單的， 以及業務壓力不大的應用來進行試點，一旦做出成績，就可以給其它團隊以信心和動力。
淘寶應用架構升級後續規劃
目前，淘寶的異步化改造在技術上已經大部分完成，後續的規劃主要包括：
- 回壓的實現
- 分佈式上下游的聯動回壓，解決高併發壓力下的響應時間、有效請求數、系統自恢復、鏈路短板自發現等問題，解決系統在突發流量下的穩定性問題，以及提高資源利用率。
- 自適應回壓解決靜態配置無法應對系統波動變化問題
- 實現全異步/流式爲核心的服務框架，讓業務方做到異步優先；
- 考慮引入Kotlin協程，它的異步設計符合過程式的編程習慣。
淘寶的回壓方案，目前正在推進和實施的過程當中，後續他們也將會有更多的經驗分享出來，歡迎關注。