Microservice 概念

 

一天我司招財貓姐(HR 大人)問我，你給我解釋一下 Microservice 是什麼吧。故成此文。一切都是從一個創業公司開始的。

故事

最近的創業潮很是火爆，我禁不住誘惑也摻和了進去，建立了一家公司。爲了表達個人抱負，取千秋萬代，一統江湖之意。我給公司定下了一個很是響亮的名字叫作——一統。

從集中到分權

雖然說叫作一統可是凡是都要從頭開始，公司成立之初有五個成員：羅密歐，朱麗葉，維克多，布拉伯還有老大——我。咱們五我的都是工程師出身，自身具有了很是優秀的學習能力，各個都是從業務到代碼的好手，五我的一塊兒作策劃，搞市場，寫程序，作運維，面對客戶；可謂你中有我，我中有你，努力拼搏，好不熱鬧。爲了吉利，咱們找了一個車庫做爲機房和資料室，上至合同，下至代碼，全都放在裏面。這就是一統最初的樣子。

雖然創業艱難，大部分公司都在前兩年倒下了，可是我大一統不但沒有倒掉，還意外的獲得了增加。客戶從當初的一家猛增到一百家。這樣即便咱們的團隊再出色也應付不了這麼多的客戶了。掙錢仍是要命呢？

命得要，錢也得掙！怎麼辦呢？招人吧！咱們絞盡腦汁蒐羅（挖角）市場上的人才，組成了巨型一統團隊。咱們認爲咱們團隊中的任何成員都應該跟初創時期的五我的同樣，能攻能守，內外兼修，可是……咱們發現這是不可能的，有些人擅長寫代碼而非面對客戶，有些人善於作市場可是不喜歡算財務。後來出現了更加讓人撓頭的事情，有一個財務流程，問了5-6我的居然沒有一我的可以完整的串起來。因而，我一個一個的問，最後才把整個流程從這些碎片知識裏面串聯起來。

這樣的團隊的服務質量可想而知，不久就接到了數十件客戶投訴。競爭對手趁機搶佔市場，一個欣欣向榮的公司瞬間就風雨飄搖了。

爲了留住客戶，咱們必須在擴張的同時可以保證服務質量。我發現目前最重要的問題就是職責不清晰，你們不知道本身應該幹什麼也不清楚怎麼幹，因而我抽調了各個業務部分的精幹力量，總結流程，造成了客戶及市場、財務/合同、技術運維、管理團隊四個獨立的業務部分。採起內部招聘的方式將人力分配到了這四個部門中。我指望將你們從紛繁的知識體系中解脫出來，每個不須要了解那麼多的知識，集中力量關注本身的問題以提高效率和服務質量。

在這次結構調整以後，你們的工做效率明顯提高了。抱怨知識結構太複雜，沒法短時間適應工做的聲音消失了。一個月以後，咱們作了一個抽樣調查，發現你們對本身的工做範圍和內容都瞭如指掌。一些客戶又從新和咱們簽定了合同。

正當我沾沾自喜的時候，發生了一個重大事件。因爲咱們的資料室是對全公司開放的，任何成員均可以查看或修訂其中的信息。客戶及市場部的一個員工平時很是好學，對財務方面的知識掌握的很是系統。有一天，公司急需草擬一份財務清單，可是這個任務很是耗時，財務部門的同時當時正在月末審覈，無暇抽身。這位熱心的同窗就憑藉本身出色的能力從資料室取來相應的材料完成了清單。三天後，財務部的羅密歐準備細化這個清單。可是清單的內容讓他着實吃了一驚——清單上的填寫內容和他們部門內約定格格不入。羅密歐只得本身從新完成了清單。一來一去讓他的工做耽擱了一天，羅密歐向我抱怨道。無獨有偶，其餘部門也發生了一樣的事情。這讓我意識到只是把人員的職責進行劃分並不能完全解決問題。咱們不能再繼續混用一個資料室了，由於這樣人人均可以任意修改各類資料，安全性很差不說還會形成填寫格式混亂。因而我把財務部的資料放在了另外一個獨立的屋子裏，並給羅密歐單獨配了鑰匙。這樣，任何想填寫財務清單的人只能找財務部的人所要單據，而當單據繳回的時候也必須通過財務部的審覈。鑑於財務部每月底都會很忙，在那時我會臨時抽調人手去幫忙。

