這個小系列的前兩個部分介紹了如何使用WildFly Swarm構建一個微型JAX-RS服務并將其打包到Docker映像中 。 您學習了如何將此示例部署到OpenShift ，現在該進行一點擴展了。

為什么擴展很重要

基于微服務的體系結構的關鍵方面之一是分解為高性能的單個服務，這些服務可以按需擴展并且在技術上很容易。 現在正在構建應用程序以擴展規模，并在必要時透明地提供基礎結構幫助。 盡管Java EE開發人員過去在標準水平縮放方面做了很多工作，但它們通過將更多的物理框彼此相鄰放置，或者通過在同一主機上旋轉更多實例來限制垂直縮放。 微服務允許使用不同的擴展方法。 關于縮放比例不同變化的更完整定義可以在《可縮放性的藝術》一書中找到。 我將在以后的博客文章中探討不同的方法。 為了使擴展變得更容易一點，我們今天將通過旋轉更多的pod來垂直擴展我們的小型應用程序。

什么是豆莢

吊艙（例如在鯨魚或豌豆吊艙中）是Kubernetes對象，它對應于在共享上下文中運行的同一組應用程序。 就Docker結構而言，一個容器由一組共享容器的Docker容器組成。 在前容器世界中，它們將在同一物理或虛擬主機上執行。 因此，這就是我們在本示例中要擴展的內容。 已運行的Pod。

到目前為止，我們做了什么？

當您首次部署JAX-RS示例時，OpenShift創建了很多資源。 即：

• Imagestream ：圖像流類似于Docker圖像存儲庫，其中包含一個或多個由標簽標識的Docker圖像。 OpenShift存儲有關每個圖像的完整元數據（例如，命令，入口點，環境變量等）。 OpenShift中的圖像是不可變的。 OpenShift組件（例如構建和部署）可以觀看圖像流并在添加新圖像時接收通知，例如通過執行構建或部署來做出反應。
• 服務 ：Kubernetes服務充當內部負載平衡器。 它標識一組復制的Pod，以便代理它接收到的連接。
• DeploymentConfig ：OpenShift在復制控制器的基礎上，通過部署概念增加了對軟件開發和部署生命周期的擴展支持。 OpenShift部署還提供了從映像的現有部署過渡到新映像的功能，并且還定義了在創建復制控制器之前或之后運行的掛鉤。

因此，服務將我們的請求代理到Pod，并且在Kubernetes復制控制器之上構建了一個deployconfig，該控制器控制Pod的數量。 我們越來越近了！

請立即擴展我的微服務！

只需再延長一秒鐘，就可以了：盡管服務為可能突然出現或不存在的Pod提供了路由和負載平衡，但ReplicationController（RC）用于指定并強制應存在的Pod（副本）的數量。 可以認為RC與服務處于同一級別，但是它們在pod上方提供不同的功能。 RC是Kubernetes對象.OpenShift在RC頂部提供了一個稱為``部署配置（DC）''的``包裝''對象。 DC不僅包含RC，而且還允許您定義映像之間的過渡以及部署后掛鉤和其他部署操作的發生方式。

我們終于知道要看哪里了。 讓我們看一下啟動集群樣本映像時創建的DeploymentConfig的外觀。

oc get dc swarm-sampleNAME ? ? ? ? ? TRIGGERS ? ? ? ? ? ? ? ? ? ?LATEST VERSION swarm-sample ? ConfigChange, ImageChange ? 1

即使RC控制Pod的縮放比例，它們也封裝在一個更高的結構DeploymentConfig中，該結構還管理何時，何地以及如何部署這些Pod / RC。 我們仍然可以看到底層的RC ：（注意：輸出被截斷）

oc get rc swarm-sample-1CONTROLLER ? ? ? CONTAINER(S) ? IMAGE(S) ? REPLICAS swarm-sample-1 ? swarm-sample ? 172.30.101.151:5000/myfear/swarm-sample@sha256:[...] ? 1

現在我們需要知道我們要進行的縮放是否確實有效。 我確實推送了一個curl腳本 ，該腳本從JAX-RS端點輸出結果，并休眠2秒鐘，然后再次請求輸出。 啟動它，并觀察返回全部相同主機名環境變量的結果，直到執行以下命令：

oc scale dc swarm-sample --replicas=3

現在一切都發生了變化，過了一會兒，您將看到返回了三個不同的主機名。 可能需要一段時間（具體取決于您的計算機以及OpenShift旋轉新Pod的速度。您還可以在管理控制臺中看到更改，該控制臺現在顯示三個Pod。

我們可以通過將副本數設置回1來還原行為。

oc scale dc swarm-sample --replicas=1

那很簡單。 并沒有完全被認為是最佳實踐。 因為所有Pod共享相同的上下文，所以它們永遠不應在同一臺物理計算機上運行。 相反，最好在同一RC內的三個Pod上運行完整的微服務（前端，后端，數據庫）。 但這是更多博客文章發表的主題。 現在您已經了解了如何在OpenShift上縮放Pod，我們可以繼續進一步擴展示例應用程序，并在以后進行更多縮放示例。

翻譯自: https://www.javacodegeeks.com/2015/10/scaling-java-ee-microservices-on-openshift.html

總結

以上是生活随笔為你收集整理的在OpenShift上扩展Java EE微服务的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。