Java 微服務指南。第 2 部分：部署與測試

《Java微服務：實用指南》的 翻譯與改編。指向指南第一部分的連結。 任何伺服器端 Java 程式以及任何微服務都只是一個副檔名為 .jar 或 .war 的檔案。Java 生態系統（或更確切地說JVM）有一個很棒的事情：您只需要編寫一次Java 程式碼，它就可以在幾乎任何作業系統上運行，只要您沒有使用比您的版本更新的Java 版本來編譯程式碼。目標 JVM 版本。理解這一點很重要，尤其是當涉及 Docker、Kubernetes 或（擊鼓！）雲端等主題時。為什麼？讓我們看看不同的部署場景。

簡約 Java 微服務部署範例

讓我們繼續以銀行為例。因此，我們有一個 monobank.jar 檔案（monolith）和新提取的riskengine.jar（第一個風險檢查微服務）。我們還假設這兩個應用程序，就像世界上所有其他應用程式一樣，都需要一個 .properties 檔案。在我們的例子中，它僅包含資料庫 URL 和憑證。最小部署可能包含兩個如下所示的目錄：首先：

-r-r------ 1 ubuntu ubuntu     2476 Nov 26 09:41 application.properties
-r-x------ 1 ubuntu ubuntu 94806861 Nov 26 09:45 monobank-384.jar

ubuntu@somemachine:/var/www/www.monobank.com/java$ java -jar monobank-384.jar

  .   ____          _            __ _ _
 /\\ / ___'_ __ _ _(_)_ __  __ _ \ \ \ \
( ( )\___ | '_ | '_| | '_ \/ _` | \ \ \ \
...

第二：

-r-r------ 1 ubuntu ubuntu     2476 Nov 26 09:41 application.properties
-r-x------ 1 ubuntu ubuntu 94806861 Nov 26 09:45 risk-engine-1.jar

ubuntu@someothermachine:/var/www/risk.monobank.com/java$ java -jar risk-engine-1.jar

  .   ____          _            __ _ _
 /\\ / ___'_ __ _ _(_)_ __  __ _ \ \ \ \
( ( )\___ | '_ | '_| | '_ \/ _` | \ \ \ \
...

這就留下了一個懸而未決的問題：.properties 和 .jar 檔案將如何到達伺服器？不幸的是，答案可能有很多。

如何使用建置工具、SSH 和 Ansible 部署 Java 微服務

關於如何部署 Java 微服務的建議很無聊，但同樣出色……實際上，這正是過去 20 年來系統管理員在公司中部署任何 Java 伺服器程式的方式。這是混合：

• 你最喜歡的建置工具（Maven、Gradle）
• 很好的舊 SSH/SCP，用於將 .jar 複製到伺服器
• 用於管理部署腳本和伺服器的 Bash 腳本
• 甚至更好：一些 Ansible 腳本。

當然，這並不適合需要「會呼吸」的雲端、具有自動負載平衡功能的伺服器等的創新者。這真是無聊的老派。然而它有效！

如何使用Docker部署Java微服務

讓我們回到選擇的甜蜜痛苦。幾年前，Docker 出現了，隨之而來的是容器化。如果您從未使用過它，這裡有一個針對最終用戶和開發人員的簡短描述：

• 容器（簡化版）類似於老式的虛擬機，但「更輕」。如果您不清楚「更簡單」在這種情況下的含義，請查看Stackoverflow 上的這個答案。
• 容器保證了自身的可移植性。也就是說，它在任何地方都有效。聽起來很熟悉，不是嗎？

有趣的是，考慮到 JVM 的可移植性和向後相容性，這個功能似乎並不是一個優勢。您只需在任何 Raspberry Pi（甚至手機）上下載 JVM.zip，將其解壓縮並運行任何 .jar 檔案。PHP 或 Python 等語言的情況會發生變化，其中版本不相容或部署設定更加複雜。或者，如果您的 Java 應用程式依賴許多其他已安裝的服務（具有正確的版本號）：例如 Postgres 資料庫或 Redis 鍵值儲存。因此，Docker 對於 Java 微服務（或更準確地說對於 Java 應用程式）的主要優勢是：能夠使用Testcontainers等工具設定同質化測試或整合環境。複雜的開發更容易安裝。以Discourse論壇軟體為例。您可以使用單一 Docker 映像來安裝它，該映像包含您需要的一切，從使用 Ruby 編寫的 Discourse 軟體到 Postgres 資料庫，再到 Redis 和廚房水槽。如果您的部署類似或您想執行一個漂亮的小型 Oracle 資料庫，請嘗試 Docker。總而言之，您現在不只是查看 .jar 文件，而是：

• 將您的 jar 檔案捆綁到 Docker 映像中
• 將此映像推送到私有 Docker 註冊表
• 在您的目標平台上拉取並運行此映像
• 或直接將 Docker 映像複製到生產系統並運行。

如何使用 Docker Swarm 或 Kubernetes 部署 Java 微服務

假設您決定嘗試 Docker。每次部署 Java 微服務時，您都會建立一個捆綁 .jar 檔案的 Docker 映像。假設您有幾個這樣的 Java 微服務，並且您希望將這些服務部署在多台電腦上（在叢集中）。那麼問題來了：如何管理這個叢集？運行 Docker 容器、檢查效能、部署更新、擴充系統 (brrr)？這個問題的兩個可能的答案是 Docker Swarm 和 Kubernetes。詳細介紹這兩個選項會使這個已經很長的教程變得太長，但我們認為重要的是要提到這兩個選項最終都依賴於您編寫 YAML 檔案（請參閱Yaml縮排故事）來管理集群。如果你想知道這在實踐中會引起什麼感受，只需在 Twitter 搜尋中輸入類似的查詢即可。因此，Java 微服務的部署過程現在看起來像這樣：

• 配置和管理 Docker Swarm/Kubernetes
• Docker 的所有步驟（見上文）
• 寫作並執行 YAML，直到你的眼睛流血，直到一切正常。

如何測試 Java 微服務

假設您決定在生產中實施微服務。現在開發過程中如何測試n微服務整合？如何查看整個工作流程（而不僅僅是部分工作流程）是否正常運作？在實踐中，您可以使用以下三種方法之一：

1. 只需做一點工作（如果您使用的是Spring Boot 等框架），您就可以將所有微服務組合到一個啟動器類中，並使用單個Wrapper.java 類加載所有微服務- 取決於您的計算機上是否有足夠的記憶體來運行你所有的微服務。
2. 您可以在本機複製 Docker Swarm 或 Kubernetes 設定。
3. 只是不再在本地運行整合測試。相反，部署專用的開發/測試環境。這是很多團隊在屈服於本地微服務設定的痛苦時實際上所做的事情。

此外，除了 Java 微服務之外，您可能還需要一個正在執行的訊息代理程式（例如 ActiveMQ 或 RabbitMQ）或電子郵件伺服器或 Java 微服務需要相互通訊的任何其他訊息元件。這導致 DevOps 方面的複雜性被嚴重低估。看看微服務測試庫，它們可以減輕這種痛苦。無論如何，這種複雜性為我們帶來了微服務的一般問題，我們現在將討論這些問題。在最後一部分中，我們將討論 Java 微服務的一般問題。