软件体系结构和微服务的基本原理[Podcast]

多年来出现了许多技术、实践和体系结构模式–其中之一就是微服务体系结构，我们将在这一集的鸡尾酒中深入研究它。

今天加入我们的是流行的“软件体系结构的基础”一书的作者之一，我们讨论了微服务是进化的还是革命性的，这是试图实现该体系结构的主要障碍，并发现为什么在软件体系结构方面真的没有任何“最佳实践”。

成绩单

凯文·蒙塔博：好的。今天从澳大利亚远道而来的还有ToroCloud的首席执行官兼创始人大卫·布朗(DavidBrown)。你好吗大卫？

大卫·布朗：很好，谢谢凯文。

KM：我们今天的嘉宾是一位经验丰富、动手动手的软件架构师，他参与了各种技术中的微服务体系结构、面向服务的体系结构和分布式系统的架构设计和实现。他在应用程序集成和企业架构方面拥有丰富的经验和专业知识，所有这些都可以在DevelopertoArchitort.com上找到，这是他创建的一个免费网站，致力于帮助开发人员成为软件架构师。

除此之外，他还著有许多技术书籍和视频，包括“软件体系结构的基本原理”、“软件体系结构基础”视频系列，以及几本关于微服务的书籍和视频，以及企业消息传递。除了亲自咨询外，他还是一名会议演讲者和培训师，曾就各种与企业相关的技术主题向世界各地的数百个会议和用户组发表演讲。

现在，他可以自豪地在其中一次演讲中加入鸡尾酒编码。女士们先生们，马克·理查兹和我们一起喝一杯鸡尾酒。你好，马克，你好吗？

马克·理查兹：嗨，凯文！太棒了。我做得很好。非常感谢你让我上这个播客。真令人兴奋。我喜欢“鸡尾酒编码”这个名字。我假设这只是那些正在倾听的人，而不是那些说话的人。所以，我正在适当地喝茶，这将是我今天的鸡尾酒。

DB：大家都知道我们会在表演中带来一杯鸡尾酒。这取决于一天中的时间。

我个人正在喝咖啡，因为在菲律宾已经是早上7点了。好的。所以，非常感谢你，马克，和我们在一起。我们直接跳进去吧。

所以，去年12月，你在推特上提到了你备受争议的O‘Reilly主题演讲，你说过，我引用“软件体系结构中没有最佳实践。”我认为这是你与NealFord合著的“软件体系结构的基本原理”一书的主要主题。你能告诉我们更多关于你是怎么得出这个结论的吗？为什么在软件架构中没有最佳实践？

男孩，凯文，我是不是因为这句话而陷入了激烈的争论。事实上，这是在去年2月O‘Reilly的软件架构会议上的主题演讲中–大约一年前。那是2020年2月。我喜欢做两种形式的键盘笔记，一种是激励，另一种是煽动。而这个似乎两者兼备。是的，事实上，这句话非常大胆，我很高兴，凯文，你问这个问题是因为我想对它进行限定，因为它在发表声明后立即在很多社交媒体上引起了很大的争议。

它的关键，真的，来自软件架构的两条定律，尼尔·福特和我在我们的书“软件体系结构的基础”中发明了这两条定律，而我们发明的软件体系结构的第一条定律是，软件体系结构中的一切都是一种权衡。这是第一条法律。第二条定律，实际上与它无关，但我要提到的是，“为什么”比“如何”更重要。这是我们的一个顿悟，当你描述一个建筑的时候，最有趣的是为什么你做出了一个特定的选择。我能看到它是怎么工作的，但我不知道。我看不懂你的心思。但让我回到第一个问题，因为这是一个相当大胆的声明，是基于我们的第一条定律–顺便说一句，没有人反驳–软件体系结构中的每一件事都是一种权衡。我更进一步地说，“这推断出在软件架构中没有最佳实践。”

