微服务架构即将被淘汰
服务架构的演进
微服务初期
产生了：springCloud，dubbo 等微服务框架，大部分的服务治理（熔断，限流，服务编排，服务链路跟踪）功能与框架甚至业务代码强依赖。
Kubernetes
kubernetes 是一个很杰出的软件产品，在一定程度上解决了微服务所需的应用编排，伸缩等问题，但是在流量治理，日志，监控，指标度量，等场景能力有限。
网格化服务
可以理解它是 kubernetes 中期的产物（也许你还没摸过 kubernetes 初期的产物他就即将逝去），网格化服务可以弥补 Kubernetes 的不足，提供更为丰富的服务治理方案。
回首我们曾在微服务那个青葱岁月犯过的傻!
项目开始
老板：说我们要跟上时代，要用微服务。
开发：没啥问题。服务开始拆分，引入 springCloud 或者 dubbo 等框架，完工。（就是这么简单，没有谁比我更懂微服务了！）
上线运行
老板：微服务上了，我们现在是不是可以像大公司那样无停机发布了？
开发：我们只是拆分了服务，并没有做其它的，这块目前做不了。
开发：微服务太难搞了，日志，监控，异常排查，
服务部署，成本是之前的好几倍。
填坑之路
引入大量中间件，代码配合植入辅助功能，来实现日志采集，服务链路监控，智能网关，熔断。
多语言异构系统：中间件难以兼容，springCloud支持的大部分微服务功能都只适用 Java 而已。and so on (等等 太痛苦了)
初见 kubernetes ，曾以为它能拯救全世界。
Kubernetes 提供服务发现、配置管理、负载均衡和网关。既然这样，那么是否就可以不再需要注册中心和服务治理框架，只基于Kubernetes构建微服务系统呢？
很多公司进行了这方面的尝试，尝试后发现从治理功能丰富度、大规模集群效率等方面，还是有不太满意的地方。
流量治理能力不足——缺乏熔断能力，没有灰度控制能力； 大规模使用时的性能问题——基于Kubernetes Service的服务发现过程需要经过Iptables或IPVS的查找过程，集群规模大时性能影响会比较明显。 日志，链路监控，指标度量 等依旧需要额外的组件以及业务代码中需要加入辅助的代码。
目前较为成熟的方案：使用Kubernetes部署+Spring Cloud（或Dubbo等），该方案在语言和框架依赖比较局限
豪门出身，不但有颜值还是个实力派（扎心了）
以 Istio 为代表的网格化服务横空出世，彻底战胜了传统微服务在服务数量多，多语言的，在安全性、网络流量控制、可观察性等方面的挑战。
彻底把业务和服务治理逻辑切分开(没有语言和框架依赖)
更灵活，更细粒度的流量管理
监控，日志，链路跟踪提供编辑、统一的规范
官网定义的四大功能
偷偷告诉你：在服务网格化的江湖里，消费者和生产者直接不需要额外引入一个注册中心，服务直接部署通信。这在网格化服务里本是一个不值得一提的点，就是为了让没见过世面的你开开眼，免得其他太深奥没听明白失敬了。
没有繁琐的服务搭建/框架图，直接上部分案例：
案例的服务架构图
productpage. 这个微服务会调用 details 和 reviews 两个微服务，用来生成页面。 details. 这个微服务中包含了书籍的信息。 reviews. 这个微服务中包含了书籍相关的评论。它还会调用 ratings 微服务。（有3个版本） ratings. 这个微服务中包含了由书籍评价组成的评级信息。
以下是浏览器效果图
案例1 流量A/B 测试
A/B 流量测试案例 1
A/B 流量测试2
同一系统，jackson 登陆的跟没有登陆的看到的界面效果是不同的。这一切的功劳都归于 Istio，而不用你的代码设置。（想想这么香的功能，自己是不是曾经反反复复在自己代码里面插入了很多埋点/配置）
案例2 服务链路跟踪
productpage 访问 detail，review，rating 的链路一目了然
案例3 监控
虽然很常见，但是你没用过都不知道他有多便利多香
部署脚本演示
灵活的流量设置
轻轻松松实现故障植入的功能
安利到这里，具体感兴趣的话还是要靠你自己去尝试。
来源：https://www.toutiao.com/i6903536074665034243/
