皇上,还记得我吗?我就是1999年那个Linux伊甸园啊-----24小时滚动更新开源资讯,全年无休!

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

作者 Manuel Pais,译者 张健欣

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

转自 http://www.infoq.com/cn/news/2017/12/serverless-challenges-hybrid-env

分享到:更多 ()

评论 抢沙发