巨人也能身手敏捷？看美國KeyBank的實戰經驗

Raffaele Spazzoli是紅帽PaaS和DevOps諮詢部架構師。本博文描述了他在加入紅帽之前為KeyBank提供服務的經驗。

將發布周期從三個月縮短到一星期的歷程。

這是超大型地區銀行KeyBank將每季度向生產環境部署縮短到每周部署的歷程。在這個過程中，我們全部採用開源軟體從WebSphere遷移到Tomcat，並使用OpenShift作為私有Linux容器雲平台。並且是在數字渠道現代化項目中做到這一點的，這是銀行在當時最重要的項目。

數字渠道現代化項目的範圍是遷移基於控制器、在本土MVC框架上開發，並在Java 1.6和WebSphere 7.x上已運行15年的Java web應用到更現代化的web環境，並創建一個新的移動Web應用。

該Web應用在維護和滿足我們SLA方面的花費越來越高。這是一種典型的大型應用。我們的架構目標是創建一個API層，用於將展示邏輯（Web或移動）與業務邏輯分離——這首先需要完全更新持續集成和部署流程。最初，我們的發布周期是每個季度。發布流程的費用高昂，任務艱巨。這是極高標準的發布流程（包含需要大約70個手工步驟完成的Excel電子表格），通常在周末進行，目的是系統在周一早上可以恢復上線，進行正常的業務處理。我們曾對此有信心，但結果並不好。

於是，我對大型企業（Google、Amazon、Facebook等）如何管理髮布流程進行了一些研究，而且幸運的是，我在參加一次會議聽到了Netflix介紹自己採用的方法。通過研究發現，這些企業的發布流程指標（頻率、成本、代碼完成到代碼部署到生產環境的時間）比我們大兩三個量級。我決定讓我們的交付組織從每季度發布改為每周發布。坦率地說，我對這個挑戰並沒有太認真地考慮，但這個目標已經在我心中形成。我認為，每周發布對於銀行的數字渠道非常合理。我在項目中的角色是解決方案架構師。我提出了一種新的架構，其中包含完全無狀態的REST服務層和兩個前端：基於AngularsJs的Web應用和基於Ionic框架的移動應用（基本上採用與Web應用相同的代碼）。目前，我們的計劃仍然是在WebSphere上運行這個新應用，因此，我開始要求運營團隊開展一系列變更。我要求對JDK進行更新（從版本6更新到版本7）。我需要更新的JDK，這樣才能利用JAX-RS編寫REST服務。起初，運營團隊不願意做出改變，然後，在認識到目前使用的JDK很快就會淘汰後，他們開始部署新的JDK。這個過程耗時6個月。我要求能夠使用Liberty作為應用伺服器。WebSphere在開發人員的筆記本電腦上啟動速度極慢，需要5-10分鐘，因此，由於即將開始實施的大項目，我們需要更敏捷、更快的解決方案。我得到的答覆是：我們可以在筆記本上使用Liberty，但生產環境唯一支持的應用伺服器是WebSphere。因此，我們在做這件事的時候感覺非常不舒服，原因是從直覺上來講，我們知道生產環境「走得更快」很重要，否則，在更高層的環境（IT、QA、生產）中更改堆棧的主要要素時，環境中會出現過多錯誤。我需要一種分布式緩存工具。之所以需要這種工具，是因為我希望我們的服務層完全無狀態（而且無會話），而且處於效率方面的考慮需要有緩存功能。我了解到的情況是，目前並沒有官方支持的分布式緩存平台，未來可能會有。這些情況（以及其他未提到的情況）讓我思考：我們顯然做錯了。開發團隊無法正確地表達自己的需求，運營團隊可能過於擔心業務中斷從而保持現狀，而我作為解決方案架構師夾在這兩個部門之間，可能無法展開很好的協作。我覺得需要徹底改變這種模式，並且摒棄交付團隊以前採用的複雜服務請求流程，改為由運營團隊交付基礎架構。另一個需要設立全新基礎架構的團隊曾經做過一項調查，結果發現，他們必須提出大約四百項申請。我認為交付團隊應該能夠自行配置其自己的基礎架構。最後得出結論，我需要私有雲基礎架構。於是，我決定自己進行研究，看哪種工具最適合我們。同時，一個小型運營團隊剛剛解決了一些非常棘手而且長期存在的網路問題，並接手了下一個難題，即在KeyBank構建私有雲。我們攜手合作，並且根據研究結果，確定Kubernetes是目前最好的基於容器的私有雲平台。我們採用基於虛擬機的雲平台沒有意義，因為我們明白容器從技術上來講優於虛擬機。我們尋找為Kubernetes提供專業支持的機構，最終發現紅帽及其OpenShift平台是極為可靠的選擇。隨後的事情進展很快。在與紅帽簽約後，我們進行了為期4個月的生產環境預覽，並且7個月內在首批客戶的生產環境中部署。我們將應用從WebSphere遷移到Tomcat，並且將REST引擎從Wink轉移到更受歡迎的（在WebSphere中無法運行）Jersey，同時新增了Hystrix，並實施了斷路器模式作為可用性戰略的組成部分。我們採用Redis實施分布式緩存。

