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

编程问答

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

發(fā)布時間：2025/4/5 编程问答 36 豆豆

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

原文地址：http://www.infoq.com/cn/articles/yhd-11-11-high-availability-and-high-performance

1.?背景

1.1?三高是電商核心交易系統(tǒng)的基礎(chǔ)

電商核心交易系統(tǒng)有很多特點，如分布式、高可擴展等，在眾多特性中，高可用、高并發(fā)、高性能是基礎(chǔ)。大到技術(shù)峰會、論壇、研討會，小到一場面試，高可用、高并發(fā)、高性能始終是焦點，是技術(shù)大牛、技術(shù)追隨者永遠津津樂道的話題，成為他們畢生的追求。

另，ArchSummit全球架構(gòu)師峰會北京站將于2015年12月18日~19日在北京國際會議中心召開，大會設(shè)置了《揭秘雙十一背后的技術(shù)較量》專題來深入解讀雙十一背后的技術(shù)故事，歡迎關(guān)注。

1.2 三高首先依賴的是架構(gòu)

日常和同行、同事的交流過程中，大家經(jīng)常討論的問題就是，你們是如何做到高可用的？訪問峰值達到了什么級別，系統(tǒng)怎么撐住的？高并發(fā)下怎么保證數(shù)據(jù)一致性？性能如何提升？采用了什么新技術(shù)？

盡管大家的答案各有不同，從硬件到軟件、從程序到SQL、從靜態(tài)到動態(tài)、從C到JAVA，但大家最終總能達成一致，高可用、高并發(fā)、高性能依靠的不是某個硬件、某種技術(shù)、某種DB，而是好的架構(gòu)。

1.3 能落地的架構(gòu)才是好架構(gòu)

好架構(gòu)很多，網(wǎng)上隨便一搜，微軟、Google、阿里、京東等眾多大牛的架構(gòu)圖很多，都是好架構(gòu)。

當然今天我們不是來談什么是好架構(gòu)，因為我們從不缺架構(gòu)圖。架構(gòu)圖是形，怎么落地是神；就如軍用材料，技術(shù)大家都懂，工藝才是關(guān)鍵。

所以，能落地的架構(gòu)才是好架構(gòu)，當然我們更缺的是好架構(gòu)的落地點。

2.?1號店如何做三高

1號店技術(shù)部從1個人做起到今天千人級別的規(guī)模，系統(tǒng)支持每天億級的訪問量、單Service支持每天億級的請求、訂單支持每分鐘幾萬單級別、Service服務(wù)可用性達到99.9999%，架構(gòu)上也經(jīng)歷了歷次演進，今天我們就從應(yīng)用架構(gòu)歷次演進的落地點談起。

1號店應(yīng)用架構(gòu)的演進大致經(jīng)歷了以下歷程：強依賴-> Service化->業(yè)務(wù)解耦->讀寫分離->異步->水平/垂直拆分->服務(wù)邏輯分組等。

當然這個過程從不是串行的，永遠是并行的，并且這個過程永遠是在1號店這輛系統(tǒng)大巴行進過程中進行的，因為我們不能停車也不能剎車，而且還必須不斷提速。

2.1 應(yīng)用架構(gòu)的最大演進-SOA治理

早期的1號店系統(tǒng)，遵循簡單的MVC架構(gòu)，Controller層處理了所有的業(yè)務(wù)邏輯包括與DB的交互，在系統(tǒng)初期這種Simple的架構(gòu)方便快捷，成本低業(yè)務(wù)響應(yīng)快。但當業(yè)務(wù)開始變得復雜、人員規(guī)模爆發(fā)式增長，這種強耦合強依賴帶來的弊端就成了巨大的瓶頸，代碼耦合度高互相沖突、出錯概率和事故概率明顯提升，業(yè)務(wù)需求不能快速響應(yīng)，SOA治理迫在眉睫，解耦和去依賴成為第一需求，于是Service化成為第一前提。

2.2 SOA治理- Service日志是保障

1. 做Service首先是規(guī)劃，Service規(guī)劃的第一步首先考慮什么？大家可以先自行考慮下

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

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

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

進數(shù)據(jù)庫、持久化有序化這個大家都理解，我曾經(jīng)接手過的一個應(yīng)用系統(tǒng)，一天下來Tomcat的log文件大小超過1G，會讓你崩潰的。
分類化、層次化、特別是錯誤code唯一這個是關(guān)鍵，它是大海航行中的那盞燈塔，讓你可以瞬間定位問題位置，它給監(jiān)控預警帶來的好處同樣偉大，可以從各個維度去做監(jiān)控預警。

4. 1號店現(xiàn)在有了很好的SOA中間件 – Hedwig，可支持百億級的訪問請求，它有SOA級別的日志，也很完善。但應(yīng)用級別的日志我們還是建議各應(yīng)用系統(tǒng)自己做，它的業(yè)務(wù)性、個性化是公共架構(gòu)永遠代替不了的。

2.3 應(yīng)用架構(gòu)演進之落地

一定有人要問1號店采用的什么RPC框架，好吧，是Hessian，這不是什么秘密。

為什么要用Hessian？我偷偷告訴你，PHP是最偉大的的開發(fā)語言。

2.3.1 業(yè)務(wù)垂直拆分

萬事具備，草船已借箭，要從業(yè)務(wù)角度規(guī)劃Service 了。

我們從產(chǎn)品、用戶、訂單三個維度上對Service進行了規(guī)劃，構(gòu)成1號店應(yīng)用架構(gòu)上的三架馬車，確立了SOA治理的框架基礎(chǔ)。

在此基礎(chǔ)上，又陸續(xù)衍生出促銷、積分、支付等眾多Service業(yè)務(wù)，在三架馬車中同樣會細分至如文描、價格、庫存、下單、訂單查詢等垂直服務(wù)。

