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