微服務部署的正確策略

在過去的幾年中,微服務體系結構提供了高級軟件可伸縮性,因此非常流行。儘管組織接受這種架構模式,但是許多組織仍在努力制定能夠克服一些主要挑戰的策略,例如將其分解爲基於微服務的應用程序。

在本文中,優銳課將分享一些最受歡迎的微服務部署策略,並研究組織如何利用它來獲得更高的敏捷性,效率,靈活性和可擴展性。


微服務部署挑戰

整體應用程序的部署意味着您將運行一個通常較大的應用程序的多個相同副本。這主要是通過配置N臺物理或虛擬服務器,並在每臺服務器上運行應用程序的M個實例來完成的。儘管看起來很簡單,但通常不是。但是,這比部署微服務應用程序容易得多。


如果你打算部署微服務應用程序,那麼你必須熟悉編寫這些服務的各種框架和語言。這也是最大的挑戰之一,因爲這些服務中的每一項都有其特定的部署,資源要求, 擴展和監視需求。此外,部署服務必須快速,可靠且具有成本效益!

好消息是,可以輕鬆擴展幾種微服務部署模式,以處理來自各種集成組件的大量請求。閱讀此博客,找出最適合你的並進行部署。


微服務部署策略

1.每個主機(物理或VM)有多個服務實例

部署應用程序的最傳統方法也許是“每主機多個服務實例”模式。在這種模式下,軟件開發人員可以提供單個或多個物理或虛擬主機,並在每個主機上運行多個服務實例。此模式幾乎沒有變體,包括每個服務實例作爲一個流程或在同一流程中運行多個服務實例的變體。

image.png

好處

由於多個服務實例使用同一服務器及其操作系統,因此資源使用效率相對較高。


服務實例的部署也相對較快,因爲你只需要將服務複製到主機上並運行它即可。


例如,如果該服務是用Java編寫的,則只需複製JARWAR文件,或者如果它是用Node.jsRuby編寫的,則複製源代碼。

由於沒有開銷,因此以這種模式啓動服務也很快。 如果服務具有其進程,則可以將其啓動,也可以將其動態部署到容器中,或者如果該服務是在同一容器進程或進程組中運行的許多實例之一,則可以重新啓動它。

挑戰性

  • 對服務實例的控制很少或完全缺乏控制,除非每個實例都是一個單獨的進程。你無法限制每個實例使用的資源。這會大大消耗主機的內存。

  • 如果多個服務實例在同一進程中運行,則缺乏隔離。這通常會導致一個行爲異常的服務中斷同一進程中的其他服務。

  • 部署過程中出現錯誤的風險更高,因爲部署它的運營團隊需要知道服務的詳細信息。因此,開發團隊和運營之間的信息交換是消除所有複雜性的必要條件。

2. 每個主機的服務實例(物理或VM

每個主機模式的服務實例是部署微服務的另一種方法。這使你可以在其主機上分別運行每個實例。這有兩個專長:每個虛擬機的服務實例和每個容器的服務實例。


每個虛擬機模式的服務實例使你可以將每個服務打包爲虛擬機(VM)映像,例如Amazon EC2 AMI。每個實例都是使用該VM映像運行的VM。使用這種模式的流行應用之一是Netflix的視頻流服務。要構建自己的VM,你可以配置Jenkins等連續集成服務器或使用packer.io

image.png

好處

每個虛擬機模式使用服務實例的最大好處之一是,它使用有限的內存,並且由於是獨立運行的,因此無法從其他服務中竊取資源。

它允許你利用成熟的雲基礎架構(例如AWS)來利用負載平衡和自動擴展功能。

由於該服務一旦打包爲虛擬機,便成爲黑匣子,因此可以密封你服務的實施技術。它使部署變得更加簡單和可靠。

挑戰性

  • 由於虛擬機通常在典型的公共IaaS中具有固定的大小,因此有可能無法完全利用它。效率較低的資源利用率最終也會導致更高的部署成本,因爲IaaS提供程序通常會向VM收費,而不管它們是空閒還是繁忙。

  • 最新版本的部署通常很慢。這是因爲VM映像由於其大小而導致創建和實例化速度很慢。通常可以通過使用輕量級VM來克服此缺陷。

  • 除非你不使用工具來構建和管理VM,否則每個虛擬機模式的服務實例對於你和你的團隊而言通常很耗時。這通常是一個繁瑣的過程,但是好消息是可以通過使用各種解決方案(例如Box保險絲)解決該問題。

3. 每個容器的服務實例

在這種模式下,每個服務實例都在其各自的容器中運行,這是操作系統級別的虛擬化機制。一些流行的容器技術是DockerSolaris Zones


爲了使用此模式,你需要將服務打包爲一個文件系統映像,其中包含執行該服務所需的應用程序和庫,通常被稱爲容器映像。將服務打包爲容器映像後,你需要啓動一個或多個容器,並可以在物理或虛擬主機上運行多個容器。爲了管理多個容器,許多開發人員喜歡使用集羣管理器,例如KubernetesMarathon

好處

就像每個虛擬機的服務實例一樣,該模式也可以獨立工作。它使你可以跟蹤每個容器正在使用多少資源。與VM相比,最大的優勢之一是容器重量輕且構建速度非常快。由於沒有操作系統啓動機制,因此容器可以快速啓動。

image.png

挑戰性

儘管基礎架構日趨成熟,但每個容器模式的服務實例仍落後於VM基礎架構,並且不如VM安全,因爲它們共享主機OS的內核。

VM一樣,你要承擔所有管理容器映像的繁重工作。如果你沒有另外的容器解決方案(例如Amazon EC2容器服務(ECS)),則還必須管理容器基礎結構,可能還需要管理VM基礎結構。

此外,由於大多數容器都部署在按VM定價的基礎架構上,因此會導致額外的部署成本和VM的超額配置,以應對意外的負載高峯。

4. 無服務器部署

無服務器部署技術是微服務部署的另一種策略,它支持JavaNode.jsPython服務。AWS Lambda是全球開發人員使用的一種流行技術。在這種模式下,你需要將該服務打包爲一個ZIP文件並將其上傳到Lambda函數(這是一個無狀態服務)。


你也可以提供元數據,該元數據具有處理請求時要調用的函數的名稱。Lambda函數自動運行足夠的微服務實例來處理請求。你只需根據花費的時間和消耗的內存爲每個請求付費。

image.png

好處

無服務器部署的最大優勢是定價,因爲你將僅根據服務器執行的工作向你收費。

它使你從IT基礎架構的任何方面(例如VM,容器等)中解放出來,從而使你有更多時間專注於應用程序的開發。

挑戰性

無服務器部署的最大挑戰是它不能用於長期運行的服務。所有請求必須在300秒內完成。

此外,你的服務必須是無狀態的,因爲Lambda函數可能會爲每個請求運行不同的實例。

服務必須使用一種受支持的語言,並且必須快速啓動,否則服務可能會超時並終止。


總結

如果沒有正確的策略,部署微服務應用程序可能會非常困難。由於這些服務是用多種框架和語言編寫的,因此每種服務都有其部署,擴展和管理要求。因此,有必要知道哪種模式最適合你的組織。

 


發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章