无服务器架构在混合环境下的挑战-InfoQ

抖音技术能力大揭密！钜惠大礼、深度体验，尽在火山引擎增长沙龙，就等你来！立即报名>> 了解详情 



 写点什么

Sam Newman 是一位独立咨询顾问，也是《 Building Microservices 》这本书的作者。他在伦敦举行的Velocity 大会上发表演讲，讨论了关于在一些同时依赖无服务器架构和传统基础设施的混合系统中所面临的挑战。尤其是，Newman 重点讨论了无服务器架构如何改变了我们关于系统弹性的概念，以及两个体系同时存在于一个高负荷系统内会发生怎样的冲突。

系统弹性在传统服务系统中依赖于状态来控制（例如，在任何时间点用数据库连接池，来及时调节和控制访问数据库的请求数量）。在这种系统中，系统稳定性通过控制输入负载并把这些负载均衡到多个系统实例中来维持。但是，在短暂的函数（lambdas）中没有地方来存储这些控制状态，因此在函数随着负载自动扩展与后端数据库扩展之间需要一个平衡机制。

自动扩展的云数据库，例如亚马逊的DynamoDB 或者谷歌的Bigtable ，很适合无服务器架构。但是Newman 指出，大多数系统依赖传统数据库，因此简单地在一个遗留的系统中嫁接无服务器函数可能会导致严重的后果。Newman 强调，即便是作为无服务器架构典范之一的 Bustle 也面临过许多前所未有的挑战。尽管他们特意给任意一个 Redis 节点设置了一个 1000 lambda 连接数的限制（可以处理 10 倍那个数量的连接），但是他们仍然发现一些失效的节点，因为据传闻说，lambda 函数似乎在连接停止后也会保持连接存活长达 3 分钟。Bustle 的工程师不得不深入研究 Redis 内部工作机制来修复这个问题（强制这些僵尸连接更快地超时）。Newman 说，这也突出了无服务器架构系统与非无服务器架构系统在处理负载和系统弹性的方式上的不协调。

Newman 提到的另一个挑战是，通常被用在微服务中来处理失败的下游服务，能够有效降低负载从而让整个系统更具弹性的断路器（circuit breakers），是依赖于维护跨多个请求的状态来实现的。例如，一旦下游服务恢复稳定，断路器就能够自我关闭。

Newman 讲到，服务网格（service meshes），例如 Istio 或者 Linkerd ，也许能够帮助解决这些问题。它们可以作为持久化的状态代理，而这些状态能够协调微服务函数间的负载。

最后，从安全角度来看，函数是运行在容器中的，因此很容易受到攻击，因为一个容器可以侵入到另一个运行在同一台主机上的容器。但是，如果函数运行所在的容器存活的时间很短，这种攻击就会变得很困难，因为不能在函数结束后进行攻击。诸如 Guy Podjarny 等安全专家警告说，无论如何，无服务器架构都将安全隐患转移到了应用层级别，并且如果没有正确的安全措施，一长串的函数链调用很可能会受到攻击。

Newman 也提到了许多人在选择一家 FaaS（Function-as-a-Service）供应商时所关心的问题，而这些问题也涵盖在最新的InfoQ eMag 中。将讨论内容从如何锁定一家供应商，转变为理解（以及接受）每个FaaS 实现在提高运行速度（负载越少速度越快）和迁移成本（跨FaaS 供应商的工具集越相似，成本就越少）之间的权衡，是解决这个问题的关键。

查看英文原文： Serverless Challenges in Hybrid Environments

感谢罗远航对本文的审校。

给InfoQ 中文站投稿或者参与内容翻译工作，请邮件至 editors@cn.infoq.com 。也欢迎大家通过新浪微博（ @InfoQ ， @丁晓昀），微信（微信号： InfoQChina ）关注我们。