用例-使用Docker、Mesosphere、Artifactory和Bintray连续部署到未知领域

讨论转录:

吉拉德:好吧。下面讲VMware中如何进行CI/CD流程。首先，我要向你们解释一下什么是通用SaaS平台。这只是VMware内部正在开发的东西。别担心。不是产品演讲。我不是卖产品的，我们也不卖产品。所以你很适合。在此之后，我们将详细讨论通用SaaS平台的CI/CD流程。CSP。 Then we’re going to go on how do we upgrade CSP once it’s in production. And if we have time, I will talk a bit about Xenon, which is a distributed control plane open source framework from VMware.

我叫吉拉德。我是VMware的架构师。和我在一起的是Kiril Nesenko我们的DevOps主管。我们在云提供商软件方面工作[…]。这只是我们为云提供商开发服务的一种华丽的说法。

你可能会问自己:服务?VMware吗?在座有多少人知道VMware有服务。当然，VMware的人除外。是的，我们最出名的是vSphere，但VMware正从一家以产品为基础的公司转型为一家以软件为基础的公司。但这并不意味着我们要抛弃vSphere。当然，vSphere是一个伟大的产品，我们将继续开发它。但我们正在进行转型，我们正在尝试——我们开始开发SaaS产品，过去两年我们一直在做这件事。因此，在我们开发SaaS的过程中，我们注意到许多服务在VMware内部都有一个需要连接的共同点。所有-大多数服务需要连接到VMware计费系统，身份系统，VMware ID，所以当你登录到服务时，你不需要创建一个新帐户，你可以使用你现有的VMware ID帐户(如果你有的话)。 And other capabilities such as monitoring and telemetry.

我们的发现并不令人惊讶，开发人员更喜欢写业务逻辑。谁写过与计费系统的集成?这不是一个有趣的过程。在好的情况下，你有一个基于soap的类似接口，在最坏的情况下，你需要发送一些mqp服务器和大量的XML，这真的不是很有趣。

所以，像优秀的工程师一样，我们决定[…]我们的努力，并创建一个平台，VMware内部服务将运行并与该平台集成。该平台将为他们完成繁重的工作，并集成到VMware内部的计费系统和标识系统中。

这个平台就是我和基里尔一直在搭建的。它被称为通用SaaS平台或CSP。所以在设计SaaS平台时，我们制定了一套设计原则。我们的首要原则是我们的平台应该与云无关。它可以运行在VMware外部或VMware内部的任何云提供商上。当然，如果没有高可用性和可扩展性，SaaS是无法实现的。这是我们拥有的另外两个设计原则。我们的平台应该有很棒的公共api，这样使用我们平台的内部服务就会有很棒的体验而不是糟糕的体验。我们的平台应该是模块化的。我们应该有能力向平台添加功能，甚至在关闭某些功能或缺少某些功能的情况下发布我们的平台。 And finally our platform should be easy to operate once in production and easy to develop when you’re in the development phase.

这些设计原则是如何付诸实践的呢?因此，为了做到与云无关，我们决定，我们唯一希望运行我们平台的基础设施能够支持容器。所以我们使用CSP的主要工件是一个运行jar的容器。我相信大多数云提供商都可以支持容器。对于高可用性，我们使用可调的一致性，我们的大多数数据最终是一致的。而且我们的平台是有状态的，而不是无状态的。我们没有单独的数据库后端。我们把所有的数据都存储在平台本身。我们使用文件系统只是为了备份和恢复。为了可伸缩性，我们的平台运行在一个动态集群上，使用SWIM协议。 So we can just add nodes on the fly in an ad-hoc manner.

为了促进公共api，我们决定在CSP中不存在内部api。我们所有的功能，所有的- CSP内部的开发人员自己都在使用他们自己的api，而不是我们使用的一些捷径-通常平台通常创建的。没有内部api。

