微服务2.0
在编写分布式应用程序时,传统智慧认为应将应用程序拆分成独立服务,以便独立部署。这种基于微服务的架构方法充满了良好的意愿,但却常常适得其反,带来挑战,抵消架构本身试图实现的好处。从根本上说,这是因为微服务混淆了逻辑边界(代码的编写方式)和物理边界(代码的部署方式)。在本文中,我们提出了一种不同的编程方法,该方法将两者解耦,以解决这些挑战。通过我们的方法,开发人员将应用程序编写为逻辑单体应用,将应用程序的分布式决策和运行工作外包给自动化运行时,并以原子方式部署应用程序。我们的原型实现已相比现状将应用程序的延迟降低了15倍,成本降低了9倍。
关键词:云计算,客户机-服务器架构
- 介绍 近年来,云计算获得了前所未有的增长。编写和部署可以扩展到数百万用户的分布式应用从未如此简单,很大程度上要归功于诸如Kubernetes[25]、消息解决方案(如[7,18,31, 33,40,60])和数据格式(如[5,6,23,30])等框架。在使用这些技术时的通用方法是,手动将应用程序拆分为独立的微服务,以便独立部署。
通过对各种基础设施团队的内部调查,我们发现开发人员将他们的应用程序拆分为多个二进制文件通常是出于以下原因:(1)它提高了性能。独立服务可以独立扩展,从而导致更好的资源利用率。(2)它提高了容错性。一个微服务的崩溃不会导致其他微服务的崩溃,从而限制bug的破坏半径。(3)它改善了抽象界限。微服务需要清晰明确的API,代码交织的可能性被严重最小化。(4)它支持灵活的部署。不同的二进制文件可以以不同的速率发布,这导致了更敏捷的代码升级。
然而,将应用程序拆分为独立部署的微服务也并非没有挑战,其中一些直接与上述好处相矛盾。
- C1:它损害性能。序列化数据和通过网络发送数据的开销正日益成为瓶颈[72]。当开发者过度拆分他们的应用程序时,这些开销会积累[55]。
- C2:它损害正确性。跟踪每个部署版本的每个微服务之间的相互作用极其困难。在对8个广泛使用系统的100多起灾难性故障的研究中发现,三分之二的故障是由系统的多个版本之间的相互作用引起的[78]。
- C3:它难以管理。开发人员不再只需要构建、测试和部署一个二进制文件,而是要管理n个不同的二