本文根據白輝在2016ArchSummit全球架構師（深圳）峰會上的演講整理而成。ArchSummit北京站即將在12月2日開幕，更多專題講師信息請到北京站官網查詢。
非常榮幸在這里跟大家一起來探討“海量服務架構探索”相關專題的內容。
我叫白輝，花名是七公。2014年之前主要在阿里B2B負責資金中心、評價、任務中心等系統。2015年加入蘑菇街，隨著蘑菇街的飛速成長，經歷了網站技術架構的大
變革。今天分享的內容來自于去年我們做的事情，題目用了一個關鍵詞是“籬笆”，籬笆的英文是Barrier，是指2015年蘑菇街面臨的問題和艱巨的困難。我們越過了這些籬笆，取得了很好的成果。
引言
今天分享的內容主要分為五部分。第一部分，概述電商系統發展中期面臨的一般性問題。第二部分，如何解決面臨的問題，主要的策略是做拆分、做服務化。第三、四部分，服務化之后業務的大增長、網站流量飛速的增加、“雙11”大促等的挑戰很大，我們做了服務的專項系統優化以及穩定性治理。第五部分，進行了總結和展望。
電商系統發展中期面臨的一般性問題
我們先看第一部分的內容。
我總結了一下，一般電商系統發展到中期都會面臨三個方面的問題（如圖）。第一方面是業務問題。比如，一開始做業務的時候可能很隨意，一是并不考慮業務模型、系統架構，二是業務之間的耦合比較嚴重，比如交易和資金業務，有可能資金和外部第三方支付公司的交互狀態耦合在交易系統里，這些非常不利于業務發展。第二方面是系統問題。2014年我們面臨單體應用，400人開發一個大應用，擴展性很差，業務比較難做。第三方面是支撐問題，比如關于環境、開發框架和質量工具等。這些是電商系統發展到中期都會面臨的問題，中期的概念是用戶過了千萬，PV過了1億。
我們來看一下蘑菇街2015年初面臨的問題。蘑菇街2015年用戶過億，PV過10億，業務在超高速發展，每年保持3倍以上的增長。電商促銷、交易、支付等業務形態都在快速膨脹，我們需要快速支持業務發展，而不是成為業務的瓶頸。那么就是要去做系統的拆分和服務化。
系統拆分與服務化過程
第二部分的內容，是關于蘑菇街系統拆分與服務化的歷程。
按照如下幾條思路（見圖），我們進行系統拆分以及服務化。最開始，大家在同一個應用里開發一些業務功能，都是選擇速度最快的方式，所有的DB和業務代碼都是在一起的。首先我們將DB做垂直拆分。第二步是做業務系統垂直拆分，包括交易、資金等。第三步是在系統拆完了之后要考慮提供什么樣的API來滿足業務的需求？這里我們要做數據建模+業務建模，數據建模方面包括數據表的設計和擴展支持，數據模型應該非常穩定；業務建模方面，使用標準和靈活的API，而且盡量不用修改代碼或者改少量代碼就能支持業務需求。第四步是需要將業務邏輯下沉到服務，Web層專注于展示邏輯和編排，不要涉及過多業務的事情。然后用SOA中間件建設服務化系統。最后會做一些服務的治理。
來看一個API服務化的例子，在做服務化之前和做服務化之后，交易創建下單業務有什么不一樣。服務化之前我們面臨的問題有：入口分散，如果要在底層做任何一個微小的改動，十幾個入口需要幾十個人配合修改，這是非常不合理的一種方式；多端維護多套接口，成本非常高；還有穩定性的問題，依賴非常復雜，維護很難。我剛到蘑菇街的時候，一次大促活動就導致數據庫崩潰，暴露了系統架構很大的問題和總量上的瓶頸。按照上面提到幾條思路去做服務化，看看有了哪些改善？首先是API統一，多個端、多個業務都用統一的API提供；其次是依賴有效管理起來，大事務拆分成多個本地小事務；最后降低了鏈路風險，邏輯更加清晰，穩定性更好。
2015年3月我來到蘑菇街之后，先制訂了服務化的規范，探討了到底什么是標準的服務化。在做服務化的過程中，發現大家代碼風格完全不一樣，所以制定編碼規范非常重要。2015年8月，我們完成了各個模塊的改造，包括用戶、商品、交易、訂單、促銷、退款等，然后有了服務化架構1.0的體系。在此基礎之上，我們進一步做了提升流量和穩定性等更深度的建設。2015年9月，我們實施了分庫分表和鏈路性能提升優化，2015年10月做了服務治理和服務保障。
接下來，以服務架構和服務體系建設為主線，講一下去年整個網站架構升級的過程。
在服務化1.0體系完成之后，我們得到了一個簡單的體系，包含下單服務、營銷服務、店鋪服務、商品服務和用戶服務，還有簡單的RPC框架Tesla。當時，我們并沒有做很多性能優化的事情，但是通過業務流程化簡和邏輯優化，每秒最大訂單數從400提升到1K，基礎服務也都搭建了起來。
有了1.0初步的服務化體系之后，更進一步，我們一是要繼續深入網站如資金等的服務化，二是要做服務內部的建設，比如容量、性能，這也是接下來要講的內容。
購買鏈路的性能提升
這個鏈路（見圖）是比較典型的電商鏈路，有商品頁、下單、支付、營銷和庫存等內容。一開始每個點都有瓶頸，每個瓶頸都是一個籬笆，我們要正視它，然后翻越它。
我們先來看第一個籬笆墻：下單的瓶頸。
2015年“3.21”大促的時候，DB崩潰了，這個瓶頸很難突破。下一個訂單要插入很多條數據記錄到單DB的DB表。我們已經用了最好的硬件，但是瓶頸依然存在，最主要的問題就是DB單點，需要去掉單點，做成可水平擴展的。流量上來了，到DB的行寫入數是2萬/秒，對DB的壓力很大。寫應該控制在一個合理的量，DB負載維持在較低水平，主從延時也才會在可控范圍內。所以DB單點的問題非常凸顯，這座大山必須邁過去，我們做了一個分庫分表組件TSharding來實施分庫分表。
將我們寫的分庫分表工具與業界方案對比，業界有淘寶TDDL Smart Client的方式，還有Google的Vitess等的Proxy方式，這兩種成熟方案研發和運維的成本都太高，短期內我們接受不了，所以借鑒了Mybatis Plugin的方式，但Mybatis Plugin不支持數據源管理，也不支持事務。我大概花了一周時間寫了一個組件——自研分庫分表組件TSharding（https://github.com/baihui212/tsharding），然后快速做出方案，把這個組件應用到交易的數據庫，在服務層和DAO層，訂單容量擴展到千億量級，并且可以繼續水平擴展。TSharding上線一年之后，我們將其開放出來。
第二個籬笆墻就是營銷服務RT的問題。促銷方式非常多，包括各種紅包、滿減、打折、優惠券等。實際上促銷的接口邏輯非常復雜，在“雙11”備戰的時候，面對這個復雜的接口，每輪鏈路壓測促銷服務都會發現問題，之后優化再壓測，又發現新的問題。我們來一起看看遇到的各種問題以及是如何解決的。首先是壓測出現接口嚴重不可用，這里可以看到DB查詢頻次高，響應很慢，流量一上來，這個接口就崩潰了。那怎么去排查原因和解決呢？
首先是SQL優化，用工具識別慢SQL，即全鏈路跟蹤系統Lurker。
這張圖我簡單介紹一下。遇到SQL執行效率問題的時候，就看是不是執行到最高效的索引，掃表行數是不是很大，是不是有filesort。有ORDER BY的時候，如果要排序的數據量不大或者已經有索引可以走到，在數據庫的內存排序緩存區一次就可以排序完。如果一次不能排序完，那就先拿到1000個做排序，然后輸出到文件，然后再對下1000個做排序，最后再歸并起來，這就是filesort的大致過程，效率比較低。所以盡量要走上索引，一般類的查詢降低到2毫秒左右可以返回。
其次是要讀取很多優惠規則和很多優惠券，數據量大的時候DB是很難扛的，這時候我們要做緩存和一些預處理。特別是查詢DB的效率不是很高的時候，盡量緩存可以緩存的數據、盡量緩存多一些數據。但如果做緩存，DB和緩存數據的一致性是一個問題。在做數據查詢時，首先要看本地緩存有沒有開啟，如果本地緩存沒有打開，就去查分布式緩存，如果分布式緩存中沒有就去查DB，然后從DB獲取數據過來。需要盡量保持DB、緩存數據的一致性，如果DB有變化，可以異步地做緩存數據失效處理，數據百毫秒內就失效掉，減少不一致的問題。
另外，如果讀到本地緩存，這個內存訪問比走網絡請求性能直接提升了一個量級，但是帶來的弊端也很大，因為本地緩存沒有辦法及時更新，平時也不能打開，因為會帶來不一致問題。但大促高峰期間我們會關閉關鍵業務數據變更入口，開啟本地緩存，把本地緩存設置成一分鐘失效，一分鐘之內是可以緩存的，也能容忍短暫的數據不一致，所以這也是一個很好的做法。同樣的思路，我們也會把可能會用到的數據提前放到緩存里面，做預處理。在客戶端進行數據預處理，要么直接取本地數據，或者在本地直接做計算，這樣更高效，避免了遠程的RPC。大促期間我們就把活動價格信息預先放到商品表中，這樣部分場景可以做本地計價，有效解決了計價接口性能的問題。
再就是讀容量問題，雖然緩存可以緩解壓力，但是DB還是會有幾十K的讀壓力，單點去扛也是不現實的，所以要把讀寫分離，如果從庫過多也有延時的風險，我們會把數據庫的并行復制打開。
我們來看一下數據。這是去年“雙11”的情況（如圖）。促銷服務的RT得到了有效控制，所以去年“雙11”平穩度過。
接下來講一個更基礎、更全局的優化，就是異步化。比如說下單的流程，有很多業務是非實時性要求的，比如下單送優惠券，如果在下單的時候同步做，時間非常長，風險也更大，其實業務上是非實時性或者準實時性的要求，可以做異步化處理，這樣可以減少下單對機器數量的要求。另外是流量高峰期的一些熱點數據。大家可以想象一下，下單的時候，一萬個人競爭同一條庫存數據，一萬個節點鎖在這個請求上，這是多么恐怖的事情。所以我們會有異步隊列去削峰，先直接修改緩存中的庫存數目，改完之后能讀到最新的結果，但是不會直接競爭DB，這是異步隊列削峰很重要的作用。還有，數據庫的競爭非常厲害，我們需要把大事務做拆分，盡量讓本地事務足夠小，同時也要讓多個本地事務之間達到一致。
異步是最終達到一致的關鍵，異步的處理是非常復雜的。可以看一下這個場景（見圖），這是一個1-6步的處理過程，如果拆分成步驟1、2、3、4、end，然后到5，可以異步地做；6也一樣，并且5和6可以并行執行。同時，這個步驟走下來鏈路更短，保障也更容易；步驟5和6也可以單獨保障。所以異步化在蘑菇街被廣泛使用。
異步化之后面臨的困難也是很大的，會有分布式和一致性的問題。交易創建過程中，訂單、券和庫存要把狀態做到絕對一致。但下單的時候如果先鎖券，鎖券成功了再去減庫存，如果減庫存失敗了就是很麻煩的事情，因為優化券服務在另外一個系統里，如果要同步調用做券的回滾，有可能這個回滾也會失敗，這個時候處理就會非常復雜。我們的做法是，調用服務超時或者失敗的時候，我們就認為失敗了，就會異步發消息通知回滾。優惠券服務和庫存服務被通知要做回滾時，會根據自身的狀態來判斷是否要回滾，如果鎖券成功了券就回滾，減庫存也成功了庫存做回滾；如果庫存沒有減就不用回滾。所以我們是通過異步發消息的方式保持多個系統之間的一致性；如果不做異步就非常復雜，有的場景是前面所有的服務都調用成功，第N個服務調用失敗。另外的一致性保障策略包括Corgi MQ生產端發送失敗會自動重試保證發成功，消費端接收ACK機制保證最終的一致。另外，與分布式事務框架比起來，異步化方案消除了二階段提交等分布式事務框架的侵入性影響，降低了開發的成本和門檻。
另一個場景是，服務調用上會有一些異步的處理。以購物車業務為例，購物車列表要調用10個Web服務，每一個服務返回的時間都不一樣，比如第1個服務20毫秒返回，第10個服務40毫秒返回，串行執行的效率很低。而電商類的大多數業務都是IO密集型的，而且數據量大時還要分批查詢。所以我們要做服務的異步調用。比如下圖中這個場景，步驟3處理完了之后callback馬上會處理，步驟4處理完了callback也會馬上處理，步驟3和4并不相互依賴，且處理可以同時進行了，提高了業務邏輯執行的并行度。目前我們是通過JDK7的Future和Callback實現的，在逐步往JDK8的Completable Future遷移。這是異步化在網站整體的應用場景，異步化已經深入到我們網站的各個環節。
剛才我們講了鏈路容量的提升、促銷RT的優化，又做了異步化的一些處理。那么優化之后怎么驗證來優化的效果呢？到底有沒有達到預期？我們有幾個壓測手段，如線下單機壓測識別應用單機性能瓶頸，單鏈路壓測驗證集群水位及各層核?系統容量配比，還有全鏈路壓測等。
這是去年“雙11”之前做的壓測（見圖），達到了5K容量的要求。今年對每個點進一步深入優化，2016年最大訂單提升到了10K，比之前提升了25倍。實際上這些優化可以不斷深入，不僅可以不斷提高單機的性能和單機的QPS，還可以通過對服務整體上的優化達到性能的極致，并且可以引入一些廉價的機器（如云主機）來支撐更大的量。
我們為什么要做這些優化？業務的發展會對業務系統、服務框架提出很多很高的要求。因此，我們對Tesla做了這些改善（見圖），服務的配置推送要更快、更可靠地到達客戶端，所以有了新的配置中心Metabase，也有了Lurker全鏈路監控，服務和服務框架的不斷發展推動了網站其他基礎中間件產品的誕生和發展。2015年的下半年我們進行了一系列中間件的自研和全站落地。
我們得到了服務架構1.5的體系（見圖），首先是用戶服務在最底層，用戶服務1200K的QPS，庫存250K，商品服務400K，營銷200K，等等。
接下來我們看一下這一階段，Tesla開始做服務管控，真正成為了一個服務框架。我們最開始做發布的時候，客戶端、服務端由于做的只是初級的RPC調用，如果服務端有變更，客戶端可能是幾秒甚至數十秒才能拉到新配置，導致經常有客戶投訴。有了對服務變更推送更高的要求后，我們就有了Matabase配置中心，服務端如果有發布或者某一刻崩潰了，客戶端馬上可以感知到，這樣就完成了整個服務框架連接優化的改進，真正變成服務管控、服務治理框架的開端。
購買鏈路的穩定性提升
有了上面講到的服務化改進和性能提升之后，是不是大促的時候看一看監控就行了？其實不是。大流量來的時候，萬一導致整個網站崩潰了，一分鐘、兩分鐘的損失是非常大的，所以還要保證服務是穩的和高可用的。只有系統和服務是穩定的，才能更好地完成業務指標和整體的經營目標。
下面會講一下服務SLA保證的內容。
首先SLA體現在對容量、性能、程度的約束，包括程度是多少的比例。那么要保證這個SLA約束和目標達成，首先要把關鍵指標監控起來；第二是依賴治理、邏輯優化；第三是負載均衡、服務分組和限流；第四是降級預案、容災、壓測、在線演練等。這是我們服務的關鍵指標的監控圖（見上圖）。支付回調服務要滿足8K QPS，99%的RT在30ms內，但是圖中監控說明SLA未達到，RT程度指標方面要優化。
服務的SLA保證上，服務端超時和限流非常重要。如果沒有超時，很容易引起雪崩。我們來講一個案例，有次商品服務響應變慢，就導致上層的其他服務都慢，而且商品服務積壓了很多請求在線程池中，很多請求響應過慢導致客戶端等待超時，客戶端早就放棄調用結果結束掉了，但是在商品服務線程池線程做處理時拿到這個請求還會處理，客戶都跑了，再去處理，客戶也拿不到這個結果，最后還會造成上層服務請求的堵塞，堵塞原因緩解時產生洪流。
限流是服務穩定的最后一道保障。一個是HTTP服務的限流，一個是RPC服務的限流。我們服務的處理線程是Tesla框架分配的，所以服務限流可以做到非常精確，可以控制在服務級別和服務方法級別，也可以針對來源做限流。
我們做了這樣一系列改造之后，服務框架變成了有完善的監控、有負載均衡、有服務分組和限流等完整管控能力的服務治理框架。服務分組之后，如果通用的服務崩潰了，購買鏈路的服務可以不受影響，這就做到了隔離。這樣的一整套服務體系（如圖）就構成了我們的服務架構2.0，最終網站的可用性做到了99.979%，這是今年6月份的統計數據。我們還會逐步把服務的穩定性和服務質量做到更好。
總結及下一步展望
最后總結一下，服務框架的體系完善是一個漫長的發展過程，不需要一開始就很強、什么都有的服務框架，最早可能就是一個RPC框架。服務治理慢慢隨著業務量增長也會發展起來，服務治理是服務框架的重要組成部分。另外，Tesla是為蘑菇街業務體系量身打造的服務框架。可以說服務框架是互聯網網站架構的核心和持續發展的動力。選擇開源還是自建，要看團隊能力、看時機。我們要深度定制服務框架，所以選擇了自研，以后可能會開源出來。
服務框架是隨著業務發展不斷演變的，我們有1.0、1.5和2.0架構的迭代。要前瞻性地謀劃和實施，要考慮未來三年、五年的容量。有一些系統瓶頸可能是要提前解決的，每一個場景不一樣，根據特定的場景選擇最合適的方案。容量和性能關鍵字是一切可擴展、Cache、IO、異步化。目前我們正在做的是服務治理和SLA保障系統化，未來會做同城異地的雙活。
謝謝大家！
感謝陳興璐對本文的審校。