微服務 Micro services

微服務 (Microservices) 是一種軟件架構風格，它是以專一於單一責任與功能的小型功能區塊 (Small Building Blocks) 爲基礎，利用模組化的方式組合出複雜的大型應用程序，各功能區塊使用與語言無關 (Language-Independent/Language agnostic) 的 API 集相互通信。微服務架構運用於軟件架構風格的其中一項概念是甘露運算 (Dew Computing)，意指由許多的小露水 (表明微服務的功能元件) 聚集而成的運算能力。

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

2014年，Martin Fowler 與 James Lewis 共同提出了微服務的概念，定義了微服務是由以單一應用程序構成的小服務，本身擁有本身的行程與輕量化處理，服務依業務功能設計，以全自動的方式部署，與其餘服務使用 HTTP API 通信。同時服務會使用最小的規模的集中管理 (例如 Docker) 能力，服務能夠用不一樣的編程語言與數據庫等元件實做。

概念

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

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

微服務運用了以業務功能的設計概念，應用程序在設計時就能先以業務功能或流程設計先行分割，將各個業務功能都獨立實做成一個能自主執行的個體服務，而後再利用相同的協定將全部應用程序須要的服務都組合起來，造成一個應用程序。若須要針對特定業務功能進行擴充時，只要對該業務功能的服務進行擴展就好，不須要整個應用程序都擴展，同時，因爲微服務是以業務功能導向的實做，所以不會受到應用程序的干擾，微服務的管理員能夠視運算資源的須要來配置微服務到不一樣的運算資源內，或是布建新的運算資源並將它配置進去。

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

規劃

微服務中每一個服務都可以有本身的數據庫。

微服務的規劃與單體式應用程序十分不一樣，微服務中每一個服務都須要避免與其餘服務有所牽連，且都要可以自主，並在其餘服務發生錯誤時不受干擾。

若是數據庫都是分開的，那麼新服務上線時就會遇到數據庫爲空的窘境。咱們並不能從另外一個服務複製資料過來，由於咱們沒法肯定該服務擁有最新的資料。 此時應該從事件存儲中心重播全部事件，如此一來就能夠找回先前的全部、最新的資料。

數據庫

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

• 每一個服務都各有一個數據庫，同屬性的服務可共享同個數據庫。
• 全部服務都共享同個數據庫，可是不一樣表格，而且不會跨域存取。
• 每一個服務都有本身的數據庫，就算是同屬性的服務也是，數據庫並不會共享。

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

數據庫的可棄性

實踐微服務有許多的作法，但其中一種作法是將數據庫做爲短時間的儲存空間而不是儲存長期的資料。這意味着數據庫能夠在離線時被清空。由於它們能夠在上線時從事件存儲中心回覆，所以也能之內存快取（如：Redis） 做爲數據庫服務器。但這種作法須要將每一個請求看成事件來進行廣播。如此一來就能夠從事件存儲中心重播全部的事件來找回全部的資料。

溝通與事件廣播

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

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

事件存儲中心（Event Store）

這可讓你在服務叢集中廣播事件，而且在每一個服務中監聽這些事件並做處理，這令服務之間沒有緊密的相依性，而這些發生的事件都會被保存在事件存儲中內心。這意味着當微服務從新上線、部署時能夠重播（Replay）全部的事件。這也造就了微服務的數據庫隨時均可以被刪除、摧毀，且不須要從其餘服務中取得資料。

訊息佇列（Message Queue）

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

內容

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

• 每一個服務都容易被取代。
• 服務是以能力來組織的，例如使用者界面、前端、推薦系統、帳單或是物流等。
• 因爲功能被拆成多個服務，所以能夠由不一樣的編程語言、數據庫實做。
• 架構是對稱而非分層（即生產者與消費者的關係）。

一個微服務架構：

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

誤解

微服務這個名詞令許多人覺得是很是輕量、很是微小的，且覺得透過該理念實做程式就可以達到下列效果：

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

但這些是誤解，實際上：

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