保险行业应用级灾备如何架构设计，以实现更优性价比？
Posted twt企业IT社区
tags:
篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了保险行业应用级灾备如何架构设计，以实现更优性价比？相关的知识，希望对你有一定的参考价值。
保险行业做应用级灾备不仅仅需要考虑到数据复制层面的核心技术选择，更需要考虑应用架构、硬件架构乃至网络架构的革新。twt社区近期特意邀请了来自某大型保险集团、某省农信及IBM的资深灾备专家，围绕保险行业核心系统如何建设应用级灾备进行架构设计在线讨论，并且分享了自己保险企业应用级灾备建设的实践，以帮助大家能更好的应对灾备的建设。本文整理了本次交流分享中的精华内容，供更多同行参考。
Q1.同城灾备网络大二层打通会选择什么方案？选择依据是什么？
【问题描述】目前同城数据中心在做双活架构时基本都会考虑大二层打通，实现大二层打通有多种方案比如Vxlan、思科的OTV等，依据最佳实践建议那种组网方案是那种？
@jampg：
我们是采用Vxlan来做的。VLAN实际上就是把原始二层报文进行隧道协议封装，在网络中透明传输，屏蔽中间网络的结构和细节，整个中间网络就是一台二层交换机，各个数据中心的主机都直连这台二层交换机。天然支持跨数据中心的大二层网络。OTV有点类似于VPN技术，它将二层数据报文封装在三层报文中，跨越中间的三层网络，从而实现二层的互通。
@唐国兵：
需要根据实际物理环境及资源条件选择适合的大二层互联方案：
1.网络设备虚拟化方案。当主备数据中心的网络设备支持网络设备虚拟化功能时，可以考虑将主备交换机跨数据中心堆叠成一台设备，从而实现主备数据中心的大二层互联。但此种方案要求主备数据中心需部署同型号网络设备，数据中心之间具备光纤直连和DWDM堆叠线缆的硬件资源且数据中心之间距离通常不能超过10km。另外，网络设备虚拟化需要主备设备横向之间进行堆叠线缆及心跳监测线缆的互联，且纵向级互联设备的链路聚合也需要跨数据中心进行，因此对数据中心之间的线路质量要求较高，且会占用DWDM资源的多个通道。
2.二层“路由”方案。如果同城主备数据中心之间具备二层互联的资源环境也可以考虑利用二层“路由”方案建立大二层互联，以TRILL为例，可以将主备数据中心的TRILL网络建立在同一个TRILL域中，通过TRILL协议完成二层数据帧跨数据中心的路由转发。但该方案缺点是需要更新支持TRILL协议的网络设备，现有网络架构变动及硬件投入成本较大。
3.Overlay隧道方案。以VXLAN为代表的Overlay技术可以较好地支持跨数据中心的大二层互联，只要主备数据中心之间具备三层网络互联条件，且作为隧道接入节点的网络设备（VTEP节点）支持VXLAN协议即可。
Q2.基于OracleRAC双活方案实施，如何规避脑裂的风险？
【问题描述】基于OracleRAC双活方案实施，难点在于远距离光纤条件下的节点之间的数据交互，尤其因为仲裁的原因，导致出现的脑裂现象较多，我们应该如何规避这个风险？
@03500408163.co：
脑裂分两个层面，一个层面是共享存储的脑裂，另外一个层面是数据库RAC层面的脑裂，共享存储的脑裂通过第三方站点仲裁避免，数据库层面的脑裂通过磁盘心跳和网络心跳避免，由于发生心跳网络中断时可能同时导致存储和数据库的仲裁，所以就要优先进行存储的仲裁，存储仲裁完将会导致数据库的磁盘心跳的仲裁，这样就避免了存储和数据库的仲裁不一致的情况。当然存储仲裁的第三方站点是放在另外的机房，一般不会同时第三方站点损坏，存储心跳和数据库心跳也中断的情况。
@wanggeng：
根据一些资料的介绍，我们知道EMC的存储仲裁一般15秒左右，数据库的仲裁是通过参数missmount设置，要想不发生脑裂的现象，如何设置这个参数很重要，其中需要参考光纤速率、光纤稳定性、业务响应时间等诸多因素进行设定。
再次，数据库集群中可以设置优先写，优先读等关键参数，比如主中心注重写，备中心偏重读，这里面可以设置scanip的分配策略等。
@zihan524524：
脑裂是通过多重心跳来防止的，最主要的是网络心跳和磁盘心跳，即使数据库节点之间不能通讯，数据库集群也会保证优先级高的节点来提供服务，其他的节点会被kill掉，所以不会担心脑裂的情况。
@Switcher：
RAC尽量选择在同机房部署，同城机房或者异地机房尽量以ADG为主。
当然，对于某些有自己专用线路并且线路多条冗余，不依赖供应商线路的企业，才会推荐做跨机房的RAC。
Q3.应用级灾备架构设计如何设计性价比更好？另外在选型方面有什么建议？
【问题描述】现有的应用部署在虚拟化上，核心数据库部署在小型机上，如果要做应用级灾备架构设计如何设计性价比更好？另外在选型方面有什么建设？
@邓毓：
以通俗的语言理解应用级灾备：
1、灾备端部署了应用节点，和生产应用程序/配置一致，并可以接管生产应用
2、灾备端部署了数据库节点，和生产数据实时/异步一致，并可以接管生产数据库
要求性价比高，就是尽量简单，但能达到要求。灾备端的硬件可以半配，但必须和生产硬件平台保持一致，可以升级生产硬件配置，替换后的硬件当作灾备，也可以直接在灾备购买半配的硬件。有了硬件后，灾备应用可以直接部署，可以考虑不打通网络大二层，只是将二层网络引到灾备端，省了一笔费用。但没有大二层，没有裸光纤波分复用，数据的同步就需要靠TCP/IP来做，要么在灾备端部署一套和生产同构的存储，用IP复制来同步，要么直接用数据库基于日志的复制技术来做。前者的灾备端主机无法挂起同步过来的数据盘，后者可以直接在灾备端主机上读数据库，后者性价比更高。
@asdf-asdf：
灾备需要看企业对风险的承受力来配置灾备中心的硬件配置，建议核心系统预留500%以上算力，其他系统预留30%以上算力。看业务在切换完成需要承受的前端业务能力确定这些数据。
@bbaimm88：
配置灾备中心的硬件配置，建议核心系统与生产保持2：1以上，其他数据库计算资源配置2：1，应用计算资源根据你系统真实计算使用率来配置吧。当业务在切换完成后能承受的业务就可以了，毕竟灾备使用不多。若果你是金融也加大投资吧。数据重于一切。
@03500408163.co
应用级灾备目前已经基本都是应用双活+数据库的主备这种方式，应用的双活依赖DNS和F5都可以做，数据库的双活由于受到运营商线路质量的影响比较大，基本还是采用主备的这种方式。成本要看企业是要实现那个级别的灾备，如果希望灾备可以完全接管业务，成本肯定少不了。如果要减少成本可以考虑服务器配置减半。
@jampg
我们目前使用LinuxONE，分享一下：
我们使用LinuxONE服务器，作为灾备应用资源池，该资源池上目前分配了近1000个虚拟机，用来运行部分总部应用灾备及13个省的应用灾备任务，充分利用了LinuxONE资源复用的特点，承担测试环境的任务。
使用LinuxONE的主要优势：
① 与传统X86架构刀片方案相比，从13个机柜缩减为6个机柜，节省了机房空间；
② 经多次演练与调优，L1平台CPU使用率未超过40%，还有很大提升性能空间；
③ 很好的规避了传统平台有可能面临的单台资源瓶颈，同时还可以与当前云管平台契合，实现灵活资源交付。
Q4.保险企业异地远距离数据中心架构设计建议？
【问题描述】目前我们只有一个集中管理的数据中心，承载大部分核心和周边生产业务，我们要在外地建设数据中心（距离250公里以上），请问：
2.如何设计敏态应用架构?
3.有哪些节约成本的办法或者黑科技?
@03500408163.co
250公里只能做数据级的灾备，要做应用级灾备的话成本太高，而且必要性也不大，你的数据中心的建设本来就要考虑应对各种非自然灾害，异地主要是应对超大自然灾害，这种情况发生的概率跟投入的成本相比就太浪费了，必要性不大。敏态应用要看适合哪些业务场景，比如银行的应用场景肯定不适合敏态，银行主要是稳定，敏态应用主要适用于互联网业务，错了可以异步补救。
@jampg：
先确定数据中心的定位吧，是做纯灾备中心还是做双活的异地数据中心。纯灾备就比较简单了，源端是什么，目标端接着就行，时效性要求也不高。设计敏态应用的话，应该是需要做双活，主要问题还是距离太远，无法避免的就是时延，这个只能应用上去接受。
Q5.保险应用上云趋势下，如何规划云上应用灾备？
【问题描述】1、目前保险应用有逐步上云的趋势，如何规划云上应用的灾备？本地灾备机房与云上灾备是怎样的一种形式存在？2、请介绍下应用级灾备的实现方式，灾备的日常运维中，通过什么手段保证数据的完整性与可靠性？
@邓毓：
2、保证生产和灾备数据的一致性的问题，我在其他问题中也有提到，可以参考。
有两种方式，一种是技术上，一种是流程上。
技术上有两种方式：
一是通过克隆，例如VMWARESRM+VP（VMWARE软件复制）/存储复制，来保证主中心和灾备中心的虚拟机的一致性，应用也就一致了，只需要用SRM切换即可。这时灾备节点和生产节点都是完全一样的（OS/IP/应用等）。
二是灾备节点完全重新搭建，生产和灾备应用没有任何复制关系，借助自动化平台和工具等手段去检测两端的一致性，并批量同步变更生产节点和灾备节点。这时灾备节点和生产节点除了应用是一致的，OS/IP等都不一样。
流程上也有两种方式：
一是从变更流程上去保证同步，在设计变更流程时需要考虑到灾备节点的同步变更，落实到流程节点中的责任人，并在变更步骤中体现详细的变更操作，配备专人审核。
二是从真实演练中去发现是否同步，通过上面的技术方式仅仅是从行为上保证了一致性，灾备节点真正是否可以真实有效接管业务，依旧需要每年多次的演练去保证，发现问题可以反过来去优化流程、优化自动化监测手段和自动化投产工具，相辅相成，同时也可以完善应急预案。
@jampg：
数据的完整性和可靠性，我们主要通过两方面：一是存储级的数据复制，作为最可靠的保证，另一个数数据库级的高可用，包括RAC、HA、一主两从等。
上云的一般都是偏互联网的应用，代表着敏捷、快速迭代，传统保险公司要上云本身就是一个漫长的过程，所有人都没有办法一下就完成上云这个动作，自有的灾备机房和云上的灾备本身定位就不同，尤其是在过渡阶段。
Q6.保险行业灾难演练过程中，如何清除脏数据和定位脏数据？
【问题描述】保险经常做灾难演练，然而灾备在演练过程中时常会出现一些脏数据，不知道应该如何定位脏数据与清除脏数据？不知道是否有这方面的经验
@邓毓：
由于灾难演练过程时间窗口有限，生产切到灾备做真实的业务演练后，会产生很多演练数据，值得关注的是账务数据和真实客户数据，据我了解，通用的做法有三种：
1、建立生产和灾备存储间的实时/异步同步和切换后的反向复制，当生产切到灾备后，复制关系也将同步反转，由灾备存储实时/异步复制到生产，这是在灾备端的变更，也将复制回生产端。对于异步复制方式，在演练完成后，停止应用的继续写数据，在生产和灾备端数据完全一致后，再回切至生产。
2、仅仅只能建立一端到另一端的复制，复制关系无法反转，若需要反转需要删除原复制关系，重新建立反向复制关系。对于这种方式，通常有两种行业的做法：
（1）切到灾备演练后，不进行回切，因为反向同步需要大量时间，没有太多的时间窗口。这时就在灾备端运行一段时间，待数据完全/准完全同步回生产后，再次选择时间窗口进行回切演练。
（2）切到灾备演练后，不开启对外的外围渠道或服务，仅仅开启可控的渠道进行业务演练，演练后，放弃掉灾备端产生的演练数据，直接回切回生产，再开启全量的外围渠道或服务。
@jampg：
灾备环境是通过存储复制过去的数据，每天会克隆一次。灾备演练时，有专门预留的单子做验证，演练结束之后，只需重新克隆即可，脏数据直接覆盖掉。
Q7.应用级灾备如何保证应用一致性？
【问题描述】对于异地应用级灾备，如何保证生产端应用节点的各项配置（OS、中间件、应用、网络权限等）与灾备端的一致性，在异常时，灾备端可真实接管？
@邓毓：
可以从四个方面去保证：
一是从变更流程上去保证，在设计变更流程时需要考虑到灾备节点的同步变更，落实到流程节点中的责任人，并在变更步骤中体现详细的变更操作，并具备专人审核；
二是必须借助自动化手段去检测一致性，做应用灾备时，不仅考虑到如何做成，如何一次性保证灾备应用节点和生产的一致性，更要考虑如何去保证增量的一致性，通过自动化平台定时检测这些增量部分和变化部分，并通知相关人员注意。
三是借助自动化投产去保证，借助自动化投产工具，批量同步变更生产节点和灾备节点。
四是从真实演练中去发现，通过上面三种方式仅仅是从行为上保证了技术上的一致性，灾备节点真正是否可以真实有效接管业务，依旧需要每年多次的演练去保证，发现问题可以反过来去优化流程、优化自动化监测手段和自动化投产工具，相互相成，同时也可以完善应急预案。
@jampg：
灾备端可真实接管这个我个人觉得不是太对，应用级灾备不代表自动切换，更不代表100%做到数据不丢失。
1、不管是灾备中心还是生产中心，所有的操作都是有规则、有严格流程的，只有按照标准操作，咱们的数据中心才能对外提供服务，技术上能做到两端的一致性，但也是有一定前提的。
2、不是每次异常都需要让灾备端来接管的，每一次灾备演练都需要投入大量的人力，更别说真实的灾备事件了，至少我们是不会选择让应用在出现异常的时候自动切换到灾备端。
3、我个人认为异地灾备本身就是极小概率事件。
Q8.生产切换到灾备环境之后的回切，有什么好的解决方案吗？
【问题描述】目前的灾备环境，数据库是利用Oracle工具从生产数据库实时同步的，应用系统程序版本会定期从生产同步过来。灾备环境平时都是冷备的。现在的问题是，一旦哪天生产环境出现灾难场景，切换到灾备环境运行一段时间后，假设生存环境灾难排除，那么如何才能快速完美的切回生产环境？主要是灾备环境设备配置一般比生产环境较低，所以再重新切回生产是必要的，但是有个问题，就是灾备环境运行一段时间后，生产和灾备的数据就不一致了，想再切回生产就不是那么容易了。
@asdf-asdf：
分几个场景：
RAC数据库灾备的备库启动，数据如何返回主库
RAC数据库如何和已经启动的备库同步
回切先确定数据量问题，目前市场上有通过数据库archlog进行恢复的技术
或者把灾备的数据库做主库然后生产做备库完全同步后找个变更时间完成数据库业务回切再做RAC技术数据库保护。
@Switcher：
“Oracle工具”这个描述太含糊了，工具使用的不一样回切后的同步也不一样。
常见的工具大概以下几种吧：
1.OracleDataGuard
使用DG的话，由于你的primary——standby关系已被破坏，因此只能进行灾备环境到生产环境的“重拉”，然后在归档追上后，进行primary——standby的角色互换即可。
2.各类redo挖掘技术的软件
这类产品市面上很多家都有，由于技术上是通过解析redo、archive这些，所以不存在“角色”的概念，要进行回切还是非常简单的。反向同步，待完成后同步方向互换即可。
由于你说的是oracle工具，那么存储级别的技术就不在此讨论了
@jampg：
核心问题就是灾备的数据如何同步到主数据中心。
换个角度，在灾备中心运行的这段时间里，灾备中心就是“生产中心”，而如何将“生产中心”的数据同步到异地的生产中心去，Oracle本身提供了很多追数的办法，存储级别也有很多解决方案。
Q9.保险行业核心系统灾备能做到异地双活吗，成本是不是要很高很高？
@skey_deng：
正如江西农信邓老师说的，不考虑地理距离问题，谈双活架构就是耍流氓。举个传统架构的例子，以下纯理论，不考虑任何消耗：
2015年我行在探索双活架构时，测试在核心系统日均交易量50万左右时，EMC存储的写I/O是465M/s，运营商用单模光纤有效传输距离是40KM，秒传输速度是100Mbps,那么如果是同步传输的话，写到备库的时间就是5秒左右，但是我们的业务要求的交易响应延迟需要在200ms以内，那么这就需要一条25芯裸光纤，各位可以考虑成本问题。
说下我们没有考虑的问题：
1、光衰问题
2、上面是以单根裸光纤为基础的推论，不包含中继器。
3、不考虑环境对光纤的影响，比如噪音，温湿度等情况。
4、不考虑光波复用等设备的损耗。
我们以上的推论是以40KM为基础的，但任何一个行的异地灾备中心也不仅仅是40KM这么近吧。
《中国银行业监督管理委员会办公厅关于印发<商业银行数据中心监管指引>的通知》（银监办发﹝2010）114号）要求灾备中心异地模式是指灾备中心与生产中心处于不同地理区域，一般距离在数百公里以上，不会同时面临同类区域性灾难风险，如地震、台风和洪水等。
假设我们异地灾备中心的距离是120KM，那么我们理论上要使用的光缆就要是75芯，运营商常用光缆是48芯的，那么就需要两条，仅仅应付写。
我们现在租赁的光缆是8芯的，有3个跳点，年租金是24万，按照上面的理论推算光纤租赁费用为288万/年，如果还有备线，还要考虑读，还要考虑损耗，个人估计一年光光纤的租赁就差不多要上千万，当然这个钱对大行可能不算个事，但是大行的业务交易量也不止50万这个水平啊，所以个人认为成本投入太高。
以上仅仅是成本方面的推论，技术上的瓶颈还需要我们进一步挖掘，当时我们就遇到仲裁的问题，现在随着技术发展可能解决了，但还是有待我们探索。
最后说下分布式的说法，个人认为分布式也绕不开数据一致性的问题，多副本的同步更加大了数据传输的需求，分布式只能说是提高了解决问题的技术可能性，但是成本可能更高（个人认为）。
@huijx：
异地双活数据一致性的要求难以达到，因为实际的距离决定了传输延迟，而双活对传输延迟要求非常苛刻。异地灾备的数据库同步全是异步。
@邓毓：
目前技术而言，金融行业，核心系统异地双活难以实现，这其中的关键在于异地之间的距离，不谈距离说双活就是耍流氓，在合适的距离情况下，追求账务数据强一致性，保证RPO必须为0，牺牲一定的响应时间是能够实现双活的，至于牺牲多大看异地间距和业务并发，不可一概而论，对于金融行业的核心系统而言，难以接受这种牺牲。
@jampg：
要做异地双活，传统的架构太难了。对于中小保险公司，考虑向分布式架构转型，做异地双活就简单多了。
Q10.LinuxONE是否需要改造机房供电和制冷等配套设施？
【问题描述】看活动资料里数据估算，LinuxONE的用电量相当于70台左右的x86用电量，不知道是否需要按此功率调整机房的供电（如线缆数量和平方数）以及制冷（如密度和风道）？有没有范例方案？
@jampg：
这个数据应该是根据额定功率计算出来的，不知道你们是自由机房还是托管的机房。
我们目前主要放置在托管机房，应该没有做特殊的改造，之前的电力和制冷能够满足。
@唐国兵：
供电基本不需要改造，一般而言，LinuxONE需要2-4根供电电源线缆，目前单柜使用的是220v,，双柜需要380v,如果客户机房没有380v的电源是需要单独准备的，其它的和传统使用没区别。而耗电量而言，LinuxONE实际功耗根据配置各不相同，单柜为1.36kW到6.12kW之间，双柜为5.7kW-27.8kW之间，而x86普遍从几百W到几kW之间，所以只要整合到一定数量，可能几台或者10台，20台，这个能耗优势就慢慢体现出来了，如果是70台的话，是明显节约的，至少能节约一半以上，但是x86数量多了之后反而对数据中心能耗的要求更高，供电不足问题反而更多，改造可能性也更大。而制冷就完全没有改造的必要，LinuxONE的产品越来越标准化，做到和现有标准机房无缝融合，都是整机柜摆放，和传统机柜一样。另外LinuxONE机柜内自带的散热体系密度相当高，所以相对而言，是更节约能耗的一种解决方案。
Q11.如何应用“云”构建核心业务系统的灾备体系？
@唐国兵：
云灾备是灾备业务的实现形式，主要包括云备份与云容灾，二者是一个有机体，其中云备份是指备份技术将数据直接备份到云平台上，进而实现数据备份与恢复功能；而云容灾则是指通过数据/系统的云端迁移、高可用等方式实现业务的快速接管，保证业务连续性。其中，云灾备的特点包括：减少基础设施、降低IT成本；按需付费，具有高度机动性；可快速恢复，具备高度灵活性；安全备份，以服务为导向。
在构建核心灾备体系上云的时候最重要的前提是认清当前技术无法做到保障数据万无一失，同时提升数据安全意识。核心业务灾备一定要构建在多云环境中，提升业务连续性和可靠性，通过一些解决方案，比如块级恢复技术，实时立体保护用户环境中的文件、应用、操作系统及虚拟机，实现快速高效的持续数据保护。同时要确保云上业务灾备至本地，也能保证本地数据容灾至云，无论云上系统还是本地数据中心出现故障或业务中断，都可在灾备节点快速恢复数据，保障企业云上云下业务连续。
在云端主机恢复方案中，一定要量化指标，比如能不能达到实时保护，多少时间能够实现数据恢复，快照的时间粒度，确保有本地留存，本地可以快速接管，传输过程支持断点续传、压缩加密。支持将本地数据中心数据容灾到云；支持当本地数据中心发生站点级灾难导致数据丢失时，可从云上恢复数据等等。
Q12. 核心业务系统异地应用级灾备如果部署在云上与部署在本地的优缺点？有需要特别考虑的地方吗？安全如何考虑？
@唐国兵：
部署在云上和本地都可以，但是如果能够成功稳定的部署在云上，能提供动态的资源池、虚拟化以及高可用性，并且能使IT具有强大的灵活性，能根据业务的需求而随时作出相应调整，能够通过提高资源利用率来增强盈利能力。部署在云上也使个人、团队和企业能简化采购流程，并避免重复掌握涉及安装、配置和支持的特定计算机管理技能。这些都是企业越来越愿意把业务逐渐转向云平台上的原因。
几年前，影响云计算应用的两大障碍是云计算的安全性和可靠性。随着时间的推移，人们已经了解到云计算可以像内部部署一样安全（甚至更安全）。但这并不是说采用云计算是万无一失的。仍然有大量的重大停机事件，所以目前大部分核心业务没有上云，主要也在于安全，合规性，部署地点等限制和担心，以及企业客户在寻求更多或者更优的选择。去年看到一个很有趣的预测，认为2019年出现的停机事件会更加突出一个风险，就是企业依赖单个云平台。这也是未来发展的趋势——混合多云架构，多云可以是同一运营商的不同区域云，也可以是不同供应商的云平台，也可以是私有云和公有云的混合，确保架构发展的合理性，提升企业对于关键业务上云的安全和可靠性控制。而云计算服务提供商遇到的数据中心问题并不多，通常都是由于人为错误。有人说，应用云计算就是使用别人的电脑，但“别人”也会容易出错。除了云运营商提升运维管理能力以外，其实我们也看到其他思路，比如IBM LinuxONE通过安全服务容器的方式确保未经授权的内外部访问，从底层硬件来做隔离，也有云服务商提供专属关键业务云确保安全和可靠性。目前从技术层面来说云平台已经能够提供和本地部署相同的保障能力，甚至更高，但是企业关键业务上云路线上，还是必须考虑刚才提到的合规性，安全性和可靠性，选择最合适的平台，最合理的组合确保企业关键业务上云。
更多相关问答请点击阅读原文
资料/文章推荐：
某大型保险企业异地灾备建设的实践经验分享
http://www.talkwithtrend.com/Document/detail/tid/427515
保险行业IT架构转型及LinuxONE灾备解决方案分享
http://www.talkwithtrend.com/Document/detail/tid/427677
欢迎关注社区以下技术主题 ，将会不断更新优质资料、文章，您也可以前往提出疑难问题，与同行切磋交流。
应用级灾备：http://www.talkwithtrend.com/Topic/243
LinuxONE：http://www.talkwithtrend.com/Topic/26875
下载 twt 社区客户端 APP
与更多同行在一起
高手随时解答你的疑难问题
轻松订阅各领域技术主题
浏览下载最新文章资料
或到应用商店搜索“twt”
以上是关于保险行业应用级灾备如何架构设计，以实现更优性价比？的主要内容，如果未能解决你的问题，请参考以下文章