Serverless 風格微服務的持續交付（上）：架構案例

時間 2019-11-10

原文原文鏈接

GitChat 做者：顧宇
原文：Serverless 風格微服務的持續交付（上）：架構案例
關注微信公衆號：「GitChat技術雜談」一本正經的講技術html

無服務器架構 (Serverless Architectures) 簡介

Serverless 架構最先能夠追溯到 Ken Fromm 發表的文章《Why The Future Of Software And Apps Is Serverless》。在這篇文章裏， Ken Fromm 描述了將來雲計算基礎設施成熟的條件下應用程序是不須要服務器端的。在無武器場景下構建應用程序的時候。開發人員和運維人員無需擔憂服務器如何安裝配置，如何設置網絡和負載均衡，無需監控狀態，甚至再也不會出現服務器相關的工做內容。這樣可讓本來建設機房的時間成本和貨幣成本從按年計算縮短至按秒計算。前端

在 Martin Fowler 的博客《Serverless Architectures》中，他將無服務器架構分爲兩種：java

第一種無服務器架構被稱爲被稱爲 __BaaS（Backend as a Service，後端應用即服務）__。即應用的架構是由一大堆第三方 API 來組織的。一切狀態和邏輯都由這些服務提供方來管理。隨着移動應用和單頁 Web 應用這樣的富客戶端（Rich Client）應用的普及，先後端的通訊漸漸以 API 調用爲主，而所需的服務再也不由服務端應用開發工程師和運維工程師來維護，只須要調用提供服務的第三方 API 就能夠完成相應的功能。例如雲上的數據庫服務和用戶認證服務。node

另外一種無服務器架構被稱爲 __FaaS（Function as a Service，函數即服務)__。這一架構的興起源於 AWS Lambda 的發展。 AWS Lambda 是一種無狀態的代碼運行時服務，這項服務提供最小的代碼運行資源。你可使用 Java，Node.js，Python 和 C# 編寫程序處理 AWS 各類服務的事件。無需初始化一臺服務器，安裝操做系統並配置程序運行環境。因爲運行資源不多，完成的計算有限，使得這種應用沒法保存狀態，所以這類程序以函數的方式存在。nginx

本文所介紹的 Serverless 架構主要是以 AWS Lambda 以及 Amazon API Gateway 架構的應用，它同時也具有 BaaS 的特徵。git

AWS Lambda 的編程模型

AWS Lambda 運行在一個假想的虛擬容器裏，但你沒法經過 API 配置這個容器。此外，這個虛擬的容器有一些資源限制，主要限制以下：數據庫

5 分鐘（300 秒）的程序運行時間。
512 MB 的文件系統空間。（在 /tmp 目錄下）
最大1536 MB 的內存。（最小 128 MB，以 64 MB 做爲增量）
最多 1024 個文件描述符。
最大 1024 個內部線程。

AWS Lambda 的編程模型以下所示：編程

Lambda 的執行流程：json

當事件觸發 Lambda 執行的時候，Lambda 會將事件所攜帶的信息經過上下文對象（Context Object）傳給處理函數（Handler）。此外，Lambda 還能夠讀取預先設置的環境變量。
執行處理函數，並將日誌經過 CloudWatch 記錄下來。
執行完畢後經過事件返回執行結果，或者拋出異常。
執行結果和對應的異常能夠綁定其它資源繼續處理。

當事件請求大批量發生的時候。Lambda 會爲每個事件單獨執行一次。這意味着每個請求之間的執行期間，內容是不能共享的。（經本人親測，內存中存儲的是能夠共享的，但內容保留的有效時間和狀態沒法保證。）後端

Amazon API Gateway + AWS Lambda 的微服務架構

根據 Martin Fowler 對微服務的描述性定義，咱們能夠認爲微服務從技術層面包含如下特徵：

每一個服務運行在本身的進程中。
服務間通訊採用輕量級通訊機制(一般用HTTP資源API)。
這些服務圍繞業務能力構建而且可經過全自動部署機制獨立部署。
這些服務共用一個最小型的集中式的管理。
服務可用不一樣的語言開發，使用不一樣的數據存儲技術。

