基于spring cloud alibaba系统设计说明书

 说明：

1.因为是从word 复制过来的，很多图片没有复制过来。另外，作图工具是通过processon来做的，需要修改有原型。

2.通过此文档膜拜，质需要些下你系统具体的业务说明（菜单功能简单阐述），半天就能写完一份文档

3.如何修改说明：

  1. 某某系统平台，修改为当前系统，全局替换
  2. 搜索“需要修改”，查看需要修改的地方。
  3. 红色字体内容做为参看，基本也是需要修改
  4. 搜索“某某公司”，查看位置，需要修改
  5. 重新更新目录

 

 

 

 

 

 

 

某某系统平台

系

统

架

构

设

计

说

明

书

                                                                                                   某某公司

2020年6月1日

 

如何修改说明：

  1. 某某系统平台，修改为当前系统，全局替换
  2. 搜索“需要修改”，查看需要修改的地方。
  3. 红色字体内容做为参看，基本也是需要修改
  4. 搜索“某某公司”，查看位置，需要修改
  5. 重新更新目录

目录

1 综述6

1.1 编制目的 6

1.2 适用范围 6

1.3 参考依据 6

1.4 约束定义 7

1.4.1 文字符号约束7

1.4.2 图元约束7

1.4.3 格式约束8

1.4.4 层次定义9

1.5 导读说明 9

2 系统架构规划11

2.1 工作背景 11

2.2 设计原则 15

2.3 系统架构总览 17

2.3.1 应用架构设计17

2.3.2 数据架构设计18

2.3.3 技术架构设计19

3 应用架构26

3.1 应用模块 26

3.2 运维管理平台 27

3.2.1 模型管理27

3.2.2 隐蔽工程28

3.2.3 新线筹备与验交查验28

3.2.4 资产与设备管理29

3.2.5 质量管理29

3.2.6 应急模拟30

3.2.7 能耗管理30

3.2.8 成本管理31

3.2.9 知识库管理31

3.3 后台管理系统 32

3.3.1 系统管理32

3.3.2 权限管理37

3.3.3 资源管理40

3.3.4 系统监控41

4 逻辑架构视图46

4.1 某某系统平台后台架构图 46

4.2.1展现层46

4.2.2通讯层47

4.2.3 业务层47

4.2 数据库层 52

4.2.1 基于mysql的数据库备份和恢复方案52

4.3 服务相关 54

4.4.1、认证系统54

4.4.2日志系统57

4.4.3回话治理58

4.4.4DNS劫持处理58

4.4 组件视图 59

4.4.1 组件功能59

5 开发架构视图61

5.1 项目工程划分 61

5.2 关键代码展示 64

5.2.1 注册登录64

5.2.2 访问授权70

5.2.3 REST风格接口71

6 开发技术使用规则75

6.1 设计及编码规范 75

6.1.1 编码规则75

6.1.2 数据库设计规范75

6.1.3 异常处理规则76

7 部署架构视图77

7.1 部署图 77

7.1.1 网络拓扑图77

7.1.2 请求流程图77

7.2 日志文件约定 77

8 项目本期的安全系统设计79

8.1 需求分析 79

8.2 信息安全设计原则 79

8.2.1 整体安全原则（木桶原理）79

8.2.2 积极防御原则80

8.2.3 多重保护原则80

8.2.4 一致性原则80

8.2.5 易操作性原则80

8.2.6 可扩展性原则81

8.2.7 标准化原则81

8.3 信息安全总体设计 81

8.4 信息系统分层安全方案 82

8.4.1 物理层安全方案82

8.4.2 网络层安全方案82

8.4.3 信息安全评估83

8.4.4 系统层安全方案83

8.4.5 应用层安全84

8.4.6 数据层方案85

 

 

1 综述

1.1 编制目的

依据《国家中长期科学和技术发展规划纲要（2006－2020年）》和《国务院关于深化中央财政科技计划（专项、基金等）管理改革的方案》，在国家重点领域技术预测、交通领域技术预测、关键技术遴选工作成果以及面向相关部门、地方和机构广泛征集国家重点研发计划科技创新需求建议的基础上，科技部会同国家铁路局、交通运输部、教育部、中国科学院等部门，组织专家编制了《国家重点研发计划先进轨道交通重点专项实施方案》，在此基础上启动先进轨道交通重点专项，并发布指南。通过对需求进行结构化分析，界定广州地铁集团建立某某系统平台的需求范围和相关约束条件，为某某系统平台设计中的架构设计、详细设计、相关技术规范以及编码实现工作提供指导，也为下一阶段某某系统平台建设中的系统测试、验收等工作提供参考依据。

1.2 适用范围

本文档适用于某某公司某某系统平台中系统详细设计阶段，以及后期知识管理试点建设、实施推广、深化建设、应用提升等各阶段工作。

1.3 约束定义

1.3.1 文字符号约束

1.3.2 图元约束

（1） 流程图图元约束：

图形符号

名   称

定    义
 

开始框

标准流程的开始，每一流程图只有一个起点
 

结束框

流程的中断和结束
 

处理框

表示对事件或结果的处理过程
 

决策或判断

用来根据给定的条件是否满足决定执行两条路径中的某一路径

 

流程线

箭头的方向表示流程执行的方向与顺序，两个符号间不得使用双箭头
 

连接标识

用于同一流程图中页和页的连续或者用于同页内从一个动作框转到另一个动作框
 

流程标识

表示在流程图中引用另一个流程

 

（2） 流程图展示方式约束：

流程图推荐采用纵向页面布置、横向职能带布置的样式，另根据需要可增加划分业务流程阶段，但不得改变流程图基本样式。

流程图中所用符号应均匀分布，连线保持合理的长度，并尽量少用长线。

使用各种符号应注意符号的外形和各符号大小的统一，避免使符号变形或各符号大小比例不一。

符号内的说明文字尽可能简明。通常按从左向右和从上向下方式书写，并与流向无关。

尽量避免流线的交叉，即使出现流线的交叉，交叉的流线之间也没有任何逻辑关系，并不对流向产生任何影响。

一个大的流程可以由几个小的流程组成。单个流程过于复杂时，在不影响业务的完整性和连续性的前提下，应拆分为两个及以上子流程。

所附表单能体现流程要求时，则可简化流程图，尽量将表单能体现的流程要求合并为一个流程节点。

1.3.3 格式约束

文档模板：文档编制必须严格依据本文档模板的格式要求。

（1） 引用描述格式

l 《<资料名称>》<发布单位><发布日期>

l 《<资料名称>》(<文号>)

l 《<资料名称>》(<标准号>)

（2） 文字格式

l Word样式，正文首行缩进

l 首行缩进2字符，宋体，小四，1.5倍行距，段前 0，段后 0。

（3） 表格格式

l 列标题，Word样式，表格标题

