当前位置:云计算行业动态 → 正文

金融行业混合云场景实践

责任编辑:cres |来源:企业网D1Net  2016-06-15 11:32:43 原创文章 企业网D1Net

2016 CCS企业云计算高峰论坛(ccs.d1net.com)于6月15日在北京国际会议中心盛大举行,这是国内面向政企客户的最重要的一个云计算会展。CCS企业云计算高峰论坛上,云与大型企业的兼容性将成为主要议题。

以下是现场速递。(声明:本稿件来源为现场速记,可能有笔误和别字,仅供参考)

主持人:感谢雷博士的精彩分享。下面有请新致云架构师阳葵为我们分享“金融环境混合云场景实践”,有请!


新致云 架构师 阳葵

阳葵:大家好,我先做一下自我介绍,我是来自新致云软件的阳葵,本来这个分享应该是由另外的同事来,他本身有点事情来不了了。我今天主要给大家分享的是在云计算时代如何在公有云,如何同金融行业,这种传统的IT的一些企业的模式怎么让它去做结合起来,让它创造更大的业务价值,分享一下我们在这方面的一些经验,我们在实施的一些经验。

分享之前先介绍一下我们自己的公司,上海新致软件股份有限公司1994年成立,一直从事服务外包,大部分客户都是金融行业,包括银行和保险,员工在5000人左右。现在开始慢慢逐步转型,为企业提供全方位的云服务实施商,这就是我们提供不只是云计算的一些基础的架构,所有云的一些计算资源,我们还提供云技术的一些技术架构,包括写技术架构咨询,包括怎么做实时迁移,以及包括后续的运维服务,这是我们在早期的过程当中。这是我们机房的一个建设情况,到目前为止我们在全国大概有四个机房,建设情况从去年开始,到今年整个运维目前已经有5000台,一直在建设当中,可能预计明年会到两万左右,大概情况是这样子的。广告就做到这儿。

企业向云迁移典型的场景,企业上云,并不是所有场景都能够上云,我们可以有选择性的,有针对性的上云。我们列举了几种典型的场景,我们可以去看看哪些场景适合上云。

第一,开发测试型的应用。这个是说我们会有一些企业就是将一些开发阶段,或者测试阶段放到云端上面,因为这个有一些习惯开发的时候需要开发环境,包括长期的PaaS服务,但是自己搭建可能会比较费时间,也许会周期化很强,这样他们会选择把这些开发阶段和测试阶段的应用直接放到云端上来做。

第二,集成型应用。是说有一部分应用本身不是独立的,是依赖其他应用,但是可以把一些部分放到核心的内网,一部分放到云端上面,这是典型的场景。

第三,全新型的应用。就是将一些没有历史包袱的全新应用直接假设在公有云上。

第四,现有的应用应该怎么去迁移的一个方式。针对现有应用,首先要看一下它的复杂度,整个应用,它的依赖,到底依赖周边系统,包括你的数据都有什么数据依赖,这是我们做的一些分析。

第五,补强型应用。我们可以考虑一种方式,就是系统本身不去做迁移,但是因为在金融行业一个很重要的特征就是所有关键的应用都需要有一个灾备,必须有灾备环境。实际上我们可以把灾备环境放到云端上面来,因为云端本身具备这种异地灾备的架构能力。所以,你直接放云是最合适他们的。

第六,全托管型应用,这个是在比较初创的金融行业可能用的比较多,目前传统的保险行业,或者银行业应该很少用这种模式。

如何迁移?系统上云不仅仅是简单的把云代码部署到云端就可以了,这里面需要有方方面面的一些事情,对于从来没有上过云的一些客户来说,它对这块实际上没有任何经验,也没有任何的方式方法,这块我们提供了一套算是比较标准的服务迁移的流程,做一个事情需要有一套理论支持。我们首先从企业整体上的战略制定,然后到整体规划,然后做评估,最后就是整体设计,在设计方面考虑几个点,一个是治理架构、安全、网络、存储应该怎么做,最后才是实时迁移,迁移之后怎么测试,最后一步就是运维管理,上云之后,整体的运维会发生变化,所以我们在运维管理方面要做一些考量。

下面这个图是一个实施路径图,时间关系不具体展开了。我们后面重点说一下我们在给一些保险客户做的一个上云的方案,一个实施的过程当中所碰到的问题和怎么去解决的,因为这个还是说一下后面的事情。