在 AWS 現有的服務狀況下，AWS Lambda 知足了上面的第一、三、5 點，這只是一個微服務的處理單元，非管理單元。而 2 和 4 則須要另外的服務做爲管理單元共同構成微服務，這個任務通常交由 API 網關實現。

Amazon API Gateway 是一種徹底託管的 API 網關服務，能夠幫助開發者輕鬆建立、發佈、維護、監控和保護任意規模的 API。它集成了不少 API 網關的功能，諸如緩存、用戶認證等功能。而且支持經過 HAML 和 Swagger 配置，這樣就能夠用代碼管理系統配置 API 了。

Amazon API Gateway 能夠根據不一樣的 Restful API 訪問點將請求的數據傳遞給不一樣的資源進行處理。通常的 AWS API 架構以下所示：

當請求經過域名訪問到應用的時候，應用會將 HTTP 請求轉發給 CDN (CloudFornt)。
CloudFront 會根據轉發規則把對應的 API 請求轉發到 API Gateway 上。
API Gateway 會根據請求的訪問點和內容交給對應的 AWS Lambda 或者 EC2 服務處理，也能夠發送給其它可訪問的服務。
處理完成後將返回請求結果給客戶端。在返回的時候，API Gateway 也能夠經過 Lambda 對返回內容進行處理。

相較於傳統的微服務架構，經過 API Gateway 和 Lambda 的這種集成方式能夠獲得更輕量級的微服務。團隊只須要規劃好 API 訪問並完成函數的開發，就能夠快速的構建出一個最簡單的微服務，使得微服務基礎設施的搭建時間從幾周縮短爲幾個小時。此外，大大提高了微服務架構的開發效率和穩定性。

一次微服務架構的奇遇

2016年12月初，當時我正在以一名 DevOps 諮詢師的身份參與悉尼某一移動電話運營商的 Digital （電子渠道）部門的 DevOps 轉型項目。這個項目是提高該部門在 AWS （Amazon Web Services）雲計算平臺上的 DevOps 能力。

Digital 部門負責該電信運營商全部的互聯網和移動設備應用開發。這些應用主要是用來爲用戶提供諸如 SIM 卡激活，話費查詢，話費充值，優惠套餐訂購等自助服務（Self service），從而下降營業廳和人工話務客服的成本。

自助服務的應用系統基於 Ruby on Rails 框架開發，前端部分採用 AngularJS 1.0，可是沒有采用先後端分離的設計，頁面代碼仍然是經過 ERB 組合而成。yi移動端則採用 Cordova 開發。爲了下降開發難度和工做量，移動端的應用內容其實是把 AngularJS 所生成的 Web 頁面經過響應式樣式的方式嵌入到移動端。但由於常常超時，因此這款 APP 體驗並很差。

整套 Rails 應用部署在 AWS 上，而且經過網關和內部業務 BOSS （Business Operating Support System）系統隔離。BOSS 系統採用 SOAP 對外暴露服務，並由另一個部門負責。所以，雲上的應用所作的業務是給用戶展示一個使用友好的界面，並經過數據的轉化和內部 BOSS 系統進行交互。系統架構以下圖所示：

應用的交互流程以下

