写点什么

蚂蚁金服金融级容器引擎实践之路

  • 2019-08-30
  • 本文字数:3849 字

    阅读完需:约 13 分钟

蚂蚁金服金融级容器引擎实践之路

小蚂蚁说:

在金融级分布式架构中使用容器,许多企业的开发者都面临许多挑战。在 2018 年 ATEC 蚂蚁金服技术探索大会上,蚂蚁金服高级技术专家盛延敏在演讲中分析了容器与云原生技术的本质,为容器在分布式架构上的使用带来了实用高效的解决方案。


容器与云原生技术


云原生技术由来已久,它包含五部分基础技术,包括容器(Containers)、服务网络(Service Meshes)、声明式 API(Declarative APIs)、不可变基础设施(Immutable Infrastructure)、微服务(Microservices),以及公共云、混合云、专有云三种能力。


容器(特别是 docker)、微服务大家都比较熟悉,先来简单解释一下大家可能比较陌生的服务网络、声明式 API 和不可变基础设施的作用:


“服务网络”能够解决诸如跨语言、跨技术栈等问题;而声明式 API 则是目前 CNCF 等社区非常推崇的一种理念,比如 k8s 里面的对象采用了 api、kind、version 等方式,最终描述了一种期望达到的状态;至于不可变基础设施?这个概念比较难理解,我们知道 k8s 里面的 pod 是一个豌豆夹,里面可以放很多容器,每当声明(declare)新 spec 的时候,系统就会将 pod 销毁,产生新的 pod 对象,这个概念它比较像我们购买 iphone,iphone 是一个封闭的体系,用户想换的时候就需要买一个新的,不可变基础设施不意味着比较稳定。



回顾一下云计算的发展(如上图所示),开始的时候大家关注虚拟化,在虚拟机中安装软件和中间件,让应用跑起来。随着技术的进步,大家开始思考能不能将基础架构屏蔽,于是创造出以 app 为中心的理念,使用大规模发布的能力、自动化的运维,将中间件和应用代码耦合在一起部署在一个平台上,上移至 PaaS 层。


技术再进步,大家又想到了 CaaS,通过 docker 的镜像、云原生的统一抽象和标准,让应用和基础组件包含在一起,以镜像的方式发布应用,大家的视角转移到容器、微服务体系的融合,“云原生”的时代就此来临。

金融级分布式架构使用容器的挑战

那么在金融级分布式架构下使用容器,我们会面临什么样的挑战?主要有三方面:


第一,已有的基础设施,包括资产管理、监控体系、运维体系,如何能平滑过渡?


第二,微服务架构,包括服务发现与寻址、跨语言支持、服务治理如何落地?


第三,如何让专有云、公共云及混合云具备弹性伸缩能力?



蚂蚁金服的解决方案叫做“CAFE”(Cloud Application Fabric Engine),它是理念以及产品集合,包括“两个标准”,即云 Provider 标准、Open Service Broker API 标准;“三个平台”,即“应用与容器平台”(主要关注容器和应用生命周期的管理)、“监控分析平台”(主要关注 logging、trace、metrics 以及链路、事件等平台)及“容灾应灾平台”(‘三地五中心’就是由它支持);“三个形态”包括专有云、公共云及混合云;其中构建了“N 个解决方案”,包括 DevOps、容器以及分布式架构的解决方案等。


上文提到的三个问题究竟该如何应对呢?蚂蚁金服提供了从传统到云原生的桥梁,帮助用户平滑地过渡基础设施;SOFAMesh 原生的支持,帮助用户快速落地微服务 2.0 架构;混合云的架构,实现弹性能力。

三个应对之道

1. 从传统到云原生的桥梁

从传统到云原生,大家有很多普遍存在的困惑:比如习惯了 VM(虚拟机)体系该怎么办?云原生适合我么?能否渐进上云原生?(有些任务用传统方式做,有些用云原生,两边是不是能互联互通?)


为了解决传统运维体验的问题,蚂蚁金服提供一种方式,不将容器视为单体,而是轻量化的虚机,让用户可以登录、关机、开机、重启,这种方式与操作模式无关,用户可以通过镜像化发布,也可以登录到机器中重新做 service 的启停。


熟悉容器技术的人都知道,如果容器本身的内核不支持,整个容器资源都会显示宿主机的资源,蚂蚁有强大的团队,可以修复这样的内核问题,另外可以支持单容器操作,让发布前后容器 IP、ID 保持不变,将 PV 和 PVC 绑定,创造兼容传统运维的用户体验。做到这一点,需要很多技术积累。


基于虚拟机的生命周期管理,我们先来复习一下原生 pod 的生命周期管理:一个 pod 的创建指令被接受了以后,会进入 pending(暂停)的状态,这意味着这个容器、这个 pod 没调度,或者还没有生成,直到任务被 create(生成)出来后才会进入 running(运行)状态。如果所有的容器退出了,流程就会进入 succeed(成功),中间 running 和 failed 可能会反复。



