「微服务大牛讨论」微服务：模式和实践访谈

所以，欢迎回到微服务模式和实践跟踪。所以我们有所有的扬声器，除了一个，但这很酷;谈谈 - 是的。来吧。我们有所有发言人，这很棒。很棒，我们五个人。非常非正式，我没有正确 - 你知道，这是你想听到的。所以我想我们会试着弄清楚如何居中 - 为你和我们准备一个麦克风。太棒了，我们有两个，我可以成为赛跑者，也许我会请一位志愿者来帮助我。我会保留这个。很酷，火了。

在进行绿色部署时，如何管理数据？因此，例如，您可能有一个写入新记录的版本，旧版本无法理解，旧版本如何知道它不是错误，它实际上是真实数据？

Randy Shoup：我有一个答案，但你为什么不首先尝试它。

Roopa Tangirala：所以当你在Netflix上进行更改时，你可以做到这一点，它是无状态的，这不是问题。但是当你对Cassandra进行更改时，它就是无模式的。因此，当您添加新列或更改架构时，您不一定需要执行DDL来更改架构。您可以直接插入新数据集或新列系列新列。这是一种方式。

另一方面，如果他们帮助从一个列族迁移到另一个列，我们帮助他们构建工具，我们拥有客户端库，所以我们可以帮助他们写入旧的和新的，我们有像fork这样的工具升降机，有助于从源头升级到目的地，但并非所有部署都需要在我们移动数据的地方进行更改，至少这是Netflix所具有的。

Chris Richardson：我想补充一下，所以为了减少部署时间，限制你可以在数据库级别进行的各种更改。例如，您可以添加列，但不能只删除列。因此，它需要仔细进行更改，并将数据库架构更改与零停机时间部署分离。

Randy Shoup：是的，不要做你刚才说的话。甚至不开玩笑。所以你所做的就是破坏了界面。您进行了非向后兼容的数据更改，并将其公开给其他人，并且您以某种方式执行此操作，例如，在次要版本之间。因此，如果人们熟悉语义版本控制，那么您刚才描述的是非向后兼容的主要版本更改。我在说什么才有意义？我们曾经以这种形式生成数据，现在我们以这种非向后兼容的其他形式生成数据。

所以，不要这样做。你能做的就是克里斯所说的，也就是说 - 我们可以详细谈谈你想要做出的改变。有很多方法可以进行向后兼容的更改。您可以添加一个可选字段 - 遗憾的是，我们需要更详细地讨论它。但是，是的，您知道，作为服务所有者，您的主要工作是永远不会打破使用您服务的人。 o永远不允许您破坏客户，而客户是您的活动的消费者。从概念上讲，这有意义吗？

是啊。好的，很酷。在后面的方式。实际上，我会先到这里，然后我会到这里来。

因此，我们发现的一件事是决定微服务的边界上下文。它可能就像，好吧，我们订单，然后可能有五种类型的订单，现在我们知道微服务是一段时间后的整体。你如何决定边界背景，以便在几层之后它足够好？

Louis Ryan：我的意思是，大多数情况下，您的开发实践可能会在您的开发决策中得到通知，而不是您从一开始就会尝试猜测的任何严格的语义。我的意思是，我倾向于认为微服务是出现在需要解耦的紧急模式。我没有微服务水准。它是 - 所以它是，你需要努力。但通常，您知道，解耦在开发团队的边界上工作得很好，或者在开发团队中负责。这就是我要开始的地方。

Chris Richardson：是的，我想说这是最困难的问题之一，而且它实际上并不是微服务特有的。你知道，这基本上是另一种重新措辞的方式，就像我的模块的边界一样，对吧？我认为，挑选模块边界很困难。并且，遗憾的是，没有任何一种机械过程，如果你应用它，你会想出一套完美的模块，一些模块边界。因此，就服务而言，它就像是，大多数是围绕特定的业务对象组织的，如订单管理和客户管理等。但这是你的第一个猜测，你继续这样做，如果你以后发现某些服务太大了，那么希望在那一点上，该模块的两个内部部分之间有足够的边界，这样你就可以分开它以一种有意义的方式。

然后，就像路易斯所说的那样，服务点就是让一小群开发人员能够快速安全地交付。而且，就像 - 如果一个模块，你知道，如果一个服务变得太大，这真的意味着正在开发它的团队已经变得太大了，并且它们被通信开销所拖累。所以你有点想要分裂团队，你想要拆分代码，这样他们就可以重新成为一个小而敏捷的团队。