模块化意味着我们的功能以类路径中的库的形式出现。每个功能都是一个单独的jar和这些功能之间的耦合，例如计费模块想要与标识模块对话，它为此使用公共api。而不是直接的代码访问。为了能够简单地开发和操作它，我们的平台被部署在一个罐子里。没有Tomcat容器，只有一个简单运行的jar。它不是基于Spring Bootstrap的，而是基于我们的内部框架的。这给了我们很大的灵活性。

在实践中，当我们部署平台时，它看起来是这样的。这向我们证明，当我们坚持我们的原则时，我们现在有了一个相当简单的平台。这是CSP。当它被部署到某些云提供商时。我不知道后面的同学能不能看到因为投影仪出了问题。但是所有这些绿色的圆圈，绿色的方块都是容器里面只有一个罐子。这就是平台。这些容器使用自组织网络相互连接。如果我们只是想添加另一个容器并扩展我们的平台，我们只需要将一个容器拉进来，给它一个对等IP地址，就可以了。但我可以整天谈论CSP架构，这并不是真正的架构惯例，幸运的是，我们有一个非常酷的CI/CD流程。 And for that I’ll invite Kiril here to the stage to present you with our CI/CD process and I’ll be back towards the end. Thank you.

(基)

好的。所以，我将谈谈我们如何对CSP产品进行CI/CD流程。好了，这就是我们的用例。也许在你的情况下，你可以选择不同的工具。但是我要展示的95%都是完全开源的。你可以重复使用。我们有一些内部过程。我就不分享了，因为你们无法复制它们但你们可以用我们用的相同的图案。

这是我们基础设施的高级概述。因此，我们使用Gerrit服务器进行代码审查，使用Git进行源代码控制管理。Jenkins作为CI服务器。Artifactory。我们使用Bintray将我们的工件交付给我们的客户，并且我们使用很少的环境。就像Gilad提到的，我们使用Docker容器。因此，为了能够编排所有这些内容，目前您的选择很少。你有Kubernetes，你有Mesos，你有Swarm，所以我们选择Mesos基础设施，因为这是目前对我们有效的。也许在未来我们会切换，但目前我们是基于Mesos。所以我们用Mesos来编排这些东西。

所以我们的环境很少。我们有一个自动化环境。我们有我们的领导，分期，生产，我们也有使用我们产品的客户环境。hth华体会最新官方网站那么，流动是如何进行的，它是如何运作的。开发者发送一个提交，它通过我们的审核系统，从审核系统到Jenkins。詹金斯负责所有的工作测试、构建以及代码分析。然后我们发布工件工件就是Docker映像，我们将它发布到我们内部的Docker Artifactory中。然后我们将部署和测试到我们的自动化环境中，即Mesos。我们进行测试。一切。 And if everything is okay, we can deploy to R and D staging in production.

这是可选的。目前我们没有自动部署，我们可以这样做。好的。基础设施已经准备好了，但是我们没有在每次提交时进行部署。好的。所以我们喜欢每天部署一次之类的。

因此，在我们看到生产环境中的工件是正常的之后，我们就会推广该工件。然后我们把它推到Bintray中，客户就可以从Bintray中取出那些工件。如果我们有客户对Bintray解决方案不满意，我们可以直接推送到他们的Docker注册表。我们只是为Artifactory使用记录器，但它可以是一个简单的Docker注册表，我们只是推送容器，图像，然后他们可以使用它。

这是对整个过程的概述。我们如何交付产品?现在我要深入研究左边的CI/CD中发生了什么以及我们是怎么做的。

这就是我们的Mesos基础设施。这就是我们部署CSP的方式，你可以看到我们有三个master。我们使用Marathon作为调度程序在Mesos之上运行任务。我们使用Docker奴隶。对于负载平衡，我们使用Marathon-lb，它也是开源的。所有的编配都要经过马拉松负载均衡器我们使用一个外部负载均衡器，这取决于当前是哪个。外部负载均衡器，将流量转发给内部负载均衡器。

