瓦特（Watt）：这是微服务专家组。Chris早些时候谈到了最小化微服务中的设计时耦合。他是microservices.io的创建者，《微服务模式》一书的作者。他也是Java冠军，在微服务领域非常有经验。我期待着与你们一起深入研究其中的一些领域。当然，我们有詹姆斯·刘易斯，他是最早创造和定义术语或架构风格的人之一，我们今天称之为微服务。James是ThoughtWorks的软件架构师和主管。ThoughtWorks技术咨询委员会成员，以及创建技术雷达的小组成员，致力于推动业界采用开源和其他工具和技术。还有凯蒂·加曼吉。凯蒂是CNCF的生态系统技术倡导者。她的重点是更广泛的生态系统和能够帮助微服务生存和繁荣的工具。她帮助发展和领导最终用户社区，同时缩小与其他一些生态系统领域和单位的差距。她过去的角色包括云平台工程师，她构建了很多平台，这些平台都被云本地技术所吸引，其中包括Kubernetes。

微服务还和十年前一样吗？

我想也许我们可以从一个问题开始，实际上，微服务作为一个定义。它真的还意味着我们今天认为它意味着什么吗？James，你不久前创造了这个术语，如果我们考虑敏捷，敏捷在今天的含义可能并不完全相同，因为它今天的含义是一样的。微服务还和十年前一样吗？

理查森（Richardson）：那是什么，詹姆斯？

刘易斯（Lewis）：我不知道。我应该指出，出于完全开放的考虑，不仅是我，还有弗雷德·乔治。Adrian Cockcroft同时谈到了细粒度SOA和微服务。我认为这只是一种趋同进化，不管它叫什么。时机已经成熟的想法。当时，这在很大程度上是对以技术为中心的大规模软件开发方法的反应。我们专注于技术层和所有的工具和技术，我认为我们真的希望将其从技术层带到更多的业务中，更多地关注业务，发挥更多的DDD，发挥更多的业务能力理念。本质上，我认为它有点像极限编程。有人引用Kent Beck的话说，“它只是一次做了所有的好事，结果变成了11个。”我认为这才是微服务架构真正的意义所在。它将当时存在的许多想法汇集在一起。如果你想想当时的游击队面向服务的架构。吉姆·韦伯是这个想法的始作俑者。显然，领域驱动的设计，着眼于RESTful集成，这是其中的一个重要部分，并通过超媒体实现解耦。

现在它的意思是一样的吗？不，当然不是。十年后。正如你所说，Nikki，语义扩散是一件事。词语改变了它们的意思。事实上，回想起来，我想马丁和我都会同意，我们把名字搞错了。这是零碎的。它卡住了。真的，这和尺寸无关。然后，当马丁给某物命名时，它往往保持命名状态。

理查森（Richardson）：你应该使用面向服务的架构，它会消除一些反模式。

Lewis：当然，Dan North更喜欢可替换组件架构，这可能是对其真正意义的更恰当描述。这是关于可替换性而不是可维护性的设计。这是最原始的东西。

微服务中的常见反模式

瓦特：我们尝试微服务已经有相当一段时间了。我认为我们做的很多事情可能都是对的，但我想说的是，有很多是反模式。你的同事们对你一次又一次看到的最流行或最常见的反模式有什么看法，对人们如何实现和使用微服务有什么看法？

理查森：我想说一个明显的原因是人们相信这就像一个神奇的精灵尘埃。我们的工程组织交付软件的速度很慢，我们只做微服务，一切都会很好。然而，在现实中，如果您的软件交付速度慢是因为您的流程，因为缺乏自动化测试，并且您编写的代码无法维护，那么在混合中添加微服务很可能会使事情变得更糟。我觉得在采用微服务之前，或者在采用微服务的同时，您实际上必须清理您的行为并提高组织的成熟度。假设微服务实际上是解决方案的一部分，因为不知何故，你只是改进了所有其他东西。那就足够了。

伽曼吉：我可以附和。我认为这是我所看到的一种模式，当容器的采用得到更多的动力时。这不是关于容器，也不是关于技术，而是关于理解你的问题是什么，并真正触及问题的核心。大多数时候，这也伴随着文化的转变或发展。这不仅仅是关于采用微服务，而是关于你真正理解你试图解决的问题，并尝试应用一些最佳实践。谈到反模式，已经有很多使用微服务的用例，但是仍然有一些代码没有得到很好的维护。部署起来仍然很困难。自动化不是它的一部分。Chris也提到了很多功能。成功的衡量标准也不一定是真正明确定义的。其他一些组织通过他们拥有的微服务数量来衡量他们的成功，这实际上不是你应该追求的目标，不是吗？这不仅仅是关于技术，而是关于文化的转变，真正理解你试图解决的问题的根源。

