mirror of
https://github.com/sogou/workflow.git
synced 2026-10-17 04:31:07 +08:00
Merge pull request #775 from holmes1412/master
update about-upstream.md
This commit is contained in:
+15
-6
@@ -3,7 +3,10 @@
|
||||
在nginx里,Upstream代表了反向代理的负载均衡配置。在这里,我们扩充Upstream的含义,让其具备以下几个特点:
|
||||
1. 每一个Upstream都是一个独立的反向代理
|
||||
2. 访问一个Upstream等价于,在一组服务/目标/上下游,使用合适的策略选择其中一个进行访问
|
||||
3. Upstream具备负载均衡、出错处理和服务治理能力
|
||||
3. Upstream具备负载均衡、出错处理、熔断和其他服务治理能力
|
||||
4. 对于同一个请求的多次重试,Upstream可以避开已试过的目标
|
||||
5. 通过Upstream可以对不同下游配置不同的连接参数
|
||||
6. 动态增删目标地址实时生效,方便对接任意的服务发现系统
|
||||
|
||||
### Upstream相对于域名DNS解析的优势
|
||||
|
||||
@@ -16,7 +19,11 @@ Upstream和域名DNS解析都可以将一组ip配置到一个Host,但是
|
||||
### Workflow的Upstream
|
||||
|
||||
这是一个本地反向代理模块,代理配置对server和client都生效。
|
||||
代理支持动态配置。代理名不包括端口,但代理请求支持指定端口。
|
||||
|
||||
支持动态配置,可用于服务发现系统,目前[workflow-k8s](https://github.com/sogou/workflow-k8s)可以对接Kubernetes的API Server。
|
||||
|
||||
Upstream名不包括端口,但Upstream请求支持指定端口(如果使用非内置协议,Upstream名暂时需要加上端口号以保证构造时的解析成功)。
|
||||
|
||||
每一个Upstream配置自己的独立名称UpstreamName,并添加设定着一组Address,这些Address可以是:
|
||||
1. ip4
|
||||
2. ip6
|
||||
@@ -127,10 +134,11 @@ http_task->start();
|
||||
~~~
|
||||
基本原理
|
||||
1. 每1个main视为16个虚拟节点
|
||||
2. 框架会使用std::hash对所有节点的address+虚拟index进行运算,作为一致性哈希的node值
|
||||
2. 框架会使用std::hash对所有节点的address+虚拟index+此address加到此upstream的次数进行运算,作为一致性哈希的node值
|
||||
3. 框架会使用std::hash对path+query+fragment进行运算,作为一致性哈希data值
|
||||
4. 每次都选择存活node最近的值作为目标
|
||||
5. 对于每一个main、只要有存活group内main/有存活group内backup/有存活no group backup,即视为存活
|
||||
6. 如果upstream_add_server()时加上AddressParams,并配上权重weight,则每1个main视为16 * weight个虚拟节点,适用于带权一致性哈希或者希望一致性哈希标准差更小的场景
|
||||
|
||||
### 例4 自定义一致性哈希函数
|
||||
~~~cpp
|
||||
@@ -249,7 +257,7 @@ http_task->start();
|
||||
6. 添加目标的默认组号-1,type为0,表示主节点。
|
||||
|
||||
### 例8 NVSWRR平滑按权重选取策略
|
||||
~~~
|
||||
~~~cpp
|
||||
UpstreamManager::upstream_create_vnswrr("nvswrr.random");
|
||||
|
||||
AddressParams address_params = ADDRESS_PARAMS_DEFAULT;
|
||||
@@ -328,7 +336,7 @@ static constexpr struct AddressParams ADDRESS_PARAMS_DEFAULT =
|
||||
* dns_ttl_default:dns cache中默认的ttl,单位秒,默认12小时,dns cache是针对当前进程的,即进程退出就会消失,配置也仅对当前进程有效
|
||||
* dns_ttl_min:dns最短生效时间,单位秒,默认3分钟,用于在通信失败重试时是否进行重新dns的决策
|
||||
* max_fails:触发熔断的【连续】失败次数(注:每次通信成功,计数会清零)
|
||||
* weight:权重,默认1,仅对main有效,用于Upstream随机策略选取,权重越大越容易被选中;其他策略下此参数无意义
|
||||
* weight:权重,默认1,仅对main有效,用于Upstream随机策略选取和一致性哈希选取,权重大越容易被选中
|
||||
* server_type:主备配置,默认主。无论什么时刻,同组的主优先级永远高于其他的备
|
||||
* group_id:分组依据,默认-1。-1代表无分组(游离),游离的备可视为任何主的备,有组的备优先级永远高于游离的备。
|
||||
|
||||
@@ -348,7 +356,8 @@ static constexpr struct AddressParams ADDRESS_PARAMS_DEFAULT =
|
||||
## 熔断机制
|
||||
|
||||
当某一个目标的错误or异常触达到预先设定的阈值条件时,暂时认为这个目标不可用,剔除目标,即熔断开启进入熔断期
|
||||
在熔断持续时间达到MTTR时长后,熔断关闭,(尝试)恢复目标
|
||||
在熔断持续时间达到MTTR时长后,会进入半熔断状态,(尝试)恢复目标
|
||||
如果恢复的时候发现其他所有目标都被熔断,会同一时间把所有目标恢复
|
||||
熔断机制策略可以有效阻止雪崩效应
|
||||
|
||||
## Upstream熔断保护机制
|
||||
|
||||
@@ -4,11 +4,14 @@ In nginx, Upstream represents the load balancing configuration of the reverse pr
|
||||
|
||||
1. Each Upstream is an independent reverse proxy
|
||||
2. Accessing an Upstream is equivalent to using an appropriate strategy to select one in a group of services/targets/upstream and downstream for access
|
||||
3. Upstream has load balancing, error handling and service governance capabilities.
|
||||
3. Upstream has load balancing, error handling, circuit breaker and other service governance capabilities
|
||||
4. For multiple retries of the same request, Upstream can avoid addresses that already tried
|
||||
5. Different connection parameters can be configured for different addresses through Upstream
|
||||
6. Dynamically adding/removing target will take effect in real time, which is convenient for any service discovery system
|
||||
|
||||
### Advantages of Upstream over domain name DNS resolution
|
||||
|
||||
Both upstream and domain name DNS resolution can configure a group of ip to a host, but
|
||||
Both Upstream and domain name DNS resolution can configure a group of ip to a host, but
|
||||
|
||||
1. DNS domain name resolution doesn’t address port number. The service DNS domain names with the same IP and different ports cannot be configured together; but it is possible for Upstream.
|
||||
2. The set of addresses corresponding to DNS domain name resolution must be ip; while the set of addresses corresponding to Upstream can be ip, domain name or unix-domain-socket
|
||||
@@ -19,7 +22,9 @@ Both upstream and domain name DNS resolution can configure a group of ip to a ho
|
||||
|
||||
This is a local reverse proxy module, and the proxy configuration is effective for both server and client.
|
||||
|
||||
Proxy supports dynamic configuration. Proxy name does not include port, but proxy request supports specified port.
|
||||
Support dynamic configuration and available for any service discovery system. Currently, [workflow-k8s](https://github.com/sogou/workflow-k8s) can be used to acquire Pods information from the API server of Kubernetes.
|
||||
|
||||
Upstream name does not include port, but upstream request supports specified port. (However, for non-built-in protocols, Upstream name temporarily needs to be added with the port to ensure parsing during construction).
|
||||
|
||||
Each Upstream is configured with its own independent name UpstreamName, and a set of Addresses is added and set. These Addresses can be:
|
||||
|
||||
@@ -149,10 +154,11 @@ http_task->start();
|
||||
Basic principles
|
||||
|
||||
1. Each main server is regarded as 16 virtual nodes
|
||||
2. The framework will use std::hash to calculate the address + virtual index of all nodes as the node value of the consistent hash
|
||||
2. The framework will use std::hash to calculate "the address + virtual index of all nodes + the number of times for this address to add into this Upstream" as the node value of the consistent hash
|
||||
3. The framework will use std::hash to calculate path + query + fragment as a consistent hash data value
|
||||
4. Choose the value nearest to the surviving node as the target each time
|
||||
5. For each main, as long as there is a main in surviving group, or there is a backup in surviving group, or there is a surviving no group backup, it is regarded as surviving
|
||||
6. If weight on AddressParams is set with upstream_add_server(), each main server is regarded as 16 * weight virtual nodes. This is suitable for weighted consistent hash or shrinking the standard deviation of consistent hash
|
||||
|
||||
### Example 4 User-defined consistent hash function
|
||||
|
||||
@@ -280,7 +286,7 @@ Basic principles
|
||||
6. Add the default group number -1 of the target, and the type is main
|
||||
|
||||
### Example 8 NVSWRR selection weighting strategy
|
||||
~~~
|
||||
~~~cpp
|
||||
UpstreamManager::upstream_create_vnswrr("nvswrr.random");
|
||||
|
||||
AddressParams address_params = ADDRESS_PARAMS_DEFAULT;
|
||||
@@ -303,7 +309,7 @@ http_task->start();
|
||||
When the URIHost of the url that initiates the request is filled with UpstreamName, it is regarded as a request to the Upstream corresponding to the name, and then it will be selected from the set of Addresses recorded by the Upstream:
|
||||
|
||||
1. Weight random strategy: selection randomly according to weight
|
||||
2. Consistent hashing strategy: The framework uses a standard consistent hashing algorithm, and users can define the consistent hash function consistent_hash for the requested uri
|
||||
2. Consistent hash strategy: The framework uses a standard consistent hashing algorithm, and users can define the consistent hash function consistent_hash for the requested uri
|
||||
3. Manual strategy: make definite selection according to the select function that user provided for the requested uri, if the blown target is selected: **a.** If try_another is false, this request will return to failure **b.** If try_another is true, the framework uses standard consistent hash algorithm to make a second selection, and the user can define the consistent hash function consistent_hash for the requested uri
|
||||
4. Main-backup strategy: According to the priority of main first, backup next, select a main server as long as it can be used. This strategy can take effect concurrently with any of [1], [2], and [3], and they influence each other.
|
||||
|
||||
@@ -360,7 +366,7 @@ Each address can be configured with custom parameters:
|
||||
* dns_ttl_default: The default ttl in the dns cache in seconds, and the default value is 12 hours. The dns cache is for the current process, that is, the process will disappear after exiting, and the configuration is only valid for the current process
|
||||
* dns_ttl_min: The shortest effective time of dns in seconds, and the default value is 3 minutes. It is used to decide whether to perform dns again when communication fails and retry.
|
||||
* max_fails: the number of [continuous] failures that triggered fusing (Note: each time the communication is successful, the count will be cleared)
|
||||
* Weight: weight, the default value is 1, which is only valid for main. It is used for Upstream random strategy selection, the larger the weight is, the easier it is to be selected; this parameter is meaningless under other strategies
|
||||
* Weight: weight, the default value is 1, which is only valid for main. It is used for Upstream weighted random strategy selection and consistent hash strategy selection, the larger the weight is, the easier it is to be selected.
|
||||
* server_type: main/backup configuration, main by default (server_type=0). At any time, the main servers in the same group are always at higher priority than backups
|
||||
* group_id: basis for grouping, the default value is -1. -1 means no grouping (free). A free backup can be regarded as backup to any main server. Any backup with group is always at higher priority than any free backup.
|
||||
|
||||
@@ -383,7 +389,9 @@ As the fault is repaired, the effect will disappear, so the duration of the effe
|
||||
|
||||
When the error or abnormal touch of a certain target meets the preset threshold condition, the target is temporarily considered unavailable, and the target is removed, namely fuse is started and enters the fuse period
|
||||
|
||||
After the fuse duration reaches MTTR duration, the fuse is closed, (attempt to) restore the target
|
||||
After the fuse duration reaches MTTR duration, turn into half-open status, (attempt to) restore the target
|
||||
|
||||
If all targets are found fused whenever recovering one target, all targets will be restored at the same time
|
||||
|
||||
Fuse mechanism strategy can effectively prevent avalanche effect
|
||||
|
||||
|
||||
Reference in New Issue
Block a user