本人个人博客原文，未经允许，谢绝转载

方案概述：

方案初衷涉及到一些工作，略过

整体方案解决体系分为三步：

  • 方案拟定、方案定型、搭建一套和目前生产环境一致的系统架构体系，用于生产测试环境，根据业务的需求进行优化配置，对测试环境进行大并发高可用性能进行测试，满足业务运营需求。

  • 复制一套体系做为生产环境，纳入上线管理，安全防护，针对管理权限进行细化，完整的生产应急响应机制，对该阶段暴露的体系问题，记录分析。

  • 对系统体系架构暴露出的问题进行分析解决，对现有的架构体系进行优化整改，完成稳定版系统架构体系定型，在此基础上实现横向扩张，自动伸缩。


 1.1       整体方案架构场景

整体方案架构图：

%E8%87%AA%E5%8A%A8%E5%8C%96%E4%BD%93%E7%


1.1.1  架构方案初期建设

  • 亚马逊云服务商解决方案建设，负责选型可用的服务方案建设，对云服务商提供的解决方案解析筛选，成本控制预算、相关费用透明化；亚马逊方案云服务提供解决方案定型，实现业务快速部署。

  • 安全防御体系建设，制定相应的解决方案，应对网络***采用亚马逊云提供商提供的服务方案，采用AWS waf 和 Aws shield,应对来自网络***，利用Amazon CloudWatch 对来自网络***进行实施监控，实现***实时告警，实时响应。

  • 亚马逊安全体系建设架构图：

%E4%BA%9A%E9%A9%AC%E9%80%8A.png

  • 完成系统标准化规范方案，为后期自动化建设体系做基础性工作后期自动化方案架构图：

%E8%BF%90%E7%BB%B4%E8%87%AA%E5%8A%A8%E5%

  • 初期环境部署系统架构解决方案图：

注：为也生产业务稳定运行，满足业务7X24小时高可用机制，所有关键性节点采用双节点方案，避免单节点故障，边缘化业务采用低配置实现双节点服务，采用高可用主从方式，为后期做自动伸缩扩张做预留方案。

整体架构图如下：

%E8%BF%90%E7%BB%B4%E8%87%AA%E5%8A%A8%E5%

服务器标准化版本规范

  • 为了业务稳定运行，采用官方统一稳定版本进行部署，采用版本如下：

操作系统及应用版本：

  • CentOs CentOS 6.8

  • 数据库版本：       MySQL 5.6.36

  • Redis版本：       Redis 3.2.0

  • Nginx版本： Nginx-1.9.12

  • PHP 版本：           PHP 5.6.31

  • Tomcat版本：       5

  • Java JD版本：       Version 1.8

操作系统及应用版本

  • Zabbix 版本： zabbix 3.0

  • ELK 版本： 根据官方选择最新稳定版

  • Salt stack 版本： 根据官方选择最新稳定版

2.1 生产环境业务架构体系部署

2.1.1 生产环境自动化测试平台构建

  • 版本发布、新版本上线达到测试性能标准、输出相应的测试数据报告，针对不同的关键性指标，需要指定相应的测试机制。

  • 自动化测试环境框架筹备工作，建立初步自动化测试工具平台。

  • 自动化平台架构图：

%E8%87%AA%E5%8A%A8%E5%8C%96%E4%BD%93%E7%

  • 版本更新需要经过测试环境，测试完毕后，放入生产预热测试环境测试，进行相应的测试，满足相应的测试指标及周期，然后进入生产发布版本。

  • 规划测试体系投入比例：按照相应的比重进行划分单元测试、集成测试、接口测试、UI测试、自动化测试。

2.1.2 生产业务服务器监控系统

  • 制定完善的业务监控体系统，实现短信告警功能，整体监控体系架构图：