那么我们在CSP - CI/CD中使用哪些工具呢?Artifacts是Artifactory和Bintray。CI是詹金斯。源代码控制，Git。代码审查是Gerrit。Gerrit是一个由谷歌开发人员开发的开源项目。非常好，它和Jenkins有很好的融合。对于奴隶，对于詹金斯奴隶，我们用码头工人。这是什么意思?这意味着我们不使用静态从库。 I have — we have a few Docker servers, so we have slaves on demand. Okay. It depends on the load that we have. So each time we run a job we provision a new slave which is a Docker container and we run the test there. So we can have as much slaves as we want. And each time that we execute a job we are sure that we are starting with a clean environment. Okay. Which is cool.

因此，对于基础设施，我们使用Mesos和Docker。代码分析是声纳。对于构建工具，我们使用Gradle和makefile。这些是我们目前使用的技术:Java, JavaScript, Python和Go。对于自动化，我们使用Python shell。对于通信，我们使用Stack。好的。所以这是[…]我们也知道，如果一些开发人员开始部署管道，但它失败了，或者构建失败了，我们知道如何在Slack上通知特定的用户。我们给他发了一个带有工作链接的信息。我一会儿给你们看。

这就是我们的内部基础设施。因此，我们有大约300个Jenkins工作岗位，我们还在不断增长，因为我们正在测试和新的管道。因此，我们有一个单独的项目Git存储库。我们曾经有过一个，给我们带来了很多问题。从CI的角度来看，很难理解哪个项目内部发生了什么变化。我们需要在作业内部创建一些包装器。对我们没用。所以我们决定把他们分开。正如我提到的，我们有动态的Jenkins奴隶和Jenkins和Slack的集成。这些就是我们用于Mesos的技术。 So Marathon is a scheduler. For load balancing, Marathon-lb. We also use Mesos-dns. Calico for the networking solution. And Chronos to execute tasks on our cluster.

正如我提到的，我们有很多詹金斯的工作，而且我们还在增长。对于使用Jenkins的人来说，在UI中管理这些是非常困难的。好的。就是一团乱。

这是一个例子。你想换哪份工作?我想改变所有Gradle的工作。假设你有200个Gradle作业，你想要碰撞一个Gradle版本，如果你在使用UI，你需要遍历每个作业并更改这个版本。这一点都不酷。

为此，我们使用Jenkins job builder。这是一个由OpenStack开发的开源项目。所以它给了你什么，它给了你以yaml格式保存作业的能力。好的。因此，当您在Jenkins端创建一个新作业时，并单击文件系统后端的保存按钮，它会创建XML文件。好的。XML不是人类可读的。你不能把这个文件中的技巧放到你的Git中并维护它，但是yaml格式更适合人类阅读，所以你可以用yaml格式创建你的作业，它适合人类阅读。如果你想换工作，或者创建一份新工作，你要经历与开发人员相同的过程。这意味着你登录Git，创建一个新的补丁，改变yaml格式，将它发送到我们的审查系统，我们测试它，然后部署。 When you deploy, Jenkins takes those yaml files, the tool will transform this yaml file into the XML and deploy on the Jenkins side. So, everything will happen for you automatically. No manual — nothing that you should do manual on the UI.

因此，您可以将配置保存为副本，我将向您展示如何操作。所以你可以在这些作业中包含shell, Groovy, Python脚本。因此，假设您有相同的脚本，希望将其包含到不同的作业中，只需将其保存在文件系统的一个位置，并将该文件包含到yaml中。你可以在部署之前进行测试。这就是我们所做的。你可以在文件系统上组织它，就像所有的构建器，所有的部署作业，等等。

当然，它是作为一个备份。因为所有东西，整个配置都保存在Git端。好的。我并不关心某个开发人员是否删除了作业，更改了作业，它失败了。每次我们都可以运行重新部署作业，所有内容都将被重新部署。好的。我们的开发者不使用UI。我们只使用yaml文件。

