股权众筹项目通信系统中迭代开发与开源技术的应用.docx

1、股权众筹项目通信系统中迭代开发与开源技术的应用 股权众筹通信系统中迭代开发与开源技术的应用 目录1. 股权众筹项目介绍.12. 股权众筹通信系统概述.33. 迭代开发在股权众筹通信系统的应用实践.43.1 迭代开发介绍. 43.2 迭代开发的应用实践. 53.3 迭代开发与系统架构. 94. 开源技术在股权众筹通信系统的具体应用.114.1 Spring开源框架 . 114.2 Quartz开源组件 . 144.3 JavaDBF开源组件 . 185. 启示与思考.205.1 系统架构的动态平衡. 205.2 精细化的质量控制. 205.3 开发框架的自主可控. 215.4 系统的规划与稳健的

2、策略. 22 1. 股权众筹项目介绍股权众筹是一种基于互联网渠道进行融资的新模式，依据证监会股权众筹融资试点管理办法（征求意见稿），股权众筹融资必须通过专门的中介平台开展，“发行的股票”应在中国证券登记结算有限责任公司集中登记存管，其市场主体关系如图 1 所示。图1 股权众筹市场主体关系示意图根据与蚂蚁金服等互联网众筹平台对职责分工的商定，中国结算要实现的业务功能主要包括：证券账户开立和管理，登记类业务（初始登记、定向增发等），投资者业务（质押/解质押、司法冻结等），服务费用的计算和收取。股份和资金的清算交收由各平台自行办理。根据业务方案的分期安排，技术系统采用了分期开发、逐步完善的建设策略。

3、对股权众筹账户，采用场内深市封闭式基金账户改造而来的财富管理账户；对登记结算，在新三板登记结算生产系统里部署独立的数据存放环境，与股转市场数据隔离，单独运维；对外通信采用 PROP 与众筹平台对接，同时开发建设独立的内部通信系统，完成数据校验、分拆、合并、存储转发等工作。系统整体架构如图 2 所示。1 股权众筹项目具有典型的互联网特色。在业务需求上，蚂蚁金服、京东众筹等平台的业务实现细节还有一定的差异性；新需求更新频繁，对外数据接口修订至少 7 次；需求响应快、开发周期紧，最初要求40 天完成系统开发。在功能扩展上，一期建设要实现从无到有，满足一天一个登记批次的最低需求，但也要同步规划实施单日

4、多批次的基础功能。在系统性能上，上线第一年要求每日最多为 60 万投资者提供登记，第二年数量增长为 300 万。此外，个性化业务功能，如额度控制，要求我司和众筹平台之间能够实时更新和共享投资者及众筹项目的可用额度，否则在批处理时有可能因为额度超出限定值导致多个平台的项目登记失败，这对登记系统和通信系统提出了新的挑战。图2 股权众筹系统总体架构图2 2. 股权众筹通信系统概述为实现股权众筹一期业务目标，通信系统采用了如下方案：后台通信子系统以新三板通用文件传输模块为基础进行迁移开发，为主机提供文件上下传服务；设计开发数据调度和数据处理服务器，完成数据校验、合并、拆分和备份等功能；迁移改造数据中转

5、服务器，完成登记系统与 UAP 等内部系统间的数据交换；选取 PROP 与股权众筹平台对接，实现对外数据交换功能。通信架构如下图所示。图3股权众筹通信架构示意图在新三板 CCNET 通信系统中，由于在用户侧部署了通信网关，因此在前端实现了时间管理、流量控制、数据校验等功能。在股权众筹通信系统中，PFX 只作为数据传输通道，因此需要设计开发相应的通信服务器，在服务端实现相应的数据控制和处理功能。图 3 中，数据调度服务器与 PFX 部署在同一台物理机，对申报数据进行实时校验和调度。主要功能包括：1）工作日和时间管理，3 对非服务时间收到的申报数据返回错误提示；2）数据实时校验，对申报数据进行合法