说这个之前,先看一家保险工资具备的典型的一个IT系统的整体架构。这个图基本上囊括了一家保险公司所应该具备的一些系统。大概分几个类型,像前台销售系统和电商系统是属于电商类型,所有的保险公司都会有,哪怕自己建云,对接淘宝也好,都会有类似的系统。另外,数据分析系统,渠道关系系统,包括客户关系管理。最重要是中间的核心系统,这是所有的必须必备的系统。另外,共享型的应用,这些应用和具体的业务没有太多的关系,但是它必须要有,是一些组件类型的应用。一家保险公司应用系统多种多样,对这种保险公司的系统怎么样的方式上云,上云步骤是什么样的?我们针对整个系统,大概有几个方向去给它评估,然后怎么做策略。

从四个方面考虑。第一,平台服务外迁。第二,渠道业务外迁。第三,核心业务外迁。第四,计算能够外迁,从这四个方面将整个保险公司的系统上云,分各种场景做上云的方案。

平台的服务外迁,举两个例子。分业务线和IT线,业务线是有外包服务,就是金融行业在以前的经验里面,业务上有一些功能已经外包了,像录单、客服、理算这样的工作,在业务层面其实已经外包出去了,不在自己的范围之内。对这种业务类型,这种系统可以直接上,比如云端,云平台提供整体的SaaS服务就可以实现,所以对这类型的系统直接可以放到云端上去。

第二,类似于基础服务类型,这个短信服务还不只是说就是一个SaaS服务,现在网上的很多SaaS服务提供短信平台,但是对保险来说,要求把控整个短信服务的通道能力,它有自己的通道,它有自己的一个短信服务平台,能够把控短信发生的优先级,所以这个传统的SaaS服务不能满足它的要求,这方面可以把它自己自建的短信服务直接纺到云上。

这是两个例子,通过这两个例子来看,外包服务类型可以上云,基础服务类型的业务可以直接搬到云上去。

渠道业务外迁。渠道业务指什么?最近互联网很火,很多保险公司和金融行业实际上都有自己的一些电商平台,包括B2C,b2bi,包括移动营销,都有一些互联网业务,因为互联网业务有互联网的特征,这个特征就是有可能在做某个活动的时候有大量的流量进来,这对传统的行业来说没有这种经验,第二,机房建设和持续建设不能满足这种要求,所以可以让它放到云端上面,共享云平台所提供的标准化的技术架构,所谓的标准化技术架构指你上云了,这个平台拥有的复杂均衡能力,缓存能力,类似标准化的架构设计的能力直接使用,不需要你重新设计,也不需要你使用更多的技术做这个事情。所以,我们可以考虑将电商类型的业务直接外迁。

核心业务外迁。也是我们在实施过程当中发现的一些问题。因为核心系统真的不能直接放到云上,这样他们整体架构是一个混合云模式,内网有一些自己的系统,有一些系统在云端上面。在混合模式的部署情况下面,很多时候要考虑数据一致性,服务一致性,状态一致性,这三大过程有一些问题,目前没有厂商能够解决这个问题,所以这块我们直接上云,这个事情值得商榷。但是,核心业务虽然不能直接上云,但是可以做一些其他方面的尝试。

最后,计算能力外迁,将核心应用中涉及到需要大量资源进行计算的业务进行外迁。这个举个很简单的例子,以渠道系统为例,渠道系统什么意思?在保险行业里面,渠道系统是给这种代理人计算薪酬和考核的。整个薪酬考核过程会非常的占用大量的资源,特别是像大的保险公司都有机构,都有层级,算一个代理人的薪酬要算方方面面,看本月的绩效,上个月的绩效,包括团队的绩效,一大堆的事情有很多依赖。这样对上云过程要求又要占用很大的资源,如果一家企业是按照最大的规模估算,自己采购硬件设备是非常不合适的。所以,这块我们可以将这种类型的业务,因为实际上它仅仅是做计算,不涉及到具体交易,所以这种业务可以外迁到云平台。

这个业务怎么迁移?还是以这个为例。首先,它是将整个计算规则化,我们说整体的渠道系统,刚刚说的这个事情,计算这种薪酬和考核最主要是两个部分,一个是计算规则和依赖数据。计算规则,首先这个规则做成脚本化。对数据做了两个尝试,第一个尝试,最简单的模式,它的数据刚开始在内网,在企业的私有网络里面,在计算的时候直接查询数据接口,以简单粗暴的方式直接获取。但是,实际上我们在整个测试过程中发现,由于网络问题会产生很多其他的问题出现。所以,这个方式事实上不可行,所以我们产生了第二种方式。第二种方式是尽快的同步方式,就是系统将在内网将数据分成文件块,然后通知到云端,云端再进行数据同步。采用这个方式来做。通过这两个方式,我们可以把整体的规则,也就是渠道性的薪酬考核计算功能,就这个计算的过程可以放到云端来实现了,这是技术架构图。下面是一个理想的场景化。

