hello，各位同學們大家好，我是姚半仙，慕課網Java架構師課程講師團成員之一。今天不算命，想給大家分享一下我在阿裡所經曆的新零售業務商品中心微服務化的過程。
所謂往事不堪回首啊~~，我們先來看一下它的業務背景。作為整個集團的戰略級項目，這個業務它的背景相當的艱難。
首先，它時間緊。新業務需要進行急速疊代，探知市場的微妙變化，培養使用者的心智，以達到快速驗證商業模式可行性的目的。
其次，這個業務它的任務非常的繁重。 我們所經曆的不是給一座摩天大樓添磚加瓦，而是從0到1搭建這座大樓。是以，在那段黑暗的歲月裡，所有員工過的都是相當的辛苦。9117就像呼吸一樣的自然。（咦，同學們知道9117是什麼意思嗎？可能大家隻知道996吧，9117意思是早上九點到晚上十一點，一周七天班）
時間緊、任務重，這都還好說，咱小夥伴們皮實着呢，但是關鍵問題在于我們**承擔的責任大呀。** 首先這是集團**No.1**的戰略方向。集團對這項業務的投入可以這樣說，叫不計成本。
綜合以上三點,我們的小夥伴們隻好把網際網路精神中的**糙快猛**這種開發模式運用到了極緻。是以當時我們推進項目的方針隻有一個字，那就是快。
這裡隻是一個開頭,我們接下來往下看。除了業務背景以外，**我們再來了解一下業務方都有哪些**。咱們做電商業務的，就是要把商品賣給使用者，是以我們的第一個業務方自然就是終端的使用者， 他們可以通過我們開發的A p p來通路我們系統，除此以外，我們的系統還內建到了手機淘寶當中。手淘這個超級巨無霸App會源源不斷的将使用者流量導入到我們的業務系統。除了這兩項以外，我們還有線下的POS，也就是說，使用者可以在阿裡入股的大型超市中通過線下買單的形式，在我們的背景應用中建立訂單。
我們的業務方當然還包括咱自己的營運小二同學們。我們的産品同學，營運同學，采購同學，他們通常會通過Web頁面登入背景的管理系統來制定業務的規則。除了這些坐在辦公室的同學，我們還有奮戰在一線的從業人員，這些從業人員可以通過履約終端App或者是揀貨端的掃碼槍來通路我們的業務系統，是以我們的業務方非常多元化，使用者導流的入口也是分散在不同的地方。考慮到我們有手淘的導流，這個使用者體量可是相當相當大的,對我們的業務系統的性能是一項非常大的挑戰。
那接下來我們就去了解一下新零售業務都有哪些業務上的需求。我這裡把系統當中比較核心的業務子產品先跟同學們講一下。首先, 首當其沖的就是商品子產品,有的時候我們也叫它商品中心。它是所有電商業務當中最重要的組成部分，因為我們所圍繞的業務核心就是商品。除了商品以外，我們還有訂單中心以及履約中心。訂單中心控制的訂單生成和後面的支付系統相對接。履約中心則是後面的配送流程，是以商品，履約，訂單這三個子產品是我們整個業務系統中最重要的三個部分。當然了，我們可以顯示在這個頁面上的，都是非常重要的需求。
後面還有庫存子產品，它管理着你的商品有多少庫存，能賣多少。這一塊控制不好，可是容易出現超買超賣的情況。後面我們還有使用者中心，那使用者這個概念穿插在整個電商鍊路上下遊所有的業務當中。什麼樣的使用者可以享受什麼樣的優惠？你是不是新人？會不會給你發放新人優惠券？如何檢視這個使用者的目前訂單，曆史訂單等等，都要通過使用者中心來擷取使用者的資訊。那接下來還有搜尋子產品， 搜尋是一個非常重要的導流端，你想買什麼商品，都是通過這一個子產品來觸發的。我們的業務系統不僅涉及到台前這些跟使用者直接打交道的子產品，同時還有幕後的子產品，那就是背景的營運系統。我們的營運同學，銷售同學以及采購同學，他們需要在背景系統當中定制業務的玩法，比如說接下來的營銷子產品，我們可以通過背景的營運系統在營銷子產品中建立新的優惠規則，比如買二送三或者滿五十減十塊或者發放新人優惠券。那再接下來是導購投放系統，這裡就涉及到使用者畫像，通過你的過往浏覽記錄，或者是你的購物記錄來猜測你所需要的商品，投放對應的商品資訊到你的頁面當中。這裡還有一個重要子產品是購物車，它是達成下單的一個必不可少的步驟。那半仙老師我将我自己的青春奉獻給了哪些子產品呢？
就是商品中心，背景營運系統和營銷平台了。其中商品中心和營銷平台可以說是我一手搭建起來的，背景營運系統我也揮灑了很多汗水啊。那我們在這個頁面當中展現的十個子產品，它們背後都被拆成了n多個微服務。但是要提醒同學的是，這裡隻是我們整個業務系統中相對重要的子產品，我們當然還有很多的支援子產品，它并沒有出現在這裡，是以同學們可以預想到在一線網際網路公司中的電商場景，它背景所涉及的業務真的是非常非常複雜的。
那我們接下來就拿老師最熟悉的商品中心再來看一看它在最早期初代的短命版本都是怎麼樣的架構的。首先我們來畫一個圈圈，這個圈圈是什麼啊？它自己說了：“我是一個War包。”
那你想怎麼着吧？它又說了：“我這裡面啥都有”。那我的看看這裡面都有什麼呀。
這裡商品釋出，商品上下架，詳情頁服務，商品搜尋，商品優惠，編輯圖文，所有的功能全部都摻雜在這裡。一個War包提供了整個商品中心所有的功能點，這就是一個非常典型的單體應用。那同學們可能會說，堂堂大阿裡的戰略級産品怎麼建構成了單體應用的架構呢？大家要知道這個單體是一個人寫出來的，是以相當的不容易。為了達到快速上線的目的，可能也不得不這麼做。不過把項目架構成這個樣子的可不是我啊，我把這個鍋甩出去了，但是，轉折來了，我們說這個版本是一個短命的版本，為什麼它的命這麼短啊？因為這個時候老師登場了呀。我加入到這個項目以後呢，就開啟了仙人指路的模式，然後我們立馬上馬了一個新的項目，**叫老城區改造項目**，也就是整個商品中心的微服務改造的大幕被緩緩的拉開了。
現在就帶大家去看一下當時老師做老城區改造計劃的時候，是從哪些方面來做服務的拆分規劃的。我首先從抗壓的角度來分析，将所有的使用者場景劃分為不同的次元。那為什麼從這個角度出發呢？是因為我想把那些非常高頻的（用我們的黑話就叫QPS）這類服務單獨拎出來。這部分服務所承接的壓力非常大，我們在做微服務改造的時候，盡可能的要把這部分服務和基礎服務隔離開來。那我拎出哪些服務呢？一個是商品釋出服務，另外一個是庫存釋出服務，我們把這兩個服務歸類到了低頻瞬時流量的場景。
為什麼說它低頻？因為商品釋出通常都是我們自己集團的從業人員來操作的，那什麼時候操作呢？比方說我開了一家新店的時候，或者說我這裡有一批次供應商剛剛談好了合同，有很多的新商品需要加入，那它的通路頻率并不是非常高，也就是說它是一個低頻場景，不過瞬時流量高，為什麼呢？打個比方，我今天開了一家新的門店，我要把所有現有的十萬或者是二十多萬個商品一鍵釋出到新店，那這時候可能就會在短時間内打出非常高的QPS，那庫存釋出也是同樣的一個道理，我在每天午夜時分要釋出第二天的庫存，那它是一個背景執行的批量請求，它隻在某天當中的幾個時間段會觸發。但是呢，它影響到的商品數量會非常的多，是以我們需要将這種低頻瞬時流量的場景隔離出來。這樣呢，一旦我們因為突發流量導緻商品服務不可用，它也不會影響到其他的技術服務。
ok，我們接下來看另外一個場景。商品詳情頁和商品搜尋服務。這兩個場景不用說我們也知道，它是高頻的勻速流量場景。
所謂高頻，就是說每個使用者在達成一個真實訂單之前，它總要來來回回選擇自己心儀的商品對不對。這個篩選商品的操作一定會途徑商品搜尋服務所檢索出來的商品清單，并且它還要點進去看商品詳情。這兩項服務一定是高頻場景，并且它是相對勻速的，因為我們的剁手族總會在這一天中的任何時刻打開App,翻來覆去的去看自己心儀的商品。那除了低頻突發流量和高頻勻速流量這兩個場景以外，我們還有一些低頻的場景，比如說商品編輯。營運團隊為了吸引顧客，可能會在自己的商品文案當中做一些修改，那這個場景相對頻次會比較低。除此以外，還有預售和改價單，比如設定某一個商品為預售商品使用者可以先點選預購買，但是我并不會實際的發貨，那這就是預售場景了。可下單往往隻應用在某些大促活動之前。打個比方，雙十一之前我設定了一個改價單，讓它在雙十一的0點生效，這個場景同樣頻次也并不高。那接下來往後看，我們還有營銷規則的設定，比如就是前面提到的買二送一，滿五十送五塊。這類營銷規則通常來講也是綁定在某些特定的日期，比如說雙十一、雙十二或者是在新店開張的時候。與營銷規則類似的，還有優惠券的場景，這裡要設定一個新的優惠券模闆，新人專享卷或者是老人專享券等等。那接下來是商品的類目編輯，因為我們新零售業務主要集中在吃貨場景上，是以我們的商品類目要比淘系的全鍊路類目少很多很多，這一類的低頻場景數不勝數，它涵蓋在各種的營運場景當中。
那我們這一頁舉的例子就是想告訴同學們，我們從抗壓的這個角度，把所有的服務大緻歸為了三類：低頻突發流量，高頻勻速流量和低頻的場景。
那我們接下來下一部分是老城區改造計劃的業務角度來出發，把不同的服務歸類于不同的業務，然後把邊界劃厘清楚。比方說我這裡有一個定時任務，定時任務包括改下單，它會在某年某月某日我指定的時間生效。還有庫存釋出計劃，那這兩個場景，我們把它歸類為定時任務的場景。
接下來還有主鍊路+使用者場景。主鍊路是我們電商場景中最核心的鍊路，也就是說，我們的微服改造盡量要圍繞着主鍊路展開。針對主鍊路上的服務，我們會添加投放更多的硬體資源，同時定制非常細緻的降級熔斷政策。那這裡比較有代表性的，有一個是商品詳情頁，還有商品的搜尋服務。這兩塊是主鍊路中非常核心的部分。除此以外，我們還有廣告投放。其實廣告投放并不是主鍊路的一部分，但是它和商品搜尋和商品詳情頁都緊密的綁定了起來，共同構成了使用者購買行為的流量入口。 接下來還有營銷優惠的計算，以及領取優惠券，這兩部是在主鍊路當中生成訂單環節必須要參與訂單價格計算的。那說到訂單，我們自然會想到購物車以及訂單頁面需要展現的商品資訊。
我們說主鍊路大部分是和使用者息息相關。使用者在購買行為當中會直接去操作，去接觸。除此以外，我們還有一些幕後的營運場景，比如說我們前面提到的商品編輯，以及預售商品的設定，還有營運、營銷規則的設定，滿減滿送或者是滿額送券等等。一提送券，我們又要提到優惠券的模闆設定了，當然還有商品的釋出服務，也是營運場景當中的一部分，後面還有商品類目的編輯。
那我這裡隻是從衆多營運場景中篩選了幾個例子，我們将所有服務大緻籠統的歸為了這三類，不過當時在做老城區改造的時候，其實還有更加細緻的分類。這裡隻是舉這樣幾個例子，化繁為簡，幫助同學們了解如何根據業務次元來對商品服務進行分類。
那看完了這兩個不同的分類次元之後，我們就要去談一談，老城區改造計劃都有哪些指導方針。我們的總方針就是**拆遷**。但是這個拆遷也要談一談補償安置方案，你怎麼拆，拆多少。在這裡這個方針更像是一個口号，比如說我們前面根據業務場景做了一些分類，那麼我在做老城區改造計劃的時候，要隔離業務場景。 什麼意思呢？主鍊路當中的場景，我們盡可能把它的服務剝離出來不與其他類型的場景混用，因為主鍊路的場景是使用者完成一個下單必不可少的步驟，我們需要更多的資源去守護它，是以也并不希望它被其它的邊緣業務所影響。除了業務隔離以外呢，我們還要剝離高頻通路的接口，比如前面提到的商品詳情頁和商品搜尋。因為高頻高QPS的計劃往往最容易被使用者的流量給壓垮。是以為了減輕這種情況下對其他服務的影響，我們要剝離高頻的接口。
那接下來我們就順着這兩個指導方針一刀兩段。
看一看經過老城區改造之後的商品中心長什麼樣子。
歡迎各位上司莅臨參加新城區改造項目的驗收會，我們先有請淘系的中台業務方登場。這裡有IC訂單中心，淘系商品中心，UMP營銷優惠中心和背景的支付系統。作為集團大中台戰略中的一部分，這裡的淘系中台業務會為集團所有不同的事業部業務方提供服務支援。那對于我們商品中心來說，首先拆卸的兩個服務就是商品詳情頁的微服務，以及商品釋出的微服務。商品詳情頁微服務是一個高頻高并發的場景，而商品釋出服務是一個低頻，但是有突發流量的場景，是以從性能角度考慮，這兩個微服務都要對上各種各樣的中間件。這裡有分布式的配置中心，緩存以及各種的圖檔存儲，視訊存儲的部分。除此以外，由于商品釋出的調用鍊路非常長，經常會在某些鍊路上卡殼，是以我們這裡引入了一個容錯機制來專門做異常補償，那它底層會将商品釋出的失敗請求轉發到RocketMQ，然後重新消費。因為咱底層是使用的淘系商品，是以這兩個微服務自然而然的需要對接到淘系中台裡的第二個服務-**淘系商品服務**。那我這裡抽象出了一層專門做對接的微服務，就是服務淘寶微服務。服務淘寶專門跟淘系的中台打交道。不過在這個架構下，其實還是有點優化空間的，因為畢竟如果服務淘寶承接了過多的業務方，那它本身也可能成為一個主鍊路中的性能瓶頸，是以我們也可以把商品詳情頁和商品釋出服務直接對接到淘系的中台。
從我個人的使用感受來說，其實中台服務的對接成本是相當相當低的。
那我們接下來往後看，還有哪些微服務？
這裡列出了商品營銷的微服務，還有商品導購的微服務，導購就是前面提到的使用者畫像，一步步把你勾引過來去消費的這個服務。接下來還有資源位的微服務，它是設定手機App的展示商品的清單順序以及它的布局。那前面我們有提到過定時任務的場景對不對啊，就是商品背景批量釋出的任務，比如改下單和庫存釋出。那這裡把這兩個任務單獨抽成了一系列的微服務，同時它們對接到RocketMQ做流量的消峰，用這種方式降低突發流量對系統的沖擊。我們這裡還有一個非常重要的微服務是商品搜尋微服務，它直接對接到淘系的中台，為手機App端提供搜尋支援。與此同時，我們的營運在背景的營運系統當中也會進行商品搜尋，隻不過這個商品搜尋我們走了另外一條鍊路，內建了淘系自己研發的OpenSearch架構，提供搜尋支援。
這裡列出的隻是一部分為服務。我們後面還有很多雜七雜八的，專門為營運小姐姐們準備的微服務，以及衆多更雜七雜八的為剁手族準備的非主鍊路環節的微服務。
那各位上司對咱新城區的改造全貌還滿意嗎？一個單體應用拆解成了這麼多的微服務，不管你有什麼樣的需求，我都可以給你快速變更進來。如此一來項目傳遞大提速，我們的新需求做的更快了，小夥伴們也少加班了。
那經過這麼一番改造，從此我們的團隊就過上了幸福的生活，那麼究竟有多麼幸福呢？我們的作息直接從9117縮減成了隻要996就可以了，此刻我留下了激動的熱淚，真的是太幸福了~~
同學們，我們本次分享就到這裡結束了。在這篇文章中我們從頭到尾體驗了當年阿裡的戰略級産品中商品中心從單體應用到微服務的整個過程，那麼在未來，希望能和大家一起分享下SpringCloud。