我但願對其餘部門作相應的整改，但這種動做幅度畢竟很大，所以，一段時間內還會有多個部門共用資料室。通過一個月的努力，咱們最終仍是淘汰了公用資料室。爲每個部門都配備了獨立資料室。雖然須要繳納更多的房租，可是各部門再也沒有犯以前的錯誤。

協做

如今咱們的資料室都獨立了，再也沒有辦法像之前同樣有須要就去公共資料室裏取資料了。那麼咱們應該如何進行協做呢？

串聯協做

一個很是天然的想法是把各部門用業務流程穿起來。例如，若是洽談一個訂單，先由客戶及市場部進行調查和談判，而後由技術部制定解決方案，管理部審批以後由財務合同部擬定合同，最終遞交管理部簽署。

爲了將這一方案執行下去，咱們對各個部門的人員進行了培訓。例如，對於對於技術部，若是是洽談一個訂單，那麼技術部須要給出解決方案，完成以後須要將方案遞交管理部審批。相似的業務有不少，每個業務各個部門任務都不一樣，而下游接收的部門也不同。可是個人同事們仍是克服了困難，將它們爛熟於胸。

業務調度員

業務變化是最日常的，一變就是一大把。如今對於洽談訂單的業務，咱們須要在技術方案給出以後先給財務部進行預算審覈再遞交管理部。這須要從新培訓三個部門的人，洗腦同樣的把他們以前的流程抹掉。一個業務變化還好，可是一下二三十個業務發生變化讓你們抓狂。甚至有人說這和以前一大坨人一塊兒作全部事情的時候沒有什麼差異。看來這種業務串聯的方式是行不通了。

所謂我不入地獄誰入地獄，這種狀況下我自告奮勇，入住市場部——由於這個部門是直接爲客戶服務的。我對全部的流程瞭如指掌，當業務來了的時候，有我去對業務進行協調。例如，當一個洽談訂單的業務到來的時候，我會先將他交給客戶市場部進行談判；結束後市場部將需求和意向書交給我，我再把需求交給技術部去制定解決方案；方案制定完畢以後技術部會把方案返回給我，我再把結果交給財務部審覈…如此進行。這樣，每個部門就不會因爲業務變化從新接受培訓了，也不用記住他們的下游應該是誰。你們以爲，職責明確多了，工做輕鬆多了。

公司廣播

如今我儼然成爲了流程的中心，其餘業務部門不須要關注業務流程的變化。這給咱們增長了不少靈活性，由於我一我的的變化速度要比一羣人的變化速度快得多（你是獨裁者嗎喂）。可是個人大腦老是有限的，一年以後，經歷了三四輪的業務變化，我已經開始不能準確的回憶某些業務細節。我不得不開始頻繁的查詢個人業務筆記來肯定個人下一步操做；此外，不停的往各部門送信也令我不堪重負。這時候，我但願其餘人可以爲我分擔。我決定化被動爲主動，不禁我主動聯絡各個部門，而由各個部門主動接受任務。我在公司安裝了一個大喇叭，話筒就在個人辦公室裏。當一個訂單洽談業務到來的時候我就朝着喇叭嚎：新訂單來啦。客戶和市場部專門關注新訂單，由於按照流程，訂單到來以後市場部要儘快投入談判。因而他們會主動開始行動。當市場部工做完畢以後，他們會將談判的結果、需求以及意向書拿到個人辦公室裏。我會再嚎：需求來啦。此時，技術部會從我這裏拿走這些資料資料並開始工做。如此往復，直到項目完成。

