架構師小組交流會是由國內知名公司技術專家參與的技術交流會，每期選擇一個時下最熱門的技術話題進行實踐經驗分享。
本期小組交流會邀請到了滬江 Java 架構師黃凱、唯品會架構師鄭明華、滴滴架構師趙偉、七牛雲技術總監肖勤，對微服務粒度、高可用、持續交互展開了交流。
第一輪：自由交流
滬江黃凱：大家好，我是來自滬江的 Java 架構師黃凱。第一次接觸微服務這個概念是在三年前 IBM 的一次 Devops 培訓上，其開發的高效性和與生俱來的便捷性給我留下了深刻的印象。從此，我便會在設計時考慮使用微服務的概念。
離開 IBM 加入滬江以後，正好趕上了重構滬江課件項目。在需求分析階段，發現業務正好符合微服務的特性，用簡單的功能串聯起復雜的業務，結合 Docker+Mesos+Marathon 三劍客的服務編排，使我們大大節省了運維和服務器的開支，從此對微服務更加熱愛。滬江課件系統的架構思想非常簡單，把需求按資源的定義分離開，對每個資源的 CRUD 自然就成爲了一個微服務。比如把課件信息看爲一個資源，這個資源又涉及到數據庫資源和鑑權服務資源，把這三個資源分別做成微服務部署在產線環境中，一個天然的資源調用鏈就出來了。每個微服務的顆粒度按照微服務教主紐曼的教導，以能在兩個星期重構完成的指導下劃分。
唯品會鄭明華：我是來自唯品會的鄭明華。我們並沒有真正實現嚴格意義上定義「微服務」的定義，但我們還是希望把所有的業務領域垂直化劃分。由於剛到唯品會，因此本次討論的基本上都是上家公司的一些經驗。以前在阿里，我們會把訂單、商品、會員、支付、物流，以及後面涉及到外貿相關的通關、外匯、退稅、金融結算等，按照業務領域拆分成不同的服務。但我們並沒有把大的服務再做進一步的拆分，比如讀的服務從報關係統拆分出來，或者是某一部分的寫拆分出來，沒有做這麼細的拆分。只是拆分一個相對比較大的，或相對比較垂直的領域，然後每個領域，是一個或者多個服務組成。
我們剛開始是把下單系統做成一個大的系統，後來發現這個下單系統什麼業務邏輯都在裏面，O2O 在裏面，聚划算在裏面，淘寶在裏面，天貓在裏面，後來把聚划算的拆出來，O2O 拆出來，拆成一個個的微服務。然後把淘寶、天貓的各種交易率讀數不同的拆出來，一個個拆好。所以服務的演進，是跟着我們的業務，對系統的理解一步步來改的，也不是說一設計來是一個大的，其實拆成很多個小的出來的。
我這些都是以前在淘寶、天貓工作內容。我們都是拆成一個一個服務，跟滴滴的也一樣，以前下單（buy）系統也是個大的系統，我們的 buy 系統是個大的辦事系統。後來把整個 buy 系統，又做成了類似於不同的業務，不同的業務是一個不同的服務。後面還有一個成單（TP）系統，成單系統做一個公共的服務，去承接所有訂單的成單，這是我們所說的交易平臺系統。
滴滴趙偉：大家好，我叫趙偉，來自滴滴，目前是在代駕事業部負責架構方面的工作。微服務它應該是一種架構模式，它是將一個系統或者一個應用拆分成一個個小的服務，服務之間的這種相互通信，相互協作，最終爲用戶提供價值。
微服務有幾項特徵：
每個服務都是單一進程的；
業務是獨立性的；
每個服務只做單一功能；
每個服務是高度自治的，從它的這種開發、測試，包括構建部署，這都是獨立的，自己獨立的一套。
我們採用了微服務的架構，是因爲以下幾點優點：
我們覺得微服務相對比較簡單一些，一個業務要統一去考慮的話它是將一個複雜的問題，通過微服務可將複雜問題拆分，它是一個難度降級的過程；
它的比較好的一點就是，服務是一個抽象的東西，它是一種複用的；
它的優點在於它透明，對於調用方來說，它只需要去關心調用的接口，其實我並不關心服務的內部實現的業務邏輯的複雜度；
擴展性會比較好一些，因爲我們現在通過服務無狀態的設計，方便了服務的無限擴展，來支撐互聯網大規模請求。
然後另外一個優點就是改造方面，體現在兩點，第一點就是嘗試一些新的技術比較方便。由於已經拆成能很多服務了，如果有新的技術想嘗試，其實可以找一個三級系統或二級系統，就可以嘗試這個技術了。如果在服務上面能夠實現成功的話，就可以在整個系統的大規模這種推廣。在這個過程中，會對業務的影響會降到最低，這種不可控會降到最低。另一方面，架構改造方面會比較方便一些，比如像服務的拆分或者服務合併，這方面會相對簡單一些。
最後一個優點，相對於單體服務來說，它發佈要簡單一些，因爲每一個服務，它因爲已經拆分了，拆分後它對外部的這種依賴或者說環境對它的影響會比較小，所以說它發佈相對簡單一些。並且代駕事業部現在都是無狀態的服務，狀態全部都是存在緩存裏面的。所以基於這些優點，在滴滴代駕我們是按微服務架構去進行設計的。
七牛肖勤：大家好，我是七牛技術總監肖勤，目前負責基礎架構運營、部署相關的研發工作，爲基礎架構部門的同事提供支持。微服務架構的設計理念非常適合七牛的業務特點。每個服務只負責單一的職責。比如音視頻的處理服務：音視頻轉碼 (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 的數據庫，還是用的大型機。
滬江黃凱：我記得曾經有開發銀行業務的架構師跟我說，他們不是不想動，是不敢動，因爲誰也不知道他那個模塊裏面寫的是什麼東西。如果他們稍微改一改，然後交易或者是轉賬出錯了，誰負責？
滴滴趙偉：我有幾個問題想問一下。
第一個問題在拆服務的時候，你們的組織架構，會不會做一些調整，因爲你拆成微服務了，這種團隊怎麼來負責，責任到人，我不知道你們是怎麼考慮的。
第二個問題，在整個微服發佈過程，它是一個過程，不是一下子就可以做完的，你怎麼去保證它對這種業務的發展，不去影響業務。否則你在調整架構你說多長時間不接需求或者怎麼樣，那業務方就跳起來了。
第三個問題因爲微服務不像單體服務，單體服務它一損俱損，其實它出問題我們很快就能感知到的。微服務它一旦出現問題，剛開始感知會很小，但這種問題會像雪球效應不斷的被放大，最終導致服務不可用。你們在監控、告警、降級等都是怎麼去考慮的？
唯品會鄭明華：第一個問題你說的很敏感，系統架構直接會影響到組織架構。但是我非常不希望看到組織架構影響到系統架構的這樣的一個問題，我是希望系統架構影響到組織架構，所以我在以前團隊面臨的這個問題，這個問題比較難解決。很多時候希望老闆的支持，調整部門之間的利益平衡，有一些時候，架構設計需要作出一些妥協。
滴滴趙偉：是的，但是因爲他是你的支持方，如果沒有這個很好的支持你這個微服務的整個落地可能就會很難，阻力很大。
七牛肖勤：微服務架構在七牛現在已經是一個潛移默化的影響。微服務架構不僅僅是描述技術架構，同樣也是描述團隊架構。就像一種服務的精神，你要注意構建、運營和管理這個服務，這樣一種精神在團隊中是非常有益的，每個人對自己的職責都能夠更加清晰地認識，從而發揮主觀能動性，包括運營、後期的改進，能夠自發地去提升，團隊的管理就會更加輕鬆，效率也會更高。