%E7%9B%91%E6%8E%A7%E4%BD%93%E7%B3%BB%E6%

  • 根据业务制定相应的监控指标，对监控指标进行一段时间的评估期。

  • 对异常告警处理完毕后，输出相应的处理报告，对报告进行分析、评估、最后纳入公司技术文档FQA库

  • 监控告警机制及响应及处理，设定预警机制、设定报警机制、设定告警机制、故障划分、故障响应、故障分级等

  • 架构图如下：


%E8%BF%90%E7%BB%B4%E4%BD%93%E7%B3%BB%E5%


2.1.3 备份机制、容灾机制、业务快速恢复

  • 针对不同业务进行不同的数据备份

  • Web集群备份机制

  • MySQL集群备份机制

  • Redis集群备份机制

  • 监控系统备份机制

  • 负载均衡集群备份机制

  • 管理系统备份机制

  • ELK系统备份机制

  • 容灾机制、数据恢复演练机制

  • 业务系统备份架构图：

%E5%A4%87%E4%BB%BD%E6%9E%B6%E6%9E%84%E5%

3.1针对不同业务进行不同的数据备份

3.1.1 Web集群备份方案与负载均衡备份机制：

  • 规范所有服务安装目录：比如创建专用的目录用于存放安装对应的软件服务

  • 备份对应的配置文件，实现本地压缩打包，同步到备份服务器进行数据备份及MD5值校验，防止被篡改。

  • 备份机制实现每天凌晨1点全量备份，如手动更改配置文件时，需要首先做手动备份，然后开始修改配置文件。

  • 备份回滚机制，定期恢复数据，进行演练机制，自动删除90天前的配置文件备份数据。

  • 备份命名机制：“业务名+年月日周+IP”

3.1.2 MySQL集群备份机制

  • MySQL采用每天增量备份，每天一次全量异地备份，数据保存36个月，备份命名机制“业务数据库名+年月日周+IP”，脚本自动删除3个月以前的备份数据，定期进行数据恢复演练。

3.1.3 Redis集群备份机制

  • 每小时备份一次 RDB 文件，并且在每个月的每一天，也备份一个 RDB 文件。 这样的话，即使遇上问题，也可以随时将数据集还原到不同的版本。

 

  • 每秒钟一次 fsync ，每秒备份一次数据、或者每次执行写入命令时 fsync 。 AOF 的默认策略为每秒钟 fsync 一次，在这种配置下，Redis 仍然可以保持良好的性能，并且就算发生故障停机，也最多只会丢失一秒钟的数据（ fsync 会在后台线程执行，所以主线程可以继续努力地处理命令请求）。

 

  • 暂定每秒fsync，每秒备份一次数据，备份命名机制采用：“业务名称+Redis+IP+年月日时分秒”

 

3.1.4监控系统备份机制

  • 监控系统备份，采用每日凌晨1点进行备份，数据保存周期为一年，备份命名机制采用：“zabbix+IP+年月日”。

3.1.5管理系统备份机制

  • 管理系统备份机制，根据业务不同来划分具体的备目录，统一采用saltstack进行批量管理文件，根据业务分类，对配置文件进行分类备份，备份命名机制采用:“实例名+IP+年月日”，备份机制增量备份，如有新的改动或大面积的调整，调整前后都需要手动进行备份，以保证误操作可以实现秒级回滚机制，实际环境执行，必须加上测试条件，待返回结果正常才能去掉测试条件，例如：salt ‘master_agent’ state.highstate test=Ture。

 3.1.6 ELK备份机制

  • ELK备份机制，针对不同的索引进行不同分分类备份，针对不同的应用日志，ELK配置日志规则，按照业务的不同进行分类分目录进行备份，便于管理及查找、针对ELK日志集中事件展示分析做相应的日志分类，对日志保存周期为6个月，备份机制采用每天全量备份、对关键性的业务及文件日志采用实时备份，采用MD5校验的方式来实现，命名规则采用：“索引值+日志类型+IP+年月日时分秒”。