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记录机制、监控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解释，微服务的颗粒度越细，尽管有助提高弹性，但是，需要搭配一致的程式码架构和工具，透过标准化让工程师聚焦在业务问题，持续改善工具和功能，才能快速进行一系列的微幅迭代修改，来打破大型金融应用的复杂性，又能降低风险。

#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相关动态