Serverless和PaaS之间区别

概述
最近做了一些关于server应用的集群化平台运维相关的事情，所以想写一篇关于 Serverless 和PaaS（Platform-as-a-service）的东西。坦率地来讲，Serverless 较 PaaS 而言，缺少了一些部署相关的构件，这句话怎么理解呢，一个是服务级别，一个是部署包级别。拿容器化PaaS来举例，部署包级别就一定会存在编译打包部署，要将部署包部署到类似tomact，jboss中间件的过程。而对于服务级别的Serverless，只需要能编译为 Unix 进程即可。此处虽然有点儿标题党的意味，但在我看到，进程以何种方式、何种组建、灵不灵活、简不简单地部署，这些并不是最重要的事情。服务在持续稳定的运行过程中，能够很好地横向伸（缩）拓展以及提供服务化的负载均衡，这便是业务需求的核心问题。

1. Serverless 和 PaaS 的相似之处
为什么总喜欢把Serverless和PaaS这两者放在一起比较呢，不是SaaS，更不是IaaS？那就让我们先盘一下 -aaS 的整体Manage层次关系，我比较喜欢下面这张图，是不是觉得一目了然（And you？）

IaaS：基础架构即服务

基础架构即服务（IaaS），由高度可扩展和自动化的计算资源组成。 IaaS是完全自助服务，用于访问和监控计算、网络，存储和其他服务等内容，它允许企业按需求和需要购买资源，而不必购买全部硬件。IaaS通过虚拟化技术为组织提供云计算基础架构，包括服务器、网络，操作系统和存储等。这些云服务器通常通过仪表盘或API提供给客户端，IaaS客户端可以完全控制整个基础架构。 IaaS提供与传统数据中心相同的技术和功能，而无需对其进行物理上的维护或管理。 IaaS客户端仍然可以直接访问其服务器和存储，但它们都通过云中的“虚拟数据中心”。

PaaS：平台即服务

平台即服务（PaaS）为某些软件提供云组件，这些组件主要用于应用程序。 PaaS为开发人员提供了一个框架，使他们可以基于它创建自定义应用程序。所有服务器，存储和网络都可以由企业或第三方提供商进行管理，而开发人员可以负责应用程序的管理。PaaS的交付模式类似于SaaS，除了通过互联网提供软件，PaaS提供了一个软件创建平台。该平台通过Web提供，使开发人员可以自由地专注于创建软件，同时不必担心操作系统、软件更新，存储或基础架构。

SaaS：软件即服务

软件即服务（SaaS，也称为云应用程序服务）代表了云市场中企业最常用的选项。 SaaS利用互联网向其用户提供应用程序，这些应用程序由第三方供应商管理。 大多数SaaS应用程序直接通过Web浏览器运行，不需要在客户端进行任何下载或安装。由于其网络传输模式，SaaS无需在每台计算机上下载和安装应用程序，而在每台计算机上下载和安装应用程序正是IT员工的噩梦。 通过SaaS，供应商可以管理所有潜在的技术问题，例如数据、中间件，服务器和存储，因此企业可以简化其维护和支持。

FaaS：函数即服务

函数即服务（FaaS）意在无须自行管理服务器系统或自己的服务器应用程序，即可直接运行后端代码。其中所指的服务器应用程序，是该技术与容器和PaaS等其他现代化架构最大的差异。FaaS可以取代一些服务处理服务器（可能是物理计算机，但绝对需要运行某种应用程序），这样不仅不需要自行供应服务器，也不需要全时运行应用程序。

BaaS：后端即服务

后端即服务（BaaS）是指我们不再编写或管理所有服务端组件，可以使用领域通用的远程组件（而不是进程内的库）来提供服务。BaaS只以API的方式提供应用依赖的后端服务，例如数据库和对象存储(对中间件资源池的关注转变对API能力接口的关注，真正从资源到服务)。BaaS可以是公共云服务商提供的，也可以是第三方厂商提供的。从功能上讲，BaaS可以看作PaaS的一个子集，即提供第三方依赖组件的部分。

