无服务器架构在混合环境下的挑战
极客时间编辑部
讲述：杜力大小：1.07M时长：02:21
在最近举行的伦敦 Velocity 大会上，《构建微服务》一书作者萨姆·纽曼（Sam Newman）发表演讲，讨论了一些同时依赖无服务器架构和传统基础设施的混合系统中所面临的挑战。
在纽曼看来，无服务器架构改变了人们关于系统弹性的概念。传统服务系统中，系统弹性依赖于状态来控制，例如，在任何时间点用数据库连接池来及时调节和控制访问数据库的请求数量。
在这种系统中，系统稳定性通过控制输入负载，并把这些负载均衡到多个系统实例中来维持。但是，在短暂的函数 lambdas 中没有地方来存储这些控制状态，因此在函数随着负载自动扩展与后端数据库扩展之间，需要一个平衡机制。
自动扩展的云数据库，例如亚马逊的 DynamoDB 或者谷歌的 Bigtable，就很适合无服务器架构。
但是纽曼指出，大多数系统依赖传统数据库，因此简单地在一个遗留的系统中嫁接无服务器函数可能会导致严重的后果。
随后纽曼举例道，即便是作为无服务器架构典范之一的 Bustle 也面临过许多前所未有的挑战。尽管他们特意给任意一个 Redis 节点设置了一个 1000 lambda 连接数的限制（可以处理 10 倍那个数量的连接），但是他们仍然发现一些失效的节点，因为据说，lambda 函数似乎在连接停止后也会保持连接存活长达 3 分钟。
对此，Bustle 的工程师不得不深入研究 Redis 内部工作机制来修复这个问题，以便能强制这些僵尸连接更快地超时。
纽曼表示，这也突出了无服务器架构系统与非无服务器架构系统在处理负载和系统弹性的方式上的不协调。
纽曼提到的另一个挑战是，通常被用在微服务中来处理失败的下游服务，能够有效降低负载从而让整个系统更具弹性的断路器（circuit breakers），是依赖于维护跨多个请求的状态来实现的。例如，一旦下游服务恢复稳定，断路器就能够自我关闭。
而服务网格（service meshes），例如 Istio 或者 Linkerd，也许能够帮助解决这些问题。它们可以作为持久化的状态代理，而这些状态能够协调微服务函数间的负载。
演讲中，纽曼也提到了许多人在选择一家 FaaS（Function-as-a-Service）供应商时所关心的问题，他表示，将讨论内容从如何锁定一家供应商，转变为理解以及接受每个 FaaS 实现在提高运行速度和迁移成本之间的权衡，是解决这个问题的关键。
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线笔记
复制
AI
- 深入了解
- 翻译
- 解释
- 总结
该免费文章来自《极客视点》，如需阅读全部文章，
请先领取课程
请先领取课程
免费领取
© 版权归极客邦科技所有，未经许可不得传播售卖。 页面已增加防盗追踪，如有侵权极客邦将依法追究其法律责任。
登录 后留言
精选留言
由作者筛选后的优质留言将会公开显示，欢迎踊跃留言。
收起评论