英國數字銀行Monzo兩位資深工程師Matt Heath和Suhail Patel在倫敦一場研討會上，分享瞭如何管理1600個後端微服務的經驗。這間設立超過5年的英國銀行，金融用戶超過了4百萬人，去年9月開始進軍美國市場，目前也正在開發企業用的數字銀行服務。
Monzo所有金融服務都是通過手機App提供，也因此，他們一開始就決定建立分佈式架構，而不是建立一套龐大的銀行核心系統。最初採用Mesos來建立容器集羣，在2016年時則全面換成了K8s，來打造了一個執行各種金融微服務的平臺。Monzo是少數很早就開始建立K8s的企業，也將基礎架構遷移到AWS平臺，來減少運維人力。
Monzo使用了容易水平擴展的NoSQL數據庫Cassandra，後端系統主要開發語言則是簡潔的Go，他們的理由是，這個語言保證向下相容，所以遇到語言改版時，例如有次新版增加了垃圾蒐集功能，原有代碼不用修改，直接用新版Go重新編譯後即可執行，就能使用新功能來提高記憶體管理效率。
這是一家喜歡自己開發工具的公司，若有需要連接第三方系統或支付平臺時，Monzo都儘可能自制開發整合機制，來提高效率，避免採用第三方整合工具，而帶進了許多額外不需要的代碼，例如他們就開發了一個互動工具，來連接AWS環境和K8s環境，讓開發者通過一個pull reques指令，就可以快速進行部署或恢復舊版部署。
在微服務設計上，Monzo將每一個微服務，都跑在一個Docker容器中。容器化微服務的代碼，還分爲兩層，一層是所有微服務都必須內置的共用核心代碼庫層（Shared Core Library Layer），包括了RPC、Cassandra、鎖定機制、Log記錄機制、監控Matrics、Queuing等六大類代碼庫，另一層則是業務層，也就是這支微服務要放進入的代碼。
Monzo拆分微服務顆粒度的原則是，進可能地拆解到越細小的程度，他們解釋，拆解得越細，可以將變動風險降到最低，例如更新單一功能，能減少對其他微服務的影響。但是，微服務顆粒度越小，代價是會產生大量的微服務。Monzo統計，第一年不過數百個微服務，但到了2019年11月初達到了1,500個微服務，甚至去年12月更暴增到1,600個已上。這些微服務間互相的不重複呼叫超過了9,300個。
因爲所有服務都在線上，Monzo希望儘可能落實零信任安全制度，因此，採取白名單方式來管控每一個微服務可呼叫的其他微服務名單。起初微服務數量不多時，這份白名單使用人工維護，但是數量達到數千，甚至近萬個時，維護工作非常複雜，因此，Monzo決定開發自動化維護工具。
習慣自己開發工具的Monzo先挑了安全管控最嚴格的一支微服務service.ledger來測試，利用K8s的網絡政策資源，在配置文件中建立一個呼叫白名單。這是一支負責跨帳戶移動金錢的微服務。
接着，Monzo開發了一個微服務通訊剖析rpcmap，可以自動分析每一支Go語言程式，找出對service.ledger微服務的所有呼叫來源，來建立白名單。
有了名單之後，Monzo下一步是利用K8s的NetworkPolicy資源來執行過濾，在service.ledger所屬的ledger服務配置文件中建立網絡政策，只有加上可允許標籤的網絡流量來源纔可以放行，並在ledger代碼目錄中，放入一份授權來源的白名單文件。一旦有其他開發團隊想要取得呼叫權限時，就得更新這個白名單文件，並且重新創建ledger服務（因爲代碼內的檔案有異動）後才能生效，ledger開發團隊在構建階段就可以審查這個新增的外部呼叫。
不過，測試後發現了幾個問題，多了不少人工審查呼叫的負擔，也會提高微服務回覆舊版本的風險，再加上開發團隊習慣手動編輯配置文件，每一個人都能修改呼叫白名單，而難以管控。後來Monzo決定導入開源的K8s網絡安控項目Calico，在每一個微服務上建立一個微型防火牆功能，來管理存取。另外，Monzo也大力提高微服務管理的信息透明度，如自制微服務剖析工具，方便開發團隊查詢每次代碼checkout後，微服務所用API的清單和狀態信息，並且大量採用視覺化監測工具來追蹤流量和用量。
除了工具面的管理機制，Monzo也製作了一份後端工程師101指南，要求開發團隊第一次撰寫後端程序就要開始遵循，內容從新服務建立，RPC處理程序導入、信息查詢、如和通過Firehose發佈和使用信息、如何撰寫單元測試，到如何部署，都有詳細的說明和規定，並提供了一個Slack頻道來討論這套後端應用規範的上手問題。Monzo要求，每一個開發成員都要遵守這個規範來開發後端的微服務。
Monzo解釋，微服務的顆粒度越細，儘管有助提高彈性，但是需要搭配一致的程序架構和工具，通過標準化讓工程師聚焦在業務問題，持續改善工具和功能，才能快速進行一系列的迭代修改，來打破大型金融應用的複雜性，又能降低風險。