用例——使用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的一名架构师。和我在一起的是我们的DevOps主管Kiril Nesenko。我们在云提供商软件领域工作[…]。这只是我们为云提供商开发服务的一种花哨的说法。

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

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

所以，就像优秀的工程师一样，我们决定[…]我们的努力，并创建一个内部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。而不是直接的代码访问。为了能够简单地开发和操作它，我们的平台部署在一个单独的jar中。没有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。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的方式，你可以看到这里我们有三个主服务器。我们使用Marathon作为调度程序，在Mesos之上运行任务。我们使用Docker奴隶，对吧。对于负载平衡，我们使用Marathon-lb，它也是开源的。所以所有的编排都要经过Marathon负载平衡器我们使用一个外部负载平衡器，这取决于当前是哪个。外部负载平衡器，将流量转发到内部负载平衡器。

那么我们在CSP中使用哪些工具呢?工件是Artifactory和Bintray。CI是詹金斯。源代码管理，Git。代码审查就是Gerrit。Gerrit是一个由Google开发的开源项目。非常好，它与Jenkins有很好的整合。对于奴隶，对于詹金斯的奴隶，我们用Dockers。这是什么意思?这意味着我们不使用静态从节点。 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。代码分析是Sonar。对于构建工具，我们使用Gradle和makefiles。这些是我们目前使用的技术:Java, JavaScript, Python和Go。为了实现自动化，我们使用Python shell。我们使用Stack进行通信。好吧。我们也知道，如果一些开发人员启动了部署管道，但它失败了，或者构建失败了，我们知道如何通知Slack上的特定用户。我们把工作链接发给他。之后我会给你看的。

这是我们的内部基础设施。我们大约有300个詹金斯职位，而且我们还在增加，因为我们正在测试和新的管道。所以我们有一个单独的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端创建一个新作业，并在文件系统的后端单击save按钮时，它将创建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作业或构建器作业)创建模板。作业可以使用、继承该模板，并只填写缺失的参数。比如说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的例子。这是我们实例的打印屏幕。如你所见，这就是变化。有人发来了修改，并在这句话上加了几行。

这就是詹金斯失败的例子。正如你所看到的，这是门控工作。所以开发人员发送一个提交和一些东西——比如构建失败了。所以你可以看到詹金斯给的是- 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.

这是声纳故障的例子。这意味着詹金斯的工作可能会通过，我的意思是，测试和构建都没问题。但是，声纳，代码覆盖工具得了负一分。这是第一行。所以开发者应该修复它。开发人员增加代码复杂性的原因，或者他对补丁有主要的评论。一切都可以通过这个UI使用，你只需点击链接，它们是链接。你可以看到结果。好吧。所以开发者应该修复它。

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

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

我们现在用这些钩子做什么呢?我们正在检查提交消息的样式。我们不允许提交修复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.

因此，与获取作业一样，每个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秒钟。正如你所看到的，每次我们做一个迁移周期，增量就会关闭。在最后的迁移周期中，我们只迁移了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基于Xenon, Xenon是VMware开源的分布式控制平面。通常在构建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世界杯阿根廷预选赛赛程

• 作为你的工艺品。码头工人注册表
• 如何设置一个专用，远程和虚拟Docker注册表