京東智聯云在Serverless的探索是怎樣的

京東智聯云在Serverless的探索是怎樣的，很多新手對此不是很清楚，為了幫助大家解決這個難題，下面小編將為大家詳細講解，有這方面需求的人可以來學習下，希望你能有所收獲。

Serverless 的概念和定義

提到 Serverless，?家基本上第?時間會想到的就是 AWS lambda，沒錯，讓 Serverless 這個名稱真正?起來的其實就是 AWS 推出的 FaaS 服務 -- Lambda，它是?個平臺，允許你在云上允許獨?的代碼段，通過預先設置好的事件觸發代碼的運?。

除了 FaaS 之外，還有BaaS，雖然和 Blockchain as a Service 的縮寫?樣，但它其實是 Backend as a Service -- 后端即服務的縮寫，?需編寫/管理所有服務端組件，與虛擬機和容器相?，概念上更接近 SaaS（軟件即服務），BaaS 服務都是領域通?的組件服務，通過 API 調?的?式來使?。

說完了定義，再來看下 Serverless 的發展史。

• 最早可以追溯到 2006 年，Zimki 推出的代碼執?平臺，它是?個提出按使?收費的服務；

• 接著就是 2011 年的 Parse，它提供了 BaaS 框架，?便?戶基于它更快的構建應?程序，后來是被 Facebook 收購；

• 到了 2012 年，相繼有 Fribase 和 IronWorker 服務，前者是?個針對移動端的應?開發平臺，后來被 Google 收購了，后者是基于容器的應?負載平臺；

• 到了 2014 年，也就是 AWS 推出了 Lambda，?個云上的 FaaS 服務，將 Serverless 概念帶到了?眾的視野中；

• 緊接著在 2016 年，Google，Azure，IBM 分別在他們的云服務上上線了 FaaS 服務。

在過去提到云計算，?家?熟能詳的就是 IaaS，PaaS，SaaS，那么這個 FaaS 和其他三者什么區別？在我的定義??，操作系統以上都需要?運維的屬于 IaaS；PaaS 其實和 FaaS 是?乎?樣的，除了應?這?層之外，其他都是由云服務提供商來進?運維；SaaS 最簡單，現成的，直接上?使?即可。

?家可能會好奇，既然你說 FaaS 和 PaaS ?乎?樣，那么為什么不直接稱之為 PaaS 呢。不著急，我們先來看看這個：CloudFoundry，可能有?些?會?較陌?，但是如果你是屬于云計算的?兵，那么你肯定不會陌?。

AWS 是 2006 年推出的，國內最早的阿?云也是在 09 年才成?，其實到了 2012 年左右，云計算的概念才慢慢傳到國內，我是 2013 年開始涉?云計算，那時候其實就已經開始 IaaS，PaaS，SaaS 的競爭，有的公司從 IaaS 做起，有的直接從 PaaS 或者 SaaS 開始做起；那時候提到 PaaS，肯定就會提到 CloudFoundry（業界?個開源的 PaaS 平臺），很多互聯?企業基于 CloudFoundry 構建了 PaaS 云服務， ?如：京東的 JAE，新浪的 SAE，百度的私有云等等。

當我第?次接觸 FaaS 的時候，我第?個感覺就是， 咦，這個和 CloudFoundry 很相似啊，在你向 CloudFoundry 發布應?的時候，對執?環境有要求，明確選擇你是基于什么開發語?以及版本，如果當前平臺不?持，那么你其實也是?法部署運?起來的，其次平臺也提供了?動彈性伸縮，?動服務?可?，以及?關/路由等服務，然后你發現兩者的最?區別在于， CloudFoundry 平臺上提供的是?個常駐服務，但是 FaaS 是?個事件觸發代碼運?的服務。

為了讓?家更直觀的理解，我們來看下這個。

在裸?屬時代，從硬件到代碼都是需要?運維的，到了后來出現了虛擬化，像各家云上的云主機服務，使?者只需要關注操作系統以上這?層即可，再到后來的容器技術出現，使?者是需要關注容器?身和業務代碼即可，?前 CloudFoundry 平臺就是提供了容器服務，?戶將 ??的業務代碼部署到容器中，作為?個常駐服務運?起來。最右邊就是 Function 了，?戶連容器都不需要 ??維護了，只需要關注代碼即可。

每?項新技術的出現即是為了解決當前的技術遇到的問題，同時新技術的采?也必然會引?新的問題。?先說下 Serverless 的優勢：

