业务支撑架构设计文档
技术框架设计方案文档

技术框架设计方案文档一、项目背景。
咱们这个项目啊,就像是盖一座超级酷炫的大楼。
不过呢,在盖楼之前,咱们得先把这个框架搭好,就像大楼的骨架一样重要。
这个框架得能支撑起咱们各种各样的功能需求,就像骨架要能撑起大楼的每一层和里面的各种设施一样。
二、目标。
1. 稳定性。
这框架啊,得像一个稳重的老大哥一样,不管遇到啥情况,都不能轻易倒下。
比如说,要是有好多用户同时来访问咱们的东西,就像一群人同时冲进大楼一样,它得稳稳地扛住,不能晃悠。
2. 可扩展性。
咱们的项目肯定是要不断发展壮大的,就像大楼要不断加盖新的楼层。
所以这个框架得很容易就能添加新的功能,就像在大楼上轻松加建一个新房间那么简单。
3. 高效性。
它得像一个超级高效的小助手,处理各种任务的时候速度要快。
就好比大楼里的电梯,得快速地把人送到他们想去的楼层,不能让人等得不耐烦。
三、整体架构设计。
# (一)分层架构。
1. 表现层(用户界面)这就像是大楼的外立面,是用户直接看到和交互的部分。
这个层面要做得漂亮又好用,就像大楼的外观设计得时尚又方便人们进出一样。
它主要负责展示信息给用户,接收用户的输入,就像大楼的大门,既能让人看到里面的大概情况,又能让人进来或者把东西送进来。
2. 业务逻辑层。
这个层啊,就像是大楼里的各种管理部门。
它负责处理业务规则,比如说,要是用户要注册一个账号,它就得检查这个账号是不是符合规定,就像大楼的管理部门要检查进入大楼的人有没有带齐证件一样。
这一层要把表现层和数据层连接起来,就像部门之间要互相协作,把大楼的各个部分联系起来。
3. 数据访问层。
这就好比大楼的仓库,负责存储和管理所有的数据。
它要能高效地存储数据,就像仓库要把东西摆放得整整齐齐,方便找到一样。
而且它还要能快速地提供数据给业务逻辑层,就像仓库管理员能迅速把需要的东西拿出来给其他部门一样。
# (二)模块划分。
1. 用户管理模块。
这个模块就专门负责管理用户相关的事情。
比如说,用户的注册、登录、修改密码这些操作。
架构设计之如何写架构设计说明书

架构设计之如何写架构设计说明书架构设计是需求分析到软件实现的桥梁,也是决定软件质量的关键。
编制架构设计说明书是开发⼈员向架构师转变必定会经历的过程。
在架构师整个的成长过程中,必定会经历编制架构设计说明书、评审架构设计说明书以及根据业务需求分析设计系统架构的三个过程。
架构设计是需求分析到软件实现的桥梁,也是决定软件质量的关键。
编制架构设计说明书是开发⼈员向架构师转变必定会经历的过程。
在架构师整个的成长过程中,必定会经历编制架构设计说明书、评审架构设计说明书以及根据业务需求分析设计系统架构的三个过程。
作为⼀个架构师,我想尝试⼀下根据这三个过程对不同能⼒需要,写⼀次系列⽂章,包括《架构设计三部曲之如何写架构设计说明书》、《架构设计三部曲之如何评审架构设计说明书》以及《架构设计三部曲之如何做架构设计》,⼀来可以帮助⾃⼰整理思路,重新审视架构设计,⼆来也可以与⼤家分享⼼得,听取⼤家的意见,共同进步。
本篇属于系列中的第⼀篇。
那么到底如何编写架构设计说明书?该说明书应该包括哪些⽅⾯的内容呢?我们知道,架构设计说明书是阐述系统架构具体内容的,根据我之前的⽂章《我的架构观-架构未来的发展》我们明⽩架构的本质是呈现三⼤能⼒:即系统如何⾯向最终⽤户提供⽀撑能⼒、如何⾯向外部系统提供交互能⼒、如何⾯向企业数据提供处理能⼒。
因此从这个⾓度看,对架构设计说明书的章节的设置及章节内容安排应该要能说明清楚系统架构到底是如何呈现这三种能⼒的,让我们逐个分析:系统如何⾯向最终⽤户提供⽀撑能⼒:这⼀点是要从系统⾃⾝的能⼒来看,即本系统到底应该具备哪些功能,各功能间如何协作以满⾜⽀撑最终⽤户的使⽤,其实就是要讲系统的功能架构或逻辑架构,回答系统从功能粒度上划分了⼏个功能模块或⼦系统,各模块或⼦系统之间的内部接⼝关系如何等问题。
当然还有⼀个需要考虑的问题,在纵向维度上,随着架构设计理念的不断发展,逻辑架构模型从最初的展⽰-数据两层模型,到展⽰-逻辑-数据(所谓的MVC)三层模型,甚⾄到展⽰-调⽤接⼝-逻辑-数据接⼝-数据五层模型,不同层次表明系统内部设计的精细程度,因此在逻辑架构设计中也需要针对实际情况加上这种分层设计的内容。
华为架构设计说明书

