金融行业容器平台落地路径：敏捷响应业务更迭

演讲中，盛延敏主要围绕着蚂蚁金服容器平台的双模容器落地路径，所能够提供的金融级云原生能力，以及所经历的实际严苛场景验证三个方面，分享了蚂蚁金服容器平台如何帮助企业实现敏捷响应业务更迭。
在这里插入图片描述
盛延敏蚂蚁金服高级技术专家

基础设施架构变革正彻底改变业务应用的交付模式

首先来回顾一下软件行业交付模式的演变历史。对于交付模式而言，最早大家比较关心IaaS层面的内容，以OpenStack、KVM或者VMWare等为代表的技术大行其道，这个阶段大家比较关心虚拟机，无论是应用还是分布式中间件，基本都是通过虚拟机来搭建和运维。随着技术的进步，通过应用无状态化以及运维自动化的技术升级，软件交付来到了一个新时代。这个时代，大家所关注的中心上移到了PaaS领域，此时应用开发者重点关注自己所开发的应用，我们可以称之为Cloud-Ready时代，这个阶段中，无论是分布式应用、所使用的语言环境还是运维和监控，都统一地托管在PaaS平台之上的。在Cloud-Ready时代，如果想要支持多语言和多框架，就要提供语言和框架的技术规范化体系，例如buildpack。技术再向前发展，到了2013年，2014年左右，一家叫做Docker的公司走向了历史舞台，它将cgroup和namespace等技术实现了极致的产品化，创造性地提出了Docker image方式，此时软件交付的方式，应用程序本身和语言、技术栈以及框架紧密地耦合在一起了，此时就进入了CaaS时代，我们可以称之为Cloud-Native的时代。在这个时代，无论是对于中间件还是微服务，完全都可以通过云原生的方式来实现，这就带来了架构、效率和运维体验的极致提升。
在这里插入图片描述

基于容器技术的“云原生”已成为事实标准

一直以来，容器技术所标榜的就是通过“集装箱”方式进行交付。将软件和产品打包成为标准化的镜像，而镜像就像是集装箱一样，可以帮助我们将软件托运到任何地方、任何环境，并通过一键拉起实现部署。现在，无论是技术社区、开发者还是云服务提供商，都在积极地拥抱和倡导基于容器技术的“云原生”时代。
在这里插入图片描述
CNCF云原生计算基金会在2018年的调查显示“云原生生产环境应用增长200%，社区关注度和评估量增长近3倍”。当然，各个组织的关注点可能不同，但是却集中在技术可用性以及生产效率的提升上。这里以Kubernetes和Docker为代表的云原生技术的关注度在下图中也得到了非常明显的体现。
在这里插入图片描述
当谈到云原生的时候，大家不禁要问什么是云原生呢？是Kubernetes还是Docker？还是OCR的标准？CNCF组织给云原生定义了一套标准，而这套标准也在不断实践和打磨，在2018年他们也推出了一个新版本，主要包括了五种技术基石和三种云形态支持。这五中技术基石分别是容器、服务网络、微服务、不可变基础设施以及声明式API，三种云形态则包括公共云、混合云以及专有云。
在这里插入图片描述
这里需要强调的是声明式API，这是云原生时代与之前时代所不同的重要理念。在过去，无论是运维还是发布，都习惯于通过发送指令来启动触发事件，比如启动或者停止某一个应用。而到了云原生时代，声明式API的理念就是“想要一个应用处于运行状态、想要一个应用处于停止状态”，其表达了终局一致的理念，非常像微积分中的无穷逼近，而Kubernetes的编排模块就是按照这个理念设计出来的，其帮助运维人员维护最终状态的驱动，这就是云原生时代和过去的运维时代非常显著的区别。

蚂蚁金服内部经过多年的实践所得到的启示是：云原生架构看上去非常好，但是云原生架构的转型并不能一蹴而就。在向云原生架构转型的过程中也存在很多问题，原本的系统中存在很多历史负债，无法实现直接跳跃，因此需要渐进的架构方案；在架构转型上，需要一个大规模、金融级的运维支持，帮助把云原生方案落地；此外，还需要经过各种严苛的金融业务场景的验证,我们的技术和产品才能提供给蚂蚁金服的客户和合作伙伴使用。
在这里插入图片描述

渐进式云原生架构转型方案

