软件架构与需求分析

软件架构与需求分析
    
软件架构体系 :
    1.系统与子系统 :    
        系统 : 由一群有关联的个体组成,根据某种规则运作,能完成个别元件不能单独完成的工作的群体--就比如一个团队
            关联 : 系统是由一群有关联的个体组成,没有关联的个体堆在一起不能成为一个系统
            规则 : 系统内的个体需要按照指定的规则运作,而不是单个个体各自为政,规则规定了系统内个体的分工和协作的方式
            能力 : 系统的能力与个体能力有本质的差别,系统能力不是个体能力之和,而是产生了新的能力

        子系统 : 也是由一群有关联的个体所组成的系统,多半会是更大系统中的一部分.子系统的定义和系统定义是一样的,只是观察的角度有差异,一个系统可能是另外一个更大系统的子系统
    2.模块,组件,服务 :
        模块 : 是一套一致而互相有关联的软件组织,分别包含了程序和数据结构的两部分.现代软件开发往往使用模块作为合成单位
        组件 : 自包含的,可编程的,可重用的,与语言无关的软件单元,组件可以很容易被用于组装应用程序中模块和组件的组成部分,只是从不同的角度拆分系统而已
            例 :
                1.从逻辑的角度拆分系统后,得到的单元就是"模块",从物理的角度拆分系统后得到的单元就是"组件"
                2.划分模块的主要目的是职责分离;划分组件的主要目的是单元复用
        服务 : 服务和组件有某种相似之处 : 他们都将被外部的应用程序使用.两者之间最大的差异在于 :
            1.组件是在本地使用的(例如: jar文件)
            2.而服务是运行起来的,要通过同步或异步的远程接口来远程使用(例如 : RestFul接口,web service,消息系统,RPC,或者socket)
        服务是可以单独运行,并且对外提供功能的一种形式.可以将一个复杂的项目分解成多个服务.
        当一个服务挂掉时不会拖垮整个系统.如果没有服务化,每当一个新的功能被添加到系统中就会影响到所有功能
        如果采取服务化,每个服务只对气上下游的服务负责

架构原则 :
    1.解耦 : 在软件工程中,耦合指的是对象之间的依赖性.对象之间的耦合度越高,维护成本就越高.因此对象的设计应使类和构件之间的耦合度最小
        软件设计中通常用耦合度和内聚度作为衡量模块独立程度的标准.
        划分模块的准则 : 高内聚,低耦合
        解耦方式 : 面向接口编程  消息队列  

        耦合性存在于各个领域,而非软件设计中独有的,理论上说绝对的零耦合是做不到的,但可以通过一些方法降耦合度降至最低,降低耦合度即可理解为解耦
        在设计上解耦的核心思想是 : 彼此独立,互不依赖
    2.分层 : 最为流行的
        分层结构是最为流行,应用最为广泛的应用软件的设计方式.在应用了分层结构的系统中,各个子系统按照层次的形式组织起来,上层使用下层的各种服务,而下层对上层一无所知.
        每一层都对自己的上层隐藏其下层的细节
        经典的三层架构 :
            在软件架构中,经典三层架构自顶向下由用户界面层,业务逻辑层,数据访问层组成.在提出该分层架构的时代,多数系统往往较为简单,本质上都是一个单体架构的数据库管理系统
            这种分层系统有效的隔离了业务逻辑与数据访问逻辑,使得这两个不同关注点能够相对自由和独立演化
        分层的设计原则 : 保证同一层的组件处于同一抽象层次,单一抽象层次原则
            例 :
            1.表现层 : PC端的组件/移动端的组件 --- 面向用户的
            2.控制层COntroller : 控制程序流转 --- 面向应用
            3.引擎层 : 实体类/数据 --- 面向业务
            4.基础层 : 数据库/MQ/Redis... --- 面向资源
    3.封装 :
        在一个类中每当对象的状态保持相对独立,就实现了封装.其余的对象并不能观察到这对象的状态,他们能做到的只有调用一些被称作"方法"的通用功能
        因此,对象使用方法掌握着自己的状态,除非明确允许,没有其他人可以接触到它.如果需要和这个对象交流,就需要使用提供的方法,默认情况下无法改变对象的状态