Randy Shoup：我还有一个想法，然后我会回到前一个问题的家伙。所以我断言的其中一件事是因为我相信，如果你是，你知道，五人初创公司，你可能不想从微服务开始。部分原因是它仍然有点复杂，构建分布式系统可能要复杂得多，每个人的问题都围绕着复杂的事情。当你小的时候，你想开始做一些不同的事情。另一部分是你想要了解你的域并在你做微服务之前以合理的方式分解它。那有意义吗？微服务只是域的分解的物理表现。所以我发现，因为我已经尝试过多次尝试并且未能做到这一点，我第一次解决了一个新问题并弄清楚域名的分解是什么 - 我一直搞乱它。我有一头白发/没有头发，我已经这样做了一段时间。因此，当你很小的时候，可能不会从微服务开始的规则有两个罕见的例外。

首先，如果您的MVP，如果您的最低价值产品需要规模。因此，如果您正在构建Heroku竞争对手，例如，您正在构建互联网基础架构，那么您可以从一开始就进行扩展。这是一个要求。第二个是，如果你了解你的领域超级好。那里的例子，我能想到的，一个很好的例子就是建立新银行的人，对吧？所以来自巴西的Nubank昨天发表了第一次谈话，他们在“你总是想知道的架构”中，开始使用微服务。为什么？因为你在过去50年中所知道的银行的组成，因为银行的组成部分真的很容易理解。但对于我们其他人来说，我们并不了解这个领域，这就是为什么这是一个如此重要的问题。

我们知道我们是一个单一的应用程序，我们知道我们想要获得业务上下文类型的服务。但是，这条线在哪里绘制 - 它是产品级别，API级别，微服务水平？那条线在哪里？这感觉恰到好处吗？

Rafael Schloming：当然。是的。这是一个 - 这是一个很难的问题，但我认为其中一种有助于思考的方法实际上是兰迪先前所说的，不考虑微服务的大小，代码行，考虑范围，以及如何定义范围？好吧，你需要了解你想要达到的高水平，一两句话。所以我总是喜欢思考，你知道，这实际上是关于你如何知道API是否完成的问题。

它实际上是服务用户与提供该服务的团队之间的协商。您需要跟踪使用情况，如果您的用户满意，那么您就完成了。而且，是的，假设您不必每五分钟更换一次。所以，是的。所以它 - 从框架的角度思考，了解服务的用户是谁，以及从那里开始，真的很有帮助。而且，从这个角度来看，你可以尝试很多不同类型的API，这些API可以提供相同的任务，并找出你需要的东西。而且，您可以再次跟踪您在创建用户方面的成功程度，以便在您艰难的设计空间中进行迭代测量。这就是我要说的。

Randy Shoup：所以这是一个轻微的翻转响应，但我并不是以任何激进的方式表达它。你们知道吗，你们建立了一个类，比如Java中的一个语言类还是其他类？不，你是如何建立的，你怎么知道课程的范围是什么？这是一个设计的东西，课程是一个单一的责任;我们试图使界面最小化，尽量不要聊天。我们这样问的原因不是让你当场，而且为我工作的人现在正在笑：这是我和我的团队多次做过的事情，这对我来说是合法的。说。男人，微服务，我们之前从未建立过服务。您是否构建了类，是否构建了类似于特定的界面，您知道的语言环境是什么？哦，是的，我们完全做到了。你怎么弄清楚进出的是什么？这很简单，我们会随着时间的推移对其进行改进。

这就是答案;你知道的不仅仅是如何设计服务。如果您知道如何设计类，那么在大多数情况下，您知道如何设计服务。唯一的一部分是认识到你不能像服务那样​​对你的过程中正在进行的过程中使用的东西。那有意义吗？但是，除此之外，你已经知道了。如果您知道如何构建应用程序，您完全按照徽章上的人员进行操作，那么您已经了解了比构建服务更多的知识。

