成功微服務實施的組織演進

在 成功微服務實施的技術演進裏咱們介紹了案例中微服務架構演進的技術背景，本文介紹一下這期間發生的組織演進。能夠說，一個合適的組織結構是驅動微服務架構成功落地的必要能力。

在咱們如何衡量微服務實施的成功裏面，咱們介紹到系統的規模會由於維護成本達到極限。這個維護成本中最主要的一個部分就是人員成本和管理成本。而在這個案例裏，咱們能夠看到兩個特徵：管理層的縮減和生產力的提高。

微服務開發團隊的演化過程

在最開始的時候，咱們的產品分爲兩類團隊，以下圖所示：

microservice-team.png

一類是維護現有產品的團隊，咱們稱之爲「BAU （Business As Usual）團隊」。這樣一個團隊用來修復 Bug、清理技術債、並對生產需求快速響應，有時候也作一些小於一個迭代（2周）的需求。能夠說是一些重要又緊急的事情。在代碼庫上負責對代碼主幹和hotfix（快速修復）分支進行更改。

另外一類團隊是功能團隊，又稱特性團隊。這樣的團隊有多個，都是按照不一樣的新特性和新需求組建的團隊。團隊大小根據需求的規模和項目的週期決定。每一個團隊都有一個特性分支，這個特性分支採用單主幹開發。在開發的過程當中會天天把master 分支合併到本身的分支上，以下降將來合併的痛苦。

待特性開發團隊完成了一個項目或者一個特性的開發後，代碼合併到主幹，開始進行1~3個月的維護期，這個期間特性團隊解散併入BAU團隊。而以前 BAU 團隊的成員開始準備成立新的特性開發團隊了。

因爲代碼是「全民全部制」，每一個人都會對全部的代碼質量負責，而不是本身負責的那一小塊。並且每一個團隊在 BAU 項目上工做的時候，能夠學習到完整的業務知識和開發實踐。所以 BAU 團隊也適合培養剛加入團隊的新人。

在這樣不斷的輪換過程當中，每一個人都學習到了整個代碼庫的業務知識，也參與了新特性的開發。

微服務團隊就來自於這樣一個特性團隊：咱們須要爲新的微服務新建一個代碼庫。也須要在原先的代碼庫上經過建立新的分支來進行修改，把微服務集成到老的系統上去。當微服務部署好以後，新的分支就會被合併到主幹，部署後和微服務集成。

後來，隨着須要微服務化改造的系統愈來愈多，會慢慢演變成下圖的樣子：

多個微服務的團隊

從宏觀上來看，一個企業爲了知足各個方面的信息化需求，必定會有不少不一樣的應用系統。好比財務、人員管理、產品管理、工做流程等。等發展到了必定階段必定會須要經過技術手段將不一樣的系統實現數據共享。咱們會採用系統集成技術來集成不一樣的系統，把全部的系統都整合到一塊兒。這裏就涉及到了兩個問題：

一個是「�Single source of truth」，也就是單一事實來源。咱們但願在多系統集成的狀況下，某一種數據，例如客戶信息、價格，等都有單一的事實來源。不然在不一樣子系統之間出現數據不一致的狀況。

另一個就是以前提到的 Design For Failure，在業務正在運行的期間，應用系統的改造不能使當前業務崩潰。所以，咱們的任何一個決策都要保持現有業務運行的穩定，一方面是人員組織，另外一方面是系統架構。

圖裏三個顏色表示三個業務系統，三個業務系統最開始只有 Team A 是作微服務的，它只作一個應用的一小部分，好比 APP-1 的其中一個微服務。而其它的團隊還在維護各自的單體應用。他們把全部應用業務切分紅不一樣的微服務並集成，花了三到五年的時間。他們的團隊所面對的維護工做量看起更大的了，由於他們須要關注的點更多了，可是它的團隊沒有增長反而減小了。某些團隊被拆散，和其餘的團隊整合。或者開發了新的業務部門。

以前在這個公司裏面一共有120個開發人員在維護這些系統，包括咱們這邊和客戶那邊的，到如今只剩80我的了。過去四年到五年有將近 30% 的人離職去搞比特幣或者區塊鏈創業了，固然還有人補充進來。

然而他們的系統並無由於要維護這麼多模塊垮掉，而是這麼多人已經足夠多了。一開始咱們是有運維團隊的，第一個微服務團隊和這個團隊是一塊兒工做的。到後面它又再也不去到每個團隊工做了，而是造成一個運維模式，這個團隊就是以前文章提到過的「熊貓團隊」（PandA，Platform AND Architecture 平臺和架構團隊）。