架构的方法 :
    架构图是为了表示软件系统的整体轮廓和各个组件之间的相互关系和约束边界,以及软件系统的物理部署和软件系统的演进放心的整体实体.要让干系人理解,遵循架构决策,就需要吧架构信息传递出去,架构图就是一个很好的载体.不同的视角和角色,关注点也是不同的,看到的架构图是不一样的
    1.业务架构 :
        从整个系统最高的层次来看我们的系统,使用者 : CEO,CIO,CTO,产品总监
        需要展现 :
            1.有整体的核心业务流程
            2.核心能力
            3.面向全局的系统
    2.功能架构 : 可以直观的展示业务功能
    3.系统架构 : 站在用户请求的层次去分析
        例: 前端请求 --  网关(路由,负载) -- 应用集群 -- 公共服务层 -- 组件(mysql,redis,分布式缓存,分布式会话...) 
    4.技术架构 : 站在技术栈的角度(例: 前端技术栈,后端技术栈,微服务技术栈,存储技术栈...),对技术分层
        展示层 : 安卓,苹果,小程序,PC端,公众号...
        网关层 : nginx集群,zuul集群,防火墙,vpn......
        业务层 : 服务治理(配置中心,注册中心,服务熔断,授权的服务...),集群服务(按照功能划分)
        技术平台 : mysql,redis,mq......
    5.数据架构 : 使用者 : 系统架构师,数据架构师
        1.数据模型(可以人为是一张表),展示的是数据库设计(每张表都有自己的结构)
        2.大数据平台架构(展示大数据平台下的数据是怎么使用的,数据采集(日志,HTTP...) -- 数据存储与分析(HDFS做数据离线分析,kafka数据实时分析...) -- 数据共享层(数据可以存储在 关系型数据库/redis/HBase...) -- 数据应用层(报表,接口,数据可视化...)),展示数据的处理过程
    6.部署架构 : 使用者 : 运维架构师

架构的演进 :
    操作系统 : windows,linux
    应用服务器 : tomcat,jetty,jboos,apache,weblogic,websphere......
    数据库 : mysql,oracle,db2......
    应用系统 : java,php,asp等各种语言开发
    1.单体架构 :
        所有的业务逻辑都在单一应用系统,单应用,单数据库.数据库部署在和应用相同的虚拟机或服务器上,或者放置在另外一台机器上
        优势 :
            1.节省服务器资源,投入少
            2.管理简单 : 上线,部署,监控,问题排查等比较简单
            3.开发简单 : 软件系统功能整合在一起,不需要考虑太多的服务依赖问题,代码管理比较简单
            4.测试简单 
        缺陷 :
            1.可用性差 : 应用和数据库都是单点,无论应用还是数据库出现问题,整个系统的就会不可用了
            2.稳定性差 : 系统耦合度高,新增或修改任何一个功能,哪怕只是一行代码,也需要重启服务器,此时服务器是不可用的
            3.性能差 : 单一的应用服务器和数据库服务器,性能总会有上限的,当用户变多或者准确的说相同时刻并发访问多时,系统就容易挂掉

    2.分布式架构 : 其实就是多个实例提供服务
        1.应用集群 :
            1.反响代理服务器 : 把用户请求反向路由到应用服务器,常用的反向代理服务器 : nginx/HAProxy
            2.应用服务器 : 集群化部署
            3.数据库服务器 : 主从部署

            优点 :
                1.可用性高 : 代理服务器,应用服务器,数据库服务器都是做了集群的,当某台机器挂掉后,其他机器能够几乎无感的接替下任务
                2.性能高 : 用户请求分发到多个应用服务器上,整体性能接近单体架构的三倍(同配置情况下)
                3.安全性高 : 外网用户访问的是反向代理服务器,应用和数据库隔离在内网

        2.分布式缓存 :
            缓存分为多级缓存 : 本地缓存(JVM中),分布式缓存服务器(Redis集群等).本地缓存的访问速度更快一些,但是受应用服务器内存限制,其缓存数据量有限,而且会出现和应用程序争用内存的情况,远程分布式缓存可以使用集群的方式,部署大内存的服务器作为专门的缓存服务器,可以在理论上做到不受内存容量限制的缓存服务.常见的服务器包括redis,memcached等.使用缓存访问压力得到有效缓解

        3.业务拆分 : 按照业务进行模块的拆分
            水平拆分 : 例 : 拆分成商品,订单,用户,支付等多个系统,每个系统都是多台服务器构成的集群
            垂直拆分 : 将一些公共业务和服务,如用户中心,拆分为 : 注册登录中心,用户中心,短信,文件,消息等各种公共服务,从业务系统中拆分剥离出来.
            优势 :
                1.应用系统增加了,能够想要更多的应用请求
                2.公共服务能够提供给所有应用使用,达到服务复用的效果
            缺陷 :
                数据库可能只有一个,单一的数据库的处理能力是有限的,随着用户并发量持续增多,数据库将会是系统的瓶颈

        4.分库分表,读写分离 :
            1.读写分离 : 应用服务器在写数据的时候,访问主数据库,,主数据库通过主从复制机制,将数据更新同步到从数据库.当应用进行读操作时,可以通过从数据库获取数据
            2.分库分表 : 数据库中数据量非常大是,执行查询操作也是非常耗时的,相当于数据的处理遇到了瓶颈,另外,单库发生意外时需要修复的是所有数据,多库中一个库发生意外,只需要修复一个库
                可以对用户,商品,订单,交易进行分库,不同数据库中对数据按时间进行分表
            通常应用服务器端使用专门的数据访问模块,使数据库的分库分表,读写分离对应用透明

            优势 :
                性能得到显著提升

            缺陷 :
                管理,维护成本高

        5.静态化和CDN : 加速网站的访问速度,CDN(遵循就近原则),静态话页面/静态资源放在CDN服务器

        6.异步解耦 : 从直接依赖变成异步处理

    3.微服务架构 : 是分布式架构进一步的深化,分布式架构偏向于部署和环境,微服务专注于业务拆分,通过组件组合快速开发(业务单一的服务可以独立部署,系统灵活)
        1.服务注册发现组件 : 进行服务治理
        2.服务网关组件 : 请求的统一入口和权限控制
        3.负载均衡组件 : 提供客户端与服务器的负载均衡
        4.集中配置组件 : 服务集中管理
        5.熔断器组件 : 提供服务熔断
        6.服务追踪组件 : 提供服务监控

        微服务项目可以快速迭代和持续交付
        缺陷 :
            开发人员需要关注业务逻辑外,还需要考虑业务的一系列问题 : 服务的注册发现,通讯,熔断,超时等

