概述
最近做了一些關於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出口寬帶。
--------
看書每每在夜深人靜的時候。