Docker 解决服务运行环境可迁移问题的关键,就在于 Docker 镜像的使用上。实际微博在使用 Docker 镜像的时候并不是把业务代码、依赖的软件环境以及操作系统本身直接都打包成一个镜像,而是利用 Docker 镜像的分层机制,在每一层通过编写 Dockerfile 文件来逐层打包镜像,并且在打包 Docker 镜像的时候,可以分层设计、逐层复用。
微博的容器运维平台 DCP 的架构主要分为基础设施层、主机层、调度层、编排层。基础设施层主要解决镜像仓库的问题,用于存放容器镜像的镜像仓库、提供监控服务的监控中心、实时监控系统容量。主机层主要解决如何进行资源调度的问题,需要适配不同底层提供的创建主机的 API 进行成本核算并且进行配置初始化操作。调度层主要解决容器如何在资源上创建的问题,需要在可用的主机上创建容器。编排层主要解决容器如何运作以对外提供服务的问题,作用是对服务进行整合以对外提供服务,主要包括服务依赖、服务发现以及自动扩缩容。
微博主要使用的是 GitLab 来实现 DevOps。在持续集成阶段,需要保证每一次开发的代码都没有问题,即使合并到主干也能正常工作,这里主要依靠代码检查、单元测试和集成测试。在持续交付阶段,需要保证最新的业务代码能够在类生产环境中可能够正常运行。
微博采用了混合云部署,才真正解决了面对频繁爆发的热点事件带来突发流量时,内部资源冗余度不足的问题。但是在企业内部的私有云部署服务,又同时在企业外部公有云部署服务时,需要实现跨云服务的负载均衡、跨云服务数据同步、跨云服务容器运维。
要想让经典的微服务架构直接走向 Service Mesh 并不容易。微博的各种内部基础设施定制化、业务稳定性优先准则等因素,注定了微博需要走出一条自己的 Service Mesh 实践之路。微博也是随着业务的发展,在经过多方探索和尝试后才笃定了走 Agent 代理这条路。而采用的 Agent 代理的解决方案又与 Service Mesh 理念不谋而合,于是在 Agent 代理的方案中吸纳 Service Mesh 的思想,再进一步演化成如今的 Weibo Mesh。所以说一个可靠的架构从来都不是设计的,是逐步演进而来的。