看到最近「微服務架構」這個概念這麼火，做爲一個積極上進的程序猿，成小胖忍不住想要學習學習。而架構師老王（不是隔壁老王）最近恰好在作公司基礎服務的微服務化研究和落地，對此深有研究。java
因而成小胖立刻屁顛屁顛的跑過去向老王請教：「王哥，我看微服務架構這麼火，我也想學，您給我講講啥是微服務架構唄？」數據庫
老王笑了笑說：「要想知道什麼是微服務架構，你得先知道什麼系統架構設計。」服務器
成小胖的理想是成爲一名架構師，平時積累了很多知識，所以對「系統架構設計」這個概念仍是很熟悉的，所以他立刻就給出了答案【1】：網絡
系統架構設計描述了在應用系統的內部，如何根據業務、技術、組織、靈活性、可擴展性以及可維護性等多種因素，將應用系統劃分紅不一樣的部分，並使這些部分彼此之間相互分工、相互協做，從而爲用戶提供某種特定的價值的方式。架構
老王滿意的點點頭，繼續問：「你看最近我在作微服務的研究和落地，你知道爲何要作這個事情嗎？」框架
「由於目前的三層架構存在不少弊端，不知足業務發展的需求了唄。」運維
「對的，我看你對公司目前的架構也很是熟悉了，你來仔細說說如今的三層架構吧。」異步
因而成小胖拿了一張A4紙，圖文並茂地給老王講了他對三層架構的理解：
三層架構是指在業務和技術的發展過程當中，系統中不一樣職責的部分被定義在不一樣的層次，每一層負責的功能更加具體化。三層架構一般包括表示層、業務邏輯層和數據訪問層，層與層之間互相鏈接、互相協做，構成一個總體，而且層的內部能夠被替換成其餘能夠工做的部分，但對總體的影響不大。分佈式
以 Web 應用程序爲例，早期是將全部的表示邏輯、業務邏輯和數據訪問邏輯放在一塊兒，這就是一層架構。微服務
後來隨着 java、.NET 等高級語言的發展，提供了愈來愈方便的數據訪問機制，如 java 的 JDBC 和 .NET 的 ADO.NET。這時數據訪問部分被分離開來，造成了二層架構。
再後來，隨着面向對象設計、企業架構模式等理念的不斷髮展，表示邏輯和業務邏輯也被分離開來，造成了如今的三層架構。
三層架構的具體內容以下：
- 表示層： 用戶使用應用程序時，看到的、聽見的、輸入的或者交互的部分。
- 業務邏輯層： 根據用戶輸入的信息，進行邏輯計算或者業務處理的部分。
- 數據訪問層： 關注有效地操做原始數據的部分，如將數據存儲到存儲介質（如數據庫、文件系統）及從存儲介質中讀取數據等。
老王對這個解釋很是滿意，做了進一步的補充：「你看雖然如今程序被分紅了三層，但只是邏輯上的分層，並非物理上的分層。也就是說，對不一樣層的代碼而言，通過編譯、打包和部署後，全部的代碼最終仍是運行在同一個進程中。而這，就是所謂的單塊架構。」
成小胖撓了撓頭：「原來單塊架構是這個意思啊~~」
「嗯。根據你的實際工做經驗，你再總結下單塊架構的優缺點吧。」
平時勤於總結的成小胖很快便列出了單塊架構的優缺點：
優勢：
- 易於開發： 開發方式簡單，IDE 支持好，方便運行和調試。
- 易於測試： 全部功能運行在一個進程中，一旦進程啓動，即可以進行系統測試。
- 易於部署： 只須要將打好的一個軟件包發佈到服務器便可。
- 易於水平伸縮： 只須要建立一個服務器節點，配置好運行時環境，再將軟件包發佈到新服務器節點便可運行程序（固然也須要採起分發策略保證請求能有效地分發到新節點）。
缺點：
- 維護成本大： 當應用程序的功能愈來愈多、團隊愈來愈大時，溝通成本、管理成本顯著增長。當出現 bug 時，可能引發 bug 的緣由組合愈來愈多，致使分析、定位和修復的成本增長；而且在對全局功能缺少深度理解的狀況下，容易在修復 bug 時引入新的 bug。
- 持續交付週期長： 構建和部署時間會隨着功能的增多而增長，任何細微的修改都會觸發部署流水線。
- 新人培養週期長： 新成員瞭解背景、熟悉業務和配置環境的時間愈來愈長。
- 技術選型成本高： 單塊架構傾向於採用統一的技術平臺或方案來解決全部問題，若是後續想引入新的技術或框架，成本和風險都很大。
- 可擴展性差： 隨着功能的增長，垂直擴展的成本將會愈來愈大；而對於水平擴展而言，由於全部代碼都運行在同一個進程，沒辦法作到針對應用程序的部分功能作獨立的擴展。
老王拍了拍成小胖的肩膀，眼睛眯成了一條縫：「小夥子總結的很不錯！既然你已經對目前的單塊架構的優缺點有了很好的理解，那如今我們就能夠開始來學習微服務架構了。」
老王先從網上搜索「微服務架構」關鍵字，出來這麼一段話：
微服務架構是一種架構模式，它提倡將單一應用程序劃分紅一組小的服務，服務之間互相協調、互相配合，爲用戶提供最終價值。每一個服務運行在其獨立的進程中，服務於服務間採用輕量級的通訊機制互相溝通（一般是基於 HTTP 的 RESTful API）。每一個服務都圍繞着具體業務進行構建，而且可以被獨立地部署到生產環境、類生產環境等。另外，應儘可能避免統一的、集中式的服務管理機制，對具體的一個服務而言，應根據業務上下文，選擇合適的語言、工具對其進行構建。
成小胖看完了這段話，說：「看着有點暈，雲裏霧裏的感受……」
老王嘿嘿一笑：「莫慌，如今就給你詳細講講微服務架構的特性。」
1. 單一職責
微服務架構中的每一個服務，都是具備業務邏輯的，符合高內聚、低耦合原則以及單一職責原則的單元，不一樣的服務經過「管道」的方式靈活組合，從而構建出龐大的系統。
2. 輕量級通訊
服務之間經過輕量級的通訊機制實現互通互聯，而所謂的輕量級，一般指語言無關、平臺無關的交互方式。
對於輕量級通訊的格式而言，咱們熟悉的 XML 和 JSON，它們是語言無關、平臺無關的；對於通訊的協議而言，一般基於 HTTP，能讓服務間的通訊變得標準化、無狀態化。目前你們熟悉的 REST（Representational State Transfer）是實現服務間互相協做的輕量級通訊機制之一。使用輕量級通訊機制，可讓團隊選擇更適合的語言、工具或者平臺來開發服務自己。
3. 獨立性
每一個服務在應用交付過程當中，獨立地開發、測試和部署。
在單塊架構中全部功能都在同一個代碼庫，功能的開發不具備獨立性；當不一樣小組完成多個功能後，須要通過集成和迴歸測試，測試過程也不具備獨立性；當測試完成後，應用被構建成一個包，若是某個功能存在 bug，將致使整個部署失敗或者回滾。
在微服務架構中，每一個服務都是獨立的業務單元，與其餘服務高度解耦，只須要改變當前服務自己，就能夠完成獨立的開發、測試和部署。
4. 進程隔離
單塊架構中，整個系統運行在同一個進程中，當應用進行部署時，必須停掉當前正在運行的應用，部署完成後再重啓進程，沒法作到獨立部署。
有時候咱們會將重複的代碼抽取出來封裝成組件，在單塊架構中，組件一般的形態叫作共享庫（如 jar 包或者 DLL），可是當程序運行時，全部組件最終也會被加載到同一進程中運行。
在微服務架構中，應用程序由多個服務組成，每一個服務都是高度自治的獨立業務實體，能夠運行在獨立的進程中，不一樣的服務能很是容易地部署到不一樣的主機上。
理論上全部服務能夠部署在同一個服務器節點，可是並不推薦這麼作，由於微服務架構的主旨就是高度自治和高度隔離。
「王哥你真厲害，您這麼一說個人思惟清晰了不少！」成小胖激動的幾乎要叫起來。
「我以前瞭解過 SOA，好像跟微服務架構的思想很像啊，您能幫我區分一下嗎？」成小胖追問到。
老王嘿嘿一笑，拿起成小胖手上的A4紙，翻到另一面畫了個表格：
| SOA實現 | 微服務架構實現 |
| 企業級，自頂向下開展實施 | 團隊級，自底向上開展實施 |
| 服務由多個子系統組成，粒度大 | 一個系統被拆分紅多個服務，粒度細 |
| 企業服務總線，集中式的服務架構 | 無集中式總線，鬆散的服務架構 |
| 集成方式複雜（ESB/WS/SOAP） | 集成方式簡單（HTTP/REST/JSON） |
| 單塊架構系統，相互依賴，部署複雜 | 服務能獨立部署 |
接着老王又畫了一張圖：
成小胖看了以後說：「您這麼一畫我卻是大概明白了，可是圖裏面的 DevOps 這個概念我不懂誒……」
「這個 DevOps 就說來話長了，有時間你本身先去查查資料瞭解下吧。」
「好的。如今我對微服務架構的概念有了瞭解，您能再深刻剖析下它的本質嗎？」
「好，你可仔細聽好了哈！」
1. 服務做爲組件
微服務也能夠被認爲是一種組件，可是跟傳統組件的區別在於它能夠獨立部署，所以它的一個顯著的優點。另一個優勢是，它在組件與組件之間定義了清晰的、語言無關、平臺無關的規範接口，耦合度低，靈活性很是高。但它的不足之處是，分佈式調用嚴重依賴於網絡的可靠性和穩定性。
2. 圍繞業務組織團隊
在單塊架構中，企業通常會根據技能劃分團隊，在這種組織架構下，即使是簡單的需求變動都有可能須要跨團隊協做，溝通成本很高。而在微服務架構中，它提倡以業務爲核心，按照業務能力來組織團隊，團隊中的成員具備多樣性的技能。
3. 關注產品而非項目
在單塊架構中，應用基本上是基於「項目模式」構建的，即項目啓動時從不一樣技能資源池中抽取相關資源組成團隊，項目結束後釋放全部資源。這種狀況下團隊成員缺少主人翁意識和產品成就感。
在微服務架構中，提倡採用「產品模式」構建，即更傾向於讓團隊負責整個服務的生命週期，以便提供更優質的服務。
4. 技術多樣性
微服務架構中，提倡針對不一樣的業務特徵選擇合適的技術方案，有針對性的解決具體業務問題，而不是像單塊架構中採用統一的平臺或技術來解決全部問題。
5. 業務數據獨立
微服務架構提供自主管理其相關的業務數據，這樣能夠隨着業務的發展提供數據接口集成，而不是以數據庫的方式同其餘服務集成。另外，隨着業務的發展，能夠方便地選擇更合的工具管理或者遷移業務數據。
6. 基礎設施自動化
在微服務架構的實踐過程當中，對持續交付和部署流水線的要求很高，將促進企業不斷尋找更高效的方式完成基礎設施的自動化及 DevOps 運維能力的提高。
聽完成小胖忍不住表達了敬佩之意：「老司機就是老司機，噢說錯了……架構師就是架構師，總結得這麼簡潔又深入！」
「咳咳，低調低調……」
「聽您講解了這麼多，我以爲微服務架構解決了不少當前三層架構的痛點。不過我以爲沒有任何一項技術或架構是完美的。」
「很是正確。進行微服務架構的落地是存在不少挑戰的。」
1. 分佈式系統的複雜性
微服務架構是基於分佈式的系統，而構建分佈式系統必然會帶來額外的開銷。
- 性能： 分佈式系統是跨進程、跨網絡的調用，受網絡延遲和帶寬的影響。
- 可靠性： 因爲高度依賴於網絡情況，任何一次的遠程調用都有可能失敗，隨着服務的增多還會出現更多的潛在故障點。所以，如何提升系統的可靠性、下降因網絡引發的故障率，是系統構建的一大挑戰。
- 異步： 異步通訊大大增長了功能實現的複雜度，而且伴隨着定位難、調試難等問題。
- 數據一致性： 要保證分佈式系統的數據強一致性，成本是很是高的，須要在 C（一致性）A（可用性）P（分區容錯性） 三者之間作出權衡。
2. 運維成本
運維主要包括配置、部署、監控與告警和日誌收集四大方面。微服務架構中，每一個服務都須要獨立地配置、部署、監控和收集日誌，成本呈指數級增加。
3. 自動化部署
在微服務架構中，每一個服務都獨立部署，交付週期短且頻率高，人工部署已經沒法適應業務的快速變化。所以如何有效地構建自動化部署體系，是微服務面臨的另外一個挑戰。
4. DevOps 與組織架構
在微服務架構的實施過程當中，開發人員和運維人員的角色發生了變化，開發者將承擔起整個服務的生命週期的責任，包括部署和監控；而運維則更傾向於顧問式的角色，儘早考慮服務如何部署。所以，按需調整組織架構、構建全功能的團隊，也是一個不小的挑戰。
5. 服務間的依賴測試
單塊架構中，一般使用集成測試來驗證依賴是否正常。而在微服務架構中，服務數量衆多，每一個服務都是獨立的業務單元，服務主要經過接口進行交互，如何保證依賴的正常，是測試面臨的主要挑戰。
6. 服務間的依賴管理
微服務架構中，服務數量衆多，如何清晰有效地展現服務間的依賴關係也是個不小的挑戰。
「微服務的落地須要通過全面的考察和完善的試驗，並非每一個場景都適合使用微服務架構，也不是每一個企業都有能力或者精力去面對這些挑戰。」老王最後語重心長的說。
「嗯嗯，每件事都有兩面性，最合適的纔是最好的！對了王哥，您已經給我上完理論課了，啥時候帶我實踐下唄？」
「你先好好消化完今天講的這些，下次再說吧……」
「好吧，很期待咱們的下一次交流……」
【1】圖片源及內容主要參考《微服務架構與實踐》。