Native Pod 生命周期


然而,这个生命周期不能够完全满足企业级需求,因此我们通过升级和定制,定义了如下的 CAFE Pod 生命周期,通过它我们可以同时支持虚拟机发布和镜像发布;分组、灰度和无损发布;版本管理,变更自愈(很多开发者社区的东西并能拿来即可用,比如我们打造的底盘夯实的能力,这一能力能够在 pod 出现问题时及时熔断兜底);原地升级和重建升级;通过分布式架构体系实现同城双活、异地多活;通过技术风险体系实现 etcd 在线备份,宕机迁移,高可靠,可运维,可监控,可交付等。这一架构通过 Upgrading 支持虚拟机通过镜像原地替换的方式发布,本地的存储都可以保留下来,资源还可以放大,比如 2G 变 4G。



CAFE Pod 生命周期


我们还设计了全新的负载 Cafe Application,在主机故障或者停机时自动在新机器上拉起容器提供服务;在升级后(非 upgrade 容器方式),新 pod 和原 pod 的 Ip 不变;支持按分组配置升级部分容器,并且长时间可以保持该状态;支持原地升级(inplace)和重建升级(replace);提供类似 statefulset 的 podname,每个容器的名字都是唯一的;每个容器都有单独的 pv,pvc,类似 statefulset;在升级前可以加入一些控制,比如摘除流量,注销注册中心等;并支持回滚到之前版本。


此外,云原生方式还要求底层具有更强大的日志能力,我们要把所有在系统里面产生的 pod 的日志进行收集、存储、投递。如下是整个日志搜集能力的架构图,这一架构复用了蚂蚁中间件团队积累的强大的技术实力,包含了两大核心中间件。



第一是有流式投递能力的 AntQ。还有就是我们基于 Elastic search 做了深度改造的 ZSearch,提供整个日志的存储和检索的能力。每一台机器上会有 logAgent,它会和我们的 LogService 通信,接受 dockerD 来的一些 event(事件),然后会和 docker graph 交互,拿到 docker 实例的文件句柄,源源不断地把这些文件流输送给 AntQ,AntQ 拿到以后,我们可以通过几种路径来完成整个日志的输送,对于最实时的任务可以直接通过 AntQ 来投递到实时的计算引擎;对于准实时的日志查询或者链路监控的需求,我们建立 index(索引),让上层的链路、监控能拿到这些数据,做一些链路分析和日志查询。对于非实时的需求,我们可以通过投递到 hdfs 完成离线数据报表的分析和制作。

2. SOFAMesh 原生支持

前面一部分讲到如何从传统的应用迁移到所谓的云原生容器的方式,对任何一个公司来说如何使用容器技术落地微服务架构,并且随着产品的不断迭代、业务需求越来越多,微服务体系是否可以支持上,支持好,这么大的技术成本对于中小公司来说是难以为继的。


有没有更好的办法呢?答案就是 SOFAMesh,即 SOFAStack 的中间件,它可以提供全新的微服务 2.0 的能力。通过业务聚焦,支持多语言、多技术栈,通过 CAFE 平台可以让业务迅速获得这种能力。




上图是我们在 SOFAMesh 上的部署架构,其控制层面叫 SOFAMesh Pilot,数据层面叫做 MOSN 模块,说白了它就是一个智能网关,所有的信息都通过 APP 发给 MOSN 模块,做网络传输;MOSN 模块同时不断地把 metrics, logging 等投递到到日志,监控和链路分析基础设施,以便用户全方位地掌控微服务架构的状况。


这套体系加上蚂蚁金服沉浸多年的中间件的能力,以及数据中心,在金融场景中得到了大规模验证。


使用 CAFE 去打开 SOFAMesh 有什么好处?最大的好处就是开箱即用。而且它提升了技术竞争力,整合 PaaS 能力,统一应用管控。举个简单例子,如果有一天你的老板说,可不可以对 iOS 的移动流量来一个 5%的线上灰度,现在的微服务架构体系里面是可以做到的,但是侵入性非常大,而 SOFAMesh 框架可以定规则,由 Pilot 下发,上面的 MOSN 模块很容易实现。由此可见,SOFAMesh 爆发的能量是非常巨大的。SOFAMesh 和 CAFE 是实现微服务架构的绝佳拍档。

3. 混合云架构支持

最后说一下弹性伸缩混合云。有些公司想上专有云,琢磨着能不能在公共云里面做一部分开发测试,然后再上专有云,而专有云本身资源有限,在资源有限的情况下能不能自由迁移,弹性伸缩,节省成本,这都是很多厂商看重的。蚂蚁金服近些年在这方面做了很多努力。



