新名詞-微服務

「微服務」架構是近期軟件應用領域很是熱門的概念。那什麼是微服務？

簡單的說，微服務架構就是將一個完整的應用 從數據存儲開始垂直拆分紅多個不一樣的服務，每一個服務都能獨立部署、獨立維護、獨立擴展，服務與服務間經過諸如REST、API的方式互相調用。

傳統IT架構面臨的一些問題以及雲計算及互聯網公司大量開源輕量級技術不停涌現並日漸成熟 ，這就催生了新的架構設計風格 – 微服務架構的出現。

（簡單描述一下輕量級技術涌現：

 一、輕量級運行時技術的出現(node.js等)；

 二、新的方法與工具(Agile, DevOps, TDD, CI, XP, Puppet, Chef…)；

 三、新的輕量級協議(RESTful API接口, 輕量級消息機制)；

 四、服務平臺化(PaaS)： 雲服務平臺上具備自動縮放、工做負載管理、SLA 管理、消息機制、緩存、構建管理等各類按需使用的服務；

 五、標準化代碼管理：如Github等；）

微服務架構的優勢：

1. 每一個服務都比較簡單，只關注於一個業務功能。

2. 微服務架構方式是鬆耦合的，能夠提供更高的靈活性。

3. 微服務可經過最佳及最合適的不一樣的編程語言與工具進行開發，可以作到有的放矢地解決針對性問題。

4. 每一個微服務可由不一樣團隊獨立開發，互不影響，加快推出市場的速度。

5. 微服務架構是持續交付(CD)的巨大推進力，容許在頻繁發佈不一樣服務的同時保持系統其餘部分的可用性和穩定性。

微服務架構的缺點：

     微服務的一些想法在實踐上是好的，但當總體實現時也會呈現出其複雜性。

1. 運維開銷及成本增長：總體應用可能只需部署至一小片應用服務區集羣，而微服務架構可能變成須要構建/測試/部署/運行數十個獨立的服務，並可能須要支持多種語言和環境。這致使一個總體式系統若是由20個微服務組成，可能須要40~60個進程。

2. 必須有堅實的DevOps開發運維一體化技能：開發人員須要熟知運維與投產環境，開發人員也須要掌握必要的數據存儲技術如NoSQL，具備較強DevOps技能的人員比較稀缺，會帶來招聘人才方面的挑戰。

3. 隱式接口及接口匹配問題：把系統分爲多個協做組件後會產生新的接口，這意味着簡單的交叉變化可能須要改變許多組件，並需協調一塊兒發佈。在實際環境中，一個新品發佈可能被迫同時發佈大量服務，因爲集成點的大量增長，微服務架構會有更高的發佈風險。

4. 代碼重複：某些底層功能須要被多個服務所用，爲了不將「同步耦合引入到系統中」，有時須要向不一樣服務添加一些代碼，這就會致使代碼重複。

5. 分佈式系統的複雜性：做爲一種分佈式系統，微服務引入了複雜性和其餘若干問題，例如網絡延遲、容錯性、消息序列化、不可靠的網絡、異步機制、版本化、差別化的工做負載等，開發人員須要考慮以上的分佈式系統問題。

6. 異步機制：微服務每每使用異步編程、消息與並行機制，若是應用存在跨微服務的事務性處理，其實現機制會變得複雜化。

7. 可測性的挑戰：在動態環境下服務間的交互會產生很是微妙的行爲，難以可視化及全面測試。經典微服務每每不過重視測試，更多的是經過監控發現生產環境的異常，進而快速回滾或採起其餘必要的行動。但對於特別在乎風險規避監管或投產環境錯誤會產生顯著影響的場景下須要特別注意。

   關於微服務架構的取捨：

1. 在合適的項目，合適的團隊，採用微服務架構收益會大於成本。

2. 微服務架構有不少吸引人的地方，但在擁抱微服務以前，也須要認清它所帶來的挑戰。

3. 須要避免爲了「微服務」而「微服務」。

4. 微服務架構引入策略 – 對傳統企業而言，開始時能夠考慮引入部分合適的微服務架構原則對已有系統進行改造或新建微服務應用，逐步探索及積累微服務架構經驗，而非全盤實施微服務架構。

如今在業界基於微服務的實踐方法有兩種，一種是dubbo，一種是springcloud

未完，待續。。。。