企业应用程序通常演变成庞大而复杂的单块体系结构，维护起来往往非常困难。这使得采用一种微型服务架构对于大多数想要经历数字转换的现代组织来说非常有吸引力。但是，和大多数事情一样，这更容易说和做–不仅仅是因为与技术有关的挑战，还因为人们对变化的反应方式，以及他们对微型服务应该是什么的先入为主的观念。
在这一集的鸡尾酒中，我们与一位行业专家讨论了多年来出现的微服务反模式，如何避免所谓的反模式，为什么单体和微服务都会成为错误，以及我们如何能做到。勒死巨石。
成绩单
凯文·蒙塔尔博：和往常一样，今天加入我们的是Toro Cloud的首席执行官和创始人。戴维·布朗。嗨，大卫！悉尼怎么样？
大卫·布朗：你好凯文！今天又潮湿又多云。
知识管理：好吧。我们今天的嘉宾是一位经验丰富的软件架构师和企业家，他为组织提供成功使用微服务架构的咨询和培训。
他是Microservices.io的幕后推手，它概述了一种模式语言，帮助用户判断微服务是否适合他们的组织。他也是MicroServicesPatterns和POJO in Action的作者，这两本书都是由Manning出版的，Java冠军以及一位JavaOne摇滚明星的演讲者，并定期在世界各地关于软件开发的会议上发言。
今天，他和我们一起参加了一轮鸡尾酒。 克里斯·理查森欢迎来到节目！
克里斯·理查森：谢谢!它很高兴来到这里。可悲的是，我不知道我真的没有鸡尾酒。它这只是一杯薄荷茶。
知识管理：嗯。没问题。我有咖啡。它在菲律宾喝鸡尾酒也太早了。好吧，那就让我们先谈谈你的创业，重要的IO。你能向我们解释一下与微服务相关的挑战吗？
CR：嗯。因此，如果您考虑什么是微服务体系结构，它这是一种架构风格，它将应用程序构造为一组松散耦合的服务。这听起来非常简单，但其直接后果是服务不应该共享数据库。它们不应该共享数据库表，而且在理想情况下，它们也不应该共享数据库服务器，因为这同时引入了设计时和运行时耦合。以一个非常简单的用例为例，比如创建一个订单，您知道您在Order服务中创建了一个订单。但是同时，为了确保订单能够被创建，你必须在客户服务中保留信用，并且说，潜在地，库存服务中的库存，对吗？所以你I我有一个跨多个服务的请求。
你可以的不要只使用常规事务。你可以的不要使用分布式事务。你可以的不要使用两阶段提交。因此，您必须使用一种称为Saga模式的模式。那里还有另外几个。基本上，您有这些分布式数据模式，而且Evuate是一个开放源代码的框架，它使您能够解决这些问题。它为您提供了这些模式的实现或允许您以如下方式使用该模式的构建块：It适合您的应用程序。
DB：2018年，你与曼宁一起出版了“MicroServicesPatterns”一书。它Its因是一本关于模式和建筑的必读书而受到赞扬。几年过去了。有什么变化吗？那本书你有什么要更新的吗？还是我们仍然在很大程度上遵循您在那里概述的相同的体系结构原则？
CR：什么有趣的是，如果你真的想到这本书，它大概是在两年的时间里写出来的，我想，就像2016年末一直到2018年年中。我想是什么值得注意的是我真的认为一般情况下还是很有效的，对吧？它It我们仍然围绕着关键的模式。我觉得在那里在书中有40多个图案，对吗？你知道，他们还是很适用的。当然，你可以说，自从写了这本书，甚至在写这本书的时候，我做了大量的咨询和培训，这让我深入了解了组织是如何采用微服务并使用它们的。当然，有些技术已经成熟了。你可以说，也许在一开始，库伯内特斯并没有那么成熟。当然，现在是这样，以此类推。所以我认为它的核心是非常非常稳定的。
现在有一天，我能写第二版吗？我想我可以。所以，你知道，我想到了几件事。例如，在我的书的第二章中，我描述了定义微服务体系结构的过程。你知道，根据我在过去两年的经验，我会大大扩展这一章。我是说，在那里这实际上是一种风险，它本身可能是一整本书。把它写进书里可能是个挑战。我我当然学到了很多关于组织是如何采用或更具体地说是错误地采用了微服务架构的。因此，我可以想象在那里添加一个关于采用微服务的反模式的章节。
DB：让我们更多地讨论反模式。你提到你I我们广泛地讨论了这些问题，因此我们经常讨论实现微服务所需的组织变革。我和其他客人一起做了这些播客。我们经常谈论这是一个组织上的挑战，而不仅仅是技术上的挑战。但是你我经历了很多反模式，而我I‘我想谈谈其中一些技术细节。在我们之前，你在2018年出版了你的书。最近，詹姆斯·刘易斯(JamesLewis)在2014年撰写了微型服务的定义。那份报纸对你有多大影响？
CR：嗯，是的。你知道吗有趣的是，我对这种建筑风格很感兴趣。就像，你知道，在2010年的时候，把原本是巨大的一体机分解成多个服务，对吗？我读过这本书，可伸缩性的艺术。在这本书中，他们有一个尺度立方体，这是一个三维的缩放模型。其中一个维度是Y轴，它是功能分解。这真的引起了我的共鸣，因为在那之前，我刚刚建立了一系列的单块应用程序，而在最后一个应用程序中，实际上是最初的云创建公司(CloudFoundry)。那是一块巨石，最初的云铸造厂。那实际上是一块巨石。尽管它是由一个很小的团队建造的，也就是两个人，但它实际上是相当精细的。相当不错。它是您的标准类型的企业应用程序。所有这些不同的功能都打包到一个JavaWAR文件中。如果当时我们用微服务架构来建造它，我们就能解决一大堆问题。真的，尺度立方体模型和函数分解真的引起了我的共鸣。但我没有我不知道它的名字。我在2012年做了一个关于这个的演讲，就像分解应用程序一样，我不知道不知道，可测试性和可伸缩性什么的。这是一种能力，另一种能力，我说过了。好吧，也许我们可以称之为模块化-多字形建筑，但那不是不完全是从舌头上滚下来的。
所以很有趣。对我来说有点新鲜。但是，当然，亚马逊早在2002年就采用了这种架构。易趣，早在2008年就采用了这种架构，但是我真的不是这样的名字分布式系统有点无聊。所以，你知道，那篇文章推广了微服务这个术语，尽管出于我可以解释的原因，它实际上是一个非常误导的术语，这是整个社会都可以采用的术语。整个行业也可以采用，产生了很大的动力，对吧？包括以前洗过云的供应商，他们的产品现在试图声称它们是微服务–也是相关的。但是，你知道，只要有一个每个人都能理解的词，就像一个伟大的统一者。
DB：有意思的。您之前说过，为了迁移到微服务，您必须学习如何扼杀Monolith。你能给我们解释一下吗？
CR：有趣的是这是个有点暴力的词。它实际上可以追溯到马丁·福勒(MartinFowler)在2006年提出的一项应用现代化战略，我相信，它被称为Strangler应用程序。自那以后，他将其修改为Strangler无花果图案。所以我想有一天他要去雨林散步，我想是在昆士兰，对吧？他们有雨林吗？
DB：在北昆士兰。
CR：嗯。所以他受到了启发。他偶然发现了一种奇怪的无花果，这是一种植物，它开始在树的树冠上生长，然后实际上生长到地面，根部长得很大，长得太大了，你可以说它遮住了树的阴影，这实际上会导致这棵树的死亡。
因此，这就是他受到启发的地方，他想通过这种方式实现应用的现代化。因此，与其进行大爆炸重写，这是非常耗时和风险极大的，实际上您实际上是在传统应用程序周围逐步构建了一个奇怪的常规应用程序。某种意义上的迁移功能，你知道吗？非常直观。因此，遗留应用程序萎缩，Strangler应用程序继续增长。这就是他的通用应用现代化模式。而那是如何迁移到微服务体系结构的。因此，您逐渐将功能一次从单个模块迁移到此Strangler应用程序或Strangler图应用程序中，以便这是增量迭代过程。是的，我们可以花很多年的时间，但关键是你要专注于你的应用程序中那些能给你带来最大投资回报的领域。比如说应用程序中的四分之一的业务给了你竞争优势，你的应用程序的那些部分不断变化。
DB：我想最简单的一种可能也是最窄的范围。所以你很容易就赢了然后说，我们我现在把我们的一小块巨石移植到一个微型服务中，他们I我学到了与此相关的知识。
CR：嗯。你也许想练习一下。你可能想练习一些简单的部分，但你知道得很快。您应该关注应用程序中那些具有以下模块的部分：不断发展。你把它变成一个服务，这样你就可以快速地开发它，或者可能在那里。这是一个模块如果导致可伸缩性或可靠性问题，则需要将其迁移到服务中，以便能够独立地扩展它。
DB：有趣的是，几个月前，你回复了一条推文，说微型服务和单寡头都可能是错误的。这是怎么回事？你这么说是什么意思？
CR：如今，如果你想在推特上获得更高的参与度，你就应该在推特上发帖。微服务吸或巨石是我们要走的路。
DB：复苏是另一回事。有很多人说巨石仍然有它的位置。
CR：嗯，是的。我是说，你知道，我认为在很大程度上，对吧？我是说，什么正在发生的是我们我们正在追随高德纳的炒作曲线，对吗？在哪里，你知道，好像，每一种技术都会经历这样的过程，对吗？所以，它被炒作了，你知道，微型服务并不是万能的，你达到了膨胀的期望的顶峰。然后，当然，你意识到这是不恰当的，人们会感到沮丧。你知道，他们建造的分布式单体比真正的巨石更糟糕，然后他们就可以在会议上发表演讲。这对我们的生意来说有点糟透了。然后，你知道那是幻灭的低谷。对吗？所以这是在反弹阶段。所以就这样在某种程度上，它这是可以理解的。
但是我的方法一直是，你知道，这就是为什么我创建了Microservices.io并创建了语言模式，你知道，单块架构是一种模式。你知道，它以一种特殊的方式解决了这个问题，它有一些好处和缺点。微服务架构是另一种有优点和缺点的解决方案，对吗？它们都不是普遍适用的，也不是普遍错误的。作为一名架构师，您的工作是选择最适合特定应用程序的体系结构，以适应特定的上下文。对吗？所以我才开始这条路，对吧？我没有不要创建一个Microservices宣言，因为我认为除了敏捷宣言之外，这些实际上都是垃圾，因为我认为敏捷通常是好的。但是，你知道，很多这样的宣言，他们不是工程文件对吧？因为，您知道正确的解决方案确实取决于特定的上下文。
DB：好吧，我I我想在这里多谈一些工程原理。所以你会讨论微服务的反模式，以及各种有趣的短语，比如魔法，皮克西，尘埃等等。那么你能解释一下微服务的一些反模式吗？
CR：嗯。这些都是我在与不同的组织协商时观察到的一些模式。你知道，有一次，你可以上飞机，你可以飞到一些地方，面对面地开会。
DB：听起来糟透了。
CR：你知道你得穿上裤子。
DB：真的？
CR：嗯。不管怎么说，显然是人们干的，对吧？所以你知道，我想我一年能飞16万英里之类的。这有点疯狂，但就像访问所有这些组织，帮助他们采用微型服务一样。和一些客户一起，我看到了这种反模式的收养。你提到了魔法精灵尘对吧？而那有点相信微型服务就是这种神奇的Pixie尘埃。你只要把它撒在你的开发组织上，它就能解决你所有的交付问题，对吗？在现实中，如果您在开发过程和组织结构上有问题，那么将微服务投入到组合中就会赢。不能解决这些问题很可能会让他们更糟。所以这是一种常见的模式。而且，你知道，这可以追溯到早期关于微型服务的炒作，把它们看作是你应该经常使用的神奇事物，对吗？
然后，你知道，另一种模式，非常有趣，就像，衡量成功的程度取决于你拥有的微服务的数量。我们拥有的越多，我们就越成功。会是对的吗？特别是，有一个客户，CIO刚刚宣布我们我们要做微型服务。而它这是一种自上而下的分层组织。我还遇到了开发商。就像，你为什么要做微型服务？我的经理让我这么做的。对吗？这几乎就像奖金取决于他们创造了多少服务。但你知道太可怕了。
DB：红旗定律是什么？
CR：然后是红旗定律。所以当时的想法是，你知道，在19世纪初，当汽车问世的时候，一些司法管辖区–至少我不知道–我不认为这是一个虚构的故事-一些司法管辖区要求行人走在车前挥舞着红旗。所以这辆车可以比步行的行人跑得更快，但是他们被减速了。所以这个模式的想法是我采用了微服务，但你I我把你现有的组织结构和现有的过程保持在适当的位置，这样你就可以没有适当的好处，对吗？与我一起工作的一个客户端一样，您只能部署到生产中，比如在这个月的第三个星期六午夜。对吗？这是一条很好的规则，但您希望采用一种微服务体系结构，它允许您每天多次安全地部署到生产中。但是你你知道，我不会让人们一天多次投入生产。我是说，它这有点让人想起这个挥舞红旗的行人，对吧？
DB：嗯。我的意思是，目标之一显然是成为一个更敏捷的组织，拥有更频繁的部署和变化。
CR：是啊，那是个大司机，对吧？科维德就是个很好的例子对吧？在世界上，企业经营的市场状况是非常不稳定、不确定、复杂和模棱两可的。你不知道竞争威胁将从何而来。显然，现在我们必须应对一场全球性的大流行，它直接影响了许多组织的IT，对吗？因此，这意味着它需要灵活。他们需要快速、频繁、可靠和可持续地交付软件。
您是如何做到这一点的：DevOps、连续交付、连续部署、将组织结构作为松散耦合的团队网络的组合，然后这里的第三个元素是您的体系结构，对吗？所以，如果你想到DevOps这一切都是为了非常迅速地传递一小股变化。转变为生产的一连串变化。
所以，这需要一个架构是可测试和可部署的，对吗？你想到的是组织结构，你想的是康威在这里，为了有一个松散耦合的组织，实际上还必须有一个松散耦合的体系结构。所以你需要一个模块化的，松散耦合的架构。如果考虑到这些特性，它必须是可部署的和可测试的，因为这是DevOps需要的。它必须是松散耦合和模块化。那这是组织结构所需要的，对吗？作为一名建筑师如果你在这样一个环境中，您确实需要快速、频繁、可靠地交付软件，您需要确保您的体系结构具有这些特性。这就是我所说的成功三角。
有时候，如果你I但是，随着应用程序的增长–就像长寿命的应用程序通常所做的那样–而且，如果您如果你是超级成功的话，你会得到一堆风投资金，在你知道之前，你我有几百个或更多的开发人员，对吗？这个庞大的团队正在将您推向使用微服务体系结构的方向，而不是让许多开发人员都做出贡献和相互冲突，试图交付这个大型代码库，您可以将其分解为一个架构，每个团队都有自己的服务。可能会成功得多。
DB：你看到的动力是由遗留系统的迁移还是在新绿地的发展？
CR：大多数人我我见过这么多年了，它就像企业已经编写了关键业务应用程序，对吗？大多数场景都是将遗留的Monolith迁移到微服务体系结构中。即使是较新的公司，比如刚刚成立几年的初创公司，也是从一个独角兽开始的，顺便说一句，这通常是一种很好的方法。因为如果你这是一家小公司，你不知道我没有一个庞大的代码库，一个庞大的团队。所以，你不能但我认为，特别是风投资助的初创企业，他们发现他们实际上得到了一个很大的应用，很大的一块巨石在他们的手上。他们需要将其分解，并将其迁移到一个微服务体系结构中。
DB：明白了。有意思的。那么，如果有什么技术变化呢？就像，你知道，我们我看过像GRPC这样的协议。是否有任何其他类型的技术正在影响微型服务的采用？
CR：我发现有趣的是–这实际上是另一种反模式–你知道，组织经常关注它的技术方面。几年前我和一个客户一起工作，在他们实施第一项服务之前，这个工程部副总裁要去，那么，我们是不是应该花六位数在某个漂亮的PaaS平台上呢？
这取决于PaaS供应商，并确保您喜欢它。但你知道吗？我只是说，等一下怎么样？等待直到你我实际上部署了一些服务，并对它们进行了操作，并真正理解了您所遇到的问题。在做出这么大的购买决定之前，我们还会面对吗？因为如果你你是这样做的吗？当你的经验最少，知识最少的时候，你就会做出决定，对吗？
但这是一种普通的东西。它有点像技术，技术，技术，然而，在现实中，你必须面对的最关键的问题和决定就在你身边，我的服务是什么？和每项服务的职责是什么？, 每个服务所提供的API是什么，这些服务是如何协作的？对吗？
你知道，这种决策实际上是非常抽象的，而且相当独立于您所使用的底层技术。正在使用。事实上，技术的唯一方面关键是，您主要应该拥有一个松散耦合的异步体系结构，而不是您的服务使用同步协议(如REST和GRPC的同步方面)进行通信的方式。
DB：我明白。而你我在Chrisrichardson.net上建立了一些惊人的资源。告诉我们人们可以在你的网站上找到什么样的东西？
CR：是的，我的内容被Microservices.io和Chrisrichardson.net分割开来。所以Microservices.io主要是模式语言。那里还有一些其他的东西，指向演示文稿、代码示例等的链接。然后在Chrisrichardson.net上It我只是在我脑海中的任何话题上发表了各种各样的博客文章。我不知道我的博客还不够。我脑子里塞得太多了。
