大白話說serverless：關於無服務架構

最新 06-27

前言

本文僅代表作者的個人觀點；

本文在書寫過程中，請教了我的同事kylin，在此表示感謝；

本文的內容僅限於技術探討，不能作為指導生產環境的素材；

一、Serverless是什麼？

Serverless是什麼？百度一下能搜出一大把介紹和廣告，其本質是什麼：

看不懂？

百度上的東西，其實我也看不懂。

在看了很多篇英文博客之後，加上最近補了一些Java EE的知識以後，我大致理解了Serverless的概念了。

Serverless中的server，指的是不是X86物理伺服器，指的是App server，也可以叫EJB container，說簡單點，就是傳統WAS、Weblogic、JBoss的中間件。

所以，serverless，從字面上理解，就是要摒棄掉app server。

很榮幸，我最近正在看的JavaEE的內容，就是serverless要幹掉的技術。

在搞清楚為啥要去app server之前，我先搞清楚什麼是app server。

二、app server的本質是什麼？

紅帽的app server的名稱叫JBoss EAP。它以前還有個名稱，叫JBoss EJB container，聽起來很拉轟。

這又帶來了一個問題，什麼叫EJB。

企業級軟體的核心部分是它的業務邏輯。業務邏輯抽象了整個商務過程的流程，並使用計算機語言將他們實現。

J2EE 對於這個問題的處理方法是將業務邏輯從客戶端軟體中抽取出來，封裝在一個組件中。這個組件運行在一個獨立的伺服器上，客戶端軟體通過網路調用組件提供的服務以實現業務邏輯，而客戶端軟體的功能單純到只負責發送調用請求和顯示處理結果。在J2EE 中，這個運行在一個獨立的伺服器上，並封裝了業務邏輯的組件就是EJB（Enterprise JavaBean）組件。

上面這段話，聽起來很高大上，好比這個樣子：

別著急，我們來逐條剖析：

剖析1：所謂："業務邏輯"

我們注意到在EJB 的概念中主要提到的就是"業務邏輯"的封裝，而這個業務邏輯到底是什麼？說的那麼懸乎，其實這個所謂的"業務邏輯"我們完全可以理解成執行特定任務的"類"。

剖析2：所謂："將業務邏輯從客戶端軟體中抽取出來，封裝在組件中……運行在一個伺服器上"

既然我們知道了"業務邏輯"的概念就是執行特定任務的"類"，那麼，什麼叫"從客戶端軟體中抽取出來"？其實，這個就是把原來放到客戶端的"類"，拿出來不放到客戶端了，放到一個組件中，並將這個組件放到一個伺服器上去運行。

變成大白話就是，"把你編寫的軟體中那些需要執行制定的任務的類，不放到客戶端軟體上了，而是給他打成包放到一個伺服器上了"。EJB 就是將那些"類"放到一個伺服器上，用C/S 形式的軟體客戶端對伺服器上的"類"進行調用。

所以，用大白話說：（從java的角度）app server實際上就是運行jar包的一個軟體平台。這些jar包中，包含了很多java的類。這些類可以被客戶端遠程或者本地調用。將jar運行到app server的好處，是實現了應用的分散式。

脫去了馬甲，他變成了這個樣子：

實際上App server是一個軟體組件，提供必要的運行時環境和基礎結構來託管和管理Java EE企業應用程序。應用程序伺服器提供諸如並發性、分散式組件架構、多平台可移植性、事務管理、Web服務、資料庫對象關係映射（ORM）、非同步消息傳遞以及企業應用程序安全性等功能。

關於Java SE和EE的區別，這是個老生常談的話題：

用大白話說：JavaSE應用，我們可以通過java -jar直接運行；而Java EE應用，需要部署到app server上，才能運行。

JBoss的app server方案是EAP。它能提供的功能如下：

三、

serverless的核心概念

去掉了App Server，剩下的就是一堆java class和調用的方法。那麼他們之間的調用和協調如何實現？

