微服務

维基百科,自由的百科全书
跳到导航 跳到搜索

微服務 (Microservices) 是一種軟體架構風格,它是以專注於單一責任與功能的小型功能區塊 (Small Building Blocks) 為基礎,利用模組化的方式組合出複雜的大型應用程式,各功能區塊使用與語言無關 (Language-Independent/Language agnostic) 的 API 集相互通訊。

微服務的起源是由 Peter Rodgers 博士於 2005 年度雲端運算博覽會提出的微 Web 服務 (Micro-Web-Service) 開始,Juval Löwy 則是與他有類似的前導想法,將類別變成細粒服務 (granular services),以作為 Microsoft 下一階段的軟體架構,其核心想法是讓服務是由類似 Unix 管道的存取方式使用,而且複雜的服務背後是使用簡單 URI 來開放介面,任何服務,任何細粒都能被開放 (exposed)。這個設計在 HP 的實驗室被實現,具有改變複雜軟體系統的強大力量。

2014年,Martin FowlerJames Lewis 共同提出了微服務的概念,定義了微服務是由以單一應用程式構成的小服務,自己擁有自己的行程與輕量化處理,服務依業務功能設計,以全自動的方式部署,與其他服務使用 HTTP API 通訊。同時服務會使用最小的規模的集中管理 (例如 Docker) 能力,服務可以用不同的程式語言與資料庫等元件實作[1]

概念[编辑]

微服務是一種以業務功能為主的服務設計概念,每一個服務都具有自主運行的業務功能,對外開放不受語言限制的 API (最常用的是 HTTP),應用程式則是由一個或多個微服務組成。

微服務的另一個對比是單體式應用程式。單體式應用表示一個應用程式內包含了所有需要的業務功能,並且使用像主從式架構 (Client/Server) 或是多層次架構 (N-tier) 實作,雖然它也是能以分散式應用程式來實作,但是在單體式應用內,每一個業務功能是不可分割的。若要對單體式應用進行擴展則必須將整個應用程式都放到新的運算資源(如:虛擬機器) 內,但事實上應用程式中最吃資源、需要運算資源的僅有某個業務部份(例如跑分析報表或是數學演算法分析),但因為單體式應用無法分割該部份,因此無形中會有大量的資源浪費的現象。

微服務運用了以業務功能的設計概念,應用程式在設計時就能先以業務功能或流程設計先行分割,將各個業務功能都獨立實作成一個能自主執行的個體服務,然後再利用相同的協定將所有應用程式需要的服務都組合起來,形成一個應用程式。若需要針對特定業務功能進行擴充時,只要對該業務功能的服務進行擴展就好,不需要整個應用程式都擴展,同時,由於微服務是以業務功能導向的實作,因此不會受到應用程式的干擾,微服務的管理員可以視運算資源的需要來配置微服務到不同的運算資源內,或是佈建新的運算資源並將它配置進去。

雖然使用一般的伺服器虛擬化技術就能應用於微服務的管理,但容器技術 (Container Technology) 如 Docker 會更加地適合發展微服務的運算資源管理技術。

規劃[编辑]

微服務中每個服務都能夠有自己的資料庫。

微服務的規劃與單體式應用程式十分不同,微服務中每個服務都需要避免與其他服務有所牽連,且都要能夠自主,並在其他服務發生錯誤時不受干擾。

如果資料庫都是分開的,那麼新服務上線時就會遇到資料庫為空的窘境。我們並不能從另一個服務複製資料過來,因為我們無法確定該服務擁有最新的資料。 此時應該從事件存儲中心重播所有事件,如此一來就可以找回先前的所有、最新的資料。

資料庫[编辑]

微服務理念中有數個資料庫的規劃方式。

  • 每個服務都各有一個資料庫,同屬性的服務可共享同個資料庫。
  • 所有服務都共享同個資料庫,但是不同表格,並且不會跨域存取。
  • 每個服務都有自己的資料庫,就算是同屬性的服務也是,資料庫並不會共享。

資料庫並不會只存放該服務的資料,而是「該服務所會用到的所有資料」。更深層一點的舉例:假設有個文章服務,而這個服務可能會需要判斷使用者的帳號⋯⋯等。那麼文章服務的資料庫就可以放入使用者的部分資料。此舉是為了避免服務之間的相依性,避免文章服務呼叫使用者服務。

資料庫的可棄性[编辑]

實踐微服務有許多的做法,但其中一種做法是將資料庫作為短期的儲存空間而不是儲存長期的資料。這意味著資料庫可以在離線時被清空。因為它們可以在上線時從事件存儲中心恢复,因此也能以記憶體快取(如:Redis) 作為資料庫伺服器。但這種做法需要將每個請求當作事件來進行廣播。如此一來就可以從事件存儲中心重播所有的事件來找回所有的資料。

溝通與事件廣播[编辑]

NSQ 是一個訊息佇列系統、平台。在微服務中所扮演的角色是將訊息、資料傳遞到其他服務。 此舉是異步執行,所以不需要等到其他服務接收到訊息就能夠執行下一步。這種方式能夠避免服務之間有所牽連、呼叫。