理查森：我曾经和一个组织合作过。首席信息官读了我写的一本电子书，然后对微服务充满了热情，自上而下，8000人的组织，他刚刚宣布做微服务。这被转化为KPI，进而转化为奖金和其他东西，基本上就像许多微服务决定了你的奖金一样。

分布式事务

刘易斯：我们根本不是这个意思。这是我以前的客户，很有趣。这是关于分布式事务的。当您最终拥有大量服务，并且不得不协调事务并在这些微服务之间进行编排时，这可能是一场噩梦。Sam Newman和我在我们的培训课程中经常说，如果您认为您可能需要分布式事务，最好将这些事务放在一起，因为它们可能需要在同一个位置。我记得在一个组织中，他们有实体服务，然后是业务编排服务，该服务将协调这些事件和服务之间的事务。他们将其实现为ThreadLocal，因此每个调用都将存储在堆栈中的ThreadLocal中。如果他们需要解除分布式事务，他们会解除堆栈并对每个服务发出回滚。我们认为，这是一个很好的开始，因为这是一个很难解决的问题。那么，如果你需要两个呢？如果您需要其中两个，以防需要扩展，会发生什么？他们说，我们有一个计划。我们要把动ZooKeeper 带进来。现在他们遇到了所有的问题，因为现在他们也遇到了ZooKeeper 的问题。我们都知道这可能有点诡计，因为每次他们对其中一个微服务发出请求时，他们也必须与ZooKeeper 交谈。这很有趣。如果您正在构建微服务架构，我也觉得分布式事务是值得注意的。

理查森：我以前讲过，不管怎样，暗物质，暗能量，都是关于希望你分解的相互冲突的力量。那么，在服务和交易之间产生吸引力的力量就是抵制竞争的一个关键吸引力。

瓦特：我认为，在我们工作的一些客户中，我也看到了分布式的整体，在那里有很多服务，比如实体服务反模式，我认为当你从整体分解到微服务时，只是有一些非常传统的概念。然后，您必须将所有内容与事务以及跨越多个调用的所有这些内容放在一起。

Kubernetes如何影响和塑造微服务

就微服务而言，你现在无法摆脱的一件事是Kubernetes似乎与微服务齐头并进，有时甚至在这些句子中互换使用。在我们前进的过程中，库伯内特斯是如何影响和塑造微服务的？

Gamanji：Kubernetes的引入几乎就是容器的采用。对于Kubernetes，我们有一个容器编排器来帮助我们部署这些容器。这不仅仅是关于部署应用程序，而是关于Kubernetes带来的一些额外功能。例如，我们讨论的是可伸缩性。我们有一个水平吊舱自动缩放器，它可以自动识别何时需要缩放应用程序。它具有就绪性和活动性探测，这将确保应用程序重新启动，或者容器重新启动，以确保服务启动并运行。我们还有很多其他功能，如声明性配置，我们与物理基础架构层分离，因为我们需要考虑的是如何在Kubernetes世界中使用资源（如部署、副本集、服务等）定义应用程序。

然而，对于Kubernetes，它还是一种承载应用程序的机制。这并不一定意味着您可以在开发应用程序的阶段应用一些最佳实践。在很多情况下，整个单体都被部署到Kubernetes平台上。它要跑了。这将消耗大量资源。这将不是运行应用程序的最有效方式。它实际上也能让你做到这一点。有了Kubernetes，我认为它能让我们更快地，比如让我们把人们放在一个好的、积极的角度。它使应用程序能够更快地部署，但同时，它具有我刚才提到的一些功能：可达性、自动化、可伸缩性、就绪性探测、活动性探测等等。所有这一切实际上是真正的转变，从如何部署应用程序转变为只部署应用程序，将其容器化。实际上，只需使用Docker或BuildPack之类的工具对其进行打包，无论内部选择什么工具，这就足以让它真正准备好部署到集群中。

