从 0 开始学微服务
胡忠想
微博技术专家
64643 人已学习
新⼈⾸单¥59
登录后,你可以任选4讲全文学习
课程目录
已完结/共 43 讲
开篇词 (1讲)
结束语 (1讲)
从 0 开始学微服务
15
15
1.0x
00:00/00:00
登录|注册

28 | 微服务容器化运维:微博容器运维平台DCP

自动扩缩容
服务发现
服务依赖
Roam架构
容器创建
配置初始化
成本管理
主机创建
服务发现组件
容量评估系统
监控中心
镜像仓库
编排层
调度层
主机层
基础设施层
思考题
架构设计
微服务容器运维平台DCP

该思维导图由 AI 生成,仅供参考

微服务容器化运维系列的前两期,我给你详细介绍了微服务容器化后如何运维的几个关键问题:镜像仓库、资源调度、容器调度、服务编排,这些问题的产生都是因为微服务部署的节点从一台台物理机或者虚拟机变成了一个个容器,运维模式发生了根本性的变化。此时,容器运维平台也就应运而生。
微博的业务从 2013 年就开始进行容器化,2015 年为了应对春晚以及突发热点事件带来的峰值流量,开始引入阿里云;同时也为了适应业务的发展和运维方式的变化,在 2015 年底开始研发新的容器运维平台 DCP。今天我就和你聊聊微博容器运维平台 DCP,我会讲讲一个真实的容器运维平台是如何建设的,在建设过程中面临了哪些问题,以及对应的解决方案,希望可以让你对容器运维平台的架构有所了解,并提供一些经验可供借鉴。

DCP 整体架构

首先我们先来看看 DCP 的架构设计,从下面这张架构图你可以看到,DCP 的架构主要分为四个部分:基础设施层、主机层、调度层、编排层,对应的分别解决前面提到的容器运维平台建设的几个关键问题:基础设施层用于解决镜像仓库的问题,主机层主要解决如何进行资源调度的问题,调度层主要解决容器如何在资源上创建的问题,编排层主要解决容器如何运作以对外提供服务的问题。下面我们来看各层的详细设计。
确认放弃笔记?
放弃后所记笔记将不保留。
新功能上线,你的历史笔记已初始化为私密笔记,是否一键批量公开?
批量公开的笔记不会为你同步至部落
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线
笔记
复制
AI
  • 深入了解
  • 翻译
    • 英语
    • 中文简体
    • 中文繁体
    • 法语
    • 德语
    • 日语
    • 韩语
    • 俄语
    • 西班牙语
    • 阿拉伯语
  • 解释
  • 总结

微博容器运维平台DCP是微博在容器化运维方面的重要实践。该平台的架构主要分为基础设施层、主机层、调度层和编排层,分别解决镜像仓库、资源调度、容器调度和服务编排等关键问题。在基础设施层,DCP采用开源镜像仓库Harbor搭建私有镜像仓库,并通过主从复制机制与阿里云保持同步,以应对突发峰值流量的挑战。主机层则通过Pluto层完成资源调度,包括主机创建、成本管理和配置初始化等工作。在主机创建过程中,微博遇到了阿里云API的并发限制和库存限制等问题,通过队列机制和多可用区、多安全组、多vSwtich配置等方式进行解决。调度层采用Roam进行容器调度,支持跨IDC、高可用以及可扩展的特性。编排层则实现了服务依赖、服务发现以及自动扩缩容功能。总的来说,微博容器运维平台DCP的架构设计和解决方案为容器化运维提供了有益的经验和借鉴。

仅可试看部分内容,如需阅读全部内容,请付费购买文章所属专栏
《从 0 开始学微服务》
新⼈⾸单¥59
立即购买
登录 后留言

全部留言(10)

  • 最新
  • 精选
  • kefeng
    老师,DCP服务编排是基于overlay网络吗,还是underlay网络,这部分能介绍一下吗

    作者回复: 我们用法比较简单,docker网络模式用的是host模式

    2018-11-10
    2
  • Sean Zhang
    我也觉得应该按方式一,各个服务自动按需扩容,前面的服务扩容以后,如果后面的能支撑就不用扩容,不能支撑也会自动扩容的,如果等到所有后面的服务扩容完成就晚了。

    作者回复: 实际线上操作时,要考虑自动扩容的时间差问题,比如阿里云上的A服务扩容了,把流量都引入到阿里云上,而依赖的阿里云B服务没有扩容,就会造成B服务有问题,为了做大程度不影响线上服务我们使用的是关联扩容。

    2018-11-06
    2
  • 每天晒白牙
    微博的热点新闻比如前几天赵丽颖结婚事件,导致微博热搜停了一会儿,请问阿忠伯是因为扩容的时候不及时或带宽打满等原因吗?挺期待分享一下事件的原因和处理经过的
    2018-10-25
    1
    17
  • 思考题根据老师的描述,A依赖B,且此时A的流量暴增了,我觉得A和B同时扩容更好,这样对A有所冲击到B时已经扩容岂不更好。 若A和B自适应扩容,都会受到冲击。 若先扩容B,则A受到的扩容就会更久更多。
    2019-06-16
    1
  • 明天更美好
    胡老师请教个问题。分布式缓存与数据库双写有什么好的方案吗?由于性能要求,我们数据数据全部缓存到分布式缓存中,先更新缓存在异步更新库。但是现在数据库跟缓存存在差异。有上亿数据量,现在要迁移整个idc,并且应用不停机,求数据迁移的方案 必有重谢
    2018-10-26
    1
    1
  • 拉欧
    扩容可以自动进行,缩容可以按照服务依赖关系串行执行。如果扩容也串行执行,可能最后执行扩容的服务已经因为流量太大搞崩了
    2018-10-25
    1
  • 每天晒白牙
    我觉得采用方式一自动扩缩容的方式好一些,因为他们并行扩容等待时间段。如果采用方式二,先让依赖服务B扩容,此时服务A没有扩容,来高流量依然扛不住,等B扩容结束后再开始扩容A,相当于AB串行扩容,可能需要的时间长一些
    2018-10-25
    1
  • 俯瞰风景.
    容器化运维主要解决的问题是“如何合理地在服务器资源上创建容器并部署服务”,还有就是为了更加高效地使用服务器资源而进行动态扩缩容。
    2021-10-08
  • 徐巍
    对于容器来说,扩容应该是一个很轻量级的工作(秒级扩容),部分有损比雪崩好多了,所以先扩容B,再扩容A
    2019-10-24
  • 龙潜潜
    关于微服务划分的问题,针对同一业务域,比如user或feed,既存在来自app端的请求,又有来自管理后台的请求。请问这种情况是设置一个微服务模块,还是区分前后端设置两个?
    2018-10-26
收起评论
显示
设置
留言
10
收藏
沉浸
阅读
分享
手机端
快捷键
回顶部