openshift_在OpenShift上扩展Java EE微服务

openshift

这个小系列的前两个部分介绍了如何使用WildFly Swarm构建一个小型的JAX-RS服务并将其打包到Docker映像中 。 您学习了如何将此示例部署到OpenShift ，现在是时候对其进行一些扩展了。

为什么扩展很重要

基于微服务的体系结构的关键方面之一是分解为高性能的单个服务，这些服务可以按需扩展并且在技术上很容易。 现在正在构建应用程序以扩展规模，并在必要时透明地提供基础结构帮助。 尽管Java EE开发人员过去在标准水平缩放方面做了很多工作，但它们通过将更多的物理框彼此相邻放置，或者通过在同一主机上旋转更多实例来限制垂直缩放。 微服务允许使用不同的扩展方法。 关于缩放比例不同变化的更完整定义可以在《可缩放性的艺术》一书中找到。 我将在以后的博客文章中探讨不同的方法。 为了使扩展变得更容易一点，我们今天将通过旋转更多的Pod垂直扩展我们的小小的应用程序。

什么是豆荚

吊舱（例如在鲸鱼或豌豆吊舱中）是Kubernetes对象，它对应于在共享上下文中运行的同一组应用程序。 就Docker结构而言，一个Pod由一组共享容器的Docker容器组成。 在前容器世界中，它们将在相同的物理或虚拟主机上执行。 因此，这就是我们在此示例中要扩展的内容。 已运行的Pod。

到目前为止，我们做了什么？

当您首次部署JAX-RS示例时，OpenShift创建了很多资源。 即：

• Imagestream ：图像流类似于Docker图像存储库，其中包含一个或多个由标签标识的Docker图像。 OpenShift存储有关每个图像的完整元数据（例如，命令，入口点，环境变量等）。 OpenShift中的图像是不可变的。 OpenShift组件（例如构建和部署）可以观看图像流并在添加新图像时接收通知，例如通过执行构建或部署来做出React。
• 服务 ：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-sample

NAME           TRIGGERS                    LATEST VERSION
swarm-sample   ConfigChange, ImageChange   1

即使RC控制Pod的缩放比例，它们也封装在一个更高的结构DeploymentConfig中，该结构还管理这些Pod / RC的部署时间，地点和方式。 我们仍然可以看到底层的RC ：（注意：输出被截断）

oc get rc swarm-sample-1

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

现在我们需要知道我们要进行的缩放是否确实有效。 我确实推送了一个curl脚本 ，该脚本从JAX-RS端点输出结果，并Hibernate2秒钟，然后再次请求输出。 启动它，并观察返回全部相同主机名环境变量的结果，直到执行以下命令：

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