刘易斯：我刚才在看ThoughtWorks技术雷达和Kubernetes第一次出现在2015年的《评估》中，当时我认为谷歌只是开源的。微服务最早出现在这之前，Docker也出现在这之前。我认为我们所说的库伯内特斯所支持的模式，它们是更古老的模式。我不知道是否有人记得Dropwizard，它是一种有点时尚的格式。在Dropwizard之前，有一个Java库，来自同一个人Coda Hale，名为Metrics。这是一个典型的示例，放入一个简单的库，然后点击一个端点，每个应用程序都会有这个库。每个应用程序都有一个端点，它将为您提供服务正常运行时间、请求-响应延迟等等。现在，它已经从应用程序发展到基础架构。我认为这真的很吸引人，就像本质复杂性的演变一样，它仍然存在于业务代码中。然后是偶然复杂性，这是Martin Fowler的出发点，偶然复杂性正在迁移到您的网络、服务网格、侧车、容器运行时和编排工具中。我认为这是我们正在进行的一个有趣的轨迹。也许我们最终只需要一个业务分析师就可以将东西拖放到一起，然后部署到Kubernetes中。

Kubernetes是正确的抽象级别吗

瓦特：你认为Kubernetes是正确的抽象级别吗，或者你认为我们仍然需要在其上构建更多的生态系统，以使人们更容易构建微服务，因为有些东西的级别相当低？

理查森：我有几个不同的观点。我认为最重要的是，微服务架构的本质并不是真正的技术或基础设施相关。这一切都是关于正确识别服务边界、服务责任、它们的API和协作。这就是微服务架构的本质。就开发系统时必须做出的众多决策而言，这些是绝对关键的决策。我认为微服务采用的另一个反模式是，它正在反转它，然后思考，让我们找出我们的部署技术、工具和文字技术。这在很大程度上是一种反模式。这实际上都是关于服务定义的。

Kubernetes适合哪里？我将其视为许多可能的部署选项之一。一个明显的替代方案是无服务器，比如将东西打包成AWS Lambdas，然后在AWS或谷歌云功能上运行？如果这不适合，那么，可以考虑使用基于Docker的解决方案。ECS是一种更简单的选择，甚至是Kubernetes。那么Kubernetes实际上相当不错。到处都有。它从树莓皮到公共云，以及介于两者之间的一切。这很吸引人。我将其视为一种部署选项，而不是本质上与微服务定义相关的东西。

加曼吉：我可以在这里加一点，因为我认为，随着Kubernetes的流行，与此同时，我们有了另一种非常突出的文化模式。我在这里明确地定义了DevOps。同样，这不是一个部署过程。这是团队之间协作方法的文化转变。我认为这实际上非常重要，因为当我们讨论定义我们的服务可以做什么时，特别是在架构中，我们有无数的服务，并且有不同的团队控制它们。您如何确保您的API可用？您如何确保同步并了解如何使用API？如果您有一个功能需求，您如何联系该团队？我认为，DevOps文化更强调这一点，它引入了基础架构层，让平台团队与应用程序团队更紧密地协作，以确保服务或应用程序所需的所有需求也将由平台团队来满足。我认为这是关于定义应用程序的，但同时，下一个阶段是如何将其交付给消费者。有时需要更清楚地了解应用程序将部署在何处，以便充分利用现有的基础设施。这也伴随着团队之间的协作处理。

Lewis：这很有趣，不是吗，这个标准化的想法也很有趣，因为我们以前有一个叫做领域应用程序协议的东西，你可以考虑RESTful架构中的微格式。这是我真的看不到团队谈论这么多了。我想这又回到了你刚才说的，克里斯，重要的一点是这些东西是如何交流的？API是什么？我知道我可以通过什么协议和这边的另一个团队交谈？我使用的团队是服务边界的同义词。我认为这似乎正在消失。我不知道是否有其他人看到过。我们实际上要坐下来解决一个难题，即边界是什么？我们的服务之间的接口是什么？让我们商定一种相互交谈的通用方式？因为这本质上就是语义鸿沟。这就是语义问题，你不能通过技术来真正解决它，你只能通过人们相互交谈来解决它。

让人们与技术方面合作改变组织方面的挑战

瓦特：在之前的一些会谈中，围绕着如何解决其中一些挑战的实际工作所需的协作进行了大量讨论。康威定律也经常出现在围绕组织设计服务方面，反之亦然。我认为，我们经常会发现，使用微服务架构是为了帮助组织更快地发展，但这通常不会发生，因为组织实际上不会同时发生变化。我不知道你在这方面有什么经验。在让人们与技术方面合作改变组织方面，您在人力方面遇到了多少挑战？

