微服務架構學習系列文章：
- 微服務架構學習與思考(01)：什么是微服務？微服務的優勢和劣勢
- 微服務架構學習與思考(02)：微服務實施的前提條件？有哪些問題需要思考？
- 微服務架構學習與思考(03)：微服務總體架構圖解
- 微服務架構學習與思考(04)：微服務技術體系
- 微服務架構學習與思考(05)：微服務架構適用場景分析
- 微服務架構學習與思考(06)：如何構建微服務？
- 微服務架構學習與思考(07)：企業團隊組織架構如何變革？
單體到微服務架構的團隊變化
傳統的單體架構時期，多數企業是按照功能來划分團隊人員。大家都在一個單體架構上進行功能開發。
到了微服務架構時期，利用分治的思想把業務划分為了一個一個小的服務，每個開發團隊獨立負責幾個微服務的業務，這時候團隊組成人員也要進行相應的調整，以適應微服務架構的開發。
因為康威老爺子說過：
系統架構設計等同於組織形式，即團隊組織要適應業務系統的架構。
我們要把以前那種中心化的組織架構，改成去中心化的組織，每個團隊可以獨立完成一個微服務業務的開發上線，即設計，開發，測試，部署，上線服務。
每個團隊可以獨立修改，獨立部署服務而不影響其他服務運行。
每一個服務由一個獨立的、自治的小團隊開發和維護。
康威定律
康威定律 (康威法則 , Conway's Law) 是馬爾文·康威1967年提出的：
設計系統的架構受制於產生這些設計的組織的溝通結構。
康威定律告訴我們，如果我們實施了微服務，那么組織架構的變動也要跟着實施微服務架構而做出相應的調整。這樣才有可能適應微服務的發展。
單體架構和微服務架構
先看看傳統單體架構和微服務架構，如下圖：
左半部分的單體架構圖：
單體應用將所有功能放到一個進程中
擴展：通過將整個應用復制到多態服務器實現擴展
右半部分的微服務架構圖：
微服務架構將功能分離，放到多個不同的進程中
擴展：通過將不同的服務分布於不同的服務器上，並按需要復制方式進行擴展
組織架構
- 單體應用的組織架構：
它是一個整體式的應用團隊，每個團隊按照職能來進行划分（圖片左半部分），比如：UI團隊，中間件團隊，DBA團隊。
不同職能的人屬於不同的團隊。做項目的時候就從不同職能部門選出一些人來負責項目。這樣的組織架構有一個問題就是：跨職能部門溝通協調問題。這種團隊組織形式不能適應微服務架構的特點。
- 微服務應用組織架構
微服務架構特點：每個微服務是獨立的，團隊可以獨立開發，獨立測試，獨立部署，服務是自治的。相應的團隊組成人員也有產品，技術，測試，團隊成員在自己內部就可以完整的進行微服務各種功能開發。
這就要打破原先傳統的那種按職能划分的組織團隊形式，而要把不同職能的人組織在一個團隊內，組成一個跨職能的產品組織架構。這樣才能把一個微服務功能架構、設計、開發、測試、部署、上線運行，在一個組織內部完成，從而形成完整的業務、開發、交付閉環。
團隊組織的變化
一圖勝千言：
圖片來自：https://insights.thoughtworks.cn/management-of-microservices-team/
原先那種職能型的團隊，變成了跨職能的小團隊，這種團隊和微服務架構對齊，實現團隊的獨立和自治，實現一體化開發上線操作。
一個團隊成員多少合適
每個團隊組織成員多少合適呢？
亞馬遜的“兩個披薩團隊”，6-10人的規模。這個只是一種參考，畢竟每個公司規模、業務、行業、成員等不一樣，找到適合自己的團隊構成，就是最好的團隊組織。
組織架構變化的困難
一個組織架構的變化，會涉及到團隊人員的減少或增加，職務上的變化，業務開發上的變化等，這就涉及到各種利益關系。
為了減少推動組織變化所帶來的阻力，公司領導和開發人員，還有業務相關人員要達成廣泛的共識，技術高管需要在公司內進行積極的宣講、開會討論等，以求達成廣泛的共識。
為了順利推進組織架構的變化，以適應微服務架構的發展，至少要做到以下2點：
- 1、各級管理層必須達成共識，由高層領導直接推動組織架構變化。
- 2、由CTO(或技術高管)牽頭成立架構委員會，執行微服務架構的設計和改造。