从0开始学微服务
胡忠想
微博技术专家
立即订阅
16289 人已学习
课程目录
已完结 42 讲
0/4登录后，你可以任选4讲全文学习。
开篇词 (1讲)
开篇词 | 微服务，从放弃到入门
免费
模块一 入门微服务 (10讲)
01 | 到底什么是微服务？
02 | 从单体应用走向服务化
03 | 初探微服务架构
04 | 如何发布和引用服务？
05 | 如何注册和发现服务？
06 | 如何实现RPC远程服务调用？
07 | 如何监控微服务调用？
08 | 如何追踪微服务调用？
09 | 微服务治理的手段有哪些？
10 | Dubbo框架里的微服务组件
模块二 落地微服务 (14讲)
11 | 服务发布和引用的实践
12 | 如何将注册中心落地？
13 | 开源服务注册中心如何选型？
14 | 开源RPC框架如何选型？
15 | 如何搭建一个可靠的监控系统？
16 | 如何搭建一套适合你的服务追踪系统？
17 | 如何识别服务节点是否存活？
18 | 如何使用负载均衡算法？
19 | 如何使用服务路由？
20 | 服务端出现故障时该如何应对？
21 | 服务调用失败时有哪些处理手段？
22 | 如何管理服务配置？
23 | 如何搭建微服务治理平台？
24 | 微服务架构该如何落地？
模块三 进阶微服务 (8讲)
25 | 微服务为什么要容器化？
26 | 微服务容器化运维：镜像仓库和资源调度
27 | 微服务容器化运维：容器调度和服务编排
28 | 微服务容器化运维：微博容器运维平台DCP
29 | 微服务如何实现DevOps？
30 | 如何做好微服务容量规划？
31 | 微服务多机房部署实践
32 | 微服务混合云部署实践
模块四 展望微服务 (4讲)
33 | 下一代微服务架构Service Mesh
34 | Istio：Service Mesh的代表产品
35 | 微博Service Mesh实践之路（上）
36 | 微博Service Mesh实践之路（下）
阿忠伯的特别放送 (4讲)
阿忠伯的特别放送 | 答疑解惑01
阿忠伯的特别放送 | 答疑解惑02
微博技术解密（上） | 微博信息流是如何实现的？
微博技术解密（下）| 微博存储的那些事儿
结束语 (1讲)
结束语 | 微服务，从入门到精通
从0开始学微服务
登录|注册
28 | 微服务容器化运维：微博容器运维平台DCP
胡忠想 2018-10-25
微服务容器化运维系列的前两期，我给你详细介绍了微服务容器化后如何运维的几个关键问题：镜像仓库、资源调度、容器调度、服务编排，这些问题的产生都是因为微服务部署的节点从一台台物理机或者虚拟机变成了一个个容器，运维模式发生了根本性的变化。此时，容器运维平台也就应运而生。
微博的业务从 2013 年就开始进行容器化，2015 年为了应对春晚以及突发热点事件带来的峰值流量，开始引入阿里云；同时也为了适应业务的发展和运维方式的变化，在 2015 年底开始研发新的容器运维平台 DCP。今天我就和你聊聊微博容器运维平台 DCP，我会讲讲一个真实的容器运维平台是如何建设的，在建设过程中面临了哪些问题，以及对应的解决方案，希望可以让你对容器运维平台的架构有所了解，并提供一些经验可供借鉴。
DCP 整体架构
首先我们先来看看 DCP 的架构设计，从下面这张架构图你可以看到，DCP 的架构主要分为四个部分：基础设施层、主机层、调度层、编排层，对应的分别解决前面提到的容器运维平台建设的几个关键问题：基础设施层用于解决镜像仓库的问题，主机层主要解决如何进行资源调度的问题，调度层主要解决容器如何在资源上创建的问题，编排层主要解决容器如何运作以对外提供服务的问题。下面我们来看各层的详细设计。
取消
完成
0/1000字
划线
笔记
复制
© 版权归极客邦科技所有，未经许可不得传播售卖。 页面已增加防盗追踪，如有侵权极客邦将依法追究其法律责任。
该试读文章来自付费专栏《从0开始学微服务》，如需阅读全部文章，
请订阅文章所属专栏。
请订阅文章所属专栏。
立即订阅
登录 后留言
精选留言(9)
每天晒白牙微博的热点新闻比如前几天赵丽颖结婚事件，导致微博热搜停了一会儿，请问阿忠伯是因为扩容的时候不及时或带宽打满等原因吗？挺期待分享一下事件的原因和处理经过的2018-10-25 10
kefeng老师，DCP服务编排是基于overlay网络吗，还是underlay网络，这部分能介绍一下吗作者回复: 我们用法比较简单，docker网络模式用的是host模式
2018-11-10 1
Sean Zhang我也觉得应该按方式一，各个服务自动按需扩容，前面的服务扩容以后，如果后面的能支撑就不用扩容，不能支撑也会自动扩容的，如果等到所有后面的服务扩容完成就晚了。作者回复: 实际线上操作时，要考虑自动扩容的时间差问题，比如阿里云上的A服务扩容了，把流量都引入到阿里云上，而依赖的阿里云B服务没有扩容，就会造成B服务有问题，为了做大程度不影响线上服务我们使用的是关联扩容。
2018-11-06 1- 每天晒白牙我觉得采用方式一自动扩缩容的方式好一些，因为他们并行扩容等待时间段。如果采用方式二，先让依赖服务B扩容，此时服务A没有扩容，来高流量依然扛不住，等B扩容结束后再开始扩容A，相当于AB串行扩容，可能需要的时间长一些2018-10-25 1
徐巍对于容器来说，扩容应该是一个很轻量级的工作(秒级扩容)，部分有损比雪崩好多了，所以先扩容B，再扩容A2019-10-24
godtrue思考题根据老师的描述，A依赖B，且此时A的流量暴增了，我觉得A和B同时扩容更好，这样对A有所冲击到B时已经扩容岂不更好。
若A和B自适应扩容，都会受到冲击。
若先扩容B，则A受到的扩容就会更久更多。2019-06-16- 龙潜潜关于微服务划分的问题，针对同一业务域，比如user或feed，既存在来自app端的请求，又有来自管理后台的请求。请问这种情况是设置一个微服务模块，还是区分前后端设置两个？2018-10-26
明天更美好胡老师请教个问题。分布式缓存与数据库双写有什么好的方案吗？由于性能要求，我们数据数据全部缓存到分布式缓存中，先更新缓存在异步更新库。但是现在数据库跟缓存存在差异。有上亿数据量，现在要迁移整个idc，并且应用不停机，求数据迁移的方案 必有重谢2018-10-26 1
拉欧扩容可以自动进行，缩容可以按照服务依赖关系串行执行。如果扩容也串行执行，可能最后执行扩容的服务已经因为流量太大搞崩了2018-10-25
收起评论