惟品會、滴滴、滬江架構師，關於微服務粒度、高可用、持續交互的實踐分享交流（上）

架構師小組交流會是由國內知名公司技術專家參與的技術交流會，每期選擇一個時下最熱門的技術話題進行實踐經驗分享。
 

本期小組交流會邀請到了滬江 Java 架構師黃凱、惟品會架構師鄭明華、滴滴架構師趙偉、七牛雲技術總監肖勤，對微服務粒度、高可用、持續交互展開了交流。

第一輪：自由交流

滬江黃凱：你們好，我是來自滬江的 Java 架構師黃凱。第一次接觸微服務這個概念是在三年前 IBM 的一次 Devops 培訓上，其開發的高效性和與生俱來的便捷性給我留下了深入的印象。今後，我便會在設計時考慮使用微服務的概念。

離開 IBM 加入滬江之後，正好遇上了重構滬江課件項目。在需求分析階段，發現業務正好符合微服務的特性，用簡單的功能串聯起復雜的業務，結合 Docker+Mesos+Marathon 三劍客的服務編排，使咱們大大節省了運維和服務器的開支，今後對微服務更加熱愛。滬江課件系統的架構思想很是簡單，把需求按資源的定義分離開，對每一個資源的 CRUD 天然就成爲了一個微服務。好比把課件信息看爲一個資源，這個資源又涉及到數據庫資源和鑑權服務資源，把這三個資源分別作成微服務部署在產線環境中，一個自然的資源調用鏈就出來了。每一個微服務的顆粒度按照微服務教主紐曼的教導，以能在兩個星期重構完成的指導下劃分。

惟品會鄭明華：我是來自惟品會的鄭明華。咱們並無真正實現嚴格意義上定義「微服務」的定義，但咱們仍是但願把全部的業務領域垂直化劃分。因爲剛到惟品會，所以本次討論的基本上都是上家公司的一些經驗。之前在阿里，咱們會把訂單、商品、會員、支付、物流，以及後面涉及到外貿相關的通關、外匯、退稅、金融結算等，按照業務領域拆分紅不一樣的服務。但咱們並無把大的服務再作進一步的拆分，好比讀的服務從報關係統拆分出來，或者是某一部分的寫拆分出來，沒有作這麼細的拆分。只是拆分一個相對比較大的，或相對比較垂直的領域，而後每一個領域，是一個或者多個服務組成。

咱們剛開始是把下單系統作成一個大的系統，後來發現這個下單系統什麼業務邏輯都在裏面，O2O 在裏面，聚划算在裏面，淘寶在裏面，天貓在裏面，後來把聚划算的拆出來，O2O 拆出來，拆成一個個的微服務。而後把淘寶、天貓的各類交易率讀數不一樣的拆出來，一個個拆好。因此服務的演進，是跟着咱們的業務，對系統的理解一步步來改的，也不是說一設計來是一個大的，其實拆成不少個小的出來的。

我這些都是之前在淘寶、天貓工做內容。咱們都是拆成一個一個服務，跟滴滴的也同樣，之前下單（buy）系統也是個大的系統，咱們的 buy 系統是個大的辦事系統。後來把整個 buy 系統，又作成了相似於不一樣的業務，不一樣的業務是一個不一樣的服務。後面還有一個成單（TP）系統，成單系統作一個公共的服務，去承接全部訂單的成單，這是咱們所說的交易平臺系統。

滴滴趙偉：你們好，我叫趙偉，來自滴滴，目前是在代駕事業部負責架構方面的工做。微服務它應該是一種架構模式，它是將一個系統或者一個應用拆分紅一個個小的服務，服務之間的這種相互通訊，相互協做，最終爲用戶提供價值。

微服務有幾項特徵：

• 每一個服務都是單一進程的；

• 業務是獨立性的；

• 每一個服務只作單一功能；

• 每一個服務是高度自治的，從它的這種開發、測試，包括構建部署，這都是獨立的，本身獨立的一套。

咱們採用了微服務的架構，是由於如下幾點優勢：

1. 咱們以爲微服務相對比較簡單一些，一個業務要統一去考慮的話它是將一個複雜的問題，經過微服務可將複雜問題拆分，它是一個難度降級的過程；

2. 它的比較好的一點就是，服務是一個抽象的東西，它是一種複用的；

3. 它的優勢在於它透明，對於調用方來講，它只須要去關心調用的接口，其實我並不關心服務的內部實現的業務邏輯的複雜度；

4. 擴展性會比較好一些，由於咱們如今經過服務無狀態的設計，方便了服務的無限擴展，來支撐互聯網大規模請求。

而後另一個優勢就是改造方面，體如今兩點，第一點就是嘗試一些新的技術比較方便。因爲已經拆成能不少服務了，若是有新的技術想嘗試，其實能夠找一個三級系統或二級系統，就能夠嘗試這個技術了。若是在服務上面可以實現成功的話，就能夠在整個系統的大規模這種推廣。在這個過程當中，會對業務的影響會降到最低，這種不可控會降到最低。另外一方面，架構改造方面會比較方便一些，好比像服務的拆分或者服務合併，這方面會相對簡單一些。

