認識微服務

微服務是一種使用多個小元件建置複雜應用的方法。 本文介紹了它的工作原理、優缺點及其可帶來的優勢。

什麼是微服務?

微服務是一種利用多個小元件(每個元件執行一種功能,例如身份驗證、通知或支付處理)建置大型複雜應用的軟體架構方法。 每個微服務都是軟體開發專案中的一個獨立單元,具有自己的代碼庫、基礎設施和資料庫。 微服務協同工作,通過 Web API 或消息排程進行通訊,以對傳入事件作出回應。

Fvz96suuunwmyaenmqswis3xzy3az0k9x4zrhopq
簡化微服務架構

為什麼採用微服務架構?

在傳統單體架構中,一個應用的所有功能均在單個代碼庫中實現。 這種方法有幾個弊端:

  • 隨著應用日趨複雜,任何一位開發人員都很難弄清整個代碼庫。 新入職的開發人員也很難上手。 一個解決辦法是將不同的功能模組分配給不同的開發人員或團隊,這樣開發人員可以更輕鬆地掌控自己的代碼,但問題是會更難跟蹤與其他模組的依賴關係。 因此,一個模組的變更很有可能會影響其他模組。
  • 當您需要添加或增強功能時,您必須編譯並測試整個應用,以驗證該變更是否會破壞模塊之間的相容性。 然後將整個應用作為單個二進位檔進行部署。

而微服務架構則將應用功能劃分成多個獨立的微型服務(service),有助於簡化 CI/CD。 微服務開發速度更快且更易於理解和維護。 每個服務均可由只專注於該服務的團隊獨立開發。 該團隊可以選擇最適合微服務的程式設計語言、開發平臺和資料庫。 微服務通常封裝為容器,以進一步簡化部署。

微服務具有鬆散耦合性,這意味著它們不依賴於其他微服務的內件。 它們之間通過 API 進行通訊。 只要每個微服務暴露的 API 保持向後相容,對一個微服務進行更改時,便無需更新其他任何微服務。

簡而言之,想要在微服務架構中進行修改的開發人員可以在單個微服務容器中執行這一操作,而在單體架構中操作的開發人員則可能不得不耗費大量的時間來重寫整個堆疊。

NGINX

微服務使用者

為了快速響應不斷變化的企業需求,技術團隊紛紛轉而採用微服務架構。 開發人員正引領這一變革,這在很大程度上是因為更多企業授予了開發人員選擇應用和交付工具的許可權。 2020 年開展的一項 NGINX 使用者調查顯示,超過一半的受訪者在其部分或全部應用中使用微服務。  2022 年,在正棄用單體系統的公司工作的更多 NGINX 使用者表示,之所以採用微服務,在一定程度上是因為容器編排所允許的可擴充性。

微服務 101:優缺點

微服務可將傳統的單體應用轉變為更加靈活、安全且高效的架構,從而説明您節省大量時間、成本和資源。下面總結了微服務的優缺點,這些優缺點可能影響應用性能和設計。

優點:

  • 開發人員可以自由地獨立開發和部署服務,從而提高決策速度。
  • 得益於微服務的小規模和自主性,基於微服務的方法能夠縮短開發週期,因為不同的團隊可以同時實現不同的服務。 團隊之間的依賴性通常會減弱甚至消除。
  • 微服務可輕鬆地部署至容器,有助於減少開銷並提高跨不同環境的可移植性。
  • 由於微服務很容易與 CI/CD 工具整合,因此開發人員可實施現代 DevOps 實踐,例如自動化 CI/CD 流水線。
  • 輕鬆擴展應用,按需「調整大小」,因為通常每個服務都彈性十足。
  • 微服務更易於建置、測試和維護。
  • 服務圍繞企業功能組織實施。
  • 開發人員可以採用最適合特定服務的技術。
  • 更輕鬆地隔離故障——如果一個微服務發生故障,其他微服務仍可繼續運行。

缺點:

  • 微服務架構會加劇複雜性,因為開發人員必須降低容錯率,縮短網路延遲,處理不同的程式設計語言,並跨多個服務實現負載均衡。
  • 由於微服務具有分散式特性,因此微服務故障排除可能繁瑣複雜。
  • 增加應用中的微服務數量會增加整合和管理工作。
  • 處理多個資料庫

API 是微服務嗎?

簡而言之,不是。 API 本身不是微服務。 但 API 正越來越多地作為應用內的通訊機制整合到微服務架構中。一個微服務的功能暴露為一組 API 端點,其他微服務通過對相應端點進行 API 調用來調用該功能。

為什麼使用容器來運行微服務?

容器化平臺支持開發人員以不受基礎設施限制的最高效方式隔離、擴展並部署微服務,同時最大限度地減少對用戶的干擾。 設想這樣一種情景:在您的應用前面部署單個負載均衡和流量路由伺服器整合。 借助在 DNS 中發佈的靜態公共 IP 位址,用戶端可將其請求發送到這個穩定的入口點,然後該請求會被轉發到相應的容器。 如果添加或刪除這些容器,只需更新內部位址即可將這些請求定向到新的 IP 位址。 您也可以通過 DNS 在內部發佈這些位址。

微服務案例

微服務加速了受嚴格管制行業中的無縫安全遷移

一間身處受嚴格監管行業的跨國公司必須按照規定的時程表升級其系統,以確保遵守不斷演進的標準和最佳實踐。 這家公司的應用組合每天通過其系統處理數百萬筆交易。 多年來,即使在開源升級和第三方安全外掛程式整合期間,該公司仍然遵守行業要求。 然而,在最近的一次升級中,由於外掛程式互斥問題,該公司遇到了一些難題。 該公司曾考慮從數據中心遷移到 AWS 公有雲,但安全外掛程式問題促使其遷移到了微服務架構。 這種解決方案的成本更低,並可説明該公司快速實現安全合規。

文章來源:NGINX