l 列标题，首行缩进 无，居中，宋体，五号，单倍行距，段前 0，段后 0。

l 列标题，重复标题行

l 表格正文，Word样式，表格正文 居左

l 表格正文，首行缩进 无，居左，宋体，五号，单倍行距，段前 0，段后 0。

l 表格正文中的序号，Word样式，表格正文 居中

l 表格正文中的序号，首行缩进 无，居中，宋体，五号，单倍行距，段前 0，段后 0。

（4） 图格式

l Word样式，图居中

1.3.4 层次定义

业务域划分及其编码：

● 战略管理 SM；

● 营销服务 BM；

● 安全生产 SP；

● 规划建设 PP；

● 人力资源 HR；

● 财务管理 FI；

● 物资管理 MM；

● 信息管理 IM；

● 综合管理 GM；

1.4 导读说明

编号

如果您是：

请关注以下部分：

1

领导层

第一、二章

2

公司业务人员

第一、二章

3

公司信息人员

第一、二、三章

4

项目建设人员

第二、三、四、五、六、七、八章

5

评审人员

第一、二、三、四、五、六、七、八章

2 系统架构规划

2.1 工作背景

作为最具可持续性的交通运输模式，轨道交通是国民经济大动脉、大众化交通工具和现代城市运行的骨架，是国家关键基础设施和重要的基础产业，对我国经济社会发展、民生改善和国家安全起着不可替代的全局性支撑作用。

轨道交通科技持续自主创新更是国家通过实施“创新驱动发展”战略，全面支撑“新型城镇化”、“区域经济一体化”、“一带一路”、“制造强国”和“走出去”战略的全局性重要基础保障；对建设创新型国家、构建现代综合交通运输体系、在经济社会发展新常态下，实现全面建成小康社会目标，具有重大意义。

依据《国家中长期科学和技术发展规划纲要（2006－2020年）》和《国务院关于深化中央财政科技计划（专项、基金等）管理改革的方案》，在国家重点领域技术预测、交通领域技术预测、关键技术遴选工作成果以及面向相关部门、地方和机构广泛征集国家重点研发计划科技创新需求建议的基础上，科技部会同国家铁路局、交通运输部、教育部、中国科学院等部门，组织专家编制了《国家重点研发计划先进轨道交通重点专项实施方案》，在此基础上启动先进轨道交通重点专项，并发布指南。

专项的指导思想是：以满足国家战略需求为目标，以国内外市场需求为导向，在既有轨道交通科技发展成果的基础上，以“产学研用”协同创新为主要模式，强化国际合作创新，通过在轨道交通系统安全保障、综合效能提升、可持续性和互操作等战略技术方向进

 

2.2 设计原则

某某系统平台的设计，遵循“十三五”信息化规划的总体要求，基于前期业务模型构建成果，以切实发挥本阶段承上启下的作用为目标，贯穿整个设计研发过程。以下是一些主要的设计原则和规范。

开放性原则

某某系统平台的可扩展性：系统的设计在软件上充分考虑系统的可扩展性，采用模块化设计，以便于随着系统服务项目的增多和业务量的增加平滑地进行系统的扩充。

系统的可管理性：对系统运行的监测、控制和管理功能，从而保证系统的正常运行。

良好的系统接口：某某系统平台作为公司的重要数据中心和信息平台，要求它与其他现有的各种信息系统相连，以实现资源共享，为业务层、管理层和决策层提供一个信息化工作环境。系统的开放性原则是实现系统互连的基础，它使系统具备良好的扩展和互操作能力，以便于系统的维护和管理。

标准化原则

某某系统平台基于信息技术和现代网络技术的标准化趋势有三个方面：

n 业务流程标准化；

n 信息流标准化；

n 数据格式标准化。

某某系统平台的标准化，成为了其他系统的连接的枢纽，有助于信息的标准化；信息流标准化的重点是企业各类信息的编码、管理信息、经营数据和技术数据标准化问题；数据格式标准化主要是为了解决数据的互联与互通。实现数据交换和信息的共享，利用先进的信息化管理技术手段实现标准统一，标准要适当超前的目标。

容错性原则

提供有效的故障诊断及维护工具，具备数据错误记录和错误预警能力；具备较高的容错能力，在出错时具备自动恢复功能。

安全性原则

用户认证、授权和访问控制，支持数据库存储加密，数据交换的信息包加密，数据传输通道加密，采用密级强度可自定义的标准型加密算法。发生安全事件时，能以事件触发的方式通知系统管理员处理。

可靠性原则

应能够连续7×24小时不间断工作，平均无故障时间达到99.99％以上，出现故障应能及时告警，软件系统应具备自动或手动恢复措施，自动恢复时间<60分钟，手工恢复时间<24小时，以便在发生错误时能够快速地恢复正常运行。软件系统要防止消耗过多的系统资源从而避免系统崩溃。

兼容性原则

满足向下兼容的要求，软件版本易于升级，任何一个模块的维护和更新以及新模块的追加都不应影响其他模块，且在升级的过程中不影响系统的性能与运行。

易用性原则

应具有良好的简体中文操作界面、详细的帮助信息，系统参数的维护与管理通过操作界面完成；系统的建设应最大限度利用现有的设备和数据资源，保护现有的软、硬件资源。

 

2.3 系统架构总览

2.3.1 应用架构设计

某某系统平台的应用架构如下：

 

流程需要需要修改

实现整个面向全生命周期成本优化的轨道交通设计、建设、运营协同技术之某某系统平台的“集约建设、规范管理、数据共享、互通协同”，是希望通过为太和站及夏太、太竹区间的运维管理提供一套更智慧、更有效、多维度的、基于BIM的数字孪生某某系统平台，将机电管理、信息管理、能源管理、安全管理、质量管理、智能系统管理及各业务等多种类的子模块进行一体化整合，使多个系统在同一子平台进行可视化呈现以及协同。同时新增人流密度统计、区域关注、温度统计、流程审批、节能减排等功能，对站台门、道岔、低损耗变压器、紧急疏散等典型专业的全生命周期成本优化关键技术进行数据验证与设计、建设反馈协同。

 

2.3.2 数据架构设计

某某系统平台的数据来源于外部系统和基于系统的自产生（隐形知识显性化）

  • 外部系统来源：

 

  • 隐性知识显性化：

隐性知识存在于员工的头脑中，如工作经验、操作技巧和方法，心得体会等，难以表达和系统化；同时隐性知识也是企业知识管理中的重点和难点。

2.3.3 技术架构设计

技术架构自下而上分为六层，分别是基础设施层、数据层、支撑层、服务层、应用层和展示层。