理查森：人类，他们是麻烦。我使用成功三角的概念。这就像为了快速、频繁、可靠和可持续地交付软件，您需要三个方面的结合。从流程的角度来看，它是精益的，而且是DevOps。从组织的角度来看，这是一个松散耦合的产品团队网络。然后从架构的角度来看，它是一个松散耦合的模块化架构，有时是微服务，有时是一个整体。为了实现快速可靠的软件开发目标，您需要这三个方面。

刘易斯：这就像一句古老的格言，当持续交付是一种新事物，构建管道是一种新事物时，你会发现人们会花几个月的时间定义和构建完美的构建管道，让你的软件投入生产。我们可以按需将软件投入生产，速度非常快。太好了，什么软件？我们没有任何软件。这是一个经典[听不见00:22:47]。如果其他人看到了这一点，你肯定会想，你的构建管道有多好？因为如果你没有任何可用的软件来推动它，那就是解决真正的业务问题或产生真正的成果，那么你就不会交付任何东西。

Gamanji：从工程团队的角度来看，在内部做好战略提升工作是非常重要的。如果我们采用新的概念来部署应用程序或在内部创建应用程序，我认为创建员工可以遵守的内部标准非常重要。我认为这是非常重要的，清晰的沟通、透明和提高技能的机会。我认为人类的问题永远都会存在。但我们似乎有不同的方法来处理它。

刘易斯：组织会找到一切可能不改变的理由。Eli Goldratt几年前，我认为在《目标》（the Goal）的一篇[听不见的00:23:57]中，他谈到了范式转换，组织中的人们最难做的事情就是转换范式。有点像微服务风格的架构，采用云原生，这是一个巨大的转变。这是一个巨大的范式转变，因为它是关于人的。这是关于团队结构的。我想我们忘记了一些事情，比如，对于亚马逊，杰夫·贝佐斯（Jeff Bezos）没有说构建微服务。他说还有很多其他的东西，其他的约束，其他的强制功能，包括直接看到你的客户，建立产品团队，就像Chris说的，拥有小的授权团队，他们自己管理一切。都是这些东西。这就是一种范式转变。Eli Goldratt说，你需要三件事来改变一个范例。您需要做的第一件事是在现有的范例中尝试其他一切。你需要承受巨大的压力。你需要有人帮助你迈出第一步。当然，ThoughtWorks总是可以提供帮助的。

理查森：我也是。

瓦特：你也是，凯蒂？

伽曼吉：是的。我在这里。

如何影响管理层和领导层以适应变化

瓦特：我不知道你们中是否有人读过《团队拓扑》这本书，并且随着旅程的发展，不得不改变团队。有时您可能会有一个完整的产品团队启动，但您可能会有处于不同交互模式的平台团队。我认为这是一个可能在过程中丢失的东西，因为你发现公司倾向于建立，他们说，这是我们的结构，这是我们做事的方式。它不会随着组织和架构的实际变化而变化。对于如何真正影响管理层和领导层，使其能够认识到这一点并加以适应，您有什么建议或看到什么吗？

理查森：我认为最终，一家公司不盈利或盈利能力下降是大多数商人的最终动机。大多数组织往往不会有这样的直接危机，但如果他们有，那么这就是改变和变革的真正令人信服的原因之一。我曾经与一位客户合作过，他们是一家非常成功的公司，但他们有一块老化的单体，它是预先部署的。因为它太大太旧了，他们很难对它进行测试。它是有缺陷的，客户害怕升级，因为这意味着停机。这转化成了一个企业可以理解的问题，因为它涉及资金。然后，这实际上促使他们开始研究微服务架构，这样他们就可以切块，然后对它们进行彻底的测试。

Gamanji：我认为这是相同的问题空间，但它也可以应用于不同的领域。Chris一直在谈论采用或鼓励使用微服务。在采用Kubernetes作为平台时，我看到了一种非常类似的模式。同样，归结到相同的核心原则，每个企业都希望有一个与众不同的优势，这将使他们能够尽快向客户部署其功能。为此，有时候，当涉及到平台时，我们可以真正提供一个非常好的用例，这不仅可以降低维护基础架构的成本，而且可以使您的团队拥有更多的控制权，并且可能更容易地执行一些生命周期管理操作，例如升级和更新集群，确保有机会引入新技术，例如，服务网格。同样，拥有业务差异通常要归结于技术。在公司的不同阶段，可以采用微服务，也可以采用容器和Kubernetes，或者呼叫提供商等等。我认为这是一个正在经历的问题，即公司或组织如何盈利？

