我的爱好:大马，狗，我喜欢武术。所以我们开始真正看到微服务的出现。它们确实需要一些新的DevOps解决方案。这是我们编写和交付软件方式的一个巨大转变。我们开始看到的两个趋势是围绕微服务的服务目录的出现。这是一个巨大的潜在市场，现在有5亿美元，这对于一种新兴技术来说是相当大的。我们也看到了持续交付的融合，在GitHubs，我们喜欢称之为实验供应商。
Tyler Jule的文章中有关于趋势和DevOps新方法的预测。我们也看到了DevOps使用的增加，CN\CF去年做了一项研究，该研究表明基于他们的用户，92%的用户说他们现在在生产中使用容器，而去年这一比例约为84%。所以我们看到集装箱的使用在持续增加。
如果这些集装箱要转移到微服务，我们还不清楚。但我们知道，Kubernetes被用于生产的比例约为83%，高于2019年的约78%。所以，你知道，生产中的容器或生产中的Kubernetes的出现将表明微服务将是下一个重大转变。
我喜欢用SD Times在2019年写的一篇文章《微服务——越多并不总是越好》，亚历山德拉·努南接受了采访，她谈到了微服务的扩展。她说，事情是这样的，我们发布一个库的更新，然后一个服务会使用新的服务，现在突然间，所有其他服务器都在使用旧版本的库，我们必须试着跟踪哪个服务在使用哪个版本的库。Randy Hefner说，微服务开发如果没有连贯、自律、管理的方法。所以微服务是复杂的，这是因为我们把静态应用程序，分解成更小的拼图。让我们来看看真正的问题是什么。为了真正理解微服务扩张的问题，我们必须理解我们是如何走到这一步的。因此，我们必须将我们的整体实践与微服务实现或微服务体系结构进行比较。在我们的整体应用中，它们是被配置和静态链接的，这基本上就是我们开始这段旅程的地方。
大多数人都有构建管理人员，构建管理人员会创建构建脚本，静态配置脚本会指出如何编译和链接以及在编译和链接过程中使用什么。非常非常关键的位置。当他们这样做时，他们会查看版本控制，并决定应该使用什么。
他们担心，你知道，拉请求，合并，取出主线，重新编译主线。这就是CI的本质。它会查看这些构建脚本，然后说，我在Git中有了一些新东西，我要把它取出来，然后自动运行构建脚本。在这一点上，您可能会调用artifactory之类的东西来进行一些扫描，例如，查找传递依赖性，但在一天结束时，整个构建步骤所做的是，创建一个应用程序二进制文件，并为它分配一个可能使用的版本构建号作为版本这是一个完全符合逻辑的事情。
如果你擅长你所做的事情，你就会生成一份材料清单来说明你所做的事情包括你使用的库。如果你真的很好，你会做一个差异报告，你会比较你的两个酒吧报告，然后说，这是之前的构建和我们刚刚做的构建之间的差异。
所有这些，所有这些都是我们整体方法中的北极星，这是CI管道的开始。一旦完成了这些，您就有了一个发行候选版本，它可能会或可能不会通过CD管道进行推送。但是，您要经常频繁地这样做，以确保添加到Git并准备编译的任何更改都没有破坏构建。那么，我们如何知道在微服务的世界中，我们没有破坏一个整体的构建呢?
这才是真正的诀窍。让我们思考一下微服务开发人员如何在这个世界中进行交互。微服务是独立构建和部署的。这就是重点，你要分解你的应用程序你要独立地部署这些对象，这就是复杂性的来源。
拆分是很难的，从庞然大物到微服务也不容易。一旦微服务开发人员完成了他的代码，他就为我们构建了300或者400行Python代码，或者更新它，他会创建一个新的容器，他会把那个容器注册到容器注册表。一旦它在容器注册表中，它就准备好了。它被推到开发中，或者推到测试中，或者推到生产环境中。这就是CD管道接收该容器并将其推到测试环境或生产环境的地方。
现在，如果你还在做单片建筑，你正在建造…你的容器包含了整个整体应用程序，你并不是在做一个真正的微服务环境，你实际上是在一个整体中运行，容器的处理方式与CD管道相同。在微服务的世界中，这是不同的，因为微服务是独立于您的应用程序运行的。这是我们问题的开始，它是由整体步骤驱动的。
链接步骤静态链接我们将要使用的所有外部库被替换为api，这是在运行时完成的。所以这样想。我们把我们的整体应用程序拆分成可以共享的更小的可重用组件。这才是重点。我们在运行时动态链接它们。因此我们需要克服一些挑战。那么影响是什么呢?
首先，我们不再有应用版本了。这充其量是合乎逻辑的。我们没有应用程序BOM报告，很难知道特定微服务的版本您的应用程序可能会消耗资源。当然，要生成一个差异报告来显示我们上次建造它时的样子是很困难的，这是它的样子。
今天，我们重新编译了它，这是新的BOM报告，这是不同点。这种可视性的缺乏实际上为高频更新带来了一些瓶颈。我经常听到SREs在发布微服务时感觉自己在瞎飞，因为他们不知道这些影响会是什么。所以会有些犹豫。虽然我们可以在一个高频率的基础上推出东西，但我们最终做的是等待它被部署到一个环境中，等待事件报告，然后使用可观察性工具试图跟踪事务并整理出发生了什么。
微服务扩展是采用我们的单块方式并将其转移到云原生环境的另一个影响。我们这么做的原因是为了解决我刚才描述的一些问题。但本质上，我们对影响一无所知。我们不知道微型服务的爆炸半径是多少。我们不知道一个微服务是影响一个应用程序，还是影响20个应用程序。这是一个问题。
让我们来看看问题的核心。我们要做的是什么，为什么这么难?首先，soa旨在利用共享服务，而不是复制服务。这意味着我们必须改掉一成不变的习惯，因为一成不变习惯实际上会阻碍分享。
我们曾经尝试过面向对象编程，最后我们做的是创建动态链接库或DLL的概念，它应该能够在多个应用程序之间共享。但我们不想这么做。相反，我们所做的是把那个图书馆搬到我们的环境中，并给它重新命名。事实上，如果你想想微软，你知道，Visual工作室工作，它会为你重新命名。这就是我们解决问题的方法，我们……我们想使用我们自己的版本，我们不相信有一个共享的版本。因此，共享服务确实带来了新的挑战，因为概念是，如果你共享服务，如果你更新一个特定的服务，每个人都能同时得到修复，而不是重新编译所有东西，然后把它推出去。
这就是共享soa的美妙之处，也是微服务的美妙之处。如果你有一个安全问题，你在一个地方解决它，所有消费的人都能立即得到解决。不需要重新编译，这是业务中的终极敏捷性。
但是，在这个新世界中，除非您进入集群并基于事务查看，否则无法深入了解应用程序和服务关系。这甚至不会真正向你显示BOM报告，你的应用程序消耗了什么，当然也不会给你影响分析，如果其中一个服务要更新，你可能想在它发布之前知道它的影响。所以，是我们单一的习惯造成了这种蔓延，其中有人为因素，也有实际的工具因素。在我们这个单一的世界里，我们真的依赖于所有权。
我们想要自己版本的库。你知道，你会听到像我不想要意外的更新，我们的团队决定部署一个新服务，即使我们不拥有它。所有权，是一种单一的习惯。缺乏合作，我们的团队没有被告知有新的服务可用，没有人告诉我们。协作在SOA环境中是至关重要的，因为当新功能和新服务推出时，你需要有一种沟通的方式。
一致性。我们以前听说，它在我的机器上很有效。现在我们听说，它在我的集群上工作。所以我们不需要新版本，因为它在我们的集群上工作，我们将保留那个版本并将那个版本向前推进。和验证。
我们从未用特定版本的服务测试过我们的应用程序，这又回到了我们的信任问题。我们必须能够相信编写微服务的人会确保它同意我们在测试中的那些合同。让我们看看它实际是什么样子的。不是每个人都在Kubernetes或像我今天在这里展示的云原生环境中移动，但我看到它比……比我想象的要多
这基本上是构建应用程序的统一方法在集群环境中运行。在这个例子中，我们有一个虚构的商店叫做在线商店公司。
这里有糖果店、服装店和玩具店，这些都是我们在网上商店公司管理的。我们有共享服务，我们有购物车服务，我们有运输服务，我们有支付服务。现在，因为所有三个团队都不习惯在共享服务更新后信任对方，所以他们要求建立自己的集群，让他们的应用程序在自己的私有集群中运行。对于生产，我们有三个集群，12个舱，12个静音服务，运输服务已经漂移。
在我们的例子中，糖果店和玩具店使用相同的运输服务，但服装店选择退出或不知道更新运输服务。这就是扩张和漂移。所以不是每个人都重复使用这些东西最近的版本，我们已经SILOed他们了。
这是云原生环境中的一个整体方法。它创造了更多的工作。现在我们有12个这样的pod，如果你把它乘以你的开发测试和刺激，你管理着36个，你的应用程序实际上只使用3个共享服务。所以扩张发生得非常快。所以这是一种平衡，对吧?
我们如何平衡风险和控制?当我们SILO这些集群时，控制权就交给了我们，因为它给了我们一个高度的控制，我们将使用什么作为服务，但风险是，如果其中一个服务被更新，您就会产生漂移，这意味着关键的修复可能不会被所有的应用程序使用，而在面向服务的体系结构中，它们可以很容易地使用微服务。所以我们必须弄清楚如何管理平衡的行为。管理平衡行为的一部分是改变我们的一些内部文化，因为文化很重要，同时引入一些新的工具来构建具有一些洞察力的SOA体系结构。因此，首先，信任外部团队服务的使用是至关重要的，我们必须达到一个点，即应用团队可以信任使用他们无法控制的微服务。他们必须有一种共享的文化，共享组件并围绕这些组件进行合作。
你知道，我们一直在努力改进我们的协作，而且，你知道，像GitHub这样的公司已经讨论协作很长时间了。但在SOA环境中，我们必须知道，如果三楼的人写了一个非常惊人的安全例程，我们如何告诉八楼的人，他们的应用程序应该使用它。我们必须考虑领域驱动的设计，我把它扔出来是因为如果你真的在学习并试图理解如何构建SOA DDD是你应该关注的东西。
我们在面向对象编程中学过这个，但我们并没有很好地实现它。我们必须在这一点上，我们必须开始基于解决方案空间来理解我们的微服务因为这将有助于共享和协作以及理解，如果你是一个应用团队，有一个很棒的运输服务你应该使用，你应该依赖于微服务开发人员来确保它会以它应该的方式运行。然后是新的工具，新的工具是必需的，我们看到围绕管理Kubernetes出现了大量的新工具。
我们将开始看到更多关于管理微服务、服务目录的工具，以及如何真正开始了解可以利用微服务的SOA体系结构。考虑一下和之前的图相反的情况。我们有一个集群，假设这是prod, test，或Dev在这个集群中，我们有三个商店，糖果店，服装店和玩具店。它们在自己的名称空间中运行，对在这些名称空间中发生的事情有完全的控制。
但是，它们在命名空间之外与共享服务命名空间进行通信。这就是他们收取运费、付款和购物车服务的地方。现在，在这种配置中，我们有一个集群、六个豆荚和四个名称空间，而且没有漂移。这是最关键的部分，没有漂移。
微服务扩展产生漂移，漂移可能是一种危险的情况。你知道，这听起来很夸张说很危险，但当你有一个库需要重新编译和重新链接时每个人都在那里，每个人都必须迁移到那个库的新版本，因为这是我们需要的关键更新，每个人都在使用它。这是一个整体的方法。在微服务SOA方法中，你所做的只是更新一次，每个人都能得到它。因此，如果我们将Dev、test和prod添加到其中，我们就有了3个集群、18个pod和12个名称空间。我们讲了工具，我要讲一点Ortelius，这是一个在CD基金会孵化的开源项目。
我很荣幸成为这个项目的社区主任。我们对它的进展非常兴奋，我们有大量非常积极的提交者，他们理解这个问题，并真正致力于解决微服务、管理和编目。Ortelius跟踪我称之为服务逻辑集合的东西，创建应用程序的逻辑视图，并在其中添加版本控制。所以你知道，我们谈论整体，我喜欢把它说成一个巨大的拼图，我们把它压层，我们推动它的生命周期。而微服务不会这样做。
微服务采用一块拼图，并将其贯穿整个生命周期。所以我们必须开始了解这些部件是如何协同工作的。这在本质上就是奥特留斯的目标。Ortelius会缩小爆炸半径，它知道影响，它知道微服务是否有更新，是否会通过管道，以及它会影响谁。SOA体系结构的关键部分。一旦一个容器被注册，它就会告诉你它将影响谁，你不需要等待它被部署。
奥特留斯也用到了域的概念。如果您正在进行领域驱动的设计，它将允许您构建一个目录，在这个目录中，微服务开发人员可以将微服务发布到一个目录中，这意味着应用程序团队可以进行一些协作，因为他们可以查看已发布的内容并使用它。
它通过创建这些逻辑应用程序视图来恢复控制。想想当你。在一个整体的世界里，你拿一个应用，你创建一个包。在微服务的世界中，这个包将包括独立部署的组件或组成该应用程序包的微服务。好吧?这是基础版本。如果其中一个服务被更新了，那么您的应用程序就有了一个新版本。如果其中一个服务被三个不同的应用程序使用，那么您就有应用程序的三个新版本。因此，Ortelius实际上致力于通过跟踪这些逻辑应用程序版本来恢复控制。
它会给你BOM报告，DIFF报告，以及爆炸半径报告。所以我们所做的就是在微服务环境中添加可见性，而不是可观察性。如果你想一下两者的区别，我们来讨论一下。
Ortelius并不运行在您的集群中，而是位于您的集群之上，集成到CD管道中，并进行自动化配置管理以获取这类信息。换句话说，这是对CI的重新想象。可观察性在集群中运行，它可以很好地向您展示事务是什么样子的。Ortelius的目标是为您提供一些高级信息，这样您就可以看到谁是通常的可疑对象，通常的可疑对象通常是最后更新的内容。你可以通过差异报告看到这一点。我们来看看奥特列斯是如何运作的。在容器注册发生时调用Ortelius。因此，一旦注册发生，它就会触发Ortelius对微服务进行版本化，跟踪应用程序配置管理并构建关系映射。现在，它的启动方式是一个应用程序团队创建一个基于应用程序的版本，并创建一个包。这个包包含了应用程序在基本版本中将要使用的所有服务。
一旦注册了一个新的容器，我们就知道它将影响到任何使用该容器上一个版本的人，然后开始构建这些映射。这就是它如何开始跟踪和构建部署信息元数据的本质，这些元数据是关于您的微服务如何被使用的，以及您的应用程序是什么样子的。
一旦发生这种情况，它可以触发部署，或者可以触发调用Helm图表。这样我们就能得到一个反馈。因此，我们需要能够看到在集群级别发生了什么，以便我们可以将其报告回去。因此，我们正在报告所有已部署的集群上的微服务清单。
为什么这很重要呢?这很重要，因为每个集群看起来都不一样，每个集群看起来也不一样，每个集群可以有不同的微服务集合。因此，每个集群都有应用程序的不同版本。这不是什么新鲜事，我们已经做过了为开发，测试或刺激很长时间。
这就是有这些不同阶段的意义所在因为我们有不同版本的应用程序。奥特利乌斯通过创建反馈回路来追踪这些信息，我们知道它们被安装到集群中，因此我们知道在生命周期的任何点上运行的是哪个版本的应用程序。棘手。它还有一套完整的api，这样你就可以调用它，它可以执行所有的魔法，所有的版本控制和所有的关系映射，以及Postgres数据库中的域。为了探索它所绘制的地图我们以亚伯拉罕·奥特留斯的名字命名它为奥特留斯，亚伯拉罕·奥特留斯创造了第一幅世界地图。他以一种非常酷的方式做到了。
他可以说是我们的第一个开源领袖，因为他知道当时欧洲各地都有人在航海绘制世界地图，他把这些地图汇集在一起，所有的制图师一起创建了第一个世界地图集。
他没有邀功。如果你看他的一些旧地图，你可以看到不同的人在哪里创建了地图的一部分或在地图上签名。因此，他汇集了许多人的知识，建立了我们的第一个世界地图集。在很多方面，这就是奥特利乌斯所做的。
它把这些不同微服务的信息汇集在一起，它们被部署在哪里，从而创建地图。你知道，如果你真的想要考虑它，我们有一个巨大的集群我们对集群中的每个点都进行版本控制。我们得到的是应用程序版本的BOM报告，我们可以显示这些应用程序版本之间的差异。
在本例中，在下面这里，我们显示购物车服务已更新。在这个例子中，我们展示的是购物车服务被更新了，当它更新的时候，它影响了三个不同的应用程序。现在，这类数据可以很容易地传递到管道的其他部分。例如，如果这个推车服务已经更改，我们需要为这三个不同的应用程序执行测试工作流。从本质上说，我们正在做的是，重新想象CI并理解各个部分是如何组合在一起的，因此我们知道我们必须通知这些其他的应用程序团队，他们的世界中有一些东西正在改变，他们应该知道。从我们的早期采用者那里得到的反馈是，他们看到他们的微服务的扩展和冗余编码减少了大约50%。他们说这种自动配置管理可以节省1到2个每次部署需要数小时的手工工作。
现在，如果你一周做一次或两次部署，这可能不是太多，但如果你每天都做，或者如果你想每小时都做，这是一个很大的数字。SREs现在可以在部署像爆炸半径这样的部署之前做出一些数据驱动的决策。我们确实在驱动这些内置到现有CD管道中的高频更新，这样我们就可以连接到您选择的CD管道中，使其开始管理微服务的概念，并进行自动化配置管理，以获得那些报告。就到这里，时间不多了。
让我们继续对话，你可以通过Tracy@DeployHub.com找到我，我的推特账号是@TracyRagan，你可以在Tracy-Ragan-OMS找到我。登陆Ortelius网站。你可以在GitHub上查看我们。如果你有兴趣参与进来，我们欢迎你的加入。
这是一个大问题。我们需要来自SREs、开发人员、测试人员和操作人员的尽可能多的输入，才能真正开始收集我们需要的那种数据，从而真正创建一个可靠的部署元数据中心，让我们所有人都指向北极星。这就是谷歌集团中的Ortelius开源开发。
非常感谢大家的聆听。嘿，JFrog的朋友们，谢谢你们再次邀请我。我喜欢做这些。
我爱你们所有人。谢谢。再见。
