无服务器架构：Serverless

当我们还在容器的浪潮中前行时，有人已经在悄然布局另外一个云计算战场——Serverless架构，如图2-6所示。

图2-6　Serverless架构

2014年11月14日，亚马逊AWS发布了新产品Lambda。当时Lambda被描述为：一种计算服务，根据时间运行用户的代码，无须关心底层的计算资源。从某种意义上来说，Lambda姗姗来迟，它像云计算的PaaS理念：客户只管业务，无须担心存储和计算资源。在2014年10月22日，谷歌收购了实时后端数据库创业公司Firebase。Firebase声称开发者只需引用一个API库文件就可以使用标准REST API的各种接口对数据进行读写操作，只需编写HTML＋CSS＋JavaScript前端代码，不需要服务器端代码（如需整合，也极其简单）。

相对于上两者，Facebook在2014年2月收购的Parse，则侧重于提供一个通用的后台服务。这些服务被称为Serverless或No sever。想到PaaS（平台即服务）了是吗？很像，用户不需要关心基础设施，只需要关心业务，这是迟到的PaaS，也是更实用的PaaS。这很有可能将会变革整个开发过程和传统的应用生命周期，一旦开发者习惯了这种全自动的云上资源的创建和分配，或许就再也回不到那些需要微应用配置资源的时代了。

1.Serverless架构的优点

Serverless架构能够让开发者在构建应用的过程中无须关注计算资源的获取和运维，由平台来按需分配计算资源并保证应用执行的SLA（服务等级协议），按照调用次数进行计费，有效地节省应用成本。

低运营成本：在业务突发性极高的场景下，系统为了应对业务高峰，必须构建能够应对峰值需求的系统，这个系统在大部分时间是空闲的，这就导致了严重的资源浪费和成本上升。在微服务架构中，服务需要一直运行，实际上在高负载情况下每个服务都不止一个实例，这样才能完成高可用性；在Serverless架构下，服务将根据用户的调用次数进行计费，按照云计算pay-as-you-go原则，如果没有东西运行，就不必付款，节省了使用成本。同时，用户能够通过共享网络、硬盘、CPU等计算资源，在业务高峰期通过弹性扩容方式有效地应对业务峰值，在业务波谷期将资源分享给其他用户，有效地节约了成本。(www.xing528.com)

简化设备运维：在原有的IT体系中，开发团队既需要维护应用程序，同时还要维护硬件基础设施；在Serverless架构中，开发人员面对的将是第三方开发或自定义的API和URL，底层硬件对于开发人员透明化了，技术团队无须再关注运维工作，能够更加专注于应用系统开发。

提升可维护性：在Serverless架构中，应用程序将调用多种第三方功能服务，组成最终的应用逻辑。目前，例如登录鉴权服务、云数据库服务等第三方服务，在安全性、可用性、性能方面都进行了大量优化，开发团队直接集成第三方的服务，能够有效地降低开发成本，同时使得应用的运维过程变得更加清晰，有效地提升了应用的可维护性。

更快的开发速度：在互联网创业公司得到很好的体现，创业公司往往开始由于人员和资金等问题，不可能每个产品线都同时进行，这时候就可以考虑第三方的Baas平台，比如使用微信的用户认证、阿里云提供的RDS、极光的消息推送、第三方支付及地理位置等，能够很快进行产品开发，把工作重点放在业务实现上，把产品更快地推向市场。

2.Serverless架构的缺点

厂商平台绑定：平台会提供Serverless架构给用户，比如AWS Lambda，运行它需要使用AWS指定的服务，如API网关、DynamoDB、S3等，一旦在这些服务上开发出复杂系统，将会粘牢AWS，此后涨价或者下架等操作都不可控，个性化需求很难满足，不能进行随意的迁移或者迁移的成本比较大，同时不可避免带来一些损失。Baas行业内一个比较典型的事件，2016年1月19日Facebook关闭曾经花巨额资金收购的Parse，造成用户不得不迁移在这个平台中产生一年多的数据，无疑需要花费比较大的人力和时间成本。

成功案例比较少，没有行业标准：目前的情况也只适合简单的应用开发，缺乏大型成功案例的推动。对于Serverless缺乏统一的认知以及相应的标准，无法适应所有的云平台。

目前微服务架构在四种架构中处于主流地位，很多应用第一种、第二种架构的企业也开始慢慢转向微服务架构。到目前为止微服务的技术相对于数年前已经比较成熟，第四种架构将是未来发展的一种趋势。