通过以上的方式,是不是已经可以解决所有的问题了?实际上这个问题还没有完全解决,我们发现还是有一些问题在里面。一个是脚本方式不是同一个方式,不同的服务集成商,不同的项目,不同的保险公司对应的规则是不一样的。如果想把项目放到我们云平台,这个是不同用的,没有做到很方便的迁移。

这块我们怎么解决呢?我们引用了Docker技术,也算是新的技术架构,这个方式我们怎么实现?将每家保险公司自己的业务规则和他计算需要依赖的数据全部打包放到一个Docker容器里面,通过Docker复制让你在各个计算单元执行,而不需要再去创新,这样可以做很多的一些重复利用。

看一下这个架构图,这是混合云的容器运行的平台,它有自己的私有网络,私有云实际上可以部署在你自己的机房里面,也可以部署在自己的虚拟机上面。公有云就不说了,传统的公有云都可以,公有云和私有云之间,通过云平台网络互通,变成一个混合云的架构模式。对于开发人员来说,他要做的事情就是做代码提交,可以写脚本,写规则,写完之后,作为Docker的迹象,然后我们把Docker迹象放到迹象仓库里,这个迹象仓库可以公有云和私有云共同读取,这样可以解决怎么去规则通用化的问题,另外就是文件分发的问题,通过Docker来实现。基本上我们通过这种模式可以解决大部分的计算能力外迁的应用场景。

我们整个上云过程中还会碰到很多问题,这是我们在实践经验的总结,我们相信有更多问题会出现,我们希望更多问题会在整个实践过程中慢慢发现和解决。

我们相信随着混合云应用的一些架构的深入,对传统IT企业的一些架构和原生架构会共同的演进,共同成长,谢谢大家!

关键字:云计算

原创文章 企业网D1Net

x 金融行业混合云场景实践 扫一扫
分享本文到朋友圈
当前位置:云计算行业动态 → 正文

金融行业混合云场景实践

责任编辑:cres |来源:企业网D1Net  2016-06-15 11:32:43 原创文章 企业网D1Net

2016 CCS企业云计算高峰论坛(ccs.d1net.com)于6月15日在北京国际会议中心盛大举行,这是国内面向政企客户的最重要的一个云计算会展。CCS企业云计算高峰论坛上,云与大型企业的兼容性将成为主要议题。

以下是现场速递。(声明:本稿件来源为现场速记,可能有笔误和别字,仅供参考)

主持人:感谢雷博士的精彩分享。下面有请新致云架构师阳葵为我们分享“金融环境混合云场景实践”,有请!


新致云 架构师 阳葵

阳葵:大家好,我先做一下自我介绍,我是来自新致云软件的阳葵,本来这个分享应该是由另外的同事来,他本身有点事情来不了了。我今天主要给大家分享的是在云计算时代如何在公有云,如何同金融行业,这种传统的IT的一些企业的模式怎么让它去做结合起来,让它创造更大的业务价值,分享一下我们在这方面的一些经验,我们在实施的一些经验。

分享之前先介绍一下我们自己的公司,上海新致软件股份有限公司1994年成立,一直从事服务外包,大部分客户都是金融行业,包括银行和保险,员工在5000人左右。现在开始慢慢逐步转型,为企业提供全方位的云服务实施商,这就是我们提供不只是云计算的一些基础的架构,所有云的一些计算资源,我们还提供云技术的一些技术架构,包括写技术架构咨询,包括怎么做实时迁移,以及包括后续的运维服务,这是我们在早期的过程当中。这是我们机房的一个建设情况,到目前为止我们在全国大概有四个机房,建设情况从去年开始,到今年整个运维目前已经有5000台,一直在建设当中,可能预计明年会到两万左右,大概情况是这样子的。广告就做到这儿。

企业向云迁移典型的场景,企业上云,并不是所有场景都能够上云,我们可以有选择性的,有针对性的上云。我们列举了几种典型的场景,我们可以去看看哪些场景适合上云。

第一,开发测试型的应用。这个是说我们会有一些企业就是将一些开发阶段,或者测试阶段放到云端上面,因为这个有一些习惯开发的时候需要开发环境,包括长期的PaaS服务,但是自己搭建可能会比较费时间,也许会周期化很强,这样他们会选择把这些开发阶段和测试阶段的应用直接放到云端上来做。

