传统微服务即将过时，这不是唬人的标题。3年前Kubernetes刚出现的时候，我觉得3年左右这个东西就会普及。毕竟是谷歌十几年来容器编排的精髓。图片来自Pexels，今天安利一下网格服务，如下图：限流、服务编排、服务链路跟踪）功能对框架甚至业务代码的依赖性很强。KubernetesKubernetes是一款优秀的软件产品，在一定程度上解决了微服务所需的应用编排和伸缩问题，但在流量管理、日志记录、监控、指标测量等场景能力有限。网格服务可以理解为Kubernetes的一个中期产品（可能你还没有接触过Kubernetes的早期产品，它即将逝去），网格服务可以弥补Kubernetes的短板，提供更丰富的服务治理方案.回首我们在微服务的青涩岁月里犯下的愚蠢！①项目之初老大：他说要跟上时代，用微服务。发展：没问题。服务开始拆分，引入SpringCloud或Dubbo等框架，工作完成。（就这么简单，没有人比我更懂微服务了！）②上线运行Boss：现在微服务上线了，我们现在能不能像大公司一样不停机发布？开发：我们只是拆分了服务，其他的我还没做，所以现在做不了。开发：微服务太难实现。日志、监控、异常排查、服务部署等成本是之前的数倍。③填坑之路引入大量中间件，代码配合辅助功能的植入，实现日志采集、服务链路监控、智能网关、熔断。多语言异构系统：中间件难以兼容，SpringCloud支持的微服务功能大多只适用于Java。等等（等等，太蛋疼了）当我第一次看到Kubernetes的时候，我以为它会拯救世界。Kubernetes提供服务发现、配置管理、负载平衡和网关。在这种情况下，是不是可以不再需要注册中心和服务治理框架，只构建一个基于Kubernetes的微服务系统呢？很多公司在这方面做了尝试，发现在治理功能的丰富性和大规模集群效率等方面，还存在一些不尽如人意的地方：流量管理能力不足：熔断能力不足，没有灰度控制能力;大规模使用时的性能问题：基于KubernetesService的服务发现过程需要经过Iptables或IPVS的搜索过程，集群规模大时对性能的影响会更加明显。日志、链路监控、指标测量等仍然需要额外的组件，需要在业务代码中添加辅助代码。目前比较成熟的方案：采用Kubernetes部署+SpringCloud（或Dubbo等），该方案在语言和框架依赖方面有所限制。出身豪门，不仅有颜值还有实力（心疼）。以Istio为代表的网格服务横空出世，彻底克服了传统微服务在服务数量多、多语言、安全、网络流量控制、可观察性等方面的挑战：全面管理业务和服务逻辑切分（无语言和框架依赖）。更灵活和细粒度的流量管理。监视、日志记录和链接跟踪提供编辑和统一规范。官网定义的四个函数偷偷告诉你：在服务网格世界中，消费者和生产者不需要直接引入额外的注册中心，服务可以直接部署和通信。这是网格服务中不值得一提的一点。只是让没见过世面的你开开眼界，免得对其他高深莫测的东西不敬。没有繁琐的服务搭建/框架图，直接看一些案例：案例服务架构图本例部署了一个应用来演示Istio的各种特性，它由四个独立的微服务组成。此应用程序模仿在线书店中的类别，显示有关书籍的信息。该页面将显示一本书的描述、该书的详细信息（ISBN、页数等）以及关于该书的一些评论：productpage：该微服务将调用两个微服务details和reviews来生成页面。details：该微服务包含图书信息。评论：此微服务包含与图书相关的评论。它还调用评级微服务。（有3个版本）ratings：这个微服务包含由书评组成的评级信息。以下是浏览器的效果图。Case1:TrafficA/BtestA/Btraffictestcase1A/Btraffictest2在同一个系统中，jackson登录和非登录看到的界面效果是不一样的。所有功劳都归功于Istio，而不是您的代码设置。（想想这么香的功能，我是不是反复在自己的代码中插入了很多埋点/配置）。案例二：服务链接跟踪productpage访问详情、评论、评分的链接一目了然。这种链接跟踪不需要在您的代码或框架中植入额外的代码。案例三：虽然监控很常见，但如果你没用过，就不知道它有多方便，有多香。部署脚本演示灵活流量设置轻松实现故障植入功能作者：RJ不限编程编辑：陶家龙来源：头条网/i6903536074665034243/