瀏覽器或者移動端經過域名（由 AWS Route 53託管）轉向 CDN（採用 AWS Cloudfront）。
CDN 根據請求的內容類別進行區分，靜態文件（圖片，JS，CSS 樣式等），會轉向 AWS S3 存儲。動態請求會直接發給負載均衡器（AWS Elastic Load Balancer）。
負載均衡器會根據各 EC2 計算實例的負載狀態將請求轉發到不一樣的實例上的 Ruby On Rails 應用上。每個應用都是一個典型的 MVC Web 應用。
EC2 上的應用會將一部分數據存儲在關係型數據服務(AWS RDS，Relational Database ServiceS）上，一部分存儲在本地文件裏。
通過應用的處理，轉換成 SOAP 請求經過網關發送給 BOSS 系統處理。BOSS 系統處理完成後會返回對應的消息。
根據業務的須要，一部分數據會採用 AWS ElasiCache 的 Redis 服務做爲緩存以優化業務響應速度。

團隊痛點

這個應用經歷了多年的開發，先後已經更換過不少技術人員。可是沒有人對這個應用代碼庫有完整的的認識。所以，咱們對整個團隊和產品進行了一次痛點總結：

組織結構方面

運維團隊成爲瓶頸，60 我的左右的開發團隊只有 4 名 Ops 支持。運維團隊除了平常的事務之外，還要給開發團隊提供各類支持。不少資源的使用權限被限制在這個團隊裏，就致使各類問題的解決進度進一步拖延。
隨着業務的增加，須要基礎設施代碼庫提供各類各樣的能力。然而 Ops 團隊的任何更改都會致使全部的開發團隊停下手頭的進度去修復更新所帶來的各類問題。

應用架構方面

應用架構並無達到先後端分離的效果，仍然須要同一個工程師編寫先後端代碼。這樣的技術棧對於對於開發人員的要求很高，然而市場上缺少合適的 RoR 工程師，致使維護成本進一步上升。通過了三個月，仍然很難招聘到合適的工程師。
多個團隊在一個代碼庫上工做，新舊功能之間存在各類依賴點。加上 Ruby 的語言特性，使得代碼中存在不少隱含的依賴點和類/方法覆蓋，致使了開發進度緩慢。咱們一共有 4 個團隊在一個代碼庫上工做，3個團隊在開發新的功能。1 個團隊須要修復 Bug 和清理技術債，這一切都要同時進行。

技術債方面

代碼庫中有大量的重複 cucumber 自動化測試，可是缺少正確的並行測試策略，致使自動化測試會隨機失敗，持續集成服務器（Jenkins）的 slave 節點本地難以建立，致使失敗緣由更加難以查找。若是走運的話，從提交代碼到新的版本發佈至少須要 45 分鐘。若是不走運的話，兩三天都沒法完成一次成功的構建，真是依靠人品構建。
基礎設施即代碼（Infrastructure As Code）創建在一個混合的遺留的 Ruby 代碼庫上。這個代碼庫用來封裝一些相似於 Packer 和 AWS CLI 這樣的命令行工具，包含一些 CloudFormation 的轉化能力。因爲缺少長期的規劃和編碼規範，加之人員變更十分頻繁，使得代碼庫難以維護。
此外，基礎設施代碼庫做爲一個 gem 和應用程序代碼庫耦合在一塊兒，運維團隊有惟一的維護權限。所以不少基礎設施上的問題開發團隊沒法解決，也不肯解決。

我參與過不少 Ruby 技術棧遺留系統的維護。在經歷了這些 Ruby 項目以後，我發現 Ruby 是一個開發起來很爽可是維護起來很痛苦的技術棧。大部分的維護更改是因爲 Ruby 的版本和 Gem 的版本更新致使的。此外，因爲 Ruby 比較靈活，人們都有本身的想法和使用習慣，所以代碼庫很難維護。

雖然團隊已經有比較好的持續交付流程，可是 Ops 能力缺少和應用架構帶來的侷限阻礙了整個產品的前進。所以，當務之急是可以經過 DevOps 提高團隊的 Ops 能力，緩解 Ops 資源不足，削弱 DevOps 矛盾。

DevOps 組織轉型中通常有兩種方法：一種方法是提高 Dev 的 Ops 能力，另外一種方法是下降 Ops 工做門檻。在時間資源很緊張的狀況下，經過技術的改進，下降 Ops 的門檻是短時間內收益最大的方法。

微服務觸發點：併購帶來的業務功能合併

在我加入這個項目的時候，客戶收購了一個本地的寬帶/固定電話運營商。所以原有的系統須要須要承載固話和寬帶的新業務。恰巧有個訂單查詢的業務須要讓當前的團隊完整這樣一個需求：經過現有的訂單查詢功能能夠同時查詢移動和固網寬帶訂單。

這要求在起因的訂單查詢功能上新增添一些選項和內容，能夠同時查到移動和固網寬帶的訂單。經過上述痛點可知，這在當時完成這樣一個任務的代價是十分昂貴的。

在開發的項目上進行 DevOps 轉型就像在行進的汽車上換車輪，一不留心就會讓全部團隊中止工做。所以我建議經過設立並行的新團隊來同時完成新功能的開發和 DevOps 轉型的試點。

這是一個功能拆分和新功能拆分需求，恰好訂單查詢是原系統中一個比較獨立和成熟的功能。爲了不影響原有各功能開發的進度。咱們決定採用微服務架構來完成這個功能。

構建微服務的架構的策略

咱們並不想重蹈以前應用架構的覆轍，咱們要作到先後端分離。使得比較小的開發團隊能夠並行開發，只要協商好了接口之間的契約（Contract），將來開發完成以後會很好集成。

這讓我想起了 Chris Richardson 提出了三種微服務架構策略，分別是：中止挖坑，先後端分離和提取微服務。

中止挖坑的意思是說：若是發現本身掉坑裏，立刻中止。

原先的單體應用對咱們來講就是一個焦油坑，所以咱們要中止在原來的代碼庫上繼續工做。而且爲新應用單首創建一個代碼庫。因此，咱們拆分策略模式以下所示：

在咱們的架構裏，實現新的需求就要變更老的應用。咱們的想法是：

構建出新的業務頁面，生成微服務契約。
根據 API 契約構建出新的微服務。
部署 Web 前端到 S3 上，採用 S3 的 Static Web Hosting （靜態 Web 服務）發佈。
部署後端微服務上線，並採用臨時的域名和 CDN 加載點進行測試。
經過更新 CDN 把原應用的流量導向新的微服務。
刪除舊的服務代碼。

咱們本來要在原有的應用上增長一個 API 用來訪問之前應用的邏輯。但想一想這實際上也是一種挖坑。在評估了業務的複雜性以後。咱們發現這個功能若是全新開發只須要 2人2周（一我的月）的時間，這僅僅佔咱們預估工做量的20%不到。所以咱們放棄了對遺留代碼動工的念頭。最終經過微服務直接訪問後臺系統，而不須要經過原有的應用。

在咱們拆微服務的部分十分簡單。對於後端來講說只須要修改 CDN 覆蓋原先的訪問源（Origin）以及保存在 route.rb 裏的原功能訪問點，就能夠完成微服務的集成。

構建出新的業務頁面，生成微服務契約

結合上面的應用痛點和思路，在構建微服務的技術選型時咱們肯定了如下方向：

前端框架要具有很好的 Responsive 擴展。
採用 Swagger 來描述 API 須要具有的行爲。
經過消費者驅動進行契約測試驅動微服務後端開發。
前端代碼庫和後端代碼庫分開。
前端代碼框架要對持續交付友好。

所以咱們選擇了 React 做爲前端技術棧而且用 yarn 管理依賴和任務。另一個緣由是咱們可以經過 React-native 爲將來構建新的應用作好準備。此外，咱們引入了 AWS SDK 的 nodejs 版本。用編寫一些常見的諸如構建、部署、配置等 AWS 相關的操做。而且經過 swagger 描述後端 API 的行爲。這樣，後端只須要知足這個 API 規範，就很容易作先後端集成。

部署前端部分到 S3 上

因爲 AWS S3 服務自帶 Static Web Hosting （靜態頁面服務）功能，這就大大減小了咱們構建基礎環境所花費的時間。若是你還想着用 Nginx 和 Apache 做爲靜態內容的 Web 服務器，那麼你還不夠 CloudNative。

雖然 AWS S3 服務曾經發生過故障，但 SLA 也比咱們本身構建的 EC2 實例處理靜態內容要強得多。此外還有如下優勢：

擁有獨立的 URL，很容易作不少 301 和 302 的重定向和改寫操做。
和 CDN （CloudFront）集成很好。
很容易和持續集成工具集成。
最大的優勢：比 EC2 便宜。

根據 API 契約構建出新的微服務

在構建微服務的最初，咱們當時有兩個選擇：

採用 Sinatra （一個用來構建 API 的 Ruby gem）構建一個微服務，這樣能夠複用原先 Rails 代碼庫的不少組件。換句話說，只須要 copy 一些代碼，放到一個單獨的代碼庫裏，就能夠完成功能。但也一樣會面臨以前 Ruby 技術棧帶來的種種問題。
採用 Spring Boot 構建一個微服務，Java 做爲成熟工程語言目前仍是最好的選擇，社區和實踐都很是成熟。能夠複用後臺不少用來作 SOAP 處理的 JAR 包。另外一方面是解決了 Ruby 技術棧帶來的問題。

然而，這兩個方案的都有一個共同的問題：須要經過 ruby 語言編寫的基礎設施工具構建一套運行微服務的基礎設施。而這個基礎設施的搭建，前先後後估計得須要至少 1個月，這仍是在運維團隊有人幫助的狀況下的樂觀估計。

因此，要找到一種下降環境構建和運維團隊阻塞的方式避開傳統的 EC2 搭建應用的方式。

這，只有 Lambda 能夠作到！

基於上面的種種考量，咱們選擇了 Amazon API Gateway + Lambda 的組合。而 Amazon API Gateway + Lambda 還有額外好處：

支持用 Swagger 規範配置 API Gateway。也就是說，你只要導入前端的 Swagger 規範，就能夠生成 API Gateway。
能夠用數據構建 Mock API，這樣就能夠很大程度上實現消費者驅動契約開發。
經過 Amazon API Gateway 的 Stage 功能，咱們無需構建 QA 環境，UAT 環境和 Staging 環境。只須要指定不一樣的 Stage，就能夠完成對應的切換。
Lambda 的發佈生效時間很短，反饋很快。原先用 CloudFormation 構建的 API 基礎設施須要至少 15 分鐘，而 Lambda 的生效只須要短短几秒鐘。
Lambda 的編寫很方便，能夠採用在線的方式。雖然在線 IDE 並不很好用，可是真的也寫不了幾行代碼。
Lambda 自動根據請求自擴展，無需考慮負載均衡。

雖然有這麼多優勢，但不能忽略了關鍵性的問題：AWS Lambda 不必定適合你的應用場景！

根據上文對 AWS Lambda 的介紹，支持 AWS Lambda 運行的資源和時間頗有限。所以不少對同步和強一致性的業務需求是沒法知足的。因此，AWS Lambda 更適合可以異步處理的業務場景。此外，AWS Lambda 對消耗存儲空間和 CPU 不少的場景支持不是很好，例如 AI 和大數據。（PS: AWS 已經有專門的 AI 和大數據服務了，因此不須要和本身過不去）

對於咱們的應用場景而言，上文中的 Ruby On Rails 應用中的主要功能（至少60% 以上）實際上只是一個數據轉換適配器：把前端輸入的數據進行加工，轉換成對應的 SOAP 調用。

所以，對於這樣一個簡單的場景而言，Amazon API Gateway + Lambda 徹底知足需求！

部署後端微服務

選擇了Amazon API Gateway + Lambda 後，後端的微服務部署看起來很簡單：

更新 Lambda 函數。
更新 API 規範，並要求 API 綁定對應 Lambda 函數處理請求。

可是，這卻不是很容易的一件事。咱們將在《Serverless 風格微服務的持續交付（中）：持續交付的挑戰》中對這方面踩過的坑詳細介紹。

把原應用的請求導向新的微服務

這時候在 CDN 上給新的微服務配置 API Gateway 做爲一個新的源（Origin），覆蓋原先寫在 route.rb 和 nginx.conf 裏的 API 訪問規則就能夠了。CDN 會攔截訪問請求，使得請求在 nginx 處理以前就會把對應的請求轉發到 API Gateway。

固然，若是你想作灰度發佈的話，就不能按上面這種方式搞了。CloudFront 和 ELB 負載均衡並不具有帶權轉發功能。所以你須要經過 nginx 配置，按訪問權重把 API Gateway 做爲一個 upstream 裏的一個 Server 就能夠。

刪除舊的服務代碼

不要留着無用的遺留代碼！

重要且最容易被忽略的事情要說三遍。斬草要除根，雖然咱們能夠保持代碼不動。可是清理再也不使用的遺留代碼和自動化測試能夠爲其它團隊減小不少沒必要要的工做量。

最終的架構

通過6我的兩個月的開發（原計劃8我的3個月），咱們的 Serverless 微服務最終落地了。固然這中間有 60% 的時間是在探索全新的技術棧。若是熟練的話，估計 4 我的一個月就能夠完成工做。

最後的架構以下圖所示：

在上圖中，請求仍然是先到 CDN （CloudFront），而後：

CDN 根據請求點的不一樣，把頁面請求轉發至 S3 ，把 API 請求轉發到 API Gateway。
前端的內容經過藍綠部署被放到了不一樣的 S3 Bucket 裏面，只須要改變 CDN 設置就能夠完成對應內容的部署。雖然對於部署來講藍綠 Bucket 乍看有一點多餘，但這是爲了可以在生產環境下作集成在線測試準備的。這樣可使環境不一致儘量少。
API Gateway 有本身做用的 VPC，很好的實現了網絡級別的隔離。
經過 API Gateway 轉發的 API 請求分紅了三類，每一類均可以根據請求情況自擴展：
- 身份驗證類：第一次訪問會請求 ElastCache（Redis），若是 Token 失效或者不存在，則從新走一遍用戶驗證流程。
- 數據請求類：數據請求類會經過 Lambda 訪問由其餘團隊開發的 Java 微服務，這類微服務是後臺系統惟一的訪問點。
- 操做審計類：請求會記錄到 DynamoDB （一種時間序列數據庫）中，用來跟蹤異步請求的各類日誌。
API Gateway 本身有一些緩存，能夠加速 API 的訪問。
消息返回後，再有三類不一樣的請求的結果統一經過 API Gateway 返回給客戶端。

Serverless 風格微服務架構的優勢

因爲沒有 EC2 設施初始化的時間，咱們減小了至少一個月的工做量，分別是：

初始化網絡配置的時間。
構建 EC2 配置的時間。
構建反向代理和前端靜態內容服務器的時間。
構建後端 API 應用基礎設施的時間。
構建負載均衡的時間。
把上述內容用 Ruby 進行基礎設施即代碼化的時間。

若是要把 API Gateway 算做是基礎設施初始化的時間來看。第一次初始化 API Gateway 用了一天，之後 API Gateway 結合持續交付流程每次修改僅僅須要幾分鐘。

不管怎麼說，Serverless 大大下降了基礎設施配置和運維門檻。

此外，對於團隊來講，Amazon API Gateway + Lambda 的微服務還帶來其它好處：

開發效率高，原先至少 45 分鐘的開發反饋週期縮短爲 5 分鐘之內。
無關的代碼量少，須要維護的代碼量少。除了專一業務自己。上游和 API Gateway 的集成以及下游和後端服務的集成代碼量不多。
應用維護成本低。代碼僅僅幾十行，且都爲函數式，很容易測試。避免了代碼庫內部複雜性的增長。

此外，咱們作了 Java 和 NodeJs 比較。在開發一樣的功能下，NodeJS 的開發效率更高，緣由是 Java 要把請求的 json 轉化爲對象，也要把返回的 json 轉化爲對象，而不像 nodejs 直接處理 json。此外， Java 須要引入一些其它 JAR 包做爲依賴。在 AWS 場景下開發一樣一個函數式微服務，nodejs 有 4 倍於 java 的開發效率提高。