第二,集成型应用。是说有一部分应用本身不是独立的,是依赖其他应用,但是可以把一些部分放到核心的内网,一部分放到云端上面,这是典型的场景。

第三,全新型的应用。就是将一些没有历史包袱的全新应用直接假设在公有云上。

第四,现有的应用应该怎么去迁移的一个方式。针对现有应用,首先要看一下它的复杂度,整个应用,它的依赖,到底依赖周边系统,包括你的数据都有什么数据依赖,这是我们做的一些分析。

第五,补强型应用。我们可以考虑一种方式,就是系统本身不去做迁移,但是因为在金融行业一个很重要的特征就是所有关键的应用都需要有一个灾备,必须有灾备环境。实际上我们可以把灾备环境放到云端上面来,因为云端本身具备这种异地灾备的架构能力。所以,你直接放云是最合适他们的。

第六,全托管型应用,这个是在比较初创的金融行业可能用的比较多,目前传统的保险行业,或者银行业应该很少用这种模式。

如何迁移?系统上云不仅仅是简单的把云代码部署到云端就可以了,这里面需要有方方面面的一些事情,对于从来没有上过云的一些客户来说,它对这块实际上没有任何经验,也没有任何的方式方法,这块我们提供了一套算是比较标准的服务迁移的流程,做一个事情需要有一套理论支持。我们首先从企业整体上的战略制定,然后到整体规划,然后做评估,最后就是整体设计,在设计方面考虑几个点,一个是治理架构、安全、网络、存储应该怎么做,最后才是实时迁移,迁移之后怎么测试,最后一步就是运维管理,上云之后,整体的运维会发生变化,所以我们在运维管理方面要做一些考量。

下面这个图是一个实施路径图,时间关系不具体展开了。我们后面重点说一下我们在给一些保险客户做的一个上云的方案,一个实施的过程当中所碰到的问题和怎么去解决的,因为这个还是说一下后面的事情。

说这个之前,先看一家保险工资具备的典型的一个IT系统的整体架构。这个图基本上囊括了一家保险公司所应该具备的一些系统。大概分几个类型,像前台销售系统和电商系统是属于电商类型,所有的保险公司都会有,哪怕自己建云,对接淘宝也好,都会有类似的系统。另外,数据分析系统,渠道关系系统,包括客户关系管理。最重要是中间的核心系统,这是所有的必须必备的系统。另外,共享型的应用,这些应用和具体的业务没有太多的关系,但是它必须要有,是一些组件类型的应用。一家保险公司应用系统多种多样,对这种保险公司的系统怎么样的方式上云,上云步骤是什么样的?我们针对整个系统,大概有几个方向去给它评估,然后怎么做策略。

从四个方面考虑。第一,平台服务外迁。第二,渠道业务外迁。第三,核心业务外迁。第四,计算能够外迁,从这四个方面将整个保险公司的系统上云,分各种场景做上云的方案。

平台的服务外迁,举两个例子。分业务线和IT线,业务线是有外包服务,就是金融行业在以前的经验里面,业务上有一些功能已经外包了,像录单、客服、理算这样的工作,在业务层面其实已经外包出去了,不在自己的范围之内。对这种业务类型,这种系统可以直接上,比如云端,云平台提供整体的SaaS服务就可以实现,所以对这类型的系统直接可以放到云端上去。

第二,类似于基础服务类型,这个短信服务还不只是说就是一个SaaS服务,现在网上的很多SaaS服务提供短信平台,但是对保险来说,要求把控整个短信服务的通道能力,它有自己的通道,它有自己的一个短信服务平台,能够把控短信发生的优先级,所以这个传统的SaaS服务不能满足它的要求,这方面可以把它自己自建的短信服务直接纺到云上。

这是两个例子,通过这两个例子来看,外包服务类型可以上云,基础服务类型的业务可以直接搬到云上去。

渠道业务外迁。渠道业务指什么?最近互联网很火,很多保险公司和金融行业实际上都有自己的一些电商平台,包括B2C,b2bi,包括移动营销,都有一些互联网业务,因为互联网业务有互联网的特征,这个特征就是有可能在做某个活动的时候有大量的流量进来,这对传统的行业来说没有这种经验,第二,机房建设和持续建设不能满足这种要求,所以可以让它放到云端上面,共享云平台所提供的标准化的技术架构,所谓的标准化技术架构指你上云了,这个平台拥有的复杂均衡能力,缓存能力,类似标准化的架构设计的能力直接使用,不需要你重新设计,也不需要你使用更多的技术做这个事情。所以,我们可以考虑将电商类型的业务直接外迁。