克里斯理查森：是的，分解适用于许多层面。从某种意义上说，您可以分解方法和类以及包，模块，因此微服务只是这种层次结构中的另一个层次。我要补充的一点是，我认为微服务也与团队结构有着这种重要的关系。就像对我来说，我认为微服务有两种模式。有这种超细粒度模型，这是每个开发人员的一项服务，似乎在一些公司正在发生。对？或者，当你拥有成千上万的服务时，我的意思是，那种数量级。另一种思考服务的方式是，足够小的引用“应用程序”，团队可以保持敏捷和敏捷。

这就是一种 - 这是一种更为粗糙的微服务谷物模型。这会影响分解。

Louis Ryan：所以，是的，我的意思是，我认为这可能是房间里很多人的常见问题，他们有一个他们想刮胡子的单块牦牛，这是完全没问题的。在您认为剃须增加价值的地方开始剃须，并在您没有​​获得更多价值的地方停止剃须。如果它正在做它应该做的事情，那么可以拥有一块巨石。我知道这可能是异端邪说，但如果它正在做它应该做的事情。如果不是，请刮胡子，然后迭代。

Randy Shoup：对不起，这是休息时的一个很好的问题。我会在此之后闭嘴。优秀的问题或多或少，嘿，微服务值得吗？对我们大多数人来说，答案可能不是，对吧？这是 - 再次，正如我在演讲中试图说的那样，它是.1％，0.01％达到了真正的大，绝对你 - 谷歌，亚马逊，Netflix，StitchFix没有办法没有微服务。但微服务，如果你没有巨大的负载，坚持使用巨石就可以了。就像这一点，我们什么时候应该坚持使用微服务？那么，你什么时候应该，你什么时候不能独立扩展，什么时候放慢速度，什么时候会以不同的速度发展？那是你必须扩展的墙。但如果你感到高兴，我很高兴 - 我们会这样说。

Chris Richardson：我想补充一点，比如，你知道，如果你的开发速度不是它需要的地方，我会在切换到微服务之前开始审查你的开发实践。因此，例如，如果您没有彻底进行自动化测试，我认为根据源实验室报告，可能有70％以上的组织没有 - 完全不接受自动化测试。所以，如果你是其中之一，那就先做好。然后，你知道，一旦掌握了这一点并且你真的能够尽可能地自动化，那么考虑一下微服务架构。有点像，在跑步之前尝试跑步或走路。

Rafael Schloming：是的，这是一个很好的观点。对不起，这是一个很好的观点，而且一件好事只是，它不需要超重，就是追踪你花时间的地方。如果您正在进行大量的手动测试，这会减慢您的速度，那么您不一定会在日常工作中考虑这一点。并且，你知道，如果你花费大量时间与你的巨石的特定区域搏斗，也许那时你应该开始剃掉你特定的牦牛。

Louis Ryan：所以我认为兰迪给出了几个你可能想要这样做的例子，规模是业内引用的更明显的例子。我认为还有其他原因;安全性是你为什么想要削减你的巨石的一个重要原因，因为你有两件事不应该在同一个信任域中粘在一起，这是一个很重要的原因。他的开发经验显然是一个，释放速度是一个大问题。因此，有多种原因，你知道你的域名，你知道你的域名正在发生什么，你应该能够推断出这些决定的原因。

克里斯理查森：是的，从我的角度来看，它很有意思。我认为微服务主要是一种解决复杂性而不是扩展的方法。缩放，我的意思是，显然，这是一种扩展方式，但复杂性是第一位的。

是的，我有一个问题 - 你们可以评论团队用于获得微服务的模式吗？它们是从真正重要的中间开始的，它是一个重要的对象，或者我是在它没有产生重大影响的一侧做的，我可以在现有应用程序上打一个休息API并调用它微服务？

Chris Richardson嗯，你知道，如果你是 - 如果你的年度奖金取决于拥有微服务......但是，我只是开个玩笑。但是，不，我的意思是，微服务 - 这个术语微服务真的会被滥用，对吗？就像这个动议一样，我可以 - 我可以使用一个微服务，这是一种错误的概念，我的意思是，从我的角度来看。微服务是微服务架构的一小部分，微架构架构是应用程序的架构风格;这就是拥有一个系统。

还有一件事要考虑，所以如果你有这个巨大的巨石，如果有一部分是非常非常积极的发展，另一部分是你永远不会触及的，那么如果你想把它们拿出来，要知道，如果要构建微服务或服务，请提取应用程序中经常更改的部分。因为那会给你带来最大的收获。

