近年来，随着云计算、大数据、移动互联网、「联网+」等技术的飞速发展，我们身边的每个行业都在发生着巨大的变化。
保险行业也面临着竞争加剧、创新加速的局面，尤其是去年保监会提出所有保险公司都要实施双录系统，即投保时需要录音录像，这些变化对保险企业的信息系统提出了越来越高的要求。
本文从数据的存储、传输以及应用封装等角度分析了保险行业面临的挑战，并基于 QingCloud 完整的企业级云计算平台和服务，提出了相应的建议架构和解决方案。
目前保险行业用户的数据主要有以下四种：
第一种数据，双录系统即将成为行业规范，而双录系统一定会涉及到音视频文件。当双录系统上线后，会产生海量的音视频文件，这些文件如何存储与处理是保险行业必须面对的问题；
第二种数据，保险公司在核保、理赔的时候会涉及到非常多的图片上传和下载。同时，在保险公司日常的 OA 系统里，发生报销时发票的上传和下载也会产生大量图片；
第三种数据，很多保险公司都会涉及到文件分发与文件共享，其中包括平时的报价文档、险种发放以及一些保险公司宣传的材料。这些数据将会在各个公司之间、公司内部的部门之间进行文件的传递和共享；
第四种数据，大部分保险公司的核心业务系统和非核心业务系统都会使用关系型数据库，很多客户的非核心业务系统，基本上都会沿用传统的关系型数据库，而且大都会沿用核心系统的数据库体系。
以上这些数据大致可以分为两大类：结构化数据和非结构化数据。其中，保险行业用户的结构化数据主要有两类：
一是 Oracle 数据库，基本上 90% 的保险公司核心和非核心数据库都是 Oracle；
二是微软 SQL Server，有一部分保险公司会使用。目前，这两个数据库基本上覆盖了 95% 的保险行业客户。
除了数据库之外，其他的都是非结构化数据。非结构化数据的范围很广，包含音频文件、视频文件、图片文件、电子保单、电子发票、邮件归档和共享文档等。
音视频文件：在没有双录系统之前，其实在寿险做核保时也会有部分的录音录像，但那时还没有行业规范。在行业规范出来之后，音视频文件一定是数量骤增，且容量会急剧增长；
图片文件、电子保单、电子发票：这是保险行业核心业务系统中必然会生成并使用的文件与数据；
邮件归档：在目前一些中大型的保险公司可能会涉及到的，从保险公司覆盖的人员来说，人员很广泛，势必对邮件系统的压力也会很大，一定要对当前的邮件做一个备份，对之前的邮件做归档，此部分对存储空间的消耗量非常巨大；
文件共享：对于保险公司来说，文件到底基于什么样的方式分发给员工、用户或者其它的公司，这也是很重要的部分。
保险行业流行的存储解决方案及问题
从目前这两部分数据的数量和容量上来看，非结构化数据是最多的，但从核心业务系统的重要性来说，结构化数据（保险公司的核心数据库）也是非常重要的。针对这些数据，目前有两种比较流行通用的解决方案：
针对结构化数据，目前最流行的解决方案就是通过 SAN 存储和 NAS 存储。
目前，无论是新成立的保险公司还是一些比较传统的大中型保险公司，一定会有 SAN 和 NAS 这两套存储系统，而且上面跑的一定是保险公司的核心数据库，无论是 Oracle 还是 SQL Server。但这两个数据库有一个重要问题 —— 所有数据库不能区分是核心系统还是周边业务系统，多数情况下，都运行在同一个存储集群上。
针对非结构化的数据，大部分用户是用 NAS 存储接虚拟带库的方式来实现的。
之所以后面有个虚拟带库，是因为 NAS 的容量没有办法承载如此巨量的音视频文件，这两个文件占空间非常大。
这两种解决方案是目前保险公司内部正在使用的典型存储方案，但这两种存储方案也存在着一系列问题：
一是综合成本高，集中存储的价格都很贵。
二是扩容难度大。
从扩容的角度来说，SAN 的扩容对业务系统是不透明的，需要凭业务系统才能做这个事情；周期比较长，一个 SAN 的扩容如果数据量少一周可以搞定，数据量更多的话扩容的周期就更长。
三是权限控制难。
从权限的角度来说，在一个 SAN 存储集群有多个数据库运行，势必要对存储集群进行分区隔离，满足多个数据库库独立运行，虽然权限控制比较复杂，但至少 SAN 存储这个层面做的还好，它主要的问题体现在文件共享上面，很多保险公司做文件共享会通过两种方式：
第一种是将需要共享的文件都放在 FTP 上面，但这个权限只能通过 FTP 的账号去控制，这样做权限粒度会很粗，而且不能区分部门、文件；
第二种是用 Windows 共享，很多 IT 部门内部做一些软件的共享或者文档的共享都是通过此类方法。这种方法一般是通过 NAS 或者更多的基于虚拟机内部的一个大磁盘，要做到权限很明确基本不可行。
四是运维强度高。
系统中既有 NAS、SAN，又有虚机或物理机上磁盘的共享，这对运维的压力非常大，各种各样的存储都需要了解，出现任何问题必须能快速处理，这与我们目前统一化基础设施或者统一规划是背道而驰的。
数据存储的建议架构
针对以上这四点问题，青云QingCloud 可以做什么呢？
第一，针对结构化数据，QingCloud 提供了 Flash SAN 存储解决方案。
虽然很多人现在已经用了 SAN 存储，从使用难度或使用习惯来说会有一个延续性，可能他们会继续使用 SAN，但 IT 系统架构升级转型的方向是通用化+分布式，我们的建议是不与趋势为敌，再继续使用 SAN 不是不行，但对业务的支撑和扩展一定会有瓶颈；
QingCloud Flash SAN 可以做到超大容量存储，一个卷可以超过 100TB，目前 Oracle 数据库的单表也就在 30-40TB 左右，100TB 从容量上看完全是足够的。
使用 SAN 一定是对存储的 IO 或 IOPS 要求极高，QingCloud Flash SAN 的存储性能单个 volume 可以达到 10 万 IOPS。同时，在如此之高的 IOPS 下，整个存储的延迟可以做到 200 微秒。(这个数据是在采用三副本的前提下实现的，如果副本数量更低，综合性能还会更高。)
QingCloud 所做的整个存储完全是基于纯软件自行开发的，例如 QingCloud 开发了高度优化的存储协议栈，可以直接对接到底层存储资源，网络资源并没有用 FC，使用的是标准的以太网，一端可以兼容 TCP 网络，而后端的存储副本同步采用的是 RDMA 网络（即超低延迟网络）来实现的。
QingCloud 整个集群的容量和性能可以通过逐步增加 Flash SAN 存储节点的方式来 Scale Out。
从 QingCloud 与多个保险公司交流和使用的情况来看，完全的云架构不太现实，而用户从现有的传统 IT 架构分离出一部分做成 Flash SAN 或者分布式存储方案是可行的，混合架构已成为必然。
这种方案适用于两个场景：
有一些非核心的数据库，虽然用 Oracle 数据库或微软的 SQL Server，但完全可以把它从核心的存储上面迁移出来，部属在分布式 Flash SAN 之上；
现在很多保险公司都在做两地三中心的同城容灾或异地容灾。从设计角度来讲，容灾中心是承载用户所有业务在出现灾难时承载业务的，而从理论上来讲，大部分容灾设计应该按照 1：2 的比例来分，也就是说按照生产中心 50% 的容量去设计，Flash SAN 完全可以作为异地容灾中心存储方案来使用。
这样有两个好处：第一，它的成本不高，比传统 FC SAN 的综合成本要低很多。第二，它完全可以沿用用户之前在传统 FC SAN 上面业务系统的部署方法和使用方法，在使用上没有任何差异。
第二，针对非结构化数据，QingCloud 提供了对象存储解决方案。
从保险行业的数据来看，图片、音视频的增长一定会越来越多。针对如此海量的数据，未来一定会有新的业务系统来调取，而要针对原始数据做分析和处理，存储一定不能是一个封闭的空间。
对象存储具备开放*的能力，具有多个开放的 API 接口，可以对接到 Hadoop 集群、Spark 集群，任何系统都可以与它无缝的对接。
对应到传统保险行业用户的业务系统中，双录系统、人寿险系统的音视频文件，车险系统、办公 OA 及报销系统的图片文件，企业网盘、邮件归档、企业 OA 里的邮件与文档管理，后端的存储采用对象存储无疑是最佳的方案。
QingCloud 本身是运营公有云的，在设计对象存储的时候采取了多区部属的概念，而不仅仅局限于用户的某一个数据中心，每一个区都是一个分布式的架构，所以它可以支撑广域网级的部属方案。而在一个集群之内，QingCloud 的对象存储也具备很好的横向扩展能力。
横向扩展能力主要体现在三个方面：
第一是接入，其实传统的存储系统无论是 SAN 还是 NAS 都具备存储网关或者机头，机头是有吞吐或者 IO 上限的，一个集群所有的吞吐能力是通过机头来表现的。
但如果整个存储系统的能力都限制在一个存储网关上，那后端再多的存储空间或存储能力都发挥不出来。QingCloud 通过分布式的访问层或者接入系统无限扩展存储的接入能力，每个集群可以水平横向扩展，提升整体的接入的 IO，集群数量没有限制。
第二是索引，所有数据都是有索引录入的，随着用户数据的增多，数据的目录层级也会变得非常多。
如何快速定位到这个文件所在的位置，同时不会由于整个系统规模的庞大导致检索的时间很长呢？其实通过 QingCloud 索引子系统就能保证所有的响应速度能够达到用户业务系统所要求的最低水平。
第三是数据，QingCloud 的数据存储目前采用了三副本的数据保护，理论上来说三副本可以达到很高的数据可靠性，基本上数据放在 QingCloud 对象存储上一定是不会丢的，同时用户还可以通过水平扩展的方式增加存储节点来扩充整个存储的容量。
云端传输的建议架构
从业务系统的角度来说，存储只是其中一个方面。如何将数据传输到存储集群中（如对象存储、Flash SAN），这又涉及到传输方面的问题，QingCloud 提供了以下三个方面的解决方案：
第一个是专线，大部分保险公司都会用。
专线为客户数据中心或办公场所提供安全可靠的互联网接入服务，QingCloud 可以提供最高 1GB 的单线（电信、联通、移动任选其一）或多线 BGP 线路。异地的专线可以是 SDH 或 MSTP，MSTP 是比较新的方式，最早可以用 v*n、裸纤或者基于互联网接入到 QingCloud 的接入点来提供；
第二是骨干网。
目前 QingCloud 北京区域的骨干网是一个环网，从用户任意一个办公区域或者数据中心都可以接入 QingCloud 的接入节点，通过 QingCloud 骨干网你可以很快地连接各个数据中心或者各个办公区、各个用户。
另一方面，用户也可以通过 QingCloud 的骨干网将自己分布于北京各个地区或者分布于北京、上海、广州等异地的数据中心有效地互联互通。
数据的传输要做到开源节流，开源可以通过专线、骨干网各种链路实现提升带宽互联互通的能力，那么如何节流呢？QingCloud CDN 就可以帮助用户节省带宽，提升带宽的使用效率。
CDN 可以在用户与业务服务器所在地域间物理距离较远，需要进行多次网络转发，传输延时较高且不稳定时，对一些比较大的没有状态的数据（如视频、图片、音频等）提供临时的存储位置，来综合地提升互联网业务中的访问效率。
云端运管的建议架构
前面提到了数据的存储和传输，那如何将这些数据组合成上层的应用呢？这需要企业从 IT 系统架构和运维方面转变思维。
首先，不应再局限于基础资源的交付。
从泰康的实践就可以看到这个变化，最早泰康对 QingCloud 的使用仅仅局限于 IaaS 层，如虚机、块存储、VPC 网络等资源，但现在泰康已经更多偏向 PaaS 层的使用。
其次，需要转变目前发布系统与云平台的松耦合状态。
保险业每个用户都有一套统一的发布管理系统，业务系统要上线、要迭代，需要对接到云平台，大多数用户希望和云平台之间是松耦合的状态，但 QingCloud 认为应用的发布系统或生命周期管理应该和云保持一种紧耦合的状态。
从运维的角度来讲，无论技术的运维还是传统的运维可能更关心硬件，如服务器、网络设备、存储设备等，但由于软件定义技术的出现，使得大部分运维人员不需要再关注硬件，而是聚焦于业务系统本身。
AppCenter 2.0 就满足了以上三个转变的需求。QingCloud AppCenter 是一个云计算环境中的应用交付与运营管理平台，同时包含一整套用来开发云应用及云化已有应用的框架。
让应用提供商和开发者可以从资源层管理的复杂性中脱离出来，从而更高效地开发、部署、运维及管理所提供的应用，让用户可以便捷地选择需要的应用来构建和管理自身的业务。
AppCenter 与云平台做到了紧耦合的状态，为了实现这点，QingCloud 主要做了以下几项工作：
第一，模板化。所有的业务系统都做成标准化的，只有标准化才能统一和自动化，没有标准化运维起来难度极高。基于模板，我们可以将业务系统抽象出来，形成一个标准的模板，大幅降低云端应用开发、部署及运营复杂度；
第二，可视化。可视化是以应用为粒度的可视化编排功能，提供全新的复杂业务系统构建模式。实现可视化后，用户无需再关注底层资源情况，可以将更多精力关注到业务系统的构成上；
第三，高性能。基于 AppCenter 开发的应用完全构建于青云QingCloud IaaS 平台之上， 充分享受青云QingCloud 提供的高性能计算资源、调度管理、SDN 2.0 与 SDS 2.0 支持。此外，QingCloud 还在私有云环境中，提供基于容器的解决方案。从前，QingCloud 大部分业务系统都是基于虚机实现的， 而虚机的性能是有一定损耗的，但容器可以提供媲美物理机的性能。AppCenter 既可以支持虚拟机，也可以支持容器技术。
同时，AppCenter 支持基于 KVM / Docker / LXC 三种技术体系构建应用，并提供完整的应用编排与管理能力，实现对异构资源的统一管理；兼容 Kubernetes、 Mesos 及 Docker Swarm 等主流容器管理框架，帮助用户基于主流框架实现容器应用编排及 DevOps 持续交付。
前面提到过，发布系统一定要与云平台实现紧耦合，AppCenter 可以对底层的所有资源实现智能、快速的应用调度，如应用发布、扩容、配置变更这些工作不再需要运维人员去调整底层的资源，只需将代码上传到 AppCenter，AppCenter 就会对所涉及到的组件做出智能的调度和分配。