技術方面永遠是最容易做到的。我們的目標仍然是每周發布，而且我們遵循的原則是：自行配置基礎架構和無法更改的基礎架構。為了實現目標，我們需要定義OpenShift中部署的應用的所有權和支持模式。事實上，如果開發團隊可以自行維護其基礎架構，那麼問題是：誰為其提供支持？通過考察Google、Netflix、Spotify的方式，我們採用的模式是由交付團隊負責其所需要的基礎架構（即在容器中添加的內容），而開發團隊的任務是保持OpenShift的可用性（很明顯，OpenShift對可用性的要求比其上運行的應用更高，這意味著銀行要達到接近100%的可用性）。為了保證所有權的明晰，我們決定將指定項目的OpenShift配置文件與其他項目源代碼放在一起。我們還需要通過持續交付渠道實現所有業務的自動化。

我們採用以下邏輯在Jenkins中建立了一個流程：

• 每十分鐘對源代碼庫輪詢一次，如果有變化，我們將觸發新的構建動作。

• 構建流程會運行單元測試和其他操作，以創建我們項目的Docker鏡像。該Docker鏡像此後不會變化。這是我們的不可變基礎架構的一個要點。

• 下一步是在解決方案的每一層以隔離方式運行一系列集成測試。隔離是指模擬對外依賴性。這樣，我們就能夠獨立於可用性而運行一系列測試，包括下游依賴關係和測試數據的質量。這些測試在臨時環境中運行（在OpenShift中相對較容易進行）。

• 接下來的步驟是在IT環境中運行一系列集成測試。

• 我們每天在QA環境中部署最後一個成功的構建版本。這個環境用於手動探索性測試和手動（目前如此）載入測試。

• 最後一步是在生產預覽環境中每周部署一次。這一步需要手動批准。

在生產環境中部署需要KeyBank的多次批准。這些批准以會議形式完成，即人們展示將部署的內容，而高級領導者簽署發布命令。這個過程不適合我們，因為我們沒有足夠的時間每周舉行三次會議（的確，這需要三個不同部門確信發布版本的合理性）。我們可以改變這樣的流程，並且同意：如果一個版本僅影響OpenShift內部的組件，我們就自動批准該版本的發布。我們需要的最後一塊是我們的自動化回歸測試套件的完全覆蓋。經歷幾次磨人的操作，我們很快認識到，如果不能做到完整的回顧測試覆蓋，我們就無法將發布速度提升到每周一次。實際上，手動測試團隊無法足夠快地每周對所有內容進行重新測試。我們採用一些行為驅動開發 (BDD) 原則構建了測試框架，並選擇Cucumber作為BDD工具。Cucumber的優點在於，它允許以自然語言（英語或其他語言）編寫測試案例。我們決定充分利用這個優點，並讓業務分析師團隊編寫測試例子。這樣，我們能夠同時開發業務代碼和測試代碼，而在以前，這兩項任務要依次進行，因此，測試（手動或自動）過程始終要測試舊版本的代碼。我們使用Selenium測試瀏覽器和瀏覽器應用操作系統的多種組合，並使用 Appium測試移動設備和移動應用操作系統的多種組合。結論現在，KeyBank對我們發布流程的信心有了很大提高，而且我們能夠在每個星期四早上發布。通過採用滾動部署——OpenShift的現成特性之一，我們可以進行零停機發布，這是我們長期以來的要求，而以前的解決方案都做不到這一點。我們還實現了自動擴展。我們在載入測試期間深入測試了這項特性，而且我們現在知道，我們的系統（或者至少是在OpenShift中部署的層）將通過橫向擴展，為管理當前負載部署正確數量的實例，從而應對負載峰值。這在銀行內部被認為是一個優秀的成功故事，而接下來的任務是將這些流程複製到其他項目中，將更多負載遷移到OpenShift。

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！