最後一個優勢，相對於單體服務來講，它發佈要簡單一些，由於每個服務，它由於已經拆分了，拆分後它對外部的這種依賴或者說環境對它的影響會比較小，因此說它發佈相對簡單一些。而且代駕事業部如今都是無狀態的服務，狀態所有都是存在緩存裏面的。因此基於這些優勢，在滴滴代駕咱們是按微服務架構去進行設計的。

七牛肖勤：你們好，我是七牛技術總監肖勤，目前負責基礎架構運營、部署相關的研發工做，爲基礎架構部門的同事提供支持。微服務架構的設計理念很是適合七牛的業務特色。每一個服務只負責單一的職責。好比音視頻的處理服務：音視頻轉碼 (avthumb)， 音視頻拼接 (avconcat)， 視頻幀縮略圖 (vframe)，點播流式轉碼 (avvod)，都是以微服務的方式構建，這樣每一個服務都擁有獨立的運行環境，而且能夠根據自身的業務壓力狀況進行獨立擴展，動態的彈性擴展還能夠提升資源的利用率。

當須要調用多個微服務時，根據七牛雲的數據處理的業務特色咱們使用管道（pipeline）來進行串行的處理。每個微服務的輸出都是下一個微服務的輸入，直到最後一個微服務執行結束纔是最終數據處理的內容。好比上傳一個視頻資源後，須要作兩個數據處理操做: 轉成 Mp4 資源和進行 HLS 切片，這種場景下不能對原資源同時執行兩個數據處理的操做，必須按序執行。同時還支持將經常使用的一些 MServer 集合進行服務組的定義，好比對全部的視頻都有轉碼和加水印的操做，那麼能夠把這兩個服務定義爲一個服務組，這樣每次調用這個服務組就能夠同時執行兩個服務了。

第二輪：話題交流

主持人：微服務的粒度是怎樣的？每一個微服務跟的數據庫，服務數據的對應關係是怎樣的？

滴滴趙偉：關於微服務粒度這塊，個人理解是適合本身的是最好的。其實沒有規定必定服務粒度多大，要多少代碼或者要多長時間開發完，其實沒有這種。在系統剛上線的時候，要根據業務配合，除了業務以外，可能還要根據組織架構這種方式跟微服務相配合起來。

最初在上線的時候，咱們的業務場景只有一個，就是酒後代駕。咱們的 Team 當時又分紅管理後臺、訂單、用戶、營銷跟支付這 5 個 Team。而後每一個 Team，用戶的話就是用戶服務，訂單的話就是訂單服務。除了主要的幾個服務以外，還有一些二級的服務，像組合服務之類的。咱們當時服務的力度是比較粗的，好比訂單服務從用戶的下單，最後到派單、搶單，整套服務所有在裏面的。

隨着業務的發展，咱們的業務場景在不斷的擴展。除了最新上的帶保養項目，帶保養的跟酒後代駕最大的區別在於，酒後代駕用戶下一個訂單，實際須要一次代駕服務。可是代保養，下一個訂單其實是須要兩次代駕服務的。因此在原先的訂單的服務，你會發現它的服務的粒度已經不適合了。緣由在於這種業務場景，你要再往原先的訂單裏面去加就已經很難加了，這種維護成本就很高，而後咱們對服務的粒度又進行了拆分。好比，咱們把派單或者搶單，這種細粒度的服務，進行了一個拆分，把這些作成一個基礎服務池。基礎服務池裏有訂單、發單、全司機、派單，包括實時的計費，原先都是在同一個的訂單服務裏的。可是如今把它拆成基礎服務，咱們都會有專人去維護它，要改的話就由專人去改。

咱們把訂單、支付，用戶等稱之爲普通服務。普通服務就是對應到業務場景，好比酒後代駕的業務場景，它有本身的訂單，底下會使用到基礎服務，好比說返單、全司機。代保養它也會有本身的訂單，由於它的這種訂單，可能跟酒後代駕這種訂單的業務形態不太同樣，可是它的發單、全司機、派單這種業務形態是同樣的，因此它到時候也會去使用咱們的基礎服務池裏面的基礎服務。由於把服務粒度又縮小了，至關於不一樣的業務場景抽象出來的一些基礎服務，而後提供不一樣的業務場景。架構的演進是隨着業務形態的發展去逐步演進的，不可能作到一次到位。每一個商業上，它都有商業時間點的，你錯過窗口期就可能趕不上了。因此你必須把多快好省的把系統先上上去，在架構上逐步演進。咱們剛開始的時候只有酒後代駕，你要去考慮到什麼代保養、什麼包司機之類的，當時是不必的，而且你也不知道最終的需求形態會是什麼樣子。

滬江黃凱：微服務其實有一些準則，好比說最好是能在兩個星期內所有完成。但在實際的項目中，咱們要考慮三個點。第一個它是 Share requestful，這什麼意思呢？把本身功能集中在本身這，不屬於這些功能的儘可能的分出去，這就是咱們常說的高內聚，低耦合。第二個是是否可以獨立的自治。最後一個是是否能自動的發佈。我認爲只有知足這三個點才能稱爲一個微服務。

