Serverless无服务应用架构纵横谈

苏泽湛

　　Serverless无服务应用架构纵横谈
　　一、Serverless是啥
　　自从互联网兴起以来，Server就成了网络的核心部件。所以围绕Server的生意圈，也发展得如火如荼。
　　从最早的电信托管，到虚拟机，到现在的Serverless，形成了几大阵容：
　　1、IaaS（基础设施即服务：Infrastructure as a Service）
　　2、PaaS（平台即服务：Platform as a Service）
　　3、SaaS（软件即服务：Software as a Service）
　　IaaS是包硬不包软，面对集成商，PaaS是包硬包软不包工，面对开发者，SaaS是全包，面对消费者。

　　三大阵营都在不断演进中，互相取长补短，甚至模糊了彼此的界限。
　　PaaS最新的发展就是：
　　1、BaaS（后端即服务：Backend as a Service）
　　2、Faas（函数即服务：Functions as a Service）
　　这两种架构被称为Severless
　　BaaS与FaaS这两种架构被称为Severless，并非对开发者而言，是对服务商而言，没有一直运行的定制服务存在，不占用服务商的计算资源。同共享单车有些类似，是计算机分时租赁方式，按次按时计价。
　　BaaS并不存放客户代码，只提供通用的逻辑，产品的逻辑都需要在富客户端完成。这些通用的逻辑为所有客户共享，因而不浪费服务商的计算资源，也就可以做到按API调用次数计算费用。
　　以前叫我们把二层的富客户端都改成三层瘦客户端，现在搞个共享数据库，又叫我们改成富客户端。横竖赚钱。

　　而FaaS存放客户代码，当访问时，调入相关资源，开始运行，运行完成后，卸载所有开销。
　　嘶~~~，听起来耳熟。靠，这不就是PHP吗？！我是不是发现了什么~~
　　二、Serverless凭啥
　　看来BaaS和FaaS都是新瓶装旧酒，那么Serverless凭啥流行，又是不是未来？
　　Facebook 于2013年花费了 8500 万美元收购了主流的BaaS平台 Parse 。由于 Parse 一直以来未能为>　　搭个共享数据库赚钱的想法基本破灭后，行业都纷纷压宝FaaS。那么FaaS的前景如何?
　　虽然FaaS是BaaS的“升级版”，并且与流行的微服务架构相吻合。但是无法改变它有强制所有程序按PHP方式运行这样一个可怕的设定。而这个无奈的设定所解决的是导致先行者AppEngine举步维艰的病根，那就是大量进程占用服务商过多的资源而不怎么赚钱。所以FaaS这个扭曲版AppEngine对于服务商来说是一剂良药，但是未必会是行业的未来。
　　这些年随着Docker平台的发展，启停一个容器的成本已经接近于启停一个进程。将AppEngine平台上的侦听进程都去掉，用一个统一的WebServer来侦听路由，当访问到来时，启动容器，运行，停止容器。这和PHP的做法一模一样，不过是把PHP.exe换成了Docker容器罢了。同一个思路，换一个环境，马上从落后变成了先进。可以你想像，FaaS是降低成本的利器，也一定会占有一部分低端市场。
　　但是，PHP也没有像FaaS一样强制要求所有服务达到函数这个级别，一步到位的确有点匪夷所思。函数也非FaaS最好的包装形式，不如像PHP直接对应到一个文件上。在我看来，现有FaaS平台的行为模式，只适合推广PHP，能够与PHP生态很好地对接，而其它语言则有不可调和的矛盾。
　　看了一下开源框架Fission的源码，想出一个兼容其它语言的方案，以Python语言为例。
　　要求Flask程序实现2个接口，原有的程序不加任何修改即可在FaaS框架下运行了，/register接口载入所有Route，并返回所有绑定规则，FaaS框架只需要把Route表合并就可以一次性创建所有Route。不必要一条一条调用fission function create与fission route add了。Http 请求来时调用/specialize接口，根据endpoint（即函数名）载入代码，实现FaaS功能。把框架接口开放给程序，能够实现最大的兼容现有框架，如果不放心，可以调用/specialize?endpoint=echo&echo=hello，来验证程序是否支持FaaS平台即可。
　　

from flask import Flask, request　　

　　
app
= Flask(__name__)　　

　　
userfunc
= None　　

　　
@app.route(
'/register', methods=['POST'])　　

def register():# 引入所有Routes，并返回所有Rules　　from .main import main as main_blueprint
　　app.register_blueprint(main_blueprint)
　　return jsonify(app.url_map._rules_by_endpoint)
　　

　　
@app.route('/specialize', methods=['POST'])
　　
def load():
　　# 特化载入，只载入单个endpoint
　　body = request.get_json()
　　name = body['endpoint']
　　global userfunc
　　userfunc = imp.load_source(name)
　　return ""
　　

　　三、Serverless有啥
　　Serverless平台一般分为如下三类：
　　1. 公有云Severless平台：
　　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. Gestalt （DC/OS）、
　　E. IBM OpenWhisk （Docker）、F. Iron Functions （Docker，Swarm， Kubernetes）
　　3.Serverless平台的包装框架：
　　A. Serverless（Node，大多数平台）、B. Apex（Go，AWS）
　　C. Zappa（Python，AWS）、D. Chalice（Python，AWS）
　　E. Claudia.js（Node，AWS）F. Gordon （Python，AWS）
　　四、Serverless干啥
　　1、AWS Lambda的包装框架Zappa，可以使用Flask,Django等框架。功能看下图可知：

2、Fission是一个Serverless开源框架。可以看看它都干了啥。
Fission是基于Kubernetes的，而Kubernetes是基于Docker的容器集群管理系统。
Kubernetes的内容太丰富，简单说来，实体对象有若干节点（Node）包含若干Pod，Pod又包含若干容器（Container），通过Pod上的标签（Label）组合成服务（Service）。

　　Master包含如下组件：

• apiserver：作为kubernetes系统的入口，封装了核心对象的增删改查操作。它维护的REST对象将持久化到etcd。
  
• etcd：分布式强一致性的key/value存储
  
• scheduler：负责集群的资源调度，为新建的pod分配机器。
  
• controller-manager：负责执行各种控制器，目前有两类：
  
  
  
  • endpoint-controller：定期关联service和pod(关联信息由endpoint对象维护)，保证service到pod的映射总是最新的。
    
  • replication-controller：定期关联replicationController和pod，保证replicationController定义的复制数量与实际运行pod的数量总是一致的。
    
  
  

　　Slave Node（称为Minion）包含如下组件：

• kubelet：负责管控docker容器，如启动/停止、监控运行状态等。它会定期从etcd获取分配到本机的pod，并根据pod信息启动或停止相应的容器。同时，它也会接收apiserver的HTTP请求，汇报pod的运行状态。
  
• proxy：负责为pod提供代理。它会定期从etcd获取所有的service，并根据service信息创建代理。当某个客户pod要访问其他pod时，访问请求会经过本机proxy做转发。
  
• docker：docker容器引擎
  

　　Fission简单说来，就是一个Web应用，Go语言编写，使用gorilla框架。不过它的模板引擎替换成了Kubernetes中的Service。使用k8s.io/client-go/kubernetes接口来操控（k8s就是Kubernetes）。

　　参考文档：
　　《采用Serverless架构》
　　《Kubernetes初探》
　　《十分钟带你理解Kubernetes核心概念》
　　《Kubernetes权威指南》
　　（完）