• 優勢?：降低成本，這?的成本既包括了運營成本，也包括了開發成本，這個很好理解，由于你不需要維護像操作系統，硬件等相關的組件，所以也就不需要雇傭相應領域的?員，從?降低了成本；

• 優勢?：加速創新，當開發完業務代碼，配合和現成的 Serverless 第三?服務（?如認證服務，?件存儲服務等），可以快速的把業務部署并運?起來，??縮短了過去業務開發的周期；

• 優勢三：可擴展性，在沒有 FaaS 之前，要解決業務的彈性伸縮功能，需要購買云?商提供的彈性伸縮服務，并且進?相應的條件配置之后，才能實現業務的?動彈性伸縮；在 FaaS 服務中，?動彈性伸縮的功能是默認就?持的。

接著說下 Serverless 的劣勢：

• 劣勢?：延遲，由于采?了 Serverless 的?式部署服務，所以服務之間的調?都需要經過?絡傳輸，?不能是原先的本地調?，所以相對??延遲肯定會增加；

• 劣勢?：集成測試，由于采?了 Serverless 技術，那么當你開發完代碼想在本地環境中進?測試驗證， 就?較麻煩，因為你本地不存在和云上的?樣環境；

• 劣勢三：供應商綁定，由于 Serverless 技術是?個新興的技術，每?個供應商的提供技術和標準并不?致，所以?旦你基于某?個云?商的 Serverless 服務部署你的業務，如果再想搬遷到其他云上，那么難免對你的業務會有改造成本；

Serverless 在京東智聯云的應?和實踐

介紹完 Serverless 的概念和定義，接下來看看 Serverless 在京東智聯云的應?和實踐。

?先我們來看下?前在京東智聯云上已經提供的 Serverless 服務列表都分別有哪些：

• 在 16 年的 2 ?份，京東智聯云上線了對象存儲服務，第?個采? serverless 架構的云上系統；

• 在 18 年的 9 ?份，我們推出了 Faas 服務，是?款事件驅動的計算服務，通過函數服務，?戶?需配置和管理服務器等基礎設施，即可彈性、可靠地運?業務代碼，快速構建應?與服務，且只需為代碼實際消耗的資源付費；

• 在 18 年的 12 ?份，我們推出了 API ?關，提供API的全?命周期管理；?戶可通過 API ?關實現?身系統集成和服務聚合，還能便捷安全地開放其業務功能和數據，并實現與開發者或合作伙伴的連接；

• 在 19 年的 1 ?份，我們推出了隊列服務，是?款基于 serverless 架構的全托管消息隊列服務，它可以提供?可靠并且?乎?限擴展的托管消息隊列；

• 在 20 年的 1 ?份，我們推出了通知服務，是?款基于 serverless 架構實現發布訂閱模式的消息通知服務，提供了?可靠、?可?、可動態擴展的消息推送主題。

接下來詳細看下京東智聯云的 FaaS 服務技術架構圖。

中間粉?框起來的這部分屬于 Faas 的內部系統模塊；

• ?先我們來看下函數事件注冊流程，API 會接收從 web 端傳過來的事件注冊請求，將事件觸發條件等元數據信息存儲到 MySQL 關系型數據庫中，將函數的運?代碼存儲到 BaaS 服務，即 OSS 對象存儲服務中， 這樣就完成了事件注冊過程；

• 接著我們來看下函數事件的觸發流程，trigger 是?個主從?可?服務，當有外部的 event 發送事件到 trigger 的時候，如果是?個同步事件，會直接將事件發送給 dispatcher 服務，如果是異步事件，會先發送到 queue ??，再由 queue 將事件傳遞給 dispatcher 服務，dispatcher 會采?集群的 部署模式，dispatcher 會判斷當前 event 對應的函數代碼是否已經處于運?態，如果是，那么直接會調?container ??的函數代碼；否則會發送請求到 scheduler 服務。scheduler 是?個主從?可?服務，scheduler 服務會負責啟動?個 container 服務，在啟動 container 的過程中會從 oss 服務中拉取這個 event 對應的函數代碼并運?起來。

在整個系統中，trigger、dispatcher、scheduler 服務都會和 etcd 服務進?交互，通過 etcd 來確保數據的?致性以及進??些選主操作。

?前 FaaS 已經接?的事件源分別是 API ?關，OSS【對象存儲】，云事件（有點類似通知服務，可以定義事件源，?如是某?個資源的監控指標觸發了條件之后，會調? FaaS 服務），還有就是 JQS【隊列服務】；前三者事件采?主動推送的?式，JQS 的事件是通過 FaaS 主動去輪詢獲取的。FaaS 接收到 API ?關的事件會采?同步處理?式，其他三者會采?異步處理的?式。