6、性检查；3）数据量控制，对记录数超出约定数值的申报返回错误提示；4）调度管理，将通过合法性检查的申报数据推送到数据处理服务器；5）批次控制，根据配置信息和时间节点触发数据调度逻辑，为登记系统单日多批次处理预留空间；6）通信监控。数据处理服务器单独部署在 Linux 操作系统，对数据进行合并、拆分和中转处理。主要功能包括：1）数据合并，接收数据控制服务器推送来的账户和登记申报数据，按照数据接口将不同平台的同类数据进行合并；2）数据拆分，将登记系统和 TA 系统下发的回报数据按不同平台进行拆分；3）数据中转，将合并后的登记申报数据转移到指定目录供登记系统抓取，将合并后的账户申报数据推送至 TA 系

7、统，将拆分后的账户和登记回报数据推送至数据控制服务器，再通过PFX 发送至众筹平台；4）数据备份。3. 迭代开发在股权众筹通信系统的应用实践3.1 迭代开发介绍迭代开发类似不断重复的小型瀑布式项目。根据业务需求的完善程度和项目进度，整个开发工作被划分为一系列短小的小项目，每个小项目的需求与进度是确定的，其阶段目标也是明确的。待上一阶段小项目启动后，再根据最新情况确定下一阶段小项目目标并启动建设。4 与瀑布模型相比，迭代开发更容易适应需求的更新和变化，适合业务需求和项目进度存在不确定性时。迭代开发可以在业务需求完整确定前启动开发，加快了项目实施进度。各迭代阶段完成后的输出物是系统实现，业务和运维

8、人员可以更早地接触技术系统并提出反馈建议，降低了项目实施风险。通过分阶段部署还可以尽早对系统运行进行验证，也降低了运维风险。由于系统架构和功能一直处在更新变化中，因此迭代开发对项目管理和质量控制的要求也比较高。3.2 迭代开发的应用实践股权众筹业务需求的更新非常频繁，据粗略统计，在预计上线时间非常紧张的情况下，其业务需求经历了 11 个版本的变化，关键时间节点和进度安排如下表所示。表1 股权众筹业务需求变更情况示意提出时间需求变更情况进度要求2015.07.03 提出股权众筹建设任务2015.07.09 提出登记存管业务方案初稿2015.07.20 提出登记存管业务需求初稿预计2015年9月底

9、上线同上同上补充更新证券代码、工作日管理等若干业 上线时间预计推迟至102015.08.19务需求2015.08.28 提出账户处理业务方案初稿提出登记存管业务性能需求，补充发起人月中旬预计10月中旬完成联调测试，上线时间顺延2015.09.08同上信息、项目增发等功能需求上线时间预计顺延至122015.10.22 确定账户处理技术方案月初2015.11.03 提出股权众筹投资者适当性管理方案2015.12.02 补充投资者额度控制业务需求同上2016年1月底完成上线准备同上同上2016.01.12 确定账户处理具体需求和流程2016.01.30 补充司法冻结、额度控制等需求细节2016.02

10、.24 补充批处理自动化、系统监控等运维需求 同上5 可见，股权众筹业务需求经历了不断完善的过程，但进度要求始终非常紧张。实际工作中，系统开发与需求完善基本是并行开展，因为在时间紧、任务重的情况下，不可能等到业务需求完全确定再启动开发，而系统开发也为需求完善提供了印证，二者在相互促进中滚动前行。作为提供底层基础设施的通信系统，又是基于开放平台进行自主开发，更是在收到股权众筹建设任务的第一时间启动了相关工作。通信组的主要任务有三个条线，如下表所示。表2 股权众筹通信系统任务条线任务条线受业务需求变化影响程度任务名称任务复杂度低任务说明后台通信系统迁移建设迁移新三板现有后台通信系统1低考察PROP

11、、FDEP、证联网、自主开发 4 种方案，完成选型和系统搭建对外通信系统建设2高高中在业务需求不断更新的情况下制订建设方案并完成项目开发内部前置通信系统建设3高表2 中，任务1 的复杂度和难度最低，任务2 复杂度高但受外界条件影响较大，只有任务3，复杂度和难度最大，但有较大的自主权，是采用迭代开发的工作重点。表3通信组人力分工任务名称分配人力1补充说明中国结算自有员工，分配任务还包括代码审查中国结算自有员工，分配任务还包括代码审查外包商需求分析（含概要设计）详细设计1编码和单元测试集成测试22外包商内部前置通信系统包括数据调度服务器、数据处理服务器、数据6 库服务器和数据中转服务器，为完成系统