微服務的團隊大小的原則

多大的微服務團隊是合適的？下面是咱們微服務團隊的照片，亞馬遜提出兩個披薩餅的團隊。咱們也採用過兩個必勝客披薩的團隊，但咱們發現兩個披薩的團隊不符合實際。是由於你所碰到微服務的粒度是不同大的。

所以，咱們組建了「兩個桌子間」的團隊，以下圖所示：

兩張桌子間的微服務團隊

團隊的規模決定了兩件事：溝通的成本和微服務的大小

這兩個條件一個決定了團隊規模的上限，一個該決定了團隊規模的上限。所謂「兩個披薩的團隊」事實上約束了團隊的成本，一樣也約束了微服務的規模。若是團隊面對的代碼庫以爲力不從心，你就得縮減一下微服務的規模直到團隊可以獨立維護這個微服務。若是不少人都空閒，你可讓團隊承擔多一點代碼。

這張照片是咱們的一個微服務團隊大概的規模：兩個桌子背對背的空間，最大不超過16我的。

這樣的一個空間造成了一個自然的場地：顯示器是自然的屏障，你須要轉過身來面對你們而不是坐在顯示器背後。這樣人和人之間不存在阻礙，也沒有了祕密。這偏偏是一個團隊理想的開會場所，咱們在這裏開站立會議，而且在一頭設置了物理的看板牆，這樣團隊能夠對當前的工做一目瞭然。

咱們決定微服務團隊的大小有三個原則：

1. 團隊的成員相互之間能夠隨時溝通：兩個桌子之間的空地就是咱們的會議室，有事隨時溝通，同時也不會被隔壁桌子打擾。

2. 不增長額外的管理成本：無需增長管理團隊來管理微服務團隊，微服務團隊的工做責任邊界徹底自治。

3. 不須要加班便可完成計劃的任務：代表當前的工做量對於團隊成員來講是合適的。

若是大於這個尺寸，證實你的微服務團隊過大，須要進一步拆分。遇之相對應的是你的微服務的開發維護工做量過大，也須要進一步拆分。團隊的最好的大小是和微服務的工做量是一致的。

若是小於這個尺寸，會由於微服務拆分的太小反而增長管理成本。你會發現有不少的團隊須要協調，不得不增長協調人員來協調各微服務之間的工做，這就是額外的微服務團隊管理成本。

固然，你能夠擁有「兩輛轎車」的團隊或者「一個大圓桌團隊：團隊全部人出去吃飯恰好能夠坐下兩輛轎車，或者能夠坐下一個包廂的圓桌。主要仍是爲了下降團隊溝通和決策的成本，增長團隊凝聚力。

從工做量的角度來看，天天的工做量要達到75%以上的時間利用率。也就是說，若是是「朝九晚六」（9:00-18:00）的工做方式，除去午休的一個小時。全天有8個小時的工做時間，起碼要保證至少 6 個小時是在微服務的工做上。能夠有2個小時左右的時間處理私人和組織的事務。若是微服務團隊內部的工做時間小於這個比例，那麼就證實組織之間存在額外的溝通成本，這些溝通就是須要被拆分出來的依賴，或者被下放的責任。

微服務團隊中的角色分工

做爲一個微服務團隊組織是什麼樣的呢？咱們的微服務團隊是一個全功能的敏捷團隊。這樣的一個團隊除了知足以上的團隊大小外，還須要知足「全功能」和「敏捷」兩個條件。

首先，咱們是一個全功能的團隊，也就意味着咱們的團隊能夠處理整個團隊端到端的全部任務，而無需依賴其它團隊。這就保證了團隊的自治。

其次，咱們是一個敏捷團隊，採用敏捷方法論和實踐指導微服務的實踐。

咱們的角色分工是這樣的：

微服務團隊是一個全功能團隊

• 一名微服務的負責人。這樣的團隊咱們又叫項目經理（PM），又叫MS-MASTER，它是一個複合的角色，不光是經理仍是架構師是技術角色。幫咱們隔離外部的干擾，例如會議、溝通等……以確保團隊能夠獨立的工做。

• 一名業務分析師（BA），而發現須要這麼一個角色的過程是經歷過慘痛教訓的：若是你的團隊沒有人十分熟悉業務流程和組織結構，劃分出來的微服務就會和別的團隊有重複。這就違反了單一事實來源的原則，而提早的分析能夠避免這一點。而團隊內部大部分是開發工程師，兩個到14個不等。固然，這樣的一名業務分析師能夠多個團隊共享。不過剛開始的時候，建議一個微服務團隊有一個專門的業務分析師和領域專家共同合做。

