Skip to content

Commit 8dc3942

Browse files
geekibligeekibli
committed
服务注册中心
1 parent 9ba44d5 commit 8dc3942

7 files changed

+228
-10
lines changed

‎极客时间-微服务实战160讲/容错与限流-hystrix/11.SpringCloud Hystrix.md

-10
Original file line numberDiff line numberDiff line change
@@ -9,7 +9,6 @@ Spring Cloud对 Hystrix进行了封装，方便了开发人员的使用。开发
99

1010
#### 1. 将student和school微服务项目导入IDE
1111

12-
1312
**注意**：school项目依赖
1413

1514
```xml
@@ -82,12 +81,3 @@ hystrix dashboard
8281
```
8382
http://localhost:8088/hystrix
8483
```
85-
86-
87-
88-
89-
90-
91-
92-
93-

‎极客时间-微服务实战160讲/容错与限流-hystrix/12.Netflix Turbine简介.md

+20
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,20 @@
1+
# Netflix Turbine简介
2+
3+
4+
Turbine其实是一个聚合服务。如果是单个应用的话，我们是可以直接把应用的Stream推到Dashborad中的，但是如果是集群模式下，就需要聚合服务来聚合集群中的Stream,然后统一推到Dashboard中的。
5+
6+
![](https://oscimg.oschina.net/oscnet/up-f703a5b3cf5b50a1c7b7f26e1a522b4f37e.png)
7+
8+
比如有些数据需要做汇总，统计错率率，或者其他的一些数据，这些工作可以由Turbine来完成。
9+
10+
一般Turbine仅需要部署一台就可以，但是如果业务量非常大的话，Turbine也可以部署集群。
11+
12+
13+
## 对接Eureka
14+
15+
![](https://oscimg.oschina.net/oscnet/up-3a404ae0e943e5c724f9f9b0b4915bc9bde.png)
16+
17+
1. 首先Hystrix应用都集成在我们的微服务和网关中的，这些应用可以统一注册在Eureka或者其他的注册中心上
18+
2. 当Turbine连接各个Hystrix应用的时候，直接去注册中心获取所有的Hystrix应用列表
19+
3. 拿到Hystrix应用列表之后，Turbine可以接入集群Hystrix流，然后对数据进行聚合和计算
20+
4. Turbine聚合后的数据，直接推到Dashboard上，做可视化

‎极客时间-微服务实战160讲/容错与限流-hystrix/13.Hystrix生产环境最佳实践.md

+27
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,27 @@
1+
# Hystrix生产最佳实践
2+
3+
1. 网关集中买点，覆盖大部分应用场景
4+
> 搞定网关上的限流熔断可以解决绝大部分场景，其他的限流熔断埋点可以根据实际情况去做细化
5+
> 比如杨波老师说的携程在调用三方接口去查询机票信息的时候，需要调用航空公司自己的接口
6+
> 有比如，我之前做过保险报价平台，需要并发调用多家保险公司的接口进行报价
7+
> 像这些依赖的三方接口可以做一些限流熔断是非常有必要的。
8+
9+
2. 尽量框架集中埋点，客户端为主
10+
> 一般是客户端调用服务端的时候进行封装的
11+
12+
3. 配置对接配置中心比如Apollo,根据实际情况动态调整配置阈值
13+
14+
4. 信号量隔离VS线程池隔离
15+
1. 信号量：如果是网关的话一般使用信号量，还有一些缓存的请求也是信号量
16+
2. 线程池：服务间调用客户端，数据库访问，第三方调用，有性能消耗
17+
18+
5. 线程池大小经验
19+
> 30 rps x 0.2 sec = 6 + breathing room = 10 threads
20+
> Thread-pool Queue size: 5~10
21+
22+
6. 部署部分
23+
1. Hystrix Dashboard 大盘（无线/H5/第三方网关）实时监控进入网关的流量
24+
2. 共享Hystrix Dashboard/Turbine服务器，公司小组间内部尽量共享。
25+
3. 熔断告警
26+
27+
7. 如果使用了Springboot框架可以使用SpringCloud Hystrix进行开发，降低了开发难度

‎极客时间-微服务实战160讲/注册发现-Eureka/1.服务发现的需求.md

+98
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,98 @@
1+
# 服务发现的背景
2+
3+
4+
## 从单体到微服务
5+
6+
现在基本上已经没有单体应用的，基本上都是微服务架构。
7+
8+
![](https://oscimg.oschina.net/oscnet/up-07a15a546529731560f4d71f7b0a4b5aa10.png)
9+
10+
## 微服务架构的根本问题
11+
12+
微服务架构有着两个根本的问题。
13+
14+
在微服务架构中，又着两个角色，服务的提供者：**服务端**，服务的使用者：**消费端/客户端**
15+
16+
第一个问题：一个服务可能部署了多个节点，那么客户端如何得知都有哪些节点呢？
17+
18+
第二个问题：一个请求最终肯定是由一个服务端处理的，那个多个服务端的情况下，客户的请求到底由谁处理呢?
19+
20+
![](https://oscimg.oschina.net/oscnet/up-0072a942c952aa132d562f0fbde467c7c54.png)
21+
22+
由此引出两个技术： **服务发现** 和 **负载均衡**
23+
24+
> 这里的负载均衡值得是客户端的负载均衡
25+
26+
27+
## 解决办法
28+
29+
通过代理的方式，客户端可以找到服务端。
30+
31+
![](https://oscimg.oschina.net/oscnet/up-a5e81ae22d51d557db226e0a63bd45d420a.png)
32+
33+
根据代理组件存放的位置不同，衍生出很多不同的模式
34+
35+
36+
### 传统集中式代理
37+
38+
代理放到消费者和服务端中间，集中独立部署的。
39+
40+
![](https://oscimg.oschina.net/oscnet/up-fbfc10fd25910eeb780b3f1b37751091976.png)
41+
42+
这种模式下如何进行服务端的发现呢？
43+
44+
一般的情况下，是由专门的人员比如专门的运维团队来进行管理，当后端微服务上线的时，将服务的信息添加到Nginx中。
45+
46+
客户端如何发现服务呢？
47+
48+
通过DNS域名解析，客户端首先找到代理，然后在解析运维人员之前配置的信息，路由到服务器上
49+
50+
> 比如user.com分配到UserServer上面。
51+
52+
中间的代理有两种，一种是硬件的代理F5，另一种是软件的代理，比如Nginx
53+
54+
55+
### 服务注册中心+客户端嵌入式代理
56+
57+
代理挪到客户端。一般需要注册中心配合使用。
58+
59+
![](https://oscimg.oschina.net/oscnet/up-955281eabe435f981d54158846eb19d5527.png)
60+
61+
后端的服务自注册到注册中心上面，客户端可以自发现有哪些服务，然后通过负载均衡的策略，把请求路由到正确的服务上。
62+
63+
这种方式会受客户端语言的影响。
64+
65+
### 主机独立进程代理
66+
67+
代理即不放在服务端也不放在客户端的代码里，而是在每个客户端的主机上，部署一个进程。
68+
69+
当前主机的多个客户端，通过代理进程，可以访问服务端。
70+
71+
![](https://oscimg.oschina.net/oscnet/up-4dcb3d49dea048291a9f9f07567fdfca61b.png)
72+
73+
74+
### 上面三种模式比对
75+
76+
![](https://oscimg.oschina.net/oscnet/up-66b2ba44aef78fe6ed76a43e9955026b0a0.png)
77+
78+
79+
80+
## 集中代理模式的两个变体
81+
82+
代理模式是目前比较主流也是非常好用的模式。
83+
84+
### 变体1
85+
86+
服务的注册不用运维人员注册，而是通过注册中心实现自注册和自发现。
87+
88+
![](https://oscimg.oschina.net/oscnet/up-961619d1f685f12d91ab86bdabb0dd7e895.png)
89+
90+
### 变体2
91+
92+
同样使用注册中心，但是不适用自注册的功能。因为自注册的话需要服务进程引入注册中心的客户端，这样才能实现自注册。
93+
94+
![](https://oscimg.oschina.net/oscnet/up-61e19ca5b3232db002904b4815d096f5651.png)
95+
96+
这种方式，不需要引入每个服务进程都引入注册中心的客户端程序。
97+
98+
而是在注册中心上面提供一个页面或者接口，可以手动的添加注册后端服务。注册中心可以定期检查后端服务。

‎极客时间-微服务实战160讲/注册发现-Eureka/2.Eureka和Ribbon的背景介绍.md

+19
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,19 @@
1+
# Netflix Eureka 和 Ribbon的背景介绍
2+
3+
现在知道Netflix这家公司的技术有多牛逼了吧!
4+
5+
- [**Eureka**](https://github.com/Netflix/eureka)
6+
- [**Ribbon**](https://github.com/Netflix/ribbon)
7+
8+
## Eureka/Ribbon背景
9+
10+
![](https://oscimg.oschina.net/oscnet/up-872f764393f0be0979d64a08298214a4729.png)
11+
12+
13+
## 主要应用（Netflix）
14+
15+
![](https://oscimg.oschina.net/oscnet/up-e0a2efdac0b613e8b84cfa720eb398bc46b.png)
16+
17+
这里整个架构区分了多层。
18+
19+
其中Middle Tier Service是后端服务，Edge Service作为边界服务或者聚合服务，都需要注册到注册中心上面。

‎极客时间-微服务实战160讲/注册发现-Eureka/3.Eureka和Ribbon架构原理.md

+42
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,42 @@
1+
# Eureka架构原理
2+
3+
[**深度剖析服务发现组件~Netflix Eureka**](https://zhuanlan.zhihu.com/p/24829766)
4+
5+
## Eureka架构
6+
7+
关于Eureka的详细介绍，可以参见官方文档 [**Eureka-at-a-glance**](https://github.com/Netflix/eureka/wiki/Eureka-at-a-glance)
8+
9+
![](https://oscimg.oschina.net/oscnet/up-824a3e4a47440279e21fc83bd1be925a0e4.png)
10+
11+
Eureka相当于一个服务器，且它本身不带数据库，不代内存的。
12+
13+
14+
## Eureka如何做到高可用？
15+
16+
如上图所示：在同一个机房，部署多个Eureka，每个机房都是一样的部署多台Eureka节点。
17+
18+
不同机房的Eureka的信息会进行replicate备份。
19+
20+
这样整个Eureka部署架构可以作为一个集群。
21+
22+
对于服务提供者，可以自注册到Eureka上，当节点下线的时候也会自下线Eureka。
23+
24+
对于服务消费者，直接获取Eureka的服务列表，然后发起调用，一般都是通过RPC来调用。
25+
26+
核心亮点是支持跨机房，高可用部署。
27+
28+
29+
30+
## Eureka内存模型
31+
32+
有点类似于Hashmap。
33+
34+
![](https://oscimg.oschina.net/oscnet/up-f8555b1b21bb6fde8aec051cc414f49cb8b.png)
35+
36+
37+
38+
39+
40+
41+
42+

‎极客时间-微服务实战160讲/注册发现-Eureka/4.Ribbon架构原理.md

+22
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,22 @@
1+
# Ribbon架构原理
2+
3+
[**深入理解Ribbon之源码解析**](https://blog.csdn.net/forezp/article/details/74820899)
4+
5+
## Ribbon主要组件
6+
7+
1. Rule负载均衡：各种客户端负载均衡策略
8+
2. Ping心跳检测：下限的服务不需要调用
9+
3. ServerListUpdater服务列表更新
10+
4. ServerListFilter服务列表过滤（同机房优先调用）
11+
5. ServerList(服务列表)
12+
13+
![](https://oscimg.oschina.net/oscnet/up-d2ae891d6bd9df220f14133cae2d880a760.png)
14+
15+
16+
## Ribbon设计
17+
18+
如上图所示，S1、S2和S3是从Eureka中获取的服务列表，并且可以更新服务列表。
19+
20+
Ping组件可以检测服务是否健康。
21+
22+
客户端调用的时候通过Rule选择负载均衡策略。

0 commit comments

Comments
 (0)