让我给你们举几个例子，这是从哪里来的，然后我可以给你们做一些限定。因为每当我们在建筑，结构架构中做任何事情时，你都不能说，“哦，你应该总是关注性能”，或者“哦，你应该总是把这些服务分开。”“只要你有一项服务能做三件事，就把它分成三件。”因为我们的软件体系结构的第一定律，你不能做这些陈述。我可能会花半个小时来研究每件事都是一种权衡的例子。这就是为什么我们总是说-这取决于每次我们得到一个问题，它取决于。然而，我确实想对此加以限定，因为我在社交媒体上和很多人进行了很多非常有建设性和有趣的谈话，也有关于这个问题的Zoom和电话。我可以说，在软件架构的结构方面，没有最佳实践，因为每个环境，每一种情况，都是不同的，你不能说，“哦，你应该一直这样做。”

然而，我同意软件体系结构的另一个方面，即体系结构，过程，实际上有一些最佳实践。始终协作，与涉众沟通。有个好办法。总是这么做。这里有一个很好的方法–总是分析权衡，这是一种元，因为它实际上证实了我们软件体系结构的第一个定律。所以我不得不软化一下语气，把重点放在结构方面，因为我同意，在创建架构的过程中确实存在最佳实践。但是，是的，这是一个非常有趣的基调。它真的搅动了锅，这就是我认为键盘应该做的。这就是让他们兴奋的原因。

DB：马克，你说它激起了人们的反应。主要的反对意见是什么？

Mr：主要的反对意见是，事实上，它是为了表达一种声明，即事实上在架构中存在最佳实践。问题是，大卫，当我发表这个声明时，我并没有真正涵盖软件体系结构的两个方面。当我们思考和尝试定义软件体系结构时，它真的很难定义。要真正理解和定义软件体系结构，最好的方法之一就是把它看作是两个不同的方面–体系结构，结构–这是更多的技术架构。当我们开始讨论衔接、耦合和连接，以及关于构造代码和服务的所有这些技术细节时，这就是结构方面。顺便说一句，我仍然坚持认为，在结构方面没有最佳做法。这总是取决于。

但是过程方面，你现在所指的，实际上是我试图定义软件体系结构的一种方式，令人惊讶的是，David，这些都是争论最终发生的地方。就像，“不，和利益相关者沟通怎么样？”，“合适的文档呢？”，“这个呢？”，我说，“哦，是的。”你知道，“和团队合作怎么样？”我说，“哇，是的，你是对的。”我说，“啊，我知道我哪里错了。”

DB：你想出了这个最初的概念。如何区分结构和过程？

结构是当我们开始应用技术方面来处理我们的代码，我们的源代码是如何组织的。它是一个部署为单个单元的大型单块应用程序，如分层或单块？

DB：我的想法是，当你想出这句话时，“没有最佳实践…”。，您是否区分过“与工艺设计相比，结构设计中没有最佳实践？”或者，这是你在搅乱了锅，把这场辩论搞得一干二净之后所作的区分吗？结果如何？

你知道吗，大卫，这就是我绝对喜欢的会议，也是我非常想念在会议现场演讲的原因，因为如果不这样做，你就得不到反馈。是的，事实上，我和尼尔福特都考虑了技术和软技能方面的问题。让我给您一个非常好的例子：架构决策记录的使用。我喜欢建筑决策记录。这是一种记录和记录体系结构的方法，但是记录“如何”，或者我很抱歉，记录“为什么”。但我不能说那是最好的做法。我真的很喜欢用它们。我发现它们非常有效，但是您，David，可能不会，您的环境可能不利于您可能需要的文档类型，而这种文档类型在架构决策记录中是缺乏的。那么，我怎么才能说和声称这是一个最佳做法呢？

所以我们分析了很多过程的方面，但是尼尔和我互相取食。我们真的没有从这些会议和发言中得到的大量实时反馈。所以我能说的很好的一点是，我完全没有，很抱歉我在那次演讲中发表了这个声明，因为它产生了很多健康的交流和例子，我们都从中学到了很多东西。这才是关键。我认为，大卫，这是我们做出这些声明的事实，尤其是如果它们煽动了某件事，或者它们有点有争议，那么它所提倡的就是对话。在我看来，这就是学习的来源。因此，我从那次会议上学到了一些东西，在那种大胆的表述中，我们没有考虑到建筑的所有过程方面。然而，关于没有最佳做法的说法是我对第一部法律的解释。所以，就像我说的那样，我有点超出了底线，我很高兴我做到了。