惟品會鄭明華：這個粒度有點細，若是作學術研究是還不錯的原則，可是放在工程方面，我以爲還須要從新考慮，仍是太細了。

滬江黃凱：贊成，其實由於這些粒度太過於細，致使一個問題。就是大家剛剛討論的，我以爲也是有道理的，折射出一個康爲定律。康威定律是說一個組織結構決定了系統結構。若是公司的組織就沒有分的這麼細，架構設計出來的再細，它也是不可能實現，由於我以爲系統架構決定不了組織結構。可是若是咱們的組織架構慢慢的變細了，那麼系統結構必定會向微服務發展。

惟品會鄭明華：另一個就是我以爲若是服務拆的太細的話，後面帶來的服務的管理，服務的分佈式事業的問題很差解決。

滬江黃凱：據我瞭解騰訊有一個微服務的結構，調用鏈達到 36 級，一個請求發出去要 36 層調用後纔會給一個迴應，我以爲這就拆的太細了，微信紅包就是這麼作的。他們一秒支付率是 15.6 萬筆。他們在網關和服務間的調用上面花了太大的投入了，騰訊基本上把底層給優化了，連網卡的緩存他們都用起來了。騰訊對系統性能挖掘與調優已經作到極致了，36 層調用鏈，也就是一會的事情，也沒看見微信紅包在過年的時候垮掉。

惟品會鄭明華：騰訊有個哥們是 Linux 內核開發者，因此他應該可以改到你說的網卡的緩存這塊，可是通常的公司很難有這方面的高手去作這個事情。

滴滴趙偉：騰訊的操做系統實際上是被本身優化過的，由於他們自己在騰訊主流的話，就是 C，C++ 這種開發，自己他們對 Linux，TCP 這種的都很熟的。並且他們底層是單元化的，雖然有三十幾層的調用鏈，可是他們都是在同一個機房或同一個地區去完成，他們請求不會去產生跨機房或者跨地區的調用，並且他們自己內部的機器也很好，帶寬也很足。並且自己在於服務之間的網絡傳輸，它們耗時並不高的，主要可能仍是會在業務上面，就是每一個服務本身處理的市場問題。

滬江黃凱：我以爲這要根據本身的業務和本身的研發能力，不少人對微服務的理解就是一個單體服務，是胖一點的單體服務的減肥版，減掉一些，排除一些功能而已。

惟品會鄭明華：沒那麼簡單吧，微服務首先是你應該業務拆分，從業務開始一直到底層的數據庫要拆分。

滬江黃凱：但這個拆分很是之痛苦，若是你開始以微服務來設計那還好，若是你開始是一個大型的服務，特別像銀行這種金融性的業務，拆成微服務的話更難。

惟品會鄭明華：銀行好像沒有用微服務的這種模式吧。銀行的數據庫仍是單個數據庫，仍是 Oracle 的數據庫，仍是用的大型機。

滬江黃凱：我記得曾經有開發銀行業務的架構師跟我說，他們不是不想動，是不敢動，由於誰也不知道他那個模塊裏面寫的是什麼東西。若是他們稍微改一改，而後交易或者是轉帳出錯了，誰負責？

滴滴趙偉：我有幾個問題想問一下。

第一個問題在拆服務的時候，大家的組織架構，會不會作一些調整，由於你拆成微服務了，這種團隊怎麼來負責，責任到人，我不知道大家是怎麼考慮的。

第二個問題，在整個微服發佈過程，它是一個過程，不是一會兒就能夠作完的，你怎麼去保證它對這種業務的發展，不去影響業務。不然你在調整架構你說多長時間不接需求或者怎麼樣，那業務方就跳起來了。

第三個問題由於微服務不像單體服務，單體服務它一損俱損，其實它出問題咱們很快就能感知到的。微服務它一旦出現問題，剛開始感知會很小，但這種問題會像雪球效應不斷的被放大，最終致使服務不可用。大家在監控、告警、降級等都是怎麼去考慮的？

惟品會鄭明華：第一個問題你說的很敏感，系統架構直接會影響到組織架構。可是我很是不但願看到組織架構影響到系統架構的這樣的一個問題，我是但願系統架構影響到組織架構，因此我在之前團隊面臨的這個問題，這個問題比較難解決。不少時候但願老闆的支持，調整部門之間的利益平衡，有一些時候，架構設計須要做出一些妥協。

滴滴趙偉：是的，可是由於他是你的支持方，若是沒有這個很好的支持你這個微服務的整個落地可能就會很難，阻力很大。

七牛肖勤：微服務架構在七牛如今已是一個潛移默化的影響。微服務架構不只僅是描述技術架構，一樣也是描述團隊架構。就像一種服務的精神，你要注意構建、運營和管理這個服務，這樣一種精神在團隊中是很是有益的，每一個人對本身的職責都可以更加清晰地認識，從而發揮主觀能動性，包括運營、後期的改進，可以自發地去提高，團隊的管理就會更加輕鬆，效率也會更高。