【.com快译】Gartner研究总监RajBala表示，serverless产品最好的地方之一就是你可以“以前所未有的方式混合搭配编程语言和框架”。作为服务（无服务器）平台，您可以编写调用Python库的Java应用程序。这个真的很酷。但这也可能意味着意大利面条代码（即非结构化、难以维护的代码）的新时代。告别单体代码并不意味着它不会被“影响部署、通信、监控等的分布式系统问题”所取代。与更传统的软件开发一样，开发易于维护的微服务需要一种慎重且深思熟虑的方法。传播对微服务的热爱Bala指出，无服务器和“单一用途微服务”的主要好处之一是“您可以使用正确的工具来完成正确的工作，而不是被锁定在一种语言、一种框架，甚至一个数据库。”这极大地解放了开发人员，因为他们现在可以编写与临时无服务器功能相关的微服务，而不是面临尖峰工作负载和潜在低利用率的单体应用程序。当系统空闲时，它会免费关闭。每个人都是赢家。这也使得代码更容易维护。在整体应用程序的情况下，更新代码可能是一种负担，因为很难涵盖所有依赖项。正如OphirGross指出的那样，“到处检查意大利面条代码以查看正在使用哪个版本的接口，以及以确保执行正确的代码。这些代码通常是杂乱无章的，因为代码更改会影响在开发阶段难以预测的方面的功能，通常会导致维护工作量增加。”相比之下，使用基于微服务的方法，微服务中的代码仅限于业务的一个功能，因此更容易理解。团队可以使用他们最喜欢的实施技术和框架，并且彼此独立运作。然而，微服务并非没有自己的风险。具有讽刺意味的是，其中一个风险可能恰恰是开发人员积极拥抱微服务以逃避的意大利面条代码。分布式意大利面条代码除了其他复杂问题（更复杂的调试、逐渐更改API的困难、确保服务使用的API是最新的等），微服务的一个问题是开发人员可能以类似的方式使用它们给他们正在处理的那些构建系统的整体应用程序方法。人们通常没有意识到微服务实际上需要独立。例如，您经常看到创建了各种服务，但共享一个数据库。另一个问题是人们正在按照他们过去在单体架构中使用的方式进行编程，这使得服务之间（通过网络）的同步调用链太长。也没有注意各种服务相互使用可能导致的意大利面条结构。设计微服务的关键是正确地“定义它们的边界以及它们之间的关系。松散耦合的服务在一个地方包含相关的行为，而对它们所使用的系统的其余部分知之甚少。”松耦合很关键。您希望您的服务与有限数量的端点异步通信，并且没有共享数据库。当然，这并不排除“SpaghettiCode2.0”的可能性。强大和方便会导致开发人员针对无服务器功能创建各种API调用，事情很快就会变得一团糟。但是，确保服务松散耦合会有所帮助。原标题：Howtoavoidturnmicroservicesintodistributedspaghetticode，作者：MattAsay