Service化是前提，Service化完成后，后面可以大刀闊斧地干了，因為業(yè)務(wù)獨立了、DB讀寫權(quán)限收回了，哈，好像整個天下都是我的了。但，得天下易治天下難，真正的大戲在后面。

2.3.2 讀寫分離

讀寫分離的重要性不需多講，除了最簡單的讀寫分離，寫可以從應(yīng)用層面繼續(xù)細分，讀也可以從應(yīng)用和DB層面再細分，如訂單的讀寫分離：

2.3.3 水平拆分

早在2013年，1號店就實現(xiàn)了庫存的水平拆分，2014年又一舉完成訂單水平拆庫&去Oracle遷Mysql項目。

訂單水平拆庫&去Oracle遷Mysql兩個重量級的大項目合并為一個項目并完美無縫上線，在經(jīng)濟上時間上節(jié)省的是成本，在技術(shù)上體現(xiàn)的1號店的整體技術(shù)實力和水平。

2.3.4 服務(wù)邏輯分組

前面說到了讀寫分離，大家也注意到了，這是物理隔離。

物理分離好處明顯，但其硬件成本、維護成本高的弊端也顯而易見。這時候，我們的大殺器-Hedwig又上場了，有興趣多來了解下我們SOA中間件-Hedwig，這可是獲總裁獎的項目。

Hedwig提供了服務(wù)自動注冊發(fā)現(xiàn)、軟負載均衡、節(jié)點踢出與復活、服務(wù)動態(tài)邏輯分組、請求自動重試等眾多SOA框架所需的強大功能，支持并行請求、灰度發(fā)布，其背后提供的調(diào)用鏈路及層次關(guān)系、日志分析、監(jiān)控預警等更是為SOA治理提供了強大的后勤保障。

2.3.5 業(yè)務(wù)解耦/異步

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

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

我們曾經(jīng)花費兩周多的時間將一個系統(tǒng)的整體性能優(yōu)化提升了近10倍，最后總結(jié)下來，純技術(shù)的優(yōu)化（代碼或sql質(zhì)量導致的性能差）幾乎沒有。

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

異步本身不是什么高深的技術(shù)，關(guān)鍵是哪些業(yè)務(wù)可以走異步，這更體現(xiàn)架構(gòu)師的業(yè)務(wù)理解能力和綜合能力。

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

3.?追求極致

開放、共享、追求極致是1號店技術(shù)人的理念。我們在追求極致上做了很多，簡單舉幾個例子：

3.1 一個下單接口定義了135個錯誤編碼

前面提到過日志和錯誤編碼的定義，大家一定想象不到，我們僅一個下單接口就定義了135個錯誤編碼。接口上線后至今出現(xiàn)的錯誤編碼在50-60個，也就是說有50-60處不合理或錯誤的地方，這個不合理或錯誤既有業(yè)務(wù)的又有程序的也有我們對編碼定義的不合理。

出現(xiàn)一個我們就解決一個，系統(tǒng)自然越來越健壯和穩(wěn)定，目前日常每天下單出現(xiàn)3-5個錯誤編碼，主要為業(yè)務(wù)性如特價商品已售完無庫存等。

那沒有出現(xiàn)過的幾十個編碼是不是就意味著我們工作白做了？

功夫下對了永遠不會浪費，在下單接口上線近2年后，一個之前從未出現(xiàn)過的錯誤編碼跳出來了，是一個很難出現(xiàn)的業(yè)務(wù)場景，但通過這個編碼，我們馬上定位了問題，都不用去看代碼。

我們永遠不能保證系統(tǒng)沒有bug，bug可以藏的很深埋的很久，但我們不怕，因為我們的伏兵也一直在，你一跳我們立馬抓，毫不猶豫。

3.2 Service服務(wù)可用性99.9999%

6個9的Service服務(wù)可用性，可能有人不信，看看我們真實的監(jiān)控郵件，這是每天億級的調(diào)用量。

功夫永遠在戲外，結(jié)果僅僅是一個結(jié)果，一步步踏實走過來的旅程才是我們收獲最大的。

3.3 銷售庫存準確率99.9999%，超賣率為0

做過電商核心系統(tǒng)的人都明白庫存控制的難度，庫存不準甚至超賣的問題至今還有很多電商公司沒有完全解決。

這個問題也曾經(jīng)困擾我們，為此還專門寫了一個庫存刷子的程序來刷數(shù)據(jù)，現(xiàn)在這個程序已基本宣告廢棄了，因為我們的庫存準確率達到了6個9，超賣率為0。

怎么做到的？業(yè)務(wù)、業(yè)務(wù)、業(yè)務(wù)，重要的事說三遍。

我們團隊花了3個多月的時間，對所有庫存應(yīng)用場景逐一排查，最終梳理出16個有問題的庫存場景，并逐一協(xié)調(diào)解決，讓庫存形成嚴格的閉環(huán)線路，保證了庫存的準確性。在這過程中，對庫存閉環(huán)方案和對業(yè)務(wù)的理解成為關(guān)鍵，純靠技術(shù)，我們能做的并不多。

4.?應(yīng)用場景

4.1 業(yè)務(wù)監(jiān)控>

業(yè)務(wù)監(jiān)控首提訂單監(jiān)控，對訂單我們從實際訂單數(shù)據(jù)和Service接口調(diào)用量兩個維度去做監(jiān)控，保證了監(jiān)控系統(tǒng)的穩(wěn)定和準確（監(jiān)控系統(tǒng)也會出錯的），其中下單接口調(diào)用量使用的就是Service日志數(shù)據(jù)。

4.2 服務(wù)監(jiān)控

依賴查詢

(點擊放大圖像)

服務(wù)監(jiān)控