一、平台开发规范

采用国际最新的科技成果，利用符合国际、国内标准的软硬件技术规范，适时引进成熟稳定的新的技术和IT产品，保证软件设计思想成熟稳定。既能符合信息技术的发展趋势，又能充分考虑各系统之间的建设关系以及有可能产生的相互影响，使最终设计符合总体规划要求。具体在操作上，软件系统的选择与开发应在满足业务需求的基础上具有易改造、易升级、易操作、易维护等特性，实现业务的无纸化操作。

1.安全性

平台应当具备可靠的数据信息加密和身份认证机制，确保业务数据的正确性和安全性。具备对系统操作人员、系统管理人员、运维管理人员的多级安全控管和灵活的多级授权机制，以及对各种操作的有效记录和制约。

系统建立在成熟稳定的硬件环境和应用软件基础上，通过完善的备份恢复策略、安全控制机制、可靠的运行管理监控来保障系统的运行稳定、安全。

系统具备全面的安全防护机制，可对敏感数据如银行卡、身份证进行脱敏展示。

2.易用性

软件产品必须具备友好的用户操作和管理维护界面，操作简洁、高效，具备实时的系统监控和故障分析与隔离能力，方便维护和管理。

3.高效性

交易系统可以确保系统平稳运行，满足高峰交易处理的需要，基于PCserver的TPS至少达到1000。性能稳定性需达到99.99%,系统交易转发时间不高于80毫秒；认证响应时间不高于200毫秒；单笔交易时间不能超过05秒。确保客户端交易响应时间小于5秒。

4.易维护性

系统的可维护性将决定系统的运行成本。在设计中应充分考虑系统的运行监控，提供方便灵活的管理手段和工具。

集中监控包括系统资源监控、交易实时监控、批处理实时监控、集群版本发布、日志管理等功能。

5.开发规范

使用JAVA语言，符合信创要求。系统采用开放平台设计，遵循组件化、模块化、参数化、高内聚、松耦合的设计原则，保证软件系统架构易于改造和扩展，提高软件的复用性、可维护性和开发效率，保证新业务功能的不断扩充不会影响应用系统的各种原有功能。

灵活使用同步/异步、缓存、阶段事务、交易补偿等设计技术，并有明确的架构原则、使用场景指导不同技术、机制的使用；

日志输出有规范要求，并能按照政府规范进行修改。具有多种日志级别，支持不重启生效，日志生成不对性能带来明显影响；

系统设计开发需遵循政府的集成架构规范和开发规范，满足自动化部署、灰度发布、运维监控的规范要求；

版本管理遵循行里统一要求，全量信息上传至政务云，通过自动化流水线进行版本发布及代码管理。

二、系统总体设计

2.1系统设计原则

基于成熟的产品实现系统基础构建，完整保留相关业务及系统建设经验，保证目标系统的高效、稳定、可靠。

由于目标系统为全行集中系统，所以应用采用集群模式构建，以保证系统的高吞吐量、高可用性、易扩展性、易维护性和7*24小时工作能力。

由于本系统需要与行内/外众多业务系统对接，所以必须有良好的接口支持能力，扩充性强，灵活性高，能够方便、快捷的与相关业务系统完成接口设计、改造、调试工作。

2.2前瞻性

在满足同意支付平台建设目标和整体IT架构的要求前提下，强调“以客户为中心，数据驱动业务创新”的经营模式，支持金融产品快速、灵活创新和流程优化，强调会计核算与业务管理、风险控制并重的设计理念，为面向客户服务、金融创新的经营方式提供快捷、方便、安全、多手段、多渠道的服务支持。

2.3覆盖性

支付系统面向营业的需求，以业务需求为驱动，能够完全覆盖银行开门营业的各类业务和技术需求。

2.4易拓展性

遵循分层部署，高度参数化和组件化设计原则，通过高内聚的应用和层次化的应用结构实现金融产品插件式的管理模型，系统的各个关键部件基于成熟的应用软件产品、开发工具实现，体现金融产品开发到金融产品装配的逐步转变，易于进行业务功能范围和系统承载能力的双向扩展。对于互联网金融市场创新业务能够在支付业务系统改造过程中及时、高效地实现。

整体架构按照高内聚、低耦合的思路进行设计，如新增或修改某支交易，不会对其他交易造成影响。

