架構師小組交流會是由國內知名公司技術專家參與的技術交流會， 每期選擇一個時下最熱門的技術話題進行實踐經驗分享。
本期小組交流會邀請到了滬江 Java 架構師黃凱、唯品會架構師鄭明華、滴滴架構師趙偉、七牛雲技術總監肖勤， 對微服務細微性、高可用、持續交互展開了交流。
自由交流
滬江黃凱
大家好， 我是來自滬江的 Java 架構師黃凱。 第一次接觸微服務這個概念是在三年前 IBM 的一次 Devops 培訓上， 其開發的高效性和與生俱來的便捷性給我留下了深刻的印象。 從此， 我便會在設計時考慮使用微服務的概念。
離開 IBM 加入滬江以後， 正好趕上了重構滬江課件項目。 在需求分析階段， 發現業務正好符合微服務的特性， 用簡單的功能串聯起複雜的業務， 結合 Docker+Mesos+Marathon 三劍客的服務編排， 使我們大大節省了運維和伺服器的開支， 從此對微服務更加熱愛。 滬江課件系統的架構思想非常簡單， 把需求按資源的定義分離開， 對每個資源的 CRUD 自然就成為了一個微服務。 比如把課件資訊看為一個資源， 這個資源又涉及到資料庫資源和鑒權服務資源， 把這三個資源分別做成微服務部署在產線環境中， 一個天然的資源調用鏈就出來了。 每個微服務的顆粒度按照微服務教主紐曼的教導， 以能在兩個星期重構完成的指導下劃分。
唯品會鄭明華
我是來自唯品會的鄭明華。 我們並沒有真正實現嚴格意義上定義「微服務」的定義， 但我們還是希望把所有的業務領域垂直化劃分。 由於剛到唯品會， 因此本次討論的基本上都是上家公司的一些經驗。 以前在阿裡， 我們會把訂單、商品、會員、支付、物流， 以及後面涉及到外貿相關的通關、外匯、退稅、金融結算等， 按照業務領域拆分成不同的服務。 但我們並沒有把大的服務再做進一步的拆分， 比如讀的服務從報關系統拆分出來， 或者是某一部分的寫拆分出來， 沒有做這麼細的拆分。 只是拆分一個相對比較大的， 或相對比較垂直的領域， 然後每個領域， 是一個或者多個服務組成。
我們剛開始是把下單系統做成一個大的系統，
我這些都是以前在淘寶、天貓工作內容。 我們都是拆成一個一個服務， 跟滴滴的也一樣， 以前下單（buy）系統也是個大的系統， 我們的 buy 系統是個大的辦事系統。 後來把整個 buy 系統， 又做成了類似於不同的業務， 不同的業務是一個不同的服務。 後面還有一個成單（TP）系統， 成單系統做一個公共的服務，
滴滴趙偉
大家好， 我叫趙偉， 來自滴滴， 目前是在代駕事業部負責架構方面的工作。 微服務它應該是一種架構模式， 它是將一個系統或者一個應用拆分成一個個小的服務， 服務之間的這種相互通信， 相互協作， 最終為用戶提供價值。
微服務有幾項特徵：
每個服務都是單一進程的；
業務是獨立性的；
每個服務只做單一功能；
每個服務是高度自治的， 從它的這種開發、測試， 包括構建部署， 這都是獨立的， 自己獨立的一套。
我們採用了微服務的架構， 是因為以下幾點優點：
我們覺得微服務相對比較簡單一些， 一個業務要統一去考慮的話它是將一個複雜的問題，
它的比較好的一點就是， 服務是一個抽象的東西， 它是一種複用的；
它的優點在於它透明， 對於調用方來說， 它只需要去關心調用的介面， 其實我並不關心服務的內部實現的業務邏輯的複雜度；
擴展性會比較好一些， 因為我們現在通過服務無狀態的設計， 方便了服務的無限擴展， 來支撐互聯網大規模請求。
然後另外一個優點就是改造方面， 體現在兩點， 第一點就是嘗試一些新的技術比較方便。 由於已經拆成能很多服務了， 如果有新的技術想嘗試， 其實可以找一個三級系統或二級系統， 就可以嘗試這個技術了。 如果在服務上面能夠實現成功的話， 就可以在整個系統的大規模這種推廣。在這個過程中，會對業務的影響會降到最低，這種不可控會降到最低。另一方面，架構改造方面會比較方便一些，比如像服務的拆分或者服務合併，這方面會相對簡單一些。
最後一個優點，相對於單體服務來說，它發佈要簡單一些，因為每一個服務，它因為已經拆分了，拆分後它對外部的這種依賴或者說環境對它的影響會比較小，所以說它發佈相對簡單一些。並且代駕事業部現在都是無狀態的服務，狀態全部都是存在緩存裡面的。所以基於這些優點，在滴滴代駕我們是按微服務架構去進行設計的。
七牛肖勤
大家好，我是七牛技術總監肖勤，目前負責基礎架構運營、部署相關的研發工作，為基礎架構部門的同事提供支援。微服務架構的設計理念非常適合七牛的業務特點。每個服務只負責單一的職責。比如音視頻的處理服務：音視頻轉碼 (avthumb)， 音視頻拼接 (avconcat)， 視頻幀縮略圖 (vframe)，點播流式轉碼 (avvod)，都是以微服務的方式構建，這樣每個服務都擁有獨立的運行環境，並且可以根據自身的業務壓力情況進行獨立擴展，動態的彈性擴展還可以提高資源的利用率。
當需要調用多個微服務時，根據七牛雲的資料處理的業務特點我們使用管道（pipeline）來進行串列的處理。每一個微服務的輸出都是下一個微服務的輸入，直到最後一個微服務執行結束才是最終資料處理的內容。比如上傳一個視頻資源後，需要做兩個資料處理操作: 轉成 Mp4 資源和進行 HLS 切片，這種場景下不能對原資源同時執行兩個資料處理的操作，必須按序執行。同時還支援將常用的一些 MServer 集合進行服務組的定義，比如對所有的視頻都有轉碼和加浮水印的操作，那麼可以把這兩個服務定義為一個服務組，這樣每次調用這個服務組就可以同時執行兩個服務了。
話題交流
Q
微服務的細微性是怎樣的？每個微服務跟的資料庫，服務資料的對應關係是怎樣的？
滴滴趙偉：關於微服務細微性這塊，我的理解是適合自己的是最好的。其實沒有規定一定服務細微性多大，要多少代碼或者要多長時間開發完，其實沒有這種。在系統剛上線的時候，要根據業務配合，除了業務之外，可能還要根據組織架構這種方式跟微服務相配合起來。
最初在上線的時候，我們的業務場景只有一個，就是酒後代駕。我們的 Team 當時又分成管理後臺、訂單、使用者、行銷跟支付這 5 個 Team。然後每個 Team，使用者的話就是使用者服務，訂單的話就是訂單服務。除了主要的幾個服務之外，還有一些二級的服務，像組合服務之類的。我們當時服務的力度是比較粗的，比如訂單服務從使用者的下單，最後到派單、搶單，整套服務全部在裡面的。
隨著業務的發展，我們的業務場景在不斷的擴展。除了最新上的帶保養項目，帶保養的跟酒後代駕最大的區別在於，酒後代駕使用者下一個訂單，實際需要一次代駕服務。但是代保養，下一個訂單實際上是需要兩次代駕服務的。所以在原先的訂單的服務，你會發現它的服務的細微性已經不適合了。原因在於這種業務場景，你要再往原先的訂單裡面去加就已經很難加了，這種維護成本就很高，然後我們對服務的細微性又進行了拆分。比如，我們把派單或者搶單，這種細細微性的服務，進行了一個拆分，把這些做成一個基礎服務池。基礎服務池裡有訂單、發單、全司機、派單，包括即時的計費，原先都是在同一個的訂單服務裡的。但是現在把它拆成基礎服務，我們都會有專人去維護它，要改的話就由專人去改。
我們把訂單、支付，使用者等稱之為普通服務。普通服務就是對應到業務場景，比如酒後代駕的業務場景，它有自己的訂單，底下會使用到基礎服務，比如說返單、全司機。代保養它也會有自己的訂單，因為它的這種訂單，可能跟酒後代駕這種訂單的業務形態不太一樣，但是它的發單、全司機、派單這種業務形態是一樣的，所以它到時候也會去使用我們的基礎服務池裡面的基礎服務。因為把服務細微性又縮小了，相當於不同的業務場景抽象出來的一些基礎服務，然後提供不同的業務場景。架構的演進是隨著業務形態的發展去逐步演進的，不可能做到一次到位。每個商業上，它都有商業時間點的，你錯過視窗期就可能趕不上了。所以你必須把多快好省的把系統先上上去，在架構上逐步演進。我們剛開始的時候只有酒後代駕，你要去考慮到什麼代保養、什麼包司機之類的，當時是沒必要的，並且你也不知道最終的需求形態會是什麼樣子。
滬江黃凱：微服務其實有一些準則，比如說最好是能在兩個星期內全部完成。但在實際的項目中，我們要考慮三個點。第一個它是 Share requestful，這什麼意思呢？把自己功能集中在自己這，不屬於這些功能的儘量的分出去，這就是我們常說的高內聚，低耦合。第二個是是否能夠獨立的自治。最後一個是是否能自動的發佈。我認為只有滿足這三個點才能稱為一個微服務。
唯品會鄭明華：這個細微性有點細，如果做學術研究是還不錯的原則，但是放在工程方面，我覺得還需要重新考慮，還是太細了。
滬江黃凱：同意，其實因為這些細微性太過於細，導致一個問題。就是你們剛剛討論的，我覺得也是有道理的，折射出一個康為定律。康威定律是說一個組織結構決定了系統結構。如果公司的組織就沒有分的這麼細，架構設計出來的再細，它也是不可能實現，因為我覺得系統架構決定不了組織結構。但是如果我們的組織架構慢慢的變細了，那麼系統結構一定會向微服務發展。
唯品會鄭明華：另外一個就是我覺得如果服務拆的太細的話，後面帶來的服務的管理，服務的分散式事業的問題不好解決。
滬江黃凱：
唯品會鄭明華：騰訊有個哥們是 Linux 內核開發者，所以他應該能夠改到你說的網卡的緩存這塊，但是一般的公司很難有這方面的高手去做這個事情。
滴滴趙偉：騰訊的作業系統其實是被自己優化過的，因為他們本身在騰訊主流的話，就是 C，C++ 這種開發，本身他們對 Linux，TCP 這種的都很熟的。而且他們底層是單元化的，雖然有三十幾層的調用鏈，但是他們都是在同一個機房或同一個地區去完成，他們請求不會去產生跨機房或者跨地區的調用，而且他們本身內部的機器也很好，頻寬也很足。而且本身在於服務之間的網路傳輸，它們耗時並不高的，主要可能還是會在業務上面，就是每個服務自己處理的市場問題。
滬江黃凱：我覺得這要根據自己的業務和自己的研發能力，很多人對微服務的理解就是一個單體服務，是胖一點的單體服務的減肥版，減掉一些，排除一些功能而已。
唯品會鄭明華：沒那麼簡單吧，微服務首先是你應該業務拆分，從業務開始一直到底層的資料庫要拆分。
滬江黃凱：但這個拆分非常之痛苦，如果你開始以微服務來設計那還好，如果你開始是一個大型的服務，特別像銀行這種金融性的業務，拆成微服務的話更難。
唯品會鄭明華：銀行好像沒有用微服務的這種模式吧。銀行的資料庫還是單個資料庫，還是 Oracle 的資料庫，還是用的大型機。
滬江黃凱：我記得曾經有開發銀行業務的架構師跟我說，他們不是不想動，是不敢動，因為誰也不知道他那個模組裡面寫的是什麼東西。如果他們稍微改一改，然後交易或者是轉帳出錯了，誰負責？
滴滴趙偉：我有幾個問題想問一下。
第一個問題在拆服務的時候，你們的組織架構，會不會做一些調整，因為你拆成微服務了，這種團隊怎麼來負責，責任到人，我不知道你們是怎麼考慮的。
第二個問題，在整個微服發佈過程，它是一個過程，不是一下子就可以做完的，你怎麼去保證它對這種業務的發展，不去影響業務。否則你在調整架構你說多長時間不接需求或者怎麼樣，那業務方就跳起來了。
第三個問題因為微服務不像單體服務，單體服務它一損俱損，其實它出問題我們很快就能感知到的。微服務它一旦出現問題，剛開始感知會很小，但這種問題會像雪球效應不斷的被放大，最終導致服務不可用。你們在監控、告警、降級等都是怎麼去考慮的？
唯品會鄭明華：第一個問題你說的很敏感，系統架構直接會影響到組織架構。但是我非常不希望看到組織架構影響到系統架構的這樣的一個問題，我是希望系統架構影響到組織架構，所以我在以前團隊面臨的這個問題，這個問題比較難解決。很多時候希望老闆的支持，調整部門之間的利益平衡，有一些時候，架構設計需要作出一些妥協。
滴滴趙偉：是的，但是因為他是你的支持方，如果沒有這個很好的支援你這個微服務的整個落地可能就會很難，阻力很大。
七牛肖勤：微服務架構在七牛現在已經是一個潛移默化的影響。微服務架構不僅僅是描述技術架構，同樣也是描述團隊架構。就像一種服務的精神，你要注意構建、運營和管理這個服務，這樣一種精神在團隊中是非常有益的，每個人對自己的職責都能夠更加清晰地認識，從而發揮主觀能動性，包括運營、後期的改進，能夠自發地去提升，團隊的管理就會更加輕鬆，效率也會更高。
往期回顧
就可以在整個系統的大規模這種推廣。在這個過程中，會對業務的影響會降到最低，這種不可控會降到最低。另一方面，架構改造方面會比較方便一些，比如像服務的拆分或者服務合併，這方面會相對簡單一些。最後一個優點，相對於單體服務來說，它發佈要簡單一些，因為每一個服務，它因為已經拆分了，拆分後它對外部的這種依賴或者說環境對它的影響會比較小，所以說它發佈相對簡單一些。並且代駕事業部現在都是無狀態的服務，狀態全部都是存在緩存裡面的。所以基於這些優點，在滴滴代駕我們是按微服務架構去進行設計的。
七牛肖勤
大家好，我是七牛技術總監肖勤，目前負責基礎架構運營、部署相關的研發工作，為基礎架構部門的同事提供支援。微服務架構的設計理念非常適合七牛的業務特點。每個服務只負責單一的職責。比如音視頻的處理服務：音視頻轉碼 (avthumb)， 音視頻拼接 (avconcat)， 視頻幀縮略圖 (vframe)，點播流式轉碼 (avvod)，都是以微服務的方式構建，這樣每個服務都擁有獨立的運行環境，並且可以根據自身的業務壓力情況進行獨立擴展，動態的彈性擴展還可以提高資源的利用率。
當需要調用多個微服務時，根據七牛雲的資料處理的業務特點我們使用管道（pipeline）來進行串列的處理。每一個微服務的輸出都是下一個微服務的輸入，直到最後一個微服務執行結束才是最終資料處理的內容。比如上傳一個視頻資源後，需要做兩個資料處理操作: 轉成 Mp4 資源和進行 HLS 切片，這種場景下不能對原資源同時執行兩個資料處理的操作，必須按序執行。同時還支援將常用的一些 MServer 集合進行服務組的定義，比如對所有的視頻都有轉碼和加浮水印的操作，那麼可以把這兩個服務定義為一個服務組，這樣每次調用這個服務組就可以同時執行兩個服務了。
話題交流
Q
微服務的細微性是怎樣的？每個微服務跟的資料庫，服務資料的對應關係是怎樣的？
滴滴趙偉：關於微服務細微性這塊，我的理解是適合自己的是最好的。其實沒有規定一定服務細微性多大，要多少代碼或者要多長時間開發完，其實沒有這種。在系統剛上線的時候，要根據業務配合，除了業務之外，可能還要根據組織架構這種方式跟微服務相配合起來。
最初在上線的時候，我們的業務場景只有一個，就是酒後代駕。我們的 Team 當時又分成管理後臺、訂單、使用者、行銷跟支付這 5 個 Team。然後每個 Team，使用者的話就是使用者服務，訂單的話就是訂單服務。除了主要的幾個服務之外，還有一些二級的服務，像組合服務之類的。我們當時服務的力度是比較粗的，比如訂單服務從使用者的下單，最後到派單、搶單，整套服務全部在裡面的。
隨著業務的發展，我們的業務場景在不斷的擴展。除了最新上的帶保養項目，帶保養的跟酒後代駕最大的區別在於，酒後代駕使用者下一個訂單，實際需要一次代駕服務。但是代保養，下一個訂單實際上是需要兩次代駕服務的。所以在原先的訂單的服務，你會發現它的服務的細微性已經不適合了。原因在於這種業務場景，你要再往原先的訂單裡面去加就已經很難加了，這種維護成本就很高，然後我們對服務的細微性又進行了拆分。比如，我們把派單或者搶單，這種細細微性的服務，進行了一個拆分，把這些做成一個基礎服務池。基礎服務池裡有訂單、發單、全司機、派單，包括即時的計費，原先都是在同一個的訂單服務裡的。但是現在把它拆成基礎服務，我們都會有專人去維護它，要改的話就由專人去改。
我們把訂單、支付，使用者等稱之為普通服務。普通服務就是對應到業務場景，比如酒後代駕的業務場景，它有自己的訂單，底下會使用到基礎服務，比如說返單、全司機。代保養它也會有自己的訂單，因為它的這種訂單，可能跟酒後代駕這種訂單的業務形態不太一樣，但是它的發單、全司機、派單這種業務形態是一樣的，所以它到時候也會去使用我們的基礎服務池裡面的基礎服務。因為把服務細微性又縮小了，相當於不同的業務場景抽象出來的一些基礎服務，然後提供不同的業務場景。架構的演進是隨著業務形態的發展去逐步演進的，不可能做到一次到位。每個商業上，它都有商業時間點的，你錯過視窗期就可能趕不上了。所以你必須把多快好省的把系統先上上去，在架構上逐步演進。我們剛開始的時候只有酒後代駕，你要去考慮到什麼代保養、什麼包司機之類的，當時是沒必要的，並且你也不知道最終的需求形態會是什麼樣子。
滬江黃凱：微服務其實有一些準則，比如說最好是能在兩個星期內全部完成。但在實際的項目中，我們要考慮三個點。第一個它是 Share requestful，這什麼意思呢？把自己功能集中在自己這，不屬於這些功能的儘量的分出去，這就是我們常說的高內聚，低耦合。第二個是是否能夠獨立的自治。最後一個是是否能自動的發佈。我認為只有滿足這三個點才能稱為一個微服務。
唯品會鄭明華：這個細微性有點細，如果做學術研究是還不錯的原則，但是放在工程方面，我覺得還需要重新考慮，還是太細了。
滬江黃凱：同意，其實因為這些細微性太過於細，導致一個問題。就是你們剛剛討論的，我覺得也是有道理的，折射出一個康為定律。康威定律是說一個組織結構決定了系統結構。如果公司的組織就沒有分的這麼細，架構設計出來的再細，它也是不可能實現，因為我覺得系統架構決定不了組織結構。但是如果我們的組織架構慢慢的變細了，那麼系統結構一定會向微服務發展。
唯品會鄭明華：另外一個就是我覺得如果服務拆的太細的話，後面帶來的服務的管理，服務的分散式事業的問題不好解決。
滬江黃凱：
唯品會鄭明華：騰訊有個哥們是 Linux 內核開發者，所以他應該能夠改到你說的網卡的緩存這塊，但是一般的公司很難有這方面的高手去做這個事情。
滴滴趙偉：騰訊的作業系統其實是被自己優化過的，因為他們本身在騰訊主流的話，就是 C，C++ 這種開發，本身他們對 Linux，TCP 這種的都很熟的。而且他們底層是單元化的，雖然有三十幾層的調用鏈，但是他們都是在同一個機房或同一個地區去完成，他們請求不會去產生跨機房或者跨地區的調用，而且他們本身內部的機器也很好，頻寬也很足。而且本身在於服務之間的網路傳輸，它們耗時並不高的，主要可能還是會在業務上面，就是每個服務自己處理的市場問題。
滬江黃凱：我覺得這要根據自己的業務和自己的研發能力，很多人對微服務的理解就是一個單體服務，是胖一點的單體服務的減肥版，減掉一些，排除一些功能而已。
唯品會鄭明華：沒那麼簡單吧，微服務首先是你應該業務拆分，從業務開始一直到底層的資料庫要拆分。
滬江黃凱：但這個拆分非常之痛苦，如果你開始以微服務來設計那還好，如果你開始是一個大型的服務，特別像銀行這種金融性的業務，拆成微服務的話更難。
唯品會鄭明華：銀行好像沒有用微服務的這種模式吧。銀行的資料庫還是單個資料庫，還是 Oracle 的資料庫，還是用的大型機。
滬江黃凱：我記得曾經有開發銀行業務的架構師跟我說，他們不是不想動，是不敢動，因為誰也不知道他那個模組裡面寫的是什麼東西。如果他們稍微改一改，然後交易或者是轉帳出錯了，誰負責？
滴滴趙偉：我有幾個問題想問一下。
第一個問題在拆服務的時候，你們的組織架構，會不會做一些調整，因為你拆成微服務了，這種團隊怎麼來負責，責任到人，我不知道你們是怎麼考慮的。
第二個問題，在整個微服發佈過程，它是一個過程，不是一下子就可以做完的，你怎麼去保證它對這種業務的發展，不去影響業務。否則你在調整架構你說多長時間不接需求或者怎麼樣，那業務方就跳起來了。
第三個問題因為微服務不像單體服務，單體服務它一損俱損，其實它出問題我們很快就能感知到的。微服務它一旦出現問題，剛開始感知會很小，但這種問題會像雪球效應不斷的被放大，最終導致服務不可用。你們在監控、告警、降級等都是怎麼去考慮的？
唯品會鄭明華：第一個問題你說的很敏感，系統架構直接會影響到組織架構。但是我非常不希望看到組織架構影響到系統架構的這樣的一個問題，我是希望系統架構影響到組織架構，所以我在以前團隊面臨的這個問題，這個問題比較難解決。很多時候希望老闆的支持，調整部門之間的利益平衡，有一些時候，架構設計需要作出一些妥協。
滴滴趙偉：是的，但是因為他是你的支持方，如果沒有這個很好的支援你這個微服務的整個落地可能就會很難，阻力很大。
七牛肖勤：微服務架構在七牛現在已經是一個潛移默化的影響。微服務架構不僅僅是描述技術架構，同樣也是描述團隊架構。就像一種服務的精神，你要注意構建、運營和管理這個服務，這樣一種精神在團隊中是非常有益的，每個人對自己的職責都能夠更加清晰地認識，從而發揮主觀能動性，包括運營、後期的改進，能夠自發地去提升，團隊的管理就會更加輕鬆，效率也會更高。
往期回顧