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


Advertisement

更多 iThome相關內容