高度参数化与最大可复用性使应用系统的开发可以做到便捷、快速和有效。

2.5功能架构设计

数据持久化

基础设施层，提供底层的硬件资源，包括资源虚拟化、资源监控、负载均衡、资源部署和安全管理等。

业务支持层：

技术平台层，为应用系统提供技术支持和接口调用，主要包括对接外部系统短信接口、银行资管系统等系统支持，及我司的技术框架、服务注册中心、分布式数据库、分布式文件系统、监控报警系统和发布部署平台等。

应用层：

应用系统层，实现真正的业务逻辑，包括老人及其代理人报名、投诉管理、预收资金监管、缴费订单统一管理、数据分析等。

2.6软硬件配置建议

2.6.1配置原则

总体原则是平台要充分利用现有系统的软、硬件资源；系统配置经济合理，便于升级维护。同时应充分考虑其开放性、可靠性、可扩展性；以保证系统能够满足未来业务的不断发展。

2.6.2业务系统主机设备

平台配置应充分考虑业务发展及特殊性，应满足以下要求：

满足系统的功能要求和最繁忙时业务处理的需要；

满足业务对系统响应时间的要求；

满足聚合支付业务信息存储容量的要求；

配置经济合理，系统维护方便；

在设计年限内，服务器主机系统的磁盘利用率最大不超过75%；

服务器要求应有较高的安全可靠性保障措施，并给出所能达

到的技术指标，如备份机接管事务的切换时间等；

服务器应具有较大的扩充能力和灵活的扩充方式，须保证系统能够在规模和性能两个方面向上扩展，以保证未来不断发展的要求，支持整个服务器系统的无间断扩充；

服务器需7*24小时连续运行，因而要求其具有极高的安全可靠性。主要要求为：1）保证数据安全可靠的存储、备份、管理；2）在某一主机出现故障时，备份机能接管故障主机的所有工作。

采用先进、成熟的64位RISCCPU；支持64位操作系统；

支持多种主流的编程语言、数据库（包括并行数据库系统）、中间件和其它第三方的软件；

具备开放性、高可用性、高可靠性、先进性和安全性；

具有硬件的分区功能；主要部件应有冗余备份，具有故障的自动隔离功能。

在管理软件支持下可以实现磁盘数据的在线（不停机）备份，保证系统7*24时运行；支持数据的远程拷贝；主要部件应有冗余备份。

2.6.3系统软件配置要求

操作系统（运行环境）

应用运行平台支持两台服务器以上，服务器系统支持Linux及Windows环境，并提供互联网访问地址；支持REDIS数据库和SQLSERVER或ORACLE版本数据库；系统开发语言为java语言。

支持非root用户启动运行，应用的启停支持通过远程ssh或rsh调用单一脚本进行控制。

应用可按照操作系统的需求调整部署目录位置，应用产生日志位置可按照操作系统要求进行调整变更。

后端数据库系统支持OracleRAC，支持数据库运行在Linux平台上。

数据库

使用Oracle11g及以上版本，支持ZHS16GBK字符集，支持数据库通过Service连接。

非部署在通用应用中间件平台（WAS，Weblogic等）上的应用必须自带数据库连接池模块。数据库连接池需配置TCP超时时间，支持连接异常时自动重连。

除通用jdbcthin连接方式外，支持调用OCI或jdbcThick驱动进行连接。

集群部署模式下，支持对数据库的并行访问调用。

中间件

应用中间件采用Tomcat。

通讯标准

支持主流技术规范，包括但不限于WebService、TCP/IP、HTTP、HTTPS、Tuxedo。

客户端浏览器

PC端仅支持IE8及以上版本。手机端支持Safari、UC等浏览器。

网络设备配置要求

尽量利用行内现有网络设备及防火墙资源，如现有的网络设备不能满足本系统的要求，增配新的网络设备。

路由器设备

支持多种路由协议，以便在组网时根据网络的特点，选择最佳的路由协议；

支持各种广域网接口和协议，以满足接入不同公用通信子网的要求；

应具有广播风暴隔离、子网划分、虚拟网交换、端口过滤等功能，以提高网络带宽的利用率和确保网络安全；

支持简单网络管理协议（SNMP）和远程网络管理标准（RMON）；

具有良好的安全性、可靠性，根据实际应用的需要，最好选用能提供冗余双处理器、冗余双电源、模块可带电拔插等技术的路由设备。

