微服務架構學習系列文章：
- 微服務架構學習與思考(01)：什么是微服務？微服務的優勢和劣勢
- 微服務架構學習與思考(02)：微服務實施的前提條件？有哪些問題需要思考？
- 微服務架構學習與思考(03)：微服務總體架構圖解
- 微服務架構學習與思考(04)：微服務技術體系
- 微服務架構學習與思考(05)：微服務架構適用場景分析
一、前言
“地址：https://www.cnblogs.com/jiujuan/p/13284412.html
前一篇文章簡單分析了微服務的好處，以及會帶來的問題。
遇到問題並不可怕，可怕的是我們不去面對它，不去想辦法解決它，逃避問題是不可能有任何進步。所以積極想辦法應對問題並解決問題，才能不斷的進步。
前面講了，微服務一般都是由單體演進而來，很少有業務從0就開始進行微服務開發。如果能從0就開始用微服務開發，確實是一件很好的事情，前提是你確實考慮清楚了用微服務開發適合當前的業務以及業務的發展需求。
那么問題來了，企業什么時候引入微服務呢？
二、企業什么時候引入微服務？
引入原因：
“單體應用無法滿足業務增長的需求，業務的交付、業務的可靠性、穩定性要求，隨着時間推移問題會越來越多。-- 也就是前面遇到的一些問題
“不過也有人，不是從本公司業務發展，開發成本，開發效率來考慮問題，而是什么開發大會上看到很多公司微服務的演講，或者聽說很多公司在用微服務，從這些方面來考慮，也就是隨大流，這種思考方式顯然不是正確思考方式。不要為了微服務而微服務。采用微服務收益一定要大於單體應用，要能解決遇到的問題。
從單體架構升級到微服務架構，肯定希望提高研發效率，縮短工期，加快產品交付速度。
那他們在具體生產效率上有什么區別？
根據馬丁·福勒（Martin Fowler）的這篇文章，揭示了生產率和復雜度的關系。 在復雜度較小時，單體應用的生產率更高，微服務架構反而降低了生產率。但是，當復雜度到了一定規模，無論采用單體應用還是微服務架構，都會降低系統的生產率。區別是：單體應用生產率開始急劇下降，而微服務架構則能緩解生產率下降的程度。如下圖： 
x 軸是系統復雜度，y 軸是開發的生產力
-
綠色表示單體應用 -
藍色表示微服務架構
單體應用和微服務有一個相交的點，這個點是單體應用生產率急劇下降，微服務平緩下降的交叉點，他們的生產效率開始出現不同。
這個點就是把單體應用切換到微服務的時間點。
但問題是，這個時間點，文章並沒有具體說明什么時候會出現，怎么衡量這個時間點。 所以只能各個公司具體問題具體分析，技術領導者要考慮判斷這個時間點。這也是考慮技術領導力的時候。不過有些要素可以參考：
-
業務角度 -
業務需求開發是否經常延遲 -
產品交付是否能跟上業務發展
-
-
研發質量 -
代碼是否因為修改而經常出現bug -
代碼臃腫龐大
-
-
技術人員 -
有技術，有意願 -
團隊人數
-
等等一些考慮因素，在加上前一篇單體應用出現的一些問題。
在考慮清楚之后，決定引入微服務，那么，又會遇到什么問題？
三、組織架構如何變化？
康威定律
“康威定律 (康威法則 , Conway's Law) 是馬爾文·康威1967年提出的： 設計系統的架構受制於產生這些設計的組織的溝通結構。
康威定律告訴我們，如果我們實施了微服務，那么組織架構的變動也要跟着實施微服務架構而做出相應的調整。這樣才有可能適應微服務的發展。
單體架構和微服務架構
先看看傳統單體架構和微服務架構，如下圖： 
“圖片來自：https://martinfowler.com/articles/microservices.html
左半部分的單體架構圖： 單體應用將所有功能放到一個進程中 擴展：通過將整個應用復制到多態服務器實現擴展
右半部分的微服務架構圖： 微服務架構將功能分離，放到多個不同的進程中 擴展：通過將不同的服務分布於不同的服務器上，並按需要復制方式進行擴展
組織架構
-
單體應用的組織架構： 
“圖片來自：https://martinfowler.com/articles/microservices.html
它是一個整體式的應用團隊，每個團隊按照職能來進行划分（圖片左半部分），比如：UI團隊，中間件團隊，DBA團隊。
不同職能的人屬於不同的團隊。做項目的時候就從不同職能部門選出一些人來負責項目。這樣的組織架構有一個問題就是：跨職能部門溝通協調問題。這種團隊組織形式不能適應微服務架構的特點。
-
微服務應用組織架構 
“圖片來自：https://martinfowler.com/articles/microservices.html
微服務架構特點：每個微服務是獨立的，團隊可以獨立開發，獨立測試，獨立部署，服務是自治的。相應的團隊組成人員也有產品，技術，測試，團隊成員在自己內部就可以完整的進行微服務各種功能開發。
這就要打破原先傳統的那種按職能划分的組織團隊形式，而要把不同職能的人組織在一個團隊內，組成一個跨職能的產品組織架構。這樣才能把一個微服務功能架構、設計、開發、測試、部署、上線運行，在一個組織內部完成，從而形成完整的業務、開發、交付閉環。
團隊組織的變化
一圖勝千言：
“圖片來自：https://insights.thoughtworks.cn/management-of-microservices-team/
原先那種職能型的團隊，變成了跨職能的小團隊，這種團隊和微服務架構對齊。
每個團隊組織成員多少合適呢？ 亞馬遜的“兩個披薩團隊”，6-10人的規模。這個只是一種參考，畢竟每個公司規模、業務、行業、成員等不一樣，找到適合自己的團隊構成，就是最好的團隊組織。
“說明： 以上圖片侵刪，請聯系主頁郵箱！
四、基礎設施建設
這里的基礎設施建設，指的是以 CI/CD 為基礎的自動化交付流水線，到最后建設成從開發、測試、預發布、上線、運維等整個研發流程自動化的 DevOps 為目標。
因為隨着微服務的逐步建設，服務數量增多，上線服務次數必然增多，交付頻繁會帶來故障次數增多，所以我們必須建設自動化的工具鏈，來幫助我們快速無誤的交付服務，實施好微服務項目。
五、怎么構建第一個微服務項目
-
第一種：有新項目，可以從0開始設計微服務架構。
-
第二種：改造舊有的老項目 這種也可以划分2類：
-
從項目小范圍開始試水，進行改造。 -
完全重構項目 - 一般 不推薦這種方式。因為不僅老項目需要維護，而且來了新需求咋辦？是老項目停止需求開發，還是新舊一起加，一起加又浪費人力，不加技術跟不上業務發展。這些風險都是需要思考衡量。
-
-
第三種：從邊緣不重要的小項目開始。
這種項目需求開發一般不緊迫，項目又小，相對獨立，與現有系統耦合較小，可以完全重構。從這種小項目開始實施微服務，一步一步來構建，降低風險。
經驗豐富后，在逐步將其他項目進行改造。 這種是折中的辦法，不是那種“休克療法”。