从管理结构上看，对开发者来讲，Serverless和PaaS的后台架构都是对用户不可见的，它们是很相似的。（虽然SaaS的后台架构也是对用户不可见，但是SaaS的应用软件都不是自己的<花钱买~omg~>，别提有多不开心啦。。。）

2. Serverless 和 PaaS 的区别特点
2.1 先聊聊 PaaS
无论您的公司规模如何，使用PaaS都有很多优势。 首先，如果有多个开发人员在同一个开发项目上工作，或者必须包含其他中间件等，PaaS可以为整个过程提供极大的速度和灵活性。其次，开发人员能够创建自定义应用程序，可以复用平台工具代码，大大减少了编码量。再者，在应用部署和管理上，PaaS具有很强的可用性和拓展性，提供自动化业务策略，能轻松迁移到混合模型。

以 AWS Elastic Beanstalk 举个栗子吧，Amazon Web Services (AWS) 包含一百多种服务，每项服务都针对一个功能领域。服务的多样性可让开发者们灵活地管理 AWS 基础设施，但是，判断应使用哪些服务以及如何进行预配置可能会非常困难。通过 Elastic Beanstalk，可以在 AWS 云中快速部署和管理应用程序，减少了管理复杂性，也不会限制选择或控制权。你只需上传应用程序，Elastic Beanstalk 将自动处理有关容量预配置、负载均衡、扩展和应用程序运行状况监控的部署细节，同时还有console控制台和special CLI工具等，方便与其上面的所有应用程序进行相关交互。

2.2 再说说 Serverless
大部分人开始了解 Serverless 的时候，会误以为 Serverless 等价于 FaaS，比如Google的Cloud Function，AWS 的 Lambda，这些都是 Serverless 没错，但是用等价关系，我个人举脚趾头不赞同。我们产生这样的误区的原因，可能在于我们拿它和微服务比较的时候，实际上比较的是FaaS和微服务。

直观上来看，微服务和FaaS的差别在于粒度，微服务是功能级别，FaaS 是函数级别。server 要实现FaaS，首先必须将单体应用演进到微服务，然后才能进一步地分解到函数级别，实现FaaS。FaaS产品不要求必须使用特定框架或库进行开发，这点很重要，没有很重的开发框架概念，类似在微服务架构开发的时候，我们还会使用SpringCloud开发框架和库，这个在FaaS里面不再存在。

在语言和环境方面，FaaS函数就是常规的应用程序，譬如 AWS Lambda 的函数可以通过Javascript、Python以及任何JVM语言（Java、Clojure、Scala）等实现。部署方法会有较大变化 – 将代码上传至 FaaS供应商，其他事情均可由供应商完成（不再存在编译构建，并要打包为部署包这个动作）。目前这种方式通常意味着需要上传代码的全新定义（例如上传zip或JAR文件），随后调用一个专有API发起更新过程。我们部门的IDC天算平台上的算法包服务，也是一个很好的例证。

2.3 边缘计算能力
Serverless应用程序不依赖于特定的机器或平台，可以在互联网的任何部分任何地方运行；所以可以部署在紧邻终端用户的地方，极大的缩短延迟。对于PaaS而言，虽然从开发者角度看，PaaS也是无服务器的（不用管理服务器），但PaaS应用程序代码本质上是跑在IaaS（其他供应商的IaaS或自己的）。这意味着构建在云平台上的应用程序很有可能只能运行在特定机器上（如云计算中心特殊设计的机器或云数据库），从而可能阻止开发者优化应用程序来在边缘设备上运行。

3. 为什么说“缺”一个负载均衡
PaaS具有许多将其定义为云服务的特征，包括：

