Skip to content

Commit c6402cd

Browse files
committed
[feat]目录和内容调整完善
1 parent e734c45 commit c6402cd

File tree

4 files changed

+132
-56
lines changed

4 files changed

+132
-56
lines changed

README.md

Lines changed: 14 additions & 5 deletions
Original file line numberDiff line numberDiff line change
@@ -61,9 +61,11 @@ Github用户如果访问速度缓慢的话,可以转移到[码云](https://git
6161
- [RPC](#rpc)
6262
- [消息队列](#消息队列)
6363
- [API 网关](#api-网关)
64-
- [唯一 id 生成](#唯一-id-生成)
65-
- [ZooKeeper](#zookeeper)
64+
- [分布式id](#分布式id)
65+
- [分布式限流](#分布式限流)
66+
- [分布式接口幂等性](#分布式接口幂等性)
6667
- [数据库扩展](#数据库扩展)
68+
- [ZooKeeper](#zookeeper)
6769
- [大型网站架构](#大型网站架构)
6870
- [性能测试](#性能测试)
6971
- [高并发](#高并发)
@@ -275,11 +277,18 @@ SSO(Single Sign On)即单点登录说的是用户登陆多个子系统的其中
275277

276278
网关主要用于请求转发、安全认证、协议转换、容灾。
277279

278-
- [浅析如何设计一个亿级网关(API Gateway)](docs/system-design/micro-service/API网关.md)
280+
1. [为什么要网关?你知道有哪些常见的网关系统?](docs/system-design/micro-service/api-gateway-intro.md)
281+
2. [如何设计一个亿级网关(API Gateway)?](docs/system-design/micro-service/API网关.md)
282+
283+
#### 分布式id
284+
285+
1. [为什么要分布式 id ?分布式 id 生成方案有哪些?](docs/system-design/micro-service/分布式id生成方案总结.md)
286+
287+
#### 分布式限流
279288

280-
#### 唯一 id 生成
289+
1. [限流算法有哪些?](docs/system-design/micro-service/limit-request.md)
281290

282-
- [分布式id生成方案总结](docs/system-design/micro-service/分布式id生成方案总结.md)
291+
#### 分布式接口幂等性
283292

284293
#### ZooKeeper
285294

docs/system-design/micro-service/API网关.md

Lines changed: 46 additions & 51 deletions
Original file line numberDiff line numberDiff line change
@@ -2,14 +2,11 @@
22
>
33
> 本文授权转载自:[https://github.com/javagrowing/JGrowing/blob/master/服务端开发/浅析如何设计一个亿级网关.md](https://github.com/javagrowing/JGrowing/blob/master/服务端开发/浅析如何设计一个亿级网关.md)
44
5-
## 1.背景
6-
7-
### 1.1 什么是API网关
8-
5+
# 1.背景
6+
## 1.1 什么是API网关
97
API网关可以看做系统与外界联通的入口,我们可以在网关进行处理一些非业务逻辑的逻辑,比如权限验证,监控,缓存,请求路由等等。
108

11-
### 1.2 为什么需要API网关
12-
9+
## 1.2 为什么需要API网关
1310
- RPC协议转成HTTP。
1411

1512
由于在内部开发中我们都是以RPC协议(thrift or dubbo)去做开发,暴露给内部服务,当外部服务需要使用这个接口的时候往往需要将RPC协议转换成HTTP协议。
@@ -31,9 +28,7 @@ API网关可以看做系统与外界联通的入口,我们可以在网关进
3128
对于流量控制,熔断降级非业务逻辑可以统一放到网关层。
3229

3330
有很多业务都会自己去实现一层网关层,用来接入自己的服务,但是对于整个公司来说这还不够。
34-
35-
### 1.3 统一API网关
36-
31+
## 1.3 统一API网关
3732
统一的API网关不仅有API网关的所有的特点,还有下面几个好处:
3833

3934
- 统一技术组件升级
@@ -48,10 +43,8 @@ API网关可以看做系统与外界联通的入口,我们可以在网关进
4843

4944
不同业务不同部门如果按照我们上面的做法应该会都自己搞一个网关层,用来做这个事,可以想象如果一个公司有100个这种业务,每个业务配备4台机器,那么就需要400台机器。并且每个业务的开发RD都需要去开发这个网关层,去随时去维护,增加人力。如果有了统一网关层,那么也许只需要50台机器就可以做这100个业务的网关层的事,并且业务RD不需要随时关注开发,上线的步骤。
5045

51-
## 2.统一网关的设计
52-
53-
### 2.1 异步化请求
54-
46+
# 2.统一网关的设计
47+
## 2.1 异步化请求
5548
对于我们自己实现的网关层,由于只有我们自己使用,对于吞吐量的要求并不高所以,我们一般同步请求调用即可。
5649

5750
对于我们统一的网关层,如何用少量的机器接入更多的服务,这就需要我们的异步,用来提高更多的吞吐量。对于异步化一般有下面两种策略:
@@ -67,86 +60,83 @@ Netty为高并发而生,目前唯品会的网关使用这个策略,在唯品
6760
对于网关是HTTP请求场景比较多的情况可以采用Servlet,毕竟有更加成熟的处理HTTP协议。如果更加重视吞吐量那么可以采用Netty。
6861

6962
#### 2.1.1 全链路异步
70-
7163
对于来的请求我们已经使用异步了,为了达到全链路异步所以我们需要对去的请求也进行异步处理,对于去的请求我们可以利用我们rpc的异步支持进行异步请求所以基本可以达到下图:
7264

73-
[![img](https://camo.githubusercontent.com/ea78c61029cee6487f3aa0cecf5443f18d102173/68747470733a2f2f757365722d676f6c642d63646e2e786974752e696f2f323031382f31302f33312f313636633837373331356535353761663f773d3133303026683d34383026663d706e6726733d3639323735)](https://camo.githubusercontent.com/ea78c61029cee6487f3aa0cecf5443f18d102173/68747470733a2f2f757365722d676f6c642d63646e2e786974752e696f2f323031382f31302f33312f313636633837373331356535353761663f773d3133303026683d34383026663d706e6726733d3639323735)
7465

75-
由在web容器中开启servlet异步,然后进入到网关的业务线程池中进行业务处理,然后进行rpc的异步调用并注册需要回调的业务,最后在回调线程池中进行回调处理。
66+
![](https://user-gold-cdn.xitu.io/2018/10/31/166c877315e557af?w=1300&h=480&f=png&s=69275)
7667

77-
### 2.2 链式处理
68+
由在web容器中开启servlet异步,然后进入到网关的业务线程池中进行业务处理,然后进行rpc的异步调用并注册需要回调的业务,最后在回调线程池中进行回调处理。
7869

70+
## 2.2 链式处理
7971
在设计模式中有一个模式叫责任链模式,他的作用是避免请求发送者与接收者耦合在一起,让多个对象都有可能接收请求,将这些对象连接成一条链,并且沿着这条链传递请求,直到有对象处理它为止。通过这种模式将请求的发送者和请求的处理者解耦了。在我们的各个框架中对此模式都有实现,比如servlet里面的filter,springmvc里面的Interceptor。
8072

8173
在Netflix Zuul中也应用了这种模式,如下图所示:
8274

83-
[![img](https://camo.githubusercontent.com/22d9288d6e9137b98aef563ff7a5a76a090a4609/68747470733a2f2f757365722d676f6c642d63646e2e786974752e696f2f323031382f31302f33312f313636633837383234303735333733353f773d39363026683d37323026663d706e6726733d3439333134)](https://camo.githubusercontent.com/22d9288d6e9137b98aef563ff7a5a76a090a4609/68747470733a2f2f757365722d676f6c642d63646e2e786974752e696f2f323031382f31302f33312f313636633837383234303735333733353f773d39363026683d37323026663d706e6726733d3439333134)
75+
![](https://user-gold-cdn.xitu.io/2018/10/31/166c878240753735?w=960&h=720&f=png&s=49314)
8476

8577
这种模式在网关的设计中我们可以借鉴到自己的网关设计:
8678

8779
- preFilters:前置过滤器,用来处理一些公共的业务,比如统一鉴权,统一限流,熔断降级,缓存处理等,并且提供业务方扩展。
80+
8881
- routingFilters: 用来处理一些泛化调用,主要是做协议的转换,请求的路由工作。
82+
8983
- postFilters: 后置过滤器,主要用来做结果的处理,日志打点,记录时间等等。
84+
9085
- errorFilters: 错误过滤器,用来处理调用异常的情况。
9186

9287
这种设计在有赞的网关也有应用。
9388

94-
### 2.3 业务隔离
95-
89+
## 2.3 业务隔离
9690
上面在全链路异步的情况下不同业务之间的影响很小,但是如果在提供的自定义FiIlter中进行了某些同步调用,一旦超时频繁那么就会对其他业务产生影响。所以我们需要采用隔离之术,降低业务之间的互相影响。
9791

9892
#### 2.3.1 信号量隔离
99-
10093
信号量隔离只是限制了总的并发数,服务还是主线程进行同步调用。这个隔离如果远程调用超时依然会影响主线程,从而会影响其他业务。因此,如果只是想限制某个服务的总并发调用量或者调用的服务不涉及远程调用的话,可以使用轻量级的信号量来实现。有赞的网关由于没有自定义filter所以选取的是信号量隔离。
10194

10295
#### 2.3.2 线程池隔离
103-
10496
最简单的就是不同业务之间通过不同的线程池进行隔离,就算业务接口出现了问题由于线程池已经进行了隔离那么也不会影响其他业务。在京东的网关实现之中就是采用的线程池隔离,比较重要的业务比如商品或者订单 都是单独的通过线程池去处理。但是由于是统一网关平台,如果业务线众多,大家都觉得自己的业务比较重要需要单独的线程池隔离,如果使用的是Java语言开发的话那么,在Java中线程是比较重的资源比较受限,如果需要隔离的线程池过多不是很适用。如果使用一些其他语言比如Golang进行开发网关的话,线程是比较轻的资源,所以比较适合使用线程池隔离。
10597

10698
#### 2.3.3 集群隔离
107-
10899
如果有某些业务就需要使用隔离但是统一网关又没有线程池隔离那么应该怎么办呢?那么可以使用集群隔离,如果你的某些业务真的很重要那么可以为这一系列业务单独申请一个集群或者多个集群,通过机器之间进行隔离。
109100

110-
### 2.4 请求限流
111-
101+
## 2.4 请求限流
112102
流量控制可以采用很多开源的实现,比如阿里最近开源的Sentinel和比较成熟的Hystrix。
113103

114104
一般限流分为集群限流和单机限流:
115-
116105
- 利用统一存储保存当前流量的情况,一般可以采用Redis,这个一般会有一些性能损耗。
117106
- 单机限流:限流每台机器我们可以直接利用Guava的令牌桶去做,由于没有远程调用性能消耗较小。
118107

119-
### 2.5 熔断降级
120-
108+
## 2.5 熔断降级
121109
这一块也可以参照开源的实现Sentinel和Hystrix,这里不是重点就不多提了。
122-
123-
### 2.6 泛化调用
124-
110+
## 2.6 泛化调用
125111
泛化调用指的是一些通信协议的转换,比如将HTTP转换成Thrift。在一些开源的网关中比如Zuul是没有实现的,因为各个公司的内部服务通信协议都不同。比如在唯品会中支持HTTP1,HTTP2,以及二进制的协议,然后转化成内部的协议,淘宝的支持HTTPS,HTTP1,HTTP2这些协议都可以转换成,HTTP,HSF,Dubbo等协议。
126112

127113
#### 2.6.1泛化调用
128-
129114
如何去实现泛化调用呢?由于协议很难自动转换,那么其实每个协议对应的接口需要提供一种映射。简单来说就是把两个协议都能转换成共同语言,从而互相转换。
130115

131-
[![img](https://camo.githubusercontent.com/d680a88d0dd9063fe53df26705836c4b7a19c121/68747470733a2f2f757365722d676f6c642d63646e2e786974752e696f2f323031382f31302f33312f313636633838306163386264623537353f773d3133333826683d39363326663d706e6726733d3830313730)](https://camo.githubusercontent.com/d680a88d0dd9063fe53df26705836c4b7a19c121/68747470733a2f2f757365722d676f6c642d63646e2e786974752e696f2f323031382f31302f33312f313636633838306163386264623537353f773d3133333826683d39363326663d706e6726733d3830313730)一般来说共同语言有三种方式指定:
116+
![](https://user-gold-cdn.xitu.io/2018/10/31/166c880ac8bdb575?w=1338&h=963&f=png&s=80170)
117+
一般来说共同语言有三种方式指定:
132118

133119
- json:json数据格式比较简单,解析速度快,较轻量级。在Dubbo的生态中有一个HTTP转Dubbo的项目是用JsonRpc做的,将HTTP转化成JsonRpc再转化成Dubbo。
134120

135-
比如可以将一个 [www.baidu.com/id](http://www.baidu.com/id) = 1 GET 可以映射为json:
121+
比如可以将一个 www.baidu.com/id = 1 GET 可以映射为json:
136122

137123
代码块
138124

139125
```
140-
126+
{
127+
“method”: "getBaidu"
128+
"param" : {
129+
"id" : 1
130+
}
131+
}
141132
```
142133

143134
- xml:xml数据比较重,解析比较困难,这里不过多讨论。
135+
144136
- 自定义描述语言:一般来说这个成本比较高需要自己定义语言来进行描述并进行解析,但是其扩展性,自定义个性化性都是最高。例:spring自定义了一套自己的SPEL表达式语言
145137

146138
对于泛化调用如果要自己设计的话JSON基本可以满足,如果对于个性化的需要特别多的话倒是可以自己定义一套语言。
147-
148-
### 2.7 管理平台
149-
139+
## 2.7 管理平台
150140
上面介绍的都是如何实现一个网关的技术关键。这里需要介绍网关的一个业务关键。有了网关之后,需要一个管理平台如何去对我们上面所描述的技术关键进行配置,包括但不限于下面这些配置:
151141

152142
- 限流
@@ -156,29 +146,34 @@ Netty为高并发而生,目前唯品会的网关使用这个策略,在唯品
156146
- 自定义filter
157147
- 泛化调用
158148

159-
## 3.总结
160-
149+
# 3.总结
161150
最后一个合理的标准网关应该按照如下去实现:
162151

163-
[![img](https://camo.githubusercontent.com/16eef64bd42ee7b2eb08c36039316fadb4e4d6b3/68747470733a2f2f757365722d676f6c642d63646e2e786974752e696f2f323031382f31302f33312f313636633838343136633463633232373f773d3230313326683d3130303726663d706e6726733d313532363930)](https://camo.githubusercontent.com/16eef64bd42ee7b2eb08c36039316fadb4e4d6b3/68747470733a2f2f757365722d676f6c642d63646e2e786974752e696f2f323031382f31302f33312f313636633838343136633463633232373f773d3230313326683d3130303726663d706e6726733d313532363930)
152+
![](https://user-gold-cdn.xitu.io/2018/10/31/166c88416c4cc227?w=2013&h=1007&f=png&s=152690)
164153

165-
| --- | 京东 | 唯品会 | 有赞 | 阿里 | Zuul |
166-
| -------- | ------------------------------ | ----------------------------- | ----------------------------------------------------- | ------------------------------------------------------------ | ------------------------------------------------------------ |
167-
| 实现关键 | servlet3.0 | netty | servlet3.0 | servlet3.0 | servlet3.0 |
168-
| 异步情况 | servlet异步,rpc是否异步不清楚 | 全链路异步 | 全链路异步 | 全链路异步 | Zuul1同步阻塞,Zuul2异步非阻塞 |
169-
| 限流 | --- | --- | 平滑限流。最初是codis,后续换到每个单机的令牌桶限流。 | 1.基本流控:基于API的QPS做限流。2.运营流控:支持APP流量包,APP+API+USER的流控33.大促流控:APP访问API的权重流控。阿里开源:Sentinel | 提供了jar包:spring-cloud-zuul-ratelimit。1.对请求的目标URL进行限流(例如:某个URL每分钟只允许调用多少次)。2.对客户端的访问IP进行限流(例如:某个IP每分钟只允许请求多少次)3.对某些特定用户或者用户组进行限流(例如:非VIP用户限制每分钟只允许调用100次某个API等)4.多维度混合的限流。此时,就需要实现一些限流规则的编排机制。与、或、非等关系。支持四种存储方式ConcurrentHashMap,Consul,Redis,数据库。 |
170-
| 熔断降级 | --- | --- | Hystrix | --- | 只支持服务级别熔断,不支持URL级别。 |
171-
| 隔离 | 线程池隔离 | --- | 信号量隔离 | --- | 线程池隔离,信号量隔离 |
172-
| 缓存 | redis | --- | 二级缓存,本地缓存+Codis | HDCC 本地缓存,远程缓存,数据库 | 需要自己开发 |
173-
| 泛化调用 | --- | http,https,http1,http2,二进制 | dubbo,http,nova | hsf,dubbo,http,https,http2,http1 | 只支持http |
154+
---| 京东| 唯品会| 有赞| 阿里| Zuul
155+
---|---|---|---|---|---
156+
实现关键|servlet3.0|netty|servlet3.0|servlet3.0|servlet3.0
157+
异步情况|servlet异步,rpc是否异步不清楚|全链路异步|全链路异步|全链路异步|Zuul1同步阻塞,Zuul2异步非阻塞
158+
限流 |---|---|平滑限流。最初是codis,后续换到每个单机的令牌桶限流。|1.基本流控:基于API的QPS做限流。2.运营流控:支持APP流量包,APP+API+USER的流控33.大促流控:APP访问API的权重流控。阿里开源:Sentinel|提供了jar包:spring-cloud-zuul-ratelimit。1.对请求的目标URL进行限流(例如:某个URL每分钟只允许调用多少次)。2.对客户端的访问IP进行限流(例如:某个IP每分钟只允许请求多少次)3.对某些特定用户或者用户组进行限流(例如:非VIP用户限制每分钟只允许调用100次某个API等)4.多维度混合的限流。此时,就需要实现一些限流规则的编排机制。与、或、非等关系。支持四种存储方式ConcurrentHashMap,Consul,Redis,数据库。
159+
熔断降级|---|---|Hystrix|---|只支持服务级别熔断,不支持URL级别。
160+
隔离|线程池隔离|---|信号量隔离|---|线程池隔离,信号量隔离
161+
缓存|redis|---|二级缓存,本地缓存+Codis|HDCC 本地缓存,远程缓存,数据库|需要自己开发
162+
泛化调用|---|http,https,http1,http2,二进制|dubbo,http,nova|hsf,dubbo,http,https,http2,http1|只支持http
174163

175-
## 4.参考
176164

165+
166+
# 4.参考
177167
- 京东:http://www.yunweipai.com/archives/23653.html
168+
178169
- 有赞网关:https://tech.youzan.com/api-gateway-in-practice/
170+
179171
- 唯品会:https://mp.weixin.qq.com/s/gREMe-G7nqNJJLzbZ3ed3A
172+
180173
- Zuul:http://www.scienjus.com/api-gateway-and-netflix-zuul/
181174

175+
176+
182177
## 公众号
183178

184179
如果大家想要实时关注我更新的文章以及分享的干货的话,可以关注我的公众号。

0 commit comments

Comments
 (0)