這種協做方式令我沒必要再操心信息在各部門之間的流轉。各部門知道他們應該什麼時候介入，我只須要對着大喇叭喊天然會有相關的部門將活幹完。這樣，我做爲業務的中轉中心，工做量不會隨着業務的增加顯著的增大（只要喊話就好了，至多就是增長喊話種類），而各部門也不用關心本身的下游究竟是誰，只須要關心我喊的話就好了。看起來這是一種很是方便的形式。可是這真的就又快又省嗎？

有一天，來了一個新的訂單。在我接到意向書和需求以後，我照例喊話：需求來啦！接着，我就出去吃飯了（真是資本家啊你）。等我回到了辦公室，發現文檔已經被拿走了，而結果尚未送過來。時間一天一天過去了，我手頭的新訂單越積越多，需求文檔和意向書源源不斷的送過來。到了第三天我實在是受不了了，想去查找文檔的去向和任務的完成情況。這時候我才發現我根本無從下手，由於我不知道文檔是誰拿走的，因而我便一個部門一個部門的去詢問。但是因爲業務的發展，如今咱們已經有20多個部門了，這種很是規的詢問不只讓我跑斷了腿，並且爲了查證，須要翻閱各部門成噸的業務日誌，各部門的部長對此也很有微辭。我終於意識到——這種協做方式在令結構鬆散靈活的同時也極大的增長了監管的難度。必須採起額外的投入來彌補這一短板。

因而，專門監視各部門動向的「紀檢委」：監管部出現了。一開始，我只是想確認一下各部門運做是否正常，有沒有因爲天災人禍而出現團滅的現象。出於不對各部門添加新的壓力的願望，監管部會按期去肯定各部門走一圈看看是否都在好好幹活（真是討人嫌的部門啊），就像這樣。

可是隨着業務的發展，我但願獲得各個部門更加詳盡的信息，例如，各部門是否積壓了大量任務而須要幫助，在處理過程當中是否因爲流程不合理而沒法繼續下去等等。須要收集的數據已經遠遠超過了監管部跑腿的速度。怎麼辦呢？若是我手頭沒有什麼錢，我可能會下降監管部工做的週期，例如以前是半天一次，如今改爲兩天一次。可是我是土豪，因而我制定了監管彙報單，強制各部門在情況出現問題的時候主動向監管部彙報，就像這樣。

隔離和協做的矛盾

從躊躇滿志的創業開始到如今，我感慨於業務的擴大和公司規模的發展。也有一些會議例如 PCon 但願咱們可以去介紹的結構劃分和協做模式。可是每當我在工做之餘靜靜思考的，卻感到一些厭倦。咱們的協做真的好嗎？隨着職責的劃分，咱們愈來愈專業化，互不影響的工做方式極大的增長了咱們的效率，良好的隔離讓咱們的失誤不至於擴散並可以橫向擴展；而監控系統也告訴咱們一切盡在掌握。可是隔離同時也是壁壘。爲了協做，咱們在這些壁壘上開了些小孔，爲了嚴格控制進出，咱們制定了愈來愈多的規條，例如，信件應該怎麼寫，單據應該怎麼填。回頭看去，成百上千的規約連我也不能盡數，當我須要對個人公司作出變化的時候，若是變化僅僅發生在各個部門內部，這種結構的優點就顯露無遺。可是若是設計到部門之間的協做，甚至部門的拆分合並，就會變得異常艱難。因爲部門和規約的耦合是存在於腦內的，並不顯露在外，修改已經存在的規約和部門結構每每不現實，只能花更多的錢去組建新的部門，逐步介入公司業務後淘汰舊有的部門。而這種週期動輒是以月計算的。有的時候，可能寧肯去接受新的方式從頭開始，賣掉舊的公司，建立新的公司，而後繼續輪迴。

隔離既創造了靈活的單點變化也擴展造就了總體的僵化。細小的部門劃分不能解決這個問題，由於部門越多，規約越多，實施成本越高（在例子中咱們並無考慮資料室的房租，監控的支出，可是現實中這每每是一個決定性因素）。單個部門結構的簡化造就了總體的複雜。

