保 密 承 诺
本技术方案内容涉及本项目组商业秘密，仅对有投资意向的领
导公开。本项目组要求各位领导收到本技术方案书时做出以下承诺：
妥善保管本技术方案书，未经本项目组同意，不得向第三方公
开本技术方案书涉及的本项目组的商业秘密。
领导签字：
接 收 日 期：
年
月
日
1
1 目录
2
第一部分 执行摘要 .................................................................................... 3
2.1 方案背景 ........................................................................................... 3
2.2 需求分析 ........................................................................................... 4
2.3 技术选型（彭博文） ......................................................................... 5
3
第二部分 管理团队 .................................................................................... 6
4
第三部分 整体设计 .................................................................................... 6
4.1 架构分析 ........................................................................................... 6
4.1.1 单体架构分析 .......................................................................... 6
4.1.2 微服务应用现状 ....................................................................... 8
4.1.3 目前资产业务架构分析 ............................................................ 8
4.2 设计方案 ........................................................................................... 8
4.2.1 系统功能简介（曹磊，谭铭杰） .............................................. 8
4.2.2 方案实现与设计思路（彭博文，张婷婷） ............................. 10
5
第四部分 平台设计原则 ........................................................................... 11
5.1 系统平台设计原则........................................................................... 11
5.1.1 高可靠性原则 ........................................................................ 11
5.1.2 安全性原则 ............................................................................ 11
5.1.3 可维护性原则 ........................................................................ 12
5.1.4 全备份 (Full Backup) ............................................................ 12
5.1.5 增量备份 (Incremental Backup) ............................................ 12
6
第五部分 参考文献 .................................................................................. 14
2
2 第一部分 执行摘要
2.1 方案背景
紫越公司的资产业务已经发展数年，主要客户是学校，根据学校的特点和
使用系统的用户规模，资产系统一直使用 MVC 架构进行建设和维护。多年来
并未遇到架构问题与技术瓶颈。
3
但根据技术的发展路径，与目前市场竞争的双重压力，目前的垂直架构模
式无法在市场中脱颖而出，业务变化的响应速度与模块化部署都无法满足客户
需求。目前有些客户已经明确要求需要资产系统按模块提供微服务能力。例
如：浙江农林，建桥学院等。
除外部竞争压力，资产系统本身的架构方式以及积累多年的技术经验导致
了目前系统庞大，资产系统的生命周期已经处于末端，如不变革必然下行。
经多学校的资产实践，资产业务的精简化是一个系统发展的必然趋势，资
产系统给客户带来的不应该是复杂繁琐的业务流程，在全校师生参与资产管理
的今天，精简的系统和操作流程是未来资产系统发展和新生的必然趋势。目前
的垂直结构会使以往积累的资产管理经验变成负担，牵一发而动全身，因此架
构的革新势在必行。
2.2 需求分析

资产全生命周期微服务化
资产生命周期模块的拆分如下，需按模块提供微服务对接能力。
1) 预算、项目、计划
2) 申购，采购
3) 验收入库
4
4) 资产日常管理
5) 资产处置
6) 资产盘点

数据统计分析库与业务库分离
资产报表的统计与资产数据的定时快照备份、折旧需与主库做分离，不影响
主库业务。
1) 资产折旧
2) 资产卡片快照
3) 资产统计分析

移动端的完善
建立完善的移动端，支持微信企业号与 APP，精简系统操作，提供便利的审
批和移动办公功能。
2.3 技术选型（彭博文）
描述下需要使用的技术与原因
架构图
选型此技术的原因
5
3 第二部分 管理团队
4 第三部分 整体设计
4.1 架构分析
4.1.1单体架构分析

什么是单体架构
一个归档包（例如 war 格式）包含了应用所有功能的应用程序，我们通常
称之为单体应用。架构单体应用的方法论，我们称之为单体应用架构。

单体架构示例图
6