微服務中最重要的就是每個服務的獨立與自主,因此服務與服務之間也不應該有所溝通。倘若真有溝通,也應採用異步溝通的方式來避免緊密的相依性問題。要達到此目的,則可用下列兩種方式:

事件存儲中心(Event Store)[编辑]

這可以讓你在服務叢集中廣播事件,並且在每個服務中監聽這些事件並作處理,這令服務之間沒有緊密的相依性,而這些發生的事件都會被保存在事件存儲中心裡。這意味著當微服務重新上線、部署時可以重播(Replay)所有的事件。這也造就了微服務的資料庫隨時都可以被刪除、摧毀,且不需要從其他服務中取得資料。

訊息佇列(Message Queue)[编辑]

這令你能夠在服務叢集中廣播消息,並傳遞到每個服務中。具有這個功能的像是 NSQ 或是 RabbitMQ。你能夠在 A 服務上廣播一個「建立新使用者」的事件,這個事件可以順便帶有新使用者的資料。而 B 服務可以監聽這個事件並在接收到之後有所處理。這些過程都是異步處理的,這意味著 A 服務並不需要等到 B 服務處理完該事件後才能繼續,而這也代表 A 服務無法取得 B 服務的處理結果。與事件存儲中心近乎相似,但有所不同的是:訊息佇列並不會保存事件。一旦事件被消化(接收)後就會從佇列中消失,這很適合用在像發送歡迎信件的時機。

服務探索[编辑]

單個微服務在上線的時候,會向服務探索中心(如:Consul)註冊自己的 IP 位置、服務內容,如此一來就不需要向每個微服務表明自己的 IP 位置,也就不用替每個微服務單獨設定。當服務需要呼叫另一個服務的時候,會去詢問服務探索中心該服務的 IP 位置為何,得到位置後即可直接向目標服務呼叫。

這麼做的用意是可以統一集中所有服務的位置,就不會分散於每個微服務中,且服務探索中心可以每隔一段時間就向微服務進行健康檢查(如透過:TCP 呼叫、HTTP 呼叫、Ping),倘若該服務在時間內沒有回應,則將其從服務中心移除,避免其他微服務對一個無回應的服務進行呼叫。

內容[编辑]

一個微服務架構的應用程式有下列特性:

  • 每個服務都容易被取代。
  • 服務是以能力來組織的,例如使用者介面、前端、推薦系統、帳單或是物流等。
  • 由於功能被拆成多個服務,因此可以由不同的程式語言、資料庫實作。
  • 架構是對稱而非分層(即生產者與消費者的關係)。

一個微服務架構:

  • 適用於具持續交付 (Continuous Delivery) 的軟體開發流程。
  • 服務導向架構 (Service-Oriented Architecture) 不同,後者是整合各種業務的應用程式,但微服務只屬於一個應用程式。

誤解[编辑]

微服務這個名詞令許多人以為是非常輕量、非常微小的,且以為透過該理念實作程式就能夠達到下列效果:

  • 微服務很輕量。
  • 程式碼將會變得更加地簡潔。
  • 變得更簡單、開發時程變短。
  • 微服務處理的事情變得更單一。

但這些是誤解,實際上:

  • 由於服務是獨立自主的(也稱:真空性),除了需要能夠有自己的一套執行方式外,還不應該仰賴另一個服務。為此,服務內會有著與其他服務相同的邏輯,這也導致了服務並不輕量。這部分有兩派說法,分別是在服務之間建立同套資源庫、工具,但這可能導致額外的相依性存在。而另一種說法則是傳統地將程式碼複製與貼上,這將避免相依性問題,但在全域修改時可能不易管控,需要分散管理。
  • 微服務屬於分布式系統的概念之一,程式碼並不會因此變得簡單、短少,反而有可能為了處理外來的事件而變得更多
  • 微服務需要額外處理事件的廣播、甚至是分布式的錯誤回溯問題,這導致開發時可能會更加地複雜,且花上更多時間在處理錯誤上。
  • 基於第一點誤解,微服務為了自主有可能會跨域實作,如文章服務有可能會帶有使用者服務的理念,所以在處理事情上並不會特別專一。

相關程式語言[编辑]

微服務採用者[编辑]

平台實作[编辑]

參考[编辑]

  1. ^ Microservices: A definition of this new architectural term
  2. ^ Jolie. 
  3. ^ AnyPresence Launches a New API Platform for Mobile and IoT Developers. 
  4. ^ How Enterprise PaaS can add Critical Value to Microservices. 
  5. ^ Developing Microservices for PaaS with Spring and Cloud Foundry. 
  6. ^ Microservices (PDF). [失效連結]
  7. ^ Microservices. 
  8. ^ Microservices. 
  9. ^ Products > Platform. 1060 Research Ltd. [12 October 2015]. 
  10. ^ Wilma documentation
  11. ^ Wilma source code
  12. ^ Vertx. 
  13. ^ Baratine. 
  14. ^ KumuluzEE.