我不知道你们能不能看到，因为分辨率不是很好。但这是yaml文件的示例。这是工作的描述。因此，您可以看到作业名称是docker_clean_images_container。所以无论你是否支持并发，你想在这个作业中包含哪些参数，我们想什么时候触发这个作业，我应该克隆哪个Git。我要执行哪个构建器，哪个脚本。所以你可以填写。

这就是最终结果。这就是詹金斯那边的样子。好的，创建yaml文件，运行工具，它将部署到Jenkins，这将是最终结果。但这仍然是不够的，因为如果你有200个Gradle作业，你仍然需要每个作业一个文件。好的。这解决不了问题。

这就是为什么有模板。好的。因此，您可以为常见的作业创建模板，如Gradle作业或builder作业。作业可以使用，继承，这个模板，只需要填入缺失的参数。以Gradle作业为例，当你构建Java项目时你要确保所有作业的所有内容都是通用的，比如环境变量，相同的Gradle版本，所有内容都应该是相同的，而不是一个参数，构建项目。我是说，你想做的项目。为此，您可以创建模板并像这样重用该模板。只需将缺少的参数转发到作业中，作业就会为您创建。所以在这个例子中，如果你有200个Gradle作业，并且你想要修改Gradle版本，你只需要在一个地方更改它。在模板中。 And everything will be redeployed for you. So no manual will work through UI, everything goes through the Git.

这是Jenkins重新部署工作的例子。因此，作业正在运行，在每个任务中重新部署，一切顺利。部署。

好的，我们有哪些工作类型。我们目前有三种主要的工作类型。好的。第一个是门控工作。门控作业的目的是监听补丁集创建的事件。这是什么意思?这意味着每当开发人员发送提交时，都会执行门控作业。好的。我们正在做测试代码覆盖率。 This is the next slide.

关于构建。构建是为您构建某些东西的实际工作。例如，它会构建一个rpm, war, jar, Docker容器，等等。还有听众。侦听器[…]侦听变更合并事件的作业。这意味着当您提交更改时，我的意思是，当您提交合并的补丁时。好的。这种工作将被执行。它将动态地为您构建管道。我们会解释怎么做的。

所以控制工作。对于每个补丁，我们运行一个门控作业。每个Git项目都有自己的门控工作。正如我之前提到的，我们把所有的项目都分开了——它的项目在它自己的git存储库中，所以对于每个git存储库，我们都有它自己的门控工作。也就是说我们现在有20个。这项工作的目的是构建、测试并将结果发布到我们的审查系统。这意味着当你，当开发人员创建一个提交并发送一个补丁时，作业将监听补丁创建事件，作业将自动执行，它将为你构建、测试项目，并将结果发布到Gerrit。因此，对于一个大型项目，开发人员在10分钟内就已经在Gerrit方面得到了结果，并且他可能知道它是好是坏。

这就是门控工作的流程。所以开发者会发送一个补丁。然后Jenkins取出这个补丁集。针对此补丁运行测试。将结果发布到Gerrit。所以开发者决定是否合并。此外，在我们的案例中，开发人员不允许在没有人工审查的情况下合并补丁。好的。所以我们还需要一个人，一个开发人员来审查这个补丁。因此，如果补丁被合并，我们将启动管道，它将为我们部署产品。

这就是Gerrit的例子。这是我们实例的打印屏幕。如你所见，这就是变化。有人发送了更改，并在此基础上增加了几行。

这就是詹金斯失败的例子。如你所见，这是门控工作。开发者发送了一个提交，比如构建失败了。你可以看到Jenkins给出的是- 1。所以这个补丁不能合并。好的。所以我们真的不关心构建是否在你的笔记本电脑上工作。或者你的环境。我们不在乎。好的。 It should work on Jenkins because each time we provision a new slave, clean environments. So, make it happen on Jenkins. And if it’s like kind of […] problems, which we might have, because the slaves, the Jenkins slaves are Docker images, developer just can pull the image to his laptop and execute the test and everything on his environment. Okay. So he can easily reproduce the build on his environment.