12、建设，通信组以现有人力为基础进行了分工，如表 3 所示。从 2015 年 7 月项目启动至 2016 年 2 月对外联调测试结束，通信组进行了多轮迭代，项目总体进展如下图所示。图4股权众筹前置通信系统迭代开发示意图如图 4 所示，各迭代阶段的具体说明如下：1、在迭代一阶段，需求分析经历了 3 个版本的快速变化，因为在项目启动初期，业务需求尚未成型，还处于快速变化中，而且项目前期的架构设计十分重要，所以经历了多次讨论修订。2、迭代二阶段开始启动后，迭代一阶段的开发编码还在进行中，此时业务需求初步定型，功能需求更加完善，而上阶段的开发编码尚未完成，因此将两阶段的开发工作合并进行。3、迭代三阶段又经

13、历了需求的快速更新，因此将前两阶段的开7 发编码继续合并，该阶段编码完成后，系统版本开始相对稳定，因此集成测试也于本阶段开始启动。4、迭代四阶段相对时间较长，因为此时预计上线时间相对宽松，通信需求的变更不再频繁，系统架构也趋于稳定，本阶段工作重点开始转向非功能需求的完善和各项测试工作。5、迭代五阶段由于补充了账户处理功能，确定了对外通信方案，因此又经历了架构的完善，该阶段最接近传统的瀑布开发模型。虽然各迭代阶段的开发流程有所不同，但阶段目标却又非常明确，如下表所示。表4各迭代阶段开发目标说明阶段名称迭代一预期目标完成情况遗留问题针对已知需求迅速启动开发工作；设计合理可扩展的架构，当后续需求明确

14、时可方便的扩充功能完成基本功能开发；明确服务器功能尚需完善，架构划分有待明确、合理性尚待检验系统架构初步确定，部分基本功能开发完成系统架构基本明确，基本功能开发完成迭代二 服务器职能，系统架构更清晰未包括最新需求系统性能等非功前期功能性需求基 能性目标还需完补充最新需求，完善系统迭代三 功能，完成第一个稳定有效的版本本开发完成善，版本稳定性有待测试非功能需求需进一步完善；账户功能还未包括进行性能优化，完善系统 性能得到提升，系统迭代四迭代五监控等非功能需求稳定性进一步增强系统扩展性需要进一步优化，下阶段架构衍进目标待明确系统功能和性能具备了一定的可用性和可靠性补充账户处理功能，阶段性的系统架构

15、定型由上可见，在迭代开发的具体运用中，由于需求更新等外部条件的变化，无法拘泥于教科书模式去流程化的开展各阶段工作，但各阶8 段目标十分明确，正所谓形散而神不散，迭代开发的精髓也正是根据分步走的策略，制订切实可行的小目标，积小胜为大胜，最终实现系统建设的大目标。3.3 迭代开发与系统架构图5迭代开发与系统架构衍进示意图系统架构存在自身的生命周期，迭代开发中的系统架构就一直处于动态衍变中。迭代开发的主要原则就是以架构为中心，在早期迭代中尽快确定系统核心架构，通过几次迭代来尽快设计出能够满足核心需求的系统架构，在之后的开发测试中检验系统架构的有效性、合理性和扩展性，待系统核心架构稳定后，再去实现系统

16、中尚未完成的功能。通过这样累加开发的方式，不断地完善系统，对系统的瑕疵或不足不断地进行重构和改进设计，最终形成阶段性、稳定的系统架构模型。同理，在下阶段项目启动后，以前一阶段的系统架构为基础，对9 其进行设计扩展，作为本阶段的核心架构重复完善的过程，在这样的架构迭代中，架构模型不断完善。当系统架构的潜力被挖到极致，说明系统也到了更新换代的时刻，架构的生命周期也走到了尽头。系统开发与架构设计的迭代阶段不一定重合，如图 5 所示。股权众筹前置通信系统的架构模型也经历了从无到有、边开发边验证、逐步完善的过程。项目启动之初，架构设计的主要问题是确定数据调度和数据处理是由 1 台服务器完成，还是各自分开

