微服務架構基本原理學習筆記(一)

一、什麼是微服務

  微服務是一種技術架構,通常我們可以把它理解爲一組可以相互之間協同工作的應用程序或服務,這些應用程序或服務能夠被單獨部署到不同的服務器中,並且能夠自主運行和維護。

  微服務技術只是一個名稱而已,或許我們在日常工作中已經或多或少在使用其中的一種或幾種技術和架構,但我們並沒有將其稱之爲微服務。而且,對於微服務的大小和規模,也並沒有嚴格的限制,也許幾百行代碼或者數個文件,也或者比這個規模更大一點,都沒有關係。我們不應該在這一點上過多地糾結,而應該更多地去關心微服務到底解決了什麼問題?這纔是最主要的。

二、爲什麼需要微服務

  換句話說,微服務架構到底解決了什麼問題?要回答這個問題,我們先對比一下單體架構(Monolith)與微服務架構(Microservice)。

單體架構

  在單體架構中,代碼通常都放在一個代碼庫中,這就意味着所有的開發人員都必須基於同一個源代碼庫來工作。另外,單體架構的應用程序通常都運行在單一服務器或虛機中,並且數據被持久化到單個數據庫。其優點是:

  1. 開發環境比較簡單,所使用的技術棧統一。
  2. 所有的代碼和資源都在同一個代碼庫中,容易查找和定位錯誤。
  3. 應用程序的部署和更新操作比較容易,我們只需要在一臺服務器或虛機上替換掉舊的應用程序即可。

  單體架構有其自身的優點,如果你的應用程序符合這一定位並且運行良好,那麼其實你完全沒有必要使用微服務架構,或者說目前暫時還不需要。但是,當應用程序的規模不斷增加時,問題就會逐漸被暴露出來。隨着代碼庫變得越來越大,複雜性也會顯著增加,其中積累的技術債也會越來越多,最終會導致代碼變得難以維護,而且各個模塊間的依賴關係也會非常複雜,往往一個小的功能調整也會涉及到許多代碼的改動。

  另外一個問題就是單體應用程序的更新部署往往會導致服務的中斷,從而影響到整個產品的用戶體驗和可用性。

  最後就是單體應用程序的功能擴展往往比較困難。當訪問量增加時,我們除了增加服務器的配置和數量外(垂直擴展),無法簡單地對程序進行橫向擴展和功能擴充。這個時候你會發現,無論你採用何種技術棧,都無法擺脫單體架構本身所帶來的這些問題,你所要考慮的是調整整個應用程序的架構,使其更符合敏捷開發模式的思維。

  有一點值得注意的是,我們需要將傳統的分佈式單體架構與微服務架構區別開來。

  所謂分佈式單體架構,是指將組成應用程序的各個不同的模塊或服務部署在不同的服務器或虛機中,它們都共享同一個中央數據庫,彼此之間相互關聯,形成一個緊耦合的結構。任何一個模塊或服務的缺失都會導致整個應用程序無法正常工作。同時,這種結構也會給更新和部署帶來挑戰。

微服務架構

  在微服務架構中,我們將應用程序分解成足夠小的部分,每一部分可以有自己獨立的源代碼庫並且由不同的小型開發團隊來進行開發和維護。就每一個微服務而言,其開發成本相對較低,隨着項目的迭代,在必要的時候也可以丟棄某些微服務或者完全改寫部分微服務。

  項目中的每一個微服務都可以自由選擇所使用的技術和開發工具。你完全可以在其中一個微服務中使用關係型數據庫,而在另一個微服務中使用文檔型數據庫。也可以在一個微服務中使用函數式編程語言(例如JavaScript或者Python),而在另一個微服務中使用面向對象編程語言(例如C#或Java)。每一個微服務的開發團隊都可以自由選擇最合適的技術。

  由於微服務之間是松耦合的,每一個微服務可以單獨部署和運行,這樣我們就可以實現整個應用程序的零宕機更新。而且如果有需要,每一個微服務也可以隨時重新發布和更新,而不影響整個應用程序的運行。

  另外,根據需要我們也可以非常方便地對單個微服務進行擴展,從而將成本控制在最低。

  微服務架構的這些特性更加符合敏捷開發的原則,從而使得我們可以更快地適應不斷變化的業務和需求。我想這也是爲什麼近年來微服務架構變得如此流行的原因之一。

  不過,在使用微服務架構之前,你需要首先了解下面這些你將要面對的挑戰:

  1. 初始化並運行每個微服務,然後在整個應用程序的上下文中進行測試。由於每個微服務所使用的技術不同,運行的環境也千差萬別,所以從下載源代碼開始,你可能需要花費比較多的時間才能讓這些微服務運行起來。考慮使用容器來自動完成所有這些預備步驟是一個不錯的選擇。
  2. 由於微服務之間的交互往往非常複雜,如果處理不當,你會很容易地陷入到多個微服務之間大量低效而冗長的通信陷阱中,這會導致整個應用程序性能低下。
  3. 雖然單個微服務的部署較爲容易,但是當大量微服務同時工作時,手動部署和更新將變得更加低效和繁瑣。因此,自動化部署將變得至關重要。
  4. 最後一點就是監控微服務的運行。我們當然不希望逐個地去檢查每個微服務當前的運行狀態,而是希望這些微服務能夠自動報告它們的運行狀況。因此,我們需要一種監控機制,能夠讓系統管理員在一個集中的地方查看所有微服務的運行日誌和數據。

  不過,你不用太擔心,有許多開源的軟件和工具能夠幫忙我們解決上述這些問題。

  Github上一個非常好的例子eShopOnContainers可以用來幫助我們學習和理解微服務架構。下面是這個項目的微服務架構圖:

 

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