单体架构的缺陷
a) 复杂性高。整个项目包含的模块非常多，模块的边界模糊，依赖关系不
清晰，代码质量参差不齐。每次修改代码都心惊胆战，甚至添加一个简
单的功能，或者修改一个 BUG 都会造成隐含的缺陷。
b) 技术债务。随着时间推移、需求变更和人员更迭，会逐渐形成应用程序
的技术债务，并且越积越多。已使用的系统设计或代码难以修改，因为
应用程序的其他模块可能会以意料之外的方式使用它。
c) 部署频率低。随着代码的增加，构建和部署的时间也会增加。而在单体
应用中，每次功能的变更或缺陷的修复都会导致我们需要重新部署整个
应用。全量部署的方式耗时长、影响范围大、风险高，这使得单体应用
项目上线部署的频率较低，从而又导致两次发布之间会有大量功能变更
和缺陷修复，出错概率较高。
d) 扩展能力受限。单体应用只能作为一个整体进行扩展，无法结合业务模
块的特点进行伸缩。
e) 阻碍技术创新。单体应用往往使用统一的技术平台或方案解决所有问题，
7
团队的每个成员都必须使用相同的开发语言和架构，想要引入新的框架
或技术平台非常困难。
由于单体架构的缺陷日益明显，所以越来越多的公司采用微服务架构范式
解决上面提到的单体架构中的问题。不同于构建单一、庞大的应用，微服务架
构将应用拆分为一套小且互相关联的服务。
4.1.2微服务应用现状
描述下微服务应用场景，市场现状，和我们使用微服务达到的目的。
4.1.3目前资产业务架构分析
描述下目前资产架构存在的问题，以及应用微服务后能达到的效果。
4.2 设计方案
4.2.1系统功能简介（曹磊，谭铭杰）
模块
子模块
功能点
面料关键词检索
店铺关键词检索
图片照料
网站
首页
商品分类（全部商品）
款式分类
广告轮播
8
趋势
推介面料
优质商家
发布求购
页脚内容页
友情链接
左右导航栏
3D 试衣
商品条件检索
面料列表页
趋势参考
同款推介
店铺详情页
增加收藏、取消，登录后查看联系方式
收藏管理
新增收藏管理
搜索结果
在搜索（文字、图片）无结果时，增加面料推荐
交易流程
付款方式（支持支付宝、汇天下）
导出报表
管理端
广告后台管理
款式找料
移动
App
找灵感
设计师首页
女装、男装、童装、进口面料
优质商家
9
款式分类
广告
广告轮播
面料上传技巧
商家首页
优料宝商户手册教你如何提高订单量
分享功能
分类
发布面料
面料名称（现在是拼接的）
面料详情页
界面优化
在 7 月 9-11 号期间，新用户注册后系统自动发一张
优惠券
满 30-10 的优惠券到用户账号内，发送后不用任何
提示。
趋势列表
Tab 标签的内容
趋势详情
隐藏上传面料入口，将“使用优料宝精品面料 3D 试
衣”
3D 试衣
修改为“使用店铺面料 3D 试衣”，进入后筛选结果为
当前
商户的所有面料
4.2.2方案实现与设计思路（彭博文，张婷婷）
描述下具体的实现过程与思路
10
5 第四部分 平台设计原则
5.1 系统平台设计原则
5.1.1高可靠性原则
1) 系统支持连续 7×24 小时不间断地工作。应用软件中的任一构件更新、加载
时，在不更新与上下构件的接口的前提下，不影响业务运转和服务。
2) 系统支持负载均衡能力，支持应用部署在多台服务器上，避免应用系统的单
点故障。冗余点在单台设备软硬件故障情况下，系统所承载业务仍正常提供
且服务质量不劣化。
5.1.2安全性原则
1) 系统提供有效的安全保密措施，确保系统和数据资源的安全，防止对系统资
源的非法侵入，对违背安全事件记录并报警；
2) 提供联机的数据备份能力，保证数据的完整性和有效性；
3) 不同的操作员具有不同的数据访问权限和功能操作权限，系统管理员能对各
操作员的权限进行配置和管理。
4) 对数据库/应用主机等设备，系统管理员能方便灵活、定期对密码进行修改，
不影响业务的正常运行。
11
5.1.3可维护性原则
1) 系统易于分析和测试。
2) 系统易于修改，对某一个系统的修改，不影响其他系统的正常运行。
3) 系统易于扩展，新增服务时要求对系统做尽可能少的修改。
4) 系统具备自管理和监控功能，能够实时监控各模块的执行。
5) 系统在发生主备切换时，系统从系统软件到应用软件均能完成自动启动而不
需要人为干预。
5.1.4全备份 (Full Backup)
每次备份定义的所有数据，优点是恢复快，缺点是备份数据量大，数据多
时可能做一次全备份需很长时间
5.1.5增量备份 (Incremental Backup)
增量备份又分为差量备份和累计备份。
 差量备份 (Differential Backup)
备份自上一次备份以来更新的所有数据，其优点是每次备份的数据量少，
缺点是恢复时需要全备份及多份增量备份。
 累计备份 (Cumulative Backup)
备份自上一次全备份以来更新的所有数据。
从应用角度划分，数据库备份分为脱机与在线备份两种方式。脱机备份是
指在数据库系统加载而未打开方式的情况下进行的备份，有时也称冷备份。冷
12
备份进行时实际是将数据库的相关文件作为文件系统的一部分进行备份，但仍
将与普通的文件系统备份不同，它需要数据库备份代理和数据库系统的支持。
而在线备份是数据库打开方式下进行的备份，有时也称热备份，此时数据库的
应用除性能上受到备份任务的影响外仍然可用，而脱机备份时数据库是不可用
的。方案建议书中所指的备份绝大多数是在线备份，但建议用户在进行数据库
运行较长时间后或系统进行了较大的结构性修改后进行一次脱机备份，尽管它
不是必须进行的。
从备份方式划分，数据库备份又分为物理与逻辑备份两种。物理备份主要
是通过数据库自身备份工具如 Oracle 的 RMAN 与备份软件的数据库备份代理
对数据库的相关文件，如 Oracle 系统的控制文件、数据文件、日志文件进行备
份。通常可以对单个的数据文件或整个数据库进行备份。目前大型数据库备份
通常选择物理备份。逻辑备份有时也称导出创建数据库对象的逻辑拷贝并存入
一个二进制文件，逻辑备份的工具如 Oracle Export，它实际上利用 SQL 从对象
中读取数据并将其存入二进制文件，导入工具如 Oracle Import 利用该文件恢复
这些特定数据库对象到数据库中。
逻辑备份不提供时间点（Point-in-Time）恢复，而且不能和归档日志重做
日志文件联用进行数据库的恢复。如果由于某种原因，磁盘上的数据块被破
坏，则物理备份将产生该块的拷贝，错误将影响备份。使用逻辑备份的一个优
点是，由于在导出表时进行全面表扫描，所以这种破坏不会影响备份。因为这
种情况下，在导出时这种损坏将被检测到，并且导出失败。另外，逻辑备份还
可以辅助数据库进行内部数据表的恢复。
13
本次项目我方建议以物理备份为主，同时使用逻辑备份作为辅助备份方
式。
6 第五部分 参考文献
[1]施法中.计算机辅助几何设计与非均匀有理 B 样条[M].北京:北京航空航
天大学出版社,2002.
[2]魏斌.人机系统仿真中曲面建模新方法研究与实现[D].北京:北京航空航天
大学,1997.
[3]许增朴.准三维机器快捷制衣量体系统的研究[J].天津纺织工学院学报，
2000
14