高并发系统设计40问
唐扬
美图公司技术专家
立即订阅
9202 人已学习
课程目录
已更新 38 讲 / 共 40 讲
0/4登录后，你可以任选4讲全文学习。
开篇词 (1讲)
开篇词 | 为什么你要学习高并发系统设计？
免费
基础篇 (6讲)
01 | 高并发系统：它的通用设计方法是什么？
02 | 架构分层：我们为什么一定要这么做？
免费
03 | 系统设计目标（一）：如何提升系统性能？
04 | 系统设计目标（二）：系统怎样做到高可用？
05 | 系统设计目标（三）：如何让系统易于扩展？
06 | 面试现场第一期：当问到组件实现原理时，面试官是在刁难你吗？
演进篇 · 数据库篇 (5讲)
07 | 池化技术：如何减少频繁创建数据库连接的性能损耗？
08 | 数据库优化方案（一）：查询请求增加时，如何做主从分离？
09 | 数据库优化方案（二）：写入数据量增加时，如何实现分库分表？
10 | 发号器：如何保证分库分表后ID的全局唯一性？
11 | NoSQL：在高并发场景下，数据库和NoSQL如何做到互补？
演进篇 · 缓存篇 (6讲)
12 | 缓存：数据库成为瓶颈后，动态数据的查询要如何加速？
13 | 缓存的使用姿势（一）：如何选择缓存的读写策略？
14 | 缓存的使用姿势（二）：缓存如何做到高可用？
15 | 缓存的使用姿势（三）：缓存穿透了怎么办？
16 | CDN：静态资源如何加速？
加餐 | 数据的迁移应该如何做？
演进篇 · 消息队列篇 (6讲)
17 | 消息队列：秒杀时如何处理每秒上万次的下单请求？
18 | 消息投递：如何保证消息仅仅被消费一次？
19 | 消息队列：如何降低消息队列系统中消息的延迟？
20 | 面试现场第二期：当问到项目经历时，面试官究竟想要了解什么？
用户故事 | 从“心”出发，我还有无数个可能
期中测试 | 10道高并发系统设计题目自测
演进篇 · 分布式服务篇 (9讲)
21 | 系统架构：每秒1万次请求的系统要做服务化拆分吗？
22 | 微服务架构：微服务化后，系统架构要如何改造？
23 | RPC框架：10万QPS下如何实现毫秒级的服务调用？
24 | 注册中心：分布式系统如何寻址？
25 | 分布式Trace：横跨几十个分布式组件的慢请求要如何排查？
26 | 负载均衡：怎样提升系统的横向扩展能力？
27 | API网关：系统的门面要如何做呢？
28 | 多机房部署：跨地域的分布式系统如何做？
29 | Service Mesh：如何屏蔽服务化系统的服务治理细节？
演进篇 · 维护篇 (5讲)
30 | 给系统加上眼睛：服务端监控要怎么做？
31 | 应用性能管理：用户的使用体验应该如何监控？
32 | 压力测试：怎样设计全链路压力测试平台？
33 | 配置管理：成千上万的配置项要如何管理？
34 | 降级熔断：如何屏蔽非核心系统故障的影响？
高并发系统设计40问
登录|注册
24 | 注册中心：分布式系统如何寻址？
唐扬 2019-11-18
你好，我是唐扬。
上一节课，我带你了解了 RPC 框架实现中的一些关键的点，你通过 RPC 框架，能够解决服务之间跨网络通信的问题，这就完成了微服务化改造的基础。
但是在服务拆分之后，你需要维护更多的细粒度的服务，而你需要面对的第一个问题就是如何让 RPC 客户端知道服务端部署的地址。这就是我们今天要讲到的服务注册与发现的问题。
你所知道的服务发现
服务注册和发现不是一个新的概念，你在之前的实际项目中也一定了解过，只是你可能没怎么注意罢了。比如说，你知道 Nginx 是一个反向代理组件，那么 Nginx 需要知道应用服务器的地址是什么，这样才能够将流量透传到应用服务器上，这就是服务发现的过程。
那么 Nginx 是怎么实现的呢？它是把应用服务器的地址配置在了文件中。
这固然是一种解决的思路，实际上，我在早期的项目中也是这么做的。那时，项目刚刚做了服务化拆分，RPC 服务端的地址就是配置在了客户端的代码中，不过，这样做之后出现了几个问题：
首先在紧急扩容的时候，就需要修改客户端配置后，重启所有的客户端进程，操作时间比较长；
其次，一旦某一个服务器出现故障时，也需要修改所有客户端配置后重启，无法快速修复，更无法做到自动恢复；
最后，RPC 服务端上线无法做到提前摘除流量，这样在重启服务端的时候，客户端发往被重启服务端的请求还没有返回，会造成慢请求甚至请求失败。
取消
完成
0/1000字
划线
笔记
复制
© 版权归极客邦科技所有，未经许可不得传播售卖。 页面已增加防盗追踪，如有侵权极客邦将依法追究其法律责任。
该试读文章来自付费专栏《高并发系统设计40问》，如需阅读全部文章，
请订阅文章所属专栏。
请订阅文章所属专栏。
立即订阅
登录 后留言
精选留言(11)
longslee打卡。交通流量这个比喻不错。2019-11-20 4
👽服务注册和发现的核心，其实就是——中间件。
引入了一个注册中心的中间件，来统一管理 服务端 和 客户端。
采用的保证服务端正常运行的手段是——心跳机制。
定时向注册中心发送心跳包表明自己运行正常。作者回复: 👍
2019-11-25 3
旅途老师你好 rpc节点向注册中心发送心跳包是通过什么方式呢作者回复: 我之前的项目是注册中心提供http接口
2019-12-01
Keith你好, 关于服务注册的问题:
1. RPC服务端注册时的提供的是IP还是域名?
2. 对于有多个节点的RPC服务端, 它向注册中心注册时是以整个服务为单位还是以每个节点为单位注册?作者回复: 1. 一般是IP
2. 是每个节点2019-11-23- Keith关于文中提到的通过配置文件来实现服务发现的问题(扩容,服务故障修复,平滑重启), 对于其他服务可能存在, 但是对于Nginx, 它有reload指令来"热重启"服务, 有健康检查以及故障移除机制, 所以这些对Nginx来说不是问题吧?
作者回复: 算是吧，不过高并发下 reload会有性能损耗
2019-11-23 
我，还是过于单纯老师 您好
之前说的闪断指的rpc服务和注册中心之间发生网络抖动导致连接短暂断开后又连上这样的场景作者回复: 是的 只要保证阈值时间内有心跳收到就可以了，闪断一般是不影响的
2019-11-21- 我，还是过于单纯老师 您好
按照文中所述服务端和注册中心是通过心跳来检测是否可用，那么是否意味着不存在所谓闪断的问题？如果存在闪断的问题，那么其使用的连接是重新创建的连接还是沿用以前的连接呢？作者回复: 闪断指的是rpc服务吗
2019-11-20 1 
我来也有个疑问：
“假如你的服务有 100 个调用者，有 100 个节点，那么变更一个节点会推送 100 * 100 = 10000 个节点的数据。”
这里为什么是100*100，而不是99+100呢？
某个节点下线，告知另外的99个节点和100个调用者。
难道是：
每个节点再通知各自的调用者？2019-11-19
约书亚其实我觉得你们自研的注册中心应该进一步学习eureka，做成分AZ部署的。自建机房和云是两个AZ，每个AZ一个注册中心，每个注册中心自己独享一个redis。二者互相同步，通过一些机制保证同步不会陷入循环，以及旧版本数据不会覆盖新版本的。作者回复: 现在存储已经改成raft协议的实现了
2019-11-18
Geek_ed5c7b老师您好，我们公司由于规模不大目前没有使用注册中心。主要是通过域名或者k8s的svc来访问。我有个疑惑就是我们使用注册中心是不是因为http协议在请求的时候请求头数据大才选择通过rpc框架来进行服务调用。作者回复: 也不是，其实也可以使用http协议，只是国内同学已经被dubbo教育了好多年了：）
2019-11-18 2- Geek_e986e3老师想问问注册中心注册自身的时候多网卡的情况下怎么获取自身ip？我们之前是去掉127.0.0.1之后取第一个。有没有什么更优雅的获取ip的方法呢？
作者回复: 可以标准化机器名，然后通过机器名获取IP
2019-11-18
收起评论