Spring Cloud 还没学明白，Istio 又是什么鬼？？

Posted 2022-07-11 Java技术栈

tags:

篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了Spring Cloud 还没学明白，Istio 又是什么鬼？？相关的知识，希望对你有一定的参考价值。

点击关注公众号，Java干货及时送达

背景

过去，我们运维着“能做一切”的大型单体应用程序。这是一种将产品推向市场的很好的方式，因为刚开始我们也只需要让我们的第一个应用上线。

而且我们总是可以回头再来改进它的。部署一个大应用总是比构建和部署多个小块要容易。

集中式：

集群：

分布式：

分布式和集中式会配合使用。

我们在搭建网站的时候，为了及时响应用户的请求，尤其是高并发请求的时候，我们需要搭建分布式集群来处理请求。

我们一个服务器的处理能力是有限的。如果用我们一台设备当作服务器，那么当并发量比较大的时候，同一时间达到上百的访问量。那服务器就宕机了。然后只能重启服务器，当出现高并发访问的时候，就又会宕机。

所以我们需要更多的服务器来并行工作，处理用户的请求。那么问题来了，我们服务器运行的时候，怎么分发大量的请求给不同的服务器呢？

一般会采用(1apache+nTomcat)或者服务器模式来分发并处理请求。或者采用nginx分发请求。

微服务是运行在自己的进程中的可独立部署的服务套件。他们通常使用 HTTP 资源进行通信，每个服务通常负责整个应用中的某一个单一的领域。

在流行的电子商务目录例子中，你可以有一个商品条目服务，一个审核服务和一个评价服务，每个都只专注一个领域。

用这种方法让多语言服务（使用不同语言编写的服务）也成为可能，这样我们就可以让 Java/C++ 服务执行更多的计算密集型工作，让 Rails / Node.js 服务更多来支持前端应用等等。

微服务会成为大规模分布式应用的主流架构。任何复杂的工程问题都会归结为devide and conquer（分而治之），意思就是就是把一个复杂的问题分成两个或更多的相同或相似的子问题，再把子问题分成更小的子问题……

直到最后子问题可以简单的直接求解，原问题的解即子问题的解的合并。微服务本质是对服务的拆分，与工程领域惯用的“分而治之”的思路是一致的。

Spring Cloud 与 K8S 对比

两个平台 Spring Cloud 和 Kubernetes 非常不同并且它们之间没有直接的相同特征。

两种架构处理了不同范围的MSA障碍，并且它们从根本上用了不同的方法。Spring Cloud方法是试图解决在JVM中每个MSA挑战，然而Kubernetes方法是试图让问题消失，为开发者在平台层解决。

Spring Cloud在JVM中非常强大，Kubernetes管理那些JVM很强大。同样的，它就像一个自然发展，结合两种工具并且从两个项目中最好的部分受益。

可以看到，里面差不多一半关注点是和运维相关的。这么看来，似乎拿spring cloud和kubernetes比较有点不公平，spring cloud只是一个开发框架，对于应用如何部署和调度是无能为力的，而kubernetes是一个运维平台。

也许用spring cloud+cloud foundry去和kubernetes比较才更加合理，但需要注意的是，即使加入了cloud foundry的paas能力，spring cloud仍然是“侵入式”的且语言相关，而kubernetes是“非侵入式”的且语言无关。

推荐阅读：Spring Cloud Alibaba 终于一统江湖！

Spring Cloud vs Istio

这里面哪些内容是我们可以拿掉或者说基于 Service Mesh（以 Istio 为例）能力去做的？最新 Spring Cloud 面试题整理好了，大家可以在Java面试库小程序在线刷题。

分析下来，可以替换的组件包括网关（gateway 或者 Zuul，由Ingress gateway 或者 egress 替换），熔断器（hystrix，由SideCar替换），注册中心（Eureka及Eureka client，由Polit，SideCar 替换），负责均衡（Ribbon，由SideCar 替换），链路跟踪及其客户端（Pinpoint 及 Pinpoint client，由 SideCar 及Mixer替换）。

这是我们在 Spring Cloud 解析中需要完成的目标：即确定需要删除或者替换的支撑模块。