（1）微服務是什麼？它的優缺點有哪些？

“微服務”一詞來源於 Martin Fowler 的《Microservices》一文。微服務是一種架構風格，即將單體應用劃分為小型的服務單元，微服務之間使用 HTTP 的 API 進行資源訪問與操作。

在筆者看來，微服務架構的演變更像是一個公司的發展過程，從最開始的小公司，到後來的大集團。大集團可拆分出多個子公司，每個子公司的都有自己獨立的業務、員工，各自發展，互不影響，合起來則是威力無窮。

臃腫的系統、重複的程式碼、超長的啟動時間帶給開發人員的只有無限的埋怨，絲毫沒有那種很舒服的、很流暢的寫程式碼的感覺。他們把大部分時間都花在解決問題和專案啟動上面了。

微服務架構的優勢

使用微服務架構能夠為我們帶來如下好處：

1）服務的獨立部署

每個服務都是一個獨立的專案，可以獨立部署，不依賴於其他服務，耦合性低。

2）服務的快速啟動

拆分之後服務啟動的速度必然要比拆分之前快很多，因為依賴的庫少了，程式碼量也少了。

3）更加適合敏捷開發

敏捷開發以使用者的需求進化為核心，採用迭代、循序漸進的方法進行。服務拆分可以快速釋出新版本，修改哪個服務只需要釋出對應的服務即可，不用整體重新發布。

4）職責專一，由專門的團隊負責專門的服務

業務發展迅速時，研發人員也會越來越多，每個團隊可以負責對應的業務線，服務的拆分有利於團隊之間的分工。

5）服務可以動態按需擴容

當某個服務的訪問量較大時，我們只需要將這個服務擴容即可。

6）程式碼的複用

每個服務都提供 REST API，所有的基礎服務都必須抽出來，很多的底層實現都可以以介面方式提供。

微服務架構的劣勢

微服務其實是一把雙刃劍，既然有利必然也會有弊。下面我們來談談微服務有哪些弊端，以及能採取什麼辦法避免。

1）分散式部署，呼叫的複雜性高

單體應用的時候，所有模組之前的呼叫都是在本地進行的，在微服務中，每個模組都是獨立部署的，透過 HTTP 來進行通訊，這當中會產生很多問題，比如網路問題、容錯問題、呼叫關係等。

2）獨立的資料庫，分散式事務的挑戰

每個微服務都有自己的資料庫，這就是所謂的去中心化的資料管理。這種模式的優點在於不同的服務，可以選擇適合自身業務的資料，比如訂單服務可以用 MySQL、評論服務可以用 Mongodb、商品搜尋服務可以用 Elasticsearch。

缺點就是事務的問題了，目前最理想的解決方案就是柔性事務中的最終一致性，後面的章節會給大家做具體介紹。

3）測試的難度提升

服務和服務之間透過介面來互動，當介面有改變的時候，對所有的呼叫方都是有影響的，這時自動化測試就顯得非常重要了，如果要靠人工一個個介面去測試，那工作量就太大了。這裡要強調一點，就是 API 文件的管理尤為重要。

4）運維難度的提升

在採用傳統的單體應用時，我們可能只需要關注一個 Tomcat 的叢集、一個 MySQL 的叢集就可以了，但這在微服務架構下是行不通的。當業務增加時，服務也將越來越多，服務的部署、監控將變得非常複雜，這個時候對於運維的要求就高了。

 

推薦分散式架構原始碼

需要框架原始碼請看我個人簡介