这是一个创建于 934 天前的主题，其中的信息可能已经有所发展或是发生改变。
就是把所有的服务分成 AB 两组，
平常流量随机进入 AB ，A 组服务也能调用 B 组服务。
在发布的特定时间段，AB 互相隔绝，做到先发布 A 组再发布 B 组。
平常流量随机进入 AB ，A 组服务也能调用 B 组服务。
在发布的特定时间段，AB 互相隔绝，做到先发布 A 组再发布 B 组。
51 条回复 • 2022-04-21 12:45:02 +08:00
 |
1
minmini 2022-04-19 09:59:58 +08:00
service mesh?
|
 |
2
armyHcz 2022-04-19 10:03:39 +08:00
这不就是 service 的流量分配吗,类似 nginx 的负载均衡
|
 |
5
helone 2022-04-19 10:08:29 +08:00
istio
|
 |
6
hwdef 2022-04-19 10:09:46 +08:00  1
平常用 service ，特定时段用 networkpolicy?
|
 |
8
rushssss 2022-04-19 10:55:42 +08:00 2
只用原生 service 实现的话，可以考虑 A 、B 两组服务打上两组标签，如 service=backend,group=a; service=backend,group=b
建立一个 svc ，平时 selecor 只指定 service=backend 就行，这样 AB 两组都会被选择到 需要的时候增加 selector 的条件，即可实现流量到指定的 group |
 |
10
zhanggg 2022-04-19 11:08:12 +08:00
ingress + service selector + networkpolicy 组合试试
|
 |
11
FullBridgeRect 2022-04-19 11:17:08 +08:00
@pigmen 可能想表达 iptables ？用过是有明显损耗，但不至于不行吧
|
 |
12
NathanInMac 2022-04-19 11:19:20 +08:00
就楼主说的这点需求 nginx 也能做到
|
 |
14
idblife OP |
|
15
idblife OP @NathanInMac
求 nginx 指教 |
 |
16
binfengxy 2022-04-19 11:23:05 +08:00
性能垃圾? 性能不是现在很多服务最后才考虑的事情么？ XD
|
|
19
binfengxy 2022-04-19 11:41:27 +08:00
关键是需求怎么定吧？感觉这个比较难根据实际弄清楚
下面是我当时做灰度发布时候定的初始目标，然后 pipeline 按这个要求去改. 发出来大家讨论一下，希望多多给建议，谢谢！ 需要达成的目标 1. 可以手动指定某个老版本和最新版本同时发布在生产环境中； 2. 实现发布新版本时，让测试人员对新版本进行线上测试，普通用户依旧访问老版本； 3. 可以灵活控制新老版本的访问流量比例及运行服务器副本（ pod ）数量； 4. 保证同一个用户持续稳定访问一个版本，而不是首次请求新版本，后面可能请求老版本导致 404 等错误； 5. 在一个项目中，需要在部署环境中存在 2 个不同版本的发布； 6. 1 个版本为当前提交并打 tag 的 image 版本，另一个版本为指定的 tag 且发布成功的 image 版本（若不指定则默认为上个 tag 对应的 image 版本）； 7. 确保当前版本号和指定的版本号以变量的方式注入到对应的发布版本 image 中； |
 |
20
Hanggi 2022-04-19 12:28:44 +08:00
istio 性能垃圾？头一回听。
我们这边生产环境，不算 replica 几十个服务统一 istio 管理流量。 服务底层都是 envoy 做转发，怎么会有性能问题，还是再看看是不是你配置有问题。 Istio 是正解。 |
 |
22
strawberryBug 2022-04-19 13:45:11 +08:00 via Android
没懂你说的 istio 导致的性能损耗是指什么？ envoy 转发带来的请求响应时长增加吗？
|
 |
23
eudore 2022-04-19 14:10:01 +08:00
istio 性能垃圾+1
|
|
24
Hanggi 2022-04-19 14:47:04 +08:00
@idblife 你这人真有意思啊，才几十个服务，replica 都算上不就几百个了吗？
你在这里喊 Istio 性能垃圾，你把你的 Benchmark 发出来，内部运转的 profile 结果打出来给大家瞧瞧呗？ 怎么，还等别人给你分析你的集群里的 Istio 为啥性能很垃圾吗？ |
 |
