您為什麼應該使用微服務和容器?

收藏待读

您為什麼應該使用微服務和容器?

什麼是微服務和容器?

首先,什麼是微服務?微服務是將應用程序拆分為多個服務的一種架構類型,這些服務具備構成整個應用程序的細粒度功能。每個微服務將具備針對您的應用程序的不同邏輯功能。與應用程序的所有組件和功能都在單個實例中的單體架構相比,微服務是應用程序架構領域一種更為現代的方法。您可以參考下圖中單體架構與微服務架構的比較情況。

您為什麼應該使用微服務和容器?

您為什麼應該使用微服務和容器?

我們要將微服務放置在哪裡?在容器中。容器是存放軟件的包,裏面包含運行軟件所需的一切內容,比如代碼、依賴關係、庫、二進制文件等等。 Docker 是一種構建和運行容器的流行工具,但是 Kubernetes 正快速成為行業標準,用於編排企業環境中的多個容器。與虛擬機相比,容器可以共享操作系統內核,而不是像在一個主機上構建多個虛擬機那樣擁有完整的副本。雖然可以將微服務放置在多個虛擬機中,但在這種情況下通常會使用容器,因為容器佔用的空間更少,啟動速度也更快。

為什麼使用微服務架構?

微服務架構是為解決人們在單體應用程序中遇到的問題而創造的。微服務已被廣泛使用,一些大型網站已將他們的單體應用程序轉變為微服務。使用微服務架構的一些好處是:

  • 與單體應用程序中的大型代碼庫相比,開發人員只需處理小型代碼庫。  當應用程序組件鬆散耦合時,開發人員可以輕鬆理解源代碼,而不會減慢開發速度。如果使用的代碼行數更少,您的 IDE 的速度顯然會更快。開發人員無需處理各種功能的複雜性和依賴關係,這種情況只會在單體應用程序中出現。
  • 開發人員的職責將會更加明確。  可以按照應用程序的組件或微服務來分配團隊工作。代碼複查速度將會加快。與單體應用程序相比,更新速度將會加快,而且無需構建和部署一切內容。
  • 應用程序的技術堆棧可以通過微服務有所不同。 應用程序不再需要依賴一種語言或庫。只要開發人員認為合適,微服務就可以利用多種不同編程語言。可以使用如下圖所示的多語言微服務。 您為什麼應該使用微服務和容器?
    您為什麼應該使用微服務和容器?
  • 持續交付將變得更加容易。  對於簡單變更,使用微服務就無需像單體應用程序那樣再次重新部署一切。您可以選擇僅重新構建和部署需要更新的微服務。頻繁更新的速度將會加快。
  • 可擴展性與每個微服務無關。 您可以選擇根據應用程序所需的資源擴展它的每個組件。無需像單體應用程序那樣為一切內容構建多個實例。擴展微服務將會有效利用可用資源,而不是像在單體應用程序中那樣擁有整個應用程序的多個副本。 您為什麼應該使用微服務和容器?
    您為什麼應該使用微服務和容器?
  • 數據可以分散化處理。 您可以選擇為微服務使用不同的數據庫/存儲器。如果比起關係數據庫,您的微服務更適合使用非關係型數據庫,那麼就可以選擇這種數據庫。微服務也可能只需要簡單的密鑰存儲數據庫,比如 Redis。如下圖所示,您可以選擇組合使用 Cloudant、MySQL 和 MongoDB。您可以利用不同的數據庫來存儲不同的數據類型。 您為什麼應該使用微服務和容器?
    您為什麼應該使用微服務和容器?
  • 隔離故障。  一個微服務中的錯誤或缺陷不會使整個系統宕機。如果採用鬆散耦合的組件,您的應用程序中的微服務出現錯誤時,其他微服務不太可能受到影響,因為它們都在自己的容器中,不會完全依賴彼此。而對於單體應用程序,如果沒有正確找出缺陷或錯誤,就會使整個應用程序流程宕機。

存在哪些弊端?

在使用微服務解決單體架構的一些問題時,每種微服務都存在一系列問題。如果您試圖將單體應用程序拆分為微服務,那麼第一個挑戰就是如何拆分。您可以選擇將它們拆分為多個業務功能,比如一個微服務處理批次,另一個微服務處理支付服務。最後,您的組件應該只具有一小部分的功能或責任。

