從微服務開始(二):容器與微服務
1 Star2 Stars3 Stars4 Stars5 Stars 給文章打分!
Loading...

原文連結:https://blogs.oracle.com/the-cloud-front/getting-started-with-microservices%2c-part-2%3a-containers-and-microservices

簡介

在本系列文章的第一部分討論了微服務的主要優勢,並且接觸到一些在使用微服務時需要考慮的問題。

在第二部分我們將看一下容器是如何加入微服務故事的。對於一些開發人員和架構師來說,微服務和容器仍然是新的領域,所以對這兩個術語仍然有一些疑惑,在有的時候會將他們混淆。微服務和容器實際上是不同的兩個東西。微服務是一種架構形式;容器是一種工具,經常用來幫助基於微服務的應用。

本文的目的是讓大家深入的瞭解容器是如何幫助微服務的,並且提供了一些使用編排工具執行容器化微服務的一些高階概念。

容器與微服務

這篇部落格的目的,是讓你能夠考慮容器作為封裝的、獨立部署的元件,利用作業系統級別的虛擬化,以隔離的例項執行在相同的核心之上,因此能夠非常快速(秒級)的啟動。

隔離與密度

容器的隔離級別介於虛擬機器(VM)和程序之間。對於微服務來說,執行在VM當中會獲得更好的隔離性,但是它也無法進行快速的擴充套件,因為通常VM的啟動需要花費一些時間。容器能夠在幾秒鐘之內快速啟動,能夠立即對負載或者流量的增加做出反應。

程序的啟動也很快,能夠對資源,比如記憶體,進行動態的分配,並且能夠對它們進行高效的共享。從密度的角度看,每個程序或者程序組執行多個服務例項也是很好的。在每個程序中執行一個或者多個微服務例項不好的地方是,它們不能很好的與其他的環境進行隔離,會受到其相鄰環境產生的噪音的影響,如果程式碼寫的不好,有可能影響到整個虛擬機器環境。對服務程式碼進行容器化,它的執行環境、依賴關係、系統庫等,都被打包在一起,執行在一個容器當中,通過它完整的、私有訪問的作業系統結構檢視,解決在進行執行時所遇到的一些隔離問題。

圖1
展示了不同的隔離級別

DevOps的好處

良好的DevOps實踐是微服務應用成功的關鍵,並且容器對它也是非常有益的。設想一個基於微服務的應用是由多種語言編寫的不同服務組成的。在這個例子當中,DevOps團隊需要專門的知識來部署每一個服務,這極大的增加了運維的複雜性。如果你將微服務打包為容器的一部分,容器映象就成為一個部署單元,DevOps團隊只需要知道如何部署容器就可以了,不需要去考慮裡面執行的是什麼應用。通過這種方式,你也能夠避免由於缺少依賴庫,或者環境版本(比如你的服務所需要的框架、依賴)不匹配所造成的服務失敗,服務所需要的所有的東西都被打包在一起,成為一個不可變的環境,這就是典型的持續整合的一部分。從運維的角度,通常在一個容器當中只執行一個服務,容器能夠讓你將系統元素(CPU,記憶體等)收集到服務本身。容器還可以將開發人員和運維人員對主機和作業系統的一些特殊技術細節進行遮蔽。比如,如果基礎架構團隊決定更換主機上的Linux作業系統,因為它上面執行都是容器,所以不會對應用造成影響。

這些都是使用容器所帶來的一些好處。從微服務的角度看,它可以被看做是開發和運維之間的橋樑,讓你在微服務環境運維變得更加簡單。

讓我們看一個例子。圖2展示了一個執行在容器中的微服務應用。這個應用包括三個微服務:一個Order服務、一個Profile服務和一個Catalog服務。每一個服務,他們的依賴環境和執行環境都被打包到一個容器當中。由於容器的封裝和隔離級別,即使你的服務有不同的版本(比如Order
v1和Order v2),不同的執行環境和不同的依賴元件(Profile服務依賴於LibraryC
v1,Catalog服務依賴於LibraryC v2),你可以讓他們執行在相同的主機之上。如果有一個服務的執行出現問題,耗盡了所有的資源,比如CPU或記憶體,它也不會影響到其他的服務,因為它只能夠使用分配給它所在容器的資源。

圖2:一個執行在容器中的微服務應用

微服務的編排