DB：是的，这很有趣，因为我们开发的最成功的内容之一是我们写了一篇文章，讨论我们为什么要关闭连接器。连接器在应用程序集成和直接API到API集成之间是死的，通过传递连接器是未来的发展方向。它引起了类似的反应，因为它几乎是一个观点，对吗？人们说，“好吧，连接器对我很有用。”你知道，“我已经用了好几年了，它们能增加价值”，等等，等等。

因此，这是非常有价值的，因为有了有效的观点，有效的讨论，让社会讨论了连接器的整个概念和价值，以及业界可能引领的领域，并引发了一场讨论。但是，如果这是一篇关于定义一个问题或者描述一个过程的文章，你知道，如果你在这个特定的领域做一些工作，它是很有趣的，而且它也很有用，但是它不一定得到你现在在内容营销中想要的那种吸引力。让我们继续讨论建筑本身。你写了很多关于微服务的文章。让我们进入那个空间。你认为它们是进化的还是革命性的？

先生：哦，哇。我认为微型服务是进化的还是革命性的？我不得不说，大卫，两者都是。我认为微型服务展示了这两者。让我解释一下为什么我要说两者。我认为微型服务是进化的。换句话说，将这种差异定义为，我们是否在大约6到7年前演变成了这种建筑风格？我相信我们做到了，这也是我非常喜欢微型服务的原因。我确实认为它是进化的。它最终会发生。让我解释一下，为什么在我看来有两件事，至少在我看来，有两件事是微观服务的催化剂。首先是连续部署的整个想法。我们有了持续的集成，这是很好的第一步，但是当DaveFarley和JezHumball出版这本书的时候，持续的部署是非常了不起的。

我的意思是，这最终给了我们如何有效部署软件的答案。如果我们都有一堆无法工作的大型单块应用程序呢？所以，这个实验，这个进化说，“好吧，如果我们把应用程序搞得有点分崩离析呢？”这起作用了。就像，“嘿，如果我们再把它们拆开呢？”这也起作用了。当我们开始进一步分解我们的应用程序时，我们发现能够完成这些有效的部署管道、持续部署和持续交付。在我看来，从进化的角度来看，这确实是第一个催化剂。我观察到的第二个问题是艾瑞克·埃文斯(EricEvans)，他的革命性领域驱动设计。我认为，这些概念确实形成了微观服务。我敢说，再一次，我喜欢这些大胆的声明：如果没有Eric Evans真正通过域驱动设计的概念的有限上下文，就不可能存在微服务。

所以我真的倾向于认为大卫，这两个人在某种程度上是微型服务的父母，这是进化的方面。但是微型服务–我已经做了六年多一点的微型服务，几乎把我的整个职业生涯都花在了过去六年的时间里–我也看到了微型服务的革命性方面。微型服务公司终于打败了我们。我们因必须注意数据而被打得不可开交。是的，是的。MicroServices是最早出现的体系结构风格，它要求我们将数据作为架构设计的一部分。现有的任何其他架构风格都没有这样的要求。

这是个好主意吗？哦，是的。这就是你如何得到一个有效的系统，但它是必要的吗？不，我们仍然可以有阻抗错配，这两个架构师和数据架构师阵营，他们以某种方式将可怜的开发人员结合在一起。嗯，微观服务在这方面是革命性的。所以这是第一个方面。它唤醒我们说，“嘿，数据在体系结构中很重要。”试着在没有数据的情况下构建一个有限度的上下文，但你不能。另一方面–革命性的–我认为这是一个主要的方面–实际上是这个数据片段，但也是微服务的另一个革命性方面–这是真正的协作桥梁。最后，最后，大卫，我们一直在努力合作，而不是相互交流，而是真正地合作，在一个有凝聚力的系统上共同工作，并开发这个凝聚力的系统。而微型服务需要这种合作。如果没有它，事情就会完全分崩离析。