你知道，如果你考虑一下你的整体，那就是发展缓慢，你从微服务中提取出来的一切都在快速部署，快速部署和所有这些。因此，您希望将精力投入那些真正有效的领域。

Randy Shoup：所以，一如既往，我有想法。所以这是我的想法。这些步骤，所以我将从整体到微服务进行一些架构改变。因此，我想证明这种千禧一代的微服务方式实际上是一件事，并且会在我们的环境中发挥作用。所以步骤零是做一个飞行员。所以我想考虑的方式 - 让我们采取对我们的业务至关重要的纵向，端到端的实际体验，例如，我不知道您的业务是什么。让我们想象一下，你有一些对用户真正重要的东西，并以一种新的方式构建它。所以它可以合法地成为一种新的东西，你将建立一种新的方式，或重建一种以新的方式存在的旧东西。无论哪种方式，采取垂直的端到端事物并以现在的方式构建它。为什么？

我们正在建立一个试点，我们想要降低它的风险，我们想要学习所有我们不了解微服务的事情。我们将其作为试点而不是构建整个基础架构。我们提供垂直的端到端用户体验，因为我们希望能够专注于某些特定的事情，并告诉我们我们需要做什么，不需要做什么。如果我们选择无关紧要的东西，我们就不知道里面或外面是什么。如果我们选择实际有用的东西，那么这将有助于我们专注于完成工作所需的最小事情。我们选择有用的东西的另一个原因是，如果这不起作用，最坏的情况是，我们为客户提供了一些价值。

那有意义吗？这就是步骤零，那个飞行员。既然这个试点成功了，我们已经学会了所有关于如何以新的方式做事的事情，我们将其称为微服务，现在步骤1-N采取的是投资回报最高的事情，不是最简单的事情，不一定是最艰难的事情，而是投资回报最高的事情，我们首先将这些转变为新的方式。

所以这有点，我打算，比如，你知道，消费者，我想要过去所有人们正在发表的评论。因此，考虑一下真正快速变化的领域，可能具有最高投资回报率，或者收入最高的网站部分，这将是一个有利于更快地获得更多收入的地方。这有意义吗？你做了飞行员，你冒了风险，然后你做了最高的投资回报率，然后是第二和第三高，你继续前进，直到你没有耐心或资源。如果你在完成之前就用尽了，那很酷，因为仍然存在的巨石不是你关心的东西。没有投资回报率，它没有超出我们需要的范围，你知道，有动力将其转换为微服务。

这正是Ebay所做的。因此，当Ebay-来到这里的人听过我之前关于Ebay的谈话时，有了这个怪物C ++巨石，他们把它分解成许多用Java编写的应用程序。所以它不是微服务，但原理是一样的。一旦他们做了试验并且他们确信Java可以在Ebay基础设施中使用技能和人员以及所有类型的东西工作，那么他们基本上对网站进行反向排序，比如，哪些 - 他们把网页打开了该网站并通过收入贡献对其进行逆向排序。所以他们首先转换的最高收入页面，并不是因为他们非常想要承担最大的风险，但是，如果他们没有耐心，金钱或资源，他们首先做了最有价值的事情。甚至在我2011年离开那里的时候，他们已经在2000年或2002年开始了重新架构，或类似的东西，他们大部分已经完成，我想说2007年或2006年。它花了一段时间，并且即使我在2011年离开后，仍然存在V2上的东西，比如C ++ monolith体系结构，但它们是没有人使用过的东西;他们很简单，他们没有改变。所以没有投资回报率将其转换为新的方式。你去吧

我的问题是关于微服务之间的通信。所以我们谈论有事件，所以服务A谈到服务B-顺便说一下我在这里。那么，对于关键业务服务，如信用卡处理，并说我们看到Kafka或其他经纪人的大量模式，一旦我收到 - 一旦消息在经纪人中，那么有办法恢复，或重试。但是，建议确保信用处理服务确实发布事件的建议是什么？我看到，例如，Kafka现在有Kafka连接，并且对于每个数据库提交或每个数据库事务，它都可以直接发布到Kafka。如果业务对象与数据库中的业务对象不同，该怎么办？所以我想在这里得到你的想法。

