1.微服務簡介

1.1.單體架構

一個歸檔包（例如war格式）包含了應用全部功能的應用程序，咱們一般稱之爲單體應用。架構單體應用的方法論，咱們稱之爲單體應用架構。

缺點：
1. 複雜性高
以筆者經手的一個百萬行級別的單體應用爲例，整個項目包含的模塊很是多，模塊的邊界模糊，依賴關係不清晰，代碼質量良莠不齊，混亂地堆砌在一塊兒……整個項目很是複雜。每次修改代碼都心驚膽戰，甚至添加一個簡單的功能，或者修改一個BUG都會形成隱含的缺陷。

2. 技術債務
隨着時間推移、需求變動和人員更迭，會逐漸造成應用程序的技術債務，而且越積越多。「不壞不修（Not broken，don’t fix）」，這在軟件開發中很是常見，在單體應用中這種思想更甚。已使用的系統設計或代碼難以修改，由於應用程序的其餘模塊可能會以意料以外的方式使用它。

3. 部署頻率低
隨着代碼的增多，構建和部署的時間也會增長。而在單體應用中，每次功能的變動或缺陷的修復都會致使咱們須要從新部署整個應用。全量部署的方式耗時長、影響的範圍大、風險高，這使得單體應用項目上線部署的頻率較低。而部署頻率低又致使兩次發佈之間會有大量的功能變動和缺陷修復，出錯機率比較高。

4. 擴展能力受限
單體應用只能做爲一個總體進行擴展，沒法結合業務模塊的特色進行伸縮。例如，應用中有的模塊是計算密集型的，它須要強勁的CPU；有的模塊則是IO密集型的，須要更大的內存。因爲這些模塊部署在一塊兒，咱們不得不在硬件的選擇上作出妥協。

5. 阻礙技術創新
單體應用每每使用統一的技術平臺或方案解決全部問題，團隊的每一個成員都必須使用相同的開發語言和框架，想要引入新的框架或技術平臺會很是困難。例如，一個使用Struts 2構建的、100萬行代碼的單體應用，若是想要換用Spring MVC，切換成本無疑是很是高的。
數據庫

1.2.微服務架構

簡而言之，微服務架構風格這種開發方法，是以開發一組小型服務的方式來開發一個獨立的應用系統的。其中每一個小型服務都運行在本身的進程中，並常常採用HTTP資源API這樣輕量的機制來相互通訊。這些服務圍繞業務功能進行構建，並能經過全自動的部署機制來進行獨立部署。這些微服務可使用不一樣的語言來編寫，而且可使用不一樣的數據存儲技術。對這些微服務咱們僅作最低限度的集中管理。

微服務特性：
從中咱們能夠看到，微服務架構應具有如下特性：
1. 每一個微服務可獨立運行在本身的進程裏；
2. 一系列獨立運行的微服務共同構建起整個系統；
3. 每一個服務爲獨立的業務開發，一個微服務只關注某個特定的功能，例如訂單管理、用戶管理等；
4. 微服務之間經過一些輕量的通訊機制進行通訊，例如經過REST API進行調用；
5. 可使用不一樣的語言與數據存儲技術；
6. 全自動的部署機制。網絡

1.3.微服務架構的優勢與挑戰

1.3.1.微服務架構的優勢

1. 易於開發和維護一個微服務只關注一個特定的業務功能，因此它的業務清晰、代碼量較少。開發和維護單個微服務相對是比較簡單的。而整個應用是由若干個微服務構建而成的，因此整個應用也會維持在可控狀態。

2. 單個微服務啓動較快
單個微服務代碼量較少，因此啓動會比較快。

3. 局部修改容易部署
單體應用只要有修改，就得從新部署整個應用，微服務解決了這樣的問題。通常來講，對某個微服務進行修改，只須要從新部署這個服務便可。

4. 技術棧不受限
在微服務中，咱們能夠結合項目業務及團隊的特色，合理地選擇技術棧。例如某些服務可以使用關係型數據庫MySQL；某些微服務有圖形計算的需求，咱們可使用Neo4J；甚至能夠根據須要，部分微服務使用Java開發，部分微服務使用NodeJS進行開發。

5. 按需伸縮
咱們能夠根據需求，實現細粒度的擴展。例如：系統中的某個微服務遇到了瓶頸，咱們能夠結合這個微服務的業務特色，增長內存、升級CPU或者是增長節點。
架構

1.3.2.微服務架構的挑戰

1. 運維要求較高
更多的服務意味着更多的運維投入。在單體架構中，只須要保證一個應用的正常運行；而在微服務中，須要保證幾十甚至幾百個服務的正常運行與協做，這給項目的運維帶來了很大的挑戰。

2. 分佈式固有的複雜性
使用微服務構建的是分佈式系統。對於一個分佈式系統，系統容錯、網絡延遲、分佈式事務等都給咱們帶來了很大的挑戰。

3. 接口調整成本高
微服務之間經過接口進行通訊。若是修改某一個微服務的API，可能全部使用了該接口的微服務都須要作調整。

4. 重複勞動
不少服務可能都會使用到相同的功能，而這個功能並無達到分解爲一個微服務的程度，這個時候，可能各個服務都會開發這一功能，從而致使代碼重複。框架

1.4.微服務設計原則

1.單一職責原則
ref：
https://en.wikipedia.org/wiki/SOLID_(object-oriented_design)

2.服務自治原則
服務自治，是指每一個微服務應該具有獨立的業務能力、依賴與運行環境。

3.輕量級通訊原則
輕量級的定義指：

4.接口明確原則
每一個服務的對外接口應該明肯定義，並儘可能保持不變。運維