这就是我真正感到兴奋的地方。作为架构师，我们必须与开发人员协作，否则就无法工作。作为架构师，我们必须与数据架构师和DBA协作，否则就无法工作。我们必须与行动部门合作。现在我们从来没有真正的，你知道，我们与他们交谈，沟通，但没有合作。这确实是这个革命性方面的第二个方面–对数据的亲密性的理解，以及它是如何与体系结构相联系的–这是关于协作的核心部分，也是真正构建它的核心部分。DevOps是个不错的主意。早在我在IBM工作的时候，我就开始尝试DevOps，这可以追溯到，哦，天哪，90年代末，2000年初。只是一个词而已。那是个想法。我们试验过它，但微型服务需要它。所以它真的是这些东西的催化剂，革命。

DB：如果这是一场革命，就会造成很大的破坏。那么，对一家公司来说，主要的障碍是什么？当他们实施微服务时，他们面临的挑战是什么？

先生：哇。大卫，多么伟大的类比啊，因为你在任何革命中都是正确的，有很多痛苦。任何革命都有很多附带的损害。有很多烦心事。哦天啊。到目前为止，经过六年的时间和使用微型服务的计算，我认为这周没有足够的时间来真正克服微型服务的所有挑战和障碍。但就你的观点而言，有一些真正的关键问题，大卫，我真的可以指出，对于任何听这个播客的人来说，这些都是值得警惕的故事。想到微型服务或者做这件事，要么是点头，要么是说，“哦，我没想过。”甚至考虑到微型服务的发展，“稍等一下”。实际上，第一个是，我通常看到的第一个障碍是关于服务粒度的。

一项服务应该有多大？这是非常非常困难的事情。当然，我们的支付服务，我们接受五种不同的付款类型的处理-是一种服务还是五种？我们应该通过短信、电子邮件甚至邮政信件通知客户吗？这应该是一种或三种服务吗？这些都是导致团队进行激烈辩论的原因，或者说，我想出一种更友好的方式来表达激烈的辩论。生动的对话，让我们这样说吧，大卫。

服务粒度很难。另一个则是数据的分崩离析。这也许是除了服务粒度之外，可能是最大的挑战，至少在我在客户站点的经验中，我一直在帮助和帮助，它实际上是处理数据和分解数据。分解数据是非常困难的。数据是相互关联的。我们有外键。我们有数据之间的关系。当我们开始形成有限制的上下文时，它听起来很容易，而且在纸上看起来很好。

所以，你真的试着去做。我说，“等等，我现在需要那些数据，但你是说我不能去查询那个表？”“不，你不能质疑那张桌子。”“那我怎么才能得到我的数据呢？”这确实是第二件。另一种–这很有趣，特别是当我们谈论无服务器，作为微服务的一部分–我称之为部署地狱。我们以前在C时代就有dll地狱。

当然，当Java出现的时候，我们也有了地狱。现在，在微型服务中，部署地狱，所有这些服务相互依赖，数百个。是的，我们有操作自动化来帮助我们解决这个问题，但是，孩子，我们把一项服务敲掉了，突然之间，我们甚至不知道通过工作流与它联系在一起的事情就开始中断了。所以，是的，部署，虽然在微服务中的比例很高，如果不正确的话，可能是你最可怕的噩梦。但丁的第九层地狱基本上是微服务做错了，然后，哦，天，就像我说的，我可以继续，你知道，管理工作流程。这在微观服务领域是一场巨大的斗争。服务依赖关系是微服务真正开始崩溃的地方。这些都是真正的主要障碍和挑战。幸运的是，所有这些都有解决办法。

DB：是的。我的意思是，您知道，用于部署的托管服务和诸如此类的东西使它变得更容易。并通过这些公共服务、托管服务来记录或补救，如果你是公共云提供商，那么这个过程就更容易了。但是这个，这个有趣的方面，数据和有界的上下文之间的相互关系，说起来容易做起来难，对吗？所以，无论你是在设计一个新的应用程序，还是像你所说的那样，打破一个单一的应用程序，都有很多关系。有时候，你知道，当我们自己构建微型服务时，我不想远程调用这些数据。会有性能问题，数据完整性问题，还有其他问题。所以让我们把它捆绑到服务中，你知道，好吧，好吧，我们又开始构建一个完整的应用程序了，现在他们总是推荐微服务本身的概念。这是一个真正的挑战。有简单的答案吗？