它基于虚拟化技术，这意味着随着业务的变化，资源可以轻松扩展或缩小
提供各种服务以协助开发，测试和部署应用程序
许多用户可以访问相同的开发应用程序
Web服务和数据库是集成的
这些“云”特质，正是Serverless所不包含的。PaaS提供服务集成化、规模化支撑的时候，负载均衡的功能自然涵盖在平台打包构建部署里面了，而Serverless提供服务，从自身服务管理级别就忽略了“负载均衡”这一层面。

4. 负载均衡的方法
我们讨论的负载均衡一般分为两种，一种是基于DNS，另一种基于IP报文。

4.1. DNS负载均衡
DNS负责提供域名解析服务，当访问某个站点时，实际上首先需要通过该站点域名的DNS服务器来获取域名指向的IP地址，在这一过程中，DNS服务器完成了域名到IP地址的映射，这样映射可以是一对多的，这时候DNS服务器便充当了负载均衡调度器，通过映射策略配置（ 即配置多条A记录，用来指定域名对应的IP地址），将用户的请求分散到多台服务器上。

我们来dig一下alibaba.com的DNS配置：

DNS服务器作为调度器，它本身的性能几乎不用担心。因为DNS记录可以被用户浏览器或者互联网接入服务商的各级DNS服务器缓存，只有当缓存过期后才会重新向域名的DNS服务器请求解析。也说是DNS不存在http的吞吐率限制，理论上可以不断地增加实际服务器的数量。

特性:

可以根据用户IP来进行智能解析。DNS服务器可以在所有可用的A记录中寻找离用记最近的一台服务器。
动态DNS：在每次IP地址变更时，及时更新DNS服务器。（当然，因为缓存，有一定的延迟不可避免。）
不足：

用户不能直接看到DNS解析到了哪一台实际服务器，给Ops的调试带来了不便。
AA轮询。一般采用A记录轮询策略，如果要根据实际服务器的实时负载差异来调整调度策略，这需要DNS服务器在每次解析操作时分析各服务器的健康状态，对于DNS服务器来说，这种自定义开发存在较高的门槛，更何况大多数站点只是使用第三方DNS服务。
DNS记录缓存，各级节点的DNS服务器不同程序的缓存会让你晕头转向。
4.2. http重定向和反向代理
当http代理（比如浏览器）向web服务器请求某个URL后，web服务器（视作主站点服务器或调度器）可以通过http响应头信息中的Location标记来返回一个新的URL。这意味着HTTP代理需要继续请求这个新的URL，完成自动跳转，这便是http重定向；如果主站点服务器不是根据Location标记等信息来判断，而是根据URL的/子路径作请求分发，这便是反向代理负载均衡。

特性：

调度策略丰富。例如可以为不同的实际服务器设置不同的权重，以达到能者多劳的效果。
主站点服务器（或者调度器）可以监控和保护后端服务器，比如系统负载、响应时间、是否可用、TCP连接数、流量等，从而根据这些数据调整负载均衡的策略。当网络发生恶意攻击的时候，可以一定程度上保护后端服务器减轻危害。
主站点服务器（或者调度器）可以让用户在一次会话周期内的所有请求始终转发到一台特定的后端服务器上（粘滞会话），这样的好处一是保持session的本地访问，二是防止后端服务器的动态内存缓存的资源浪费。
不足：

主站点服务器（或者调度器）的并发处理能力要求高，因为它工作在HTTP层面。
吞吐率限制。“一夫当关”，自身会成为请求访问瓶颈。
主站点服务器（或者调度器）进行转发操作本身是需要一定资源开销的，比如创建线程、与后端服务器建立TCP连接、接收后端服务器返回的处理结果、分析HTTP头部信息、用户空间和内核空间的频繁切换等，虽然这部分时间并不长，但是当后端服务器处理请求的时间非常短时，转发的开销就显得尤为突出。
可以建议反向代理负载均衡配合DNS负载均衡一起配套使用。

4.3. VIP负载均衡(LVS-NAT和LVS-DR)
因为重定向和反向代理服务器工作在HTTP层，其本身的性能和资源开销严重制约了容量的可扩展性，那能否在HTTP层面以下实现负载均衡呢？

