scope hosting_Java Cloud Hosting Services的成本降低策略

scope hosting

重要要点

• 随着项目的增长，您需要迁移到更大的VM。 但是，如果下一步行动超出了您的要求，则您付出了过多
• 容器比虚拟机具有更高的粒度，并且可以在不重新启动运行实例的情况下垂直扩展
• 可以将单片和旧版应用程序从VM迁移到系统容器，而无需修改设置
• 垂直扩展Java需要正确的JVM配置，以及缩小的垃圾收集器
• “按需付费”与“按需付费”云定价模型以及提高效率的正确选择

云资源可能会很昂贵，尤其是当您被迫支付不需要的资源时； 另一方面，资源短缺会导致停机。 开发人员要做什么？ 在本文中，我们将讨论确定黄金媒介的技术，该媒介可让您仅支付实际消耗的资源，而不受应用程序容量需求规模的限制。

承认您为VM多付了钱

当然，任何解决方案的第一步都是承认您有问题。 以下是许多云用户所面临的问题的一些详细信息。

几乎每个云供应商都可以从各种不同的VM大小中进行选择。 选择合适的虚拟机大小可能是一项艰巨的任务。 太小，您可能会在负载高峰期间触发性能问题甚至停机。 过度分配？ 然后，在正常负载或空闲期间，所有未使用的资源都被浪费了。 通过您自己的云托管应用程序，这种情况看起来是否很熟悉？

当项目开始水平增长时，资源效率低下的问题在每个实例中都会重复出现，因此问题按比例增长。

此外，如果您只需要向同一VM添加更多资源，那么大多数当前云供应商的唯一出路就是将VM大小增加一倍。 请参阅下面的AWS产品样本。

（点击图片放大）

加剧该问题的是，您需要在移动时导致停机，方法是停止当前VM，执行应用程序重新部署或迁移的所有步骤，然后处理不可避免的相关挑战。

这表明虚拟机在资源使用方面不够灵活和高效，并且会根据可变负载限制调整。 这种缺乏弹性直接导致支付过多。

查找如何有效地按比例放大和缩小

如果横向扩展无法有效地利用资源，那么我们需要深入研究虚拟机，以更深入地了解如何实现垂直扩展。

垂直扩展会根据其当前负载优化任何实例的内存和CPU使用率。 如果配置正确，那么这对于单片和微服务都将是完美的。

在不停机的情况下通过动态添加或删除资源来在VM内部设置垂直扩展是一项艰巨的任务。 VM技术提供内存膨胀 ，但是它不是完全自动化的，需要工具来监视主机和来宾OS中的内存压力，然后根据需要激活放大或缩小。 但这在实践中效果不佳，因为内存共享应该是自动的以便有用。

借助cgroups的帮助，容器技术可以在同一主机上的容器之间实现开箱即用的自动资源共享，从而将灵活性提升到一个新的高度。 限制范围内未消耗的资源将自动与在同一硬件节点上运行的其他容器共享。

并且与VM不同，无需重新启动正在运行的实例，即可轻松扩展容器中的资源限制。

因此，与迁移到较大的VM相比，动态调整同一容器的大小更容易，更便宜，而且更快。

从VM迁移到容器

容器有两种类型-应用程序容器和系统容器。 应用程序容器（例如Docker或rkt）通常只需要一个进程即可运行，而系统容器（LXD，OpenVZ）的行为就像完整的OS，并且可以运行功能齐全的init系统，例如systemd，SysVinit和openrc，允许进程在单个容器中一起生成其他进程，例如openssh，crond或syslogd。 两种类型都支持垂直扩展和资源共享，以提高效率。

理想情况下，您希望从头开始围绕应用程序容器设计新项目，因为使用公开可用的Docker模板创建所需的映像相对容易。 但是有一个普遍的误解，即容器仅适用于未开发的应用程序（微服务和云原生）。 经验和用例证明了将现有工作负载从VM迁移到容器的可能性，而无需重写或重新设计应用程序。

对于单片和旧版应用程序，最好使用系统容器，以便您可以重用原始VM设计中实现的体系结构，配置等。 使用多播等标准网络配置，在容器内运行多个进程，避免内存限制确定不正确的问题，在容器重启时写入本地文件系统并确保其安全，以已建立的方式对问题进行故障排除和分析日志，并使用多种基于SSH的配置工具，并且可以自由地依赖其他重要的“老派”任务。

要从VM迁移，应将整体应用程序拓扑分解为分布在一组互连容器之间的小逻辑块。 下图显示了分解过程的简单表示。

每个应用程序组件应放置在隔离的容器内。 这种方法通常可以简化应用程序拓扑，因为在新体系结构中项目的某些特定部分可能变得不必要。

