写点什么

对 Service Mesh 望而却步?可能都没理解这一点

作者:baiyutang
  • 2022 年 8 月 14 日
    广东
  • 本文字数:1148 字

    阅读完需:约 4 分钟

Service Mesh 发展已经有 6-7 年的时间,很多人对 Service Mesh 只停留在了解和知道的水平上,特别是很多技术人第一次接触到 Service Mesh,看到服务网格的解释,看到 Istio 的架构,对这门技术仍然云里雾里。劝退大多数人的不是技术,而是概念本身。

大部分的架构演进止步于微服务

架构的演进都是为了解决问题,然而现实是,大部分的公司架构演进止步于微服务。


微服务现在大行其道,但是对于大多数的公司而言,除非使用 Java 等又大量框架和库能支持快速落地,其他语言技术栈可能找一些稍微通用的框架修修改改。甚至见过 RESTful API 格式提供的服务,以手写 SDK 调用其他服务,这种还没有服务发现机制。


现实有两点:

  1. 少部分公司能够落地到接近微服务最佳实践,可能没有更大的业务体量迫使架构进一步优化。

  2. 更多公司似是而非的进行着架构落地,往微服务正走,支撑过业务的快速发展,而足矣。甚至业务的生命周期比软件的生命周期更短。

问题是什么?

在落地微服务之后,在业务体量或数据量疯狂扩张,服务节点数量成倍增加。甚至服务拓扑图成了一张网。

我们都知道微服务治理是最重要的功课,如果所有的微服务都统一语言和技术栈还好。假如整个业务体系再跨语言,那治理微服务诸如重试、限流、认证等等手段难不成都要跨语言、跨不同的客户端去实现一遍?假如某一次请求异常,又如何再跨语言跨技术栈等复杂的系统中快速定位问题?


我们更应该清楚的看到在跨端、跨语言、跨技术栈、又特别大体量业务和网络环境的情况下:

  1. 多套框架或中间件如何能够快速迭代、修复和演进?

  2. 复杂架构中如何快速定位网络问题?

  3. 如果让流量统一可控?如故障注入?支持多泳道?

所有问题都可以通过增加一层来解决

我们以服务发现最简单的治理手段举例,我们已知的这几种服务发现方式:

  1. 客户端做发现

现有 RPC 框架的的服务发现多数是基于这种方式实现的,大致流程是,客户端定期从注册中心获取一组服务实例,根据一定规则和发现机制选取其一,然后发起 RPC 调用。

  1. 集中式 LB 做转发

所有服务发现统一走一个 LB 或路由器,缺点也很明显,容易制造新的单点,且增加了的维护成本和调用次数。

  1. 服务代理形式做转发

部分服务实例以组为单位对外提供服务,这样能减小集中式的路由器或网关的压力,算是基于上述两种折中的方式,但是应该思考的问题是如何维护?

代理如何做?

Service Mesh 一言以蔽之:就是以代理的形式对服务进行治理,特别是网络层面的。那现在的问题就是如何实现代理。

ServiceMesh 演进过程

第一阶段:公共库抽取,解决业务耦合问题,但维护成本高,语言相关,通用型较差

第二阶段:代理模式,功能较为简陋,手工操作,如 Nginx

第三阶段:边车模式,帮助微服务处理大部分网络请求,

第四阶段:ServiceMesh,边车模式网格化,更为通用的网络处理模型

第五阶段:ServiceMesh2,ServiceMesh 升级版,增加控制平面


发布于: 刚刚阅读数: 3
用户头像

baiyutang

关注

开源爱好者 | CloudWeGo 2017.12.13 加入

广州 | Microservices | Golang | Cloud Nitive | “Smart work,Not hard”

评论

发布
暂无评论
对 Service Mesh 望而却步?可能都没理解这一点_baiyutang_InfoQ写作社区