蚂蚁金服支持混合云架构,能够把应用的数据、镜像等在多朵云之间同步,在多个云上迅速拉起应用,包括任务调度等,在专有云、公共云之间自由分配工作负载,达到弹性伸缩的能力。



上图是我们基于 CAFE 容器引擎验证的全栈产品输出能力,我们的全栈产品的品牌叫做 Antstack,包括了金融企业需要的所有关键组件,大家熟知的 OceanBase 容器化也在这个平台里面。Antstack 底层通过资源调度提供计算存储网络,再上层提供产品组件,开发平台等等,这些产品可以满足不同金融场景,包括银行保险场景的解决方案。


最后三句话总结一下,CAFE 为传统运维平滑迁移到云原生提供了很好的桥梁,为基于 SOFAStack、SOFAMesh 的微服务落地提供了绝佳的大规模运维的平台,为整个企业选择公有云、专有云、混合云架构提供了更好灵活性和敏捷性,蚂蚁金服还将继续将运维部署做稳做精,就像精心制作一杯醇正的咖啡(Cafe 同音),为大家带来更好的体验。


本文转载自公众号蚂蚁金服科技(ID:Ant-Techfin)。


原文链接:


https://mp.weixin.qq.com/s/IgfBjNJ8ILL71I1HUzBqtg


2019-08-30 15:00956
用户头像

发布了 150 篇内容, 共 31.5 次阅读, 收获喜欢 37 次。

关注

评论

发布
暂无评论
发现更多内容

信创背景下,J2PaaS低代码平台如何支持企业国产化?

J2PaaS低代码平台

信创 低代码平台 J2PaaS 企业国产化 J2PaaS低代码

报名开启 | 3月30日,阿里云-索信达智能金融平台线上发布会

索信达控股

什么是持续集成?如何基于Jenkins进行持续集成?

阿里云云效

云计算 阿里云 云原生 持续集成 CI/CD

【Python】此集合非彼集合

謓泽

3月月更

Windows、Linux、Apple三大操作系统的主流文件系统包含哪些?

Ethereal

TDesign React Starter 发布

TDesign

手把手带你走进Babel的编译世界

CRMEB

云原生小课堂|Envoy请求流程源码解析(三):请求解析

York

云原生 网络 envoy Service Mesh (ASM)

ABAP 获取本地路径

Jasen Ye

abap 文件路径

国家产业政策不断加码,氢能步入加速发展期

易观分析

氢能源 氢能源产业

什么是数据恢复?数据丢失的最常见原因有哪些?

Ethereal

EMAS 移动推送发布uni-app插件

移动研发平台EMAS

ios 阿里云 Android端 开发与运维 移动推送

拜托,不用记密码真的超酷好吗?

蚂蚁集团移动开发平台 mPaaS

小程序 移动开发 mPaaS

详细解读开源 PolarDB 三节点高可用的功能特性和关键技术

阿里云数据库开源

数据库 阿里云 开源 polarDB

延期通知 RocketMQ Summit 议题全揭秘

阿里巴巴云原生

让人秒懂的Redis的事件处理机制

Linux服务器开发

redis reactor epoll Linux服务器开发 Linux后台开发

拆分电商系统为微服务

孙强

架构师实战营

【百度智能云X英伟达】直播实录|GPU云产品体系介绍和应用场景分享

百度开发者中心

虎符交易所APP产品UI全新升级 让用户体验更流畅

区块链前沿News

虎符交易所

开源实践 | OceanBase 在红象云腾大数据场景下的实践与思考

OceanBase 数据库

oceanbase OceanBase 开源 OceanBase 社区版

项目成本管理系统解决方案

低代码小观

资产管理 成本优化 企业管理系统 CRM系统 项目管理软件

国产版Postman

Liam

Java Jmeter Postman swagger Mock

怎样做一个知识库网站

小炮

知识库 SaaS平台

网络安全Kali之基于SSH、FTP协议收集信息

学神来啦

【图解数据结构】排序全面总结(下)

知心宝贝

数据结构 算法 排序算法 3月月更

从建好到用好,阿里云原生微服务生态的演进

阿里巴巴云原生

弱监督语义分割:从图像级标注快进到像素级预测

网易云信

安全

【百度智能云X英伟达】直播实录|超大规模AI异构计算集群的设计和优化

百度开发者中心

4/8 Serverless 技术实践营成都站持续报名中

阿里巴巴云原生

Ansible:实战笔记

NChunHisenG.🐰

ansible

Java AOT之GraalVM native image介绍以及简单长连接服务实践

BUG侦探

GraalVM java aot native image

蚂蚁金服金融级容器引擎实践之路_文化 & 方法_Geek_cb7643_InfoQ精选文章