传统架构迁移到云原生架构会存在一些普遍问题，也有一些存在于开发和运维同学心中的观点。第一种理念就是非常习惯原本虚拟机方式，希望所做的任何事情都围绕机器展开，比如能够到机器上看日志，并跟着机器和IP进行监控，包括将遗留资产体系的打通都是围绕这套理念实现的。第二种理念就是虽然非常推崇云原生，也希望使用云原生，但是云原生在自身实际场景中不能玩得转。因为云原生基于终局一致的理念，这就意味着它意味着无时无刻都在发生着生产线的变更。这些变更能否在传统运维体系中被完全的掌控和监控，以及调度上的一些问题能否完全解决，都存在很大的问题，这或许会使得开发和运维对于云原生架构产生不信任甚至怀疑。还有一种观点就是敢于拥抱云原生，但是又不得不思考已有系统架构和已有业务的问题，考虑能否在传统方式和云原生方式之间提供一些“鱼与熊掌皆可兼得”的方案。
在这里插入图片描述
蚂蚁金服所提供的答案是“Yes”。蚂蚁提供了在已有基础设施之上进行的渐进式架构迁移方案，提供了基于Docker VM轻量级虚拟机的一整套运维体系的规范，同时也提供了支持云原生体系的发布、部署以及运维的规范，前者能够完美地对接已有资产和系统监控运维等体系，使得用户不再困惑。此外，蚂蚁还将中间件最佳实践落实到大规模容器云平台之上，包括了Service Mesh的落地以及跨语言的架构。并且容器平台还会能够支持弹性能力的诉求，可以完美适配公有云、专有云、混合云。
在这里插入图片描述

传统与云原生架构的双模运维

可以大致将组织里面的业务分成两种形态：稳态和敏态。稳态业务就是比较传统和核心的业务，这些业务追求稳定和已有的运维、监控、发布体系的兼容性，蚂蚁的金融行业容器平台对此提供了轻量级虚机解决方案，融合了分组、灰度以及无损发布等能力，让用户在原本的体系下可以继续玩得转。另外一方面，一些创新业务归为敏态业务，这些业务需要依靠大数据以及人工智能等技术的创新，因此对于敏态业务而言，拥抱新开源框架和新技术的诉求非常强烈。而基于云原生理念，可以帮助用户迅速拥抱这种变化，并且可以提供安全容器技术帮助用户实现更好的安全隔离，保证企业和组织实现“鱼与熊掌兼得”，使得传统业务和创新业务同步开展，并且是通过一套系统支持业务的迭代和创新。
在这里插入图片描述

原生支持Service Mesh

对于任何一个组织而言，想要打造像蚂蚁金服这样经过十几年的风雨所打造的微服务架构体系，所付出的努力是难以想象的。而如今，开发组织可以通过对接SOFA Mesh，并通过在透明的Pod里面注入Sidecar的方式，瞬间就可以拥有蚂蚁金服沉淀多年的分布式架构技术红利，从而对企业产生巨大的帮助。此外，结合蚂蚁金服分布式单元化架构能够提供更好的容灾服务能力。
在这里插入图片描述

混合云架构

此外，蚂蚁金服还提供了混合云架构解决方案，因为底层使用的是容器化技术，所以可以对接物理机以及OpenStack和VMWare等虚拟化平台。云上和云下都提供了一套体验一致的分布式中间件，通过服务目录的方式把应用所依赖的服务进行注入，这样就能够在公有云和专有云之间灵活地分配负载。当大促来临的时候，可以将负载更多地切换到公有云上，大促结束之后可以将资源返还给公有云资源池，这样就可以从根本上解决企业运营所面对的资源伸缩问题。
在这里插入图片描述

大规模金融级运维能力支撑