• 一名質量分析師（QA），咱們的 QA 不只僅是作測試的，咱們的 QA 還要理解業務，而 QA 是作全流程的質量保障。咱們的測試流程是開發工程師寫的自動化測試。注意，因爲微服務的拋棄成本很低，咱們並無很高的單元測試覆蓋率，可是咱們要確保對應的端到端測試和集成測試都是大部分被覆蓋的。另外咱們須要運維工程師來幫咱們設計持續部署和在線微服務的監控。此外，因爲QA熟悉業務，某種程度上能夠替代 BA 的職責。

• 一名運維工程師（Ops），幫咱們構建基礎設施平臺並作好配置，以便咱們快速部署微服務。這樣當須要運維支持的時候，咱們就不須要依賴運維團隊了。這樣一個角色能夠是多個團隊共有的，它能夠在多個團隊中尋找一些模式來構建微服務平臺或者工具。

• 一名技術負責人（Tech Lead），主要負責架構和技術選型，指導其它開發者的開發，某種程度上是能夠做爲 Ops 。

• 若干個開發者（Dev），完成微服務的開發。須要注意的是，這樣一個團隊包括前端工程師和後端工程師，而不只僅是前端工程師。

此外，微服務團隊的劃分容易出現兩個誤區：一個是根據系統模塊劃分團隊，另外一個是團隊只負責某一個微服務。

1. 前端團隊和後端團隊：有些狀況下，咱們會根據技能或者技術棧來區分兩類團隊。這樣的有一個明顯的陷阱：兩個團隊只對微服務的一部分負責。這樣的先後端依賴若是沒有管理的很好則會出現阻塞。一種解決辦法是採用消費者驅動的契約測試來創建先後端之間的開發規範。另一種辦法則是經過全功能團隊來消除這種隔閡。微服務團隊的 PM、QA 和 BA 共同監督先後端的集成。這時候，前端和後端都要看作統一的微服務，只是集成到不一樣的網關而已。

2. 按微服務劃分團隊：另一個很危險的事情是一個微服務一個團隊，這樣劃分團隊的結果會變成更加隔離小團隊。每一個小團隊只關注本身的微服務，而無論的整個業務的場景集成。這時候就須要更多的管理手段來介入，反而增長了更多的管理層使整個組織膨脹。此外，這樣會給人一種錯覺，咱們都是獨立發佈獨立部署的。然而開發需求、特別是集成不少微服務的需求則是須要詳細安排開發計劃的，這樣不考慮業務場景的並行開發只會致使更多的阻塞和延遲，使得端到端的測試成本不斷提升，阻礙整個架構靈活的變更。一種錯誤的技術解決方案是採用多個在線的微服務版原本保證兼容性。但帶來的只會是過渡方案的妥協和資源的浪費：爲了不兼容性帶來的問題，會在線留存多個版本，誰都不能輕易下線以前的版本。

所以，一個團隊可以獨立的完成端到端的開發和部署纔是微服務團隊的黃金原則。

微服務團隊的工做規範和節奏

樹立起微服務的工做規範是很重要的，它能造成文化和模式，替代管理人員將微服務的經驗快速擴張。因此微服務的工做規範是須要最先開始確立，並不斷在實踐中完善的。

當咱們剛開始作微服務的時候，並不知道哪一條微服務路徑是更好的。儘管有各類各樣的方法論，但在實際過程當中還會出現這樣那樣的問題。因此咱們先作一到兩個試點，而後去總結出一個模式出來，可是必定要注意不要把它造成一個公共代碼庫，不然又變成了新的耦合。

此外，要採用自動化的方式作微服務端到端的部署。最好是除了代碼提交和最後灰度發佈，中間的全部環節都是自動化的。包括靜態掃描、單元測試、構建、製品管理、部署、部署後功能性測試和部署後非功能性測試。要在每一個代碼庫中作到必定的質量規範，以確保每個微服務上線質量都是有所保障的。

這樣就能夠經過自動化落地一個制度，避免人工執行中形成的疏漏和變形。咱們是經過「流水線即代碼」技術，把交付規範變成了一系列自動化的手段。並且採用了 git hook 的技術，在代碼提交前就作自動化測試，避免沒有通過測試的代碼提交到代碼庫上。

