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

為什么擴展很重要

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

什么是豆莢

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

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

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

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

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

請立即擴展我的微服務(wù)！

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

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

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

即使RC控制Pod的縮放比例，它們也封裝在一個更高的結(jié)構(gòu)DeploymentConfig中，該結(jié)構(gòu)還管理何時，何地以及如何部署這些Pod / RC。 我們?nèi)匀豢梢钥吹降讓拥腞C ：（注意：輸出被截斷）

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

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

oc scale dc swarm-sample --replicas=3

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

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

oc scale dc swarm-sample --replicas=1

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

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

總結(jié)

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

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。