【51CTO.com快译】Serverless架构的风格挑战了软件设计的现状，并且实现了最优开发、操作和管理开销的部署基础。随着它继承了来自微服务架构(Microservices Architecture，MSA)的基本概念，它已经被赋予了相当前卫的模式，以达到了最低级别的硬件空置架构。
尽管它带来了显著的进展，但是采用它则需要一个深思熟虑的过程，从而将企业对于解决方案的需求映射到Serverless计算之上。
最初的软件系统的实现是部署在物理服务器上的，因为在给定的时间内操作系统只能有一个实例在运行，因此底层硬件的计算能力是无法被最优地利用到的。随着技术的发展，在分时功能的计算资源被确立之后，通过同时在多个虚拟机之间进行切换CPU和I/O的操作，它们得以运行在相同的硬件之上。
这种科技性的发展引领了许多行业的创新，而也对于云技术的起步是非常重要的。此时的虚拟机孤立于软件部署的计算环境，是一些最为可控的、可伸缩的、和可编程的单元。2006年前后，当Google结合Linux内核的特性实现了控制组的时候，Linux容器技术也就随即出现了。
从那以后，Linux容器其实都一直止步不前，因为，只有像Google这样大规模的且技术卓越的企业才能够成规模使用它。到了2012年，微服务架构的概念被一组软件架构师介绍到了欧洲。而在2013年的晚些时候，Docker眨眼之间填补了容器生态系统中的可访问性、可用性、以及支持服务的空缺。因此，容器也就开始变得流行起来了。
Linux容器打开了新视野，它将大型整体的系统分解为单个的、自包含的服务，并能以细粒度的资源利用率来执行之。伴随着这些进步的推进，像Kubernetes(Google开源的Docker容器集群管理系统)和Mesosphere这样的容器集群管理系统，开始提供端到端容器即服务(Container as a Service，CaaS)的功能，并同时进入了上升周期。
到了2015年的晚些时候，AWS通过引入AWS Lambda又向前跨了一大步。它可以通过按需运行微服务，并在无负载时停止之，从而进一步节省了软件部署的成本。这个概念类似于节能汽车上的启停功能，通过自动关闭内燃发动机以减少燃料的消耗。
它是如何工作的?
尽管“Serverless”一词乍一看来看有些荒谬，但是它的实际意义是：在没有任何基础设施干预下的软件部署的能力。Serverless平台自动化了整个过程中的建立、部署和按需启动服务。用户只需注册各种所需要的业务功能和其资源的需求。
很明显，这样的功能可以被分为两种主要类型：由客户请求所触发的功能和那些需要在后台执行的时间或事件所触发的功能。一般来说，这样的Serverless系统可以使用一个容器集群管理器(container cluster manager，CCM)来实现，它具有一个动态的能按需延展容器的路由器。然而，这也将需要考虑到路由器的延迟性、容器的创建时间、语言的支持、协议的支持、函数的接口、函数的初始化时间、配置参数的传递、以及提供证明文件等方面。
尽管这种部署风格需要在没有负载的时候容器能够被停止，但在现实环境中，在服务请求之后这么快速地终止容器是需要高昂代价的。因为在较短时间的间隔内很可能会有更多的请求的产生，所以更为通常出现的情况是：Serverless计算容器会在预配置好的一段时间内被保存，以便被更多请求服务所重用到。这类似于PaaS平台的自动扩展行为。一旦服务被扩展，它的一些实例将会被保留一段时间，以便处理更多的请求，而非立即终止它们。
选择一个Serverless平台
Serverless平台一般分为如下三类：
1. 公有云上的功能即服务(Functions as a Service，FaaS)解决方案：
A. AWS Lambda、B. Microsoft Azure Functions、C. Google Cloud Functions、D. Webtask、E. Syncano
2. 运行在共有和私有数据中心的severless框架：
A. Fission - 运行在Kubernetes上、B. Funktion -运行在Kubernetes上、C. Kubeless -运行在Kubernetes上、D. Galactic Fog Gestalt – 运行在DC/OS上、E. IBM OpenWhisk – 运行在Docker上、F. IronFunctions – 运行在Docker，Docker Swarm， Kubernetes上
3.提供agnostic应用接口或/和现有Serverless框架增值服务的包装框架：
A. Serverless.com – 支持AWS Lambda， IBM OpenWhisk、B. Apex – 支持AWS Lambda
如果你要决定选择哪一个Serverless平台的话，首先取决于数据中心将要运行何种方案。其次是它的特殊性、成熟度，以及对供应商的依赖程度，这也可能是需要被评估的方面。除了公共FaaS所能提供的，AWS Lambda和Azure也能够提供完全成熟的Serverless产品。Google的云服务功能仍处于alpha阶段，且只能通过邀请来获取。Fission和Funktion这两个对Kubernetes的Serverless框架的适用比较流行。由Iron.io所开发的IronFunctions是一种独立于Serverless框架的相对新的平台。IBM的OpenWhisk平台已经捐赠给了Apache软件基金会，现处于孵化阶段。另外，上述第三个类型也提供了实现多重云的Serverless部署选项，也是现有的公共FaaS的一种增值提供。
设计Serverless功能的最佳实践
我们在设计Serverless功能时，应考虑如下的设计原则：
· 在定义功能的范围时应遵循单一责任的原则。
· 通过优化功能来实现以毫秒为单位的执行效率。
· 坚持无状态的协议，以能够在功能上无缝地扩展。
· 使用外部的服务来实现服务的发现、状态和缓存管理。
· 使用环境变量来读取配置而非不依赖于文件。
· 鉴于容器被设计为是短暂的，我们应该避免使用文件系统去保持数据的持久性。
结论
Serverless架构的技术和设计模式还处在起步阶段。当前，只要没有对可支持的编程模型在实现该功能上的限制，各种新的应用程序和现有系统的扩展都可以毫不费力地迁移到该架构之上。同时，由于各种RPC协议，例如WebSocket、协议缓冲区、AMQP、MQTT、Apache Thrift都需要一个一直处于激活状态的侦听器，因此为信息接收通道选择无状态协议也是非常重要的。而且，实现协调逻辑的业务需求，为业务流程实现功能分组，管理分布式的事务、状态等方面都可能需要第三方服务和工具。使用容器池的Serverless平台，因为对于容器的重用方式的不同，也可能会带来一些安全漏洞。它们也可能会不允许根据功能来进行资源配置。所以，在考虑为生产系统采用Serverless架构的时候，理解所有这些方面都是相当重要的。不过，鉴于许多框架已经被建立和完善，这仍然可能是对于搭建一个POC(云平台)和为即将上马的项目评估其优势的大好时机。
【原标题】Adapting Serverless Architecture (作者: Imesh Gunaratne)
原文链接：https://dzone.com/articles/adapting-Serverless-architecture
【51CTO译稿，合作站点转载请注明原文译者和出处为51CTO.com】