通過serverless的方案實現。也就是，通過serverless的方案，替代傳統的app server的功能（FaaS）。

談到serverless，還有具體的兩種方式:BaaS和FaaS。

BaaS和PaaS的區別在於：PaaS需要參與應用的生命周期管理，BaaS則僅僅提供應用依賴的第三方服務。典型的PaaS平台需要提供手段讓開發者部署和配置應用，例如自動將應用部署到Tomcat容器中，並管理應用的生命周期。BaaS不包含這些內容，BaaS只以API的方式提供應用依賴的後端服務，例如資料庫和對象存儲。BaaS可以是公共雲服務商提供的，也可以是第三方廠商提供的，

我們舉個例子，在典型的PaaS平台，Openshift中，我們部署一個tomcat的web sever，將war包拷貝到容器中企業運行；不用的時候，將pod停掉（將rc設置為0）。在這個過程中，我們對應用進行了全生命周期的管理，我們叫PaaS。

BaaS（後端即服務：Backend as a Service）公司為移動應用開發者提供整合雲後端的邊界服務。例如AppCan，它可以提供的服務有：

信息推送。為Android和iOS終端分別提供基於MQTT和APNS技術的可靠高效信息推送能力，並保證推送信息到達的即時準確。

資料庫。為移動應用提供了庫、表、記錄等級別的DDL和DML操作介面，支持多表關聯處理和數據批量處理，提供記錄導入、導出和檢索管理能力，交付靈活的許可權控制手段。

文件存儲。為移動業務應用提供靈活的文件存儲、上傳、下載服務，支持存儲配額操作介面，提供後台統計分析手段。

第三方接入。為企業業務應用提供第三方平台(新浪微博、微信、QQ)的接入能力，支持接入授權，快速降低應用註冊門檻，方便用戶快捷登錄

我們可以將BaaS看作PaaS的一個子集，即使用第三方提供的PaaS服務。

在serverless中，FaaS是它的核心。而FaaS，正是上文提到的，通過新的技術，去掉傳統app server的功能。那麼，將傳統的app server去掉以後，應用怎麼運行呢？

這就需要看一下serverless的方案了。

四、serverless的方案

Serverless 在當前市場上主要有開源和閉源兩類實踐，如下表：

閉源的方案以 AWS Lambda 為代表，它以服務的方式呈現，在開發者一端，開發者參與到服務的構建，通常實現某特定方法，而在伺服器端則需要依賴廣泛的 AWS 上服務，如 API 網關、存儲、資料庫等

開源的方案以 Apache OpenWhisk 為代表，這種實現主要是圍繞容器對應用開發標準化、規範化、自動化的特性去打造 Serverless，目前它的社區活躍，傳統應用開發廠商積极參与，發展勢頭迅猛

在開源領域，Apache OpenWhisk是很火的。用大白話說，就是用Apache OpenWhisk 替代傳統的app server的功能。

Serverless和微服務的區別是什麼呢？

從筆者的角度看，微服務是將一個單體應用，拆成多個小的模塊，每一個模塊負責一個功能，各個模塊通過zuul（spring cloud）串起來。而serverless，可以對一個小的功能模塊接著拆，最終可以拆成java類的方法，所以serverless的最高境界-FaaS的F，指的就是類的方法、功能。或者，我們可以將FaaS理解成微服務的高階階段。

我們舉個例子，一個傳統的三層應用：

客戶端的訪問，通過瀏覽器：HTML + Javascript，應用運行在app server上，連接後端的資料庫使用JPA。

將這個架構改造成serverless，將會變成什麼樣子呢？

看起來好像更複雜了？沒關係，解釋一下就明白了。

組件1：表示：新的架構，刪除了原有架構的認證組件，採用第三方的BaaS服務。如使用Auth0。這裡，還得簡單介紹一下Auth0。

