TCM同城双活设计方案
原创
TCM能力概述
架构概述
上篇文章，讲述了接入层高可用设计，这篇文章我们聊聊TCM。TCM是腾讯云提供的微服务流量治理云产品，100% 兼容支持 Istio API，TCM 与腾讯云基础设施原生集成，提供全托管服务化的支撑能力，轻松保障和管理网格生命周期。
简易架构如下图：
腾讯云托管网格主要是增强了Control plane，默认与腾讯云基础设施集成，如CLB(负载均衡)、APM(应用性能监控)、TMP(Prometheus)、CLS(日志服务)、TKE(容器服务)等，用户无需配置即可用原生方式使用服务网格。
托管网格的跨区可用性
托管网格的控制面，部署在对所有云用户不可见的TKE集群。
TKE集群内node来自多可用区，同时通过反亲和性配置，保证同一个用户的控制面进程在不同的可用区，从而实现了部署层面的高可用。
同时，基于TKE集群本身的健康检查机制等，保证了进程的高可用
TCM详细资料参考：https://cloud.tencent.com/document/product/1261/62928
架构设计方案
同城双活需求分析
使用了TCM产品，只需要考虑数据面的高可用建设，即业务程序的同城双活。
这种架构模式下，有两个技术点需要解决：
- 接入层的流量负载均衡
- 逻辑层的set部署，即可用区内流量闭环
设计方案
适合上面同城双活的集群部署模式，如下图一、图二所示。
图一代表一个服务网格 + 一个TKE集群的部署模式，TKE集群的Node节点分布在两个可用区
图二代表一个服务网格 + 两个TKE集群的部署模式，一个TKE的node节点分布在上海四区，另一个TKE的node节点分布在上海五区。
图一 图二
建设要求 | 一个服务网格+一个TKE集群 | 一个服务网格+两个TKE集群 |
|---|---|---|
部署模式 | 承载双活业务的node节点在两个可用区内平均分布保证在一个可用区内pod>=2副本 | 保证在一个TKE集群内>=2副本 |
反亲和性 | 配置避免同区、同node的反亲和性配置(preferred模式) | 配置避免同node的反亲和性配置(preferred模式) |
就近接入能力 | 网格默认能力 | 网格默认能力 |
failover能力 | 需配置outlierDetection | 需配置outlierDetection |
原理分析
就近接入能力
istio本身会参考Region/Zone/Sub-zone这个三元组来决定就近调度。
Region来源：对应云的地域，从k8s node节点label中获取，key是 topology.kubernetes.io/region
Zone来源：对应云的可用区，从k8s node节点label中获取，key是topology.kubernetes.io/zone
Sub-zone来源：istio自定义的，用来定义比可用区更细的调度单元，需用户按需给node节点打label topology.istio.io/subzone
计算就近的顺序是Region、Zone、Sub-zone。
比如一个服务网格+一个TKE集群场景，流量进入四区的istio-gateway后，只会调用四区的Service A，依此类推。
默认情况下，该能力是关闭的，即流量进入四区的istio-gateway后，会在四区、五区的Service A轮询，如需使用，需开启异常检测能力，即配置outlierDetection流量管理功能，参考配置如下：
spec:
host: stock
trafficPolicy:
outlierDetection:
consecutiveErrors: 5
interval: 10000ms
baseEjectionTime: 30000ms
maxEjectionPercent: 10
minHealthPercent: 50failover能力
就近接入能力开启后，那就面临一个问题，如果就近区域的服务全部不可用，如何failover呢？
实际是通过envoy endpoints中的priority参数来控制，不设置默认是0。
在大于两个单元的场景，failover的顺序是按0>1>2的顺序来转移。
细节参考文档：Locality Weighted Load Balancing — envoy tag-v1.23.0 documentation
相关配置分析
调用链路
如果流量是从四区的istio gateway进入，那么访问product时，链路会是istio gateway --> frontend --> product，且都在四区，反之亦然。
配置情况
下面是一个服务网格+一个TKE集群场景下ingress-gateway的endpoint配置，172.16.0.38 locality为zone: "200005"
- addedViaApi: true
hostStatuses:
- address:
socketAddress:
address: 172.16.1.124
portValue: 80
healthStatus:
edsHealthStatus: HEALTHY
locality:
region: sh
zone: "200004"
weight: 1
- address:
socketAddress:
address: 172.16.0.38
portValue: 80
healthStatus:
edsHealthStatus: HEALTHY
locality:
region: sh
zone: "200005"
weight: 1
name: outbound|80||istio-ingressgateway.istio-system.svc.cluster.local
observabilityName: outbound|80||istio-ingressgateway.istio-system.svc.cluster.localfrontend的endpoint配置，172.16.0.37 locality为zone: "200005"
- addedViaApi: true
hostStatuses:
- address:
socketAddress:
address: 172.16.0.37
portValue: 80
healthStatus:
edsHealthStatus: HEALTHY
locality:
region: sh
zone: "200005"
weight: 1
- address:
socketAddress:
address: 172.16.1.120
portValue: 80
healthStatus:
edsHealthStatus: HEALTHY
locality:
region: sh
zone: "200004"
priority: 1
weight: 1
name: outbound|80||frontend.base.svc.cluster.local
observabilityName: outbound|80||frontend.base.svc.cluster.localpronduct的endpoint配置，172.16.0.36 locality为zone: "200005"
- addedViaApi: true
hostStatuses:
- address:
socketAddress:
address: 172.16.0.36
portValue: 7000
locality:
region: sh
zone: "200005"
weight: 1
- address:
socketAddress:
address: 172.16.1.119
portValue: 7000
locality:
region: sh
zone: "200004"
priority: 1
weight: 1
name: outbound|7000||product.base.svc.cluster.local
observabilityName: outbound|7000||product.base.svc.cluster.local结果验证
从调用链来看，确实实现了就近接入，且与上面配置一致：
从前端界面来看，相关请求都到了五区。
原创声明：本文系作者授权腾讯云开发者社区发表，未经许可，不得转载。
如有侵权，请联系 cloudcommunity@tencent.com 删除。
原创声明：本文系作者授权腾讯云开发者社区发表，未经许可，不得转载。
如有侵权，请联系 cloudcommunity@tencent.com 删除。
腾讯云开发者
