成功的微服務，須要企業組織架構如何變革？

微服務架構表現爲組件化、模塊化，
每一個組件或模塊稱爲產品中的一個服務，
不一樣的服務由不一樣的人員來開發和維護，
從而規避傳統單體架構下面臨的各類問題，
實現迭代速度快、新人易上手、業務高可用等好處，
也所以，微服務架構成爲企業數字化轉型升級的必備武器。

須要注意的是，
康威老爺子早已告誡咱們：
系統設計等同於組織形式，
即團隊要適應業務系統的架構。

因爲傳統單體應用和微服務架構差別巨大，
傳統企業的微服務實踐要取得成效，
組織架構的變革固然是必不可少的。
那麼，
成功的微服務化改造須要怎樣的組織架構呢？

匹配微服務：從中心化到去中心化

首先，咱們須要一種去中心化的組織架構， 
由於單個服務的owner須要擁有對該服務的絕對自主權。 
咱們知道，微服務下降業務研發難度， 
來自於其分而治之的基本思想， 
一個大型系統分割成多個小而自治的服務， 
支持每一個服務採用不一樣的標準和技術來開發， 
能夠獨立修改、獨立部署而不影響其餘服務的運行， 
服務之間採用輕量級的通訊機制。 
 
回顧傳統單體應用的中心化架構， 
小功能每每要積累到大版本才能上線， 
上線又要開總監級別的大會， 
微服務化以後， 
若是仍然保持這種先請示後上線的組織架構， 
是否上線、什麼時候上線、選擇何種數據庫都須要高層決策， 
那麼服務拆分的粒度越細，決策的瓶頸就越明顯。 
採用去中心化的組織架構， 
每個服務由一個獨立、自治的小團隊開發和維護， 
小團隊負責人自主決定服務的技術選擇和開發計劃， 
微服務架構快速迭代的能力才能體現出來。 
同時， 創建相應的機制來保證小團隊的主動性， 
避免由於小團隊責任心不足而影響整個產品發展。 
至於 小團隊的終極規模，
能夠參考「兩個披薩原則」， 
一般是5-7我的， 
超過10人則考慮進一步分散。

但如同業務拆分很難一步到位，
團隊拆分也須要相應地逐步拆分。
須要注意的是，
因爲組織架構的變革會涉及各類利益關係，
管理層共識和第一推進力的前提是必不可少的，
能夠成立專門的架構師（中間件）團隊執行微服務改造。
一來架構組能夠勸說業務開發組和運維組實施微服務化，
二來微服務實踐是一個漸進過程而非一場運動，
一旦實施了微服務，
業務系統就處於不斷更新和迭代的狀態中，
也處於不斷的拆分和組合中，
架構組能夠專心打造適合業務的、可靠的中間件，
好比消息隊列、緩存等，
幫助企業更好地hold住這個演進的過程。

業務相對簡單或者人力不足的企業也能夠沒有架構組，
不過中間件還要依賴於成熟第三方平臺。

搞定微服務：從U型組織到全能小團隊

伴隨着組織架構的去中心化，
全權負責每個服務的小團隊必須是全能的，
或者說是全棧的， 
搞得定用戶交互UI設計、後臺服務開發， 
作得了數據庫管理、服務運營和運維等， 
唯其如此，才能實現服務自治。 
傳統組織每每是一種職能型組織結構， 
也稱爲U型組織， 
不一樣職能人員分別隸屬於不一樣的團隊， 
好比產品、開發、測試、運維團隊之間彼此獨立。 
U型組織下跨部門溝通協調成本很高， 
產品需求實現和使用反饋的鏈路都很長， 
即使管理層把權力下放了， 
迭代效率也不高，還容易出問題， 
對軟件交付並不友好。 
因此， 
爲每個服務設置一個專屬的全能小團隊， 
由產品、開發和測試人員負責服務的迭代開發， 
DBA和運維人員提供平臺化的CI/CD、治理等底層支持， 
這是微服務架構的呼喚。 
全能小團隊和傳統的項目組有聚有散不一樣， 
由於微服務長久存在而須要長期穩固的合做。 
網易很早就採用一種專人就位的職能支撐模式， 
由各個職能部門培訓並安排專人入駐各個產品組， 
同時確保崗位人員的專業性和產品團隊的溝通效率， 
經過這種方式成功孵化了大量的互聯網產品， 
這是傳統企業在服務化改造過程當中能夠效仿的。 