流程需要修改

 

  • 基础设施层：主要是系统层，包括硬件设备和系统软件，硬件设备主要是为应用系统提供硬件支撑。采用质量可靠、性能优越、容量满足未来业务发展的服务器，包括应用服务器和数据库服务器。在硬件设备层采用集群实现，保障系统的可用性。 系统软件主要是成熟的操作系统、中间件、数据库软件等，用于构建系统的应用支撑环境。
  • 数据层：数据层为应用系统提供数据服务，通过构建统一的数据中心体系，实现数据资源的充分有效管理和利用。数据类型主要结构化数据、非结构化数据和索引数据。根据不同的数据周期，制定各自的归档策略，并且采用适度的常规备份和事件触发的备份策略，建议每周进行一次全备份，每天进行增量归档备份。此外，在进行大数据量的数据导入之后，例如进行完大量知识业务数据的维护之后，在从外部系统导入完历史数据之后，都要进行一次完整的数据库备份，以保证在发生意外时，拥有基本实时的数据。
  • 支撑层：支撑层是应用系统的基础服务层，在这一层中提供通用的服务和组件，主要是J2EE容器、工作流引擎、内容引擎和搜索引擎。

² J2EE容器：提供Web应用程序的配置、管理和发布。包括Web服务器端容器Applet客户端容器（包含组件为Applet，Applet是嵌在浏览器中的一种轻量级客户端；应用客户端容器（包含的组件为Application Client。能够使用J2EE的大多数Service和API）。

² 工作流引擎：提供工作流服务，通过工作流引擎灵活实现各业务流程的角色分配和任务走向。

² 日志引擎：对不同系统进行日志统一搜集展示处理等。

² 搜索引擎：提供基于索引数据的搜索服务，包括关键字查询、布尔条件查询等。

  • 服务层：服务层提供基于SOA的服务，分为WebService、FTPService和MQ等。应用层：公共服务。
  • 展示层：展示层是整个系统的统一访问入口和集成前端展现，提供与各类最终用户进行交互的多种界面。提供统一的访问授权、个性化控制、内容共享、发布和订阅以及面向主题的展现集成。支持不同形式的展示终端，包括浏览器、客户端和PDA/手机。

2.3.3.1 系统可用性

项目中各地铁运营保障子系统实行独立运行、分散监控，各子系统与子平台保持及时、可靠地数据交换与指令沟通。

各子系统之间的操控相对独立，可通过集成系统的高级控制逻辑和业务逻辑实现联动控制和业务关联，但每个子系统的故障均不会影响其它子系统的正常工作。

子系统之间的数据共享通过统一数据库与协议转换器完成，最大限度地减少数据流通的中间环节，以分离故障、分散风险、便于管理。

子平台支持7×24小时稳定运行。子平台的用户总人数可大于2000，并发请求考虑按3000用户并发访问设计，考虑满足不同地域、多办公地点的远程访问。服务器并发性能要求在理想的硬件及网络环境条件下，同时3000并发系统可正常运行。

子平台把各种子系统集成为一个有机的统一整体，实现如下功能集成：

1>对地铁运维保障子系统信息进行表达。

2>对地铁运维保障子系统进行集中监视和控制。

3>对全局事件进行管理。

4>以相同、相似的业务逻辑对各子系统的信息和业务进行统一管理。

5>以跨系统联动控制策略实现子系统间的信息关联、联动控制。

服务器数据性能：95%以上的数据在5s内完成数据查询。一般页面响应时间不大于3秒，全系统全文检索的响应时间不大于9秒，非全文检索方式的查询响应时间不大于5秒。

任何子系统的三维模型图形加载要求在规定时间内完成。无论任何场景，事件均要求在10秒内报出报警视频信息和三维场景。提示在报警时3秒内发出。

子平台运行帧率：1G显存保证95%的视角在25-50帧，2G显存可保证95%的视角在50-75帧，4G显存及以上可保证95%的视角在100帧以上。

任何一个3D场景在调出时，画面三角形片数不超过100万个。单个场景中可支持不少于4000个三维模型。

 

2.3.3.2 系统易用性设计

某某系统平台主用户界面主要采用基于浏览器实现和unity客户端的实现，支持主流的浏览器（谷歌、火狐、IE）和不同类型的显示终端，所有能够熟练使用浏览器的用户都能够方便容易地使用。Unity客户端能够通过不同的打包方式运行在windows和ios系统上。同时在设计用户界面时我们采用快速原型的开发理论，让用户在系统实施的早期就从用户界面的角度提出修改意见，从而保证最终交付的系统具有良好简单的用户界面，方便各类用户使用。

2.3.3.3 系统升级和扩展性设计

某某系统平台采用前后端分离的模式进行开发，前端采用浏览器和unity进行开发。浏览器端主要是基础服务器和系统的统一的管理功能，unity上承载的主要是地铁三维模型的实际运用。

后端采用的微服务的设计模式，能够根据服务访问量，调整服务的数量，以应对不的访问量需求，以便达到按需购买。从而减少成本，同时能够应对不断变化的访问量。

在这样一种架构下，可以根据不同的情况对系统进行扩展：

如果整个系统的瓶颈在Web服务器，由于所有的WEB问都将通过负载均衡服务器进行分发，因此我们可以简单地通过添加WS的方式来提高整个系统的处理能力，图示如下：

 

如果整个系统的瓶颈在应用服务器，我们可以从垂直（同一机器上的Clone） 和水平（添加机器）两个方面进行扩展，扩展的图示如下：

 

 如果系统的瓶颈在数据库服务器，可以通过增加CPU或者采用更高端的机器来实现。方案中的平台核心应用服务器软件支持跨平台使用，建议方案的开发技术又是基于Java的跨平台技术，从而保证新系统具有优秀的扩展和升级能力。在进行系统和网络设计的时候考虑到将来软硬件的扩展，设备的性能均提前考虑扩展后的需要。

2.3.3.4 系统可靠性设计

方案从几方面保障系统运行的可靠性：

  • HTTP服务可靠性：负载均衡服务器负责将用户的请求分派到两台HTTP服务器上。若其中有任何一台HTTP服务器出现故障而停止服务，负载均衡服务器会将用户全部引导到另外一台工作正常的服务器，保证系统可用。
  • 应用服务器的可靠性：HTTP服务器上安装的应用服务器插件负责将动态的功能请求分派到相应的应用服务器组。本系统中所有应用服务器都成对配置，若有任何一台应用服务器进程被停止，HTTP服务器上的插件都会将用户引导到同一应用服务器组上的另外一台正常的应用服务器上，确保服务不会中止。
  • 数据库服务器的可靠性：使用两台数据库服务器，两台数据库服务器间实现互备。若数据库服务器遇到异常停止服务，备份服务器会立即接管数据库服务器的存储和IP地址，并启动数据库服务，确保系统正常运转
  • 网络可靠性：在设备，链路上采用冗余模式，保证应用数据无间断的交互，有效的保障了整个系统的可靠性和可用性。

2.3.3.5 系统安全性设计

