一.业务架构
mvc架构和简单的rpc架构无法满足现有的业务需求，微服务架构是大中型网站主流的架构方案，团队技能和业务规模达到一定高度的时候才能hold住。
现阶段最适合的就是按soa的思想组件化开发+rpc方式实现服务层和应用层解耦，然后再随着规模发展完全服务化，最终进化到微服务。
适合我们理想的业务架构如下：
- 访问层接入各个访问终端
- web层是表象，是基于服务层聚合出来的应用层，可以灵活组合
- 接口层是服务统一调用入口，做访问鉴权，服务聚合等工作
- 服务层是按照soa面向服务的设计原则，合理拆分服务模块，统一服务管控对外开放能力
- 资源层包含关系数据存储，缓存、队列，文件存储、备份等
这样测业务架构之后，无论哪一个层出现瓶颈，都可以快速横向扩展完成伸缩扩容。
二.系统架构
所有的系统都是为业务服务的，技术不满足业务或纯粹追求技术实现都是耍流氓！
业务层面的方案确定了之后，就是系统层面的部署方案，当前系统急需解决的几个问题：
- 典型的mvc垂直架构应用，耦合严重，无法横向扩展
- 单点故障，任何一个环节挂了，整个系统瘫痪
- 没有完善的容灾、备份机制，故障恢复能力不足
- 系统个软件版本不一，服务部署有兼容风险
- 基础日志服务、监控服务、对象存储服务不足
系统发展到瓶颈之后一般都先水平拆分再垂直拆分；选择可横向扩展的集群化部署，来提高系统的吞吐能力，成本上也低的多。
现在的业务指标总体来看还没有出现瓶颈，我们按照逻辑结构把应用拆分的更合理即可。
系统高可用的几个层次:
- 单机部署：适合初期业务
- 双机热备：主发生故障后从库接管服务。缺点就是有一个闲着，现在很少人用这种方案了。
- 负载均衡:4层、7层转发，集群提供访问还有灾备的能力。
- 容灾:单机房，所有的鸡蛋都放在一个篮子里；同城双机房:所有的鸡蛋都放在一个仓库的两个篮子里；异地多活：所有的鸡蛋放在不同仓库的多个篮子里；成本也是N倍上升。
基于阿里云的部署方案：
参考资料：
https://help.aliyun.com/document_detail/27543.html?spm=a2c4g.11186623.6.544.LvP3Be
单可用区：
同城容灾：
跨地域容灾：
各部分合适的容灾方案：
| 架构层次 | 系统 | 模块 | 应用域名 | 部署方案 | 防火墙 | 备注 |
| 服务层 | soa服务 | soa服务 | service.guolijr.com | 单可用区，slb+2ecs | 否 | 内网访问限制 |
| 应用层 | 快审系统 | 快审 | liebaodaikuan.com | 单可用区，slb+2ecs | 是 | 主要营收来源，重要程度最高 |
| www.liebaodaikuan.com | ||||||
| openapi.liebaodaikuan.com | ||||||
| liebaodaikuan.cn | ||||||
| 快审(果粒) | guolijr.com | 快审马甲，独立ip | ||||
| api.guolijr.com | ||||||
| 快审(面包) | mianbaojr.cn | 快审马甲，独立ip | ||||
| mpapi.keyihua.cn | ||||||
| 果粒招聘 | keyihua.cn | 建议域名合并到快审(果粒) | ||||
| www.keyihua.cn | ||||||
| App接口 | sapi.guolijr.com | app矩阵接入层 | ||||
| 其他应用 | 门店销售系统 | shop.guolijr.com | 单ecs+备份 | 否 | 量级较小，内网访问 | |
| Beta测试 | *.beta.guolijr.com | 量级较小，内网访问 | ||||
| 管理后台 | metroplex.liebaodaikuan.com | |||||
| 大后台 | gl.guolijr.com | |||||
| gl.api.guolijr.com | ||||||
| 静态资源 | 静态资源 | static.liebaodaikuan.com |
单可用区，2+ecs |
否 | 和快审实例部署，考虑购买cdn服务 | |
| 蚂蚁有赚 | 蚂蚁有赚 | ant.keyihua.cn | 单ecs+备份 | 否 | 试运营,如果成熟了再分拆 | |
| api.ant.keyihua.cn | 单ecs+备份 | |||||
| 快审分发 | 快审分发 | ecs | 单ecs+马甲+备份 | 否 |
|
|
| 资源层 | 缓存队列 | 缓存队列 | 阿里云-redis | 标准版主备 | 否 | 适合当前业务 |
| 数据库 | 数据库 | 阿里云-rds | 主库 | 否 | 业务出现瓶颈的时候再纵向拆分 | |
| ecs-mysql | 只读从库 | 否 | 负责查询业务 | |||
| 数据备份 | 数据备份 | 阿里云-oss | 单实例三备份 | 否 | 两种环境备份，保障数据安全 | |
| 核心数据本地存储 | 办公室主机 | 否 | ||||
| 对象存储 | 对象存储 | 七牛云 | 单实例 | 否 | 公用静态文件存储 | |
| 文件服务器 | 单可用区，2+ecs | 否 | 私有信息上传 | |||
| 日志存储分析 | 日志存储分析 | elk日志分析系统 | 单ecs+备份 | 否 | 做好备份，随时恢复 | |
| 支撑系统 | 堡垒机 | 堡垒机 | 单ecs+备份 | 否 | 做好备份，随时恢复 | |
| 数据审计 | 数据审计 | 阿里云数据审计服务 | 单实例 | 否 |
|
|
| walle发布 | walle发布 | 单ecs+备份 | 否 | 做好备份，随时恢复 | ||
| zabbix监控 | zabbix监控 | 单ecs+备份 | 否 | 做好备份，随时恢复 | ||
| git仓库 | git仓库 | 单ecs+备份 | 否 | 做好备份，随时恢复 | ||
| 开发机 | 开发机 | 单主机+备份 | 否 | 做好备份，随时恢复 | ||
| 测试机 | 测试机 | 单主机+备份 | 否 | 做好备份，随时恢复 |
架构图：
落实这个结构分三个层面的事情：
一.系统运维层面
-
标准化系统软硬件配置
硬件配置决定了服务器的性能，分层横向扩展之后，同一层的配置信息一致便于运维维护和更好的发挥系统性能。
资源标准化 资源分类 操作系统 CPU 内存(G) 系统盘(GB) 存储(GB) web前端服务器 CentOS 7.4 64位 4 8 40 0 web后端服务器 CentOS 7.4 64位 4 16 40 0 mysql CentOS 7.4 64位 4 32 40 250 redis 阿里云标准双副本 1 8 rds 高可用版 8核 16 250 备份 oss
软件标准化 软件 版本 linux CentOS 7.4 64位 nginx 1.14稳定版 mysql 5.6 php 7.1.1 redis 4.0
-
灾备、容灾能力
- 系统快照、数据备份按天备份到oss
- 快速恢复、迁移到其他机器
-
安全
- 按分层统一规划安全组策略
- 非正常流量清洗
- vpn+堡垒机运维审计、操作规范
- 数据审计、数据操作规范
-
监控、报警
- 基础性能指标云监控
- 系统进程zabbix
- 业务异常、阻塞报警
二.业务层面
- 增加私网slb和服务层，现有服务层平滑迁移
- 增加redis资源层，现有业务平滑迁移
- 增加mysql只读实例，现有业务平滑迁移
- 现有业务模块化迁移
- 快审业务slb集群方案待定（ip马甲独立问题未定）
-
业务拆分预案
- app流量拆分
- 快审收量、分发拆分
- 有赚拆分
-
三.数据分析
- elk日志分析系统
- 业务监控系统
- BI分析
