Array|四种常见的系统架构,目前你处于哪个阶段呢?( 三 )


Serverless架构能够让开发者在构建应用的过程中无需关注计算资源的获取和运维 , 由平台来按需分配计算资源并保证应用执行的SLA(服务等级协议) , 按照调用次数进行计费 , 有效的节省应用成本 。ServerLess的架构如上图所示 。其优点如下所示:
低运营成本:在业务突发性极高的场景下 , 系统为了应对业务高峰 , 必须构建能够应对峰值需求的系统 , 这个系统在大部分时间是空闲的 , 这就导致了严重的资源浪费和成本上升 。在微服务架构中 , 服务需要一直运行 , 实际上在高负载情况下每个服务都不止一个实例 , 这样才能完成高可用性;在Serverless架构下 , 服务将根据用户的调用次数进行计费 , 按照云计算pay-as-you-go原则 , 如果没有东西运行 , 你就不必付款 , 节省了使用成本 。同时 , 用户能够通过共享网络、硬盘、CPU等计算资源 , 在业务高峰期通过弹性扩容方式有效的应对业务峰值 , 在业务波谷期将资源分享给其他用户 , 有效的节约了成本 。
简化设备运维:在原有的IT体系中 , 开发团队即需要维护应用程序 , 同时还要维护硬件基础设施;Serverless架构中 , 开发人员面对的将是第三方开发或自定义的API 和URL , 底层硬件对于开发人员透明化了 , 技术团队无需再关注运维工作 , 能够更加专注于应用系统开发 。
提升可维护性:Serverless架构中 , 应用程序将调用多种第三方功能服务 , 组成最终的应用逻辑 。目前 , 例如登陆鉴权服务 , 云数据库服务等第三方服务在安全性、可用性、性能方面都进行了大量优化 , 开发团队直接集成第三方的服务 , 能够有效的降低开发成本 , 同时使得应用的运维过程变得更加清晰 , 有效的提升了应用的可维护性 。
更快的开发速度:这一点在现在互联网创业公司得到很好的体现 , 创业公司往往开始由于人员和资金等问题 , 不可能每个产品线都同时进行 , 这时候就可以考虑第三方的Baas平台 , 比如使用微信的用户认证、阿里云提供的RDS , 极光的消息推送 , 第三方支付及地理位置等等 , 能够很快进行产品开发的速度 , 把工作重点放在业务实现上 , 把产品更快的推向市场 。
但ServerLess架构也有其缺点:
厂商平台绑定:平台会提供Serverless架构给大玩家 , 比如AWS Lambda , 运行它需要使用AWS指定的服务 , 比如API网关 , DynamoDB , S3等等 , 一旦你在这些服务上开发一个复杂系统 , 你会粘牢AWS , 以后只好任由他们涨价定价或者下架等操作 , 个性化需求很难满足 , 不能进行随意的迁移或者迁移的成本比较大 , 同时不可避免带来一些损失 。Baas行业内一个比较典型的事件 , 2016年1月19日Facebook关闭曾经花巨额资金收购的Parse , 造成用户不得不迁移在这个平台中产生一年多的数据 , 无疑需要花费比较大的人力和时间成本 。
成功案例比较少 , 没有行业标准:目前的情况也只适合简单的应用开发 , 缺乏大型成功案例的推动 。对于Serverless缺乏统一的认知以及相应的标准 , 无法适应所有的云平台 。
目前微服务架构在四种架构中处于主流地位 , 很多应用第一、第二种架构的企业也开始慢慢转向微服务架构 。到目前为止微服务的技术相对于二三年前已经比较成熟 , 第四种架构将是未来发展的一种趋势 。


推荐阅读