服务化 : 微服务强调的是业务系统需要完善的组件化和服务化
    1.为什么需要服务化 :
        各个大系统的堆砌整体存在的问题 :
        1.扩展性差
        2.可靠性不高
        3.维护成本高
        4.重复的轮子很多
    解决方式 :
        1.组件化,服务化

    组件化 :
        将一个大系统,按照一定的业务或者技术维度,拆分成独立的组件.目的是为了分而治之,可重用,减少耦合度
        例 : 按照技术维度 : 文件上传下载组件,短信发送组件,搜索组件,缓冲组件
             按照业务维度 : 用户中心,商品中心,支付中心等
    服务化 :
        1.调用简单
        2.代码复用
        3.业务隔离
        4.数据库解耦

        存在的问题 :    
            1.本身不大的系统,业务不复杂的系统不需要微服务架构
            2.多模块数据库,分布式是一个挑战
            3.增加了运维,测试等事物的复杂性

常见的需求问题 :
    1.需求不明确 :
        1.各阶段人员只掌握一段,盲人摸象
        2.初期阶段业务还在摸索
        3.各部门的API和目标不一致,需求有冲突
        等等...

    2.需求理解不一致 :
        1.不同的人对需求的理解会有所区别

    项目最重要的阶段是进行需求分析,明白真正的需求,项目需求指的是用户真正需要什么,而不是供应商假设用户需要什么和供应商能够供应什么.
    需求的准确定位就是按用户要求,对目标系统提出完整,准确,清晰,具体要求.
    这对一个项目的成功来说非常重要,需求分析做的不好,就会造成需求不断变更,从而影响进度,费用,甚至导致项目失败

    3.需求自身经常变动 :
        1.尽可能的分析请求那些需求是稳定的,那些是容易变动的,以便进行系统设计时,将软件核心建筑在稳定的需求上

