Monzo是一家倫敦數字銀行，它們是如何在1600種微服務上執行其銀行系統？

Monzo對可擴充套件，可擴充套件，有彈性和安全的技術平臺的要求。最初的想法是從一些基本的銀行服務開始，然後在時間和資源允許的情況下新增更多服務。

Monzo在早期就確信分散式系統的價值。銀行不希望有一個具有複雜故障轉移功能的單點的、大型彈性系統，這是維護人員DevOps永遠不希望的。

但是，如果不使用那些故障轉移模式，怎麼確保它們可靠地工作？Monzo開始從Mesos實現叢集管理，但到2016年，他們轉而使用Kubernetes（K8s）作為“新興市場領導者”。

目標之一是抽象化基礎架構的複雜性。

基礎架構擴充套件的所有複雜性，確保提供服務和資料庫可用的問題，應該由特定的團隊處理，以便工程師可以專注於產品。

K8s並非一帆風順。在2017年，Monzo由於K8s的問題以及它與etcd和linkerd的互動作用而導致的故障很大，這是由於各種錯誤的組合，這些bug很難測試。

Monzo之所以選擇Cassandra作為資料庫是因為它可以水平擴充套件（這意味著您只需新增更多硬體即可擴充套件，而不必遷移到更大的系統）。

在編碼方面：將Go用作主要的程式語言，它是靜態型別的，很容易就可以招募人員。 Go具有向後相容性保證，這意味著當出現一個新版本時，您可以簡單地重新編譯現有程式碼，從而獲得更新諸如垃圾收集器等功能的好處。Go也非常適合有關錯誤處理的嚴格策略。

銀行系統非常適合模組化方法。需要連結到許多不同的系統，例如BACS，CHAPS，Visa，萬事達卡，Apple Pay和Google Pay。將這些東西設計為單獨的微服務系統，能夠使它們更簡單。Monzo儘可能在內部構建整合，而不是使用第三方實現，以更好地控制彈性和效能（並且從長遠來看還可以節省金錢）。他們甚至建立了自己的聊天系統，供內部使用和獲得支援。

Monzo還構建了自己的工具來與AWS和K8進行互動，例如一個名為Shipper的工具，可以部署或回滾單個服務。託運人可以直接從拉取請求進行部署，這是對Git儲存庫中維護的程式碼的更新。

每個Monzo微服務都在Docker容器中執行。但是有一個共享的核心庫，每個服務都可用。儘管構建過程會刪除未使用的程式碼，但實際上將其複製到每個容器中。這意味著工程師不會重寫諸如資料編組之類的核心抽象。它還為每項服務啟用指標，以便在部署後立即將其顯示在儀表板中，並分析CPU使用率，網路呼叫等。自動警報將識別降級的服務。

每個服務公開的介面或API都有很多想法。團隊傾向於編寫許多小型服務，每個小型服務都專用於一個目的，而不是減少複雜的服務。這是希望將變更的風險降到最低。例如，如果想改變非接觸式支付的工作方式，就不會影響晶片和PIN系統。

鑑於無法在膝上型電腦上執行1,600個微服務，開發人員如何處理其程式碼？只要正在執行一個子集。有一個RPC過濾器，可以檢測到您正在嘗試向當前未執行的下游傳送請求，它可以編譯，啟動它，然後將請求傳送給它。

為什麼微服務在Monzo能正常工作，而在某些情況下卻增加了複雜性卻沒有帶來太多收益？開發人員在團隊（以及與管理層）之間進行互動的方式比他們所支援的任何開發方法都更為重要。另一個是漸進式方法可以勝過偶爾的大更改。迭代過程通常是在Monzo所關心的，無論是從基礎架構角度還是從產品角度來看。通過經常進行小的更改，可以確保朝著正確的方向發展。

簡單性勝於複雜性。總體而言，Monzo的系統工作非常複雜，但是它的系統設計方式是將這種複雜性劃分為更小，更簡單的部分，並將其抽象給從事程式碼工作的開發人員。開發人員不需要知道1,600種服務的工作方式。管理K8的艱鉅任務委託給專家。

Monzo還標準化了“一小部分技術選擇”，以便“作為一個整體，我們可以共同改進那些工具”。這對於具有不同技術偏好的開發人員可能會令人沮喪，但是由於每個人都學習相同的工具集，因此必須在協作方面提供實質性幫助。優化程式碼以提高可讀性。Monzo工程原理之一是不優化[效能]，除非它成為瓶頸。

如果您擁有包含許多元件的複雜系統，並且需要能夠在需求變化或功能新增時迅速做出響應，那麼Monzo展示的內容似乎是軟體開發和部署的強大模板。

但是請注意，Monzo使用了許多不容易複製的自定義內部工具和庫。此外，他們提出的許多原理（例如編寫清晰，可讀和規範的程式碼，專注於精心選擇的一些技術並採用漸進方法）在任何軟體體系結構中都是贏家。