MDM CF模板化改造手册
改造原因
由于原有MDM系统部署结构为使用单一EC2形式, 通过docker run的形式直接部署的, 并且各个模块间通过指定固定IP的方式配置, 存在较大弊端和隐患, 因此需要对现有MDM进行AWS云上架构适应性改造, 相关对比表格如下:
| 改造前 | 改造后(测试环境) | 是否更优解 |
|---|---|---|
| 运行于单一EC2, 所需节点配置较高 | 以多个m5.xlarge(暂定)节点分散负载 | √ |
| 运行于单一EC2, 存在单点故障的可能 | 多节点负载应用, 避免单点故障 | √ |
| 可运行于多节点, 但需指定每个节点的IP | 通过ELB对服务进行注册, 避免IP变动引发服务不可用 | √ |
| 如服务容器异常, 需人工登录处理 | ECS服务自托管, 不需要人工干预, 容器挂掉自动拉起 | √ |
| 容器在实例重启后可能无法正常启动 | 不依赖EC2环境, 如某个EC2实例出现问题, 可通过Auto Scaling 重新拉起新EC2, 快速恢复业务 | √ |
| 对单服务多容器支持不好, 需指定容器对应宿主机端口 | ELB可以支持单服务多容器的方式部署, 且自动分发流量, 不需要配置多个地址 | √ |
| 单一服务器成本, 可按需或购买RI | 增加了ECS/ELB/EFS/Redis使用费用, 会导致费用上升1 | × |