所以，分部門就必定好嗎？業務調度員就沒有公司廣播好嗎？答案應該來源於你的現實，而不是理論。若是讓我重來一次，我可能會慢一點，再慢一點。將來沒法預計，針對當下的痛點作出反應可能不是最優的，可是倒是一個容易理解的思路。

那麼什麼是 Microservice 呢？

在上面的故事裏面，哪一種是 microservice 架構呢？故事裏面公司組織結構演化分紅了幾個部分，並非每個階段的均可以稱之爲 microservice：

• 第一個階段是多個部門共用一個資料室，這種狀況每每並無擺脫數據庫集成的事實（有些項目使用 Schema 對訪問進行隔離，不在此列），不能稱爲 microservice；
• 第二個階段是各個部門有本身的資料室，這是一個很是重要的改變，直到此時，各個部門才實現了徹底的隔離，可是還足以稱爲 microservice；
• 第三個階段分三類：
  • 首先是串聯協做。在這種方式下，一個部門的變化每每影響了其餘部門，由於每個部門都須要知道業務的上游部門和下游部門，所以有比較緊密的耦合關係，沒法獨立變化。所以不足以稱爲 microservice；
  • 其次是業務調度員。這種方式下部門自身的變化不會擴散到其餘部門，所以是能夠獨立決定和操做，只要部門足夠小，這種結構能夠稱之爲 microservice了；
  • 第三是公司廣播。這種方式下的部門耦合更加鬆散，能夠獨立進行變化，在部門足夠小的前提下能夠稱之爲 microservice。

咱們的初衷是什麼呢？構造一個系統能橫向擴展以知足業務伸縮性，提供靈活變化的能力，又但願變化的影響不要擴散。所以，若是一個架構能夠稱之爲 microservice 架構，那麼意味着：

• 每個 Service 能夠進行獨立部署；
• 每個 Service 都足夠小，完成完整的定義清晰的職責；

業務調度員和公司廣播兩個例子的組織結構均可以成爲 microservice 架構。可是他們之間並無絕對的優劣之分。選用哪種應當取決於實際要求。

故事映射

這個部分會將故事中的概念映射到實際的架構中以幫助理解。關於 microservice 的更多信息，推薦 Building Microservice 一書（雖然這本書也是 ThoughtWorks 的牛人寫的，可是這真的不是軟廣啊）。

一統公司最開始時的組織結構表明了典型的 monolitic application。這種系統的邏輯架構是相似這樣的。

而在部門劃分共用一個資料庫後，系統進入了多個服務共享一個數據庫的階段，集成點在數據庫上。

在每個部門都擁有了本身的資料庫以後，各個部門的隔離很是完全了。在串聯協做的方式下，系統的結構是相似這樣的。

這種結構沒法作到服務的獨立部署，所以應當避免。而業務調度員結構以下圖所示。

若是你還記得那位勤勞的調度員（我），那麼你就必定認識 Composer 這個特殊的服務。而最複雜的大喇叭喊話則是對應着以下的架構。

寫在最後

Microservice 不是一種科學，而僅僅是實踐。就像是 OO 同樣。最終應當是需求，是人，決定架構而非架構決定需求。Microservice 是爲 Business Capability 而建，是根據實際（或者痛點）作出的抉擇。他解決了一些問題，可是並不能確定就是從此軟件的發展方向。硬件的革新——不管是近期的電池技術的發展，仍是近乎黑科技的量子態傳輸，量子計算都有可能影響甚至顛覆今天造成的軟件開發手段。就像是當年你們爲了追求極致的執行效率試圖將代碼塞進 64K 的代碼段同樣，咱們今天奉爲經典的東西將來可能只是茶餘飯後的談資。咱們能作的只有保持開放的心態，堅持辯證的觀點，堅持從實際出發（我當年政治必定得高分了），尋找出最合適的解決方案。這也就是咱們不稱本身爲碼農的理由之一吧。