微服務架構表現為元件化、子產品化，
每個元件或子產品稱為産品中的一個服務，
不同的服務由不同的人員來開發和維護，
進而規避傳統單體架構下面臨的各種問題，
實作疊代速度快、新人易上手、業務高可用等好處，
也是以，微服務架構成為企業數字化轉型更新的必備武器。
需要注意的是，
康威老爺子早已告誡我們：
系統設計等同于組織形式，
即團隊要适應業務系統的架構。
由于傳統單體應用和微服務架構差異巨大，
傳統企業的微服務實踐要取得成效，
組織架構的變革當然是必不可少的。
那麼，
成功的微服務化改造需要怎樣的組織架構呢？
首先，我們需要一種去中心化的組織架構，
因為單個服務的owner需要擁有對該服務的絕對自主權。
我們知道，微服務降低業務研發難度，
來自于其分而治之的基本思想，
一個大型系統分割成多個小而自治的服務，
支援每個服務采用不同的标準和技術來開發，
可以獨立修改、獨立部署而不影響其他服務的運作，
服務之間采用輕量級的通信機制。
回顧傳統單體應用的中心化架構，
小功能往往要積累到大版本才能上線，
上線又要開總監級别的大會，
微服務化之後，
如果仍然保持這種先請示後上線的組織架構，
是否上線、何時上線、選擇何種資料庫都需要高層決策，
那麼服務拆分的粒度越細，決策的瓶頸就越明顯。
采用去中心化的組織架構，
每一個服務由一個獨立、自治的小團隊開發和維護，
小團隊負責人自主決定服務的技術選擇和開發計劃，
微服務架構快速疊代的能力才能展現出來。
同時， 建立相應的機制來保證小團隊的主動性，
避免因為小團隊責任心不足而影響整個産品發展。
至于 小團隊的終極規模，
可以參考“兩個披薩原則”，
通常是5-7個人，
超過10人則考慮進一步分散。
但如同業務拆分很難一步到位，
團隊拆分也需要相應地逐漸拆分。
由于組織架構的變革會涉及各種利益關系，
管理層共識和第一推動力的前提是必不可少的，
可以成立專門的架構師（中間件）團隊執行微服務改造。
一來架構組可以勸說業務開發組和運維組實施微服務化，
二來微服務實踐是一個漸進過程而非一場運動，
一旦實施了微服務，
業務系統就處于不斷更新和疊代的狀态中，
也處于不斷的拆分群組合中，
架構組可以專心打造适合業務的、可靠的中間件，
比如消息隊列、緩存等，
幫助企業更好地hold住這個演進的過程。
業務相對簡單或者人力不足的企業也可以沒有架構組，
不過中間件還要依賴于成熟第三方平台。
伴随着組織架構的去中心化，
全權負責每一個服務的小團隊必須是全能的，
或者說是全棧的，
搞得定使用者互動UI設計、背景服務開發，
做得了資料庫管理、服務營運和運維等，
惟其如此，才能實作服務自治。
傳統組織往往是一種職能型組織結構，
也稱為U型組織，
不同職能人員分别隸屬于不同的團隊，
比如産品、開發、測試、運維團隊之間彼此獨立。
U型組織下跨部門溝通協調成本很高，
産品需求實作和使用回報的鍊路都很長，
即便管理層把權力下放了，
疊代效率也不高，還容易出問題，
對軟體傳遞并不友好。
是以，
為每一個服務設定一個專屬的全能小團隊，
由産品、開發和測試人員負責服務的疊代開發，
DBA和運維人員提供平台化的CI/CD、治理等底層支援，
這是微服務架構的呼喚。
全能小團隊和傳統的項目組有聚有散不同，
因為微服務長久存在而需要長期穩固的合作。
網易很早就采用一種專人就位的職能支撐模式，
由各個職能部門教育訓練并安排專人入駐各個産品組，
同時確定崗位人員的專業性和産品團隊的溝通效率，
通過這種方式成功孵化了大量的網際網路産品，
這是傳統企業在服務化改造過程中可以效仿的。
全能也還不夠，微服務還意味着需要組織DevOps化。
微服務意味着更多的并行開發、更頻繁的釋出和部署，
意味着更高的整體複雜度，
這時候打通組織和流程實作DevOps是不能少的。
開發團隊和運維團隊如果不能精誠協作，
還是沿襲傳統的工作模式，
一個隻管開發、建構、測試，
一個隻顧提供資源、部署、運維，
運維團隊還是背鍋俠，
微服務業務還是沒有辦法高效地上線部署運作的。
組織DevOps化，即需要開發與運維融合，
不同服務、不同版本的傳遞環境需要開發來寫，
因為運維對不同子產品的不同配置及更新不熟悉，
很容易出現部署出錯的情況，影響業務正常上線；
而服務注冊、發現、治理、配置等，
每一個業務單獨一套架構是不科學的，
應當下沉成為運維團隊統一管理的基礎設施。
是以開發團隊和運維團隊的工作都有變化，
好在成熟的容器技術提供了融合的工具。
組織DevOps化的最大變化，
是開發團隊需要完成環境配置的工作，
而運維團隊需要将微服務通用能力平台化。
對于開發而言，
寫個Dockerfile說明容器内部的運作環境，
僅僅是工作量增加5%的問題，難度不大。
對于運維而言，
灰階釋出、自動化測試運維、故障自愈等工作就複雜了，
對于使用者衆多、功能複雜的大型業務尤其如此，
容器管理編排體系成為了基礎，
順暢的持續內建/持續傳遞能力是不可或缺的内功，
這些都需要打造給力的工具平台來支援。
滿足全能團隊需求的當然是完備的微服務平台，
容器化、DevOps、服務治理、監控、自動化測試統統搞定。
舉個例子，
網易杭州研究院就是一個典型的DevOps組織，
整個分工界面簡化如圖，
雲計算資料中心由運維部門來管理，
上面是雲計算平台組，
該組基于OpenStack開發了租戶可自助操作的雲平台；
雲平台包括了PaaS、容器、微服務管理和治理等元件，
PaaS元件點選可得，提供SLA保障；
容器元件提供容器管理、持續內建、持續部署的工具鍊；
微服務元件支援業務部門進行微服務的開發；
中間件組或者說架構組和雲平台組溝通密切，
共同探讨如何以正确的姿勢使用雲平台元件；
最上面是業務部門的前端組、業務開發組和中台開發組。
DevOps化、建成微服務平台之後，
大規模的業務中台化便可提上日程。
大家可能難以了解網易案例中的“中台開發組”，
其實，
傳統企業也有元件化、子產品化開發模式，
實施應用架構微服務化改造之後，
可複用的元件就可以變成一個個服務，
并被注冊到微服務平台的注冊中心，
企業可以從業務開發組分離出幾個中台開發組，
負責将可複用的能力和代碼做成現成的中台服務，
提供給業務系統開發團隊使用。
這樣操作，
一來資料模型會統一，
資料共享和後續分析挖掘都更友善，
二來業務開發組不需要全部從零開始，
業務系統開發效率可以再上一個台階。
網易最近幾年在不同領域迅速推出各種新産品，
背後的中台能力功不可沒。
企業微服務化改造的收益和挑戰都是巨大的，
組織架構如果能夠做出合适的調整，
走向去中心化、小團隊化、全能化和DevOps化，
以适應微服務架的特點，
微服務的收益将會大于成本，
并且收益會逐漸遞增，而成本會遞減。
相信越來越多的企業都能從微服務架構中獲益。
點選了解網易雲輕舟微服務，擷取方案
相關文章：
【推薦】 關于Runtime.getRuntime().exec()産生阻塞的2個陷阱
【推薦】 windows系統下npm更新的正确姿勢以及原理
【推薦】 從需求到資料到改進，如何形成閉環