微服務例舉

因爲技術領域的範式轉變，以及但願以快速且可靠的方式找到更好的方法來構建應用程序，企業軟件架構老是伴隨新的架構風格而發展。

微服務架構已被普遍採用的架構風格，容許快速，安全地構建軟件應用程序。微服務架構促進軟件系統結構成爲：鬆散耦合且獨立自治的服務（獨立開發，部署和擴展）的集合。這些服務經過集成全部此類服務和其餘系統造成的單個軟件應用程序。

在本章中，將探討微服務是什麼，實例示例的微服務的特徵，以及企業軟件架構環境中微服務的優缺點。

爲了更好地理解微服務是什麼，咱們須要看一下微服務以前使用的一些架構風格，以及企業架構如何發展到包含微服務架構。

從Monolith到微服務架構

探索從單一應用程序到微服務的企業架構的演變是理解微服務的關鍵動機和特徵的好方法。讓咱們開始討論單片應用程序。

總體應用

企業軟件應用程序旨在促進衆多業務需求。在單片架構風格中，全部業務功能都集成在一個單一的應用程序中，並構建爲一個單元。考慮一個真實的例子來進一步理解單片應用程序。圖1-1顯示了使用單片架構風格構建的在線零售應用程序。

圖1-1使用單片架構開發的在線零售應用程序

整個零售應用程序是幾個組件的集合，例如訂單管理，付款，產品管理等。這些組件中的每個都提供普遍的業務功能。因爲其總體性質，向組件添加或修改功能是很是昂貴的。此外，爲了促進總體業務需求，這些組件必須相互通訊。這些組件之間的通訊一般創建在專有協議和標準之上，而且它們基於點對點通訊方式。所以，修改或替換給定組件也很是複雜。例如，若是零售企業想要在保留其他部分的同時切換到新的訂單管理系統，那麼這樣作也須要對其餘現有組件進行至關多的更改。

咱們能夠將單片應用的共同特徵歸納以下：

做爲一個單元設計，開發和部署。

對於大多數現實世界的商業用例來講，這是很是複雜的，這致使了維護，升級和添加新功能的噩夢。

實施敏捷開發和交付方法很難。因爲應用程序必須構建爲一個單元，所以它提供的大多數業務功能都沒有本身的生命週期。

必須從新部署整個應用程序才能更新它的任何部分。

隨着總體應用程序的增加，啓動可能須要更長時間，這會增長整體成本。

它必須做爲單個應用程序進行擴展，而且難以根據相互衝突的資源需求進行擴展。（例如，因爲單片應用程序提供多種業務功能，所以一種功能可能須要更多CPU，而另外一種功能須要更多內存。很難知足這些功能的個性化需求。）

一個不穩定的服務能夠下降整個應用程序。

採用新技術和框架很是困難，由於全部功能都必須創建在同質技術/框架之上。 （例如，若是您使用的是Java，那麼全部新項目都必須基於Java，即便那是更好的替代技術。）

做爲單片應用程序體系結構的一些侷限性的解決方案，出現了面向服務的體系結構（SOA）和企業服務總線（ESB）。

SOA和ESB

SOA試圖經過將單片應用程序的功能分離爲可重用，鬆散耦合的實體（稱爲服務）來應對大型單片應用程序的挑戰。這些服務可經過網絡呼叫訪問。服務是可經過網絡訪問的定義明確的業務功能的自包含實現。 SOA中的應用程序是基於服務構建的。服務是具備明肯定義的接口的軟件組件，這些接口與實現無關。 SOA的一個重要方面是將服務接口（什麼）與其實現（如何）分離。消費者只關心服務接口而不關心它的實現。

服務是獨立的（執行預約任務）和鬆散耦合（獨立）。能夠動態發現服務。消費者一般不須要知道服務的確切位置和其餘細節。經過服務元數據存儲庫或服務註冊表發現服務的元數據。當服務元數據發生更改時，服務能夠在服務註冊表中更新其元數據。能夠從其餘服務的聚合構建組合服務。

使用SOA範例，每一個業務功能都構建爲具備多個子功能的（粗粒度）服務（一般實現爲Web服務）。這些服務部署在應用程序服務器中。在涉及業務功能的消耗時，咱們常常須要集成/檢測多個此類服務（並建立組合服務）和其餘系統。企業服務總線（ESB）用於集成這些服務，數據和系統。消費者使用從ESB層公開的組合服務。所以，ESB用做鏈接全部這些服務和系統的集中總線（見圖1-2）。

 

圖1-2基於SOA / ESB樣式的在線零售系統
例如，回到在線零售應用程序用例。圖1-2說明了使用SOA / Web服務的在線零售應用程序的實現。在這裏，咱們定義了多種Web服務，知足各類業務功能，如產品，客戶，購物，訂單，支付等。在ESB層，集成這些業務功能並建立複合業務功能，這些功能能夠向消費者展現。或者ESB層能夠只用於公開功能，具備額外的交叉功能，例如安全性。所以，顯然ESB層還包含整個應用程序的重要業務邏輯部分。其餘橫切關注點（如安全性，監控和分析）也可能應用於ESB層。 ESB層是一個單一的實體，全部開發人員共享相同的運行時來開發/部署他們的服務集成。
APIS蜜蜂
將業務功能公開爲託管服務或API已成爲現代企業架構的關鍵要求。可是，Web服務/ SOA實際上並非知足此類需求的理想解決方案，由於Web服務相關技術（如用做服務間通訊的消息格式）的複雜性，WS-Security（到服務之間的安全消息傳遞），WSDL（定義服務合同）等，以及缺少圍繞API構建生態系統的功能（自助服務等）
所以，大多數組織在現有SOA實現之上放置了一個新的API Management / API Gateway層。該層稱爲API外觀，它爲給定的業務功能公開了一個簡單的API，並隱藏了ESB / Web服務層的全部內部複雜性。 API層還用於安全性，限制，緩存和貨幣化。
例如，圖1-3在ESB層之上引入了API網關。咱們的在線零售應用程序提供的全部業務功能如今都做爲託管API公開。 API管理層不只要將功能公開爲託管API，還要構建一個完整的業務功能生態系統及其消費者。

圖1-3經過API網關層將業務功能公開爲託管API
隨着對複雜業務功能的需求不斷增長，單片架構沒法知足現代企業軟件應用程序的開發需求。 單片應用程序的集中性致使沒法獨立擴展應用程序，阻礙獨立應用程序開發和部署的應用程序間依賴性，因爲集中性而致使的可靠性問題以及使用各類技術進行應用程序開發的限制。 爲了克服大多數這些限制並知足現代，複雜和分散的應用程序需求，必須構思一種新的體系結構範例。
微服務架構已經成爲一種更好的架構範例，能夠克服ESB / SOA架構以及傳統單片應用架構的缺點。