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 一直以來未能為 Facebook 提供預期的營收，Facebook 決定一年後将其正式關閉，并将其代碼開源。Facebook這不差錢的行為，直接為整個行業蒙上了陰影。可以說直接逼死了某些跟風者。 

搭個共享資料庫賺錢的想法基本破滅後，行業都紛紛壓寶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權威指南》

（完）