整套体系想要落地就离不开大规模金融级运维能力的支撑。接下来从规模化集群运维、单元化发布、一体化监控分析以及自动化流程编排这四个方面来阐述大规模金融级运维能力。
在这里插入图片描述
大规模集群运维能力；对于Kubernetes而言，想要管理好一套Kubernetes集群也都是极其困难的事情，更不用说在生产环境中运维和管理多套Kubernetes集群了。经过技术性探索，蚂蚁金服创造性地提出了Kubernetes管理方案——K8S on K8S（KOK）。对于KOK方案而言，底层存在元集群，元集群采用一体化方式安装起来的。元集群的使命就是运维业务集群，而元集群的组件不会频繁升级，所以安装基本上就是一次性工作。元集群安装完成之后，可以在其上面布置组件，这里包括两个非常关键的组件——Machine Operator和Cluster Operator，这两个组件负责对业务集群进行管理。业务集群的Master节点将会作为元集群的Worker节点加入到元集群中，这样就可以被元集群管理，而且其部署方式也是通过原生方式实现的，这样就可以在元集群的监控面板上看到业务集群所有中控组件，可以很方便地进行运维、升级以及版本管理，借助Kubernetes本身的能力就可以管理好多个集群，带来业务和运维上的便利。
在这里插入图片描述
单元化发布运维能力；蚂蚁容器平台支持VM和容器的双模发布，这一点在单元化发布方式上都会得到支持。单元化发布能够轻松支持万级规模节点的蓝绿机房发布和灰度发布，实现分钟级容灾能力。并且我们支持蓝绿发布和弹性伸缩。下图中最右边是动态弹性伸缩模块，其通过收集监控告警信息并进行处理分析，进而触发弹性伸缩，这样就会保证对外服务的节点和副本数保持不变。
在这里插入图片描述
一体化监控分析；对于任何大规模的容器平台或者PaaS平台而言，监控体系都是其灵活的“眼睛”。通过一体化监控分析平台可以统一收集监控数据，并送到后台模块进行统一处理和建模，经过一体化处理以后，数据将会呈现在可视化大盘上，并可以提供给业务进行自定义分析。一体化监控体系也秉持“兼容社区，拥抱开源”的理念，不仅可以兼容社区的很多技术，还在积极地回馈社区。
在这里插入图片描述
自动化流程编排；如下图左侧所示的是自动化流程编排的案例，提供了一些基于条件驱动的模块，使得用户可以不断沉淀流程模板并且加入到流程商店里面，通过这种方式将一些碎片化的操作整合成相应的自动化流程模板。在下图中右侧还展示了两个例子，一个是网商银行故障自愈场景的案例，另外一个则是蚂蚁国际运维自动化场景的案例。
在这里插入图片描述

严苛金融业务场景实际验证

下图所示的是网商银行基于Kubernetes的实践案例。网商银行是中国第一家将核心系统全部运行在SOFA Stack分布式架构和蚂蚁金融云上的银行。在2018年的大促中，网商银行做了几件重要的事情，包括了分布式架构数据的拆分、单元化、异地多活等。另外，我们还对底层的技术架构进行了升级，将2018年双11和双12的所有工作负载都放在了容器引擎上，支持了数千的节点和数万的Pod，有力的保证了网商银行大促的增长达到400%。我们的容器引擎带来的技术红利包括两部分，一方面使得资源利用率更高，通过高密度部署，使得物理机使用效率更高；再加上离线在线任务的弹性混部，使得CPU的利用率也更高。第二方面还使得整体效率得到提升，从原本的软件包交付模式变成集装箱式交付模式，使得整个开发者工程效率和SRE运维效率都得以提升。
在这里插入图片描述
如今，蚂蚁金服提供了一整套基于Ant Stack的产品，在这套产品之上构筑了各种场景的解决方案，包括了大家所熟知的蚂蚁风控、生物识别、移动开发以及蚂蚁国际化和国际支付等，都是基于蚂蚁的容器引擎之上的。可以说，蚂蚁金服围绕着金融决策和金融分析打造了一整套面向合作伙伴的解决方案。现在，蚂蚁将自身的容器引擎实现了产品化，以PaaS平台的方式为企业客户提供。通过蚂蚁金服DevOps的持续集成流水线，大规模容器化发布部署以及高效资源编排的能力，最终为用户提供完整的PaaS平台。
在这里插入图片描述
如下图所示的是蚂蚁的SOFA Stack为大家提供的PaaS产品和解决方案的全景图。在这张全景图上有两套标准、三个平台和三种形态。第一个标准就是Cloud-Provider，其意义在于屏蔽掉底层基础设施的区别，通过Cloud-Provider可以对接虚拟化平台，隔离底层基础设施。另外一个标准Open Service Broker API的标准，这一标准主要是为了拥抱生态，使得PaaS平台能够更好地扩展能力，对接计算、存储以及网络能力，将这些能力整合进来，变成应用PaaS平台所能提供的能力，这也符合整个社区一贯的做法。三个平台则是应用与容器平台、监控分析平台以及容灾应急平台。三种形态是公有云，专有云和混合云。最上面则会提供面向各种应用场景的解决方案，包括了DevOps解决方案、容器化解决方案、单元化结构，以及异地和同城容灾的解决方案。
在这里插入图片描述