局域网交换机设备

选用千兆交换机，可向下兼容以太网、快速以太网；

具有合适的端口类型和数量；

支持SNMP网管协议，按实际需要可选用支持RMON网管协议的局域网交换机，便于对网络监测和管理；

支持VLAN以及多种VLAN划分方式；

满足与网络中其他的交换机设备统一管理。

防火墙

防火墙支持多种接入模式

防火墙系统最好支持与IDS、CA、审计等安全产品的联动。防火墙系统应支持SNMP协议，便于集中管理。

防火墙系统能够完成对经过它的通信、操作命令、访问资源甚至访问内容进行审计。

2.7非功能设计实现

2.7.1高可用性实现

目标系统所有子系统均支持负载均衡和横向扩展，可通过配合合理的部署方案，将能够保证系统的软、硬件平滑地扩容和升级，使之不仅能满足当前的业务需要，还为今后业务领域的发展提供的扩展支持。

应用系统集群模式为全节点Online模式，即所有应用集群内部节点可同构横向扩展并负载均衡。当一个节点出现故障时，集群自动将故障节点隔离；当检测到原故障节点恢复时自动纳入集群可用节点。

通过以上机制，确保了系统在发生单点故障时，不影响整个系统运行，相对于传统HA模式，全节点Online模式无切换不应期，保证了系统的7*24小时服务能力。

2.7.2交易系统高可用实现

交易系统可参考基于我司的联机应用平台(RADP)开发运行，该平台支持服务的分布式部署、集群容错和负载均衡。

通讯高可用

交易系统集群模式为全节点Online模式，所有应用集群内部节点可同构横向扩展并负载均衡。当一个节点出现故障时，集群自动将故障节点隔离，并将交易请求分流到其它正常节点；当检测到原故障节点恢复时自动纳入集群可用节点。

通过以上机制，确保了系统在发生单点故障时，不影响整个系统运行，相对于传统HA模式，全节点Online模式无切换不应期，保证了系统的7*24小时服务能力。

2.7.3数据库高可用实现

为了解决数据库的单点故障，提供系统的整体可用性，存在以下两种技术路线：

基于传统数据库的高可用集群，主要包括共享存储（Share-Storage）、全共享（Share-Everything）和无共享（Share-Nothing）等；

OracleRAC集群

基于“Share-Everything架构”的数据库集群，不仅共享存储，还共享缓存。

RAC通过不同的节点使用一个或者多个Oracle实例（Instance）与一个数据库（database）连接，该数据库存放于多个节点的共享存储（ShareStorage）上，通过高速缓存合并技术使得集群中的每个节点可以通过高速集群互联高效的同步其内存高速缓存，从而最大限度地减低磁盘IO，并且自动并行处理及均匀分布负载，当其中一个节点发生故障时可以自动容错和恢复能力来实现节点的故障切换（Failover），从而保证数据库的高可用性。

2.7.4稳定性和可靠性实现

应用系统在设计上，采用共享内存和CACHE，提高系统联机部分的处理效率，设计分段处理机制，提高稳定性降低重复工作的概率。在设计系统硬件架构时候，支持并行处理、双机互备、热备以及冷备份等多种方案，保证整个系统架构的高可靠性。

在网络连接上设计可考虑多级备份，并在经济性和复杂性方面进行了权衡，在骨干网络连接上采用了对设备和通讯连接的双重冗余，消除了各种单点故障，保证了在线路、网络设备包括生产系统故障情况下的正常运营。

采用支持网络的IP路由随着网络接入的改变而自动动态调整，尤其在出现故障时，网络将以最少的时间自动进行路由切换，传输联机业务的数据可经路由自动切换转到容灾中心再到生产中心，不会影响联机业务的营业交易。

数据库的主、备服务器之间进行集群，一旦主数据库服务器出现故障，备数据库服务器自动启动代替主服务器继续工作。数据库服务器出现故障后对系统的影响是在主/备数据库切换的时间段单个数据区域的交易不成功。

