- 主题:大家对Service Mesh(istio)那套怎么看?
大家对Service Mesh(istio)那套怎么看?
在Java越来越不能一统天下的时代,在Spring Cloud都快要没人更新了的时代。
如果想一个微服务平台同时有各种语言java/go/rust/pyhon/node.js等等。是不是Service Mesh(istio)那套会变得越来越有价值?
--
FROM 103.149.83.*
不懂,我感觉K8s+grpc搞也可以,利用K8s做服务发现,grpc搞跨语言
【 在 Xjt 的大作中提到: 】
: 大家对Service Mesh(istio)那套怎么看?
: 在Java越来越不能一统天下的时代,在Spring Cloud都快要没人更新了的时代。
: 如果想一个微服务平台同时有各种语言java/go/rust/pyhon/node.js等等。是不是Service Mesh(istio)那套会变得越来越有价值?
--
FROM 36.112.199.*
graal也可以
【 在 Xjt 的大作中提到: 】
: 大家对ServiceMesh(istio)那套怎么看?
: 在Java越来越不能一统天下的时代,在SpringCloud都快要没人更新了的时代。
: 如果想一个微服务平台同时有各种语言java/go/ru...
- 来自 水木说
--
FROM 223.104.212.*
现在都serverless化了,service mesh 已经不潮了
1. 2010年前后以springcloud为代表的第一代微服务架构,一般是语言限定的,富客户端,开发范式命令式,引入对应的包。
2. 2017前后service mesh的,把流量管理+可观测性+安全的能力下层到sidecar,以k8s+istio为代表的,流量的管理的能力更强使用起来也更容易,基本可以支持各种语言,可以做到有限的弹性,开发范式是申明式的,成本增加了2跳。
3. 2020以后serverless 浪潮,可以做到按量收费+极度弹性,摆脱了几核几G的概念,让开发者关心于业务,流量管理、可观测性完全云化,对开发者是透明的。
RPC框架从2010前后的百花齐放,到第二代k8s+istio成为事实标准,到serverless时代的完全透明和云化,系统架构师的需求锐减,需要3、5年才能习得的能力目前开箱既有,开源和云计算导致了技术的马太效应,拥抱serverless,系统架构师要关注业务,拥抱DDD。
【 在 Xjt 的大作中提到: 】
: 大家对Service Mesh(istio)那套怎么看?
: 在Java越来越不能一统天下的时代,在Spring Cloud都快要没人更新了的时代。
: 如果想一个微服务平台同时有各种语言java/go/rust/pyhon/node.js等等。是不是Service Mesh(istio)那套会变得越来越有价值?
--
修改:sanhaoyang FROM 121.195.188.*
FROM 121.195.188.*