Roopa Tangirala：所以在服务方面，拥有真相的来源，因此每个应用服务都是其所服务数据的真实来源。因此，对于付款处理，在Netflix的情况下，他们不使用Kafka，他们有不同的付款工具。他们使用交易数据工具进行支付处理。但基本上这个想法是每个服务都拥有它负责的数据，而且它是真相的来源。对？

所以，这就是交互发生的方式，比如，其他服务会询问服务而不是直接复制数据集或在后端有多个副本。

克里斯理查森：它有几个部分。一种是在数据发生变化时以原子方式发布消息。因此，从概念上讲，更新数据库和发布消息涉及到一个事务。所以，我将在我的演讲中介绍的其中一件事情，接下来 - 显然轨道主持人不会，那里，因为他将会发表不同的演讲。所以无论如何，围绕事务性消息传递有一个完整的东西，这是一种方式，这是一个非常有趣的话题。然后，它最终可靠地发布到消息代理。

那就是，你知道，第一步。然后是第二步，您的消息代理必须可靠。这就是兰迪至少在交付时所谈论的内容。然后是消费者端，您需要幂等事件或消息处理来确保正确的语义，并且包括跟踪您看到的所有消息ID。所以这是一个完整复杂的话题，我将在今天下午晚些时候讨论，有些我会在我的书中介绍微服务模式，无耻插件。

Rafael Schloming：我只是想参考一下，你知道，这就像设计课程一样，这个所有权领域是 - 所有权和整个沟通领域，以及整个事件。这是您转移某些数据所有权的责任。这就是微服务与设计类最不同的地方，或者他们与设计传统类API最不同的领域之一，因为你不必担心，你没有这样，有点，您知道，类层次结构的上下文中的数据的位置。因此，这是一个值得关注的事情。

我想，只是一个后续问题，在最后一个问题上有点像燕尾。与事件驱动的体系结构相关，您是否可以从面板上分享您对使用值传递，通过引用这些消息以及消费者如何处理该消息的想法，以及您对如何处理订单的想法那些？

Louis Ryan：我可以提出我的看法，这也可能在某些方面有些异议，但这受到了Google规模的影响。我们大多不这样做。大多数服务通信服务都不通过代理进行协调。我们使用诸如重试和网络级别之类的东西来通过不打击存储来扩展。你知道，这又是一个规模问题。如果存储中的持久队列为您提供了大规模应用程序级别所需的可靠性，那么您应该使用它。我认为，在某些规模上，某些模式可能会变得更加有限，特别是取决于等待的工作量。对？因此，我们并不反对这种模式，我们确实使用了这种模式，并且我们使用封装在API后面的模式，并明确分配责任。但是，在大多数情况下，我们不会这样做。我们不做会合或那种类型的事情。

克里斯理查森：我不相信你不使用卡夫卡。

Louis Ryan：我们看起来像这样的东西。

克里斯理查森：不，这是个玩笑。但卡夫卡看起来很时髦。

路易斯瑞恩：所以我听到了。

克里斯理查森：无论是对还是错。所以，对我来说，所以当你 - 所以当我们谈论事件时，在我的大脑中，我所翻译的是域事件，这是域驱动设计的概念。所以，如果你去阅读其中一本DDD书籍，你知道，他们就像Vaughn Veron或Vernon Vaughn一样实施DDD，它有一章关于域名事件，包括你在活动中应该拥有的东西，你可以选择。如果创建了订单，您可以发布订单ID，但这对消费者没用，因为他们必须获得订单。所以有事件丰富的概念，它说放置对事件中的消费者有用的有用数据。当您发布订单创建的事件时，请在其中填写订单详细信息。当您使用事件源时，您的事件是域对象的存储机制，除了将必要的数据放在那里之外别无选择。

然后你的另一点是订购，是的。我认为有序，至少一次，域事件的交付真的非常非常重要，因为如果它们无序到达，那么你将会有非常奇怪的行为。我的意思是，可能还有其他情况你不关心交付，你可以发布/分发一个事件，但订购通常非常重要。

Randy Shoup：你问过这个问题，当我多次得到这个东西时，我是如何处理事件传递的，我该如何处理事件排序？因此，在事件过程中或跨分布式系统的消息传递中没有的那些事情或那些问题。是的，我想我们已经提供了部分答案，我想我会说，我的意思是，我一直威胁要做这个活动大师班，它可以 - 每次我都谈论这个问题。你去，玩得很好。所以，是的。让我们来看看。