Auth0是一個「身份即服務」創業公司，同時也是重度的雲服務用戶。Auth0提供給了程序員和公司構建模塊，使得保護應用程序變成一件簡單的事，開發者不需要成為安全領域的專家，即可以輕鬆構建安全的應用。我們可以將任何應用（基於任何棧的任一種語言）連接到Auth0，也可以定義你想要使用的身份提供者（你想怎樣讓用戶登錄）。我們可以基於應用程序所使用的技術來選擇相應的SDK（或者調用我們的API）來連接你的應用。每次用戶試圖登錄，Auth0都會驗證他們的身份並傳回一些應用程序所需要的信息。

組件2：也提供BaaS提供：我們允許客戶端直接訪問我們資料庫的一個子集（用於產品列表），它本身完全由第三方託管（例如，Google Firebase）。我們可能有不同的安全配置文件客戶端以這種方式訪問資料庫，而不是訪問資料庫的伺服器資源。

組件3：此前app server：Pet Store 中的某些業務邏輯，抽取出來，放到客戶端內，例如：跟蹤用戶會話、了解應用程序的UX(UX是User experience的縮寫,中文翻譯為:用戶體驗。UX指用戶體驗,UX設計指以用戶體驗為中心的設計)結構，從資料庫讀取數據並將其轉換為可用的視圖等。由此，客戶端正在成為單頁應用程序。

組件4：我們可能需要保留一部分可客戶體驗相關的功能在app server上。這種通常是它的計算密集型或需要訪問大量的數據。在我們的寵物商店應用中，典型的就是「搜索」。在這種情況下，我們也不需要像改造之前的架構，長期保留app server，我們可以通過API網關響應HTTP請求。這樣也能實現FaaS。

組件5：我們用另一個單獨的FaaS功能替換「購買」功能。由於這個功能比較重要，出於安全原因選擇保留在伺服器端，而不是在客戶端實現。因此和搜索功能一樣，它也被API網關管理。

我們對比一下新舊架構的區別：

在舊架構中，所有訪問流量、控制和安全都由app sever管理。在新的架構中，app server，每個組件都扮演著更具架構意識的角色。以這種方式構建的系統通常「更靈活，更易於改變」。

四、serverless在私有雲中的技術實現

serverless在私有雲中的技術實現：Apache OpenWhisk on Openshift。

其架構如下：

Apache OpenWhisk 架構分三個核心：

以 API 網關為中心的服務治理- 雲原生應用包括 Serverless 將一切服務化、與傳統架構相比，對服務治理的需求更高，現代應用開發需要著重考量服務分類、流量控制、多級安全、記費、API 文檔等。

以 Kafka 為中心的分散式消息處理層- Kafka 在現代應用架構中的作用與日俱增，不管是分散式系統，流數據處理，業務集成、數據整合，企業數據湖構建等領域

以文件資料庫 + 內存計算為中心的數據持層- CouchDB 是一個文件資料庫，基於 NO-SQL key/value 的實現方式，但在內存計算層有比較好的實踐

以容器為中心的計算層- 容器在計算層的優勢在於可細粒度利用計算資源，可標準化計算單元，這些優勢降低應用架構的複雜度，增強了應用架構的敏捷性

我們簡單介紹一下工作原理：

事件：觸發器(Trigger) - 可能觸發一個活動的事件，例如，當一個叫貝克漢姆的人加入到聊天室 (newPersonJoin)

方法:一段短生命周期的代碼處理一個事件，例如，一個 Javascript 輸出 "hello! welcome 貝克漢姆，你好帥!"

而方法的運行平台，就是Apache OpenWhisk on Openshift的pod里。

細心的朋友在看上圖的時候，會發現JBoss少了個組件：EAP，沒錯，serverless就是為了去除EAP功能的，放大點看：

所以說，Apache OpenWhisk是將一堆很潮的技術攢到一起，替代了傳統app server乾的事情。很關鍵的一點是，Apache OpenWhisk 與當下基礎架構中最火的容器有了聯繫，賦予了它更強的生命力與關注度。也就是說，最終OpenWhisk在Openshift上，將會以一堆pod呈現：