从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开始学微服务
登录|注册

30 | 如何做好微服务容量规划?

胡忠想 2018-10-30
专栏上一期我给你讲解了单体应用拆分为微服务后带来的开发、测试和运维复杂度的提升,可以通过 DevOps 实现 CI/CD 流程的自动化来解决。除此之外,单体应用拆分为微服务还带来另外一个问题,也就是拆分出来后的多个微服务容量如何规划的问题。在单体应用时,只需要针对这个单体应用的访问量和实际接口性能来决定要不要给单体应用扩容,而拆分为众多的微服务之后,需要考虑每个服务的容量规划,它的复杂度主要来自下面几个方面。
服务数量众多,纯靠人肉运维难以管理,比如微博 Feed 业务仅仅 RPC 服务就有将近 40 个。
服务的接口表现差异巨大,有的接口属于访问量比较大,但接口响应时间比较短的轻接口;有的接口属于访问量比较小,但接口响应时间比较长的重接口。比如微博 Feed 业务中计数接口的平均耗时只有 2~3ms,而微博 Feed 业务中 Feed 接口的平均耗时要超过 200ms。
服务部署的集群规模大小不同,需要扩容的机器数量差异很大。比如微博的 AB 测试服务集群只有大约 20 台机器,扩容只需要几台机器就满足了;而 Feed 服务则有上千台机器,往往扩容需要上百台机器。
服务之间还存在依赖关系,在服务扩容的时候,还需要考虑依赖服务的容量是否足够。比如微博 Feed 业务扩容还依赖用户关系服务和 Card 服务,扩容时还需要考虑依赖的用户关系服务和 Card 服务容量是否有问题。
取消
完成
0/1000字
划线
笔记
复制
© 版权归极客邦科技所有,未经许可不得传播售卖。 页面已增加防盗追踪,如有侵权极客邦将依法追究其法律责任。
该试读文章来自付费专栏《从0开始学微服务》,如需阅读全部文章,
请订阅文章所属专栏。
立即订阅
登录 后留言

精选留言(14)

  • 每天晒白牙
    请问阿忠伯,分区加权计算,响应时间越长,加权越大的原因是什么呢?

    作者回复: 这里权重指的是对机器资源的占用

    2018-10-30
    7
  • Ricky Fung
    想问一下在生产环境做压测,由压测产生的数据要如何处理才不会污染真实的数据?
    2018-12-25
    4
  • 波波安
    老师,这里都是考虑服务层面的扩缩容。对于数据库层面存在瓶颈的情况,有什么经验分享吗。

    作者回复: 数据库方面因为实现自动扩缩容的难度太大,我们目前是留有足够的冗余度,核心数据库都是4倍冗余

    2018-11-18
    2
  • 波波安
    不评估数据库的承受能力吗,不停的扩展服务,把数据库压挂了怎么办?
    2018-11-18
    1
  • Joyce
    如果服务存在分区域(比如地图搜索领域,来自北京的请求路由给固定处理北京数据的微服务)的场景下,怎么去做容量规划呢?因为存在这种固定数据处理微服务的特殊情况
    2019-11-08
  • 刘-阿-伟
    遇到特殊的单机故障,应该排除计算权重,避免部分异常机器,影响权重的计算。
    2019-10-20
  • godtrue
    流量大了就扩容
    流量小了就缩容
    机器是租的吗?要不缩容的机器岂不是要闲置了?
    另外就是线上的压测?不会对线上业务有影响嘛?是只有数据的读,没有写嘛?如果有写怎么控制不影响线上的真实数据?
    2019-06-16
    1
  • 滚键盘
    污染的问题 可以用影子表
    2019-03-13
  • Do
    安全线和致命线是怎么设定的呢? 和集群容量是什么样的关系?
    2019-01-29
  • 扁扁圆圆

    关于权重那块,慢请求越多,计算出来的单机容量更高?不是应该更低吗?

    作者回复: 这里容量应该是所占容量的意思

    2018-11-02
  • Switch
    为什么响应时间越长,权重越高?

    引用:区间加权来计算,也就是把请求按照响应时间分成多个区间,每个区间分别赋予不同的权重,响应时间越长权重越高

    作者回复: 这里权重代表的是对系统资源的占用

    2018-10-31
  • 三木子
    问一个与本节无关的问题,微服务通过http请求调用,数据交换你们做了压缩吗?如果使用过那么用的那种方式呢?

    作者回复: 一般会用gzip压缩

    2018-10-31
  • 拉欧
    可以设置两套监控体系,一个是针对集群的,另一个是针对单机的,对于单机的负载偏高问题,可以用一致性哈希等负载均衡的方式,把请求分配到负载偏低的节点
    2018-10-30
  • 拉欧
    可以设置两套监控体系,一个是针对集群的,另一个是针对单机的,对于单机的水位偏高,可以用负载均衡的方式,把请求分配到水位偏低的节点
    2018-10-30
收起评论
14
返回
顶部