一、前言
前一篇文章簡單分析了微服務的好處，以及會帶來的問題。
遇到問題並不可怕，可怕的是我們不去面對它，不去想辦法解決它，逃避問題是不可能有任何進步。所以積極想辦法應對問題並解決問題，才能不斷的進步。
前面講了，微服務一般都是由單體演進而來，很少有業務從0就開始進行微服務開發。如果能從0就開始用微服務開發，確實是一件很好的事情，前提是你確實考慮清楚了用微服務開發適合當前的業務以及業務的發展需求。
那麼問題來了，企業什麼時候引入微服務呢？
二、企業什麼時候引入微服務？
引入原因：
單體應用無法滿足業務增長的需求，業務的交付、業務的可靠性、穩定性要求，隨著時間推移問題會越來越多。-- 也就是前面遇到的一些問題
不過也有人，不是從本公司業務發展，開發成本，開發效率來考慮問題，而是什麼開發大會上看到很多公司微服務的演講，或者聽說很多公司在用微服務，從這些方面來考慮，也就是隨大流，這種思考方式顯然不是正確思考方式。不要為了微服務而微服務。採用微服務收益一定要大於單體應用，要能解決遇到的問題。
從單體架構升級到微服務架構，肯定希望提高研發效率，縮短工期，加快產品交付速度。
那他們在具體生產效率上有什麼區別？
根據馬丁·福勒（Martin Fowler）的這篇文章，揭示了生產率和複雜度的關係。
在複雜度較小時，單體應用的生產率更高，微服務架構反而降低了生產率。但是，當複雜度到了一定規模，無論採用單體應用還是微服務架構，都會降低系統的生產率。區別是：單體應用生產率開始急劇下降，而微服務架構則能緩解生產率下降的程度。如下圖：
x 軸是系統複雜度，y 軸是開發的生產力
- 綠色表示單體應用
- 藍色表示微服務架構
單體應用和微服務有一個相交的點，這個點是單體應用生產率急劇下降，微服務平緩下降的交叉點，他們的生產效率開始出現不同。
這個點就是把單體應用切換到微服務的時間點。
但問題是，這個時間點，文章並沒有具體說明什麼時候會出現，怎麼衡量這個時間點。
所以只能各個公司具體問題具體分析，技術領導者要考慮判斷這個時間點。這也是考慮技術領導力的時候。不過有些考慮要素可以參考：
- 業務交付
- 業務需求開發是否經常延遲
- 產品交付是否能跟上業務發展
- 研發質量
- 程式碼是否因為修改而經常出現bug
- 程式碼臃腫龐大
- 技術力量
- 有技術，有意願
- 團隊人數
等等一些考慮因素，在加上前一篇單體應用出現的一些問題。
在考慮清楚之後，決定引入微服務，那麼，又會遇到什麼問題？
三、組織架構如何變化？
康威定律
康威定律 (康威法則 , Conway's Law) 是馬爾文·康威1967年提出的：
設計系統的架構受制於產生這些設計的組織的溝通結構。
康威定律告訴我們，如果我們實施了微服務，那麼組織架構的變動也要跟著實施微服務架構而做出相應的調整。這樣才有可能適應微服務的發展。
單體架構和微服務架構
先看看傳統單體架構和微服務架構，如下圖：
左半部分的單體架構圖：
單體應用將所有功能放到一個程式中
擴充套件：通過將整個應用複製到多型伺服器實現擴充套件
右半部分的微服務架構圖：
微服務架構將功能分離，放到多個不同的程式中
擴充套件：通過將不同的服務分佈於不同的伺服器上，並按需要複製方式進行擴充套件
組織架構
- 單體應用的組織架構：
它是一個整體式的應用團隊，每個團隊按照職能來進行劃分（圖片左半部分），比如：UI團隊，中介軟體團隊，DBA團隊。
不同職能的人屬於不同的團隊。做專案的時候就從不同職能部門選出一些人來負責專案。這樣的組織架構有一個問題就是：跨職能部門溝通協調問題。這種團隊組織形式不能適應微服務架構的特點。
- 微服務應用組織架構
微服務架構特點：每個微服務是獨立的，團隊可以獨立開發，獨立測試，獨立部署，服務是自治的。相應的團隊組成人員也有產品，技術，測試，團隊成員在自己內部就可以完整的進行微服務各種功能開發。
這就要打破原先傳統的那種按職能劃分的組織團隊形式，而要把不同職能的人組織在一個團隊內，組成一個跨職能的產品組織架構。這樣才能把一個微服務功能架構、設計、開發、測試、部署、上線執行，在一個組織內部完成，從而形成完整的業務開發閉環。
團隊組織的變化
一圖勝千言：
圖片來自：https://insights.thoughtworks.cn/management-of-microservices-team/
原先那種職能型的團隊，變成了跨職能的小團隊，這種團隊和微服務架構對齊。
每個團隊組織成員多少合適呢？
亞馬遜的“兩個披薩團隊”，6-10人的規模。這個只是一種參考，畢竟每個公司規模、業務、行業、成員等不一樣，找到適合自己的團隊構成，就是最好的團隊組織。
說明： 以上圖片侵刪，請聯絡主頁郵箱！