发帖    主题    评论    推荐    标签    作者    订阅    查搜    注册   登陆   关注
 
面向对象 设计模式 领域驱动设计 企业架构 框架 开发教程 微服务 CQRS 扩展性 并发编程 事件溯源 分布式 SOA

Serverless架构的优缺点

              
2016-06-19 12:07
赞助商链接

Serverless架构或Serverless计算是软件架构风格向分布式系统发展结果,而当前建立一个系统的标准是面向服务架构(SOA)或者是SOA之微服务架构。

在微服务架构中,应用/服务被开发出来然后部署,每个服务组相关一些函数,在Serverless架构中,函数是被开发并部署到独立的平台,这个平台会照顾执行这些函数响应一些事件,举例:当有HTTP请求访问时,也许有一个函数计算计算出一个响应结果,或当一些东西写入到数据库式,会有一个专门函数来执行。

乍一看,这就让人想起了传统的存储过程,与存储过程相反,Serverless架构中的函数不仅仅限制于数据库操作事件,每个函数能够被不同编程语言实现,更远,也没有保证同样函数总是在同一个服务器上运行。

下面看看Serverless的目标和优缺点权衡。

低运营成本
微服务架构中的服务需要一直运行,实际上,在高负载情况下每个服务都不止一个实例,这样才能完成高可用性,在Serverless架构中则是没有事件发生时不会有服务运行,主机平台会只有在需要时才会执行相应的函数,按照云计算pay-as-you-go原则,如果没有东西运行,你就不必付款。

在Serverless架构中,扩展和自动扩展是没有问题的,当负载增加,会让受影响的函数以并行方式运行得更频繁。

弹性配置也在Serverless架构中很有效率,对于传统的云计算环境你会说:
“我愿意买3G内存,然后以后暂时就不需要再扩展了”。
而现在你会说:
“我会为X类型的30000个事件付费,为Y类型的5000个事件付费,然后以后暂时就不需要再扩展了”。

很明显,Serverless计算针对资源的使用是有效率的,特别具有运营的可操作性。

风险1:厂商锁定
平台会提供Serverless架构给大玩家,比如AWS Lambda,运行它需要使用AWS指定的服务,比如API网关,DynamoDB,S3等等,一旦你在这些服务上开发一个复杂系统,你会粘牢AWS,以后只好任由他们涨价定价了。

复杂性和低聚合
多少年来,软件工程师为高聚合和低复杂性奋斗,领域驱动设计和微服务是完美的配合,因为他们总结过去多少年的软件工程经验。

如果开发者忽视这些经验教训是会有风险的,特别是在构建Serverless架构时,它们会遭遇不可维护的函数地狱,在这个情况下,低运营成本优势也许会被更高维护成本超过。





Purposes and trade-offs of the serverless architec

3
Serverless      SOA      微服务     

赞助商链接

赞助商链接

返回顶部

移动版 关于本站 使用帮助 联系反馈 最佳分辨率1366x768
OpenSource JIVEJDON Powered by JdonFramework Code © 2002-20 jdon.com