系统设计探索
最近在读了徐峰老师的《有效需求分析》和软考系统架构书籍和技术架构概述 - 企业架构设计方法与实践 (tonydeng.github.io)后，对怎样对一个需求做一个技术架构上的设计有了一个初步的理解，现在来总结一下。
技术架构也是我们常说的软件架构、系统架构，是将业务需求和应用功能转变为技术实现的过程。技术架构在软件开发过程中应用得比较普遍，受到广大技术人员的普遍关注，它是有关软件整体结构与组件的抽象描述，用于指导大型软件系统各个方面的设计。技术架构可以帮助我们梳理系统边界、识别系统需求、识别系统风险和问题优先级、确定技术方案和路线，让团队之间达成共识且相互约束，并指引团队适应业务和技术的变化。
在企业架构中，技术架构是支撑整个企业架构体系的技术部分，也是企业架构中IT架构的最后架构阶段。技术架构以业务架构中的业务需求、业务能力、业务流程为指导，是从应用架构和数据架构的具体形态导出的对企业数字化系统和IT基础设施进行整体部署的一组技术标准规范、原则和最佳实践，并包含相关的技术选择标准、产品选择方案、技术实施路线等，目标是优化整个企业的IT运行环境，实现IT对业务服务高效率地交付。
从广义上来讲，技术架构涉及技术研发的方方面面，包括业务、数据、应用对应的软硬件能力，比如IT基础设施、中间件、网络、通信等。同时，技术架构从技术上指导应用系统的开发、部署、测试、交付、运维等，提出公共性、支撑性的指导，推进资源共享和系统协同，发挥现有资源和基础设施的效用，提升业务系统的互操作性。技术架构解决的问题包括技术分层、技术框架选择、开发语言选择、非功能性需求实现等。
技术架构的主要是要完成如下工作：
- 理解对齐，形成共识：软件系统是为了实现用户需求，特别是针对企业架构，不同的人有不同的视角，技术架构需要将业务架构、应用架构、数据架构的需求转换成技术人员可以理解的技术语言。需求的实现往往可以有多种途径，如何选择途径？如何拆分系统？选择技术A还是技术B？这些都需要通过技术架构描述并记录下来，让大家理解对齐，形成共识。
- 标准规范，术语统一：软件开发的不确定因素很多，特别是大型企业的技术落地过程，往往有多种技术规范和标准，包括行业通用的和企业内部的，如开发规范、部署规范、稳定性保障规范等。同时，在技术层面有很多术语，不同的人有不同的理解，技术架构需要定义和解释清楚系统中涉及的关键概念，特别是非功能特性的选择和技术方案，并在整个架构设计和描述过程中使用标准和一致的术语。
- 言之有物，资产沉淀：如同讨论产品交互时对照产品原型图，讨论代码Review时需要看代码一样，技术架构也有相应的实物，即架构制图（简称架构图）。架构图是软件开发的高层次抽象，是架构持续演进的具体承载，也是技术团队的核心资产，对系统开发、新人培养等具有重要的作用，是技术团队的灵魂所在。
- 团队协同，明确分工：技术架构提供企业更有效地管理研发的流程，方便团队协同，比如通过构建企业开发平台、运维平台来协助系统的统一管理，进而结合上层应用架构、数据架构的落地，通过新技术（如云原生技术、容器化技术、敏捷交付、精益管理等软件工程管理技术）构建开发和运维一体化的平台，清楚地定义各团队的分工边界，确保业务需求和应用功能的稳定落地。
一、系统总体架构设计
那首先我们要来分析一个业务需求一般至少要做好三方面的设计：
1、业务流程设计后落地到技术上的应用架构设计；
2、技术架构设计；
3、部署架构设计；
（一）系统总体逻辑架构
其中，应用架构设计主要以图形和文字的方式来描述系统总体的架构；应该与详细设计保持一致。重点说明待建或待升级系统的位置、内部子系统划分、关联系统的交互关系以及系统使用的用户等，并梳理关联系统是否需要改造。
| 周边系统名称 |
系统定位描述 |
系统状态 |
是否需要配套改造如需配套改造，应说明改造内容。 |
（二）系统总体技术架构
如下，主要是描述清楚在系统在技术上的架构映射和依赖的一些组件部署情况。
可以看到系统从上到下分成五层设计，分别是接入层、展示层、网关层，服务层、基础服务层。其中服务层中的业务服务层是我们在业务需求分析中最重点关注的部分，我们至少要满足：
1、支持可扩展可演进的设计；
2、 使用业务对象建立业务模型；
3、 建立完善的数据模型，并识别出需要的业务组件和规则；
4、 架构设计需要考虑建立完整的业务领域模型；
5、 详细设计阶段按业务规则组件和业务流程组件的分层思想进行设计；
（三）系统总体物理架构
（四）和关联系统的关系中要写明如下几点
系统名称、交互原因和逻辑、连接方式、交互接口规范
二、系统应用功能架构设计
（一） 系统应用功能架构图
（二）子系统说明
概述系统划分为几个子系统，下面对每个子系统进行说明。
1. 划分思路
编写说明：介绍子系统划分的思路，一般从业务处理特征、技术实现角度以及可靠性保障、高性能要求等方面综合考虑；常规的子系统划分大致包括WEB管理子系统、联机交易子系统、日终批量子系统、文件传输子系统等。
划分思路示例：
1.1从业务处理特征角度
通过对需求的分析，在系统设计中，应将联机交易和批量处理交易分开，设计独立的子系统。因此，系统设计时，将这些业务按照业务特性和处理特征分离开，放到不同的子系统中实现，一方面通过充分利用各子系统的主机总体处理能力达到最终提升处理性能的目的，另一方面也有利于部署、管理和维护。此外，无论是系统的联机交易与批量交易，均包含公共的、统一的公共处理模块，此类公共功能应由统一的子系统进行接入、处理和转发，以使系统间关系简化、灵活。
1.2从技术实现角度
各个子系统间的处理流程调度、数据传输较多，如果采用点对点通讯的模式，将使系统间关系过于复杂，因此将设计批量管理子系统、数据传输子系统类似mq等“总线”类技术功能子系统，用于统一管理相关流程、数据，简化系统拓扑结构。
根据上述主要思路，从部署角度，从前之后，我们分为三层：Web服务子系统、公共管理模块、后台各业务子系统。
根据处理特征，又进一步将后台的各业务子系统划分联机业务类子系统和批量业务类子系统
2.子系统功能说明
描述各子系统的总体功能说明,例如：
Ø Web子系统
它主要是通过前端界面展示，以及用户请求的控制功能。实现客户管理、客户经理管理、营销管理、等业务功能。
Ø 应用子系统
是基于构件化平台，实现具体业务逻辑功能。构件化平台，是本系统的开发平台，是构建其它平台和应用的基础，平台中提供了一些，与业务无关的，通用基础服务或组件，以及一些公用业务模块或组件的集成。
Ø 数据处理子系统
主要是对从数据共享系统接收的数据接口文件，进行数据处理、任务调度管理，和监控管理。
Ø 报表子系统
实现本系统中所有报表数据的生成、统计、分析和展示。监控子系统实现数据处理监控、运行监控、应用进程、系统配置、日志、应用服务器监控等。
Ø 监控子系统
主要实现数据处理监控、运行监控、应用进程监控、配置监控、日志监控、应用服务器监控以及预警提示等。
Ø 前置子系统
通过接口报文、通讯管理、接口与服务的调度，实现与内部系统自身的内部数据访问的通讯接口。
三、模块功能设计
具有功能独立、能被调用的信息单元叫模块。模块功能分配的目的，就是为了将具有相同功能的模块合并，从中提取公用模块，形成公用部件，从而优化系统设计，加快开发速度，提高开发质量。
（一）专用模块功能划分
系统内的特定功能模块，仅在系统内部独立使用。
| 模块编号 |
模块名称 |
模块详细功能分配 |
模块的接口标准 |
（二）公用模块功能划分
系统内公共的功能模块，可以在系统内部共享使用。
| 模块编号 |
模块名称 |
模块详细功能分配 |
模块的接口标准 |
（三）模块的关系
主要要清晰画出系统内各模块之间的关联关系，然后用文字补充阐述模块的功能和它们之间的相互关联关系，例如：
（四）模块设计
1 模块名称
模块概述
1.1 模块设计
类图
四、核心流程设计
(一) 核心处理流程
1. Xx处理
对在本系统内流转的重要的、典型的处理流程进行详细描述，包括覆盖功能、适用范围、流程图（或泳道图）等内容，并针对流程图中的处理步骤进行文字说明。
2.跨系统核心处理流程
对在多个系统间流转的重要的、典型的跨系统处理流程进行详细描述，包括覆盖功能、适用范围、流程图（或泳道图）等内容，并针对流程图中的处理步骤进行文字说明。
五、关键技术设计
针对流程中的关键点、子系统功能模块中的关键功能，进行技术关键点的阐述和相应技术的分析。
（一）xx设计
1.总体分析
2.异常处理机制
六、接口设计
接口设计主要是描述本系统与外系统之间的数据、文件等交互方式，一般分为本系统作为客户端请求外部的服务接口说明和本系统作为服务端向外系统提供服务接口说明；
（一）交易接口列表
整理本系统涉及到的
| 序号 |
唯一标识 |
业务名称 |
发起方 |
接收方 |
通讯方式 |
报文格式 |
（二）XXX接口设计说明
编写说明：本节内容要求设计者站在本系统向外部系统发送处理请求，且外部系统进行相应功能处理的角度，按关联系统的相关交互功能接口进行描述。
1.服务方设计说明
2.请求方设计说明
七、差错处理设计
本系统在设计过程中需要考虑各种场景的异常处理，包括错误处理前后端通讯异常、系统内部异常处理、系统间异常处理等，并对各种异常情况分场景设计出可以解决问题的处理方法和流程，保证在系统实际运行过程中，能有效满足处理的正确性、高效性、安全性等性能要求。
（一） 前端异常
对错误进行统一编码，通过错误码对应到错误的中文描述，错误编码和中文含义保存在标准数据中。
1. 出错输出信息
2. 出错应对策略
(二) 系统内异常
对系统内的异常，按通讯异常、业务处理流程异常、运行期间系统异常、数据库处理异常等方向或场景分别进行描述。
1. 通讯异常
2. 业务处理流程异常
3. 运行期间系统异常
4. 数据库处理异常
（三）系统间异常
（四）异常输出信息
列出每种可能出现的错误或故障出现时，系统输出信息的形式、含义。
1. 操作界面容错
2. 后台处理容错
3. 批处理过程容错
八、非功能设计
编写说明：系统的关键非功能需求的方案设计，包括性能需求、质量需求、运维需求、安全性需求等。
（一）性能需求设计
根据业务需求提供的业务量要求进行分析，为系统容量和处理能力设计提供数据支持。
一般考虑：
1) 业务量预估
2) 根据业务量预估，提出对各项重要性能指标的要求
Ø 系统吞吐量
系统的TPS（每秒交易数）值要求为日峰值交易量的80％发生在当天的峰值处理时间（约2小时）之内。
Ø 联机交易响应时间
Ø 批量处理时间
Ø 用户操作响应时间
（二）质量需求设计
1. 可用性
Ø 负载均衡
Ø 健壮性
Ø 系统可用性
Ø 热备切换和备份冗余需求
Ø 网络和渠道切换
Ø 偶然故障率
Ø 平均无故障时间
Ø 代码缺陷密度
Ø 恢复时间目标(RTO)和恢复点目标(RPO)
Ø 平均失效恢复时间
2. 完整性
Ø 交易完整性
Ø 数据完整性
Ø 接口交互完整性
Ø 文件传输的完整性
Ø 日志和消息队列的完整性
3. 兼容性
Ø 系统兼容性
Ø 新增子系统
为未来的新产品新技术预留接口，以便平滑的升级换代，充分的利用原有资源。
Ø 新增外系统
系统应遵循开放标准，通过标准的架构和协议，来设计整个系统，应用开放式接口兼容不同关联的应用系统。
Ø 软硬件
客户端应能在主流的浏览器（包括IE 和 FIREFOX等）、台式机硬件平台、操作系统上兼容运行。
Ø 安全管理软件兼容
应用系统与生产环境要求安装的其他软件兼容。
4. 可维护性
5. 可扩充性
系统建设时应在硬件的配置和软件的设计上具有可扩展性，能为今后的相关业务预留接口并提供扩展基础。
(三)运维需求设计
1.监控
建立配套的软件监控系统，实时监控各系统软硬件运行状况，并且提供迅速、准确、可靠的故障报警功能，以便相关人员及时发现问题，准确定位问题，快速解决问题,可以大幅度提高系统的整体安全性，及早发现、排除安全隐患。
监控软件应包括三大功能： 系统参数设置功能、监控报警功能 、统计分析功能
（四）数据架构设计
1. 数据逻辑架构
阐述清楚本系统内部不同数据的分布情况，外部数据进入本系统的流转处理过程、本系统内部数据的流转处理过程；分析清楚各种数据之间的交互关系和最终落地时的方式。
2. 系统间数据关系及交换过程
描述系统间数据交互的详细过程或者相关模块组件的处理机制。
3. 数据存储架构设计
对本系统数据从数据存储方式、数据库存储方式、数据保存期限等角度进行分析，从而规划出本系统数据存储架构设计。
4. 数据交换架构设计
分析本系统和外部系统之间、本系统内部各子系统（各模块）之间交换的方式。
5. 数据访问架构设计
分析本系统和外部系统之间、本系统内部各子系统（各模块）之间数据访问的方式。
6. 故障处理
(五)灾备设计
描述系统灾备建设模式，介绍灾备建设技术实现流程，包括数据同步机制如何保证等。
九、数据库设计
（一）数据库总体设计
1. 设计思路
1.1 数据访问设计
从数据库的访问性能考虑。对记录少、数据相对稳定、查询频繁的库表（如各种配置表），应将该表缓存到内存中，以减少物理读写次数，提高数据访问性能。同时可以对数据采用方式存储，进一步提高缓存数据访问性能。可以采用现有的开源技术比如redis缓存等。
从降低数据库的访问负载以及高可用性考虑，数据库的部署设计还有以下一些方法：
1. 水平切分数据库：可以降低单台机器的负载，同时最大限度的降低了宕机造成的损失；
2. 负载均衡策略：可以降低单台机器的访问负载，降低宕机的可能性；
3. 集群方案：解决了数据库宕机带来的单点数据库不能访问的问题；
4. 读写分离策略：最大限度了提高了应用中读取数据的速度和并发量。
我们要结合自己项目的实际情况描述内存表、静态数据表、动态数据表以及以及读写分离数据表的范围。
1.2 分库及分表设计
分表可以减少单表的记录条数，减少数据查询所需要的时间，提高了数据操作的效率。分库可以分散高并发访问时数据库的访问压力，降低了单点数据库的负载。
分库分表首先要确定根据哪个字段、或者哪几个字段进行路由，一般的原则是按使用频率最高维度的字段去分库分表，尽量保证高使用维度下只查询单表。
分库分表的主要策略包括：分区、取模、数据路由表等。
Ÿ 分区：根据某一字段的取值区间拆分到多个表或多个库。
Ÿ 取模：根据某一字段对一常量进行取模将数据拆分到多个库中。
Ÿ 数据路由表：数据路由表存储了某字段与数据库节点的映射关系。
项目组根据项目的实际情况描述分库分表的设计方案。
1.3 分区设计
表分区是将一张大数据量表中的数据按照不同的分区策略分配到不同的系统分区、硬盘或是不同的服务器设备上，实现数据的均衡分配，这样做的好处是均衡大数据量数据到不同的存储介子中，这样每个分区均摊了一部分数据，然后可以定位到指定的分区中，对数据表进行需求操作；表的对数据的管理，如清理历史数据等也有帮助。
分区和分表的区别：分区和分表针对的都是数据表，而分表是真正的生成数据表，是将一张大数据量的表分成多个小表实现数据均衡；分区并不是生成新的数据表，而是将表的数据均衡分摊到不同的硬盘，系统或是不同服务器存储介子中，实际上还是一张表。另外，分区和分表都可以做到将表的数据均衡到不同的地方，提高数据检索的效率，降低数据库的频繁IO压力值，分区的优点如下：
l 相对于单个文件系统或是硬盘，分区可以存储更多的数据；
l 数据管理比较方便，比如要清理或废弃某年的数据，就可以直接删除该日期的分区数据即可；
l 精准定位分区查询数据，不需要全表扫描查询，大大提高数据检索效率；
l 可跨多个分区磁盘查询，来提高查询的吞吐量；
l 在涉及聚合函数查询时，可以很容易进行数据的合并；
表分区的注意事项：
Ÿ 在对数据表分区时，不能只对数据进行分区，需要连同其对应的索引等属性一同分区动作，某种程度上可以保持数据属性的完整。
Ÿ 对表进行分区之后，如果某个分区中的数据量依然很大或是增长迅速，那么你同样可以再进行子分区操作，将该数据再分区到其它分区中。另外，如果在一个分区中使用了子分区，那么其它的子分区也必须定义。
示例：
对表进行分区，不影响表在数据对象层面逻辑关系，对应用程序看仍然是一张完整的表，但在物理存储上，DBMS将表中的数据在物理上存放到多个表空间(物理文件上)，在数据访问，包括查询和更新等处理时，可以根据相关逻辑关系访问部分物理表空间或者使用并行技术同时访问多个表空间，从而提高数据处理的性能。
表分区的目标
l 提高访问表的性能
通过Partition Key，可使查询的数据定位在一个或少量的分区中；这需要考虑最常用的查询条件。注意在考虑提高查询效率这个因素的同时，还应兼顾数据维护管理的因素，尽可能地避免相互间地冲突。
l 增强表的管理和维护性
通过Partition Key，可以使数据维护基于分区进行，如Drop或Truncate一个或多个分区。通过Partition Key可控制只读的数据存储在相应的分区中，且这些分区存储在只读的表空间里，这将提高数据备份的性能。这类Partition Key通常与时间相关。
表分区基本原则
分区表使用的基本原则：
l 依据数据模型的大小进行分区设计
对于大表进行分区，将有益于大表操作的性能和大表的数据维护。通常当表的大小超过2GB，或对于OLTP系统，表的记录超过2000万，可考虑对表进行分区。
l 依据应用处理功能需求进行分区设计
充分分析业务需求中的处理功能，充分利用数据库的“分区筛除”功能，提高数据操作效率。
l 依据提高并行处理性能进行分区
例如：并行数据操作（Parallel DML），对于经常执行并行操作，例如并行插入（Parallel Insert）或者并行修改（,Parallel Update）的表应考虑进行分区设计，提高并行数据处理的效率。
l 依据数据访问特性进行分区设计
基于表的大部分查询应用，只访问表中少量的数据。对于这样表进行分区，可充分利用分区排除无关数据查询的特性。
l 依据数据维护可行性、方便性需求进行分区设计
某些表的数据维护，经常按时间段删除成批的数据，例如按月删除历史数据。对于这样的表需要考虑进行分区，以满足维护的需要。因为删除（Delete）大量的数据，对系统开销很大，有时甚至是不可接受的。
1.4 历史数据转存与清理
一般在大型应用系统中，对业务数据增长快，数据量特别大的数据表，应通过对数据和业务的分析，确定该类数据的常用周期和保留周期。常用周期是指数据在联机交易中会经常使用的日期间隔，保留周期是指联机交易的数据根据业务规定所要保存的最长日期间隔。历史数据指超过常用周期而未到保留周期的数据。
由于系统的业务特点，各种业务数据，特别是流水号表的增长量非常大。对于数据库中数据量增长很快的各种业务数据表，例如流水表，需要考虑数据的联机访问效率和数据存储时间，将超出数据常用周期的历史数据进行转移存储，超出数据保留周期的数据进行归档后删除。
1.5 系统数据分布设计
整体数据的设计一般遵循如下原则：
主要的数据访问请求集中在子系统内部，主要业务数据按子系统分库；
对于访问频繁的跨系统数据，通过数据同步的方式从源数据子系统发布到目标子系统，各子系统直接访问副本；
对于访问较少的跨系统数据，通过提供服务的方式完成数据访问。
2. 关键数据模型分析
2.1 关键数据模型确定
在系统的数据库设计中，应重点考虑关键数据模型的设计，从以下几个方面确定关键数据模型的范围：
数据量巨大的数据对象；
业务处理需要频繁访问的数据对象；
系统业务功能、业务处理逻辑；
2.2 关键数据模型设计要点
关键数据模型设计遵循如下要求：
充分考虑处理准实时处理的特点；
充分考虑联机交易的特点；
充分考虑按子系统进行分库设计；
考虑数据库设计要求，包括集群环境设计、分区、分表、索引等；
充分考虑大数据量操作，例如避免大批量的select、delete操作；
充分考虑日终备份及清理策略。
2.3 关键数据模型设计
3. 表空间设计
表空间的设计应遵循以下两点。
1. 空间规划时要考虑将读写操作并发关联度大的表分开存放；将数据库系统I/O容易冲突的文件分开存放到不同的物理设备等。
2. 在不同的磁盘驱动器上存储不同表空间的数据文件，以减少I/O竞争;比如数据表空间和索引表空间分开存放，系统表空间和应用表空间分开存放；数据文件和日志文件分别存放在不同的磁盘上。
(二) 数据迁移设计
1. 数据迁移范围
业务切换时迁移数据分为：本系统数据、关联系统数据和委托单位系统数据三部分；
2. 数据迁移
2.1 本系统数据迁移
本系统数据迁移流程:数据抽取、数据加工、数据导入、数据核对
以上是现在对软件设计的大致理解，关于软考中提到的安全设计，现在还在理解当中，等再熟悉一些再来梳理添加。