17、、独立设计，同时还要将对外通信方案不确定的影响降至最低。迭代 1 阶段，架构模型初步建立，但各服务器的职能划分并不明确；从迭代 1 到迭代 3阶段，架构模型逐渐清晰，服务器功能逐步完善；在迭代 4 阶段，架构的合理性和有效性得到初步验证；在迭代 5 阶段，扩充了账户处理功能，架构的扩展性得到初步验证。架构衍变的过程如下图所示。图6股权众筹前置通信系统架构衍变示意图可见，经过迭代 1 至 5 各阶段衍变，形成了阶段性稳定的系统架构，可以作为下阶段系统架构进一步完善的基础。后续阶段，可以考10 虑将数据调度服务器扩展为集群架构，强化调度管理职能；而数据处理服务器可以考虑并行处理的方式，并结合虚拟化

18、等技术进行动态迁移，进一步提升系统性能和可靠性。4. 开源技术在股权众筹通信系统的具体应用股权众筹前置通信系统基于 Java 语言在 Linux 操作系统完成开发，使用了 My Elipse、DB Visual 等开发工具，选用 Spring 作为系统开发的基础框架，在 Quartz 上实现任务调度功能，通过 JavaDBF 实现对 DBF 文件的操作，具体介绍如下。4.1 Spring 开源框架Spring 核心思想是 D（I Dependency Injection，即依赖注入）和 IoC（Inversion of Control，即控制反转）。Spring 提供了一个容器，通过在 xml

19、 文件里定义各个对象的依赖关系，由容器完成对象的构建。当java 代码里需要使用某个实例的时候就可以从容器里获取，对象的构建就被容器接管。这样，本来属于 java 程序里构建对象的功能交由容器接管，这就是控制反转，当程序要使用某个对象时候，容器会把它注入到程序里，这就是依赖注入。Spring 容器包含了对象创建、销毁、回调等应用对象生命周期的管理和配置，并提供了事务管理，持久层集成等一些基础功能，这样可以使开发人员减少对底层细节的关注而专注于核心应用逻辑。Spring 采用分层架构，如下图所示。11 图7 Spring架构示意图图 7 中，Core container（核心容器）是 Sprin

20、g 架构的核心，其中的 core 和 beans 两个模块，提供了框架的基本支持，控制了对象的构成，包含了 IoC（控制反转）和 DI（依赖注入）特性，是 Spring 架构的基础。context 建立在 core 和 beans 模块之上，继承了 beans 模块特性同时增加了国际化支持、资源访问、上下文构建等功能，还支持EJB 等 JavaEE 功能。spel 是一种表达式语言，支持在运行时查询和操作对象的属性。Data access 是 Spring 对数据层提供的支持，包括了JDBC、ORM、JMS 等一系列功能。Spring 框架还提供了对 web 应用的支持，以及 AOP（面向切面

21、）、Instrumentation（设备）、Messaging（消息发送）等多方面的功能。在股权众筹前置通信系统建设中，主要选用了 Spring 框架下 Corecontainer 和 Data access 的部分核心组件，如下图所示。12 图7 Spring在前置通信系统的应用示意图系统开发时，首先在程序中定义好具体类，在类中写明需要用到的属性和该属性的 set 方法，方便 spring 进行注入，然后在 Spring.xml中定义各个对象的依赖关系，即可实现程序对象的控制反转和依赖注入。之后，将 Spring.xml 文件和 Spring 相应的 jar 包在路径中加以引用，就可直接调用

22、 Spring 框架提供的各种 API 进行应用逻辑开发。以数据库操作为例，在前置通信系统中，无论是数据调度服务器还是数据处理服务器，在文件校验、合并、拆分时都需要对数据库进行访问以获取基本的配置信息并对处理状态进行更新，这些操作都是通过Spring 中 Data access 所提供的 jdbc 来完成。首先在代码中直接引用Spring 核心类 jdbcTemplate，并沿用其类属性和 set 方法，然后在Spring.xml 中配置 jdbcTemplet 的 beans 标签，并引用 datasource，在datasource 的 beans 标 签 中 配 置 引 入 common