25
gengchun 2022-04-19 15:03:26 +08:00
istio 本身我不是太喜欢。推广做得确实是比较优秀的。
不过运维大点规模服务的系统，一年至少化掉几百万小一千万吧，都是厂商求着给你做的。就这连优化 istio 也做不到的话，做 AB 分发这种基础需求还需要在 v 站上讨论，未免太不靠谱了。 这种基本上都要基于特定的版本和生态环境讨论。真的生产上组件和版本的选取也不是想怎么来都行的。厂商一般都是谈生意的时候，顺便帮你整个方案。谁没事会在 v 站上讨论这些？ OP 给的信息也过少。不会是哪个集成商在 v 站这里薅出一个方案文档？感觉可能是甲方上过一个 istio 失败了。所以这次不能用 istio 了。 就算在这里拿了个方案，感觉让 OP 实施，失败的概率还是过高。 |
|
26
idblife OP @Hanggi
不知道你哪里来的自信，几十个服务 几百个 replica 听起来不小了，但是你做过 benchmark 吗？ 我们是十几个集群，每个集群几百个服务，几千个 replica ，istio 带来的性能损耗在 10%左右，这还是我们调优后的性能。 |
|
28
idblife OP |
|
29
gengchun 2022-04-19 15:31:08 +08:00
@idblife istio 大部分在 L7 算简单的，linkerd 估计更找不到方案，不然就是让开发在框架上做，还有就是 k8s 的网络插件上做。都是比优化 istio 更复杂，而且用的人更少，istio10% 看具体需求。我觉得还能再争取一下，但要再省，也就这三条路了。你确定真的需要，我只是假设从 8% 降到 1% 吗？追求这指标的成本是指数级增长的。
|
|
30
Hanggi 2022-04-19 15:31:28 +08:00
@idblife
听你这么一说更不觉得是 Istio 的性能问题了，是你们服务架构设计本身就有问题。 你标题问的就是怎么做 AB 分流，主流答案就是 Service Mesh 。 你觉得 Istio 性能有问题是你们本身设计有问题，不知道你哪儿来的自信说 Istio 垃圾。 （你起码把你的服务场景、workload 、具体响应时间长的原因说出来，证明是 Istio 或者 Envoy 本身有什么，那还听得过去。就一句 Istio 垃圾，怎么听都觉得你的机会来了啊，是不是摩拳擦掌要做个性能爆炸的 Service Mesh 服务呢？不是的话就好好设计一下你们的服务架构。） |
|
31
idblife OP |
|
32
idblife OP |
 |
33
BraveRBT 2022-04-19 16:49:51 +08:00
可以在 k8s 里装个 APISIX,作为 ingress-controller.
这样做策略路由和标签路由就都没问题了,流量也不需要到 SVC 可以直接到 POD. |
 |
35
pepesii 2022-04-19 17:19:14 +08:00
抱着学习的态度，如果最后解决了也分享下过程和方案吧 :)
就单纯的流量隔离的话，我感觉就 networkpolicy 就可以了呀； |
|
37
gengchun 2022-04-19 17:37:30 +08:00
@idblife istio 或者说 service mesh 的核心，其实是一堆 CRD ，算是定义流量怎么走的一个标准——telemetry 这些暂时不讨论——相当于 nginx.conf 语法的东西。
原生 service 功能太少，ingress 功能多一些，但是肯定有 api 的。api 你过一次，无论是 nginx 还是 envoy 都意味着延迟增加。 简单的说，一切都是砍需求。当然，要流量分发，不太可能砍到连 envoyproxy 都不要了，至少目前为止，网络插件还没有普及。但是还是可能减少流量通过 envoyproxy 这种的次数。需求砍到一定程度，istio 去掉你觉得不必要的功能，也就差不多了。 |
 |
38
anubu 2022-04-19 17:58:27 +08:00
8 楼的方法应该能解决问题，也很直观。大规模使用的话，可以封装一下。
没有 istio 使用经验，不过就接触到新闻和信息，istio 的确性能不太好，并且持续很久了。 |
 |
39
pipixia 2022-04-19 18:36:33 +08:00 via Android
Istio 边车那套真不喜欢
|
 |
40
calmzhu 2022-04-19 18:38:34 +08:00
没 Get 到需求.
发布的话, 探针停一半不就可以了 |
|
41
calmzhu 2022-04-19 18:50:13 +08:00
是指灰度发布这种效果吗? https://help.aliyun.com/document_detail/200941.html
|
 |
42
raptor 2022-04-20 10:53:38 +08:00
搭车问一下，consul 比 istio 如何？
|
 |
43
tanxnative 2022-04-20 11:26:06 +08:00
10%的性能损失,带来的语言无关特性
其实你使用其他框架也会有性能损失 |
|
44
idblife OP @tanxnative
如果用 k8s 里 service 标签来实现呢？ |
 |
46
morphyhu 2022-04-20 16:54:03 +08:00
talk is cheap,show me the data.
"@idblife istio 可以做到，但是性能垃圾" |
 |
47
zmal 2022-04-20 18:12:22 +08:00
性能损耗是必然的啊。真要说起来，容器化虚拟化技术本来就都有性能损耗。
|
|
48
idblife OP |
|
50
tanxnative 2022-04-21 11:16:19 +08:00
我猜你服务没有治理, 有很多同步的调用, 还不止一跳
|
|
51
idblife OP @tanxnative
进行过指定接口的测试，确保调用链时合理的。 |
Select Language