架构设计说明书产品发布标识[填写说明:模板中用方括号括起来并以蓝色斜体显示的文本,用于向作者提供指导,在文档编辑完成后应该将其删除。
文档正文应使用常规、黑色、五号字体即系统设置的“正文”样式文档页眉处的”xxxx系统”和“版本号”仅为示例,请注意更新封页与页眉符合实际情况。
此处的版本号指的是产品版本号封页简要表中的产品名,如无可以不填写。
当某一章/节没有内容时,必须注明N/A,同时标注理由。
例如:本章/节内容无需考虑。
特别说明:当某章/节内容参见其它文档时,不能注明N/A,而应该写明参见某文档的具体章节。
华为科技(深圳)有限公司版权所有内部资料注意保密修订记录:派发清单:*动作类型:批准、审核、通知、归档、参与会议,其它(请说明)目录1 简介 (6)1.1 目的 (6)1.2 文档范围 (6)1.3 预期的读者和阅读建议 (6)1.4 参考文档 (8)1.4.1 包含文档 (8)1.4.2 相关文档 (8)1.5 缩略语和术语 (8)2 总体设计思路 (9)2.1 设计方法 (9)2.2 设计可选方案 (9)3 系统逻辑结构 (10)3.1 总体结构 (10)3.2 子系统定义 (10)3.2.1 子系统一 (11)3.2.2 子系统二 (11)3.3 子系统接口设计 (11)3.4 主要数据模型 (11)4 系统物理结构 (12)4.1 总体结构 (12)4.2 组件定义 (12)4.2.1 组件一 (12)4.3 组件接口设计 (12)4.4组件与子系统对应关系 (12)5 系统部署 (13)5.1 网络结构图 (13)5.2 部署模式 (13)6 关键技术及公用机制 (13)6.1 关键技术设计 (13)6.2 公用机制说明 (13)7 系统重用设计 (13)7.1 以往设计的重用.................................................................................... 错误!未定义书签。
业务支撑系统云化基础架构设计

( 一 )分布式处理能力
在 基 础 架 构 层 虚 拟 化改 造 后 ,每 个子 系统
一
信 息 化研 究 一
I n f o r ma t i z at i o n — Re s e ar c h
的计 算 能 力仍依 赖于 虚 拟机 的CPU ( Ce n t r aI Pr o c e s s Un i t )/ 内存配置 ,计 算 能力 的提 升需
支 撑 应 用 实 例 的 存 储 容 量 要 求 。 因 此 . 因 存 储
不 足导 致 无 法 加 载 应 用 实 例 的 情 况 .不 会 再 次
发生 。
SDN技 术 有 效地 实现 了 网络 虚 拟 化 .实现 了
网 络 转 发 、 控 制 流 量 的 分 离 机 制 。 通 过 SD N技
用本 地磁 盘 作为应 用 实例 ( 即虚拟 机 ,或 虚拟化
容 器 ) 的 存 储 介 质 .不 再 使 用 共 享 存 储 。
终 结 点 )终 结 于 不 同 的 设 备 :对于 大 数据 、物 理 机 资 源池 .VT EP 终 结于 边缘 交 换机 :对 于 虚拟化 资源 池 .VTEP 终 结于 Hy p e r v i s o r( 虚拟 化 管理程
Memc a c h ed 、Re d i s 等 分布 式 缓 存 系统 :应
用 系 统 、 操 作 系 统 日 志 汇 集 于 集 中 的 日 志 服 务 器 ,进行 归档 与分 析 。
( 二 )计算资源架构
1 . 资 源 池 化 在 基 础 架 构 层 取 代 虚 拟 化 集 群 的 是 计 算
制 , 自动 控 制 应 用 实例 的部署 、启 动 、停 止 、
中国移动省级业务运营支撑系统业务技术规范版

中国移动省级业务运营支撑系统业务技术规范版1. 引言中国移动省级业务运营支撑系统(以下简称“系统”)是为了支持中国移动各省公司的业务运营需求而开发的。
本文档旨在规范系统的业务技术要求,确保系统能够稳定、高效地进行业务运营。
2. 系统架构系统采用了分布式架构,分为前端和后端两部分。
前端主要负责用户界面的展示和用户交互,后端则负责业务逻辑的处理和数据存储。
系统的前端采用HTML、CSS和JavaScript技术,以实现跨平台的用户界面。
后端则借助Java技术进行开发,通过使用Spring框架进行模块化设计和管理,提高系统的可维护性和扩展性。
3. 数据库设计系统的数据存储和管理采用关系型数据库。
数据库的设计要遵循以下原则:•合理的表结构设计,符合数据库范式要求,以确保数据的一致性和完整性。
•恰当的索引设计,提高查询性能,减少数据检索的时间开销。
•数据库的备份和恢复机制,确保数据的安全性和可靠性。
4. 业务流程系统根据中国移动省级公司的业务运营流程进行设计和实施。
以下是常见的业务流程:1.业务办理:用户通过系统提交业务办理请求,请求将发送到后台进行处理。
2.业务审核:后台系统对用户提交的请求进行审核,根据业务规则进行判断,并生成相应的审核结果。
3.业务处理:根据审核结果,后台系统对业务进行处理和操作,包括生成工单、发送短信通知等。
4.业务完成:业务处理完成后,系统会生成业务办理的相关数据和报表,并通知用户处理结果。
系统的业务流程应该通过流程图和文字说明来清晰地呈现,以便于系统用户和开发人员的理解和使用。
5. 接口规范系统的接口规范是系统与其他系统或模块进行交互的重要依据。
接口规范应该包括以下内容:•接口功能说明:明确接口的功能和用途。
•接口参数:要求明确接口的输入参数和输出参数,包括参数类型、参数名称和参数说明。
•接口调用方法:要求明确接口的调用方式和操作步骤,以便其他系统或模块能够正确地调用接口。
接口规范的编写应该遵循统一的规范,以提高开发效率和协作效果。
BOA技术架构实例

格式转换模块
配置文件
代理运行
代理运行时 获 取 应 用 事 件 生 成 集 成 消 息 消 费 集 成 消 息 生 成 应 用 数 据
消 息 流 转
•把应用产生的数据对象转换成事先 定义好的格式,并根据发布订阅规 则放入发送队列,最后由发送线程 把消息发送到DXS上 •接收来自DXS的消息,把其中包含 的数据对象转换成应用可识别的格 式,最后传递给应用。
基于BU的应用系统运行支撑平台
组织系统信息门户 [单点登录、个性化定制]
应用层
干部管理 应用
党内管理 应用
企管人员 管理应用
专技人员 管理应用
综合应用
工作流
数据集成
报表管理
内容管理
数 据 访 问 层(Persistence Layer)
信息资源层
数据仓库
组织机构 及人员 信息库
办公 信息库
知识 信息库
Ops
PersonDAOProxy
数据集成拦截器
PersonDAO AddPerson DeletePerson UpdatePerson FindPerson
AddPerson DeletePerson UpdatePerson FindPerson
操作 PersonDAO.cs
过程集成拦截器
过程集成 接口 View
其他 建模 工具
辅助工具
流程监控 JBMon 过程分析 JBAna 过程模拟 JBSim
执行服务 工作流引擎 JBEng 工作流数据库 其他 工作流 引擎
Web Service
遗产系统
可视化表单 工具 JBFrm
过程集成机制-工作流管理系统
过程建模 过程分析 执行 监控
全业务支撑体系建设

建立面向全业务端到端支撑体系随着全业务市场竞争的日益激烈,公司已逐步向全业务运营拓展。
为了尽快满足日益增强的全业务支撑服务保障需求,进一步提升网络对市场的服务支撑能力,完善全业务端到端支撑体系。
网络部全业务室对外作为全业务支撑的统一接口,对内作为网络部支撑工作枢纽,协调相关部室,负责集团客户网络的业务接入传输和客户端设备的维护工作;负责合同约定范围内的客户端其他设备的维护工作,配合客户做好我公司责任范围之外设备的维护工作。
负责PON(驻地网)网络维护工作。
负责WLAN网络维护工作。
第一章集团信息化支撑体系建设一、集团信息化网络支撑随着集团信息化业务的快速发展,集团信息化支撑的建设越来越重要。
集客维护支撑工作较原有维护工作,在工作范畴、工作内容、工作要求均有不同的特点,首先需要跨多专业维护管理,交换+数据+传输+ 庞杂的接入/客户侧技术等。
其次需要进行售前勘查、售中开通、售后保障的全生命周期管理,最后需要对不同级别的客户、不同的业务,有不同的操作要求、操作规范,体现面向客户的差异化管理。
1、集客支撑工作内容1)组织协调为集团客户部门提供售前、售中、售后的全程技术支持,落实相关资源调配。
重点提供售前技术支撑、网络资源核查、协调业务开通、故障处理和通信保障等服务。
2)为集团客户提供差异化网络服务。
在既有网络服务的基础上,为不同需求的客户提供不同的网络质量和服务质量的差异化网络服务。
3)整合网络能力和维护能力,挖掘网络服务内容,最大限度地发挥网络运行效率和经济效益。
4)制订集团客户网络服务工作规范和流程,建立健全集团客户网络服务工作体系。
5)整合完善客户网络服务支撑手段。
加强客户网管、故障单管理、代维管理等支撑系统建设提高资源核查、业务开通及服务保障能力,满足客户端到端、差异化的服务需求。
2、各部门(室)相关职责◆集团客户部:1)负责集团客户需求的确认及客户售前相关协调工作。
负责集团客户业务变更申请及客户售中相关协调工作。
京东应用架构设计