刘易斯：关于团队拓扑的话题，还有一本非常棒的书《动态重新团队》。海蒂写了这本精彩的书。这是关于实际改变团队结构的不同技术。不一定是团队拓扑，它是从平台团队到产品团队，再到它是什么。在人员轮换、保持人员新鲜、保持人员想法、保持人员参与方面。我所见过的公司中最好的例子就是制作数据库工具的Redgate，它做到了这一点，而且做得非常好。它们最初用于SQL Server，现在也可以使用其他数据库。他们做得非常成功。他们可以让员工在不同的产品之间来回走动。他们几乎有一个海报会议，每隔几个月，开发人员就会在合理的范围内选择要开发的产品。我认为这使Redgate能够做到这一点。我认为在许多组织中，尤其是大型组织中，你看不到的是，他们拥有真正的变革型领导。他们已经建立了一种学习文化，不仅仅是在他们的团队中围绕技术实践、模式和事物，而是围绕管理实践和变革型领导。我认为这是很多组织所缺少的一点，那就是我们不仅仅停留在自己的方式上。我们不会永远这样做。我们必须适应。我们必须学习。我们必须学习新技术、新风格、新的组织结构，并与管理者一样跟上该领域的最新发展，而不是坚持我们一直在做的事情。

瓦特：我认为，有时试图让这些倡议从基层开始，除非你得到管理层和领导层的认可，否则是行不通的，真的，因为你可以一直尝试，直到脸色发青，但如果高层不理解，这肯定是一个挑战。

微服务的下一次演变

关于微服务的未来，以及我们的发展方向，您是否了解CNCF或您的客户在微服务方面的最新趋势？下一个进化是什么，或者下一个我们应该关注的东西是什么？

Gamanji：我想在这里提到一些方法或工具，特别是在应用程序开发方面。当我们谈论Kubernetes和cloud native时，它围绕着集群，围绕着如何使用Kubernetes资源在配置中定义应用程序，等等。然而，现在有一个转变，重点完全放在应用程序开发人员身上。开放应用程序模型就是这样构建的，两年前在2019年被外包。这几乎允许将重点从基础架构层转移到应用程序层。最重要的是，您将能够在config中的代码中定义应用程序，并且能够跨云提供商部署它。这不仅仅是关于Kubernetes的，如果您想在数据中心或云提供商中部署它，您也可以使用这个特定的工具。

另一件我想从云原生空间提到的事情是Gitpod，它专注于应用程序开发阶段。Gitpod实际上是一个编纂本地开发环境的工具。这是一个巨大的使能器，特别是当有人在本地创建或开发应用程序时，如果遇到bug，他们将能够将其完全编码。它都基于Git存储库，您可以像一个文件一样挥舞，甚至可以像Git存储库一样挥舞，就像一切都在那里一样。其他人将能够完全重新创建它。这将是另一位工程师的镜像。这种可移植的开发环境，也一直是人们关注的焦点。

当然，就应用程序的实际部署而言，我们有不同的方法，同样可以使应用程序更快地推送到生产环境中。这就是GitOps非常突出的地方。这也是一种机制，您可以将应用程序的所需状态存储在Git存储库中。但是，它改变了开发人员将应用程序部署到集群的方式。对于所有这些工具和方法，我想说的是，Kubernetes将留下来。我们有许多调查证实了这一数据。我们有一个来自VMware的关于Kubernetes状态的最新调查，而且每年他们都看到生产中使用Kubernetes的数量在增加。现在不仅仅是基础设施，我们正在努力提高开发人员的体验。这就是我提到的所有这些工具和方法能够真正蓬勃发展的地方，它们最近实际上获得了很多动力。

瓦特：詹姆斯，你觉得怎么样？

刘易斯：对我来说，技术是一回事。这正在演变。发生了巨大的爆炸。我做了一次演讲，回顾了微服务最初出现的地方，以及它之前的内容和之后的内容。在监控、日志记录和容器编排方面，您会遇到这种巨大的爆炸。真是太棒了。我相信，这种情况会继续下去，因为这会让很多人赚很多钱。我认为我们还没有破解更多关于领域的东西，更多关于业务架构的东西。正如克里斯所说，边界是什么。在开始编写代码方面做得很出色，很多是模式，其他人也在做类似的工作。对我来说，这是一条至今仍未落地的信息。是关于生意的。这是关于团队结构的。它关注于如何解决业务问题。我认为可能仍然有太多的注意力集中在技术上。我认为我们仍然需要纠正这一点。没有多少人还在读埃里克·埃文斯的蓝皮书。虽然Data Mesh现在显然又重新流行起来，但它的受欢迎程度似乎在下降。我认为领域驱动的设计、业务能力等仍然是微服务领域的核心。