因此，再次，在交付时，您最多可以拥有一次，或至少一次。如果您关心自己的活动，至少需要一次。那就是失败;我送了两次，三次，N次。最多一次基本上用于记录数据，那些失败的东西你想放弃它。域事件不属于该类别，但记录的是事物。这是第一件事，然后你有多次，然后你必须是幂等的，客户端必须多次交叉引用。如果您在夜间通过这些问题（无冲突的复制数据类型）保持警惕，则应该考虑CRDT。

然后就事件排序而言，A，处理它的几种方法之一。你可以处理公共汽车的订购，发誓，这不是很好。处理它的另一种方法是让事件成为发生事件的通知，然后你去回读为当前状态产生事件的服务。这些都是解决问题的合法方式，并考虑这些答案 - 兰迪的做法与克里斯的方式相比，路易斯的做法。想想这个问题有一个解决方案的空间，并且不要通过推理第一原则来解决它。我试图解决它，说这很容易 - 不，不是。几十年来，很多人已经对此做了很多考虑。

Refactoring Fame的Martin Fowler给出了一个精彩的主题演讲，今年在芝加哥GoTo举办的事件驱动架构上，这是18分钟。而且，他以非常好的方式，非常清楚，他通过事件的利弊作为通知，以及随身携带数据的事件，事件采购等。这非常值得您18分钟结账。

路易斯瑞恩：我想提一个警示故事，或者不一定是一个比喻，但我早些时候就超级大国发表了一个话题，提防超级大国。事件经纪人是超级大国。当你把事情排成队伍时要小心，你不知道他们将在何处或如何出来，或者他们会出来。如果您不知道这些问题的答案，那么在您回答问题之前，不应将这些问题放入队列中。如果您有关心的数据或您的用户关心的数据，您需要在某种程度上推理这些事情。事件经纪人已被提出作为一种方法来让操作员控制，以便他们可以回答这些问题，并对此进行验证。好的？

来自这里的问题，再次。让我们来看看一些进化。所以最初当网络开始时，每个人都在编写有趣的应用程序，然后是Rails和MVC以及Rust，然后人们就开始编写这些内容，然后我们就有了整体规模让我们放慢速度。现在微服务是流行语。你不能走进公司，也不能听到微服务这个词。所以，如果你退一步说，在微服务趋势饱和之后，你预见会发生什么？接下来是什么？ Microfunctions？

Louis Ryan：那不是已经发生了吗？

所以我想退一步看看，从不同的缩小镜头看下一步是什么，你知道什么 - 你认为会发生什么？

Randy Shoup：元回答是看看谷歌，亚马逊和Netflix现在正在做什么。如果你提出这个问题，那就没有羞耻，如果你提出这些问题，我会翻转，你就要落后于这些人，这是件好事。您无需推理，您可以查看这些较大的架构共享的内容。

克里斯理查森：是的，这是一个有趣的。在某种程度上，有一个限制，超出该限制，分解模块没有意义，对吧？所以，如果你回到面向对象设计中的一些经典工作，即常见的闭包原则，那些因同样原因而改变的东西应该打包在一起。这意味着，如果将一个包分解为两个包，并且实际上，您已将这个业务概念拆分为这两个包，那么无论何时该业务概念发生更改，您都要更改这两个包。所以你将看到这个锁定步骤。

当然，对我而言，微服务架构中的反模式中存在一种模式，即分布式整体，您实际上就是在那里同时发布多个服务。从逻辑的角度来看，这是一个部分。

然后，你知道，从简单的技术角度来看，你可以肯定地说，在部署方面，我们的部署单位已经越来越多，它的重量越来越轻，而且越来越短暂。所以，10年前，如果你想部署一些东西，你必须得到一台物理机器，或15年前。而现在你只需在AWS上部署一个lambda，就像 - 并且在如此短的时间内，这是我们如何部署事物的根本转变。所以，对我来说，这是一种巨大的趋势。甚至从设计的角度来看，您必须牢记这种常见的封闭原则。

