精华内容
下载资源
问答
  • 软件架构设计说明书

    2012-04-05 08:27:39
    软件架构设计说明书
  • 本文档全面与系统地表述了图书杂志采购和借阅系统的构架,并通过使用多种视图来从不同角度描述本系统的各个主要方面,以满足图书杂志采购和借阅...本文档记录并表述了系统架构设计人员对系统构架方面做出的重要决策
  • 某网银的架构设计说明书,很珍贵的,是做架构设计人的学习参考。
  • 点击上方蓝字,关注我们背景架构设计不是架构师的专属工作,对非技术人员甚至是开发人员来说,从实实在在的需求到高神莫测的架构设计仿佛是一个神秘的过程,只有具有架构师头衔的人才能掌握各中玄妙,这...

    点击上方蓝字,关注我们


    背景

    架构设计不是架构师的专属工作,对非技术人员甚至是开发人员来说,从实实在在的需求到高神莫测的架构设计仿佛是一个神秘的过程,
    只有具有架构师头衔的人才能掌握各中玄妙,这篇文章就是从最基本的事物关系来回答如何根据需求进行架构设计的问题。

    根据我前面的文章,架构的本质是事物与事物之间恰当的关系,不同领域的架构,其事物的指代不同,
    比如对于组织架构而言,事物指的是人与机构;建筑架构,事物指的是钢筋混凝土与空间。
    那在软件领域,事物指的是什么呢?
    我们知道,软件系统的本质是人类将自身无法处理的大量业务相关的数据进行筛选分类,并转换成计算机可以识别的格式,借助其强大计算能力来辅助处理。
    因此在软件领域,架构中的事物指的是业务数据与基于运算能力的业务逻辑,说的再宽泛一点就是数据与处理数据的计算能力。
    那么,架构设计其本质就是寻找数据、计算以及它们之间的平衡关系,这里面包括三个方面的要素,即数据、计算、平衡关系
    其中数据和计算是架构设计的基础,根据实际业务需求一般不难找出,而平衡关系是综合考虑多方面得到的一种状态,也是衡量一个架构设计优劣的核心要素。


    需求


    1.数据

    在对一个系统进行架构设计时,首先我们需要做的就是依据本系统所承载的业务需求,找出需要处理的最重要或最核心的数据,
    这些数据一般隐藏在线下的纸质材料里,或者记录在日常办公的笔记里,或是约定俗成的共同认识,只要从实际业务出发,找这些数据并不难。
    如果你无从下手,这里有个小窍门可以利用,
    找一个出现率很高的业务,在该业务处理前尽可能多的记录一些可能与该业务相关的数据状态,待业务处理完成后,再次记录,并与之前的数据进行比较,
    那些发生了变化的往往就是我们需要重点关注的重要数据。

    举例来说:

    • 如果这是一个政府行政办公的系统,那么办公流转过程就是数据,每个环节办理状态就是数据;

    • 如果这是银行信用卡管理系统,那么用户信用卡可用金额、账单、有效期等状态信息就是数据,每笔刷卡流水就是数据;

    • 如果这是电子商务系统,那么商品信息、用户订单、购物车信息就是数据。。。等等,

    所有那些在实际业务过程中会变化的,并且是与该业务紧密相关的数据,都是我们需要找到的数据,
    在所有已经找到的数据中,再依据实际业务的重要程度,找出最重要最核心的数据,作为在架构设计中我们需要重点处理的对象,
    其他次重要的数据在核心数据充分处理的前提下作为平衡关系的备用因素。


    2.计算

    重要数据找到后我们还需要确定如何处理这些数据,即计算,说的明白一点就是计算逻辑是什么,计算逻辑类似但并不完全等同于业务逻辑,
    它是业务逻辑在计算机世界里的一种体现,业务逻辑在真实世界里需要考虑人、时间、空间的因素,而计算逻辑在计算机的世界里,
    是二进制码、CPU、内存、存储、网络等因素,

    还是以上面的例子来说:

    • 政府行政办公系统需要将线下的纸质签字盖章从发起请求到办结的全过程搬移到线上由系统处理,
      那就需要转化成线上的在线申请、办理、流转、通知、办结、存档等过程,这些过程在线下可能有不同的部门来负责,
      但是线上将由我们设计的系统完全支撑;

    • 对于银行信用卡管理系统,需要将银行对信用卡的管理业务转化成具体的设置或查询可用金额、账单、有效期等信息的功能,
      还有记录和统计用户消费流水等,如果业务有需求,甚至需要根据用户的消费流水对用户画像,以便进行精准营销等所谓的大数据分析模块;

    • 电子商务系统也是一样,需要系统提供向用户展示商品信息,记录用户点击购买后的购物车信息,创建或更新用户的订单信息,
      以及跟踪订单从仓库打包到送达的物流信息。。。等等,

    这些都是我们对数据进行的动作,而动作不是我们凭空想象出来的,是从实际的业务处理转化到计算机领域而来的,
    在转化的过程中我们需要时刻对应现实中的处理动作如何转换成计算机世界里的处理数据的能力。
    由于寻找计算是一种业务动作的转化,在转化时我们可以多问自己期望系统应该如何帮我更好的处理数据,
    那些利用机器能很好的完成而人工较难做到的但又是经常需要做的且与业务相关的动作一般都是我们需要找的,

    常见的动作有:

    • 数据跟踪记录、

    • 查询统计、

    • 修改更新、

    • 导出展现、

    • 汇总分析等。

    当然有一点需要注意,我们在寻找计算因素的时候一定要基于计算机世界的客观现实,毕竟计算机不是万能的。


    3.关系

    明确了数据及如何处理数据,架构设计接下来要做的就是如何平衡好各种相互影响的关系,这些关系是所有我们能想到的会影响到系统的矛盾体,

    • 数据处理效率与处理能力的关系、

    • 数据体量与存储能力的关系、

    • 数据展现与用户要求的关系、

    • 系统部署与网络环境的关系、

    • 系统建设与建设成本的关系、

    • 系统易用性与客户要求的关系等等,

    在做架构设计的时候要尽可能多的考虑到这些关系,并根据实际情况划分关系的重要程度,重点保障那些重要性高的关系,
    毕竟再完美的架构设计也无法平衡好所有的关系,从这个角度来说,架构设计是一种平衡的艺术。
    当然,要准确找出这些关系,并对它们划分重要性等级,还需要做到按等级进行平衡是需要经验积累的,非一朝一夕之功,
    这也是人人都能做架构设计,但不是人人都能做好架构设计的原因。好在这一步并不是完全无规律可循的,
    首先我们讲如何找出这些关系,虽然涉及影响一个系统的矛盾体很多,
    

    但是大致上我们可以从以下3个方向来挖掘出这些关系:

    1. 与人相关的:

    这里的人包括筹建系统的甲方、建设系统的乙方、以及使用系统的用户,
    - 对于筹建系统的甲方来说,他一般关注系统的建设进度、成本、质量等,
    - 对于建设系统的乙方来说,重点会关注建设范围、风险、开发工具、实施环境等,
    - 对于用户来说,更关系系统易用性、界面友好,操作舒畅、能帮其解决实际问题等。
    
    涉及到与人相关的关系,除了从经验中获取,更重要的是需要在前期系统设计的过程中通过调研的方式,
    多与相关的干系人沟通,从他们那里获取,这也是为什么系统建设一般都是有需求调研过程的原因。
    针对与人相关的关系这部分设计内容一般体现在架构设计说明书中的概述里,包括项目目标、项目背景及其他说明等,
    当然与用户相关的一般也会在非功能性上有所体现,如易用性、可用性、安全等;
    

    2. 与外部系统相关的:

    主要指其运行所在的操作系统及服务器,以及与之交互的外部系统,系统需要运行在服务器特定的操作系统上,受服务器操作系统计算存储网络等因素影响,
    需要考虑服务器计算能力是否能处理数据、存储能力是否足够、网络是否稳定、如果服务器计算存储网络能力不够如何扩展等;
    与外部系统的交互方面,本系统需要从外部系统获取哪些数据与能力、需要为外部系统提供哪些数据与能力、交互方式是什么、交互协议如何等。
    
        一般来说,服务器的能力总是会有不够的,尤其是设计大数据量处理,大量用户同时访问的系统时,
        这就需要我们根据系统的特点提前做好扩展的设计,高并发处理、分布式理论、多机房部署等这些技术概念可以给我们很好的指引,
        这也是为什么架构师一定要眼界开阔的原因。
    

    这部分的设计内容一般体现在架构设计说明书中的

    • 逻辑架构、

    • 技术架构、

    • 接口设计、

    • 部署架构、

    • 性能、

    • 可维护、

    • 可扩展等非功能性设计上

    3. 与数据相关的:

    数据是系统处理的主体,需要划分本系统所处理的数据与外部数据的边界,明确与外部数据的流向关系,
    还需要根据实际业务来区分数据内部之间的关系,数据如何划分、各部分数据的边界在哪、与整体数据的关系如何等等。
    在划分与外部数据的边界时要基于本系统所承载的实际业务内容,从业务出发,那些只受本业务影响的数据肯定在边界内,
    而本业务与其他业务共同影响的还需要进一步分析哪方是影响主体,如果本业务是影响主体,那么在边界内,但是需要考虑提供给外部系统的交互接口,
    如果本业务非影响主体,那么再看是否有间接影响或关联影响,一般来说这部分数据都要考虑与外部系统的交互关系。
    对于边界内的数据关系也是如此,可以根据业务特点划分一些区块,每个区块内又是一个相对独立的单元,
    与相关的其他区块单元存在哪些数据上的直接或间接影响,他们之间如何交互等。所有这些关系都是我们需要发现并在架构设计时考虑的。
    针对这部分的设计内容一般体现在架构设计说明书中的数据架构、整体架构里。
    

    人、外部系统、数据是我们在发掘关系时可以参考的方向,根据系统各自的特点,在架构设计过程中还会有一些需要实际去考虑的关系,
    这些关系一般都是所谓的系统最大的特点或特殊情况,常见于重大需求,特色需求,亮点需求等形式,一般也不难找出。
    待把所有这些关系找出后,可以先做一个粗略的重要性分级,分级的依据是关系的相关性,

    重要需求相关>特色亮点需求>甲方相关>用户相关>乙方相关>外部系统相关>外部数据相关>内部数据相关>其他次重要的数据,

    在进行架构设计时优先满足重要性高的关系,得出一个基本的架构雏形,再根据弱一级的关系不断地优化完善架构模型,
    待大部分关系都可以满足后,架构设计也就出来了。
    当然,很多关系之间都是矛盾的,
    比如:

    • 筹建系统的甲方要求的低成本与高质量、

    • 系统间数据交互与操作舒畅等,

    需要我们在做架构设计时不断权衡,尽可能的兼顾,对于实在无法兼顾的,需要进行权衡取舍。
    综上来说,架构设计就是一个找准数据主体、明确处理逻辑、平衡矛盾关系的过程
    需要根据实际业务进行适当的抽象,使之适合体现在计算机的世界,每一步都需要我们明确主体,分清主次,并尽可能的平衡更多的关系,
    这需要不断的积累经验,也靠一点悟性,有时候也需要一些灵感。
    无论如何,架构设计都不只是架构师的工作,而是任何人都可以做的一项有趣的工作,
    愿你看完此篇文章后对架构设计不再迷茫,逐步成为一个优秀的架构师。


    技术评审提纲

    业务项目千差万别,没有一个统一的方法论完成架构设计和技术评审,架构设计只需要从某些关键点来表达系统即可,
    提纲就是用来帮助大家做架构评审的工具,帮助大家整理思路并形成可实施的方案,
    因此在做系统设计时,可有选择性的参考此提纲,根据业务特点来完成一个可实现的有效的架构设计。
    

    现状

    业务背景

    • 项目名称

    • 业务描述

    技术背景

    • 架构描述

    • 当前系统容量(系统调用量平均值)

    • 当前系统调用量峰值

    需求

    业务需求

    • 要改造的需求

    • 要实现的需求

    性能需求

    • 预估系统容量(预估系统调用量平均值)

    • 预估系统调用量峰值

    • 其他非功能质量

    方案描述

    方案1:

    • 概述

    一句话概括方案的亮点,比如说: 双写,主从分离,分库分表,扩容,归档等。
    
    • 详细说明

    方案的具体描述,文字描述不清楚的话可以结合图(任何图:UML,概念图,框图等)的方式说明,
    如果是改造方案最好突出变动的地方,以下列举了几种描述的角度:
    
    * 中间件架构(应用服务器、数据库、缓存、消息队列等)
    * 逻辑架构(模块划分、模块通信、信息流、时序等)
    * 数据架构(数据结构、数据分布、拆分策略、缓存策略、读写分离策略、查询策略、数据一致性策略)
    * 异常处理,容灾策略,灰度发布
    
    • 性能评估

    给出方案的基准数据,并按性能需求评估需要使用的资源数量。
    
    单机并发量
    单机容量
    按照预估性能需求,预估资源数量(应用服务器、缓存、存储、队列等)
    伸缩方式
    
    • 方案优缺点

    列出方案的优缺点,优缺点要具有确定性,不要有“存在一定风险”这种描述,也就是要量化。
    

    方案2:

    等等

    方案对比

    对比可选方案,并给出选择这种方案的理由,选择倾向的方案,

    风险评估

    标识所选方案的风险,提出解决此风险发生时候的应对策略,比如:上线失败时的回滚策略。

    工作量评估

    描述使用所选方案需要做的具体工作,并评估开发、测试等细化任务需要的时间,形成可实施的任务计划表,
    任务计划表推荐采用简单的表格形式,减少工具使用和学习的成本。

    性能和容量评估案例

    背景

    物流系统包含如下两个质量优先需求:

    • 维护会员常用地址,下单时提供会员地址列表。

    • 下单时异步产生物流订单,物流系统后台任务从第三方物流轮循拉取物流状态,已经下单用户查询订单的物流订单和物流记录。

    由于会员数量较大,可能有较快的增长速度,订单数量更是巨大,促销期峰值的订单产生量可能很高,这两个业务模块的数据存储需要分库分表,
    并借助消息队列和缓存抗写和读的流量,因此,本方案主要涉及这两个业务的容量评估。

    目标数据量级

    选取行业内一线电商平台的量级作为目标:

    • 会员量2亿,平均增长5万/天。

    • 平时订单量400万/天,所有订单下单时段集中在9:00-23:00,促销日订单量1400万/天,50%订单下单时段集中在晚上7:30-8:30和晚上22:00-23:00。

    量级评估标准

    • 通用标准

      • 容量按照峰值5倍冗余计算。

      • 会员常用地址容量按照30年计算,而物流订单时效性较强按照3年计算。

      • 第三方查询接口5000 QPS。

    • Mysql

      • 单端口读:1000 QPS

      • 单端口写:700 TPS

      • 单表容量:5000万条

    • Redis

      • 单端口读:4万 QPS

      • 单端口写:4万 TPS

      • 单端口内存容量:32G

    • Kafka

      • 单机读:3万 QPS

      • 单机写:5000 TPS

    • 应用服务器

      • 请求量每秒峰值:5000 QPS

    方案

    方案1:最大性能方案

    由于整个电商网站刚刚上线,数据量级还无法清晰的确定,我们根据行业内知名电商当前数据量级设计最大性能方案,
    本方案可以应对行业内电商巨头的各种促销所带来的服务请求峰值,并且拥有最快的响应时间,达到服务性能的最大化。

    需求1. 会员常用地址

    • 提供Restful服务增加会员常用地址。

    • 提供Restful服务获取会员常用地址列表。


    数据库资源评估:

    读QPS:

    会员每次下单,拉取一次会员地址列表,按照促销日订单量1400万/天,50%订单下单时段集中在两个小时内计算:

    (1400万 × 0.5) / (2 × 60 × 60) = 1000/秒
    

    容量评估按照5倍冗余计算,读QPS峰值1000/秒 * 5 = 5000/秒,需要5端口数据库服务读。

    写TPS:

    假设每天增加的会员全部添加一次常用地址,并且高峰期会员下订单时有20%的会员会增加一条常用地址:

    (1400万 × 0.2 + 5万) / (2 × 60 × 60) = 400/秒
    

    容量评估按照5倍冗余计算,400/秒 * 5 = 2000/秒,需要3端口数据库服务写。

    数据容量

    当前有2亿会员,每天增长5万会员,平均每个会员有5个常用地址,30年会员常用地址表数量计算:

    (2亿 + 5万 × 365 × 30年) × 5 = 35亿
    

    容量评估按照5倍冗余计算,35亿 * 5 = 175亿,需要350张表即可容纳。
    根据以上读QPS、写TPS的评估,如果读写混布我们共需要8端口,可以使用8主8备,
    如果读写分离,我们需要做主从部署,需要3主6从,与2倍数对齐,使用4主8从即可。
    根据表容量,需要350张表,和2的指数对齐,选择512张表,上面计算需要主库端口为4,
    考虑到将来端口扩展不用拆分数据库,尽量设计更多的库,使用32个库。

    设计结果:4端口 × 32库 × 4表, 4主8从
    
    缓存资源预估

    为了提高用户下单的体验,需要使用Redis缓存活跃用户的常用地址。
    定义当天下订单的会员为活跃会员,活跃会员的地址缓存24小时,
    假定每天下订单的会员均为不同会员,每个会员有5个常用地址,缓存大小计算如下:

    1400万 × 5 × 1k = 70G
    

    容量评估按照5倍冗余计算,70G×5=350G,按照每台Redis 32G内存计算,需要11台机器,
    根据数据库对数据存取QPS/TPS的设计,11台机器完全可以满足5000/秒的读QPS和2000/秒的写TPS。

    设计结果:11台,主从
    
    应用服务器资源评估

    根据数据库的读QPS(5000/s)峰值和写TPS(2000/s)峰值计算,单台应用服务器即可,选择2台避免单点。

    设计结果:2台
    

    需求2:物流订单和物流记录

    • 订单提交后,通过消息队列产生物流订单,消息传入物流系统,物流系统消费物流订单消息然后入库。

    • 后台任务轮循未完成物流订单,查询第三方物流接口状态,填写物流记录信息。按照每天1400万的订单,订单平均3天到货,第三方查询接口5000 QPS,
      每次状态查询需要时间计算如下:1400万 × 3 / 5000 = 8400 / 60 / 60 = 2小时,定时任务2小时查一次

    • 提供REST服务获取物流订单信息。

    • 提供REST服务获取物流记录信息。

    • 提供REST服务获取物流订单和物流记录信息。


    数据库资源评估


    读QPS:

    会员下单三天到货,三天内50%客户会查询一次物流订单和一次物流记录,计算如下:

    (1400万 × 3 × 0.5) / (24 × 60 × 60) = 250/秒
    

    容量评估按照5倍冗余计算,2 × 250/秒 × 5倍 = 2500/秒,需要3端口数据库服务读。

    写TPS
    会员每次下单,产生一次物流订单,按照促销日订单量1400万/天,50%订单下单时段集中在两个小时内计算:

    (1400万 × 0.5) / (2 × 60 × 60) = 1000/秒
    

    按照每天1400万的订单,订单平均3天到货,每条物流订单产生8条物流记录,并且8条物流记录在三天内均匀产生,物流记录写TPS计算如下:

    1400万 × 3 × 8 / 3 / (24 × 60 × 60) = 1200/秒
    
    数据容量

    当前2亿物流订单积累,每天增长400万订单,30年订单数量计算:

    2亿 + 400万 × 365天 × 3年 = 46亿
    

    容量评估按照5倍冗余计算,46亿 * 5 = 230亿,需要460张表即可容纳, 物流记录表是物流订单的8倍,460 × 8 = 3680张表。
    根据以上读QPS和写TPS,如果读写混布,我们共需要18端口,18主18备,如果读写分离,我们需要16主16从。
    根据表容量,需要3680张表,和2的指数对齐,选择4096张表,上面计算需要主库端口为16,考虑到将来端口扩展不用拆分数据库,尽量设计更多的库,使用32个库。

    设计结果:16端口 × 32库 × 8表,16主16从
    
    消息队列资源评估

    为了让系统能够应对峰值的突增,采用消息队列Kafka接收物流订单。
    根据上面对写TPS的计算,考虑5倍冗余后,峰值为5000/秒,单台Kafka和单台处理机即可处理。
    如果峰值有突增,可以增加Kafaka集群的节点来抗写流量,处理机根据后端入库性能来决定。
    例如写峰值增加10倍,达到5万/秒,需要10台Kafka,每台Kafka读QPS可达3万,理论上需要2台处理机,然而,处理机的瓶颈是后端入库的写TPS,
    根据上面计算,入库的写TPS峰值按照5000/秒设计,因此,单台处理机即可,这个场景下会有消息的堆积,但是最终会处理完毕,达到消峰的效果。

    设计结果:1台Kafka,主从,1台处理机
    
    应用服务器资源评估

    根据数据库的读QPS(2500/s)峰值和写TPS(11000/s)峰值计算,3台应用服务器即可。
    用于查询第三方接口的后台任务服务器,由于受到第三方接口5000/s的QPS的限制,单台机器即可,为了避免单点,2台处理机即可。

    设计结果:2台
    

    方案2:最小资源方案

    由于当前系统线上数据量并不多,增长量也不大,读QPS和写TPS单台机器完全可以处理,暂时不考虑使用缓存和消息队列,
    但是保留使用缓存和消息队列的接口,如果缓存和消息队列的资源可用,可以通过开关进行切换。

    当前的数据量使用单库单表即可处理,然而,考虑到将来扩容方便,数据库端口暂时使用一个,但是保留我们在最大性能方案中对数据库的分库分表,
    当读QPS和写TPS突增时,DBA可以把库重新拆分到多个端口来抗请求流量。

    因此,方案如下:

    • 需求:会员常用地址

    设计结果:1端口 × 32库 × 16表, 1主1从
    
    • 需求:物流订单和物流记录

    设计结果:1端口 × 128库 × 32表,1主1从
    

    总结

    • 当前线上流量并不大,使用最小资源方案节省成本。

    • 最小资源方案充分的考虑了数据库的分库分表,当读QPS和写TPS突增时,DBA可以拆分库到不同的端口,也就是增加端口来应对。

    • 最小资源方案在应用层设计了开关,如果性能突增可以临时申请和开启缓存和消息队列。

    总结内容

    本文以互联网企业重点关注的非功能质量为主线,总结了非功能质量需求的总体目标,并针对不同的服务和资源列举了不同的非功能质量需求,
    帮助读者在做技术评审的过程整理思路,尽量穷举评审时关注的评审点,并随后提供了一个简单有效的评审提纲,
    最后根据提纲实现一个互联网容量和性能评估的经典案例,大家可以在案例中了解高并发互联网系统是如何进行拆分的,以及依据哪些数据进行拆分。

    由于本文的数据完全是基于笔者在某个互联网平台下的经验而记录的,并不代表可以直接应用在任何企业和平台上,
    这里重点突出进行容量和性能评估的方法论,帮助大家整理实现高并发互联网系统的思路。

    QPS、TPS、并发用户数、吞吐量关系

    谷歌开源内部代码评审规范

    UML (统一建模语言) 各种图总结

    真实项目案例实战—【状态设计模式】使用场景

    欢迎分享转发,有帮助的话点个“在看”

    展开全文
  • 本系统采用四层架构设计 - 2 - 一、展现层 - 2 - Web前端 - 2 - 二、通讯层 - 2 - 三、服务层 - 3 - 四、数据层 - 4 - 其他系统: - 4 - 1、认证系统: - 4 - 2、日志系统: - 7 - 3、会话治理 - 8 - 4、DNS劫持处理...
  • 下面文档系本人开发的流媒体数字会议系统中控机的软件架构,有写的不好的地方,欢迎拍砖 1 .引言 1.1编写目的和使用范围 1.1.1 编写目的 本文档用来确定Nios的软件架构,以便帮助软件工程师更好的完成中控机的业务...


    下面文档系本人开发的流媒体数字会议系统中控机的软件架构,有写的不好的地方,欢迎拍砖

    1 .引言

    1.1编写目的和使用范围

    1.1.1 编写目的

    本文档用来确定Nios的软件架构,以便帮助软件工程师更好的完成中控机的业务逻辑功能。

    1.1.2 使用范围

    本文档适用于飞利信的流媒体总线有线数字会议系统,中控机和终端开发工程师,以及相关产品经理和项目经理。

     

    1.2术语表

    Nios  Nios嵌入式处理器ALTERA公司推出的采用哈佛结构、具有32位指令集的第二代片上可编程的软核处理器,其最大优势和特点是模块化的硬件结构,以及由此带来的灵活性和可裁减性。

     

    SOPC : System-on-a-Programmable-Chip,即可编程片上系统用可编程逻辑技术把整个系统放到一块硅片上,称作SOPC。可编程片上系统(SOPC)是一种特殊的嵌入式系统:首先它是片上系统(SOC),即由单个芯片完成整个系统的主要逻辑功能;其次,它是可编程系统,具有灵活的设计方式,可裁减、可扩充、可升级,并具备软硬件在系统可编程的功能。

     

    FPGA : FPGAFieldProgrammable Gate Array),即现场可编程门阵列,它是在PALGALCPLD等可编程器件的基础上进一步发展的产物。它是作为专用集成电路ASIC)领域中的一种半定制电路而出现的,既解决了定制电路的不足,又克服了原有可编程器件门电路数有限的缺点。

     

    TDM TDM就是时分复用模式。时分复用是指一种通过不同信道或时隙中的交叉位脉冲,同时在同一个通信媒体上传输多个数字化数据、语音和视频信号等的技术。

     

     

     

     

     

     

     

    2 .中控机

    2.1中控机功能需求

    1) 实现脱机或联机流程下,会议系统的报到、表决、发言、摄像头追踪等功能;

    2) 联机流程下,实现对FPGA、终端、前面板等模块的在线升级功能;

    3) 连接终端的六路通道实现独立并行工作,互不干扰;

    4) 通过网口或者串口与上位机进行通信;

    5) 实现十六路语音数据的混音输出(不需要Nios 软件进行干预)。

     

    2.2整体方案简介

    中控机的整体设计方案中,依据硬件和功能划分如下

    1. FPGA芯片为ALTERAS3C55,芯片的功能可以分为三个部分:

    a. FPGA :实现Nios 与外界(PC机的网口,串口,终端,前面板)通信的基本功能,不做业务逻辑控制

    b. SOPC : 搭建一个可裁剪定制的CPU+RAM+存储接口+外围电路 硬件平台;

    c. Nios软件 :在SOPC 搭建的嵌入式处理器上运行的软件,负责各种业务逻辑的实现。

    2. DSP芯片为TI5509,用来实现混音算法;

    3. 音频AD/DA芯片,用于语音的输入和输出。

    2.3 对外接口定义

    2.3.1与前面板接口

        FPGA与前面板通过串口通信,NIOSFPGA通过轮询管脚电平方式读取数据。

    2.3.2PC接口

        FPGA与上位机有两个接口,一个为串口通信,一个为网口通信。NIOSFPGA之间通过轮询管脚电平方式读取数据。

       2.3.3与终端接口

        FPGA与终端通过网口通信。下行时,NIOSFPGA通过2ms定时中断(FPGA提供)发送数据;上行时,通过轮询管脚电平方式读取数据。

     

    2.4 FPGA系统功能框图


    上图蓝色部分为FPGA编程实现的电路部分,NIOS II部分为SOPC创建的CPU内核以及其上运行的软件。

    1.上位机 中控机的通信接口为 UART 和 网口,串口和网口的通信功能由FPGA来实现,Nios 来实现对业务逻辑的控制;

    2.终端 中控机的通信接口为 PRSM Bus,PRSM的通信功能由FPGA来完成,Nios 来实现对业务逻辑的控制;

    3.前面板 中控机主板的通信接口为串口,通信功能由FPGA来完成,Nios 来实现对业务逻辑的控制;

    4.中控机音频增益部分控制的通信接口为IO控制,通信功能和逻辑控制由Nios 来实现。

    2.5软件系统框图


    PRSM Bus 会议系统按照MVC架构划分如上图所示,最核心的中控机承担MODEL的角色

     

     

     

     

     

     

     

     

     

    3 .Nios 软件系统架构

    3.1软件预期

    除中控机本身业务需求(报到,表决,发言等)外,还需注意如下几点:

     

    首先PRSM Bus 会议系统是一个TDM在同一条线路中实现通信,两毫秒的时钟为一个节拍,所以Nios 软件与终端间的通信就要按两毫秒的节拍来;

     

    其次,中控机有六个独立的通道,每个通道连接的最大设备为254台,六个通道相互独立,可以并行工作;

     

    第三,在一个物理通道内,同一个两毫秒节拍内中控机只能下发一条通信数据,所以中控机下发任务是抢占式的,其中上位机下行的消息优先级最高,其次是前面板的消息,第三位的是终端的应答消息,最后是中控机的正常轮询任务;

     

    第四,01号地址是特殊地址,可以用于连接唯一的主席机,脱机状态主席机可以进行简单的会议控制;

     

    第五,上位机接口(网口,串口)以及前面板的串口都接收数据的时候都采用流式解析方式,即每收到一个字节都进入解析程序进行判断数据合法性;

    3.2总体架构

    Nios 软件整体上采用面向对象的思想,自顶向下各个类依次如下图:

     

    Nios 软件分为三层,自底向上依次为:

    a. 驱动层: 跟硬件BSP 直接相关,基于BSP层函数实现硬件驱动层接口;

    b. 硬件抽象层:用于隔离业务层和驱动层,该层代码的功能是对硬件的操作,但是隐藏了硬件相关的细节;

    c. 业务层: 主要用于实现 PRSM Bus 协议。

    3.3数据结构

    按照面向对象的思想进行代码编写,所以数据结构类似于上面的总体架构图,下面列举几个主要的数据结构:

    1) 主结构体 FLX_CCU 

     

    2) FLX_CCU_CAMERA

     

    3) FLX_CCU_LCD

     

    4) FLX_CCU_PC

     

    5) FLX_CCU_TERMINAL

     

    6) FLX_CCU_MANAGE

     

    7) FLX_CCU_MANAGE_REGISTE

     

    8) FLX_CCU_MANAGE_SPEAK

     

     

     

    9) FLX_CCU_MANAGE_TERMINAL

     

    10) FLX_CCU_MANAGE_VOTE 

    3.4模块设计

    3.4.1模块划分依据面向对象的思想,对象FLX_CCU ,包含五个对象

    a. FLX_CCU_CAMERA,负责与集控主机进行通信,完成摄像联动;

    b. FLX_CCU_LCD,负责与前面板进行通信,完成显示信息和设置参数;

    c. FLX_CCU_PC,负责与上位机进行通信,完成会议相关的控制功能;

    d. FLX_CCU_TERMINAL,负责与终端设备进行通信;

    e. FLX_CCU_MANAGE,负责对系统(除上位机)的整体状态,功能进行管理;

    这些子模块只完成基本的功能,例如 FLX_CCU_LCD ,完成基本收发数据功能,并且完成收发数据的基本处理(接收数据的包格式合法性判别,发送的数据按包格式打包),不处理业务,也就是不判断收发数据的内容。

     

    注意,上图中的函数指针为对象的方法,需要向对待接口一样,将这些方法功能一一实现,否则会出现空指针的非法访问。

    结构如下图:


    3.4.2模块间通信

    各个模块完成自己模块的功能,模块间通信(实际就是业务的处理)在子模块的上一层来完成,这样就保证了模块内部内聚性和模块间的低耦合性。

    如图3.4.1的结构图,所有模块间的通信都是发生在业务层的最顶层对象内FLX_CCU,所以业务逻辑可以作为FLX_CCU 对象的方法。

     

    如上图所示,共需要四个数据处理的方法:

    1) 解析并响应上位机串口接收的数据;

    2) 解析并响应上位机网口接收的数据;

    3) 解析并响应前面板串口接收的数据;

    4) 解析并响应终端设备PRSM Bus口接收的数据.

     

     

    展开全文
  • 在架构师整个的成长过程中,必定会经历编制架构设计说明书、评审架构设计说明书以及根据业务需求分析设计系统架构的三个过程。 架构设计是需求分析到软件实现的桥梁,也是决定软件质量的关键。编制架构设计说明书是...

    架构设计是需求分析到软件实现的桥梁,也是决定软件质量的关键。编制架构设计说明书是开发人员向架构师转变必定会经历的过程。在架构师整个的成长过程中,必定会经历编制架构设计说明书、评审架构设计说明书以及根据业务需求分析设计系统架构的三个过程。

    架构设计是需求分析到软件实现的桥梁,也是决定软件质量的关键。编制架构设计说明书是开发人员向架构师转变必定会经历的过程。在架构师整个的成长过程中,必定会经历编制架构设计说明书、评审架构设计说明书以及根据业务需求分析设计系统架构的三个过程。作为一个架构师,我想尝试一下根据这三个过程对不同能力需要,写一次系列文章,包括《架构设计三部曲之如何写架构设计说明书》、《架构设计三部曲之如何评审架构设计说明书》以及《架构设计三部曲之如何做架构设计》,一来可以帮助自己整理思路,重新审视架构设计,二来也可以与大家分享心得,听取大家的意见,共同进步。本篇属于系列中的第一篇。

    那么到底如何编写架构设计说明书?该说明书应该包括哪些方面的内容呢?我们知道,架构设计说明书是阐述系统架构具体内容的,根据我之前的文章《我的架构观-架构未来的发展》我们明白架构的本质是呈现三大能力:即系统如何面向最终用户提供支撑能力、如何面向外部系统提供交互能力、如何面向企业数据提供处理能力。因此从这个角度看,对架构设计说明书的章节的设置及章节内容安排应该要能说明清楚系统架构到底是如何呈现这三种能力的,让我们逐个分析:

    系统如何面向最终用户提供支撑能力:这一点是要从系统自身的能力来看,即本系统到底应该具备哪些功能,各功能间如何协作以满足支撑最终用户的使用,其实就是要讲系统的功能架构或逻辑架构,回答系统从功能粒度上划分了几个功能模块或子系统,各模块或子系统之间的内部接口关系如何等问题。当然还有一个需要考虑的问题,在纵向维度上,随着架构设计理念的不断发展, 逻辑架构模型从最初的展示-数据两层模型,到展示-逻辑-数据(所谓的MVC)三层模型,甚至到展示-调用接口-逻辑-数据接口-数据五层模型,不同层次表明系统内部设计的精细程度,因此在逻辑架构设计中也需要针对实际情况加上这种分层设计的内容。尤其是对于powser/Server架构模式的MIS类系统,这种层次更为常见。另外,用户相对于机器来说对系统提供的能力是有个人喜好要求的,不仅要求系统能提供支撑,而且还要更加稳定的、更方便的、灵活的、快速的等提供,这就需要在架构设计说明书中增加所谓非功能性的设计,即需要描述系统的性能、高可用、可扩展性、可维护、安全性、可移植性等。

    系统如何面向外部系统提供交互能力:这一点是要把系统当成一个完整的整体,阐述它如何与外部的系统发生调用关系,外部系统为它提供了哪些开放接口,它又为外部系统提供了哪些外部接口和能力,同时,在这种相互的调用关系中它处于整个IT架构的何种位置,这其实就是在说系统的整体架构。另外,如果我们把操作系统和硬件服务器也当成一类特殊的外部系统的话,就需要说明系统如何基于操作系统利用硬件服务器来提供计算、存储、网络等能力,系统如何把自己拆分成不同的部分以便部署在服务器上,这其实说的是部署架构。

    如何面向企业数据提供处理能力:信息系统的原始驱动力就是人们需要借助计算机的强大计算能力来辅助处理大量数据,从而形成可理解的信息,并最终形成可掌握的知识。因此数据处理是系统的根本目的,至关重要,在架构设计说明书中需要单独描述系统对数据的处理能力,即我们所谓的系统数据架构。这还是可以从对外和对内两个角度来看,对外即需要说明本系统处理的数据在整个企业数据流中所处的位置,与相关的上下游数据之间的关系,本系统需要从数据上游的外部系统获取哪些数据?又需要为数据下游的系统提供哪些数据;对内需要说明本系统根据业务需求设计了哪些关键数据表,它们之间是何种主外键关系,是否需要从外部导入数据为系统做数据初始化等。当然还有对数据管理的描述,包括如何做数据冗余设计,备份机制,数据安全管理机制等。

    好,分析完这三种能力,我们几乎就找出了架构设计说明书中应该包括的内容,包括整体架构、逻辑架构、数据架构、部署架构、内外部接口、非功能性设计等,如果纯把架构设计作为理论研究,有这些也就够了。但是现实中我们编制架构设计说明书毕竟是用来指导我们后续系统开发的,是需要真正落地实施的,因此就会涉及使用何种技术实现?有哪些关键技术?用到了何种成熟或开源技术组件?复用了哪些之前的技术成果?等等,同时也包括对技术风险的考虑与预防措施。所有这些就是技术架构的内容。

    综上,我们就可以得到一份完整的架构设计说明书的结构及应该包含的内容,其大致章节应该是这样的:

    文档概述:包含项目背景、项目目标、文档版本信息、目标读者、参考文档、名词解释之类的一般文档都会有的章节;

    整体架构:主要从整个IT层描述系统所处的位置,与周边关联系统之间的调用关系;

    逻辑架构:系统内部功能模块的划分以及各模块功能介绍、相互之间的关系表述;

    接口设计:包括系统间的接口设计以及内部功能模块之间的接口设计;

    数据架构:本系统与上下游系统间的数据流关系,以及本系统关键数据表设计、数据管理策略等;

    技术架构:实施此架构需要用到哪些技术能力,有哪些复用能力及风险;

    部署架构:系统如何部署,网络拓扑上有何要求,对硬件服务器有何要求,需要几台,是否需要优化服务器参数;

    非功能性设计:性能、高可用、可扩展性、可维护、安全性、可移植性等。

    其他说明:如特别约束条件、风险考虑、进度要求、政策限制、环境影响等;

    以上,便是我认为一份较为完整的架构设计说明书应该包括的内容了。

    转自:http://developer.51cto.com/art/201506/478487.htm

    转载于:https://www.cnblogs.com/jshen/p/7919265.html

    展开全文
  • 在架构师整个的成长过程中,必定会经历编制架构设计说明书、评审架构设计说明书以及根据业务需求分析设计系统架构的三个过程。作为一个架构师,我想尝试一下根据这三个过程对不同能力需要,写一次系列文章,包括...

    架构设计是需求分析到软件实现的桥梁,也是决定软件质量的关键。编制架构设计说明书是开发人员向架构师转变必定会经历的过程。在架构师整个的成长过程中,必定会经历编制架构设计说明书、评审架构设计说明书以及根据业务需求分析设计系统架构的三个过程。作为一个架构师,我想尝试一下根据这三个过程对不同能力需要,写一次系列文章,包括《架构设计三部曲之如何写架构设计说明书》、《架构设计三部曲之如何评审架构设计说明书》以及《架构设计三部曲之如何做架构设计》,一来可以帮助自己整理思路,重新审视架构设计,二来也可以与大家分享心得,听取大家的意见,共同进步。本篇属于系列中的第一篇。

        那么到底如何编写架构设计说明书?该说明书应该包括哪些方面的内容呢?我们知道,架构设计说明书是阐述系统架构具体内容的,根据我之前的文章《我的架构观-架构未来的发展》我们明白架构的本质是呈现三大能力:即系统如何面向最终用户提供支撑能力、如何面向外部系统提供交互能力、如何面向企业数据提供处理能力。因此从这个角度看,对架构设计说明书的章节的设置及章节内容安排应该要能说明清楚系统架构到底是如何呈现这三种能力的,让我们逐个分析:
    1. 系统如何面向最终用户提供支撑能力:这一点是要从系统自身的能力来看,即本系统到底应该具备哪些功能,各功能间如何协作以满足支撑最终用户的使用,其实就是要讲系统的功能架构或逻辑架构,回答系统从功能粒度上划分了几个功能模块或子系统,各模块或子系统之间的内部接口关系如何等问题。当然还有一个需要考虑的问题,在纵向维度上,随着架构设计理念的不断发展, 逻辑架构模型从最初的展示-数据两层模型,到展示-逻辑-数据(所谓的MVC)三层模型,甚至到展示-调用接口-逻辑-数据接口-数据五层模型,不同层次表明系统内部设计的精细程度,因此在逻辑架构设计中也需要针对实际情况加上这种分层设计的内容。尤其是对于Browser/Server架构模式的MIS类系统,这种层次更为常见。另外,用户相对于机器来说对系统提供的能力是有个人喜好要求的,不仅要求系统能提供支撑,而且还要更加稳定的、更方便的、灵活的、快速的等提供,这就需要在架构设计说明书中增加所谓非功能性的设计,即需要描述系统的性能、高可用、可扩展性、可维护、安全性、可移植性等。
    2. 系统如何面向外部系统提供交互能力:这一点是要把系统当成一个完整的整体,阐述它如何与外部的系统发生调用关系,外部系统为它提供了哪些开放接口,它又为外部系统提供了哪些外部接口和能力,同时,在这种相互的调用关系中它处于整个IT架构的何种位置,这其实就是在说系统的整体架构另外,如果我们把操作系统和硬件服务器也当成一类特殊的外部系统的话,就需要说明系统如何基于操作系统利用硬件服务器来提供计算、存储、网络等能力,系统如何把自己拆分成不同的部分以便部署在服务器上,这其实说的是部署架构
    3. 如何面向企业数据提供处理能力:信息系统的原始驱动力就是人们需要借助计算机的强大计算能力来辅助处理大量数据,从而形成可理解的信息,并最终形成可掌握的知识。因此数据处理是系统的根本目的,至关重要,在架构设计说明书中需要单独描述系统对数据的处理能力,即我们所谓的系统数据架构。这还是可以从对外和对内两个角度来看,对外即需要说明本系统处理的数据在整个企业数据流中所处的位置,与相关的上下游数据之间的关系,本系统需要从数据上游的外部系统获取哪些数据?又需要为数据下游的系统提供哪些数据;对内需要说明本系统根据业务需求设计了哪些关键数据表,它们之间是何种主外键关系,是否需要从外部导入数据为系统做数据初始化等。当然还有对数据管理的描述,包括如何做数据冗余设计,备份机制,数据安全管理机制等。
            好,分析完这三种能力,我们几乎就找出了架构设计说明书中应该包括的内容,包括整体架构、逻辑架构、数据架构、部署架构、内外部接口、非功能性设计等,如果纯把架构设计作为理论研究,有这些也就够了。但是现实中我们编制架构设计说明书毕竟是用来指导我们后续系统开发的,是需要真正落地实施的,因此就会涉及使用何种技术实现?有哪些关键技术?用到了何种成熟或开源技术组件?复用了哪些之前的技术成果?等等,同时也包括对技术风险的考虑与预防措施。所有这些就是技术架构的内容。
        综上,我们就可以得到一份完整的架构设计说明书的结构及应该包含的内容,其大致章节应该是这样的:
    1. 文档概述:包含项目背景、项目目标、文档版本信息、目标读者、参考文档、名词解释之类的一般文档都会有的章节;
    2. 整体架构:主要从整个IT层描述系统所处的位置,与周边关联系统之间的调用关系;
    3. 逻辑架构:系统内部功能模块的划分以及各模块功能介绍、相互之间的关系表述;
    4. 接口设计:包括系统间的接口设计以及内部功能模块之间的接口设计;
    5. 数据架构:本系统与上下游系统间的数据流关系,以及本系统关键数据表设计、数据管理策略等;
    6. 技术架构:实施此架构需要用到哪些技术能力,有哪些复用能力及风险;
    7. 部署架构:系统如何部署,网络拓扑上有何要求,对硬件服务器有何要求,需要几台,是否需要优化服务器参数;
    8. 非功能性设计:性能、高可用、可扩展性、可维护、安全性、可移植性等。
    9. 其他说明:如特别约束条件、风险考虑、进度要求、政策限制、环境影响等;
    以上,便是我认为一份较为完整的架构设计说明书应该包括的内容了。
    展开全文
  • 在架构师整个的成长过程中,必定会经历编制架构设计说明书、评审架构设计说明书以及根据业务需求分析设计系统架构的三个过程。作为一个架构师,我想尝试一下根据这三个过程对不同能力需要,写一次系列文章,包括...
  • 指导如何书写软件系统的架构说明书,详细描述了每个段落改如何撰写。 500强软件企业内部资料,解释项目从软件质量管理手册中选取的特定的生命周期模型项目遵循的流程。
  • 前言架构设计是需求分析到软件实现的桥梁,也是决定软件质量的关键。编制架构设计说明书是开发人员向架构师转变必定会经历的过程。承接上文:如何做架构设计说明书 (点击直达)本文来说一下如何写架...
  • TM_架构设计说明书

    2018-01-05 13:50:51
    本文档描述了××系统最高层次...该设计主要依据用户需求规格说明,主要读者为项目经理、维护人员、设计人员、开发人员和测试人员,也可供客户、第三方产品的相关人员阅读,同时该文档最终将作为软件需求和设计的依据。
  • 软件外包写作_保险商务系统_架构设计规格说明书软件外包写作_保险商务系统_架构设计规格说明书
  • 对该软件的整个系统的结构关系进行了详细描述,阐述了系统的总体框架,包括物理、逻辑结构,说明了体系结构所采取的设计策略和所有技术,并对相关内容做出了统一的规定。为今后的设计、编码、测试都提供了可以参考的...
  • 软件概要设计说明书

    2018-09-07 16:47:46
    软件概要设计说明书模板,供售后等技术人员参考。本文档各章节间逻辑清晰,内容全面。是一份比较好的文档。文档一级目录分为以下五部分:总体设计、系统功能设计、数据库设计、系统维护设计、附录等。总体设计包含...
  • 架构设计 例子和实践 系统设计说明书(架构、概要、详细)目录结构演进架构中的领域驱动设计Web架构设计经验分享软件架构设计从MVC框架看MVC架构的设计领域驱动设计(Domain Driven Design)参考架构详解关于垂直切分...
  • 项目名称> ...软件架构设计说明书   文档状态: [发布版/草稿版] 当前版本:   作 者:   编写日期:   评审人:   评审日期:
  • 资源名称:架构实战软件架构设计的过程内容简介:本书从基本原理入手,介绍软件架构设计过程中涉及的一些概念、流程、方法、用到的工作产品及可重用的资源,从第6章开始,通过介绍一个具体的案例来阐述如 何定义需求...
  • 软件设计说明书范例,说明软件设计架构、采用的技术、功能设计、接口。
  • 本书从基本原理入手,介绍软件架构设计过程中涉及的一些概念、流程、方法、用到的工作产品及可重用的资源,从第6章开始,通过介绍一个具体的案例来阐述如 何定义需求、创建逻辑架构、创建物理架构。在第10章“进阶”...
  • 一、软件架构的定义 1、为什么要引入软件架构?...但是,在实际工作中存在一种情况,进行软件设计的人员感觉到《软件需求规格说明书》对他没有什么用,还是需要去根据软件的功能进行设计,这就意味着在需求分析和
  • 软件架构设计整理笔记 1 第一章 软件架构概念的分类 第二章 架构对新产品的作用 第三章 架构师职责 第四章 项目经理与构架师的分工与协作 第五章 架构设计为开发人员解决什么问题 第六章 开发过程 第七章 软件的质量...
  • 文章目录引言编写目的背景定义参考文献总体设计用户需求规定教师、助教学生管理员游客其他需求规定运行环境基本设计概念和处理流程结构系统模块架构数据库ER图人工处理过程尚未解决的问题接口设计用户接口外部接口...
  • 目录 1. 引言 1.1 编写目的 1.2 术语或缩写 2. 总体设计 2.1 系统说明 2.2 运行环境 2.3 关键技术 2.4 总体架构设计 3. 系统模块设计 4. 数据库设计 4.1 逻辑设计

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 762
精华内容 304
关键字:

软件架构设计说明书