先生：没有。这就是问题所在，大卫，你的观察是绝对正确的。我不能告诉你，也不会告诉你我在过去六年中的客户和客户数量，这些客户实际上创造了一个巨大的、分布的、大的泥浆球，或者我的一些客户称之为“我们有一个分布式的单体”，我会后退一步说，“等等，让我猜猜。你在使用微服务。”他们说，“你怎么知道的？”所以，你知道，你这么说很有趣，大卫，因为所有这些新的流行词都在涌现，我的意思是，分布式单体是一个矛盾的词，但它确实描述了你在微服务中可能遇到的麻烦。解决这些障碍和问题是有办法的。很多大卫都是我最后学到的，这是经过战斗考验的。

它在战壕里说，“哇，这不是正确的举动。”这是所有的经验教训和错误的做法，并说，“这是不好的，是吗？”“不，我们现在就这样做吧。”我真的开始记录所有这些东西，这也是我发明了所有这些反模式和陷阱的地方，我在会议、培训等活动中传播了这些反模式和陷阱–它让我有机会分享我提到的每一个障碍的所有经验教训，以及克服这些障碍的技巧。

DB：你能分享一下你在微服务中发现的一些弱点吗？

先生：是啊。哦天啊。弱点。嗯，事实上，我们已经触及其中的一些仅仅在障碍本身。但你知道，在我看来，这其中有两个是最重要的。首先是性能，你可能会对这个答案感到惊讶。但事实上，我的经验是，大多数微服务实现实际上比原始的单块应用程序有更低的性能或更差的性能，或者，如果您是从一个绿地，则使用单一功能。

DB：没有多少人会期望这样的结果。

你说得对，大卫，当你开始的时候不是三四个服务，但一旦你真正开始认真地开发几十到数百，甚至上千的服务，这就是你的“难题”之一。原因有三，这不仅仅是一种观点。这是我六年来在实地看到的一个观察。有三个原因。一个是网络延迟。我们倾向于忘记，当我们调用另一个服务时，这必然是一个远程服务，我们正在通过网络，并且存在我们以前没有的网络延迟。第二个问题是安全延迟，因为如果我把我的单块应用程序炸掉，甚至从一个绿地开始，我们有70，80,200个服务，那么，当我开始调用其他服务时，我必然需要保护这些端点，因为服务是一个单独部署或单独部署的功能，是微服务中的一个单一用途函数。它是单独部署的。谁能接触到它？谁能访问包含所有PCI信息的钱包服务？

因此，当我开始跳过服务来满足请求时，我不仅有网络延迟，而且现在我可能不得不重新授权您处理每一个跳。至少我必须验证我要传递到报头的安全令牌。有趣的是，还有第三个隐藏在微服务中心的原因，那就是数据延迟。这就是数据延迟。假设我想检索所有客户信息。在Monolith中，这是跨越七个表的一个SQL连接。嗯。这就是我们所做的。那是相当快的，大约7到8毫秒。现在我需要连接和查询图表七个不同的微服务，但是每个微服务都有自己的数据和自己的查询。因此，我现在使用了在SQLJOIN中的数据库中非常有效的内容。

现在我要打七个数据库电话。现在，希望我可以并行地这样做，这有助于减少一些数据延迟。但是很多时候我做不到，我必须做一个工作流程。这意味着所有这三个都指向了这样一个事实：我可能在每个请求上添加500到1500毫秒。这就是为什么表现，再一次，听起来很奇怪，不是吗？就像，“等一下，不。让东西变小应该更快。”这就像，如果您从单个UI调用单个服务，很好，有多少应用程序会这样做呢？不多。虽然不多，但你知道，微观服务的另一个弱点是成本和复杂性，这两个大的C。它们很贵。我开了个玩笑，大卫，顺便说一句，“哦，你在使用微服务。我可以推断出一些关于你的环境的事情。”“哦，是的，那是什么？”“嗯，你有很多成本超支和高消耗。”就像，“你怎么知道的？”