数据级别灾备的关注点在于数据，即灾难发生后可以确保系统原有的数据不会丢失或者遭到破坏。数据级灾备方案是指建立一个异地的数据系统，该系统为本地应用数据的一个复制。只需要投入必要的磁盘阵列和远程网络来完成数据的异地备份。在异常情况下，可通过安装新的主机系统来完成异地中心的启动工作。其最大的优点是：网络环境简单、投资少、建设快。但需要有完善的灾难恢复计划，在远程灾备中心需要有熟悉和掌握系统切换过程的专业技术人员进行切换，并且切换时间相对长，可能会影响到业务的正常运行。

数据级灾备在实施和演练过程中主要需要考虑数据同步的实效和应用系统的切换逻辑。

系统级灾备方案是在数据灾备方案的基础上，在异地建立一套完整的与本地生产系统相当的备份系统，在灾难发生时，远程系统可迅速接管业务运行。

本方案建议购置相应的主机系统、磁盘阵列，并配置相应的远程网络，在出现异常情况时，可以通过快速切换完成异地灾备中心的启用。

建议采用远程集群技术，使本地生产系统与远程灾备系统组成一套高可用系统。在本地系统发生故障或发生灾难时，在远程集群管理系统的控制下，集群中的远程灾备系统可迅速接管本地生产系统中的应用。该方案的优点是远程灾备系统接管速度快、安全系数高，且不需要人工干预。但需要的网络环境复杂，前期投入大。在操作系统级，使用大容量磁盘阵列，通过磁盘映像技术使每一个数据库文件自动分布于每个物理磁盘。这样，当某个磁盘出现物理损坏时，操作系统会自动使用映像磁盘来取代失效的磁盘，保证数据库的正常运行。

在处理中心使用双数据库服务器，在另一服务器上保留一个备份数据库。备份数据库与正在使用的数据库具有相同的参数状态，这样在数据库故障中，只需做必须的最少恢复，最大限度地缩短了恢复时间。

在多个不同的物理磁盘上保持多个控制文件的备份。控制文件在数据库恢复期间用于引导数据库，因此保持多个控制文件的备份，可以确保在出现磁盘故障后，能有可用的控制文件用于数据库恢复。

针对上述的备份范围，备份类型如下：

对于存储在生产数据库中的数据，作如下考虑：为了保证系统7＊24小时运行，数据库必须运行在ARCHIVELOG模式下。进行数据备份的时候，建议在数据库服务器上本地登录数据库（RMAN），采用每日的数据库增量备份的方式，直接备份到磁带库，每周作一次0级的完全数据库备份。

对于生产数据库的归档日志，它们对于数据库的恢复具有重要意义。可以在每天定时备份数据库当天生成的归档日志，并删除原有文件以节省磁盘空间。如果日志增长过快，可以缩短备份周期至4小时一次。

现有的生产数据库备份依靠每天批处理前的逻辑备份完成，同时逻辑备份的数据置放别处以作为一种异地容灾的手段。在本备份方案最初实施的阶段，逻辑备份仍继续保留已确保备份方案的平滑过渡。在本方案运行平稳后，可考虑减少逻辑备份的次数，仅用于异地容灾的目的。

备份的时机分为日常备份时机与异常备份时机。

在理论上，以上的数据备份方案支持7＊24备份，在任何时机均可以启动，考虑业务量的高峰期及系统的负载均衡因素，应将生产数据库的备份安排在夜间批处理以后进行。

在数据库结构发生变化后，及时完成数据库完全备份。在应用系统发生重大变更后（如增加表空间，数据文件，或完成了一次数据库恢复等），及时完成一次全备份。

数据库数据的恢复主要包括以下内容：数据库的数据发生丢失的情况多种多样，是否进行介质恢复，如果进行介质恢复，需要对数据库进行确诊：数据库是否可以开启；实例是否正常；所有数据文件的标题块是否有效

在上述问题有初步的解答后，确定是否需要进行某些数据的还原，进而确定是否需要恢复。

在进行完全恢复时，依据实际情况，进行两种恢复：整体数据库的恢复与数据库子集的恢复。

系统提供多种交易电子日志信息：

交易记录

交易日志

交易错误日志

并且这些交易电子日志可以根据系统的运行情况进行手工调整，从而调整日志的记录等级。系统日志具备自动清理功能。通过这些文本化交易电子日志，系统管理员可以有效的管理系统，识别非法的交易信息。

2.7.5安全性实现

系统建立在成熟稳定的硬件环境和应用软件基础上，通过完善的备份恢复策略、安全控制机制、可靠的运行管理监控和故障处理手段来保障系统的运行稳定、安全。