这就是声纳故障的例子。这意味着Jenkins的工作可能会通过，我是说，测试和构建都没问题。但是，Sonar，代码覆盖工具得到- 1。好的，这是第一行。所以开发者应该修复它。开发人员增加代码复杂性的原因或他对补丁有重大评论。一切都可以通过这个UI，你只需点击链接，它们是[…]链接。你可以看到结果。好的。所以开发者应该修复它。

最后一个是Gerrit失败。那么，Gerrit失败是什么呢?Gerrit怎么能检查系统会让补丁失败。使用Git时，有两种钩子。第一个钩子是Git钩子，它在提交时在客户端执行，你可以在笔记本电脑上执行一些脚本，它会为你检查一些东西。好的。这是客户端。钩。也就是Git钩子。

Gerrit钩子，这些是在服务器端执行的特殊钩子。当在服务器端执行钩子时，您可以对钩子做什么?因此，您可以决定要执行每个钩子的哪个事件。好的。例如，如果它是一个[…]创建的事件，你可以做x y z，如果我合并补丁，我可以做其他事情。好的。

所以你可以-我们现在用这些钩子做什么呢?我们正在检查提交消息的样式。我们不允许提交fix bug之类的东西。好的。我们不允许这样做，因为我们有一个内部工具——发布过程内部工具，它收集所有项目的所有提交，我们正在动态地生成发布说明。好的。这就是为什么我们需要一个特殊的提交-提交模板。我们正在检查尾随的空白，例如，假设你有一个bug。然后把bug链接放到提交信息中。当你合并时，一切都好了，从Gerrit，你可以和外部系统集成比如Bugzilla, Jira要更新这个票据，你可以关闭它。 You can reopen. You can do whatever you want. Okay.

这是Gerrit补丁失败的例子。好的。在这里你可以看到补丁后面有空格，开发人员应该删除它。所以为了能够合并一个补丁，实际上是提交它，你需要通过Jenkins这方面，这意味着测试，代码覆盖，你需要通过Gerrit，你需要通过审查。好吧?人工审查。在你成功合并你的补丁之后，我们开始动态管道。

那么，谁负责动态管道呢?这些都是听众的工作。在补丁合并事件上执行。好的。所以当我们在Gerrit端有一个合并事件时，作业将在Jenkins端执行。因此，我们动态地编排管道。那么我们该怎么做呢?我们正在使用BuildFlow插件。这是通过代码编排构建的方法。好吧? So in the Jenkins, usually, when you create a job, it’s kind of static. You do one, two, three, and if some of the steps failed, everything fails. Okay. So here you can create your pipeline dynamically through the Groovy code. Okay, so you write the code, and depends on the event, you can decide whatever you want, how do you want to create your pipeline.

因此，与gaiting作业一样，每个Git项目都有自己的侦听器作业。好的。因此，每个侦听器作业可能创建一个不同的管道。但是它们都将运行相同的代码库。好的。我们不想管理不同的管道，我指的是不同监听器的不同代码库。好的。因此，我们使用一个代码库，管道是为您动态编排的。

当然，如果出现故障，用户会在Slack上得到通知。当管道启动时，假设你在部署阶段失败了，我们知道如何通知用户。这就是破坏构建的这个家伙的例子，我们将链接附加到作业上。开发人员将能够访问作业并查看发生了什么。为什么会失败?这是我对这家伙大喊，让他修复这个结构。

举个例子，看看到底发生了什么。你们可以看到，左边有听众。因此听众。我们提交，一个流程可能是这样的。另一个可以像这样。为什么会这样呢?因为它取决于项目类型，我们可以通过编程来决定。好的。