我在微服務架構中看到的一些問題如下:

  • 一旦微服務數量增長, 就會難以進行跟蹤 。持續集成和持續交付的初始設置工作也並非易事,因為您需要處理擁有多個微服務所帶來的額外複雜性。
  • 複雜性 。微服務需要加強協作,尤其是在有多個團隊參與的時候。如果需要與其他微服務交互,那麼微服務還會引進更多的網絡調用,而在單體應用程序中則不會出現這種情況。部署微服務並不像部署應用程序的一個實例那樣簡單。您還需要考慮其他很多問題:如何處理各個微服務之間的通信,解決錯誤以避免中斷其他微服務,以及在每個組件中添加更多測試用例。
  • 找到並跟蹤應用程序中的缺陷/錯誤。如果您的微服務只有一條路徑,那麼查找起來會比較容易,但如果一個微服務與其他多個微服務進行通信,僅查找錯誤就會耗費大量時間。 您為什麼應該使用微服務和容器?
    您為什麼應該使用微服務和容器?
  • 進行微服務路由需要完成更多工作。 您需要花時間來配置和控制微服務的流動。您還需要持續跟蹤微服務的版本,並解決其路由問題。 您為什麼應該使用微服務和容器?
    您為什麼應該使用微服務和容器?
  • 微服務會消耗比單體應用程序更多的資源。 雖然我提到的優點之一就是可以更出色、更有效地利用可擴展性和資源,但是所有組件都需要有自己的實例和容器,這可能就會導致內存和 CPU 使用量增多。

可幫助您使用微服務的工具

Kubernetes

免費試用 IBM Cloud

利用IBM Cloud Lite 快速輕鬆地構建您的下一個應用程序。您的免費帳戶從不過期,而且您會獲得 256 MB 的 Cloud Foundry 運行時內存和包含 Kubernetes 集群的 2 GB 存儲空間。了解所有細節並確定如何開始。如果您不熟悉 IBM Cloud,請查閱 developerWorks 上的 IBM Cloud Essentials 課程

Kubernetes 是一個容器編排平台,支持部署、擴展和管理所有容器。它可以自動部署容器化的微服務。這就更便於管理應用程序的所有組件和微服務。您可能會希望了解 Docker 如何實現微服務容器化。IBM 公開發佈了產品 IBM Cloud Kubernetes Service ,可以為您管理集群。

Istio

Istio 能夠解決微服務中的一些弊端。Istio 是一種服務網格,可進一步幫助您管理微服務。Istio 可以安裝在 Kubernetes 之上,幫助您跟蹤和監控微服務。同時,還可以幫助您快速跟蹤應用程序中可能存在的錯誤和缺陷。Istio 還可以管理微服務的流量,比如管理和控制流動。可以輕鬆配置路由。Istio 也可以在微服務中提供安全保障,比如採用相互 TLS,或限制它訪問外部服務。您也可以將 Istio 安裝到 IBM Cloud Kubernetes Service 上。

總結

根據我的個人經驗,使用容器編排平台是通過微服務構建應用程序的必要條件。Kubernetes 是廣受開發人員歡迎的一種平台,因為它可以快速將應用程序從開發階段帶入生產環境。更棒的是,它是開源的!

對於開始構建自己的應用程序的開發人員來說,他們應該確定使用微服務是否比使用單體應用程序對他們更有利。他們應該考慮應用程序的長期易用性和可擴展性。從單體架構着手完全沒有問題,但是一旦應用程序規模擴大,將它們拆分為微服務的難度只會更大。在這種情況下,在初期開發階段就從微服務開始顯然會更加有利。對於現有的單體應用程序,開發人員應該考慮以何種方式分離應用程序中的哪些組件。

儘管存在一些弊端,但微服務在開發人員和企業中仍然很受歡迎,因為微服務對於應用程序和滿足用戶需求都極為有利。一旦使用了合適級別的微服務,藉助它的靈活性,開發人員和企業就可以快速開發或更新應用程序。

本文翻譯自: Why should you use microservices and containers? (2018-11-01)

參考資源

原文 : IBM developerWorks中國

相關閱讀

免责声明:本文内容来源于IBM developerWorks中國,已注明原文出处和链接,文章观点不代表立场,如若侵犯到您的权益,或涉不实谣言,敬请向我们提出检举。