台、仓储平台、物流平台、支付平
台、广告平台等 • 基础业务下沉,可复用。如用户、
商品、类目、促销、时效等
4. 区分主流程、辅流程
• 分清哪些是电商的主流程。运行时,
3. 隔离不同类型的业务
• 交易业务是签订买家和卖家之间的
优先保证主流程的顺利完成,辅流
6 618经验
容量规划
• 容量指标选择 • 压测 • 服务关系分析 • SLA制定 • 依赖治理
• 监测容量指标数 据 • 为扩容、降级、 降级提供依据
• 下单调用链分析:每 笔交易对应tps • 单量预测:根据历史 数据,预测618单量 • 根据调用链模型,估 算各节点业务峰值
下单调用链模型
下单调用链
7 总结
架构总结
解耦/拆分
1. 2. 3. 4. 电商业务域 核心、非核心业务 主流程、辅流程 业务规则分离
抽象
集成
1. 跨业务域调用异步 2. 非核心业务异步
复用
1. 基础业务下沉,可 复用
治理
1. 厘清业务边界、 作用域
业务
应用
1. 2. 3. 4.
应用集群水平扩展 按业务域分离应用 按功能分离应用 按稳定性分离应用
应用抽象化:应用只依赖服务抽象, 不依赖服务实现细节、位置 数据库抽象化:应用只依赖逻辑数据 库,不需要关心物理库的位置和分片 服务器抽象化:应用虚拟化部署,不 需要关心实体机配置,动态调配资源
•
不过度设计
5
•
架构原则
容错设计
4 3
•
松耦合
服务自治:服务能彼此独立修改、 部署、发布和管理。避免引发连 锁反应 集群容错:应用系统集群,避免 单点
- 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。
业务支撑系统架构设计文档文档创建信息文档修订记录修改类型分为A– ADDED(增加)M– MODIFIED(修改)D– DELETED(删除)目录1引言 (4)1.1编写目的 (4)1.2背景 (4)2系统架构设计 (4)2.1系统概述 (4)2.2设计约束 (9)2.2.1 标准与规范 (9)2.2.2 开发、运行环境 (9)2.2.2.1 开发环境 (9)2.2.2.2 运行环境 (9)2.2.2.3 软件平台 (9)2.2.2.4 硬件平台 (10)2.3体系架构 (10)2.3.1 技术框架 (10)2.3.2 代码组织结构 (12)2.3.3 配置文件组织结构 (13)2.3.4 开发原则:数据与功能分离原则: (13)2.3.5 关键技术点 (13)2.3.6 技术难点与风险、预研成果概述 (15)2.4子系统划分及说明 (15)3附录 (15)3.1本系统用到的缩写词、定义和术语 (15)3.2参考资料 (15)1引言1.1编写目的本文主要根据需求规格说明书,对业务支撑系统(以下简称BSS)进行的架构设计,并为bss的详细设计提供依据,同时为开发人员在开发过程中提供开发基础。
预期的读者:需求设计人员,产品相关负责人,详细设计人员,开发人员,质量管理人员,系统集成部署人员。
1.2背景2系统架构设计2.1系统概述整个业务支撑系统由客户关系管理(CRM),计费(BILLING),商业智能(BI),合作伙伴管理(PRM),生产管理(IOM)五部分组成。
采用统一的数据视图。
典型应用场景举例:新业务的快速配置2.2设计约束系统采用组件化设计,程序设计和实现采用统一模式,提高重用性和可维护性。
2.2.1标准与规范见webx开发规范2.2.2开发、运行环境2.2.2.1开发环境语言:javaJDK:jdk1.6.0_10开发工具:Eclipse 3.2文档工具:PowerDesigener12.0 Word 2003 V isio 2003数据库:MySql5.1.38WEB服务器:Tomcat 6.0 JBOSS6.02.2.2.2运行环境待定2.2.2.3软件平台服务器端:(使用非商业软件)应用服务器:Jboss6.0GA或者Tomcat6.0JDK:jdk1.6.0_10数据库:MySQL客户端操作系统WindowsWindows XP2.2.2.4硬件平台最大服务器配置2.3体系架构本子系统采用三层(表示层、业务层、集成层)的B/S体系架构。
2.3.1技术框架●开发框架:依据公司要求,选择公司已有的框架系统使用java语言,采用的是通常意义上的三层架构,就是将整个业务应用划分为:表现层(UI)、业务逻辑层/服务层(BLL)、数据访问层(DAL)。
各层职责如下:1.表现层(UI):通俗讲就是展现给用户的界面,该层负责页面的跳转和页面的展示。
2.业务逻辑层/服务层(BLL):针对业务逻辑的操作,实现业务接口供表现层调用。
3.数据访问层(DAL):该层直接操作数据库,封装对数据库的操作细节。
另外,模型层的领域对象(Domain objects)作为参数在上述3层间传递数据。
后台部分采用webX框架。
分层开发的结构图如下:分层结构数据访问层服务层表现层其中根据项目特点又将服务层拆分为业务代理层和服务层两部分,通过增加业务代理层避免向外部系统暴露系统内部调用逻辑,降低系统间的耦合度。
采用分层结构框架的目的即为了“高内聚,低耦合”的思想,具有如下优点: 1. 开发人员可以只关注整个结构中的其中某一层; 2. 可以很容易的用新的实现来替换原有层次的实现; 3. 可以降低层与层之间的依赖; 4. 有利于标准化;5. 利于各层逻辑的复用。
采用多层架构设计模式,使用主流框架Struts+Spring+Hibernate (SSH)为基础。
Struts实现MVC,Spring负责架构的结合,Hibernate进行数据的持久化。
架构是采用公司的webx进行开发,webx应该在公司众多项目中成功应用,webx在SSH基础上又进行了一定的封装,减少了开发工作量。
Webx经过多个项目采用其功能实现相对稳定。
2.3.2代码组织结构包名前缀:cn.ceopen.bss之下是各个子系统:billing,crm,prm,iom,bi和公共部分pub每个字系统下划分功能模块,如计费账务billing下包括rating ,sett, acct三部分。
代码安装service,dao,model,action,vo放置。
其中service下直接放置接口,实现在service.impl,dao一样。
命名:service接口命名:xxxxServiceservice实现命名:xxxxServiceImpldao接口命名:xxxxDaodao实现命名:xxxxDaoImplmodel命名:表名去除前缀,首字母大写vo命名: 表名去除前缀,首字母大写加vo标识,如xxxVo2.3.3配置文件组织结构配置文件统一放在resource.modules文件夹下,以子系统和功能模块进行划分。
每个功能模块包括hibernate、spring、Struts配置文件。
2.3.4开发原则:数据与功能分离原则:•业务数据与业务功能分离•业务功能与业务处理流程分离•业务流程的改变和业务功能的增删、修改、数据种类的改变不会影响系统其他部分。
•业务功能、数据、业务流程控制能够在运行环境下灵活的部署、分布,使得系统能够在规模上扩展,从而不限制业务的发展。
•多层软件体系结构,使用中间件构造多层体系结构为系统提供分布计算环境的平台及对应用的通用服务,构成系统的框架;采用面向对象及构件技术在框架上灵活组成应用系统。
•系统充分考虑未来业务量及业务种类增长的需求,同时也考虑与行政管理体制的配合和协调,新的软件模块即插即用2.3.5关键技术点1,计费部分采用引擎模式,COM的设计方式2,工作流引擎:订单调度,集成定单管理部分使用。
工作流引擎是指workflow作为应用系统的一部分,并为之提供对各应用系统有决定作用的根据角色、分工和条件的不同决定信息传递路由、内容等级等核心解决方案。
例如开发一个系统最关键的部分不是系统的界面,也不是和数据库之间的信息交换,而是如何根据业务逻辑开发出符合实际需要的程序逻辑并确保其稳定性、易维护性和弹性。
3,数据挖掘技术:在BI部分使用。
数据挖掘是通过采用自动或半自动的手段,在海量数据中发现有意义的行为和规则的探测和分析活动。
数据挖掘方法有多种,其中比较典型的有关联分析、序列模式分析、分类分析、聚类分析等。
(1)关联分析关联分析,即利用关联规则进行数据挖掘。
在数据挖掘研究领域,对于关联分析的研究开展得比较深入,人们提出了多种关联规则的挖掘算法,如APRIORI、STEM、AIS、DHP等算法。
关联分析的目的是挖掘隐藏在数据间的相互关系,它能发现数据库中形如“90%的顾客在一次购买活动中购买商品A的同时购买商品B”之类的知识。
(2)序列模式分析序列模式分析和关联分析相似,其目的也是为了挖掘数据之间的联系,但序列模式分析的侧重点在于分析数据间的前后序列关系。
它能发现数据库中形如“在某一段时间内,顾客购买商品A,接着购买商品B,而后购买商品C,即序列A→B→C出现的频度较高”之类的知识,序列模式分析描述的问题是:在给定交易序列数据库中,每个序列是按照交易时间排列的一组交易集,挖掘序列函数作用在这个交易序列数据库上,返回该数据库中出现的高频序列。
在进行序列模式分析时,同样也需要由用户输入最小置信度C和最小支持度S。
(3)分类分析分类分析就是通过分析示例数据库中的数据,为每个类别做出准确的描述或建立分析模型或挖掘出分类规则,然后用这个分类规则对数据库中的其它记录进行分类。
分类分析就是分析该数据库的记录数据,对每个信誉等级做出准确描述或挖掘分类规则,如“信誉良好的客户是指那些年收入在5万元以上,年龄在40~50岁之间的客户”,然后根据分类规则对其它相同属性的数据库记录进行分类。
(4)聚类分析与分类分析不同,聚类分析输入的是一组未分类记录,并且这些记录应分成几类事先也不知道。
聚类分析就是通过分析数据库中的记录数据,根据一定的分类规则,合理地划分记录集合,确定每个记录所在类别。
它所采用的分类规则是由聚类分析工具决定的。
聚类分析的方法很多,其中包括系统聚类法、分解法、加入法、动态聚类法、模糊聚类法、运筹方法等。
采用不同的聚类方法,对于相同的记录集合可能有不同的划分结果。
2.3.6技术难点与风险、预研成果概述1.应用高并发量问题业务支撑系统(BSS)为中企目前的所有产品和未来可能出现的新产品提供业务支撑服务,众多产品的服务开通、计费、服务保障都要通过BSS进行,会形成很大的业务访问量,需要系统能够处理高并发的情况。
我们采用的是J2EE架构,J2EE是SUN公司提出的在分布式环境中的一种体系结构,它提供了一种基于组件的设计、开发、集成、部署企业应用系统的方法,J2EE平台提供了多层分布式的应用系统模型、重用组件的能力、统一的安全模型和灵活的事务控制。
BSS采用JBOSS作为J2EE中间件,JBOSS在处理高并发方面有很高的性能。
2.大数据量问题BSS需要保留个产品系统计费数据和业务部门自身数据,数据量庞大。
我们选用的是mysql5.1.38数据库,mysql是一个成熟的关系型数据库系统。
mysql数据库具有很高的性能,适用于在线事务处理,同时具有客户端支持及应用模式;具有高可靠性和很好的并行性,把数据库管理扩充到了并行的、多节点的环境,操作简单,具有良好的可操作性。
已经在公司多个项目中成功运用。
3.开发工具的使用问题BSS项目中使用到了数管提供的页面组件和工作流引擎功能,因为数管的产品是针对OA系统开发的,在BSS的实际使用中很有许多需要再调整的细节。
需要加强同数管部门的沟通,获取更多的产品技术支持。
2.4子系统划分及说明3附录3.1本系统用到的缩写词、定义和术语缩写词和名词、术语定义。
3.2参考资料编写本说明所用到的各种资料,如需求报告、相关研发管理规范、背景资料、其它标准。