那么，并行部署，我们怎么做呢?所以开发者发送一个提交到Gerrit服务器，从Gerrit到Jenkins，从Jenkins部署Docker。在我们运行了所有的测试，代码分析，Gerrit，以及我之前展示的所有东西之后。所以我们把Docker镜像部署到Artifactory，然后部署到我们的自动化环境中，在那里我们将运行更多的测试。在这里你可以看到在研发，阶段和生产环境中，我们已经有了一个运行的部署。好的。我们已经有了跑步集群。那么当自动化完成之后会发生什么呢，我们推到Bintray，然后我们部署一个新的集群到研发环境，我们执行与数据的集成，所以我们在蓝绿色部署上工作。好吧?我们部署一个新环境，执行集成，然后破坏一个旧环境。 Okay. Same will happen for staging, and same might happen for production. So as you can see we have another developer that brings in a new — a new change, it might go through the same flow. Okay. So everything will be the same, same flow.

为了做到这一点。好的，持续部署到您的环境中，您需要有强大的基础设施和良好的测试。好的。因为如果您不能确定您的产品已经100%测试过，那么您就不能持续地部署到您的环境中。对吧?所以Jenkins这边有更强大的测试基础设施。

这些就是管道的例子。这些是我从Jenkins中创建的截图，所以你可以看到一个管道非常短。好的。第二个可能要长得多。好的。它们都运行着相同的代码库。第三个可能是这样的。好的。所有东西都是动态构造的。我没有提到的是，我们有一些特殊的工作，他们在做什么，他们在检查所有的项目，我们提取我们所拥有的开源依赖。 Okay. And we automatically are integrating with VMware internal systems that we need to notify them which open source project that we use, and which licenses or whatever. But, like off topic.

这就是CI/CD视角。这是非常高水平的。我们怎么做呢?我稍后会给你们展示Gilad现在会解释我们是如何整合平台的。好的。

(Gilad)

好的谢谢。因此，正如你所看到的，我们有一个全面的管道，从开发人员机器，通过内部构建管道，通过公司管道，如法律，看看我们是否开源，我们可以使用它们，并检查安全漏洞。这只是一条通往生产的管道。

当我们进入生产阶段时，我们需要升级我们的平台。CSP是一个有状态平台，这意味着所有数据都存储在内存中。其中一些在磁盘空间上，但并不真正相关。这些都发生在同一层。业务逻辑、状态层和持久化层都在同一层中，因此在升级时产生了一些问题。

升级并不是一个新概念。对吧?有蓝绿色，红黑色，我称之为旧新闻，对我来说更简单。我们也有滚动升级。当我们研究如何进行升级时。我们有两个主要目标。一是尽量减少服务中断，这样我们的外部客户就不会觉得我们在升级我们的平台。第二，因为状态和业务逻辑是耦合在一起的，我们可以开始并在必要时进行模式升级，然后执行业务逻辑升级。我们需要在同一阶段完成。当然，另一个主要目标只是将新的比特和字节部署到生产环境中。

所以我们面临着一些挑战。CSP是一个对称的集群，这意味着我们不能将不同代码的节点添加到其中。我们需要用蓝绿色。而且，正如我所说，由于状态和业务逻辑在同一层上，我们不能将模式升级与业务逻辑层分开。

所以我们设计了一种升级系统来完成以下任务。现在你必须记住，当我们升级平台时，平台是活跃的，接收流量，它的状态一直在变化。所以我们所做的就是思考如何在迁移周期中做到这一点。迁移周期意味着我们引入新的集群，新的CSP部署，在模式转换之前从旧平台中引入数据。然后将一些有意义的指标返回给在后台运行的更新编排器。它也运行在新的集群上。然后我们检查这些指标，并尝试做出有根据的猜测，我们是否可以在最短的时间内停止流量，而不会导致服务中断。或者我们需要继续进行另一个迁移周期。

所以这个过程就是对迁移周期进行检查，检查阈值，分析旧的指标，前一个迁移周期返回给它的指标。如果超过阈值，则在代理上对流量进行排队，执行另一个迁移周期以补偿在升级过程中更改的所有数据。然后释放流量并将其路由到新的集群。