系统有严谨周密的安全体系结构，能够提供有效的安全机制，抵御可能产生的恶意攻击和病毒侵蚀，并且在运行安全、网络安全和应用系统安全等方面有合理可靠的策略。安全性设计内容包括：实名认证、数据传输和存储的加密验密、数据的访问控制、操作员的权限控制以及服务器数据的抗故障和抗破坏。

身份实名确认在互联网越来越普及，为了保证用户的真实性、业务的严谨性，系统支持通过对身份证进行实名核验以及通过活体检测对用户信息进行校验。

（1）拦截、避免无效请求，减少付费接口调用次数，节约成本

对于系统服务设计接口，力求做的是便捷调用、入参简洁，记录实名认证接口的调用方、系统来源等，方便流量控制和控制爆刷风险，有迹可循，身份证号、姓名涉及敏感信息，通过加密进行存储。

（2）实名认证，提供同步、异步接口，满足业务不同场景需求

有一些业务功能需要马上验证身份信息是否一致，可提供同步接口；有的则要求时效性不是很高，我们可以提供异步接口，

缩短用户流程操作等待时间。

（3）作为原子型、通用接口，需保障接口高可用

可以根据系统运营情况，接入不同渠道的实名认证接口提供商。系统设计上，支持多个不同渠道认证供应商接口接入，渠道之间可以做切换/互备使用，防止某一个渠道商由于异常而导致整个系统的服务对接不可用。

（4）使用本地数据库保存的实名数据，提高利用率，降低运营成本

每一条实名认证流水、每次实名认证结果，都可用在做好数据加密、安全措施完备的情况下，保存下来可供在一定的时间段内，反复利用，从而不必每次请求都去调用付费接口进行查询。有效时间段的区间是可调配的，一般有效期可设置1个月。换句话说，就是在本地库中查到了有效期范围内的身份实名结果，那么就用该结果处理，无需再外调服务商的提供的付费接口了，很大程度上，节约了运营成本。

为防止恶意者伪造和窃取他人的生物特征用于身份认证，通过眨眼、张嘴、摇头、点头等组合动作，使用人脸关键点定位和人脸追踪等技术，验证用户是否为真实活体本人操作。可有效抵御照片、换脸、面具、遮挡以及屏幕翻拍等常见的攻击手段，从而帮助用户甄别欺诈行为，保障用户的利益。

（1）通过提取活体和非活体人脸区域的256个特征点的三维信息，并对这些点之间的几何结构关系进行了初部的分析处理；

（2）通过提取整个人脸区域的三维信息，并对相应的特征点做进一步的处理，再采用协调训练Co-training的方法训练了正负样本数据，之后利用得到的分类器进行了初分类；

（3）利用以上两个步骤所提取的特征点进行曲面的拟合来描述三维模型特征，然后根据曲面的曲率从深度图像中提取凸起区域，再对每个区域提取EGI特征，最后利用其球形相关度进行再分类识别。

用户认证的流程如下：

操作员进入用户登录界面，输入个人密码，个人密码必须支持至少大写字母、小写字母、数字及特殊字符中的三种组合；

后台系统向安全子系统发起个人密码验证请求；

安全子系统从数据库获取对应的密码加密密钥和操作员的个人密码；

安全子系统通过加密机，验证操作员输入的个人密码是否正确；

对于用户登录失败的，登记用户登录失败连续失败次数，当失败次数超过当天限制的最大连续登录失败次数时，拒绝登录；

安全子系统返回验证结果；

管理控制台页面根据返回的结果显示对应的页面。

权限控制

为保证系统安全，系统要建立严格的机构、柜员、渠道权限等级制度，严格控制各级机构、柜员、渠道的操作权限和数据访问权限。同时按业务的类型建立交易权限集，特定的柜员只能操作规定范围内的交易集，避免对系统有意或无意的破坏，加强管理、防范风险。

权限管理用于对各级柜员、各地机构、接入渠道等使用对象授予不同的交易权限，同时对交易授权权限，交易授权金额权限，交易单笔金额权限，远程交易授权进行管理。

不同级别的机构，对于业务操作的权限是不同的，机构权限确定该机构运行的交易集，对每个机构定义属性、级别和限额。同时，可通过授权的方式为机构增加临时性的限额。