基于信息系统安全领域的技术和经验，为系统提供安全保障。

1）对于系统安全，利用防火墙技术本身的安全性本身设置安全策略，只允许符合规则的业务数据流通过，保障了网络的安全访问和内网不同层次的安全。在内网中，通过划分VLAN，并且使数据只在某一VLAN中传递。主机和操作系统通过定期更新系统补丁，关闭不需要的端口和服务，验证密码有效长度和期限等来保证系统上的安全。

2）对于数据安全，系统中的数据安全主要体现在四个方面：身份认证、按角色进行分级权限控制、数据加密、操作日志记录。

 

 系统实现上将通过数字证书等手段确保终端身份认证；同时，对应不同角色进行不同的访问权限细分，通过操作日志记载跟踪整个系统的使用情况，防止各类用户的恶意访问。

  • 身份认证分为身份管理、认证服务、信息服务三部分,采用分级、分域的管理方式，分部门、分子系统管理用户，建立统一的用户数字身份信息库和角色信息库，集中统一的用户身份认证，实现单点登录。
  • 分级权限控制包括对用户操作级别进行划分，对应用功能进行划分，对角色进行总结与划分和角色功能的匹配。
  • 对于用户的所有操作，都记录与日志系统中，可以对异常的操作进行追踪，确保异常的操作可以溯源。
  • 数据加密在对关键信息的加密存储上，使用DES或3-DES加密算法。
  • 全程日志管理对系统的运行状态，操作状态等信息以统一格式记录在系统后台的日志中，对日志文件的访问必须有系统管理员的授权才能访问。

2.3.3.6 系统易维护性设计

采用的技术都是遵循业界标准的技术，这些技术的使用使系统的管理和维护变得非常容易。同时方案中所有的硬件和软件产品都有自己的监控管理器。同时在整个方案中的系统管理模块作为整个系统运行和维护的工作，方便系统管理员进行系统监控和管理配置。在系统实施的过程中，还将制定系统的运行和维护的相应规范和制度，从而保证新系统能够稳定地运行。

2.3.3.7 系统高性能和实时性设计

系统使用负载均衡服务将用户的请求均衡地分发到Web服务器上；如果是动态请求，它又将被均衡地分发到应用服务器上，从而实现用户请求在系统的动态均衡。在网络上，使用高性能的网络设备，以保证数据交互无阻碍，达到快速转发，以保证应用上的实时性。

 

3 应用架构

3.1 应用模块

需要修改

需要修改

可能需要修改运维管理平台侧重于三维运用，后台管理系统对一些通用数据和系统进行统一管理设置。

 

3.2 运维管理平台                                                                                                                                                                                                                                                                                                                                                                                  

3.2.1 模型管理

a.模型管理

主要包含了模型的查看，模型载入，模型同步功能。通过BIMShare中心，载入模型基本数据，在运维管理平台中修改主要参数，如果BIMShare中心数据有修改，可以通过同步，将其同步到运维管理平台。

b.模型映射

主要功能包括：模型查找，模型映射。模型映射将模型定位到具体的模型视图，修改模型的主要参数，并提交，生产一个模型审核流程，通过预定的审核流程进行审核，并记录审核过程。

c.模型审核

对提交的模型数据进行审核，这过程需要具有审核权限的人或者角色才能够进行审核操作，审核完全通过之后，数据进行真正的更新。

-----添加功能模块介绍

需要修改

 

 

3.3 后台管理系统

3.3.1 系统管理

 

a.用户管理

主要功能包括用户增删改查、密码重置，用户启用以及禁用。

 

采用左树右表的设计方式，通过点击左边的机构树，可以对用户进行过滤。

b.机构管理

       主要功能包括：机构增删改查。

 

机构类似部门，同时包括了公司这样的分类。

c.字典管理

字典提供了系统的公共参数。

字典管理包括：系统字典和业务字典。系统字典提供的是可以供系统所用的公共参数。业务字典则是提供某个业务中可以用的参数，在整个系统并不通用。

 

单击字典

 

 

 

 

 

 

，在右侧展示字典详情

 

d.菜单管理

菜单包括顶部菜单和一般菜单。顶部菜单，顾名思义就是在顶部的菜单，顶部菜单是所用菜单的父类。一般菜单是在管理后台的左侧的菜单，它和顶部菜单的位置不同，同时，在添加一般菜单的时候，可以选择所属的顶部菜单。

e.参数管理

参数管理提供的是系统主要参数的设置。

 

f.租户管理

租户管理解决了不同租户的数据隔离需求。同时，可以设定在每个租户下面的用户数量等。

 

 

 

3.3.2 权限管理

 

a.角色管理

主要功能包括角色增删改查、权限设置，角色启用以及禁用，收回权限，拷贝权限，选择用户。

 

权限设置。

 

b.数据权限

      数据权限是业务中，控制不同字段的查看权限。

 

c.接口权限

接口权限控制对外接口的访问控制权限。

 

3.3.3 资源管理

 

a.对象存储

 

配置不同的存储接口，以及存储资源的位置。

b.短信配置

配置不同的短信接口。

 

c.任务调度

3.3.4 系统监控

 

  1. Zipkin监控

       分布式系统中，存在系统间的相互调用，存在一个资源请求需要调用多个服务器，及其服务间相互调用，一旦调用过程中出错，问题将很难定位。然后通过Zipkin可以轻松的知道一次调用系统之间的调用情况。

  1. Turbine监控

       分布式系统中，相同的节点需要部署多个的情况，很多时候，运维人员希望把这些相同节点一个集群整体的方式展示出来，这样能够更好的把握整个集群的状态。

  1. Sentinel监控

       随着微服务的流行，服务和服务之间的稳定性变得越来越重要。Sentinel 是面向分布式服务架构的轻量级流量控制产品，主要以流量为切入点，从流量控制、熔断降级、系统负载保护等多个维度来帮助您保护服务的稳定性。

  1. 日志管理

       包括通用日志、接口日志、错误日志。通用日志是对操作的行为做记录，接口日志是接口调用产生的日志，错误日志是在系统出错的产生的记录。

  1. 接口文档

        

 

文档接口展示如上图

采用了swagger2自动生成文档。

  1. 服务治理

          

通过集中式的查看各个服务的健康状态，数量等信息。

  1. ELK日志管理系统

ELK是Elasticsearch、Logstash、Kibana三大开源框架首字母大写简称。市面上也被成为Elastic Stack。其中Elasticsearch是一个基于Lucene、分布式、通过Restful方式进行交互的近实时搜索平台框架。像类似百度、谷歌这种大数据全文搜索引擎的场景都可以使用Elasticsearch作为底层支持框架，可见Elasticsearch提供的搜索能力确实强大,市面上很多时候我们简称Elasticsearch为es。Logstash是ELK的中央数据流引擎，用于从不同目标（文件/数据存储/MQ）收集的不同格式数据，经过过滤后支持输出到不同目的地（文件/MQ/redis/elasticsearch/kafka等）。Kibana可以将elasticsearch的数据通过友好的页面展示出来，提供实时分析的功能。