核心业务外迁。也是我们在实施过程当中发现的一些问题。因为核心系统真的不能直接放到云上,这样他们整体架构是一个混合云模式,内网有一些自己的系统,有一些系统在云端上面。在混合模式的部署情况下面,很多时候要考虑数据一致性,服务一致性,状态一致性,这三大过程有一些问题,目前没有厂商能够解决这个问题,所以这块我们直接上云,这个事情值得商榷。但是,核心业务虽然不能直接上云,但是可以做一些其他方面的尝试。

最后,计算能力外迁,将核心应用中涉及到需要大量资源进行计算的业务进行外迁。这个举个很简单的例子,以渠道系统为例,渠道系统什么意思?在保险行业里面,渠道系统是给这种代理人计算薪酬和考核的。整个薪酬考核过程会非常的占用大量的资源,特别是像大的保险公司都有机构,都有层级,算一个代理人的薪酬要算方方面面,看本月的绩效,上个月的绩效,包括团队的绩效,一大堆的事情有很多依赖。这样对上云过程要求又要占用很大的资源,如果一家企业是按照最大的规模估算,自己采购硬件设备是非常不合适的。所以,这块我们可以将这种类型的业务,因为实际上它仅仅是做计算,不涉及到具体交易,所以这种业务可以外迁到云平台。

这个业务怎么迁移?还是以这个为例。首先,它是将整个计算规则化,我们说整体的渠道系统,刚刚说的这个事情,计算这种薪酬和考核最主要是两个部分,一个是计算规则和依赖数据。计算规则,首先这个规则做成脚本化。对数据做了两个尝试,第一个尝试,最简单的模式,它的数据刚开始在内网,在企业的私有网络里面,在计算的时候直接查询数据接口,以简单粗暴的方式直接获取。但是,实际上我们在整个测试过程中发现,由于网络问题会产生很多其他的问题出现。所以,这个方式事实上不可行,所以我们产生了第二种方式。第二种方式是尽快的同步方式,就是系统将在内网将数据分成文件块,然后通知到云端,云端再进行数据同步。采用这个方式来做。通过这两个方式,我们可以把整体的规则,也就是渠道性的薪酬考核计算功能,就这个计算的过程可以放到云端来实现了,这是技术架构图。下面是一个理想的场景化。

通过以上的方式,是不是已经可以解决所有的问题了?实际上这个问题还没有完全解决,我们发现还是有一些问题在里面。一个是脚本方式不是同一个方式,不同的服务集成商,不同的项目,不同的保险公司对应的规则是不一样的。如果想把项目放到我们云平台,这个是不同用的,没有做到很方便的迁移。

这块我们怎么解决呢?我们引用了Docker技术,也算是新的技术架构,这个方式我们怎么实现?将每家保险公司自己的业务规则和他计算需要依赖的数据全部打包放到一个Docker容器里面,通过Docker复制让你在各个计算单元执行,而不需要再去创新,这样可以做很多的一些重复利用。

看一下这个架构图,这是混合云的容器运行的平台,它有自己的私有网络,私有云实际上可以部署在你自己的机房里面,也可以部署在自己的虚拟机上面。公有云就不说了,传统的公有云都可以,公有云和私有云之间,通过云平台网络互通,变成一个混合云的架构模式。对于开发人员来说,他要做的事情就是做代码提交,可以写脚本,写规则,写完之后,作为Docker的迹象,然后我们把Docker迹象放到迹象仓库里,这个迹象仓库可以公有云和私有云共同读取,这样可以解决怎么去规则通用化的问题,另外就是文件分发的问题,通过Docker来实现。基本上我们通过这种模式可以解决大部分的计算能力外迁的应用场景。

我们整个上云过程中还会碰到很多问题,这是我们在实践经验的总结,我们相信有更多问题会出现,我们希望更多问题会在整个实践过程中慢慢发现和解决。

我们相信随着混合云应用的一些架构的深入,对传统IT企业的一些架构和原生架构会共同的演进,共同成长,谢谢大家!

关键字:云计算

原创文章 企业网D1Net

电子周刊
回到顶部

关于我们联系我们版权声明隐私条款广告服务友情链接投稿中心招贤纳士

企业网版权所有 ©2010-2024 京ICP备09108050号-6 京公网安备 11010502049343号

^