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