部署-高可用

服务高可用

1. 无状态服务 - 分布式微服务节点拓展
2. 数据库高可用 - 主从等数据结构 / newSql 数据库

部署高可用

1. 单机房
   1. 人工运维能力与 JAR 部署方式

      

      1. 优点
         1. 部署由专人控制，具有严格的流程制度，保证不会因为误操作等情况照成系统不可用。
      2. 问题：
         1. 运维人力分配：
            1. 正常情况运维人员压力不大。
            2. 异常情况运维人员人力不够。
            3. 底层思维： 关系为多对一，需要优先的运维人员进行操作，无法并行。
   2. 容器平台化部署方式

      

      1. 优点
         1. 系统恢复依靠平台，平台生态环境恢复，系统自动恢复。
         2. 本次故障典型案例：新仓储
      2. 缺点
         1. 因环境重建照成历史遗留系统程序恢复需要调整代码难度增加。
         2. 无法做到优先恢复关键系统服务，只有生态环境恢复或重建后才会自动恢复。
   3. 总体说明：
      1. 当前矛盾明显，运维太过依赖与人力。人力有限，无法照顾与记忆住各方各面。
      2. docker虚拟化刻不容缓。
   4. 附图： 容器平台快速恢复方案

      

      1. 当前完成情况：
         1. Git or Svn 完成备份：备份点为服务器物理磁盘
         2. docker镜像中心 完成备份： 备份地点为服务器物理磁盘
         3. K8s 整体配置设置 完成备份： 备份地址为服务器物理磁盘
      2. 目前可保证：
         1. K8S集群受到破坏后，可快速初始化一个新的集群并直接恢复原本运行服务。
   5. 总结：
      1. 单机房部署方式，能做的只有灾难发生后的快速恢复。恢复过程必然相对较长并且业务直接受阻。
2. 同城双活

   

   1. 分几种情况（自己定义的）
      1. 真双活
         1. 请求被平均分配到两个数据中心
      2. 主从
         1. 大部分请求被分配到一个数据中心上（主），少部分请求分配到（从）数据数据中心
      3. 主备
         1. 1%的请求会配到（备）数据中心上。只验证（备用）数据中心是否正常（含业务验证）
   2. 方式
      1. K8S影子服务组升级
         1. 基于K8S可以快速构建一套系统环境。
         2. 可升级本地私有影子服务组为公有云环境。
      2. K8s多集群模式
         1. 私有云与公有云集中管理+多集群应用。
   3. 优点：
      1. 达到快速恢复或多活。
   4. 缺点：
      1. 需要解决很多问题
         1. 服务就近访问（分区） PS ：spring cloud 提供该功能。
         2. 缓存等中间件共享。
         3. 网络互通，适配。
         4. 等等。。。
3. 两地三中心方案（城双活+异地灾备）网络有很多案例可做参考。

公有云化

1. 数据中心环境托管
2. 交于专业的公司来做专业的事情。

总体分析

1. 同城双活主备应该为当前投入最小收益最高的方案。