您好,登录后才能下订单哦!
2019年6月20日,由Rancher Labs(以下简称Rancher)主办的第三届企业容器创新大会(Enterprise Container Innovation Conference, 以下简称ECIC)在北京喜来登大酒店盛大举行。本届ECIC规模宏大,全天共设置了17场主题演讲,吸引了近千名容器技术爱好者参加,超过10000名观众在线上直播平台观看了本次盛会。
来自Rancher、阿里云、百度云、平安科技、中国联通、飞贷金融科技、中国人寿、SmartX、华泰保险、厦门航空、JFrog、新东方、Cisco等十多家企业的技术负责人出席了本届ECIC,现场带来关于企业容器项目实践经验的精彩分享,为参会的容器技术爱好者带来企业容器化的经验分享。
大会现场,飞贷金融科技作为金融行业数据库容器化的典型案例,为现场的容器爱好者带来了题为《金融领域数据库生产容器化及Istio应用》的实践经验分享。
对于飞贷金融科技而言,生产容器化及数据库应用的难点在于,如何针对金融领域生产容器化及数据库容器应用进行实践创新,如何结合研发及业务场景落地,提升资源利用效率、提升产品研发、运维管理效率。
飞贷金融科技副总裁陈定玮表示:“金融行业数据具有相较于其他行业更为严格的安全高标准,在安全合规的情况下用飞贷自研中间件,解决金融领域DB应用场景难题,带来10x的DB交付效率,极致的弹性扩容能力。”
飞贷金融科技成立于2010年,是移动信贷整体技术服务商。我们以科技创新作为企业发展的动力,在科技创新的道路上不断前行。
2011年到2015年,飞贷做的是传统的小微金融业务。2015年,我们决定进行线上互联网化转型。到2017年,我们整个公司进行了战略升级,为金融行业客户提供互联网服务。迄今为止,飞贷为人保、北京银行、华润信托、通联支付等多家金融行业企业提供了全链路的科技服务。
2018年,我们登上了美国《时代周刊》,被《时代周刊》称为“全球金融科技最佳实践”。同年,我们还拿到了世界银行和G20共同推出的首届全球小微金融奖最高荣誉——“年度产品创新”铂金奖。
接下来,我会和大家详细介绍一下,飞贷作为一家互联网金融科技企业,是怎样和容器化相结合,又是怎么在业务上应用容器化的。
飞贷应用容器化与前面分享的企业一致,同样也是基于整个企业的容器化应用。值得一提的是,飞贷做的是金融领域,所以我们对安全、对容错、对高恢复的部分相较于其他行业的企业而言更加在意。我们关注的不仅仅是应用,更多的会关注到如何迅速地进行灾难的恢复。
我们利用容器进行了整体的架构部署,从大家比较熟悉的DevOps,到我稍后会重点介绍的DB Mesh的部分。我们划分了几大平台,包括容器化平台、产品研发平台和数据平台。下面的是应用安全、数据安全、网络安全、容器安全、运维安全等部分。容器对我们而言帮助非常大,现在我们的RD都是基于容器Kubernetes做应用开发。在这一部分,飞贷在金融领域已经达到了领先的水平。
下图是飞贷的容器发展路线图。我们从2015年开始研究容器,2016年开始投产在RD环境上。在当时我们还没能完全选定Kubernetes还是另外一个容器技术,所以暂时停留在RD阶段。2017年,Kubernetes技术越来越成熟、越来越稳定,我们就把整体的方向往Kubernetes方向进行迁移。到了今年,我们的生产环境已经可以大量运用容器技术进行多个方向上的应用了。
刚才Rancher的CEO梁胜博士提到,现在Rancher已经可以做到多K8S集群管理和部署,多数据中心。这是和我们的业务发展比较贴合的。我们提供基于飞贷的金融云服务,同时我们有多租户集群管理的业务需求。目前,我们已经可以针对K8S多集群进行应用服务、中心服务、数据库服务等多个方向的多集群管理,同样,我们也可以做到多租户网络隔离。
从客户的角度来说,在客户和我们合作之前或者是过程当中,他们先前可能并不了解小贷的业务运营是这样的,所以银行会把他们的整体服务放在我们公司,飞贷就变成了一家金融云厂商。而飞贷的特殊之处就在于,我们专注于和我们业务发展相关的内容,我们为客户提供的不是一个整体的平台,而是应用。
刚才提到的所有内容都是和容器息息相关的,容器的特性包括安全审计、动态存储、高可用灰度发布等等,我们把容器的特性应用到了飞贷生产环境上,并且发挥到了极致。
下图是飞贷容器化的平台组件。无论是我们的RD还是外面的人员,飞贷会为他们提供应用商店,他们要做什么事情,就在我们的管理平台点击一下,我们会自动生产一个容器的应用帮他们进行处理。我们镜像仓库的部分是在一起的。
除了这几个部分,我们还有Prometheus和Jenkins,这些体系和我们研发的相关度比较高,现在飞贷能实现自动集成、自动打包、自动发布和自动部署,这是我们研究了两年多的平台组件成果。
飞贷为什么要让DB容器化?因为微服务部分的应用层已经发展得比较好了,但是对于DB而言还有很多的问题。假如DB宕机了,我想要迅速恢复这个DB,让业务生产能够正常运行,我们需要花费多长的时间呢?如果DB非常大,这个启动时间是非常久的。这就是为什么银行或者是大型金融机构没有小型机,不敢用开源的MySQL或者是MangoDB等资料库,因为他们要保证安全和持续运作,这是一个比较大的挑战。
这就是我今天要重点讲述的几个问题,为什么要MySQL容器化?MySQL容器化安全稳定吗?容器化MySQL的具体实现是样的?
我们刚才介绍了飞贷要做多集群管理的容器,里面存在一些限制以及要求。第一,会涉及非常复杂的网络结构;第二,故障要频繁地切换,我们认为这在金融行业是非常重要的一个部分,因为一旦发生故障,金融行业的业务基本上就会停摆了;第三,要控制容量大小;第四则是要依赖网络存储。
我们之所以要做这个部分,有三个方面的原因。第一,我们需要实现标准化快速部署,因为应用快速部署完之后,如果DB部署很慢的话,对于我们而言,整体效率还是一样地低,这是站在整体效率的部分而言的;第二就是微服务场景,我们现在的系统已经是全部为服务化进行终端的调整,在这种场景下,如果数据场景不能微服务化,那我上层所做的内容毫无意义,我们不希望数据库成为业务弹性伸缩以及管理的短板;第三就是MySQL服务化、自动化、网络化和智能化的需求。
我们进行MySQL容器化的效果很明显。第一,我们可以实现高效弹性伸缩、扩容、备份、导入、导出、恢复、快照、迁移;第二,我们可以实现整体数据库的性能监控和审计;第三,分布式存储、资源、数据多副本可以实现实时同步。我们在大数据应用的部分可能和一般的公司也有所区别,我们生产环境的一些数据和大数据实时数据是拆分开的,但我们做到了实时同步;第四就是计算资源分布式,多节点,技术设施高可用;第五是拥有故障自愈的功能。我的MySQL如果宕机,我们可以迅速恢复。
下图是我们MySQL DB的架构,底下的应用服务对应的是中间件,我们所有的中间件对应每一个单独的库。我们为了实现DB容器,把库做到了非常大的空间压缩,并且把库进行了容量限制,这样才有可能在库故障的时候,可以迅速的启动它。这部分考验了我们整体的业务运作部分,数据分表分库的能力、读写分离的能力。而这部分都是通过我们自行研发的中间件完成的。如果没有我们自行研发的中间件,DB Mesh这部分内容是我们也无法完成的。
以上基本就是飞贷DB的网络发散图,架构特征包括几个部分,一是高并发、低延迟,每秒10000事务处理,延迟小于100毫秒;二是支持IDC多活;三是支持数据路由;四是可以自动化或者人格化决策切换;五是数据多副本。
截至目前,飞贷的DB量级是PB级别的,我们大概是十几个PB这种应用数量,可对外同步实施,故障容器数目大于二分之一可以自动回复,这就是为什么我们要做DB Mesh的原因。
另一部分是关于我们容器化整合Istio的,右边是我们生产应用的图形界面,可以看到注册进去之后,我们就可以进行自动追踪,了解库的健康程度。但是里面还有一些小问题,当DB断掉再恢复之后,这个服务就不见了,需要再次手工注入。关于这个问题,我们研究了Istio的很多文档,但还没有克服这一问题。所以在DB这一部分,我们只做到在生产的时候,一开始可以注入,但是当它挂掉之后,我们还是需要手工处理,暂时没有办法自动恢复。
而在应用和管理服务的部分,我们已经做到了完全自动化,整合Istio实现微服务Service Mesh,实现了微服务访问、安全加固、控制、观察。服务追踪、限速、熔断、调度、负载等部分。
以上是飞贷整体服务的应用部署,从应用服务到中间件,这是我们整体部署的发布图,所以现在我们的RD人员基本上只负责开发,开发之后,所有一切都通过我们的平台去进行集成、发布和管理,上了生产环境之后,也会由我们的运维来处理,不会由RD来处理。在这一点上,我们做的还比较符合银行的要求。
最后,我想介绍一下飞贷容器化带来的成果:
第一是提升飞贷整体生产力。飞贷80%的基础运维都是自动化的;其次,交付能力也有所提升,一小时我们可以交付上百套的服务应用,目前来说有上千台容器在我们整个生产环境上面运作,如果我们没有进行微服务容器化的话,微服务架构部署时间会非常长;最后一个是我们具备生产环境上数百个MySQL的实例,这也是我们的一个容器化成果;
第二就是研发和扩展,可以按照容器的pod、物理主机节点、机柜及数据中心级别做扩展,这块我们也结合了很多CMDB的内容,但在这里就不详表了;
第三是IT成本的投入,这也是我们企业比较关注的一个内容,我们之前的私有云是用CloudStack作为平台去搭建的,现在我们全部换成了容器。这大约节约了我们40%的资源,节省了60%的人力投入。以前我们要部署一个应用还需要提供虚拟主机在RD上面部署,现在容器一键部署就可以完成了。另外项目研发投入时间也节省了40%,因为部署应用之类的内容现在已经不需要RD人员来处理了,都是由我们平台自动化处理的;
第四是安全、敏捷、高效,这部分业余数据的全量备份我们也是分钟级的,我们的库缩得足够小,所以我们可以在几分钟内迅速备份;第二在容灾故障的时候,我们的业务运用一键恢复也是分钟级的,数据快照是秒级的,资源利用率提升10倍,数据库交付能力提升近百倍,我们整个应用有上百个MySQL节点,如果一个个部署非常慢,我们现在已经把镜像做起来了,所以部署是非常迅速的;
最后一点是运维变得非常简单,自动化、极致的、弹性容器的调度,灰度发布、预发布、蓝绿部署、持续交付。
免责声明:本站发布的内容(图片、视频和文字)以原创、转载和分享为主,文章观点不代表本网站立场,如果涉及侵权请联系站长邮箱:is@yisu.com进行举报,并提供相关证据,一经查实,将立刻删除涉嫌侵权内容。