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