23、s-collection.jar 、commons-dbcp.jar、commons-pool.jar，以进行数据源连接和管理，这样，在程序中就可以直接使用 jdbcTemplate 类下的 query、update 等13 方法，方便的实现数据库访问。从文件大小与运行开销两方面讲，Spring 都是一个轻量级框架，在无需占用太多系统资源的前提下通过简单的定义和引用就可方便的使用。通过容器，将对象之间的依赖关系交给 Spring，使开发人员专注于具体的业务逻辑，不用关心对象创建、销毁等非核心的操作。通过框架提供的数据访问功能，不需考虑过多底层细节即可方便的进行数据库操作，这些特性都有效的提升了

24、开发效率。同时，Spring 还具有低侵入性，开发时无需引入框架代码的信息，这也降低了用户代码与框架的耦合，使得核心代码无需修改即可在不同环境进行迁移。不过，使用灵活也提高了出错的概率，开发人员需要更加关注Spring.xml 文件中对象依赖关系的定义，如果发生配置错误则对程序有致命的影响，而且类似的错误隐藏也比较深，不易查找，这也是Spring 容器在提供便利的同时，新提出的复杂性。4.2 Quartz 开源组件Quartz 是 OpenSymphony 开源组织提供的任务调度解决方案，它对任务调度领域的问题进行了高度抽象，提出了调度器（Scheduler）、任务（Job）和触发器（Trig

25、ger）等核心概念。Quartz 提供了强大的任务调度机制，允许开发人员灵活地定义触发器调度时间表，并对触发器和任务进行关联映射，同时又保持了使用的简单性。Quartz 是独立运转的框架，有独立的配置文件，开发时只需在 lib里引用 Quartz 开源 jar 包，并配置好任务扫描目录及调度时间即可。14 Quartz 中的主要组件如下： JobJob 是一个接口，只有一个方法 void execute(JobExecutionContextcontext)，开发者通过该接口定义运行任务，JobExecutionContext 类提供了调度上下文的各种信息。Job 运行时的信息保存在 JobD

26、ataMap实例中。Job 有一个 StatefulJob 子接口，代表有状态的任务，该接口是一个没有方法的标签接口，其目的是让 Quartz 知道任务的类型，以便采用不同的执行方案。无状态任务在执行时拥有自己的JobDataMap 拷贝，对 JobDataMap 的更改不会影响下次的执行。而有状态任务共享同一个 JobDataMap 实例，每次任务执行对 JobDataMap所做的更改会保存下来，后面的执行可以看到这个更改，即每次执行任务后都会对后面的执行发生影响，正因为这个原因，无状态的 Job可以并发执行，而有状态的 StatefulJob 不能并发执行。 JobDetailQuartz

27、 在每次执行 Job 时，都会重新创建一个 Job 实例，它不直接接受一个 Job 的实例，相反它接收一个 Job 实现类，以便运行时通过 newInstance()实例化 Job。因此需要通过一个实现类来描述 Job 及Job 名字、描述、关联监听器、业务逻辑等相关信息，JobDetail 承担了这一角色。 TriggerTrigger是一个类，描述触发Job的时间规则。主要有SimpleTrigger和 CronTrigger 两个子类。SimpleTrigger 适用于仅需触发一次或者以15 固定时间间隔执行的场景，而 CronTrigger 可以通过 Cron 表达式定义出各种复杂时间

28、规则的调度。 SchedulerScheduler 代表一个 Quartz 的独立运行容器，Trigger 和 JobDetail可以注册到 Scheduler 中，两者在 Scheduler 中拥有各自唯一的组及名称，组及名称是 Scheduler 定位容器中某一对象的依据。Scheduler 定义了多个方法，允许外部通过组及名称访问和控制容器中 Trigger 和JobDetail。Scheduler 可以将 Trigger 绑定到某一 JobDetail 中，这样当Trigger 触发时，对应的 Job 就被执行。一个 Job 可以对应多个 Trigger，但一个 Trigger 只能对应一个 Job。 ThreadPoolScheduler 使用一个线程池作为任务运行的基础设施，任务通过共享线程池中的线程提高运行效率。图8 Quartz在股权众筹