Skip to content

Commit

Permalink
feat(dist/gateway): add kong note
Browse files Browse the repository at this point in the history
  • Loading branch information
Alice52 committed Nov 1, 2023
1 parent fa0435e commit 3a2aa61
Show file tree
Hide file tree
Showing 6 changed files with 200 additions and 11 deletions.
32 changes: 32 additions & 0 deletions common/json/jackson.md
Original file line number Diff line number Diff line change
Expand Up @@ -478,9 +478,41 @@ public void testHello() throws IOException {
- Java 在编译时会在字节码里指令集之外的地方保留「部分」泛型信息
- **泛型接口**``**方法**定义上的所有泛型、`成员变量声明处`的泛型「都会」被保留类型信息,「其它地方」的泛型信息都会被擦除
- solution

- 利用成员变量保留泛型
- TypeReference<T>

```java
// it's failed: T will be HashLinkMap!!!
<T> T requestShopperTrak(String startTime, DetailEnum d) {} // TypeReference
StoreTrafficDTO dto = requestShopperTrak(startTime, DetailEnum.STORE)

// it's ok!!
<T> T requestShopperTrak(String startTime, DetailEnum d, Class<T> clazz) {} // Class
StoreTrafficDTO dto = requestShopperTrak(startTime, DetailEnum.STORE, StoreTrafficDTO.class)
```

- sample

```java
public class JsonResponse<T> {
private T result;
}
public class User {
private Long id;
private String firstName;
private String lastName;
}

// {"result":{"id":1,"firstName":"John","lastName":"Lewis"}}

TypeReference<JsonResponse<User>> typeRef = new TypeReference<JsonResponse<User>>() {};
JsonResponse<User> jsonResponse = objectMapper.readValue(json, typeRef);

JavaType javaType = objectMapper.getTypeFactory().constructParametricType(JsonResponse.class, User.class);
JsonResponse<User> jsonResponse = objectMapper.readValue(json, javaType);
```

4. tree
- 序列化
1. valueToTree(Object)
Expand Down
76 changes: 76 additions & 0 deletions dist/gateway/kong/0.install.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,76 @@
## install

1. compose

```yml
version: '3.1'
services:
kong_pgsql:
image: postgres:9.5
container_name: kong_pgsql
restart: always
environment:
POSTGRES_USER: postgres
POSTGRES_PASSWORD: Yu1252068782
POSTGRES_DB: kong
volumes:
- kong_pgsql_volume:/var/lib/postgresql/data
ports:
- 5431:5432

kong:
image: kong:2.6.0
restart: always
environment:
KONG_DATABASE: postgres
KONG_PG_HOST: kong_pgsql
KONG_PG_DATABASE: kong
KONG_PG_USER: postgres
KONG_PG_PASSWORD: Yu1252068782
KONG_PROXY_LISTEN: 0.0.0.0:8000, 0.0.0.0:8443 ssl
KONG_ADMIN_LISTEN: 0.0.0.0:8001, 0.0.0.0:8444 ssl
KONG_ADMIN_ACCESS_LOG: /dev/stdout
KONG_PROXY_ERROR_LOG: /dev/stderr
KONG_ADMIN_ERROR_LOG: /dev/stderr
#KONG_STREAM_LISTEN: 0.0.0.0:6379
depends_on:
- kong_pgsql
links:
- kong_pgsql
healthcheck:
#test: ["CMD", "curl", "-f", "http://kong:8001"]
test: ['CMD', 'kong', 'health']
interval: 5s
timeout: 2s
retries: 15
volumes:
- kong_volume:/usr/local/share/lua/5.1/kong/templatesa
ports:
- '8001:8001'
- '8000:8000'
- '8443:8443'
- 8444:8444
#- 6379:6379 # tcp forward
extra_hosts:
- 'host.docker.internal:172.17.0.1'

konga:
image: pantsel/konga:0.14.9
restart: always
environment:
DB_ADAPTER: postgres
DB_HOST: kong_pgsql
DB_DATABASE: konga
DB_USER: postgres
DB_PASSWORD: Yu1252068782
NODE_ENV: development
depends_on:
- kong
- kong_pgsql
ports:
- 1337:1337

volumes:
kong_pgsql_volume:
kong_volume:
```
79 changes: 74 additions & 5 deletions dist/gateway/kong/3.upstream.md
Original file line number Diff line number Diff line change
Expand Up @@ -9,23 +9,92 @@
- 健康检查: 主动检查 || 被动检查, 将流量转发至其它健康的 target
- 熔断: 根据健康检查的状态, 对客户端请求进行熔断, 防止后端级联服务雪崩

## 负载均衡: [hash 一致性算法](https://mp.weixin.qq.com/s/76R-JD5zWzixrBQb6WYjXQ)
## 负载均衡

1. 轮询、加权轮询、随机选择
1. 常见的路由策略

- 轮询
- 加权轮询
- 随机选择
- 一致性 hash: none(则使用轮询)/consumer/ip/header/cookie
- *当前*最少连接
- *总计*最少次数
- \_
- 最不经常使用(lru)
- 最近最久未使用(lfu)
- 故障转移
- 忙碌转移
- 第一个
- 最后一个

2. [hash 一致性算法](https://mp.weixin.qq.com/s/76R-JD5zWzixrBQb6WYjXQ)

### DNS 负载均衡

1. 核心(本质): 域名解析, 将域名解析为 A || srv || 线路类型(同一域名在不同线路下解析到不能 IP 服务)
2. A 记录
- 一个 A 记录映射到一个或多个 IP 地址+权重
- 解析到某条记录的比例为: 该条记录权重 ÷ 该线路所有记录权重之和
3. srv: `优先级 权重 端口 主机名`
- 一个 srv 记录映射到一个或多个 IP 地址
- `5 0 5269 xx.google.com.`
4. DNS 优先级

```mermaid
graph LR
A(先前解析的最后一个成功类型) --> B(SRV记录)
B(SRV记录) --> C(A记录)
C(A记录) --> D(CNAME记录)
```

### 环形均衡器: Ring-balancer

1. 核心: 由 Kong(配置 upstream 和 target) 充当服务注册中心, 通过槽位和权重在 target 间负载
2. **每个 upstream 都有自己的环形均衡器**和多个 target(通过一个 HTTP 请求被添加/删除节点)
- 一个环形均衡器有一个最大的预定义槽位数, 根据 target 权重分配槽位: `权重最好是倍数关系(方便均衡器性能)`
- 在均衡器中, 从 1 到 slots **随机**地分布在环上
- 当插槽数量发生变化时需要重建均衡器
3. rb 可以再单节点和集群种使用: 所有节点都要建立完全相同的环形均衡器, 以确保它们都能正常工作
- 轮询算法时没有区别
- hash 时则一定要使用 Ip 而不是域名

## 健康检查

1. 主动检查
2. 被动检查
1. 主动检查: 定期请求 target 中的特定 HTTP 或 HTTPS 端点, 并根据其响应确定 target 的健康状况

- 主动健康检查目前只支持 HTTP/HTTPS, 且时间间隔设置为 0 则表示禁用检查
- pros: 主动健康检查可以在 target 恢复健康时, 自动重新启用环形均衡器中的 target + 可以恢复被动检查导致的不健康
- cons: 主动健康检查会对 target 产生额外的流量 + 且需要指定端点

2. 被动检查: 断路器, 分析代理的流量并根据其响应确定 target 的健康状况(且无法自动恢复健康)

- nginx 会监测代理的请求并根据响应状态决定是否转发流量到改服务
- nginx 的上游服务的响应状态在短时间内累计一定的失败次数时, 会将其标记该服务器异常: 然后就不会转发流量给该服务器
- nginx 每隔一段时间还是会转发少量的一些请求给该后端服务器来探测它的返回状态: 以便识别该服务器是否恢复正常

3. **主动检查&被动检查 最佳实践: 可以启用被动健康检查, 仅根据其流量监测目标的健康状况, 只在目标不健康时使用主动健康检查, 以便自动重新启用它**
4. 健康检查仅对活动目标进行操作, 不会修改 Kong 数据库中 target 的活动状态
5. 不健康的目标不会从负载均衡器中删除, 因此在使用 hash 算法时不会对均衡器布局产生任何影响(它们只会被跳过)
6. upstream 也有健康概念: upstream 的健康状况取决于其 target 的状态
- healthchecks.threshold=55: 权重的百分比
- ups 进入不健康的状态, upstream 将只返回错误: target 恢复时, 环形均衡器的健康状态将自动更新

## target: host+port+weight

## target
1. 当不活跃的条目比活跃的条目多 10 倍时, target 将被自动清理: 此时 rb 会重建(代价比较大)
2. 健康检查器会根绝健康检查更新一系列的内部计数器
- 如果连接失败, 则增加 target 的 TCP 失败计数器并清除成功计数器
- 如返回健康的状态码, 则增加 target 的成功计数器并清除其所有其他计数器
- 如返回不健康的状态码, 则增加 target 的 HTTP 失败计数器并清除成功计数器
- 如果超时, 它将增加 target 的超时计数器并清除成功计数器
3. 健康的定义
- 健康信息不会在集群中同步, 每个 Kong 节点分别确定其目标的健康状况
- 不健康: 任何 TCP 失败、HTTP 失败或超时计数器达到其配置的阈值, target 都不可用时会返回 503
- 健康: 成功计数器达到其配置的阈值

---

## reference

1. https://www.jianshu.com/p/b44400618c69
2. https://github.com/Alice52/diagrams/blob/master/diagrams/lb/nginx/conf/03.upstream.svg
20 changes: 16 additions & 4 deletions dist/gateway/kong/readme.md
Original file line number Diff line number Diff line change
Expand Up @@ -4,6 +4,14 @@

![avatar](/static/image/dist/gateway/kong-flow.png)

1. ecology: `kong gateway Server + Apache Cassandra/PostgreSQL + Kong Manager/Konga`

- Kong Admin API: kong 内容配置(restful api)
- Kong Manager/Konga
- Kong Dev Portal: 二次开发/管理 API 版本
- Kong Vitals: Gateway 节点的健康性能指标, 是 Kong Manager 用户界面的一部分
- Kong Gateway plugins

## deploy

## config: `Route >> Service >> Upstream >> Target`
Expand All @@ -13,7 +21,7 @@
3. upstream: 上游服务, 实现负载
4. target: upstream 负载下的每个节点(物理服务 | ip + port 的抽象)
5. consumer: 代表用户或应用(核心原则是可以为其添加插件)
6. plugin
6. plugins

## plugins 开发

Expand All @@ -26,6 +34,10 @@
## reference

1. https://zhuanlan.zhihu.com/p/577842078
2. https://github.com/micro-services-roadmap/roadmap/issues/5
3. https://blog.csdn.net/lgxzzz/article/details/121683302
4. https://cloud.tencent.com/developer/article/2301049
2. https://www.jianshu.com/p/b44400618c69
3. https://github.com/micro-services-roadmap/roadmap/issues/5
4. https://blog.csdn.net/lgxzzz/article/details/121683302
5. https://cloud.tencent.com/developer/article/2301049
6. https://mp.weixin.qq.com/s/O2N2ucFLn3vF67RK_aP0UA
7. https://blog.csdn.net/zz18435842675/article/details/122449579
8. [kong logstash](https://blog.csdn.net/why_still_confused/article/details/89244200)
2 changes: 1 addition & 1 deletion job
2 changes: 1 addition & 1 deletion rpc/grpc

0 comments on commit 3a2aa61

Please sign in to comment.