ELK工作原理如下：

4 开发环境

技术/标准/协议/工具

名称

说明

开发语言

Java1.8

 

开发系统

Windows10

 

开发工具

Idea 2019.3

 

版本控制器

Git

分布式版本控制工具

前端技术

avue2.0、element-ui、unity

 

前端开发工具

Visual studio

 

日志

SFL4j，log4j

 

数据库

Mysql5.7

 

数据库客户端

Heidisql3.9

开源免费

数据库设计工具

Powerdesiner

 

流程图、拓扑图工具

Precesson

在线作图工具

接口调试工具

Postman

 

压力测试工具

AB

 

 

5 逻辑架构视图

5.1 某某系统平台后台架构图

 

4.2.1展现层

展现层分为浏览器端和unity两种的展现方式。

Web前端 基于HTML/HTML5/Vue/CSS3开发web前端页面，兼容主流浏览器。展现层和数据层完全分离，通过跨域实现前后端数据通信；Unity客户端能够通过不同的打包方式运行在windows和ios系统上。 Restful接口 基于特定业务，采用Restful标准接口，对外提供数据服务。

4.2.2通讯层

基于TCP/HTTP/HTTPS 三种通信方式，实现前后端数据通信。

4.2.3 业务层

核心业务基于Spring Cloud Alibaba架构实现微服务化。

 Spring Cloud Alibaba是一个基于Spring Boot实现的云应用开发工具，它为基于JVM的云应用开发中的配置管理、服务发现、断路器、智能路由、微代理、控制总线、全局锁、决策竞选、分布式会话和集群状态管理等操作提供了一种简单的开发方式。 微服务是可以独立部署、水平扩展、独立访问（或者有独立的数据库）的服务单元，Spring Cloud Alibaba就是这些微服务的大管家，采用了微服务这种架构之后，项目的数量会非常多，Spring Cloud Alibaba做为大管家需要管理好这些微服务。 相关的组件包括如下：

5.1.0.1 Nacos

Nacos是以服务为主要服务对象的中间件，Nacos支持所有主流的服务发现、配置和管理。四大功能包括：服务发现与服务健康检查、动态配置管理、动态DNS服务、服务和元数据管理。

Nacos架构图：

 

5.1.0.2 Netflix Hystrix

   熔断器，容错管理工具，旨在通过熔断机制控制服务和第三方库的节点,从而对延迟和故障提供更强大的容错能力。

 

 

5.1.0.3 Spring Cloud Gateway 

Spring Cloud Gateway为Spring生态系统上的一个API网关组件，主要提供一种简单而有效的方式路由映射到指定的API，并为他们提供安全性、监控和限流等等 

Spring Cloud Gateway原理如下：

 

5.1.0.4 Sentinel

集成Sentinel从流量控制、熔断降级、系统负载等多个维度保护服务的稳定性。

5.1.0.5  Spring Cloud Config

俗称的配置中心，配置管理工具包，让你可以把配置放到远程服务器，集中化管理集群配置，目前支持本地存储、Git以及Subversion。

 

5.1.0.6 Spring Cloud Bus

 事件、消息总线，用于在集群（例如，配置变化事件）中传播状态变化，可与Spring Cloud Config联合实现热部署。

 

5.1.0.7 Spring Cloud Sleuth

日志收集工具包，封装了Dapper和log-based追踪以及Zipkin和HTrace操作，为Spring Cloud Alibaba应用实现了一种分布式追踪解决方案。

5.1.0.8  Spring Cloud Task

主要解决短命微服务的任务管理，任务调度的工作，比如说某些定时任务晚上就跑一次，或者某项数据分析临时就跑几次。

 

 

 

 

5.2 数据库层

某某系统平台采用mysql数据库管理数据，mysql数据库具有很好的性能，开源，免费满足项目需求。

 

5.2.1 基于mysql的数据库备份和恢复方案

Recovery Manager（RMAN）是一种用于备份(backup)、还原(restore)和恢复(recover)数据库的 Oracle 工具。它能够备份整个数据库或数据库部件，如表空间、数据文件、控制文件、归档文件以及Spfile参数文件。RMAN也允许您进行增量数据块级别的备份，增量RMAN备份是时间和空间有效的，因为他们只备份自上次备份以来有变化的那些数据块。

备份策略如下所示：

 

图 61 数据库备份示意图

全库备份

数据库每天都进行一次全库备份，备份设备与实时运用设备分离，备份时间选择在业务系统不繁忙的夜间完成，备份后可以选择备份数据的保留时间，在一定阶段后备份数据可实现滚动，在验证下一存储数据合法性后存储压缩以节约存储介质。

实时增量热备

mysqldump备份成sql文件

假想环境：
MySQL   安装位置：C:\MySQL
论坛数据库名称为：bbs
MySQL root   密码：123456
数据库备份目的地：D:\db_backup\

脚本：


rem *******************************Code Start*****************************
@echo off

set "Ymd=%date:~,4%%date:~5,2%%date:~8,2%"
C:\MySQL\bin\mysqldump --opt -u root --password=123456 bbs > D:\db_backup\bbs_%Ymd%.sql

@echo on
rem *******************************Code End*****************************

将以上代码保存为backup_db.bat
然后使用Windows的“计划任务”定时执行该脚本即可。（例如：每天凌晨5点执行back_db.bat）

说明：此方法可以不用关闭数据库，并且可以按每一天的时间来名称备份文件。

通过%date:~5,2%来组合得出当前日期，组合的效果为yyyymmdd,date命令得到的日期格式默认为yyyy-mm-dd(如果不是此格式可以通过pause命令来暂停命令行窗口看通过%date:~,20%得到的当前计算机日期格式)，所以通过%date:~5,2%即可得到日期中的第五个字符开始的两个字符，例如今天为2020-02-05,通过%date:~5,2%则可以得到02。（日期的字符串的下标是从0开始的）

 

5.3 服务相关

4.4.1、认证系统 

采用双token的方式完成jwt。其中accessToken 用于用户身份认证。refreshToken用于当accessToken失效时重新生成。

用户登录：

 

token认证访问（accessToken失效，refreshToken有效）

 

accessToken和refreshToken 都失效

 

 

4.4.2日志系统

 

Logstash ：主要是用来日志的搜集、分析、过滤日志的工具，支持大量的数据获取方式。一般工作方式为c/s架构，client端安装在需要收集日志的主机上，server端负责将收到的各节点日志进行过滤、修改等操作在一并发往elasticsearch上去。

4.4.3回话治理

此处的会话是指Netty 会话管理。实现Channel自定义会话管理，如会话监控、会话超时、会话重建等。