理查森：技术将继续发展。我觉得这不是微服务的核心。这是一个笑话，但也许XML将取代YAML卷土重来。我只是想说。

刘易斯：而不是在YAML或JSON中隧道XML。

Gamanji：我们将在这里用YAML替换所有东西。实际上有一个项目，它允许您使用Excel电子表格管理应用程序。如果需要，情况可能会变得更糟。

理查森：一切都是YAML。真有趣。实际上，我希望Lisp是一种配置语言，我觉得这是一种更好的方法。我觉得这个问题有两个层次。第一，我完全同意詹姆斯关于编纂设计最佳实践的观点。我认为领域驱动设计和Eric Evans的蓝皮书是关键，以及相关的东西。另一部分是关于整体与微服务的争论。首先，我们应该停止使用Twitter讨论架构。这是一个可怕的格式。所有这些辩论，如果你在推特上说，单体是好的。参与程度超出了预期。我希望我们都能就monolith架构适用于何处以及微服务架构适用于何处达成一致，因为很明显，它们都适用于何处，我们只需要确定何时适用。我希望这场辩论能得出一些结论。

刘易斯：对我来说，技术是一回事。这正在演变。发生了巨大的爆炸。我做了一次演讲，回顾了微服务最初出现的地方，以及它之前的内容和之后的内容。在监控、日志记录和容器编排方面，您会遇到这种巨大的爆炸。真是太棒了。我相信，这种情况会继续下去，因为这会让很多人赚很多钱。我认为我们还没有破解更多关于领域的东西，更多关于业务架构的东西。正如克里斯所说，边界是什么。在开始编写代码方面做得很出色，很多是模式，其他人也在做类似的工作。对我来说，这是一条至今仍未落地的信息。是关于生意的。这是关于团队结构的。它关注于如何解决业务问题。我认为可能仍然有太多的注意力集中在技术上。我认为我们仍然需要纠正这一点。没有多少人还在读埃里克·埃文斯的蓝皮书。虽然Data Mesh现在显然又重新流行起来，但它的受欢迎程度似乎在下降。我认为领域驱动的设计、业务能力等仍然是微服务领域的核心。

理查森：技术将继续发展。我觉得这不是微服务的核心。这是一个笑话，但也许XML将取代YAML卷土重来。我只是想说。

刘易斯：而不是在YAML或JSON中隧道XML。

Gamanji：我们将在这里用YAML替换所有东西。实际上有一个项目，它允许您使用Excel电子表格管理应用程序。如果需要，情况可能会变得更糟。

理查森：一切都是亚马尔。真有趣。实际上，我希望Lisp是一种配置语言，我觉得这是一种更好的方法。我觉得这个问题有两个层次。第一，我完全同意詹姆斯关于编纂设计最佳实践的观点。我认为领域驱动设计和Eric Evans的蓝皮书是关键，以及相关的东西。另一部分是关于整体与微服务的争论。首先，我们应该停止使用Twitter讨论架构。这是一个可怕的格式。所有这些辩论，如果你在推特上说，单体是好的。参与程度超出了预期。我希望我们都能就monolith架构适用于何处以及微服务架构适用于何处达成一致，因为很明显，它们都适用于何处，我们只需要确定何时适用。我希望这场辩论能得出一些结论。

刘易斯：作为对这一点的提醒，每个人。我的一个同事Neal Ford显然在建筑领域非常有名，他写了很多关于它的东西。我想他们有一本书，他和马克，这是另一本即将出版的书。我想这叫做“建筑：硬的部分”，克里斯，他们已经谈论了很多。他们有一个非常好的扰流板，因为这是他们的孩子。他们有一个非常好的模型，围绕如何考虑服务的粒度或应用程序的粒度。注意那件事。

Gamanji：这是关于确定要部署的产品的最佳架构。同时，我想提醒大家，这也是关于迭代的。目前对你有用的东西可能在几年内对你不起作用。尝试为将来的问题构建，这将帮助您拥有可维护的代码库。

原文：https://www.infoq.com/presentations/panel-microservices-architecture/

本文http://jiagoushi.pro/node/1534