LVS-NAT：它工作在传输层（第四层），它可以修改发送来的IP数据包，将数据包的目标地址修改为实际服务器地址。

从Linux2.4内核开始，其内置的Neftilter模块在内核中维护着一些数据包过滤表，这些表包含了用于控制数据包过滤的规则。Linux2.6.x内核中内置了IPVS模块，它的工作性质类似于Netfilter模块，不过它更专注于实现IP负载均衡。

我们用 modprobe -l 来检查一下自己的linux系统机器是否内置了IPVS模块：

有输出意味着IPVS已经内置自带了。

下面来手把手玩一遍。IPVS的管理工具是ipvsadm，它为提供了基于命令行的配置界面，可以通过它快速实现负载均衡系统。这就是常说的LVS(Linux Virtual Server，Linux虚拟服务器)。

开启调度器的数据包转发选项
echo 1 > /proc/sys/net/ipv4/ip_forward
检查实际服务器是否已经将NAT服务器作为自己的默认网关，如果不是，如添加
route add default gw xx.xx.x.x
使用ipvsadm配置
ipvsadm -A -t 100.100.100.100:80 -s rr
ipvsadm -a -t 100.100.100.100:80 -r 10.10.120.210:7777 -m
ipvsadm -a -t 100.100.100.100:80 -r 10.10.120.211:7777 -m
添加一台虚拟服务器，-t 后面是服务器的外网ip和端口，-s rr是指采用简单轮询的RR调度策略（这属于静态调度策略，除此之外，LVS还提供了系列的动态调度策略，比如最小连接（LC）、带权重的最小连接（WLC），最短期望时间延迟（SED）等）

添加两台实际服务器（不需要有外网ip），-r后面是实际服务器的内网ip和端口，-m表示采用NAT方式来转发数据包

运行ipvsadm -L -n可以查看实际服务器的状态。这样就搞定了。

LVS-DR：工作在数据链路层（第二层）。它通过修改数据包的目标MAC地址（没有修改目标IP），将数据包转发到实际服务器上，不同的是，实际服务器的响应数据包将直接发送给客户羰，而不经过调度器。

这里假设一台负载均衡调度器，两台实际服务器，购买三个外网ip，默认网关需要都相同，设置相同的ip别名，譬如别名为11.164.87.206。这样一来，将通过11.164.87.206这个IP别名来访问调度器，你可以将站点的域名指向这个IP别名。

将ip别名添加到回环接口lo上
这是为了让实际服务器不要去寻找其他拥有这个IP别名的服务器，在实际服务器中运行：

sudo ifconfig lo:11.164.87.206 broadcast 11.164.87.255 netmask 255.255.255.192 up
sudo route add -host 11.164.87.201 dev lo:0
另外还要防止实际服务器响应来自网络中针对IP别名的ARP广播，为此还要执行：

echo “1” > /proc/sys/net/ipv4/conf/lo/arp_ignore
echo “1” > /proc/sys/net/ipv4/conf/lo/arp_announce
echo “1” > /proc/sys/net/ipv4/conf/all/arp_ignore
echo “1” > /proc/sys/net/ipv4/conf/all/arp_announce
配置完了就可以使用ipvsadm配置LVS-DR集群了

ipvsadm -A -t 11.164.87.206:80 -s rr
ipvsadm -a -t 11.164.87.206:80 -r 10.10.120.210:8888 -g
ipvsadm -a -t 11.164.87.206:80 -r 10.10.120.211:8888 -g
-g 就表示使用直接路由的方式转发数据包

LVS-DR 相较于LVS-NAT的最大优势在于LVS-DR不受调度器出口宽带的限制，它的实际服务器的响应数据包可以不经过调度器而直接发往用户端，所以它与调度器的出口宽带没有关系。于是，当响应数据包远远超过请求数据包的服务，就越应该降低调度器转移请求的开销，也就越能提高整体的扩展能力，最终也就越依赖于WAN出口宽带。