直截了當一點,如果你的應用在一個主機之上執行,但是一個主機不是真正的生產環境;比如,為了實現HA,你需要至少兩個主機。因為微服務應用本質上是分散式應用,通常他們都執行在一個叢集之上。叢集就是一組耦合的計算機(通常叫做節點),可以看做是一個單獨的系統,能夠通過網路進行連線。在叢集中排程新的服務看似簡單。然而,你也需要一些措施來保證服務在失敗的時候仍處於活動狀態;在節點失敗時能夠將服務移動到其他節點;或者服務正在被呼叫,並且你可以進行滾動升級,你的服務可以“永遠線上”。此外,它還需要了解依賴關係、位置、資源約束、優化、不同型別的資源和對資源的需求,以便列出對這些挑戰的看法。好訊息是,當你的應用執行在容器當中,你不需要擔心這些事情,容器編排,有時也被稱為排程器,能夠幫你解決這些問題。你能夠自己安裝的最流行的容器編排工具包括Kubernetes,DC/OS和Docker
Swarm。你也可以使用受管的容器服務,比如Oracle Container Cloud Service或者其他的受管容器服務。使用完全受管服務的好處是你完全不需要擔心底層架構的問題。在核心功能上,所有的容器編排解決方案,受管的或非受管的,都提供了相似的功能。

從微服務的角度看,你所面對的是一個非常動態的環境。你通常不會知道你的服務(容器)在叢集當中的什麼位置,因為你依賴於編排器,基於資源的有效性與/或者位置約束來查詢服務的最佳位置。服務註冊和服務發現時解決這個問題的方案,他們能夠對服務進行註冊,並且能夠很容易的在系統中被別的服務發現。叢集中的服務發現有時也被稱為東西路由;通常,額外的服務後設資料會連同服務的端點資訊一起儲存,並且/或者服務的健康檢查和服務例項的健康狀態一起進行維護。Etcd、Consul和Zookeeper是非常流行的註冊和發現解決方案。

圖3展示了一個叢集的高階檢視,叢集中帶有微服務例項,並且他們的端點儲存在服務註冊當中,Order服務的一個例項正在對Catalog服務進行呼叫。Order服務呼叫節點上的一個端點,本地代理服務處理對這個服務的查詢。請注意,有多種解決方案可以實現這些功能,一些受管的容器服務或者編排解決方案都已經內建服務註冊和服務發現。這個例子當中提供了一個簡單的檢視,來說明服務發現解決方案如何工作。

圖3:服務發現解決方案——高階檢視

你所需要考慮的是如何將叢集之外的客戶端呼叫流量路由給叢集內的服務。有時這被稱為南北路由。

一種常用的模式是使用應用閘道器,也稱為API網管。在微服務架構當中,API閘道器用於流量聚合,並且把客戶端請求路由給需要的服務。此外,API閘道器也用於身份認證解除安裝、SSL解除安裝、服務質量控制和監控檢視。Nginx和HA-Proxy是目前最流行的兩個應用閘道器。典型的閘道器部署模式包括對等閘道器路由,就是在叢集中的每一個節點都執行閘道器。這種模式通常用於小規模的叢集。另一種模式是專用的或者獨立的閘道器節點。專用是指通過放置約束將閘道器服務放置在特定的叢集節點之上。獨立的閘道器節點的工作模式類似,不同的地方是節點服務的所在的節點不是叢集排程的一部分。圖4展示了一個叢集架構,有一個閘道器節點將使用者請求轉發給Order服務。負載均衡器將流量定向到其中一個閘道器例項。閘道器使用路徑來指向一個從服務註冊返回的Order服務例項,將請求路由給它。

圖4:使用者請求到Order服務

總結

除了服務註冊、服務發現和服務閘道器之外,開發人員和DevOps人員還不得不考慮避免潛在的埠衝突、為每個容器分配服務一個IP等等。這就使開發人員不得不去學習更多的基礎架構和網路知識。好訊息是容器編排進化的非常快,幾乎每一個容器編排工具現在都提供了一些功能來幫助開發人員簡化基礎架構級別的工作。這也說明,仍然有很多事情開發人員需要在建立基於微服務的應用時考慮。後邊的部落格中將有更詳細的微服務模式的介紹,並且如何對容器化的微服務進行打包和DevOps。

相關文章

程式語言 最新文章