1.背景 1.1三高是電商核心交易系統的基礎
電商核心交易系統有很多特點，如分布式、高可擴展等，在眾多特性中，高可用、高並發、高性能是基礎。大到技術峰會、論壇、研討會，小到一場面試，高可用、高並發、高性能始終是焦點，是技術大牛、技術追隨者永遠津津樂道的話題，成為他們畢生的追求。
另，ArchSummit全球架構師峰會北京站將於2015年12月18日~19日在北京國際會議中心召開，大會設置了《揭秘雙十一背後的技術較量》專題來深入解讀雙十一背後的技術故事，歡迎關注。
1.2 三高首先依賴的是架構
日常和同行、同事的交流過程中，大家經常討論的問題就是，你們是如何做到高可用的？訪問峰值達到了什麼級別，系統怎麼撐住的？高並發下怎麼保證數據一致性？性能如何提升？採用了什麼新技術？
儘管大家的答案各有不同，從硬體到軟體、從程序到SQL、從靜態到動態、從C到JAVA，但大家最終總能達成一致，高可用、高並發、高性能依靠的不是某個硬體、某種技術、某種DB，而是好的架構。
1.3 能落地的架構才是好架構
好架構很多，網上隨便一搜，微軟、Google、阿里、京東等眾多大牛的架構圖很多，都是好架構。
當然今天我們不是來談什麼是好架構，因為我們從不缺架構圖。架構圖是形，怎麼落地是神；就如軍用材料，技術大家都懂，工藝才是關鍵。
所以，能落地的架構才是好架構，當然我們更缺的是好架構的落地點。
2.1號店如何做三高
1號店技術部從1個人做起到今天千人級別的規模，系統支持每天億級的訪問量、單Service支持每天億級的請求、訂單支持每分鐘幾萬單級別、Service服務可用性達到99.9999%，架構上也經歷了歷次演進，今天我們就從應用架構歷次演進的落地點談起。
1號店應用架構的演進大致經歷了以下歷程：強依賴-> Service化->業務解耦->讀寫分離->異步->水平/垂直拆分->服務邏輯分組等。
當然這個過程從不是串行的，永遠是並行的，並且這個過程永遠是在1號店這輛系統大巴行進過程中進行的，因為我們不能停車也不能剎車，而且還必須不斷提速。
2.1 應用架構的最大演進-SOA治理
早期的1號店系統，遵循簡單的MVC架構，Controller層處理了所有的業務邏輯包括與DB的交互，在系統初期這種Simple的架構方便快捷，成本低業務響應快。但當業務開始變得複雜、人員規模爆發式增長，這種強耦合強依賴帶來的弊端就成了巨大的瓶頸，代碼耦合度高互相衝突、出錯概率和事故概率明顯提升，業務需求不能快速響應，SOA治理迫在眉睫，解耦和去依賴成為第一需求，於是Service化成為第一前提。
2.2 SOA治理- Service日誌是保障
1. 做Service首先是規劃，Service規劃的第一步首先考慮什麼？大家可以先自行考慮下
2. 下單接口業務性強，其對可用、並發、性能的要求作為技術人你懂的。我們就從這個接口開始下手，但我們沒有先去分析業務，首先想的是如何定義日誌系統，讓以後的監控和問題定位更簡單更快捷。事實證明這個決定是對的，直到現在1號店的大部分訂單相關的監控、預警、問題排查定位等完全依賴這個日誌。
3. 日誌系統的設計基於以下：一是進資料庫、持久化有序化，二是分類化、層次化、錯誤code唯一。
4. 1號店現在有了很好的SOA中間件 – Hedwig，可支持百億級的訪問請求，它有SOA級別的日誌，也很完善。但應用級別的日誌我們還是建議各應用系統自己做，它的業務性、個性化是公共架構永遠代替不了的。
2.3 應用架構演進之落地
一定有人要問1號店採用的什麼RPC框架，好吧，是Hessian，這不是什麼秘密。
為什麼要用Hessian？我偷偷告訴你，PHP是最偉大的的開發語言。
2.3.1 業務垂直拆分
萬事具備，草船已借箭，要從業務角度規劃Service 了。
我們從產品、用戶、訂單三個維度上對Service進行了規劃，構成1號店應用架構上的三架馬車，確立了SOA治理的框架基礎。
在此基礎上，又陸續衍生出促銷、積分、支付等眾多Service業務，在三架馬車中同樣會細分至如文描、價格、庫存、下單、訂單查詢等垂直服務。
Service化是前提，Service化完成後，後面可以大刀闊斧地幹了，因為業務獨立了、DB讀寫權限收回了，哈，好像整個天下都是我的了。但，得天下易治天下難，真正的大戲在後面。
2.3.2 讀寫分離
讀寫分離的重要性不需多講，除了最簡單的讀寫分離，寫可以從應用層面繼續細分，讀也可以從應用和DB層面再細分，如訂單的讀寫分離：
2.3.3 水平拆分
早在2013年，1號店就實現了庫存的水平拆分，2014年又一舉完成訂單水平拆庫&去Oracle遷Mysql項目。
訂單水平拆庫&去Oracle遷Mysql兩個重量級的大項目合併為一個項目並完美無縫上線，在經濟上時間上節省的是成本，在技術上體現的1號店的整體技術實力和水平。
2.3.4 服務邏輯分組
前面說到了讀寫分離，大家也注意到了，這是物理隔離。
物理分離好處明顯，但其硬體成本、維護成本高的弊端也顯而易見。這時候，我們的大殺器-Hedwig又上場了，有興趣多來了解下我們SOA中間件-Hedwig，這可是獲總裁獎的項目。
Hedwig提供了服務自動註冊發現、軟負載均衡、節點踢出與復活、服務動態邏輯分組、請求自動重試等眾多SOA框架所需的強大功能，支持並行請求、灰度發布，其背後提供的調用鏈路及層次關係、日誌分析、監控預警等更是為SOA治理提供了強大的後勤保障。
2.3.5 業務解耦/異步
上面提到的讀寫分離、水平拆分、邏輯分組等主要是從技術層面保障，也是技術人員最喜歡的話題。業務流程的梳理、優化、改造往往不被重視，但作為應用架構，我們最不能忽視的是業務。
3.追求極致
開放、共享、追求極致是1號店技術人的理念。我們在追求極致上做了很多，簡單舉幾個例子：
3.1 一個下單接口定義了135個錯誤編碼
前面提到過日誌和錯誤編碼的定義，大家一定想像不到，我們僅一個下單接口就定義了135個錯誤編碼。接口上線後至今出現的錯誤編碼在50-60個，也就是說有50-60處不合理或錯誤的地方，這個不合理或錯誤既有業務的又有程序的也有我們對編碼定義的不合理。
出現一個我們就解決一個，系統自然越來越健壯和穩定，目前日常每天下單出現3-5個錯誤編碼，主要為業務性如特價商品已售完無庫存等。
那沒有出現過的幾十個編碼是不是就意味著我們工作白做了？
功夫下對了永遠不會浪費，在下單接口上線近2年後，一個之前從未出現過的錯誤編碼跳出來了，是一個很難出現的業務場景，但通過這個編碼，我們馬上定位了問題，都不用去看代碼。
我們永遠不能保證系統沒有bug，bug可以藏的很深埋的很久，但我們不怕，因為我們的伏兵也一直在，你一跳我們立馬抓，毫不猶豫。
3.2 Service服務可用性99.9999%
6個9的Service服務可用性，可能有人不信，看看我們真實的監控郵件，這是每天億級的調用量。
功夫永遠在戲外，結果僅僅是一個結果，一步步踏實走過來的旅程才是我們收穫最大的。
3.3 銷售庫存準確率99.9999%，超賣率為0
做過電商核心系統的人都明白庫存控制的難度，庫存不準甚至超賣的問題至今還有很多電商公司沒有完全解決。
這個問題也曾經困擾我們，為此還專門寫了一個庫存刷子的程序來刷數據，現在這個程序已基本宣告廢棄了，因為我們的庫存準確率達到了6個9，超賣率為0。
怎麼做到的？業務、業務、業務，重要的事說三遍。
我們團隊花了3個多月的時間，對所有庫存應用場景逐一排查，最終梳理出16個有問題的庫存場景，並逐一協調解決，讓庫存形成嚴格的閉環線路，保證了庫存的準確性。在這過程中，對庫存閉環方案和對業務的理解成為關鍵，純靠技術，我們能做的並不多。
4.應用場景 4.1 業務監控>
業務監控首提訂單監控，對訂單我們從實際訂單數據和Service接口調用量兩個維度去做監控，保證了監控系統的穩定和準確（監控系統也會出錯的），其中下單接口調用量使用的就是Service日誌數據。
4.2 服務監控 依賴查詢
(點擊放大圖像)
服務監控
(點擊放大圖像)
5.後言
電商核心交易系統的高可用、高並發、高性能不是一朝一夕的，需要好的技術，更需要好的架構，如何找到落地點並一步步踏實落地，這是關鍵。有想法、有目標、有執行力，必有所成。
我們是技術人，但我們的很多工作並不一定要多高深的技術，業務和技術的平衡點才是最重要的。業務敏銳性對應用架構師和開發人員來說都尤為重要，因為更多的時候我們要的是解決方案而不是技術方案。
謹以此獻給那些在追求高可用、高並發、高性能道路上飛奔的同學們！祝你們早日三高：）
感謝郭蕾對本文的策劃和審校。
給InfoQ中文站投稿或者參與內容翻譯工作，請郵件至editors@cn.infoq.com。也歡迎大家通過新浪微博（@InfoQ，@丁曉昀），微信（微信號：InfoQChina）關注我們，並與我們的編輯和其他讀者朋友交流（歡迎加入InfoQ讀者交流群）。
相關內容
相關廠商內容
看Scala如何顛覆傳統金融企業 高可用網貸系統讓您投資無憂 微眾架構首秀--基於自主可控技術的分布式架構實踐 企業級SaaS應用平臺--釘釘技術歷程之路
相關贊助商