4.4.4DNS劫持处理

移动端产品在实际用户环境下会面临 DNS 劫持、耗时波动等问题，这些 DNS 环节的不稳定因素，导致后续网络请求被劫持或是直接失败, 对产品的用户体验产生不好的影响。 DNS 有 LocalDNS VS HTTP DNS之分 在长期的实践中，互联网公司发现 LocalDNS 会存在如下几个问题： 域名缓存: 运营商 DNS 缓存域名解析结果，将用户导向网内缓存服务器; 解析转发 & 出口 NAT: 运营商 DNS 转发查询请求或是出口 NAT 导致流量调度策略失效; 为了解决 LocalDNS 的这些问题，业内也催生了 HTTP DNS 的概念，它的基本原理如下: 原本用户进行 DNS 解析是向运营商的 DNS 服务器发起 UDP 报文进行查询，而在 HTTP DNS 下，我们修改为用户带上待查询的域名和本机 IP 地址直接向 HTTP WEB 服务器发起 HTTP 请求，这个 HTTP WEB 将返回域名解析后的 IP 地址。 比如 DNSPod 的实现原理如下:

 

相比 LocalDNS, HTTP DNS 会具备如下优势: 根治域名解析异常: 绕过运营商的 DNS，向具备 DNS 解析功能的 HTTP WEB 服务器发起查询; 调度精准: HTTP DNS 能够直接获取到用户的 IP 地址，从而实现准确导流; 扩展性强: 本身基于 HTTP 协议，可以实现更强大的功能扩展。

 

5.4 组件视图

 

 

 

 

 

 

 

5.4.1 组件功能

1) brower这里的是客户端统称，代表pc端

2) Controller 控制器，所有的请求都会交到此处进行处理

3) Database数据库

4) View 用户端看到的数据

5) 事务模型

6 开发架构视图

 

其中service可以进行无限扩展，放在不同的服务器上面，提示系统的并发性能，以及可用性，例如其中同访问的service1挂机的时候，客户的请求自动切换到相同访问的其他service1上面去，提高了可用性。

6.1 项目工程划分

如图

 

├── blade-auth -- 授权服务提供

├── blade-common -- 常用工具封装包

├── blade-gateway -- Spring Cloud 网关

├── blade-ops -- 运维中心

├ ├── blade-admin -- 服务监控

├ ├── blade-develop -- 代码生成

├ ├── blade-flow -- 工作流

├ ├── blade-flow-design -- 工作流设计器

├ ├── blade-log -- 日志模块

├ ├── blade-resource -- 资源模块

├ ├── blade-turbine -- 监控控制台

├ ├── blade-xxljob -- 分布式任务调度

├ ├── blade-xxljob-admin -- 分布式任务调度后端

├ ├── blade-zipkin -- 分布式链路追踪

├ └──

├── blade-service -- 业务模块

├ ├── blade-desk -- 工作台模块

├ ├── blade-system -- 系统模块

├ └── blade-user -- 用户模块

├── blade-service-api -- 业务模块api封装

├ ├── blade-desk-api -- 工作台api

├ ├── blade-dict-api -- 字典api

├ ├── blade-scope-api -- 数据权限api

├ ├── blade-system-api -- 系统api

└── └── blade-user-api -- 用户api

项目后端模块介绍，

1）blade-gateway起到的了对所有客户端的请统一过滤、转发的作用，同时只对客户端暴露一个接口即可。减少了由于服务器迁移带来的端口的修改问题，它统一服务对外的接口。

2）blade-auth 对用户信息进行认证和授权。

3）Nacos 所有的服务包括balde-auth，blade-gateway，blade-desk，都需要在Nacos 服务上注册，从而通过注册中心统一发现和管理这些服务，监控其运行情况。

4）service 业务层逻辑都在此服务上。

6.2 关键代码展示

6.2.1 注册登录

OAuth2.0的引入：
抽象验证流程
由于OAuth1过于复杂，之后对OAuth进行了改造引入了Oauth2.0。OAuth的授权过程如下：

 

 

(A) 客户端从资源拥有者那里请求授权。授权请求能够直接发送给资源拥有者，或者间接地通过授权服务器这样的中介，而后者更为可取。

(B) 客户端收到一个访问许可，它代表由资源服务器提供的授权。

(C) 客户端使用它自己的私有证书到授权服务器上验证，并出示访问许可，来请求一个访问令牌。

(D) 授权服务器验证客户端私有证书和访问许可的有效性，如果验证通过则分发一个访问令牌。

(E) 客户端通过出示访问令牌向资源服务器请求受保护资源。

(F) 资源服务器验证访问令牌的有效性，如果验证通过则响应这个资源请求。

上面只是一个抽象的验证流程，根据上面的抽象流程演化出四种验证模式：
授权码模式
授权码模式和上述的 抽象验证模式流程比较相似：

 

(A) web客户端通过将终端用户的user-agent重定向到授权服务器来发起这个流程。客户端传入它的客户端标识符、请求作用域、本地状态和一个重定向URI，在访问被许可（或被拒绝）后授权服务器会重新将终端用户引导回这个URI。

(B) 授权服务器验证终端用户（借助于user-agent），并确定终端用户是否许可客户端的访问请求。

(C) 假定终端用户许可了这次访问，授权服务器会将user-agent重定向到之前提供的重定向URI上去。授权服务器为客户端传回一个授权码做获取访问令牌之用。

(D) 客户端通过验证并传入上一步取得的授权码从授权服务器请求一个访问令牌。（需要带上ClientId和Secret，ClientId和Secret是通过平台授予）

(E) 授权服务器验证客户端私有证书和授权码的有效性并返回访问令牌。

授权码模式（implicit grant type）
User-Agent子态适用于客户端不能保存客户端私有证书的App（纯客户端App，无Server参与）。因为可纯客户端的程序不能保存密钥

 

(A) 客户端将user-agent引导到终端用户授权endpoint。客户端传入它的客户端标识符、请求作用域、本地状态和一个重定向URI，在访问被许可（或被拒绝）后授权服务器会重新将终端用户引导回这个URI。

(B) 授权服务器验证终端用户（通过user-agent）并确认终端用户是许可还是拒绝了客户端的访问请求。