需求获取 :
    1.需求来源 :
        1.干系人 : 对系统有利益关系的个人,团队,组织,和其他系统
        例 :
            投资方(系统的投资方),主管方(批准/管理系统的),最终用户(用户/系统受益方),操作方(操作/维护系统的),监管方(认证系统的),测试方(负责系统验收的)等等
    2.需求分类 :
        1.业务需求 : 对应需要达到系统的目标
        2.用户需求 : 描述用户使用产品必须要完成什么任务,怎么完成需求,通常是进行用户访谈,调查,对用户使用的场景进行整理,从而简历从用户角度的需求
            必须能够提现软件系统将给用户带来的业务价值,也就是说用户需求描述了用户能够使用系统来做些什么,这个层次的需求很重要
            细分 :
            1.基本型需求 : 产品功能必须满足的用户需求,例 : 社交产品的,音乐产品
            2.期望型需求 : 用户满意度随着此类需求的满足程度而先行提升或下降,当此类需求越得到满足则用户满意度越高,反之越低
            3.兴奋型需求 : 是一种完全出乎用户意料的属性或功能
            4.无差异需求 : 这类需求无论满足与否,用户满意度都不会受影响,用户对此因素并不在意
            5.反向型需求 : 用户没有此需求,提供后满意度适得其反,例:产品付费功能

        3.功能需求 : 怎么实现这些功能,开发人员需要实现什么

    3.获取步骤 :
        1.与干系人交流收集需求
        2.需求重要性排序
        3.选择需求 : 根据资源,约束,选择实现需求
        4.记录需求 : 编写文档

需求要素 :
    1.角色,场景
        1.执行的前置条件
        2.明确不同的场景
        3.每个场景的使用步骤
        4.业务规则和约束
    2.业务流程 :
        1.业务流程确认 : 一个流程为一个业务事件,一般是外部角色发起或系统内部主动发起(比如时间事件或状态事件),发起后会触发一些列业务活动
        2.角色及业务获取确认 : 每个角色对应多个业务活动,需求人员在确认业务活动是一定要保证活动的粒度,一个业务活动一定是由一个角色完成且每个业务活动都是有价值的
        3.业务活动间关系及数据确认 : 确定所有业务活动的前后关系,并明确流程间传递的数据实体
        4.流程整体瓶颈分析 : 一般若某个业务活动工作量较大,或流程涉及高级领导,一般会造成瓶颈,这种情况需求人员应想办法分散工作量提出流程优化建议
    3.数据实体 :
        针对流程类需求分析各业务活动传递的数据实体,统计分析类需求需要分析统计查询条件数据实体和展示数据实体,接口类需求需要分析接口传递数据实体
        1.明确数据实体 : 确认需求分析的所有数据实体,明确那些是系统原有的实体,那些是新增的实体,那些是改造的实体
        2.明确所有数据实体间的关系 : 实体间关系包含(一对一,一对多,多对多),另外需要分析数据实体变更是否需要保留版本,实体删除(逻辑删除,物理删除)是否影响其他数据实体
        3.明确数据实体的字段 : 针对新增数据或改造数据实体需要明确新增字段的名称,字段类型,是否必填,字段取值方式(人工输入,系统自动继承其它数据实体,,系统自动计算需要明确计算公式)
        4.数据权限分析 : 需要分析不同角色在数据权限方面的差异,若设计纵向多级用户,要说明对于集团/省/地市用户的数据隔离
    4.功能性需求 :
        1.功能列表 : 分析得出实现上诉业务活动对应的功能/接口列表,并明确新增功能,改造功能
        2.功能/接口关联影响分析 : 实现某个业务活动需要新增或改造的功能对其他关联功能/接口的影响分析
        3.系统交互原型分析 : 需求人员应遵循界面规范,并与研发沟通确定系统交互原型,帮助研发或用户更好的理解需求场景
            交互包含 :
                原型界面的名称,入口,原型间关联关系和使用角色
                页面内容,格式,排序方式
                操作要点 : 例 : 交互的信息提示,界面规则和约束
        4.算法分析 : 在系统功能交互时涉及比较复杂的算法,需要但大怒对算法进行分析
    5.非功能需求 :
        1.技术可行性 : 系统交互实现方式与研发确认是否可行,需求人员在与研发沟通过程中需要不断积累哪些功能实现在技术层面很难支撑
        2.时间可行性 : 根据用户的上线时间要求分析是否可满足要求
        3.合法合规可行性 : 分析用户需求是否满足国家法规或公司法规的要求
        4.数据安全性分析 : 用户需求是否满足信息系统安全要求