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