軟體架構模式之微服務架構

1、微服務架構介紹

微服務架構（Microservice Architecture）是一種架構概念，旨在透過將功能分解到各個離散的服務中以實現對解決方案的解耦。你可以將其看作是在架構層次而非獲取服務的類上應用很多SOLID原則。微服務架構是個很有趣的概念，它的主要作用是將功能分解到離散的各個服務當中，從而降低系統的耦合性，並提供更加靈活的服務支援。

概念：把一個大型的單個應用程式和服務拆分為數個甚至數十個的支援微服務，它可擴充套件單個元件而不是整個的應用程式堆疊，從而滿足服務等級協議。

定義：圍繞業務領域元件來建立應用，這些應用可獨立地進行開發、管理和迭代。在分散的元件中使用雲架構和平臺式部署、管理和服務功能，使產品交付變得更加簡單。

本質：用一些功能比較明確、業務比較精練的服務去解決更大、更實際的問題。

2、模式描述

不管你使用何種實現風格和拓撲，有幾個通用的核心概念應用在這種架構模式上。首先是分隔釋出單元（separately deployed units）。

如圖所示，每一個微核心的元件都被分隔成一個獨立的單元。

微服務包含服務元件（service component）。不要考慮微核心的單個服務，而是最好考慮服務元件，從粒度上講它可以是單一的模組或者一個一個大的應用程式，代表單一功能（提供天氣預報或者圖片儲存）。

正確設計服務元件的粒度是一個很大的挑戰。

另一個關鍵概念是微核心是分散式的。這意味著服務元件可能是遠端方法（透過JMS, AMQP, REST, SOAP, RMI......等等）。分散式意味著這種模式可以建立大規模的應用。

另一個值得興奮的特性是它可以從其它有問題的架構模式中演化出來，而不是直接建立出來等待問題發生。當你遇到一些無法解決的問題，特別是網際網路企業的規模擴大時，是很好的引入微服務架構的時機。

一般會從兩個模式中演化：

• 一種就是一開始就是整體的應用，所有的模組都是緊耦合的；

• 另外一種是面向服務的架構模式(SOA，service-oriented architecture pattern)。SOA不是不好，但是太昂貴了，不好理解和實現。

3、模式拓撲

有很多實現微服務的方式。最通用最流行的三個方式是: API REST-based, applicaiton REST-based 和 中心化的訊息。API REST-based 適合網站提供小規模的，自包含的服務。很多網際網路網站都提供這樣的服務，比如OAuth2服務。

application REST-based不同於上面的架構，客戶端看到的是web介面或者富客戶端程式，而不是呼叫API。UI層獨立釋出，可以訪問服務元件。

中心訊息模式，它類似前面的模式，但是使用一個輕量級的訊息broker取代RESTful的服務呼叫。這個輕量級的broker不會執行服務的編排，傳輸和路由，這和SOA不同，不要把它看作SOA的簡化版。

4、架構考量

微服務架構解決了無架構的整體編碼的應用的問題以及SOA的問題。同時它還可以提供實時的產品釋出。它是一個分散式架構，也會有上面分散式的問題。

微服務模式優劣分析：

• 總體靈活性：高

• 釋出易用性：高

• 可測試性：高

• 效能：低

• 規模擴充套件性：高

• 開發容易度：高

  
  

5、總結

微服務作為單一整體的程式和麵向服務架構的替代者， 微服務架構模式在工業界很快贏得了地位。這種模式還在進化之中，在業界對於它的特性和實現還有些困惑。對於我們的思考，更多的是思維上的轉變。對於微服務架構：技術上不是問題，意識比工具重要。