DB：好吧，我不想把人们从微型服务中吓跑。就像你说的，这是一场革命，人们这么做是有原因的。那么，其中一些原因是什么呢？它们在哪里很合适？它在哪里工作？

所以，有那么多，很多很好的理由，为什么这是在炒作曲线。超高级别的可伸缩性。敏捷。对我来说，最接近和最珍贵的事情之一就是建筑的改变。为改变而设计。我在各种会议上，在各种演讲中一直在吹捧这一点，哦，天啊，大卫，关于敏捷体系结构，我已经有10到12年的时间了。这是在微型服务还没有出现之前。

而且很难。很难讨论如何使架构敏捷，因为架构确实会发生变化。微服务公司给了我们这个机会。敏捷的五星，敏捷被定义为快速响应变化的能力。让我们面对现实。为什么微型服务如此受欢迎？这是因为企业不得不在一毛钱的基础上做出改变。这是一些企业保持竞争力的唯一途径。他们必须迅速改变。企业正在学习如何快速改变业务流程，但随后它就冲击了IT，每件事都停滞了好几个月、几年，蟋蟀叽叽喳喳地叫着。因此，这是微服务给我们的第一件事就是敏捷，即快速响应改变日常部署的能力。大卫，这是很棒的东西。我可以在一个特定的微服务中做一个改变，一个小时内完成一个单一的功能，并且比我们的竞争对手更快地解决问题、修复错误和新的功能。

这就是微型服务的发光点。正确的容错水平是非常棒的。用户突然说：“哇，这些系统不会失败，是吗？”就像，“哦，是的，他们一直在失败，但你就是没注意到。”它在功能级别上是可伸缩性的。当我们谈到演化体系结构，即随着公司的发展而进化架构的能力时，这是任何架构风格中对体系结构进化方面的评价最高的。如果我需要开始改进架构来增加更多的功能，那么做我们公司正在做的不同的事情，采取不同的方向。大卫，这是一个放弃新的微服务或采用现有的所需的服务的问题。伙计，试着把石头变成石头。就像一艘800英尺的巨型驱逐舰。现在要花四英里才能使那艘船掉头。我们说的可不是一艘小小的快艇。因此，这些是一些主要的。

明白了。我是说，有很多令人信服的理由，对吧？正如您所说的，持续部署的敏捷和提供组织的敏捷几乎没有选择。从大型企业到小型企业，这是很有趣的，因为微服务有一些复杂性，因此，小企业也许没有很好的设备来部署它，但它正变得越来越普遍。很有趣。我很想知道你对这一切的看法，以及它作为一个服务的潜在功能如何适合于这一点，因为，你知道，作为一个服务的功能，而不是真正的有限制的上下文，也许还没有很好的定义。我想知道这会不会在未来造成混乱。你对微服务的发展有什么看法，服务的功能是如何适应这一切的？接下来是什么？

先生：这个，我对此很兴奋。我还没兴奋过，但这让我很兴奋。那它要去哪？简单地说，我会对此做一些扩展，但简单地说，公司加入了微型服务的行列，而A公司也在这样做，所以我们应该这样做。“我会做我们所有的事，无论是微型服务还是无服务器服务。”令人兴奋的是了解我们在哪里弯腰，以及我在整个行业中看到了什么。这些都是我工作的公司，我正在接受培训或参加会议的公司。我所看到的是微型服务的成熟程度开始上升，不仅仅是关于我们在这个播客中讨论的障碍，还包括什么时候使用它，什么时候不用它来真正拥有，我想我会说大卫，这是对微服务的一种尊重。理解它是复杂的，它不是一个灵丹妙药，也许我们不应该使用它。

