铁路售票系统架构评审文档.docx
《铁路售票系统架构评审文档.docx》由会员分享，可在线阅读，更多相关《铁路售票系统架构评审文档.docx（18页珍藏版）》请在冰点文库上搜索。
铁路售票系统架构评审文档
铁路售票系统架构评审文档
虚拟的一人多角色的评估小组，成员列表如下：
表1：
评估小组成员列表
成员
角色
评估小组负责人、评估总结者、提问者、场景书记员、时间管理者
评估负责人、提问者、架构设计师、提问者、进展书记员、数据收集人、提问者、领域专家、资料员
时间管理者、提问者、场景书记员、资料员
引言
编写目的：
本文档的编写目的是对铁路售票系统架构设计进展简略的评审，为后继的详细项目设计等工作提供参考和依据，本文档主要描述的内容有：
●表述
●调查和分析
●测试
●形成报告
本文档的预期读者为：
系统设计人员、测试人员、用户与其它有权限查阅本文档的相关人员。
背景：
●系统名称：
铁路售票系统
●任务提出者：
黄东鹏、X付俊、孙帅
●开发者〔承接单位〕：
开发小组
●用户：
网上订购铁路车票的人
定义：
三层架构软件设计
所谓三层体系结构，是在客户端与数据库之间参加了一个中间件层，也叫组件层。
这里所说的三层体系，不是指物理上的三层，不是简单地放置三台机器就是三层体系结构，也不仅仅有B/S应用才是三层体系结构，三层是指逻辑上的三层，即使这三个层放置到一台机器上。
三层体系的应用程序将业务规如此、数据访问、合法性校验等工作放到了中间层进展处理。
通常情况下，客户端不直接与数据库进展交互，而是通过/D通讯与中间层建立连接，再经由中间层与数据库进展交换。
ATAM架构评审模式
ArchitectureTradeoffAnalysisMethod（构架权衡分析方法〕。
他是评价软件构架的一种综合全面的方法。
这种方法不仅可以揭示出构架满足特定质量目标的情况，而且〔因为它认识到了构架决策会影响多个质量属性〕可以使我们更清楚地认识到质量目标之间的联系——即如何权衡诸多质量目标。
ATAM评估方法的主要目的：
1）提炼出软件质量属性需求的准确描述；
2）提炼出构架设计决策的准确描述；
3）评估这些构架设计决策，并判定其是否令人满意的实现了这些质量需求。
ATAM评估方法并非把每个可以量化的质量属性都进展详尽的分析，而是使众多的风险承当者〔包括经理、开发人员、测试人员、用户、客户等等〕都参与进来，由此而达到上述目标的。
ATAM是一种挖掘潜在风险，降低或者缓和现有风险的软件构架评估方法。
因此，以下三点是评估中要特别注重的：
风险、敏感点和权衡点。
2构架涉众
普通用户、用户管理员、票务管理员、开发人员、测试人员
参考资料：
SoftwareArchitectureinPractical〔第三版〕
第0阶段：
合作关系与准备工作
此次对项目的评估方法经小组协商讨论是采用ATAM架构评估综合方法。
待评估的项目系统为铁路售票系统。
这是一个基于B/S的体系的常见应用，基于网络连接实现铁路票务的相关业务。
对其进展架构评估主要有如下几个原因：
1.在架构搭建的过程中一定会碰见许多一致或者未知的问题和困难，如果在核心功能模块或者架构本身的设计根本上出现缺陷，尽早的发现对于晚发现，甚至完成项目后才发现的综合本钱要低得多；
2.由于该架构面向多个用户多平台，因此要有足够的健壮性，稳定性，可拓展性以与可修改性；
3.由于该系统借助了网络的传播性，可以随时随地的对系统进展管理和维护，但是网络的泛滥使得网络环境总是充斥着有意无意的攻击，为了防止系统所部属的服务器沦为肉鸡的下场，或者内部数据被恶意破坏造成重大损失，所以系统应保证相对的安全性，使得入侵者所花费的入侵本钱>入侵系统的获利本钱或客户损失。
第1阶段：
评估阶段
项目产品立项表述：
随着现代交通的开展，在基于经济以与便利的考虑根底上，铁路出行成为广阔人民首选的性价比最高的交通方式。
但随着经济的开展，人工售票逐渐不能满足庞大人口数量的根本购票需求。
随着互联网的开展，网络购票的普与解决了这个主要矛盾。
根据上述目标，质量属性可以划分为两类：
1．高优先级质量属性：
1）性能
2）安全性
3）易用性
4）兼容性
2．重要但优先级较低的属性：
1）可扩展性
2）可维护性
3）可靠性
4）可扩大
架构方法分类：
进展了架构表述后，评估小组列出他们曾听到的架构方法，以与那些在对文档进展评估前的评审中所了解到的方法：
一、分层架构
这种架构将软件分成假如干个水平曾，每一层都有清晰的角色和分工，不需要知道其他层的细节，层与层之间通过接口通信。
二、事件驱动架构
事件是状态发生变化时，软件发出的通知。
事件驱动架构就是通过事件进展通信的软件架构。
分为：
事件队列、分发器、事件通道、事件处理器。
三、微核架构
又称为“插件架构〞，指的是软件的内核相对较小，只要功能和业务逻辑都通过插件实现。
内核通常只包含系统运行的最小功能。
插件如此是相互独立的，插件之间的通信，应该减少到最低，防止出现相互依赖的问题。
四、微服务架构
是服务导向的架构的升级。
每一个服务都是一个独立的部署单元。
这些单元都是分布式的，互相解耦，通过远程通信协议联系。
五、云架构
云架构主要解决扩展性和并发问题，是最容易扩展的架构。
它的高扩展，主要原因是没使用中央数据库，而是把数据都复制到内存中，变成可复制的内存数据单元。
然后，业务处理能力封装成一个个单元。
比如访问量增加，就新建单元处理；访问量减少，就关闭但处理单元。
由于没有中央数据库，所以扩展性的最大瓶颈消失了。
由于每个处理单元的数据都在内存里，最好要进展数据持久化。
这个模式主要分成两局部：
处理单元和虚拟中间件。
架构表述：
软件架构是一系列相关的抽象模式，用于指导大型软件系统各个方面的设计。
软件架构是一个系统的草图。
软件体系结构是构建计算机软件实践的根底。
考虑到票务系统的特点，将使用三层结构进展系统的架构。
初步架构类图：
质量属性与采用的战术：
目标
实现方式
所采用战术
性能
用户访问系统能在规定时间内做出响应，如不能应反应相应的提示。
缓冲技术
云服务器分流
队列等待
安全性
用户信息不被泄露、支付安全
信息加密
易用性
操作难度让系统能适应大局部群众
界面简洁
兼容性
能在多平台运行
易移植编码
可维护性
系统能在出现问题时得到与时修复，管理员能进展信息更新
分层架构设计
可扩展性
在出现新需求时能够添加新功能，如支付渠道的增加支付渠道的选择
预留接口
可扩大性
在出现新需求时能够添加新功能，如支付渠道的增加支付渠道的选择
预留接口
可靠性
在程序的使用过程中出错概率要尽量小，出错了要能够与时修复
规X编码
生成质量属性效用树：
下表给出了在对铁路售票系统评估期间生成的质量属性效用树，有几个质量属性求精没有与之相关的场景。
这种情况经常出现，这并不是问题，对于某个质量属性，人们有时能够想出一个合理的求精，但当让他们在自己的系统的上下文中对该质量属性的用例进展说明时，却发现该求精实际上并不适用。
表2：
对铁路售票系统进展ATAM评估的效用树表格
质量属性
属性求精
场景
性能
最大负载
响应时间
吞吐量
当开票时，用户量剧增，能够同时负载至少500的用户同时访问〔H,H〕
用户输入数据后在网络畅通的情况下应能在s内给出相关信息〔H,M〕
日最高订票量500万X〔按目前网络订票系统工作18小时算，每秒处理订单量为78X〕〔H,H〕
安全性
数据存储
注册验证
登录验证
密码强度
当用户注册时，系统将用户的信息加密后存入数据库；当用户登录时，系统将数据加密后再与数据库的内容进展比拟，防止传输过程被窃取泄露。
〔H,L〕
当用户注册时,为确认为真人操作，存在手机信息验证码验证，并且60s内不允许重复获取验证码。
〔H,L〕
当用户登录时，连续输入两次错误密码后，再次登录需要根据系统给出图片验证码输入正确的验证码才能完成登录，图片验证内容随机生成，并且随机生成条纹遮挡字符，防止机器验证。
〔H,L〕
当用户注册时系统根据用户的密码显示相应的密码强度以提示用户增强密码强度。
密码强度根据密码内容字符类型以与长度确定。
为了确保根本的安全性以与防止用户遗忘密码，用户密码长度X围限制为6-16位。
〔H,L〕
易用性
用户通过输入简单的查询信息就能够得到对应的相关数据并让用户轻易完成购置〔H,M〕
兼容性
多系统支持
在一样平台的不同系统上也能够正常运行〔H,H〕
可维护性
管理员功能
维护管理
系统自动报错
管理员能够在铁路信息、用户信息需要更新时进展与时更新，并同步数据给用户〔H,M〕
当出现了不可防止的错误时，可以与时进展维护修复〔H,M〕
可以定位出系统报错内容、报错位置〔M,L〕
可扩展性
添加新功能
在出现新需求时能够添加新功能，如支付渠道的增加支付渠道的选择〔M,L〕
可扩大性
功能业务的子模块
随着开展和意见的收集，能够根据情况添加新的业务功能，如外卖预定〔M,M〕
可靠性
不易出错
在程序的使用过程中出错概率要尽量小，出错了要能够与时修复〔H,H〕
表中的场景给出了决策者所分配的优先级。
在每一对有序的字母中，第一个代表能力的重要性，第二个代表设计师对实现该质量属性的难度的估计。
我们需要注意到，一些场景已经很完备了，具备了刺激、环境和响应三个局部；一些场景没有刺激，还有一些场景没有响应。
在这个阶段，只要涉众能够理解场景的含义，不明确的场景说明是允许的。
如果所选择的场景用于进展分析，那么该场景中的刺激和响应必须得到足够的明确。
初步分析架构方法：
评估小组首先分析最重要而且最难实现的场景，每次分析一个最高优先级的场景，同时我们的设计师详细地解释了构架如何支持每个场景。
小组成员探查设计师用来实现场景的架构方法，把相关架构决策编成文档，一共确定了个8敏感点，4个风险点，3个无风险决策。
性能
场景
系统访问量达到顶峰
属性
性能
环境
系统处于顶峰访问时期
刺激
用户请求访问
响应
良好响应请求
架构决策
敏感点
权衡点
有风险决策
无风险决策
超出限制访问量的请求放在等待
S1
R1
缓存
S2
R2
N1
云服务器分流
S3
数据库连接池
S4
N2
推理
1、由于在系统部署的时候用的是单应用服务器，而一台应用服务器可同时支持的并发用户数量是很少的，在几千甚至上万的用户访问系统时，由于限制最大访问量，不能保证每个用户都能随时登录，降低用户的满意度。
2、单服务器提供的缓存数有限
3、防止了非法用户的恶意攻击，但有可能降低系统的可用性
4、减轻数据库的负担，提高系统的性能
可用性
场景
系统备份与恢复
属性
可用性
环境
系统发生错误
刺激
用户进展恢复
响应
尽快恢复并未用户提供有意义的反应信息
架构决策
敏感点
权衡点
有风险决策
无风险决策
系统备份
S5
R3
故障恢复
S6
R4
数据库备份
S7
推理
1、系统备份是进展故障恢复的前提，但频繁的备份会影响正常的业务处理，存在一定的风险
2、如果因为系统掉电或其他操作，利用备份数据可以很快恢复。
但由于使用的是但服务器机制，一旦这台服务器出现故障或者崩溃，硬件发生故障，系统的回复时间会很长，存在风险。
安全性
场景
用户信息传输
属性
安全性
环境
信息泄露
响应
信息加密
架构决策
敏感点
权衡点
有风险决策
无风险决策
信息加密
S8
N3
推理
1、信息可能在传输过程中被截获
2、信息加密传输，并且以加密格式在数据库中校对可以防止恶意获取信息
3、信息加密不影响性能，还能提高信息的安全传输和数据库安全
战术采用
采用战术
敏感点〔S〕
有风险决策〔R〕
访问量激增使用LRU缓冲
提高了系统的工作效率
单服务器提供的缓存数目有限，并发用户多的情况下，系统处理缓慢
超出限制访问量的请求放在等待队列中
提高了系统的稳定性和可用性，减少了崩溃的可能
会降低最大并发数目，使得用户等待时间过场，可能造成用户不满
云服务器分流
分流访问量，提高效率
锁机制
解决多管理用户同时访问修改同一数据
可能产生管理用户长期占用资源，降低资源使用率
备份数据库
防止数据库物理性破坏
数据库连接池
数据库连接池允许应用程序重复使用一个现有的数据库连接，而不再是重新建立一个，提高应用系统的性能
系统备份与恢复
增强系统的容错能力
操作系统和数据库软件发生崩溃时，回复时间较长
MD5加密
防止用户信息泄露
第2阶段：
评估阶段
集体讨论并确定场景的优先级：
下表给出了在本步骤中提出的某些局部感兴趣场景进展重点分析。
按重点次序罗列，由于篇幅有限，有些细微场景没有列出，只列出了认为重要场景。
表3：
集体讨论确定的场景
场景号
场景
1
为了防止软件抢票，应在对一个一样的用户的屡次请求进展分析。
如：
验证码两次输入错误之间的之间间隔。
当判定不是软件抢票时，应当随着验证错误次数的增加降低验证难度
2
用户账户与付款的绑定、多种支付方式、以与安全性的要求。
在保证安全性的前提下应该能够让用户通过最简洁的流程选择自己适宜的支付流程。
3
信息密传输
4
突然激增的流量导致服务器处理缓慢，甚至崩溃异常，要求对有害信息进展过滤，使用LRU缓冲计数减少服务器负担，增加服务器工作效率。
5
用户访问的相关车次查询、买票、下订单、付款、改签、退款的流程应直观、简洁。
6
支持新车次添加、旧车次删除、用户信息修改操作等。
7
如果存在多个管理员时怎么并发管理系统，如果多个管理员对同一数据进展修改时应如何保护数据不被屡次修改。
这里考虑到参考锁机制。
再次分析架构方法：
三层结构选择
由于票务数据以与用户数据量庞大，而三层结构的特点将数据层、逻辑层以与表现层分隔开，在开发上降低了复杂度。
并且考虑到系统的开发效率，三层结构使项目结构更清楚，分工更明确。
考虑到用户数量多，并且票务信息随时都有可能发生变化，使用三层结构有利于后期的维护、更新和升级。
并且数据的差异性大，将三层架构中的控制层进展了细分，实现低耦合、并行开发。
为解决访问流量大的问题，服务器考虑使用LRU缓冲计数以提高服务器工作效率和改善用户体验。
并且出于对大量用户信息安全的角度考虑，数据的传输和校验采用MD5加密方式。
在集中的讨论中，我们重点讨论了上述问题的解决方案，考虑到时间和空间的限制，我们就第一二个详细展开说明，以与分析和权衡。
LRU缓冲技术分析
比如说一些系统登录的操作，不可能每次你访问系统都去调用数据库的东西，如果能划出一些空间来，比如说500M，用来缓存这些东西，这样用户访问的时候先在缓存里找，找不到，再去访问数据库，同时把被访问的内容放到缓存里面〔我们可以假设这些东西还会经常被访问〕。
然而，我们分配用来做缓存〔Cache〕的空间肯定是有限的，总不可能从数据库读的东西全部放到缓存里，所以，当缓存里的内容达到上限值的时候，我们就要把最少使用的东西写回数据库，再将新的访问内容从数据库暂存到缓存里面。
以此保证服务端的效率和使用度。
MD5加密存储分析
MD5将任意长度的“字节串〞变换成一个128bit的大整数，并且它是一个不可逆的字符串变换算法，换句话说就是，即使你看到源程序和算法描述，也无法将一个MD5的值变换回原始的字符串，从数学原理上说，是因为原始的字符串有无穷多个，这有点象不存在反函数的数学函数。
将客户端的内容数据进展加密后传输到数据库进展校验，这样可以防止在传输过程中数据被盗取的安全性问题。
备份数据库
由于存储的数据信息内容数量庞大，一旦服务器出现问题，数据丢失将会导致巨大的损失。
所以在之前的部署上添加了备份数据库，防止数据丢失。
改良架构类图
结果表述
（1）由于开发人员对架构缺乏一定的熟练度，我们决定边学边做，碰见一些解决不了的问题采用在文档中总结报告，记录下来，优先完成功能模块的实现环节；
（2）平台开发入门槛较低，产品容易被模仿，需要与时更新设计以摆脱竞争对手，所以应该预留系统API接口，为不管是以后管理方设计更改界面还是可以由用户自定义开发界面都能起到良好的促进作用。
第3阶段：
后续阶段
ATAM评估的一个具体结果就是生成了最终报告，该报告包括一个有风险决策、误风险决策、敏感点和权衡点的列表。
还包括一个涉与如下内容的目录：
所使用的架构方法、效用树、经过集体讨论确定的场景以与所选择的每个场景的分析记录。
最后，最终报告还包括由该评估小组所确定的风险主题的集合，并指出了每个风险主题所危与的商业动机。
附录
拟采用架构评审方法中的ATAM方法
对ATAM模型方法的简略描述：
软件构架的评估方法：
SAAM和ATAM。
这里只详细说明ATAM方法。
ATAM一种进展构架评估的综合方法，ATAM是评估软件构架的一个健壮的方法。
在该方法中，项目决策者和涉众要清晰地阐述一个准确的质量属性需求列表〔以场景的方式〕，并说明与实现每个高优先场景相关的构架决策。
然后，把这些决策确定为有风险决策或无风险决策，以找到构架中任何存在问题的地方。
ATAM不是需求评估。
ATAM不是代码评估。
ATAM不包括实际的系统测试。
ATAM不是一个准确的手段，但它识别了构架中可能存在风险的区域。
这些风险包含在敏感点和权衡中。
ATAM活动的4个阶段：
在第0阶段〔合作关系和准备〕确定细节：
人员，时间，地点；评估小组获取资料并进展初步了解分析。
第1阶段，评估阶段，决策者参与，小组开始信息收集与分析；耗时约1周。
1～2周中断期，评估小组进一步以非正式方式了解构架。
第2阶段，评估阶段，涉众参与，分析继续；约2天。
第3阶段，后续阶段，生成最终报告，进展评估活动总结；1周。
评估阶段的步骤：
第1步：
ATAM方法的表述。
评估负责人向决策者表述ATAM方法，使大家理解其过程，了解角色布局。
第2步：
商业动机的表述。
决策者介绍系统商业动机、重要功能、各种限制〔任何相关的技术、管理、经济和政治限制〕、商业目标和上下文、主要的涉众、驱动因素等。
第3步：
构架的表述。
首席设计师或架构小组介绍构架，技术限制、所用模式等。
第4步：
对构架方法进展分类。
评估小组利用所有信息对构架方法进展分类。
第5步：
生成质量属性效用树。
生成质量属性效用树，捕获详细的需求信息，为每个场景分配一个级别，如〔高，中〕，前者为重要度，后者为实现难易度，重点放在〔高，高〕的场景；此处场景具备刺激、环境、响应三要素就可以了。
第6步：
分析构架方法。
评估小组分析所有重要场景，设计师解释如何支持该场景，检查所用构架方法，分析风险点、权衡点、敏感点。
经过一段中断期，第2阶段开始，此时涉众开始参与；首先仍然需要一个对ATAM方法的介绍，并使涉众了解已有的成果。
第7步：
集体讨论并确定场景的优先级。
集体讨论并分析场景的优先级，以了解更广泛的涉众的想法；该过程可能产生新的场景；使用“有限票数法〞投票确定每个场景的优先级——此处不考虑实现难度。
第8步：
分析构架方法。
分析新的高优先级的场景，构架师解释构架是怎么满足各场景的。
第9步：
结果表述。
总结评估结果，评估负责人展示该结果。
升级会员 