Container周報第123期：1,600個微服務怎麼管？英國當紅網銀Monzo秘訣大公開

3/1~3/13 精選容器新聞：微服務管理實例

#微服務管理,#數位銀行
如何在K8s管理1600個微服務？英國當紅數位銀行秘訣大公開

日前，英國數位銀行Monzo兩位資深工程師Matt Heath和Suhail Patel在倫敦一場研討會上，揭露了如何管理1,600個後端微服務的經驗。這間設立超過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記錄機制、監控Metrics、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解釋，微服務的顆粒度越細，儘管有助提高彈性，但是，需要搭配一致的程式碼架構和工具，透過標準化讓工程師聚焦在業務問題，持續改善工具和功能，才能快速進行一系列的微幅迭代修改，來打破大型金融應用的複雜性，又能降低風險。

#Docker,#雲端部署
戰略轉向AP部署和派送流程，Docker公開未來產品藍圖

Docker在自家部落格說明了未來營運新戰略藍圖，將會花更多的資源強化開發體驗，使開發人員可以更方便地讓程式碼，部署到多雲應用程式Runtime中。Docker將進一步發展基礎Docker工具、Docker Desktop以及Docker Hub來加速這個過程，除了改善Docker Desktop的開發體驗，並與生態系合作，且使Docker Hub能夠整合、配置和管理，建構應用程式和微服務所需要的應用程式元件。Docker Hub將不只是一個註冊表服務，而將會成為工具生態系中心，Docker Hub會提供各種工作管線選項，範疇從抽象功能到讓開發者自己從頭打造的元件都有。

#GCP,#Istio,#Envoy
微服務平臺Istio大力擁抱WebAssembly，1.5新版推出全新套件擴充模式

開源微服務平臺Istio是Google混合雲平臺Anthos的核心套件之一，最近釋出了1.5新版，最大特色是推出了新的擴充套件模式，可以讓開發者使用WebAssembly檔案，快速透過Istio內的Envoy proxy來發布或執行程式碼，整合到遠端環境中，也可整合政策管理系統、路由控管機制，甚至修改派送的訊息內容。官方指出，這個新模式可以讓開發者更彈性地將一個複合式的元件，先各自分開執行初始元件再組合。另外，命令列工具istioctl增加了十多項改善，因此進入Beta測試版，而安裝管理機制則仍舊在alpha測試版中，預計將發展成一個功能更完整的維運工具API。另外，在安全強化上，資安政策工具Auto mTlS也進入測試版本，可以支援否定語法，來強制某些控制機制的政策不會被覆蓋而出錯。在透明度上，Telemetry第二則新增加原始TCP連線的監控支援。

#VMware,#K8s
K8s重新改造的新版vSphere 7正式發布，5月正式上市

VMware在3年前開始投入K8s技術開發，甚至找來，兩位K8s創辦人加入VMware，全新的K8s產品線Tanzu和改用K8s重新設計的新版vSphere 7終於亮相，VMware在vSphere底層放入了一套K8s，提供了一個底層K8s超級節點，可以同時執行VM和K8s容器化應用，也能直接在虛擬層上提供K8s叢集。VMware執行長Pat Gelsinger直言，這是vMotion問世以來，最重要的虛擬化技術變革。Tanzu產品線則要用來管理和串接，各種不同環境的K8s，公有雲、私有雲、第三方版本等，來提供一個統一的K8s部署和管理介面。開源的Tanzu元件先釋出正式版，而vSphere 7新版則預定在今年5月1日正式上市。

#Ansibl,#DevOps
擔心疫情失業潮，知名K8s DevOps工具書一個月免費要讓工程師自學

擔心武漢肺炎疫情重創科技業，恐出線工程師失業潮，知名軟體工具書Ansible DevOps作者Jeff Geerling最近決定，將自己兩本熱門工具書，免費提供下載1個月，讓工程師可以自修來強化自己的能力。他在LeanPub電子書初版平臺上，提供《Ansible for DevOps》和《Ansible for Kubernetes》這兩本書，訂購者可自訂要購買的價格，到最低的0元。

#機器學習,#Kubeflow
開發、訓練到部署一套搞定，K8s機器學習工具包Kubeflow終於有正式版

超過2年開發，開源的K8s機器學習版終於釋出了第一個正式版本。Kubeflow原本稱為TensorFlow Extended，是Google內部用來部署TensorFlow模型到Kubernetes的方法。在2017年底在美國Kubecon中對外開源，之後專案便蓬勃發展，現在有來自30個組織上百位的貢獻者，參與Kubeflow專案的開發。Kubeflow 1.0提供了一組穩定版本的應用程式，提高開發者在Kubernetes上進行開發、建置、訓練和部署模型的效率。包括Kubeflow的使用者介面Central Dashboard以及Jupyter筆記本控制器，還有用於分散式訓練的Tensorflow和PyTorch運算子，同時也提供管理多重使用者的配置文件管理器，和部署升級工具kfctl。

#容器OS,#Bottlerocket
AWS自製容器專用OS，配置異動和搬遷都能靠API

AWS推出專門為容器主機最佳化的Linux作業系統Bottlerocket，包含容器主機所需要的元件，並且整合了現有容器調度工具，支援Docker映像檔以及OCI（Open Container Initiative）格式的映像檔。特別之處在於其更新以及API設計上，用戶可以利用呼叫API來調整配置，而不需要手動更改，並且這些更改還可以在更新時自動搬遷。Bottlerocket不使用套件更新系統，而是使用基於映像檔的更新模型，這個模型在必要時可以快速且完整的回退，Bottlerocket中幾乎所有的地方元件，都是以Rust開發而成，而Rust能夠消除某些類型的記憶體安全性問題，並且使開發者以較安全的模式開發程式。

責任編輯／王宏仁

更多Container相關動態

• GitHub買下Node.js套件管理器Npm
• 微軟釋出VS Code Docker擴充套件1.0