當前位置：首頁 > 编程资源 > 编程问答 >内容正文

编程问答

1号店11.11：从应用架构落地点谈高可用高并发高性能

發布時間：2025/4/5 编程问答 22 豆豆

生活随笔收集整理的這篇文章主要介紹了 1号店11.11：从应用架构落地点谈高可用高并发高性能小編覺得挺不錯的,現在分享給大家,幫大家做個參考.

http://blog.csdn.net/fyxxq/article/details/51597069

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規劃的第一步首先考慮什么？大家可以先自行考慮下

很多人想的是采用什么RPC框架、采用什么技術，怎么讓性能更高；也有人首先想的是業務怎么拆分，怎么才能更合理。
我們首先想到的是如何做監控和問題定位。
高可用不是一步做到的，我們的Service可用性不是一步達到99.9999%的，在這過程中一定會有很多的問題出現，怎么提前發現這些問題、出現問題后如何快速定位，這才是最重要的。這只能依賴日志，這是監控和問題定位的基礎。

2. 下單接口業務性強，其對可用、并發、性能的要求作為技術人你懂的。我們就從這個接口開始下手，但我們沒有先去分析業務，首先想的是如何定義日志系統，讓以后的監控和問題定位更簡單更快捷。事實證明這個決定是對的，直到現在1號店的大部分訂單相關的監控、預警、問題排查定位等完全依賴這個日志。

3. 日志系統的設計基于以下：一是進數據庫、持久化有序化，二是分類化、層次化、錯誤code唯一。

進數據庫、持久化有序化這個大家都理解，我曾經接手過的一個應用系統，一天下來Tomcat的log文件大小超過1G，會讓你崩潰的。
分類化、層次化、特別是錯誤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 業務解耦/異步

上面提到的讀寫分離、水平拆分、邏輯分組等主要是從技術層面保障，也是技術人員最喜歡的話題。業務流程的梳理、優化、改造往往不被重視，但作為應用架構，我們最不能忽視的是業務。

我們的一個核心Service服務，性能從2年前的近200ms到現在的幾十ms，從代碼上、sql上的優化提升頂多占到10%，更多地優化都在業務流程的梳理改造上。

我們曾經花費兩周多的時間將一個系統的整體性能優化提升了近10倍，最后總結下來，純技術的優化（代碼或sql質量導致的性能差）幾乎沒有。

優化主要在兩方面，一是架構上，如使用緩存、單SKU的循環查詢改成批量查詢等，這個能優化的也并不太多，因為我們的架構整體還是比較合理的；最大的優化還是在業務梳理上，很多地方我們使用了重接口，接口里很多邏輯計算和DB查詢，這些邏輯并不是所有的業務場景都需要的，但開發人員為了簡單沒有將業務場景細分，導致大量不合理的調用，既浪費了服務器資源又嚴重影響用戶體驗；同樣，很多地方為了一個不重要的展示或邏輯也產生大量不合理的調用，反而影響了核心業務，這些都是最需要優化的，也是優化效果最明顯的。

異步本身不是什么高深的技術，關鍵是哪些業務可以走異步，這更體現架構師的業務理解能力和綜合能力。

如下單成功后給用戶的消息通知、發票詳細信息的生成等都可以異步，我們在這方面做了很多工作，包括和各業務方的大量溝通制定方案等，在不犧牲用戶體驗又保證業務流程完整的情況下，盡量走異步解耦，這對可用、性能都是極大的提升。

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 服務監控

依賴查詢

(點擊放大圖像)

服務監控