股权众筹项目通信系统中迭代开发与开源技术的应用.docx
《股权众筹项目通信系统中迭代开发与开源技术的应用.docx》由会员分享，可在线阅读，更多相关《股权众筹项目通信系统中迭代开发与开源技术的应用.docx（38页珍藏版）》请在冰豆网上搜索。
股权众筹项目通信系统中迭代开发与开源技术的应用
股权众筹通信系统中迭代开发与开源技术的应用
目录
1.股权众筹项目介绍............................................................................1
2.股权众筹通信系统概述....................................................................3
3.迭代开发在股权众筹通信系统的应用实践....................................4
3.1迭代开发介绍.....................................4
3.2迭代开发的应用实践...............................5
3.3迭代开发与系统架构...............................9
4.开源技术在股权众筹通信系统的具体应用..................................11
4.1Spring开源框架..................................11
4.2Quartz开源组件..................................14
4.3JavaDBF开源组件................................18
5.启示与思考......................................................................................20
5.1系统架构的动态平衡..............................20
5.2精细化的质量控制................................20
5.3开发框架的自主可控..............................21
5.4系统的规划与稳健的策略..........................22
1.股权众筹项目介绍
股权众筹是一种基于互联网渠道进行融资的新模式，依据证监会
《股权众筹融资试点管理办法（征求意见稿）》，股权众筹融资必须通
过专门的中介平台开展，“发行的股票”应在中国证券登记结算有限责任公司集中登记存管，其市场主体关系如图1所示。
图1股权众筹市场主体关系示意图
根据与蚂蚁金服等互联网众筹平台对职责分工的商定，中国结算
要实现的业务功能主要包括：
证券账户开立和管理，登记类业务（初
始登记、定向增发等），投资者业务（质押/解质押、司法冻结等），
服务费用的计算和收取。
股份和资金的清算交收由各平台自行办理。
根据业务方案的分期安排，技术系统采用了分期开发、逐步完善
的建设策略。
对股权众筹账户，采用场内深市封闭式基金账户改造而
来的财富管理账户；对登记结算，在新三板登记结算生产系统里部署
独立的数据存放环境，与股转市场数据隔离，单独运维；对外通信采
用PROP与众筹平台对接，同时开发建设独立的内部通信系统，完成
数据校验、分拆、合并、存储转发等工作。
系统整体架构如图2所示。
1
股权众筹项目具有典型的互联网特色。
在业务需求上，蚂蚁金服、
京东众筹等平台的业务实现细节还有一定的差异性；新需求更新频繁，
对外数据接口修订至少7次；需求响应快、开发周期紧，最初要求
40天完成系统开发。
在功能扩展上，一期建设要实现从无到有，满
足一天一个登记批次的最低需求，但也要同步规划实施单日多批次的
基础功能。
在系统性能上，上线第一年要求每日最多为60万投资者
提供登记，第二年数量增长为300万。
此外，个性化业务功能，如额
度控制，要求我司和众筹平台之间能够实时更新和共享投资者及众筹
项目的可用额度，否则在批处理时有可能因为额度超出限定值导致多
个平台的项目登记失败，这对登记系统和通信系统提出了新的挑战。
图2股权众筹系统总体架构图
2
2.股权众筹通信系统概述
为实现股权众筹一期业务目标，通信系统采用了如下方案：
后台
通信子系统以新三板通用文件传输模块为基础进行迁移开发，为主机
提供文件上下传服务；设计开发数据调度和数据处理服务器，完成数
据校验、合并、拆分和备份等功能；迁移改造数据中转服务器，完成
登记系统与UAP等内部系统间的数据交换；选取PROP与股权众筹
平台对接，实现对外数据交换功能。
通信架构如下图所示。
图3股权众筹通信架构示意图
在新三板CCNET通信系统中，由于在用户侧部署了通信网关，
因此在前端实现了时间管理、流量控制、数据校验等功能。
在股权众
筹通信系统中，PFX只作为数据传输通道，因此需要设计开发相应的
通信服务器，在服务端实现相应的数据控制和处理功能。
图3中，数据调度服务器与PFX部署在同一台物理机，对申报
数据进行实时校验和调度。
主要功能包括：
1）工作日和时间管理，
3
对非服务时间收到的申报数据返回错误提示；2）数据实时校验，对
申报数据进行合法性检查；3）数据量控制，对记录数超出约定数值
的申报返回错误提示；4）调度管理，将通过合法性检查的申报数据
推送到数据处理服务器；5）批次控制，根据配置信息和时间节点触
发数据调度逻辑，为登记系统单日多批次处理预留空间；6）通信监
控。
数据处理服务器单独部署在Linux操作系统，对数据进行合并、
拆分和中转处理。
主要功能包括：
1）数据合并，接收数据控制服务
器推送来的账户和登记申报数据，按照数据接口将不同平台的同类数
据进行合并；2）数据拆分，将登记系统和TA系统下发的回报数据
按不同平台进行拆分；3）数据中转，将合并后的登记申报数据转移
到指定目录供登记系统抓取，将合并后的账户申报数据推送至TA系
统，将拆分后的账户和登记回报数据推送至数据控制服务器，再通过
PFX发送至众筹平台；4）数据备份。
3.迭代开发在股权众筹通信系统的应用实践
3.1迭代开发介绍
迭代开发类似不断重复的小型瀑布式项目。
根据业务需求的完善
程度和项目进度，整个开发工作被划分为一系列短小的小项目，每个
小项目的需求与进度是确定的，其阶段目标也是明确的。
待上一阶段
小项目启动后，再根据最新情况确定下一阶段小项目目标并启动建设。
4
与瀑布模型相比，迭代开发更容易适应需求的更新和变化，适合
业务需求和项目进度存在不确定性时。
迭代开发可以在业务需求完整
确定前启动开发，加快了项目实施进度。
各迭代阶段完成后的输出物
是系统实现，业务和运维人员可以更早地接触技术系统并提出反馈建
议，降低了项目实施风险。
通过分阶段部署还可以尽早对系统运行进
行验证，也降低了运维风险。
由于系统架构和功能一直处在更新变化
中，因此迭代开发对项目管理和质量控制的要求也比较高。
3.2迭代开发的应用实践
股权众筹业务需求的更新非常频繁，据粗略统计，在预计上线时
间非常紧张的情况下，其业务需求经历了11个版本的变化，关键时
间节点和进度安排如下表所示。
表1股权众筹业务需求变更情况示意
提出时间
需求变更情况
进度要求
2015.07.03提出股权众筹建设任务
2015.07.09提出登记存管业务方案初稿
2015.07.20提出登记存管业务需求初稿
预计2015年9月底上线
同上
同上
补充更新证券代码、工作日管理等若干业上线时间预计推迟至10
2015.08.19
务需求
2015.08.28提出账户处理业务方案初稿
提出登记存管业务性能需求，补充发起人
月中旬
预计10月中旬完成联调
测试，上线时间顺延
2015.09.08
同上
信息、项目增发等功能需求
上线时间预计顺延至12
2015.10.22确定账户处理技术方案
月初
2015.11.03提出股权众筹投资者适当性管理方案
2015.12.02补充投资者额度控制业务需求
同上
2016年1月底完成上线
准备
同上
同上
2016.01.12确定账户处理具体需求和流程
2016.01.30补充司法冻结、额度控制等需求细节
2016.02.24补充批处理自动化、系统监控等运维需求同上
5
可见，股权众筹业务需求经历了不断完善的过程，但进度要求始
终非常紧张。
实际工作中，系统开发与需求完善基本是并行开展，因
为在时间紧、任务重的情况下，不可能等到业务需求完全确定再启动
开发，而系统开发也为需求完善提供了印证，二者在相互促进中滚动
前行。
作为提供底层基础设施的通信系统，又是基于开放平台进行自
主开发，更是在收到股权众筹建设任务的第一时间启动了相关工作。
通信组的主要任务有三个条线，如下表所示。
表2股权众筹通信系统任务条线
任务
条线
受业务需求变
化影响程度
任务名称
任务复杂度
低
任务说明
后台通信系统
迁移建设
迁移新三板现有后台
通信系统
1
低
考察PROP、FDEP、证
联网、自主开发4种
方案，完成选型和系
统搭建
对外通信系统
建设
2
高
高
中
在业务需求不断更新
的情况下制订建设方
案并完成项目开发
内部前置通信
系统建设
3
高
表2中，任务1的复杂度和难度最低，任务2复杂度高但受外界
条件影响较大，只有任务3，复杂度和难度最大，但有较大的自主权，
是采用迭代开发的工作重点。
表3通信组人力分工
任务名称
分配人力
1
补充说明
中国结算自有员工，
分配任务还包括代码审查
中国结算自有员工，
分配任务还包括代码审查
外包商
需求分析（含概要设计）
详细设计
1
编码和单元测试
集成测试
2
2
外包商
内部前置通信系统包括数据调度服务器、数据处理服务器、数据
6
库服务器和数据中转服务器，为完成系统建设，通信组以现有人力为
基础进行了分工，如表3所示。
从2015年7月项目启动至2016年2月对外联调测试结束，通信
组进行了多轮迭代，项目总体进展如下图所示。
图4股权众筹前置通信系统迭代开发示意图
如图4所示，各迭代阶段的具体说明如下：
1、在迭代一阶段，需求分析经历了3个版本的快速变化，因为
在项目启动初期，业务需求尚未成型，还处于快速变化中，而且项目
前期的架构设计十分重要，所以经历了多次讨论修订。
2、迭代二阶段开始启动后，迭代一阶段的开发编码还在进行中，
此时业务需求初步定型，功能需求更加完善，而上阶段的开发编码尚
未完成，因此将两阶段的开发工作合并进行。
3、迭代三阶段又经历了需求的快速更新，因此将前两阶段的开
7
发编码继续合并，该阶段编码完成后，系统版本开始相对稳定，因此
集成测试也于本阶段开始启动。
4、迭代四阶段相对时间较长，因为此时预计上线时间相对宽松，
通信需求的变更不再频繁，系统架构也趋于稳定，本阶段工作重点开
始转向非功能需求的完善和各项测试工作。
5、迭代五阶段由于补充了账户处理功能，确定了对外通信方案，
因此又经历了架构的完善，该阶段最接近传统的瀑布开发模型。
虽然各迭代阶段的开发流程有所不同，但阶段目标却又非常明确，
如下表所示。
表4各迭代阶段开发目标说明
阶段名称
迭代一
预期目标
完成情况
遗留问题
针对已知需求迅速启动
开发工作；设计合理可扩
展的架构，当后续需求明
确时可方便的扩充功能
完成基本功能开发；明确
服务器功能尚需
完善，架构划分有
待明确、合理性尚
待检验
系统架构初步确定，
部分基本功能开发
完成
系统架构基本明确，
基本功能开发完成
迭代二服务器职能，系统架构更
清晰
未包括最新需求
系统性能等非功
前期功能性需求基能性目标还需完
补充最新需求，完善系统
迭代三功能，完成第一个稳定有
效的版本
本开发完成
善，版本稳定性有
待测试
非功能需求需进
一步完善；账户功
能还未包括
进行性能优化，完善系统性能得到提升，系统
迭代四
迭代五
监控等非功能需求
稳定性进一步增强
系统扩展性需要
进一步优化，下阶
段架构衍进目标
待明确
系统功能和性能具
备了一定的可用性
和可靠性
补充账户处理功能，阶段
性的系统架构定型
由上可见，在迭代开发的具体运用中，由于需求更新等外部条件
的变化，无法拘泥于教科书模式去流程化的开展各阶段工作，但各阶
8
段目标十分明确，正所谓形散而神不散，迭代开发的精髓也正是根据
分步走的策略，制订切实可行的小目标，积小胜为大胜，最终实现系
统建设的大目标。
3.3迭代开发与系统架构
图5迭代开发与系统架构衍进示意图
系统架构存在自身的生命周期，迭代开发中的系统架构就一直处
于动态衍变中。
迭代开发的主要原则就是以架构为中心，在早期迭代
中尽快确定系统核心架构，通过几次迭代来尽快设计出能够满足核心
需求的系统架构，在之后的开发测试中检验系统架构的有效性、合理
性和扩展性，待系统核心架构稳定后，再去实现系统中尚未完成的功
能。
通过这样累加开发的方式，不断地完善系统，对系统的瑕疵或不
足不断地进行重构和改进设计，最终形成阶段性、稳定的系统架构模
型。
同理，在下阶段项目启动后，以前一阶段的系统架构为基础，对
9
其进行设计扩展，作为本阶段的核心架构重复完善的过程，在这样的
架构迭代中，架构模型不断完善。
当系统架构的潜力被挖到极致，说
明系统也到了更新换代的时刻，架构的生命周期也走到了尽头。
系统
开发与架构设计的迭代阶段不一定重合，如图5所示。
股权众筹前置通信系统的架构模型也经历了从无到有、边开发边
验证、逐步完善的过程。
项目启动之初，架构设计的主要问题是确定
数据调度和数据处理是由1台服务器完成，还是各自分开、独立设计，
同时还要将对外通信方案不确定的影响降至最低。
迭代1阶段，架构
模型初步建立，但各服务器的职能划分并不明确；从迭代1到迭代3
阶段，架构模型逐渐清晰，服务器功能逐步完善；在迭代4阶段，架
构的合理性和有效性得到初步验证；在迭代5阶段，扩充了账户处理
功能，架构的扩展性得到初步验证。
架构衍变的过程如下图所示。
图6股权众筹前置通信系统架构衍变示意图
可见，经过迭代1至5各阶段衍变，形成了阶段性稳定的系统架
构，可以作为下阶段系统架构进一步完善的基础。
后续阶段，可以考
10
虑将数据调度服务器扩展为集群架构，强化调度管理职能；而数据处
理服务器可以考虑并行处理的方式，并结合虚拟化等技术进行动态迁
移，进一步提升系统性能和可靠性。
4.开源技术在股权众筹通信系统的具体应用
股权众筹前置通信系统基于Java语言在Linux操作系统完成开
发，使用了MyElipse、DBVisual等开发工具，选用Spring作为系统
开发的基础框架，在Quartz上实现任务调度功能，通过JavaDBF实
现对DBF文件的操作，具体介绍如下。
4.1Spring开源框架
Spring核心思想是D（IDependencyInjection，即依赖注入）和IoC
（InversionofControl，即控制反转）。
Spring提供了一个容器，通过
在xml文件里定义各个对象的依赖关系，由容器完成对象的构建。
当
java代码里需要使用某个实例的时候就可以从容器里获取，对象的构
建就被容器接管。
这样，本来属于java程序里构建对象的功能交由
容器接管，这就是控制反转，当程序要使用某个对象时候，容器会把
它注入到程序里，这就是依赖注入。
Spring容器包含了对象创建、销
毁、回调等应用对象生命周期的管理和配置，并提供了事务管理，持
久层集成等一些基础功能，这样可以使开发人员减少对底层细节的关
注而专注于核心应用逻辑。
Spring采用分层架构，如下图所示。
11
图7Spring架构示意图
图7中，Corecontainer（核心容器）是Spring架构的核心，其中
的core和beans两个模块，提供了框架的基本支持，控制了对象的构
成，包含了IoC（控制反转）和DI（依赖注入）特性，是Spring架
构的基础。
context建立在core和beans模块之上，继承了beans模块
特性同时增加了国际化支持、资源访问、上下文构建等功能，还支持
EJB等JavaEE功能。
spel是一种表达式语言，支持在运行时查询和
操作对象的属性。
Dataaccess是Spring对数据层提供的支持，包括了
JDBC、ORM、JMS等一系列功能。
Spring框架还提供了对web应用
的支持，以及AOP（面向切面）、Instrumentation（设备）、Messaging
（消息发送）等多方面的功能。
在股权众筹前置通信系统建设中，主要选用了Spring框架下Core
container和Dataaccess的部分核心组件，如下图所示。
12
图7Spring在前置通信系统的应用示意图
系统开发时，首先在程序中定义好具体类，在类中写明需要用到
的属性和该属性的set方法，方便spring进行注入，然后在Spring.xml
中定义各个对象的依赖关系，即可实现程序对象的控制反转和依赖注
入。
之后，将Spring.xml文件和Spring相应的jar包在路径中加以引
用，就可直接调用Spring框架提供的各种API进行应用逻辑开发。
以数据库操作为例，在前置通信系统中，无论是数据调度服务器还是
数据处理服务器，在文件校验、合并、拆分时都需要对数据库进行访
问以获取基本的配置信息并对处理状态进行更新，这些操作都是通过
Spring中Dataaccess所提供的jdbc来完成。
首先在代码中直接引用
Spring核心类jdbcTemplate，并沿用其类属性和set方法，然后在
Spring.xml中配置jdbcTemplet的beans标签，并引用datasource，在
datasource的beans标签中配置引入commons-collection.jar、
commons-dbcp.jar、commons-pool.jar，以进行数据源连接和管理，这
样，在程序中就可以直接使用jdbcTemplate类下的query、update等
13
方法，方便的实现数据库访问。
从文件大小与运行开销两方面讲，Spring都是一个轻量级框架，
在无需占用太多系统资源的前提下通过简单的定义和引用就可方便
的使用。
通过容器，将对象之间的依赖关系交给Spring，使开发人员
专注于具体的业务逻辑，不用关心对象创建、销毁等非核心的操作。
通过框架提供的数据访问功能，不需考虑过多底层细节即可方便的进
行数据库操作，这些特性都有效的提升了开发效率。
同时，Spring还
具有低侵入性，开发时无需引入框架代码的信息，这也降低了用户代
码与框架的耦合，使得核心代码无需修改即可在不同环境进行迁移。
不过，使用灵活也提高了出错的概率，开发人员需要更加关注
Spring.xml文件中对象依赖关系的定义，如果发生配置错误则对程序
有致命的影响，而且类似的错误隐藏也比较深，不易查找，这也是
Spring容器在提供便利的同时，新提出的复杂性。
4.2Quartz开源组件
Quartz是OpenSymphony开源组织提供的任务调度解决方案，它
对任务调度领域的问题进行了高度抽象，提出了调度器（Scheduler）、
任务（Job）和触发器（Trigger）等核心概念。
Quartz提供了强大的
任务调度机制，允许开发人员灵活地定义触发器调度时间表，并对触
发器和任务进行关联映射，同时又保持了使用的简单性。
Quartz是独立运转的框架，有独立的配置文件，开发时只需在lib
里引用Quartz开源jar包，并配置好任务扫描目录及调度时间即可。
14
Quartz中的主要组件如下：
Job
Job是一个接口，只有一个方法voidexecute（JobExecutionContext
context），开发者通过该接口定义运行任务，JobExecutionContext类提
供了调度上下文的各种信息。
Job运行时的信息保存在JobDataMap
实例中。
Job有一个StatefulJob子接口，代表有状态的任务，该接口
是一个没有方法的标签接口，其目的是让Quartz知道任务的类型，
以便采用不同的执行方案。
无状态任务在执行时拥有自己的
JobDataMap拷贝，对JobDataMap的更改不会影响下次的执行。
而有
状态任务共享同一个JobDataMap实例，每次任务执行对JobDataMap
所做的更改会保存下来，后面的执行可以看到这个更改，即每次执行
任务后都会对后面的执行发生影响，正因为这个原因，无状态的Job
可以并发执行，而有状态的StatefulJob不能并发执行。
JobDetail
Quartz在每次执行Job时，都会重新创建一个Job实例，它不直
接接受一个Job的实例，相反它接收一个Job实现类，以便运行时通
过newInstance（）实例化Job。
因此需要通过一个实现类来描述Job及
Job名字、描述、关联监听器、业务逻辑等相关信息，JobDetail承担
了这一角色。
Trigger
Trigger是一个类，描述触发Job的时间规则。
主要有SimpleTrigger
和CronTrigger两个子类。
SimpleTrigger适用于仅需触发一次或者以
15
固定时间间隔执行的场景，而CronTrigger可以通过Cron表达式定义
出各种复杂时间规则的调度。
Scheduler
Scheduler代表一个Quartz的独立运行容器，Trigger和JobDetail
可以注册到Scheduler中，两者在Scheduler中拥有各自唯一的组及名
称，组及名称是Scheduler定位容器中某一对象的依据。
Scheduler定
义了多个方法，允许外部通过组及名称访问和控制容器中Trigger和
JobDetail。
Scheduler可以将Trigger绑定到某一JobDetail中，这样当
Trigger触发时，对应的Job就被执行。
一个Job可以对应多个Trigger，
但一个Trigger只能对应一个Job。
ThreadPool
Scheduler使用一个线程池作为任务运行的基础设施，任务通过
共享线程池中的线程提高运行效率。
图8Quartz在股权众筹
升级会员 