在微服務的開發過程當中，容易造成「隱性知識」，即只有少部分人知道的知識。

一個有效的方法是結對編程，但當你碰到項目時間截止、預算截止又加不了人的時候，可以砍掉第一個敏捷實踐就是結對編程。可是把眼光放長遠看，你會發現結對編程是利用的是短板原理。在你的團隊你跟別人面對面工做，若是你一我的工做，你的工做能力不足你是很難感覺到的。而和別人一結對，你的工做能力不足你就有了很清晰的認識。這可讓團隊成員向高水平的成員學習，不斷提升團隊的短板。而交付代碼的結果永遠是水平較高的那我的的。

而不採用結對編程的團隊通常就是末位淘汰制。這個很容易理解，但實際上這種制度只會浪費你們的時間。由於在這樣的組織裏遵循馬太效應，強者愈強，弱者愈弱，這不利於團隊的發展，特別是須要複製的微服務團隊。

另外須要說明的一點就是結對編程是很是辛苦但可以提高效率的方式，由於你在寫代碼的時候，始終有一我的盯着你，你沒有時間開小差，你全部時間都在思考、設計。若是你沒有這樣作的話就是對結對夥伴的不尊重，因此從另一種角度來看，結對編程其實是一種監督制度，讓對方監督來克服本身的惰性。工做的高效率就是這麼造成的。

單單有結對編程這一點是不夠的，還要作微服務團隊之間的交換結對（Switch Pair）。

咱們常常會出現一個問題，那就是咱們團隊有些人水平高，有些人水平低。水平高的人開發一些功能而後離職了，留下一個坑。可是這個風險每每是咱們忽視的，咱們作交接的時候每每交出去沒有接起來，而後又變成另一個坑。而結對編程是避免坑的有效的手段，可是必定要注意按期交換結對的夥伴。

爲何呢？持續交付裏面有一個很重要的原則叫作儘早並頻繁的作一些讓你感到痛苦的事情。若是一個團隊成員離職交接很痛苦，那每一天作一次交接。這就是結對編程和交換結對夥伴所作的事，由於每一次你作交換結對的的時候都進行了增量的交接，因此交接壓力很是小。可是若是某我的作了半年的系統須要交接，這個壓力則是很是大的，由於知識量不少。

從這個角度看，結對編程也是一種組織層面 Design for Failure：任何人的離開都不會對團隊的交付產出有大的影響。

另一個很重要的環節就是回顧會議。回顧會議很是重要，團隊要學會自我改進。特別是微服務團隊剛組建的時候，必定要養成覆盤的習慣，不然不少問題就會積累，拖累整個微服務團隊的工做節奏。這樣，咱們就能夠從一個週期中認識到問題，而且在下一個週期中落實改進。採用這種循環的方式不斷提高團隊的工做表現。

此外，你須要給團隊充分的受權，若是你不信任你的團隊，你的團隊也會用不信任的方法對待你。最重要的表現是各類「評審」和「審批」，你們的注意力都在流程上，而不在最終的結果上。最後的結局就是人浮於事，你們都在「作事情」但都沒「把事情作完」。

演進中的組織

在 Netflix 的微服務經驗中，Netflix 的工程師 R. Meshenberg 提出。微服務的落地須要各方面的配合和統一。這就意味着組織結構須要變化，這些變化的落地是困難的，並且這不是技術可以解決的問題。若是咱們有一個等級森嚴，權限隔離的制度，組織的創造性和生產力則會被權力所削弱。由於不少人都但願肯定性，避免不肯定性。長此以往，就會使一個系統變得很脆弱，而花更大的代價來維護系統的脆弱性。而不是構建一個反脆弱性的系統，使組織更加有彈性，能夠面對任何外在環境的變動。

你須要你的組織可以不斷自我演化可以面對各類挑戰。而組織結構的變化是每每是微服務落地困難中容易被忽視的一環成功的微服務的組織都是能夠自我演進的，它會自我調整並孕育出新的技術。最好的例子也是 Netflix，在他們開始決定作微服務轉型的時候，微服務，甚至是 DevOps 的概念尚未出現。然而，Netflix 的自動化和工程師文化，幫助他們成功的進行了技術轉型而成爲微服務應用中的楷模。

然而在組織和技術的相互演進中，咱們也走過了不少彎路。我也發現，愈來愈多應用微服務的團隊也會犯咱們曾經犯過的錯誤，下一篇咱們就來談談《微服務演進中的經驗和反思》。