V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
• 请不要在回答技术问题时复制粘贴 AI 生成的内容
Charlie17Li
V2EX  ›  程序员

[服务网格] 服务网格似乎没那么必要上?

  •  
  •   Charlie17Li · 75 天前 · 2604 次点击
    这是一个创建于 75 天前的主题,其中的信息可能已经有所发展或是发生改变。

    前言

    接触 servicemesh 有一段时间了,越来越觉得这个东西在当前场景下是个可有可无的东西。

    于是问了下 GPT ,servicemesh 解决了啥问题,以下是他的回答以及我的想法:

    1.服务发现和负载均衡 在微服务架构中,服务实例可能会动态增加或减少。Service Mesh 负责服务发现和负载均衡,确保请求能够被路由到健康的实例上。

    事实上,公司里有非常可靠的注册中心(独立团队维护),这个部分根本用不到 Service Mesh 。

    2.安全性 Service Mesh 提供了服务间通信的安全性,包括加密、认证和授权。例如,它可以通过 mTLS ( Mutual TLS )来确保服务间通信的加密和身份验证。

    事实上,公司里使用很多私有协议,而且安全这块也有单独的团队。

    3.可观察性 Service Mesh 提供了对服务间通信的详细监控和跟踪,包括请求的延迟、错误率和流量分布等。这有助于快速诊断和解决问题。

    这个我理解,常规的分布式链路工具就能做这个

    4.流量管理 Service Mesh 可以实现复杂的流量管理策略,例如熔断、限流、重试和超时等。这有助于提高系统的稳定性和可靠性。

    熔断限流或许可以,但是流量代理私自做重试显然会有潜在幂等性等问题,没必要放在这里做

    5.故障注入和测试 Service Mesh 允许在生产环境中进行故障注入和测试,以验证系统的鲁棒性和容错能力。这有助于提前发现潜在问题。

    这一块了解不多,但是我理解 Service mesh 能过的故障注入应该很有限,Linux 有成熟的网络注入工具 TC ,公司里有很成熟的故障注入工具,包括但不限于网络故障注入

    6.策略管理 Service Mesh 提供了一个集中化的地方来管理和应用各种策略,例如安全策略、流量管理策略和访问控制策略等。

    算优点吧,但也是致命的缺点,当前应用规模非常大,Istio 的控制面就算抗的住,一旦 Crash 问题影响很大

    7.平台无关性 Service Mesh 独立于应用代码,这意味着你可以在不同的编程语言和框架中使用它,而无需修改代码。这使得它特别适合多语言、多框架的微服务环境。

    这一点比较困惑,只要预定好通信协议,应该就没有这个问题。Service Mesh 顶多就是做协议转换,事实上,公司里开发基座基本是统一的,协议转换完全可以在基座中实现。

    综上所述,Service Mesh 在上述提到的场景里,完全没有必要上,硬上还有风险,此外还要占用额外的 CPU 等资源

    大家场景里,ServiceMesh 有什么刚需场景吗

    24 条回复    2024-10-13 11:04:28 +08:00
    povsister
        1
    povsister  
       75 天前   ❤️ 1
    适合超大规模的条件下,业务和机架分离。
    举个例子,DB 访问,缓存中间件访问,服务发现,trace 等等这些东西全在 sidecar 里,鸡架更新对于业务完全无感。
    dk7952638
        2
    dk7952638  
       75 天前
    项目可能完全没必要上,但面试的时候必须上,大上特上!
    yichya
        3
    yichya  
       75 天前   ❤️ 2
    如果贵司已经是这也有那也有了的话那当然是没必要硬上。。。但是 mesh 的技术中立好处在于,在其上引入一套新的技术栈(包括对应的实现:服务发现、内网通信、tracing 、熔断 / 限流等日常治理之类)都几乎不需要侵入到业务中,如果用传统的方式开发的话需要基础架构提供一整套对应技术栈需要的 SDK ,这种对于技术栈很复杂的情况会很有意义
    yannxia
        4
    yannxia  
       75 天前
    ServiceMesh 本身不是刚需产品,整体上还是偏向于过渡态的,比如现在团队很杂,没有统一的 SDK ,有些调度策略没办法统一实现,那么 ServiceMesh 就很有必要,可以帮你解决问题,但是如果团队基建都很 Nice ,那确实不需要。
    这是一个量体裁衣的事情。
    zaunist
        5
    zaunist  
       75 天前
    如果需要晋升,那就大上特上
    Charlie17Li
        6
    Charlie17Li  
    OP
       75 天前 via iPhone
    @povsister 前两个 mesh 是可以做,但 springboot 这类的基座是不是也可以做呢?另外后两个无感可以展开讲讲吗
    mooyo
        7
    mooyo  
       75 天前
    之前的项目大规模用过 istio ,我的感受是完全没有必要。。。而且运维成本很高,线上问题很难处理。
    mooyo
        8
    mooyo  
       75 天前
    @mooyo 我其实也没看出来 istio 解决了什么痛点,感觉不存在他的舒适区。面向晋升需求可以用用
    RicardoY
        9
    RicardoY  
       75 天前
    service mesh 的主要优势是把服务发现,流量路由,协议转换和服务治理这些东西完全和业务服务解构。
    举个简单的例子,你是架构,想上一个新的治理规则,但是你们一共有 1000 个微服务,其中有 600 个微服务需要升级框架才能支持。这种时候如果没有 service mesh ,可能全公司数十个团队要花数千个 PD 才能完成框架版本的收敛并增加这个治理规则,而如果用了 service mesh ,架构侧分批升级 sidecar 并下发规则就可以了。
    RicardoY
        10
    RicardoY  
       75 天前
    一旦规模大起来了,没有 service mesh 会使这些工作效率非常低下。
    GooMS
        11
    GooMS  
       75 天前 via Android   ❤️ 1
    微服务的一整套都是刷 kpi
    vhwwls
        12
    vhwwls  
       75 天前
    我也是这样想的,个人觉得中国九成的公司只靠 Spring Cloud Alibaba 的 Nacos 那一套,就可以完成大部分微服务治理的需求,istio 最显著的一个实际意义是在公司前期的基础设施做的比较脏乱差的情况下,起到一个抹平不同时间线,不同业务向的技术栈差异的作用。
    dzdh
        13
    dzdh  
       74 天前
    换个理解方法。

    既然有团队负责这个,有团队负责那个。

    那 k8s 其实也没必要用了。他本身也只是在机器上调度容器启停更新容器镜像而已。写几十个 shell 其实也能实现多机更新,shell 用 ipvs 实现流量转发,每个机器 container 挂个 nginx 互相同步配置文件就是 ingress 了。bind9 实现内网 dns 。nfs 的共享存储。这样就重新发明 k8s 了。
    HypoChen
        14
    HypoChen  
       74 天前
    SM 很难评,如果基础设施/开发能力薄弱,SM 可以一键为业务提供服务发现,流量路由等等高阶能力。但基础设施/开发能力薄弱估计有很难维护好 SM 自身。
    另一方面,如果基础设施已经很健全了(如 OP 的场景),引入 SM 的投入和收益又很不成正比。
    lvlongxiang199
        15
    lvlongxiang199  
       74 天前
    @povsister 这种的 trace 能关联 rpc 跟 db 查询吗 ? 比如处理一个请求 req 的时候, 访问了服务 b, c 以及 db, 能在 UI 上看到这个 req 对 db 的访问吗 ? 预期的树形结构是这样的

    |_____________________req____________|
    |___b__| |__c__| |__db_|
    povsister
        16
    povsister  
       74 天前
    @lvlongxiang199
    当然可以
    lvlongxiang199
        17
    lvlongxiang199  
       74 天前
    @povsister 那是如何实现的 ? 用的魔改的 db 驱动 ?
    hangszhang
        18
    hangszhang  
       74 天前
    看规模
    lvlongxiang199
        20
    lvlongxiang199  
       73 天前
    @mark2025 发这个连接有什么用吗 ?
    lvlongxiang199
        21
    lvlongxiang199  
       73 天前
    @mark2025 我的问题是 servicemesh 如何通过 sidecar 实现 trace. opentelemetry 更像是一个规范及 sdk, 从我之前的经验来看, 得需要埋点实现, 似乎没法做到侵入性的实现 trace 等功能
    RicardoY
        22
    RicardoY  
       73 天前
    @lvlongxiang199 如果你访问 DB 的流量也是 sidecar 代理的,那 sidecar 里上报不就好了
    lvlongxiang199
        23
    lvlongxiang199  
       72 天前
    @RicardoY 在读一遍我的问题. sidecar 上报这能无侵入的实现. 但是如何无侵入的**关联 traceCtx **, 知道这个 db 查询是哪个 rpc 请求触发的 ?
    lvlongxiang199
        24
    lvlongxiang199  
       72 天前
    @RicardoY 我在 https://v2ex.com/t/1079010?p=1#r_15371204 里头的确没提到这一点
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   1107 人在线   最高记录 6679   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 22ms · UTC 18:56 · PVG 02:56 · LAX 10:56 · JFK 13:56
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.