例如，Java EE WebLogic Server主要由在VM中运行所需的三种实例组成：管理服务器，节点管理器和受管服务器。 分解之后，我们可以摆脱节点管理器角色，该节点管理器角色被设计为VM代理，用于添加/删除受管服务器实例，因为它们现在将由容器自动添加，并使用容器编排平台直接附加到管理服务器上，并且一组WLST（WebLogic Server脚本工具）脚本。

要继续进行迁移，您需要准备所需的容器映像。 对于系统容器，该过程可能比应用程序容器复杂一些，因此，您可以自己构建它，或者使用像Jelastic这样的编排器以及预配置的系统容器模板 。

最后，部署项目本身并配置所需的互连。

现在，每个容器都可以在不停机的情况下即时缩放。 与虚拟机相比，它要薄得多，因此与通过VM进行扩展相比，此操作花费的时间要少得多。 而且，由于可以轻松地从头开始配置或克隆容器，因此水平缩放过程变得非常细腻且平滑。

启用具有内存缩减功能的垃圾收集器

要垂直扩展Java，仅使用容器是不够的。 您还需要正确配置JVM。 具体来说，您选择的垃圾收集器应在运行时减少内存。

与非缩减GC或非最佳JVM启动选项相比，此类GC将所有活动对象打包在一起，删除垃圾对象，取消提交并将未使用的内存释放回操作系统，在Java应用程序中Java应用程序保留所有已提交的RAM并且无法缩放根据应用程序负载垂直放置。 不幸的是，JDK 8默认的并行垃圾收集器（-XX：+ UseParallelGC）没有缩小，并且不能解决JVM的RAM使用效率低下的问题。 幸运的是，这可以通过切换到垃圾优先 （-XX：+ UseG1GC）轻松解决。

让我们看下面的例子。 即使您的应用程序具有较低的RAM利用率（图中的蓝色），未使用的资源也无法与其他进程或其他容器共享，因为它们已完全分配给JVM（橙色）。

（点击图片放大）

但是，对于Java生态系统来说，好消息是，从JDK 9开始，默认情况下启用了现代收缩的G1垃圾收集器。 它的主要优点之一是能够压缩可用的内存空间，而无需花费较长的GC暂停时间和不提交未使用的堆的能力。

如果使用低于9版本的JDK，请使用以下参数启用G1：
-XX：+ UseG1GC

以下两个参数配置内存资源的垂直扩展：

• 设置Xms-缩放步骤
• 设置Xmx-最大缩放限制

此外，应用程序应在低负载或空闲阶段定期调用Full GC，例如System.gc（）。 该过程可以在应用程序逻辑内部实现，也可以在外部Jelastic GC Agent的帮助下实现自动化。

在下图中，我们显示了激活以下JVM启动选项的结果，其增量时间增长了约300秒：

-XX：+ UseG1GC -Xmx2g -Xms32m

（点击图片放大）

该图说明了与以前的样本相比，资源利用率的显着提高。 保留的RAM（橙色）随着实际使用量的增长（蓝色）而缓慢增加。 并且，在最大堆限制内的所有未使用资源都可以供同一主机中运行的其他容器或进程使用，而不会因闲置而浪费。

这证明了容器技术和G1的组合在云中Java应用程序的资源使用方面提供了最高的效率。

选择按需付费模式的云

最后（但并非最不重要）的重要步骤是选择具有“按使用付费”定价模式的云提供商，以便仅根据消耗量进行收费。

云计算通常与用电量进行比较，因为它可以按需提供资源并提供“按需付费”模型。 但有一个主要区别-使用更多电量时，电费不会增加一倍！

大多数云供应商都提供“按需付费”的计费模型，这意味着可以从较小的计算机开始，然后随着项目的增长添加更多服务器。 但是，如上所述，您不能简单地选择完全适合您当前需求并随您扩展的大小，而无需采取一些额外的手动步骤和可能的停机时间。 因此，您需要为这些限制支付费用-首先是一台小型计算机，然后是两倍的大小，最后是横向扩展到几个未充分利用的VM。

与此相反，“按使用付费”计费方法会考虑当前应用程序实例的负载，并即时提供或回收任何所需资源，这要归功于容器技术。 因此，您是根据实际消耗量付费的，不需要进行复杂的重新配置以扩大规模。

（点击图片放大）

但是，如果您已经锁定了运行VM的供应商，并且为限制支付了费用而又不准备更改它，那么仍然有可能的解决方法来提高效率并节省资金？ 您可以采用大型VM，在内部安装容器引擎，然后从所有小型VM迁移工作负载。 这样，您的应用程序将在VM内的容器内部运行-一种“分层蛋糕”，但它有助于整合和压缩已使用的资源，以及释放和共享未使用的资源。

实现垂直扩展的好处有助于快速消除一系列性能问题，通过草率地实施水平扩展来避免不必要的复杂性，并减少云支出，而无论应用程序类型是整体还是微服务。

翻译自: https://www.infoq.com/articles/java-cloud-cost-reduction/?topicPageSponsorship=c1246725-b0a7-43a6-9ef9-68102c8d48e1

scope hosting