玩轉微服務：從運維背鍋到DevOps組織

全能也還不夠，微服務還意味着須要組織DevOps化。 
微服務意味着更多的並行開發、更頻繁的發佈和部署， 
意味着更高的總體複雜度， 
這時候打通組織和流程實現DevOps是不能少的。 
 
開發團隊和運維團隊若是不能精誠協做， 
仍是沿襲傳統的工做模式， 
一個只管開發、構建、測試， 
一個只顧提供資源、部署、運維， 
運維團隊仍是背鍋俠， 
微服務業務仍是沒有辦法高效地上線部署運行的。 
組織DevOps化，即須要開發與運維融合， 
不一樣服務、不一樣版本的交付環境須要開發來寫， 
由於運維對不一樣模塊的不一樣配置及更新不熟悉， 
很容易出現部署出錯的狀況，影響業務正常上線； 
而服務註冊、發現、治理、配置等， 
每個業務單獨一套框架是不科學的， 
應當下沉成爲運維團隊統一管理的基礎設施。 
因此開發團隊和運維團隊的工做都有變化， 
好在成熟的容器技術提供了融合的工具。

組織DevOps化的最大變化，
是開發團隊須要完成環境配置的工做，
而運維團隊須要將微服務通用能力平臺化。

對於開發而言，
寫個Dockerfile說明容器內部的運行環境，
僅僅是工做量增長5%的問題，難度不大。
對於運維而言，
灰度發佈、自動化測試運維、故障自愈等工做就複雜了，
對於用戶衆多、功能複雜的大型業務尤爲如此，
容器管理編排體系成爲了基礎，
順暢的持續集成/持續交付能力是不可或缺的內功，
這些都須要打造給力的工具平臺來支持。
知足全能團隊需求的固然是完備的微服務平臺，
容器化、DevOps、服務治理、監控、自動化測試通通搞定。
舉個例子，
網易杭州研究院就是一個典型的DevOps組織，
整個分工界面簡化如圖，

雲計算數據中心由運維部門來管理，
上面是雲計算平臺組，
該組基於OpenStack開發了租戶可自助操做的雲平臺；
雲平臺包括了PaaS、容器、微服務管理和治理等組件，
PaaS組件點擊可得，提供SLA保障；
容器組件提供容器管理、持續集成、持續部署的工具鏈；
微服務組件支持業務部門進行微服務的開發；
中間件組或者說架構組和雲平臺組溝通密切，
共同探討如何以正確的姿式使用雲平臺組件；
最上面是業務部門的前端組、業務開發組和中臺開發組。

享受微服務：構建中臺團隊

DevOps化、建成微服務平臺以後，
大規模的業務中臺化即可提上日程。 
你們可能難以理解網易案例中的「中臺開發組」， 
其實， 
傳統企業也有組件化、模塊化開發模式， 
實施應用架構微服務化改造以後， 
可複用的組件就能夠變成一個個服務， 
並被註冊到微服務平臺的註冊中心， 
企業能夠從業務開發組分離出幾個中臺開發組， 
負責將可複用的能力和代碼作成現成的中臺服務， 
提供給業務系統開發團隊使用。 
這樣操做， 
一來數據模型會統一， 
數據共享和後續分析挖掘都更方便， 
二來業務開發組不須要所有從零開始， 
業務系統開發效率能夠再上一個臺階。 
網易最近幾年在不一樣領域迅速推出各類新產品， 
背後的中臺能力功不可沒。 

總結

企業微服務化改造的收益和挑戰都是巨大的， 
組織架構若是可以作出合適的調整， 
走向去中心化、小團隊化、全能化和DevOps化， 
以適應微服務架的特色， 
微服務的收益將會大於成本， 
而且收益會逐步遞增，而成本會遞減。 
相信愈來愈多的企業都能從微服務架構中獲益。

點擊瞭解網易雲輕舟微服務，獲取方案  

相關文章：
【推薦】 關於Runtime.getRuntime().exec()產生阻塞的2個陷阱
【推薦】 windows系統下npm升級的正確姿式以及原理
【推薦】 從需求到數據到改進，如何造成閉環