在使?新技術前的第?步?先是了解新技術是?嘛的，接下來就是如何基于新技術對現有的業務進?改造。

下?，我們以?個簡單的單體應?為例，這是?個 B/S 類型的業務，Server 是?個單體應?，采? MVC 的架構，涵蓋了 HTML，JS，Service，Data Access ?個模塊，數據采? Database 進?存儲；除了 Database 之外，其他的服務都需要?開發和運維。

針對這個應?進? Serverless 化之后，就變成了這樣的架構，HTML，JS 的靜態?件通過 OSS 來進?存 儲，?戶認證采?單獨的 User Authentication 第三?服務，不再需要??開發單獨的 service 服務來處理?戶登錄認證問題；?其他業務邏輯就使? FaaS 來進?部署，通過 API Gateway 對外暴露，當瀏覽器觸發業務調?的時候，就會觸發相應的 FaaS 服務。通過 Serverless 化，真正需要開發的功能就只剩下 FaaS 的業務代碼?已了，相對傳統?式便捷了很多。

接下來，看看京東是如何使? Serverless 服務的。

案例?，是京?消息平臺，京?是京東給商家提供的?個?具服務市場，通過這個市場可以下載聊天?具， 訂單推送?具，運營分析?具等。下?這個圖是京?的消息平臺服務，會實時的將訂單、商品、售后等信息 通過加?處理之后，發送到京東智聯云的 JQS 當中，JQS是全托管的基于 Serverless 架構的消息隊列服務，相應的?具會從對應的 JQS 中獲取到相應的信息，并把相應的信息展示給對應的商家。由于消息源的消息量是動態變化的，所以對消息隊列的集群處理能?需求也是動態的，所以 JQS 很好的滿?了京?的訴求， 根據真實?量付費。

案例?，是京喜報警平臺，京喜是京東旗下以拼購業務為核?的社交電商平臺。當平臺服務有報警信息進?到消息隊列，會觸發對應的業務線的報警處理的 FaaS 服務，根據 MQ 中的報警內容，做出相應的響應事 件，可以是發短信，發郵件，或者是打電話。同時針對固定的報警邏輯，可以執?諸如重啟服務，清理數據等相關操作。

因為本身報警就不是常態，并且隨著業務的增加，如果有?個常駐服務來處理報警業務，這樣難免會照成資源浪費，采? FaaS 就可以很好的避免資源浪費的情況，當有報警產?的時候，再運?相應的服務來處理報警。

以上兩個是?較簡單的京東在使? Serverless 服務的場景，當然還有更多的復雜場景也會使?到。就像上?所講，Serverless 并?萬能，不能滿?所有場景的訴求，但是我還是依然很看好它的未來。

Serverless 的挑戰與未來

在未來的 Serverless 形態中，還是存在很多的挑戰需要去解決：

1. 新的 BaaS 服務，可以提供臨時和持久的存儲服務，這樣就可以避免購買常駐的存儲服務，從?降低相關費?的開銷

2. 在符合 Serverless 理念的情況下，降低服務間的調?開銷；對于?個線上的業務系統??，低延遲是永遠逃避不了的話題，如何采? Serverless 的情況下，?能滿?業務需求是 serverless ?規模使?的前提

3. 軟硬結合，提供更?的處理性能；針對在 FaaS 平臺上運?的特定語?代碼，在硬件層?進?相關的特殊優化，從?實現代碼運?加速，提?性能；

4. Serverless 技術的采?降低 IT ?出成本；真正的讓?家意識到 Serverless 的應?可以降低對 IT 的?出和投?；

5. 采? Serverless 可以更便捷、更快速的實現功能；通過周邊的?具，更?便的讓?戶使?serverless來構建業務系統，真正實現業務的迭代和創新速度

即使 Serverless 還是有那么多挑戰待解決，我對 Serverless 的未來依然充滿信息；?前在 CNCF 的serverless 版圖??有越來越多的 Serverless 服務加?了進來，相信隨著云原?的興起，Serverless 可以搭上這個趟?速的列?，順利起?。

我堅信，Serverless 未來可期！

看完上述內容是否對您有幫助呢？如果還想對相關知識有進一步的了解或閱讀更多相關文章，請關注億速云行業資訊頻道，感謝您對億速云的支持。