(C) 如果终端用户许可了这次访问，那么授权服务器会将user-agent引导到之前提供的重定向URI。重定向URI会在URI片断{译者注：URI片断是指URI中#号之后的内容}中包含访问令牌。

(D) user-agent响应重定向指令，向web服务器发送不包含URI片断的请求。user-agent在本地保存URI片断。

(E) web服务器返回一个web页面（通常是嵌入了脚本的HTML网页），这个页面能够访问完整的重定向URI，它包含了由user-agent保存的URI片断，同时这个页面能够将包含在URI片断中的访问令牌（和其它参数）提取出来。

(F) user-agent在本地执行由web服务器提供的脚本，该脚本提取出访问令牌并将它传递给客户端。

密码模式
密码模式就是将密码托管给第三方App，但是必须要保证第三方App高度可信。

 

（A）用户向客户端提供用户名和密码。

（B）客户端将用户名和密码发给认证服务器，向后者请求令牌。

（C）认证服务器确认无误后，向客户端提供访问令牌。

客户端模式
这种模式不需要终端用户的参与，只是Client和Server端的交互。通常只用于Client状态的获取。

 

（A）客户端向认证服务器进行身份认证，并要求一个访问令牌。

（B）认证服务器确认无误后，向客户端提供访问令牌。

授权流程
这里以授权码方式流程说明，主要流程分为两步，获取授权码和通过授权码获取资源票据：

 

（A）用户访问客户端，后者将前者导向认证服务器。

（B）用户选择是否给予客户端授权。

（C）假设用户给予授权，认证服务器将用户导向客户端事先指定的"重定向URI"（redirection URI），同时附上一个授权码。

（D）客户端收到授权码，附上早先的"重定向URI"，向认证服务器申请令牌。这一步是在客户端的后台的服务器上完成的，对用户不可见。

（E）认证服务器核对了授权码和重定向URI，确认无误后，向客户端发送访问令牌（access token）和更新令牌（refresh token）。

 

 

6.2.2 访问授权

用户通过浏览器发起请求，请求到达服务器，通过Nginx转发到指定的服务，请求到网关服务，通过网关的转发，去获取相应的服务，在获取访问之前，如果请求被授权拦截，那么不要先获取授权信息，成功之后获取到相应的服务，服务器返回数据给客户端。

访问流程如下：

 

 

6.2.3  REST风格接口

一种软件架构风格、设计风格，而不是标准，只是提供了一组设计原则和约束条件。它主要用于客户端和服务器交互类的软件。基于这个风格设计的软件可以更简洁，更有层次，更易于实现缓存等机制。

REST 描述了一个架构样式的互联系统（如 Web 应用程序）。REST 约束条件作为一个整体应用时，将生成一个简单、可扩展、有效、安全、可靠的架构。由于它简便、轻量级以及通过 HTTP 直接传输数据的特性，RESTful Web 服务成为基于 SOAP 服务的一个最有前途的替代方案。用于 web 服务和动态 Web 应用程序的多层架构可以实现可重用性、简单性、可扩展性和组件可响应性的清晰分离。开发人员可以轻松使用 Ajax 和 RESTful Web 服务一起创建丰富的界面

运维子平台后台才用的swaggerui作为接口界面。

 

 

6.2.3.1 模型管理接口

接口截图预览

（1）模型管理api

 

（2）模型映射（列表）api

 

（3）获取token的api的调试

 

7 开发技术使用规则

 

【根据系统开发期质量属性对开发采用的技术进行约定】

7.1 设计及编码规范

7.1.1 编码规则

1）类名使用 UpperCamelCase 风格，必须遵从驼峰形式，但以下情形例外：DO / BO / DTO / VO / AO

2）方法名、参数名、成员变量、局部变量都统一使用 lowerCamelCase 风格，必须遵从 驼峰形式

3）常量命名全部大写，单词间用下划线隔开，力求语义表达完整清楚，不要嫌名字长。

4）抽象类命名使用 Abstract 或 Base 开头；异常类命名使用 Exception 结尾；测试类命名以它要测试的类的名称开始，以 Test 结尾

5）枚举类名建议带上 Enum 后缀，枚举成员名称需要全大写，单词间用下划线隔开。

7.1.2  数据库设计规范

  1）数据表命按照模块划分，头部是模块打头

  2）适当进行冗余便于业务代码和性能

7.1.3 异常处理规则

1）finnaly与try块不同的是——finally块中的语句总是会被执行，无论是try块中的语句成功执行还是你在catch块中处理了一个异常。因此所有开启的资源都能够确保被关闭。

2）将异常和它的描述一并抛出

3）优先捕获更加明确的异常

4）不要捕获throwable

8 部署架构视图

7.1规划：

LB-01:192.168.1.191 nginx+keepalived-master
LB-02:192.168.1.192 nginx+keepalived-backup
VIP：192.168.1.99

OS：CentOS 7.4 X64

 

可能需要修改

 

 

8.1 日志文件约定

日志是按照不同模块进行存放。个模块之间是按照循环方式创建日志，日志达到一定数量旧的日志数据被丢弃，同时日志按照不同级别进行存放

 

9 项目本期的安全系统设计

9.1 需求分析

随着安全系统建设越来越大，除了需要协调各个安全系统之间的问题之外，由于安全相关的数据量越来越大，有些关键的安全信息和告警事件常常被低价值或无价值的告警信息所淹没，原有安全系统不有满足所有系统的安全需求，一些全局性的、影响重大的问题很难被分析和提炼出来。为了从大量的、孤立的单条事件中准确的发现全局性的、整体的安全威胁行为，需要一个平台使得整个安全体系的检测能力更加准确，更加集中于影响重大的焦点问题。

9.2 信息安全设计原则

信息安全建设是一个系统工程，系统专用网络系统安全体系建设应按照“统一规划、统筹安排，统一标准、相互配套”的原则进行，采用先进的“平台化”建设思想，避免重复投入、重复建设，充分考虑整体和局部的利益，坚持近期目标与远期目标相结合。

在进行信息系统安全方案设计、规划时，应遵循以下原则：

9.2.1 整体安全原则（木桶原理）

一个由许多块木板组成的木桶，如果组成木桶的这些木板长短不一，那么这个木桶的最大容量不取决于长的木板，而取决于最短的那块木板。同样，一个由许多信息安全设备组成的信息安全防御系统，其信息安全防御水平取决于针对某种信息安全风险性能最低的信息安全设备。

应用该观点，分析网络的安全及具体措施。安全措施主要包括：行政法律手段、各种管理制度（人员审查、工作流程、维护保障制度等）以及专业措施（识别技术、存取控制、密码、低辐射、容错、防病毒、采用高安全产品等）。一个较好的安全措施往往是多种方法适当综合的应用结果。一个计算机网络，包括个人、设备、软件、数据等。这些环节在网络中的地位和影响作用，也只有从系统综合整体的角度去看待、分析，才能取得有效、可行的措施。即计算机信息安全应遵循整体安全性原则，根据规定的安全策略制定出合理的信息安全体系结构。

9.2.2 积极防御原则

随着黑客技术的提高，对信息安全也提出更高的要求。防御黑客除了传统的边界防御设备外，还需具备智能化、高度自动化、响应速度快的信息安全产品，配备技术力量雄厚、响应及时的本地化服务队伍，才能做好各种预防检测工作，达到防患于未然。

9.2.3 多重保护原则

任何安全防御措施都不是绝对安全的，都可能被攻破。但是建立一个多重安全保护系统，各层保护相互补充，当一层保护被攻破时，其它层保护仍可保护信息的安全，才能够有效抵御各种安全风险。

9.2.4 一致性原则

一致性原则主要是指信息安全问题应与整个网络的工作周期（或生命周期）同时存在，制定的安全体系结构必须与网络的安全需求相一致。安全的网络系统设计（包括初步或详细设计）及实施计划、网络验证、验收、运行等，都要有安全的内容及措施，实际上，在网络建设的开始就考虑信息安全对策，比在网络建设好后再考虑安全措施，不但容易，且花费也小得多。

9.2.5 易操作性原则

安全措施需要人去完成，如果措施过于复杂，对人的要求过高，本身就降低了安全性。其次，措施的采用不能影响系统的正常运行。不能够违背信息化建设必须以应用系统为基础，满足业务高效、易操作的原则。

9.2.6 可扩展性原则

由于网络系统及其应用扩展范围广阔，随着网络规模的扩大及应用的增加，网络脆弱性也会不断增加。一劳永逸地解决信息安全问题是不现实的。同时由于实施信息安全措施需相当的费用支出。因此充分考虑系统的可扩展性，根据资金情况分步实施，既可满足网络系统及信息安全的基本需求，亦可节省费用开支。

9.2.7 标准化原则

在软件、硬件、网络、安全和制度建设等方面都必须遵守国家和行业的相关法规、标准和规范。充分考虑工作特点，补充和完善符合实际的组织业务信息标准。

9.3 信息安全总体设计

信息安全系统是整体的、动态的。信息安全系统符合MPDRR模型（M-management，P-protect，D-detection，R1-responce，R2-recovery），因此，要真正实现一个系统的安全，就需要建立一个从保护、检测、响应到恢复的一套全方位的安全保障体系：

 

信息安全方案基于MPDRR模型构建，符合信息安全系统整体性和动态性的特点，是一个统一的、可扩展的安全体系平台。

9.4 信息系统分层安全方案

网络的全面解决方案包括物理安全、网络安全、系统安全、应用安全、信息安全及数据层安全等各个方面。

 

9.4.1 物理层安全方案

保证计算机信息系统各种设备的物理安全是保障整个网络系统安全的前提。物理安全是保护计算机网络设备、设施以及其它媒体免遭地震、水灾、火灾、雷击等自然灾害，人为的破坏或误操作及各种计算机犯罪行为导致破坏的过程。

严格禁止内部办公网用户拨号上网，避免单点破网，被黑客“偷渡”入网。

9.4.2 网络层安全方案

  • 内部局域网与外单位网络、内部局域网与不信任域网络之间可以通过配备防火墙来实现内、外网或不同信任域之间的隔离与访问控制，服务器区与不同信任域之间的隔离与访问控制。
  • 根据具体应用，也可以配备应用层的访问控制软件系统，针对局域网具体的应用进行更细致的访问控制。

9.4.3 信息安全评估

对于黑客的攻击，除了被动防御外，还应做到主动预防。信息安全性扫描分析系统通过实践性的方法扫描分析网络系统，检查系统存在的弱点和漏洞，提出建议补救措施和安全策略的报告，根据扫描报告结果来配置或修改网络系统，达到增强信息安全性的目的。操作系统漏洞扫描系统是从操作系统的角度，以管理员的身份对独立的系统主机的安全性进行评估分析，找出系统配置、用户配置的安全弱点，建议补救措施。

9.4.4 系统层安全方案

  • 对于Windows NT网络系统，可采取以下措施:
  • 使用NTFS文件系统，它可以对文件和目录使用ACL存取控制表;
  • 系统管理员账号由原先的“Administrator”改名，使非法登录用户不但要猜准口令，还要先猜出用户名;
  • 对于提供Internet公共服务的计算机，废止Guest账号，移走或限制所有的其它用户账号;
  • 打开审计系统，审计各种操作成功和失败的情况，及时发现问题前兆，定期备份日志文件;
  • 及时安装补丁程序。

与此同时，利用相应的扫描软件对其进行安全性扫描评估、检测其存在的安全漏洞，分析系统的安全性，提出补救措施。最后对管理人员应加强身份认证机制及认证强度。建议使用增强身份验证系统，比如基于令牌的一次性口令认证系统等。

9.4.5 应用层安全

应用系统通常包括数据库系统及专为某些应用开发的系统。对于数据库系统的安全，通常需要注意以下方面：

用户分类：不同类型的用户应该授予不同的数据库访问，管理权限。比如：数据库系统登陆权限，资源管理权限，数据库管理员权限，远程访问权限等。

数据分类：对每类用户他能够使用的数据库是不同的，要进行数据库分类。不同的用户访问不同的数据库系统。

审计功能：DBMS提供审计功能对维护数据库的安全是十分重要的，它用来监视各用户对数据库施加的动作。可以通过用户审计和系统审计两种方式来发现数据库使用过程中出现的问题，从而找到安全隐患。

数据库扫描：利用数据库漏洞扫描软件可以对数据库的安全状况进行完整的分析，并给出修补漏洞，增强安全性的建议。周期性的对数据库进行这种扫描可以降低人为造成的（有意或无意的）数据库的安全风险。

对于非常机密的数据，可以考虑以加密的形式存储数据。

数据库备份与恢复：因为数据在存储，传输过程中可能出现故障，同时计算机系统本身也可能发生一些意料之外的事情，如果没有事先采取数据备份措施，将会导致惨重的损失。因此数据库的备份与恢复也是数据库的一个安全功能，它必须提供。数据库系统的备份可以采取多种方式进行。

对于专为某项应用开发的系统，也应该进行安全配置，尽量做到只开放必须使用的服务，而关闭不经常用的协议及协议端口号。还有就是对应用系统的使用要加强用户登录身份认证。确保用户使用的合法性，严格限制登录者的操作权限，将其完成的操作限制在最小的范围内。并充分利用应用系统本身的日志功能，对用户所访问的信息做记录，为事后审查提供依据。

9.4.6 数据层方案

要保护部门间的数据在处理传输存储过程中不被泄露，必须对数据进行加密。数据加密的方法有从链路层加密、网络层加密及应用层加密。链路层加密机主要根据链路协议（Frame Relay、X.25、DDN、PSTN），采用相应类型的加密机；网络层加密由于是在网层上，因此它对链路层是透明的，与链路是何种协议无关；应用层加密主要适用于具体的加密需求，针对具体的应用进行开发。使用单位可以根据自身网络特点及应用需求选择合适的加密方法。对本系统，建议采用网络层加密设备和应用层加密软件，来保护数据在网络上传输的安全性。

 

posted @ 2020-06-04 16:00  longtengdama  阅读(3041)  评论(0)  编辑  收藏  举报