不同的接入渠道，对于业务操作的权限是不同的，渠道权限确定该渠道运行的交易集，对每个渠道定义属性、级别和限额。同时，可通过授权的方式为渠道增加临时性的限额。

不同职责的柜员，对于业务操作的权限是不同的，我们将柜员划分为不同的级别，将业务划分为不同的类别，系统根据柜员的级别、业务类别，操作金额的级别，来确定柜员的业务权限。将操作金额分为不同的限额级别，为每个柜员定义限额级别。

系统根据业务类型的不同、机构的不同、渠道的不同，身份的不同，建立权限集。为便于管理，同时建立一系列柜员角色，每个角色具有一定的业务权限，对应一个或多个权限集，并可灵活调整。各个角色可以具有重叠的权限集，主管部门根据需要建立新的角色，也可以删除不再需要的角色。

数据完整性

传输交易信息时采用MAC认证来保证数据传输的完整性和鉴别消息来源，以保证数据传输的可靠性。采用美国国家标准局公布的信息鉴别码（MAC）算法（ANSIX9.9）。在传输交易信息时交易的发起方根据交易信息生成信息鉴别码MAC并随交易信息发送到交易接受方，交易接受方对信息鉴别码进行验证，以保证信息传输的可靠性和完整性，并确认消息的正确来源，消息在各级的传送过程中，每到一个节点都要鉴别MAC，然后重新计算MAC，放入待发送的消息。换言之，每一段通信线路上传送的消息都将受到真伪的鉴别。

传输文件时采用MAC认证来保证数据传输的完整性。采用美国国家标准局公布的信息鉴别码（MAC）算法（ANSIX9.9）。在传输文件时文件的发送方根据文件信息生成信息鉴别码MAC并随文件通知发送到接收方，接收方对信息鉴别码进行验证，以保证文件传输的可靠性和完整性。

关键数据存储采用DAC认证来保证数据的完整性，使用加密算法对原数据(数据库中数据)或原数据中的关键字段（金额、账号等）进行计算，得到一小段附加数据。这一小段数据与原数据的每一位都相关，使得原数据的每一位的变化都会反映到这小段数据上来。因此，用它可判断原数据的内容是否被改变，出处是否真实。

数据存储安全

系统中有很多十分敏感的数据需要加密如：用个人化数据、手机号、身份证号码，为了确保敏感数据的不可窃取及篡改，采用白盒加密技术来保护。

软件在运行时，有很多十分敏感的数据需要加密如：用户个人密码（PIN）、手机号等会清楚的出现在计算机的内存或磁盘上，使得犯罪分子有机会读取这些数据，破坏系统的安全。针对部分数据采用SM4算法进行硬件加密设置。

数据库访问安全

对于应用系统访问数据库的用户密码需要采用SM4算法进行加密，密钥可以存储在加密机中，为了提供安全等级，也可由加密机提供加解密运算。

应用系统访问安全

业务处理系统内的所有用户在登陆过程中要进行身份验证，防止非法用户对系统的访问。通常采用以下方法：

口令机制，即通过用户输入口令进行身份认证。

使用数字证书来进行用户的身份认证。

传输安全

在保障网络不被侵犯的同时，对网络上传输的信息也要采取必要的安全措施。为了保护用户信息，防止交易消息被篡改，应进行消息真伪的鉴别。硬件加密机是该类子系统的核心，因为硬件加密机自身是一台不可编程的电脑，物理上无法非授权打开，所以保证了电子的主密钥在“黑匣”内的封闭性。主密钥只能在授权后用特殊手段注入硬件加密机。

作为外围设备，它通过ASYNC、X.25或SDLC协议与主机相连。主机和加密机之间通过请求、应答、控制等消息来实现对敏感数据的加密与解密（验证），对消息真伪鉴别和密钥的更换等操作。

消息真伪的鉴别是通过比较消息发送端和消息接收端先后计算出的两个MAC（MassageAuthenticationCode），即消息真伪鉴别码是否匹配而实现的。参与计算MAC的数据有：

消息的若干内容

消息收发双方共同约定的密钥

MAC相当于消息的辨伪标志。伪造消息的企图，只有当伪造者窃取了密钥后才有可能得逞。MAC必须在消息经过的每一节点作鉴别，然后用下次通信线上的密钥重新计算并随消息发送。