從去年開始，我們公司開始舉辦黑客馬拉松。 第一屆這樣的比賽非常成功，我們在 。 第二屆黑客馬拉松於 2019 年 XNUMX 月舉行，同樣取得了成功。 關於不久前舉辦後者的目標 組織者。
參與者被賦予了一項相當有趣的任務，可以完全自由地選擇實施的技術堆疊。 有必要實現一個決策平台，以便方便地部署客戶評分功能，能夠與快速的應用程式一起工作，承受重負載，並且系統本身易於擴展。
這項任務並不簡單，可以透過多種方式解決，正如我們在演示參與者專案的最終演示時所確信的那樣。 這次黑客馬拉鬆有6個團隊，每組5人，所有參與者都有很好的項目，但我們的平台是最具競爭力的。 我們有一個非常有趣的項目，我想在這篇文章中討論它。
我們的解決方案是基於 Kubernetes 內部無伺服器架構的平台，這減少了將新功能引入生產所需的時間。 它允許分析師在方便的環境中編寫程式碼並將其部署到生產中，而無需工程師和開發人員的參與。
什麼是得分
Tinkoff.ru 與許多現代公司一樣，有客戶評分。 評分是一種基於數據分析統計方法的客戶評估系統。
例如，客戶向我們要求向他發放貸款，或在我們這裡開設個人企業家帳戶。 如果我們打算向他發放貸款，那麼我們需要評估他的償付能力，如果該帳戶是個體工商戶，那麼我們需要確保客戶不會進行詐欺交易。
做出此類決策的基礎是數學模型，該模型可以分析應用程式本身的資料和我們儲存中的資料。 除了評分之外，類似的統計方法也可以用於為我們的客戶產生新產品的個人化推薦。
這種評估方法可以接受多種輸入資料。 在某些時候，我們可以在輸入中新增一個參數，根據歷史資料的分析結果，這將提高使用服務的轉換率。
我們擁有大量有關客戶關係的數據，而這些資訊的數量正在不斷增長。 為了進行評分，資料處理還需要規則（或數學模型），使您能夠快速決定誰批准申請、拒絕誰以及向誰提供更多產品，從而評估他們的潛在興趣。
對於手邊的任務，我們已經使用了專門的決策系統 ，根據分析師、技術人員和開發人員制定的規則，決定是否批准或拒絕向客戶提供特定的銀行產品。
市場上有許多現成的解決方案，包括評分模型和決策系統本身。 我們在我們公司使用其中一個系統。 但業務正在成長、多元化，客戶數量和提供的產品數量都在增加，隨之而來的是如何改善現有決策流程的想法不斷湧現。 當然，使用現有系統的人們對於如何使其更簡單、更好、更方便有很多想法，但有時來自外部的想法是有用的。 新黑客馬拉鬆的組織目的是收集合理的想法。
任務
黑客馬拉松於 23 月 XNUMX 日舉行。 參與者面臨一項戰鬥任務：發展一個必須滿足許多條件的決策系統。
我們被告知現有的系統如何運作，運作過程中會遇到哪些困難，以及開發的平台應該追求什麼業務目標。 該系統必須具有快速的上市時間來開發規則，以便分析師的工作程式碼盡快投入生產。 而對於應用程式的傳入流量，決策時間應該趨於最短。 此外，正在開發的系統必須具有交叉銷售功能，以便客戶有機會購買其他公司的產品（如果這些產品得到我們的批准並且客戶有潛在興趣）。
顯然，不可能在一夜之間寫出一個可以立即發布並投入生產的項目，並且覆蓋整個系統也相當困難，因此我們被要求至少實現其中的一部分。 制定了原型必須滿足的許多要求。 可以嘗試既全面涵蓋所有要求，又詳細研究正在開發的平台的各個部分。
至於技術，所有參與者都有完全的選擇自由。 可以使用任何概念和技術：資料流、機器學習、事件溯源、大數據等。
我們的方案
經過一番集思廣益後，我們認為 FaaS 解決方案是完成任務的理想選擇。
對於這個解決方案，需要找到一個合適的Serverless框架來實現正在開發的決策系統的規則。 由於 Tinkoff 積極使用 Kubernetes 進行基礎設施管理，因此我們研究了幾個基於它的現成解決方案；稍後我將向您詳細介紹。
為了找到最有效的解決方案，我們從使用者的角度審視正在開發的產品。 我們系統的主要使用者是參與規則開發的分析師。 規則必須部署到伺服器，或者像我們的例子一樣，部署在雲端，以便後續決策。 從分析師的角度來看，工作流程如下所示：
- 分析師根據倉庫中的資料編寫腳本、規則或 ML 模型。 作為黑客馬拉鬆的一部分，我們決定使用 Mongodb，但資料儲存系統的選擇在這裡並不重要。
- 在對歷史資料測試開發的規則後，分析師將其程式碼上傳到管理面板。
- 為了確保版本控制，所有程式碼都將轉到 Git 儲存庫。
- 透過管理面板，可以將程式碼作為單獨的功能無伺服器模組部署在雲端。
來自客戶端的初始資料必須通過專門的豐富服務，該服務旨在使用倉庫中的資料豐富初始請求。 以這樣的方式實現該服務非常重要，即它可以與單一儲存庫（分析師在開發規則時從中獲取資料）一起工作以維護統一的資料結構。
甚至在黑客馬拉松之前，我們就決定了要使用的無伺服器框架。 如今，市場上有許多技術都實現了這種方法。 Kubernetes 架構中最受歡迎的解決方案是 Fission、Open FaaS 和 Kubeless。 甚至還有 .
在權衡了所有的利弊後，我們選擇了 。 這個無伺服器框架非常易於管理並且滿足任務的要求。
要使用 Fission，您需要了解兩個基本概念：功能和環境。 函數是用存在 Fission 環境的語言之一編寫的一段程式碼。 包括Python、JS、Go、JVM等多種流行語言和技術。
Fission 還能夠執行分為多個檔案的功能，並預先打包到檔案中。 Fission 在 Kubernetes 叢集中的運作是由專門的 Pod 來保證的，這些 Pod 由框架本身管理。 若要與叢集 Pod 交互，必須為每個函數指派自己的路由，並且您可以向其傳遞 GET 參數或請求正文（如果是 POST 請求）。
因此，我們計劃獲得一種解決方案，允許分析師在沒有工程師和開發人員參與的情況下部署開發的規則腳本。 所描述的方法還消除了開發人員將分析程式碼重寫為另一種語言的需要。 例如，我們現在使用的決策系統，需要用高度專業化的技術和語言來編寫規則，其範圍極其有限，而且對應用伺服器也有很強的依賴性，因為所有匯票銀行規則部署在單一環境中。 因此，要部署新規則就必須發佈整個系統。
在我們提出的解決方案中，無需發布規則；只需單擊按鈕即可輕鬆部署程式碼。 此外，Kubernetes 中的基礎架構管理讓您無需考慮負載和擴充；這些問題都可以立即解決。 並且使用單一資料倉儲無需將即時資料與歷史資料進行比較，從而簡化了分析師的工作。
我們得到了什麼
由於我們帶著現成的解決方案（在我們的幻想中）來到黑客馬拉松，我們所要做的就是將所有想法轉化為程式碼行。
任何黑客馬拉鬆成功的關鍵是準備和精心編寫的計劃。 因此，我們做的第一件事就是決定我們的系統架構將包含哪些模組以及我們將使用哪些技術。
我們專案的架構如下：
此圖顯示了兩個入口點：分析師（我們系統的主要使用者）和客戶。
工作流程的架構如下。 分析師為其模型開發規則功能和資料豐富功能，將其程式碼儲存在 Git 儲存庫中，並透過管理員應用程式將其模型部署到雲端。 讓我們考慮如何呼叫已部署的函數並對來自客戶端的傳入請求做出決策：
- 客戶在網站上填寫表格並將其請求發送給控制者。 需要做出決策的應用程式進入系統輸入並以其原始形式記錄在資料庫中。
- 接下來，如有必要，將發送原始請求以進行豐富。 您可以使用來自外部服務和儲存的資料來補充初始請求。 產生的豐富查詢也儲存在資料庫中。
- 分析函數啟動，它將豐富的查詢作為輸入並產生解決方案，該解決方案也寫入儲存。
我們決定使用 MongoDB 作為我們系統中的存儲，因為資料以 JSON 文件的形式面向文件存儲，因為豐富服務（包括原始請求）透過 REST 控制器聚合了所有資料。
因此，我們有 XNUMX 小時的時間來實施該平台。 我們非常成功地分配了角色；每個團隊成員在我們的專案中都有自己的職責範圍：
- 分析師工作的前端管理面板，透過該面板，他可以從書面腳本的版本控制系統下載規則，選擇豐富輸入資料的選項並在線上編輯規則腳本。
- 後端管理，包括前端的 REST API 以及與 VCS 的整合。
- 在 Google Cloud 中設定基礎架構並開發用於豐富來源資料的服務。
- 用於將管理應用程式與無伺服器框架整合以進行後續規則部署的模組。
- 用於測試整個系統效能的規則腳本以及對傳入應用程式（做出的決策）的分析聚合以進行最終演示。
讓我們按順序開始吧。
我們的前端是使用銀行 UI 工具包用 Angular 7 編寫的。 管理面板的最終版本如下所示：
由於時間有限，我們嘗試只實現關鍵功能。 在Kubernetes叢集中部署某個功能，需要選擇一個事件（需要在雲端部署規則的服務）以及實作決策邏輯的功能程式碼。 對於所選服務的每次規則部署，我們都會編寫此事件的日誌。 在管理面板中您可以看到所有事件的日誌。
所有功能程式碼都儲存在遠端 Git 儲存庫中，該儲存庫也必須在管理面板中設定。 為了對程式碼進行版本控制，所有函數都儲存在儲存庫的不同分支中。 管理面板還提供了對編寫的腳本進行調整的功能，以便在將功能部署到生產之前，您不僅可以檢查編寫的程式碼，還可以進行必要的變更。
除了規則功能之外，我們還實現了使用Enrichment函數逐步豐富來源資料的能力，其程式碼也是腳本，可以進入資料倉儲，呼叫第三方服務並進行初步計算。 為了展示我們的解決方案，我們計算了留下請求的客戶的星座，並使用第三方 REST 服務確定了他的行動電信商。
該平台的後端是用 Java 編寫的，並作為 Spring Boot 應用程式實作。 我們最初計劃使用 Postgres 來儲存管理數據，但是，作為黑客馬拉鬆的一部分，我們決定將自己限制為簡單的 H2 以節省時間。 在後端，實現了與 Bitbucket 的集成，以對查詢豐富函數和規則腳本進行版本控制。 為了與遠端 Git 儲存庫集成，我們使用 ，它是 CLI 命令的一種包裝器，可讓您使用方便的軟體介面執行任何 git 指令。 因此，我們有兩個單獨的儲存庫來豐富函數和規則，並且所有腳本都分為不同的目錄。 透過 UI，可以選擇儲存庫任意分支的腳本的最新提交。 透過管理面板變更程式碼時，已在遠端儲存庫中建立更改程式碼的提交。
為了實現我們的想法，我們需要合適的基礎設施。 我們決定在雲端部署 Kubernetes 叢集。 我們的選擇是谷歌雲端平台。 Fission 無伺服器框架安裝在 Kubernetes 叢集上，我們將其部署在 Gcloud 中。 最初，來源資料豐富服務是作為包裝在 k8s 叢集內 Pod 中的單獨 Java 應用程式實現的。 但在黑客馬拉松中對我們的專案進行了初步演示後，建議我們使豐富服務更加靈活，以提供選擇如何豐富傳入應用程式的原始資料的機會。 我們別無選擇，只能將豐富服務也變成無伺服器。
為了使用 Fission，我們使用了 Fission CLI，它必須安裝在 Kubernetes CLI 之上。 將功能部署到 k8s 叢集非常簡單；您只需為該功能指派內部路由和入口，以便在需要存取叢集外部時允許傳入流量。 部署一項功能通常不超過 10 秒。
項目的最終陳述和總結
為了演示我們的系統如何運作，我們在遠端伺服器上放置了一個簡單的表格，您可以在其中提交銀行產品之一的申請。 若要提出請求，您必須輸入姓名縮寫、出生日期和電話號碼。
來自客戶端表單的資料傳送到控制器，控制器同時發送對所有可用規則的請求，之前根據指定條件豐富了數據，並將它們保存在公共儲存中。 總的來說，我們部署了三個對傳入應用程式做出決策的功能和 4 個資料豐富服務。 提交申請後，客戶收到了我們的決定：
除了拒絕或批准之外，客戶還收到了我們同時發送的其他產品和請求的清單。 這就是我們展示平台交叉銷售可能性的方式。
共有 3 種虛擬銀行產品可供選擇：
- 信用。
- 玩具
- 抵押。
在演示過程中，我們為每個服務部署了準備好的函數和豐富腳本。
每個規則都需要自己的一組輸入資料。 因此，為了批准抵押貸款，我們計算了客戶的星座，並將其與農曆的邏輯聯繫起來。 為了批准玩具，我們檢查客戶是否已達到成年年齡；為了發放貸款，我們向外部開放服務發送請求以確定蜂窩運營商，並做出決定。
我們試圖讓我們的演示變得有趣和互動，每個在場的人都可以進入我們的表格並檢查我們虛構的服務對他們的可用性。 在演示的最後，我們演示了對收到的申請的分析，其中顯示了有多少人使用我們的服務、批准和拒絕的數量。
為了在線上收集分析結果，我們也部署了開源 BI 工具 並將其擰到我們的存儲單元上。 Metabase 允許您建立對我們感興趣的資料進行分析的畫面；您只需註冊到資料庫的連接，選擇表格（在我們的範例中，資料集合，因為我們使用 MongoDB），並指定我們感興趣的欄位。
這樣我們就得到了一個很好的決策平台原型，並且在演示過程中，每個聽眾都可以親自檢查它的表現。 儘管來自其他團隊的激烈競爭，有趣的解決方案、完成的原型和成功的演示使我們獲勝。 我相信每個團隊的專案也可以寫一篇有趣的文章。
來源： www.habr.com