如何避免将微服务变成分布式意大利面条式代码？

【51CTO.com快译】Gartner研究主管Raj Bala说过，无服务器产品最出色的地方之一就是让你可以“前所未有地混合搭配前编程语言和框架。”这意味着，比如使用函数即服务(无服务器)平台，你就可以编写调用 Python 库的 Java 应用程序。

确实很酷。

但是这也可能意味着意大利面条式代码(即非结构化、难以维护的代码)迎来新时代。就因为你告别整体式代码，并不意味着不会换成“对部署、通信、监控等方面有影响的分布式系统问题”。与更传统的软件开发一样，开发易于维护的微服务需要一种慎重周到的方法。

传播微服务之爱

Bala指出，无服务器和“单一用途微服务”的主要好处之一是，“可以使用合适的 工具 来完成合适的工作，而不是局限于一种语言、一种框架甚至一种数据库。”这极大地解放了开发人员，因为现在他们可以编写与短暂的无服务器函数绑定的微服务，而不是编写面对尖峰式工作负载、利用率可能低下的整体式应用程序。系统处于空闲状态时，它会关闭，不花费任何费用。大家共赢。

这还可以使代码维护起来更简单。若是整体式应用程序，由于对所有依赖项很难做到面面俱到，更新代码可能是一大负担。正如Ophir Gross指出，“意大利面条式代码处处要检查，以查看所使用的接口版本，并确保执行正确的代码。由于代码更改影响开发阶段中很难预测的方面的功能，因此这种代码常常杂乱无章，通常导致维护工作量加大。”

相比之下，若是基于微服务的方法，微服务中的代码仅限于业务的一项功能，因此更易于理解。团队可以使用自己喜欢的实现技术和框架，彼此独立地运作。

然而，微服务不是没有自己的风险。具有讽刺意味的是，其中一个风险可能正是开发人员积极接受微服务以逃避的意大利面条式代码。

分布式意大利面条式代码

除了其他复杂因素外(调试更复杂、API逐渐变化带来的难题以及确保服务使用的API及时更新等)，微服务的一个问题是开发人员可能使用他们以类似于当初处理整体式应用程序的方式来构建系统。

人们常常不知道微服务其实需要独立。比如说，你常常看到创建各种各样的服务，但是共享一个数据库。另一个问题是，人们以过去在整体式架构中习惯的方式来编程，这使得服务之间(通过网络)之间的同步调用链变得太长。也没有注意彼此使用的各种服务可能引起的意大利面条式结构。

设计微服务的关键是正确“定义它们的边界以及它们如何联系。松散耦合的服务在一个地方含有相关行为，而对系统中与之协作的其余部分了解甚少。”松散耦合至关重要。你希望服务与数量有限的端点进行异步联系，并且没有共享数据库。

当然，这无法消除“意大利面条式代码2.0”的可能性。强大功能和便利性可能导致开发人员针对无服务器函数创建各种各样的API调用，局面可能很快变得一团糟。不过，确保服务的松散耦合有所帮助。

原文标题：How to avoid turning microservices into distributed spaghetti code，作者：Matt Asay

【51CTO译稿，合作站点转载请注明原文译者和出处为51CTO.com】

【责任编辑：庞桂玉 TEL：（010）68476606】