Rafael Schloming：有一种方式我喜欢思考这个问题，这个问题与此非常相似，但是从不同的角度来看，这就是考虑到你需要多少人才能完成某些事情的趋势。如果你看一下从整体到微服务的转变，通过组织视角，这就像分工的转变，对吗？你正在接受一个团队，一个由数千人组成的工程团队的输出，你从根本上将这项工作的成果以不同的方式组合成一个连贯的洞。如果你看一下，你就会知道，10年前，提供给定服务所需的团队规模是多少。我的意思是，今天，一个少年可以在周末从父母的地下室做同样的事情。所以，至少接近于此。

所以我认为这个限制真的归结为，好吧，对，那个团队规模，你知道吗，你能有效地停止收缩的重点是什么？这是一个单一的开发人员可以吸收和完成多少，直到你投入像AI这样的东西，我相信人们现在正在做什么？

克里斯理查森：我可以回应吗？有趣的是，我不知道单个开发人员编写代码的效率是否有所提高。对？喜欢，编写和创建全新的代码。所以我回头看，有些事情发生了变化，对吧？就像机器变得越来越快，如果我们陷入困境，就会有Google或Stack Overflow。然后就是所有这些开源软件，所以我们可以快速组装一堆库，如果我们遇到困难，我们就会得到答案。但是，就从头开始编写代码而言，我觉得这是一个单独的开发人员，以某种方式混淆，摸不着头脑。而且，如果这没有改变，我们在这方面没有摩尔定律用于软件开发。

Louis Ryan：所以如果我们处于预测领域，你知道，我认为有些答案是在供应商的摊位之外。越来越多的代码在同一个网络上运行，我并不是你的意思，我同时也意味着你们所有人。你们都把你的代码放到云供应商那里;这个房间里的其他人比以前更加本地化了。所以我们有这种有趣的网络效应。微服务不仅仅是您构建服务的一种方式。它也是您使用其他人为您构建的服务的一种方式。

所以我认为，当我看到那里，我看到供应商销售某些类型的服务时，让我感到震惊的是，它们是大型供应商过去销售的小型版本。当我看到它时，我看着APM空间。当有更多的微型投影机时，你会看到这种趋势继续下去;会有更多的市场可以帮助你获得有趣的东西。就像有人询问地理位置一样。你可以购买它作为一项服务。这是一个小小的服务;它在API方面做得很少，而在后端方面却有很大的数量。所以这是我们可能期待看到的一件事。

Rafael Schloming：我认为这两个答案引发了一千个，抱歉，这引发了很多。我不认为开发人员编写了一千行代码，但是他们的工作效率更高，因为他们想出了如何组装很多东西，以及你刚刚提到的其他东西，或者你刚刚提到的是一个例子。 ，有点，其他东西要组装的市场。

因此，当我登录到Netflix这样的应用程序时，它是一种非常无摩擦的用户体验，你知道，我登录一次，我没有意识到我正在登录微服务以获取我的用户配置文件，然后我没有登录或重新体验 - 我的客户历史等等。那么，在微服务架构中，您如何维护这种无摩擦的UI？因为我们大多数人都在编写跨越多个服务的应用程序，但从用户的角度来看，它实际上只是一件事，他们试图去的一个应用程序。那么我如何保持无法共享的架构的优势，我可以独立部署，我不会在它们之间创建这些依赖关系，但与此同时，我保持一种无摩擦，统一的用户体验，相同的外观和感觉？谢谢。

Roopa Tangirala：当然。你好。是的。因此，看待它的方式就是，微服务层中也有不同的层。所以有前端，它占用了所有用户流量，然后我们有中间层和后端层，这是您的会员资格和为您提供该数据集的所有酷服务。因此，就UI集成而言，这些服务之间存在很多交互，但是，在任何给定时间，真相的来源只是一种服务，对吧？

所以，在与UI的交互方面，我们所有的UI团队，我都不是 - 我对这个UI层没有太多的见解。但是他们在确保这些微服务之间的所有交互以及他们在UI中获得的结果是无缝的方面做得很好。幕后有很多工作要做，但每个微服务都与另一个没有关系。这样，您就知道要调用哪个服务。因此，虽然有很多互动，但你也有后备。因此，从UI的角度来看，您没有看到您的体验有所降低。如果您无法获得要观看的个性化电影列表，那么如果您无法使用该服务，那么他们可能会让您回到后备页面。所以你可能不会遇到降级服务;你并不认为自己没有看到活跃的电影列表，但通过这项服务，它可以为您提供后备体验。

大。所以我们没时间了。这是一个很棒的问题，非常感谢你。