背景和里程

(1)开发过程复杂，开发效率低下

• 问题：

• 组合业务难复用

• 逻辑复杂难以追踪

• 业务功能内部耦合，对外不可见

• 无法满足业务的快速交付

  
  

(2)代码重复率高，部署发布困难

• 问题：

• 单系统代码700W+行

• 编译时间>30分钟

• 改一行代码上线花5人天

• 上线前手工提交物件超10种

• 测试40%在等待环境数据

• 故障恢复时间>20分钟

  
  

(3)扩展能力差，应对冲击能力弱

• 问题：

• 无法满足突发业务下的自动扩容

• 单个业务服务多介导致资源浪费

• 应对复杂业务逻辑管理复杂，问题定位难

  
  

(4)运维效率低，故障定位困难

• 问题：

• 流量突变快，系统无法弹性伸缩

• 负载不均，性能成为瓶颈

• 应用的数据存在接口占用问题

  
  

(5)大型IT系统设计十宗罪

开发态：

• 系统解耦不足，内部纠缠林立

• 垂直方式开发，缺乏协同共享

• 代码编译成本高

• 接口层标准化程度差，学习困难

• 源代码膨胀，难管控

运行态：

• 流量突变快，系统无法弹性伸缩

• 负载不均，性能成为瓶颈

• 应用的数据存在接口占用问题

运维态：

• 缺乏自动化监控和调度手段

• 缺乏在线调控和跟踪工具

  
  

容器云架构

容器云核心能力

有状态服务：有状态服务支撑是降本增效的有效手段。基于K8S生态，深化应用承载范畴，不断实践PaaS组件的容器化改造。

SDN网络：拓展传统SDN，支撑容器网络，提供细粒度带宽控制、灵活的微分段、可视化流量监控。

高效发布：引入P2P文件下载技术，解决集群中发布时产生的带宽洪流，提高发布效率，为租户争取更多业务测试时间。

双引擎：容器云平台同时纳管Mesos和K8S两种异构调度引擎，实现统一调度，应用可一键在两种引擎内切换。

双平面：在一个调度引擎内同时包含若干个完整的可用区域，应用可在任一区域运行，提高应用高可用性。

自助管理：秉承“工具换人”思想，为租户提供应用上云全流程自助管理能力。

架构描述：

• Cluster A 和 Cluster B：两个集群通过Harbor进行镜像同步。

• Harbor：作为镜像库的主备存放位置。

• Dragonfly：用于镜像分发，包含 Df-master 和 df-client。

• Nodes：各个计算节点，通过Dragonfly获取镜像。

优化措施：

1. 镜像库主备部署：确保主备库镜像同步和数据一致性。

2. P2P发布：利用 Df-master 和 df-client 进行P2P镜像分发，减少跨机房流量。

3. 镜像分发配置：每个机房配置多个 df-master，确保P2P分发可用。

4. 镜像下载冗余：配置 mirror，当P2P方式失效时从 mirror 下载，提高可靠性。

5. 数据分析：通过数据分析提供优化建议，提高镜像库效率。

核心应用构造

传统企业上云的四点总结：

• 应用云化是关键：一切云化过程，真正的难点不在于平台云化，而在于应用的云化，即租户应用的改造。

• 康威定律引变革：企业的应用上云，不仅是应用技术的升级，它会带来应用架构的改变，而这个改变会引发组织架构的变革。

• 三驾马车跑得快：容器云、微服务中间件、DevOps是企业上云过程中，并驾齐驱的三驾马车。

• 搞得定才叫技术：没有最好的技术，只有最搞得定的技术。搞定的技术才是自己的技术。