这让我很兴奋，因为我看到学习发生在团队和公司获得并获得这些经验教训的过程中。所以，我所看到的微型服务的发展终于开始达到成熟的曲线，是的，这是一个很好的实验，一些公司仍然在做这个实验，不幸的是，我们学到了很多东西，我们学到了很多东西，在我看来，要小心谨慎。我们正在学习，而不是急于求成，立即接受微型服务，无论是个人经验，还是像我这样的其他人的经验，传播一些经验教训。它向后退了一步，采取了一种更加谨慎的方式来表达：“我们应该使用微服务吗？”另一个地方David，我真的看到微服务正在发展，更倾向于混合体系结构。我认为，我们在过去六年或七年中学到的另一件事是，坦率地说，并非应用程序的每一部分都必须是微服务。

我们可以组建混血儿。我们可以有我们的应用程序的一部分，包括微服务，体系结构和部分是微型单体，甚至是基于服务的架构。这种意识，我开始在我的客户的网站上看到，这让我很兴奋，因为这就像，“哦，我看到我一半的工作已经在这里完成了”，因为你几乎没有看到那些总是为你传福音的东西。所以，我想我会把它概括为一种谨慎的方法，理解混合体系结构，特别是当涉及到数据块时，David。这是不是所有的数据都可以分开的部分。这意味着很多时候我们不做微服务，而是一种基于服务的体系结构方法。

DB：你是从人们自己的经验中看到的。你说的是战斗伤疤。正如您所说，人们实际上正在成熟，并意识到他们可以采用这种混合方法，而且部署模型有不同的方法。

是的，没错。此外，大卫，工具肯定是成熟的。同样，我通常对这一步所做的也是传福音，给每一个聆听忠告的人。这些工具使微服务和框架变得更容易、更易于管理、更易于部署，甚至更易于创建，但细节却是最糟糕的。在很多框架和工具中，有很多隐藏的方面是从我们这里抽象出来的，而警示故事是真正理解，拥抱这些，但理解那些抽象。当我们谈到自动伸缩弹性的易用性时，我过去花了四个月的时间去建筑师那里，这是我在Kubernetes设置的一个开关。我是说，这有多容易？嗯，如果我使用内存中的数据缓存，或者通过复制缓存使用内存中的数据网格，而我有一个500 KB的缓存，我突然旋转了40个实例，猜猜会发生什么？我很快就没记忆了。所以，我的意思就是细节上的魔鬼。我很欣赏这些工具，并对微服务的框架和工具表示赞赏，使其对大多数公司来说都是可行的。但它仍然需要成熟的水平，以了解旋钮和刻度盘，以及什么是影响的自动缩放，例如。

戴：是的。你说过你喜欢会议。我猜你这几天不常开会了。那么，人们如何保持与你的联系，听到你的声音，并跟上今天你的想法是什么？

嗯，每个人都可以去的唯一地方，好东西是我的网站DevelopertoArchit.com，那是T-O，所以，想想，“我是一个开发人员，我想成为一名建筑师。”从开发人员到建筑师。这是一个充满资源的网站。大卫，我每隔一个星期一做一次名为“软件架构星期一”的活动，这是一个10分钟的免费视频。我通常将视频保存在软件体系结构的某些方面的10分钟内。这些都是免费的。你甚至不需要注册，你只要看着他们。实际上上个周末，我只出版了不到105本。所以有105到10分钟的视频是关于建筑的某些方面的。

另一件事是我的菜单项上的“即将到来的事件”页面。在那里你可以看到即将到来的事件。这些地方是我实际上在做的，仍然，公共培训和一些公共会议，仍然。我会告诉你，大卫，我真的，真的，真的很怀念亲身经历。它对我的打击很大。它开始给我沉重的打击，十月下旬，现在它对我的打击很大。我想念这些互动。我想念反馈。我怀念人们的表情和在这方面的合作。

我明白了。我是说，我不想错过这次旅行。我很高兴不是每两周上一次飞机，但是是的。没有什么比面对面的接触更重要的了。马克，很高兴你能上播客节目。非常感谢，有这么多的见解。我很荣幸。再次感谢你。

先生：好的。非常感谢大卫。还有凯文，他让我在鸡尾酒上编码，真的很兴奋。和你讨论这些想法真是太有趣了。这对每个人来说都是很重要的事情。我为你这么做而鼓掌。谢谢你邀请我。

绝对是我们的荣幸。

福州软件开发   福州APP开发