我们这里有个例子。我不知道后面的同学能不能看清楚。很抱歉是投影仪的问题。但是，这是现有的情况。我们有蓝色的节点组。节点组是CSP中运行多个节点的集群。于是我们决定开始迁徙。所以我们用更新的代码部署了一个新的CSP，我们有一个状态发现阶段，我们发现我们想要复制的东西，以及它在绿色的蓝色集群上的位置。然后我们开始迁移转换循环。因此，新的集群从蓝色集群中提取状态，并执行必要的状态-模式转换。

在这个例子中，在第一次运行时，我们提取了5000万份文档，这花了我们25秒。我们在上面运行阈值，看看这些指标是否正确。现在我们当然不能，因为如果下一个周期将花费25秒，那么HTTP客户端将开始发送错误。因此，我们执行另一个迁移循环。而这只花了600万。状态保持——保持在平台上的更新，因为它是实时的。600万份文件已经被修改，而这只花了5秒钟。所以你可以看到，每次我们做一个迁移循环时，delta都是闭合的。在最后一个迁移周期中，我们只迁移了90K个文档，这只花了我们半秒钟的时间。所以如果我们达到了我们的自定义阈值，这个阈值会告诉我们这可能是一个很好的度量，可能下一个迁移周期会花费更少的时间。 So in this point in time, we just stop the traffic to the blue and queue it in our proxy, perform another migration cycle, which pulls the last remaining state that hasn’t been changed. And this case, only 10K of documents in a really small amount of time. And after that’s done, we reroute the traffic to the new cluster. And we keep the blue one in case of something goes wrong in the meanwhile. And that is how we do the upgrading in CSP.

在问答环节之前我还有几分钟所以我可以再多讲几秒钟氙气。CSP基于VMware开源分布式控制平面Xenon。通常在构建SaaS平台时，需要建立包含以下层的大量节点。对吧?

您需要一个编配层和容器。您可能会使用Spring Boot。您需要一个持久化层。你可以选择Cassandra或Mongo，这是最受欢迎的选择。如果需要的话，还需要一个转换层或ORM。可能是因为您在集群中运行，所以需要Zookeeper或ETCD来配置和维护您的集群。你还需要一个UI服务器。你可以使用Node.js。一些缓存层，因为你关心[…]和性能，就像Redis。最终会有消息总线。

虽然所有这些技术都得到了验证。对吧?我们都在这个房间里用过，我相信，这就像是一个科技动物园。对吧?因为如果你想部署一个包含所有这些层的服务，它可能会变得有点复杂，因为你需要启动你的Cassandra集群，你需要一个接一个地启动节点。Cassandra集群启动后，现在你可以用Spring boot启动自己的集群，并将其连接到Redis集群并配置为Zookeeper。

虽然这是个好方法，但操作起来有点复杂开发起来也有点复杂因为你的开发环境，你需要运行这个或者你可以读取一些嵌入式模拟或者仅仅是嵌入式技术。

所以VMware的Xenon框架就是一个电池。这是一个包含框架的电池。这并不是当今行业中最流行的做法但这仍然是我们的做法。它在内部提供了一些这些层，所以你可以像REST API一样开箱即用，所以你可以创建自己的微服务，或者使用Xenon，它更像是一种纳米服务方法。您可以基于[…]获得持久性层，这是一种经过验证的技术，非常容易用于分发。您还可以获得领导者选举功能、发布-订阅功能、统计数据、指标，甚至UI服务功能。

这就是我们这边的结果。氙气是开源的。你可以在GitHub上读到它。Kiril提到的Jenkins Job Builder也是一个很棒的OpenStack项目。就是这样。谢谢你。

额外的资源:2022世界杯阿根廷预选赛赛程

• 作为你的Artifactory码头工人注册表
• 如何建立一个私有、远程和虚拟Docker注册表