云原生架构
在马萨诸塞州波士顿的O'Reilly建筑会议上，Rags Srinivas赶上了Matt Stine。 马特（Matt）谈到云原生架构以及一些文化和技术挑战。 他谈论了一些NetFlix服务以及Spring如何对其进行包装，以便能够在平台上设计和开发微服务。 他还谈到了SOA及其可能遗漏的内容。
InfoQ：您好，欢迎光临。 和我一起有Pivotal的Matt Stine，我们正在马萨诸塞州波士顿举行的O'Reilly建筑师会议上。 Matt，如果您能花一点时间向InfoQ受众介绍自己，那将很棒。
马特：好的。 是的，正如您所说，我是Matt Stine。 自从Pivotal几年前成立以来，我就一直在Pivotal工作，并以某种形式与Cloud Foundry团队一起工作。 我一直在做很多不同的事情：工程，技术传播，技术营销和博客。 最近，我开始围绕我们为Cloud Foundry构建的一组服务进行一些产品管理工作，这些服务涉及Spring Cloud和Netflix OSS。
InfoQ：我知道您最近写了O'Reilly出版的一本书，该书在会议上被赠送给了有关云原生架构的信息。 例如，从架构师或开发人员的角度来看，云原生的确切含义是什么？
Matt：所以我所说的“云原生”是许多不同想法的融合，同时也恰逢许多试图迁移到云的公司。 这些想法包括DevOps，持续交付，微服务，敏捷基础架构，Conway法则，以及围绕业务功能重组公司。 发生了很多事情，而云原生碰巧是我和其他一些人正在应用的通用名称。 如果这本书有一个收获，那就是我所谈论的绝大多数与人员，组织结构和文化变革有关。 而且其中融合了一些技术。
谈论云原生的架构并花费所有时间谈论人员是很奇怪的，但这确实是这种架构仅在您更改公司以促进其运作时才有效的事实。 而且，当您这样做时，该体系结构将为您带来很多好处，同时可以进行某种重组。 因此，我认为主要的收获是，这种趋势不仅是技术趋势，甚至不是主要的技术趋势。 这主要是文化和组织变革的趋势。
InfoQ：好的。 我认为这是我接下来要讨论的话题，微服务从根本上来说是新的吗？ SOA是否又重新出现了？新瓶装老酒如某些特征所示？
Matt：我参与了有关微服务与SOA的关系的一些对话。 在某种程度上，我认为这并不是一次非常有用的对话。 话虽如此，与SOA的Wikipedia页面的前几段相比，我们现在所说的微服务在很多方面听起来与SOA非常相似。 我认为真正的区别在于供应商如何通过SOA货币化。 他们的重点通常是将所有内容都放入这种称为企业服务总线的新中间件中，以取代不再流行的所有其他大型中间件。 并不是说ESB技术很糟糕。 这就是我们使用它的方式，用另一个整体替换一个大型整体。 从这里取走所有复杂性并将其推到那里。 迁移到面向服务的体系结构实际上并不需要这些。
如果您只关注明确的服务，清晰的合同和清晰的API的服务原理（换句话说，SOA背后的原意是什么），它将与背后的技术原理很好地匹配微服务也将成为。 但是，随着SOA趋势，您真正看不到的是对文化，组织甚至运营方面的关注。
当我听尼尔·福特谈论微服务时，我心中就想到了运营方面的想法。 他指出，当他查看这些涉及ESB的体系结构图时，它们看起来确实不错，而且易于理解，但从操作角度来看，它们实际上并没有做任何事情。
因此，我们去尝试用它进行连续交付。 我们遇到了所有这些意外的障碍，因为没有人真正考虑过在生产中运行此产品会发生什么。 您会看到微服务，它是在DevOps和持续交付对话发生之后出现的最早的架构之一。 现在，您有很多团队正在与他们进行对话，并且在他们的脑海中进行对话，并且您会看到这些特定类型的体系结构不断涌现。 这些是我们现在开始将“微服务”标签应用到的体系结构。
因此，我认为原则上两者之间没有太大差异，但是实现方面两者之间有很大差异。 我认为这就是对话的来源。 从原理和SOA和微服务背后的历史的角度来看，它们没有什么不同。 但是，当您实际了解人们日常工作以实现微服务与SOA的关系时，他们看起来就完全不同了。
InfoQ：现在，在SOA方面失败的经典例子就是这种整体式UDDI。 我不知道您是否还记得通用发现和目录接口？ 即使在微服务的角度来看，服务发现仍然非常关键，对吗？
马特：对。
InfoQ：那么它有多重要，以及在微服务领域正在发生什么？
马特：是的，因此，感谢您提前向我发送问题，我得以查找UDDI来提醒自己那是什么。 当它流行时，我从未真正使用过它。 当然，我不知道它曾经流行过，但这是人们谈论的话题。 我认为我们正在谈论的服务发现有很大的不同。 据我了解UDDI一样，这就像电话簿一样，作为某些服务的开发人员，我将去该电话簿中寻找我需要的东西，例如信用卡处理服务。
因此，我的第一个问题是：“那么，那里提供哪些信用卡处理服务？” 根据UDDI的答案，我将选择一个。 在选择一项时，我还将根据一些WSDL文档来发现该服务的合同定义。 我将使用该WSDL，并且可能会使用它来生成一些代码，这些代码将使我能够与信用卡处理服务进行交互。
您最终得到的是这种与目录中的这些服务松散耦合的错觉，但是实际上就该WSDL而言，您与特定合同紧密耦合。 如果WSDL发生更改，那么现在突然生成的代码将不再有效，并且您必须不断地经历此循环。
因此，当我从服务发现的角度看待今天我们谈论的内容时，目录的想法仍然存在，但是在发现“那里”有什么服务方面并没有那么多。 更进一步，我们知道我们需要某些东西，并且知道它存在于体系结构中，并且具有与之关联的逻辑名称。 我只需要知道该逻辑名如何转换为可以与之通信的实际网络地址即可。
因此，这是我在该空间中处理过的典型代码示例：我正在构建商店服务和客户服务，并且我知道客户服务需要使用商店服务。 它只是不知道商店服务的位置。 我不想硬性规定，因为我会将这些服务紧密结合在一起。 但是，通过在外面设置服务注册表，我可以消除以下事实：我知道我需要从该组件实际所在的位置开始。 这样一来，我便具备了使用商店服务做事的能力：我可以向外扩展； 我可以放大； 我可以四处移动（就像我有时喜欢在云架构中那样）。 但是，在此过程中，我从不中断客户服务。
另一件事是，我们已经完全将服务合同的发现与服务注册表本身分离开了。 您在Netflix的Eureka上，找不到关于API外观的任何WSDL或规范。 现在，您可能会获得服务的地址并连接到它，它可能会告诉您“这就是我的API”，或者您可以通过其他某种方式来实现。 但是，这是两个独立的问题，我们已经将它们分开。 而使用UDDI，它们之间的耦合要紧密得多。
是的，同样，如果您像SOA和微服务一样，具有很高的思想水平，那么Service Discover和UDDI之间会有一些相似之处。 但是，实现方式却大不相同。
InfoQ：我认为您已经提到了Netflix正在开发的一些微服务。 我知道您也在Spring Cloud上工作，对吗？ 那么，您能否谈谈Netflix OSS和Spring Cloud之间的一般协同作用，以及您正在关注的某些组件？
马特： Pivotal与Netflix之间，尤其是Spring团队与Netflix之间的关系越来越紧密，并且在不断发展，但是这种关系正在继续渗透到Pivotal的其他部分。 Netflix长期以来一直是Spring技术的用户。 他们已经成为Spring Boot的拥护者和用户，并且Netflix今天正在使用Spring Boot编写大量应用程序。 在Spring Boot诞生之前，他们还是Grails的大用户。
在构建Spring Cloud时，我们在Spring和Netflix工程团队之间进行了多次对话–了解这些东西是如何工作的以及如何正确使用它们。 并不是说我们只是去拿起开源，将其包裹起来，然后扔到那里。 为了确保这些工作做得很好，进行了大量合作。 而且，关于如何利用Spring进行下一代工作以及Netflix利用其云技术进行下一代工作并使它们之间的联系更加紧密的讨论还在继续进行着更深入的讨论。 因此，我希望在未来的几个月和几年中，这两组之间的异花传粉会带来更多激动人心的事情。
InfoQ：好的。 从开发人员的角度来看，有很多事情可以使所有这些事情变得正确，而我的意思是说，有服务发现，然后当然还有通常的事情-我必须扩展，我必须连接到日志等等，对吗？
马特：对。
InfoQ：显然，像Cloud Foundry这样的PaaS可以为您提供帮助吗？ 但是，您能否详细说明微服务方法与PaaS方法或至少Cloud Foundry方法是相似还是不相似？
马特：您只在9个月前倒带，我们真的根本没有在谈论这个。 有一次微服务对话刚刚兴起，也有一次Cloud Foundry对话–从开发人员的生产力，运营效率以及总体上来说，情况如何。 在这一点上，我们正在讨论叉车运输，接管遗留工作负载并将其转移到云中。 这在很多方面都是有问题的，很难，有时甚至是不可能的。 通常，您不想这样做。
这些问题就会浮出水面：“好吧，为在Cloud Foundry上运行而构建的应用程序看起来像什么？” 我真的开始考虑这个问题。 您如何回答？ 有一阵子，答案是十二因素。 十二因子从Heroku中出来。 我们开始在Cloud Foundry中使用他们的buildpack模型。 十二因子非常适合Cloud Foundry。 您几乎可以说Cloud Foundry已调整为运行“十二因子”应用程序。 但这甚至还告诉您一些有关应用程序运行方式的实现细节。 但是当您说“我将设计一个运行良好的应用程序”时，您可以构建一个非常大的十二因子应用程序。 这就是我们要达到的目标吗？ 可能不是。
因此，我开始研究微服务。 两者之间存在这种协同作用，几乎是共生关系。 微服务具有许多与之相关的操作挑战，您无法忽略。 事实证明，Cloud Foundry旨在解决与运营完全相同的挑战。 然后您看一下Cloud Foundry：有些应用程序在那里运行不佳，有些应用程序却在运行。 您将研究微服务及其通常的构建方式，从Cloud Foundry的角度看，它几乎像是手牵手。
您不必一定要拥有另一个，但是当您将它们组合在一起时，就会产生强大的协同作用。 因此，我作为一个挑战去出去开始这段对话。 因此，在上届Cloud Foundry峰会上，我提出了一个演讲：“ Cloud Foundry和微服务：一种共生关系。” 它被接受了，我恰好讨论了这个话题。 它受到了很好的欢迎，并在接下来的几个月中获得了成功，最终使我们真正真正地投入了这场对话。
同时，Spring Cloud项目开始独立于此进行，最终我们将这两个小组合并在一起。 现在，借助Cloud Foundry，微服务，Spring Cloud和Netflix可以全速前进。 我们的目标是建立一个云原生的应用程序平台和开发框架，以创建用于构建这些架构的全栈解决方案，并利用（至少从技术角度出发）完成此任务所需的一切。 因此，剩下的就是我们用技术无法解决的问题：文化和组织方面的挑战。
InfoQ： 行业在集装箱上疯狂的一件事是吧？ 您能描述一下Spring Boot的特性吗？我会把Spring称为轻量级容器，但我不知道Spring Boot是否是轻量级容器。 您一般对容器有何看法？
马特：当我们谈论容器时，通常是在谈论Linux容器。 我假设您正在谈论Java容器。 不幸的是，容器是一个非常重载的术语。 无论如何，每个人都在谈论Docker。 那么Docker和Spring Boot之间是什么关系呢？
因此，对于我来说创建一个Boot应用程序的Spring应用程序非常容易。 Boot帮助我嵌入了运行Web应用程序所需的servlet容器，并且可以从Tomcat，Jetty或Undertow中进行选择。
因此，现在我有了一个自包含的JAR文件，可以执行我需要的一切。 这很容易，并获得一个具有Java的Docker容器映像，然后创建一个包含我的Spring Boot应用程序的新层。 因此，现在我有了这个可移植的容器映像，其中包含可以运送的Spring Boot应用程序。 我认为那里有很好的协同作用。 如果您将其与即将通过Cloud Foundry或Lattice在Diego上运行Docker或Rocket映像（或其他任何功能）相结合，那么您将拥有一些非常强大的工具。
从连续交付的角度来看，可以说我在笔记本电脑上运行的东西，通过持续集成管道运送的东西以及现在在Cloud Foundry上生产中运行的东西都很棒。同一件事情。 持续交付的核心原则之一是差异很重要–即使微小的差异也可能是两者之间在这里起作用而在那里不起作用的区别。 因此，知道这些东西（我开发的东西，我测试的东西以及我在生产中运行的东西）在根文件系统中都是一样的，这使我大大提高了信心，相信它们会真正起作用。
关键区别在于，显然这里有一个内核，那里也有内核。 大概是相同或非常接近的。 但这是唯一应该有所不同的东西，而这并不是几年前我们就能轻松实现的。 很难做到这一点。 我们可以用虚拟机来近似它，但是它们比较昂贵，但是不幸的是，它的周转时间仍然很长。 现在，我可以在几秒钟内使用容器完成此操作。
现在，您仍然需要解决许多问题。 您如何增加规模？ 您如何管理这些图像的创建和更新？ 因为如果您不擅长容器图像卫生，请确保图像来自同一根目录（这是有道理的），那么您可以做的是创建大量彼此之间没有太多共享的图像。 您可以填满磁盘空间并在那里造成很多低效率的情况。 看起来看似简单。 我可以在五分钟内创建并运行一个容器映像。 这是一个入门练习。 当您超越这一范围时，团队需要做大量工作来创建一个纪律严明的流程，并需要一套工具来围绕以一致且可重复的方式创建和管理这些映像，以便不同的团队交付应用程序。 ，我们都没有自己的定制根文件系统，实际上，我们受益于容器映像可以为我们带来的预期效率。
我要说的是，那里没有免费的午餐。 这些东西都是强大的工具，但是没有一个是免费的。 为了有效地使用它们，您必须学习一些东西并改变做事的方式。
InfoQ：InfoQ的受众是大量实践敏捷的实践者和架构师。 我认为我们已经从敏捷开始。 所以这是我们最后要回答的问题。 从架构的角度来看，敏捷有意义吗？ 有时人们会说只是继续即兴而做，是吧？ 建筑与敏捷如何融合？
马特（Matt）：我认为某种意义上敏捷具有仪式，有时这些仪式使敏捷的心脏模糊不清，因为它会不断地响应反馈。 我们没有做大计划。 我们不做大设计。 我们不做大型架构。 我们看到了这一点，如果我们不注意的话，我们可以从频谱的一端开始，从繁重的，预先的计划和设计，瀑布，或者任何您想称呼的那端，我们可以一直飞翔到另一端，说我们什么都没考虑。 我们什么都不设计。 我们什么都不会集思广益。 我们紧跟方向盘，然后猛烈前进，继续前进，继续前进，继续进行编码，编码，编码，测试，测试，测试。 我们相信，最终，正确的事情将会浮出水面。 两种极端都不是一个好方法。
Rich Hickey在几年前的一次演讲中引起了很多人的兴趣（链接到InfoQ上的演讲链接：http：//www.infoq.com/presentations/Simple-Made-Easy）。 在演讲的一部分中，他将测试驱动的开发比作他所谓的“护栏驱动的开发”。 他说：“我不会将汽车不断撞在护栏上，并希望它们将我保持在道路上，从而使汽车保持在道路上。” 很多人认为他说测试驱动的开发是坏的还是愚蠢的。 你不应该这样工作。 你不应该做TDD。 我不会为Rich发言，但是我认为那根本不是他的意思。 我认为关键是仍有思考的空间。 实际上，思考是必不可少的-考虑架构，考虑设计，了解您要去的地方，然后使用TDD之类的实践作为工具来帮助您实现目标。
因此，可以暂停一下编写测试和代码的时间，然后开始思考，好的，我们要去哪里？ 希望该模块或API外观如何？ 我们将要面对的担忧是什么？要么使我们难以为其编写测试，要么甚至不知道如何为它编写测试？ 因此，也许我们需要退后一步，进入房间，绕过白板，然后将所有内容绘制出来。 但是，那么我们就不会将其转换为重量级的正式UML文档。 进行轻量级的体系结构和设计是完全可能的。 首先，您可以简单地意识到工作是从您的头脑开始的，然后再从您的手中流到键盘上。
我认为，当您在团队中找到合适的位置时，您就会找到成功。 该位置主要基于您要构建的东西。 它固有的复杂性是什么？ 如果要构建相对较小的应用程序，则可能不需要那么多架构。 但是，对于构建由微服务组成的大规模分布式系统而言，这些微服务以“ Web规模”运行并试图支持数百万个用户，那么，您可能不仅会以TDD的方式出现。
因此，我认为就像软件工程中的所有内容一样，这个问题也没有二进制答案。 不是这个或那个。 在这两个极端之间，您的团队有一个正确的答案。 您必须在上下文中找到要解决的问题的答案； 您需要多少架构实践，实际需要多少文档。 而且我认为，如果您只是备份并认为敏捷可以使反馈循环持续进行-获取反馈，做出响应，进行课程改正和构建正确的东西-则其余所有这些内容都可能会自行解决。
只要持续改进，持续反馈以及对该反馈的持续响应是您正在做的工作的核心，那么您可以进行架构设计，也可以进行配对和TDD。 您可以执行任何这些操作，并且会为您的特定情况找到合适的平衡点。
关于被访者
云原生架构
815
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
