Istio 能代替 Spring Cloud 吗
发布时间：2022-06-17 19:44:52 所属栏目：云计算 来源：互联网
导读：过去，我们运维着能做一切的大型单体应用程序。这是一种将产品推向市场的很好的方式，因为刚开始我们也只需要让我们的第一个应用上线。 我们一个服务器的处理能力是有限的。如果用我们一台设备当作服务器，那么当并发量比较大的时候，同一时间达到上百的访问
|
过去，我们运维着“能做一切”的大型单体应用程序。这是一种将产品推向市场的很好的方式，因为刚开始我们也只需要让我们的第一个应用上线。 我们一个服务器的处理能力是有限的。如果用我们一台设备当作服务器，那么当并发量比较大的时候，同一时间达到上百的访问量。那服务器就宕机了。然后只能重启服务器，当出现高并发访问的时候，就又会宕机。 所以我们需要更多的服务器来并行工作，处理用户的请求。那么问题来了，我们服务器运行的时候，怎么分发大量的请求给不同的服务器呢？ 一般会采用(1apache+nTomcat)或者服务器模式来分发并处理请求。或者采用nginx分发请求。 微服务是运行在自己的进程中的可独立部署的服务套件。他们通常使用 HTTP 资源进行通信，每个服务通常负责整个应用中的某一个单一的领域。 在流行的电子商务目录例子中，你可以有一个商品条目服务，一个审核服务和一个评价服务，每个都只专注一个领域。 用这种方法让多语言服务（使用不同语言编写的服务）也成为可能，这样我们就可以让 Java/C++ 服务执行更多的计算密集型工作，让 Rails / Node.js 服务更多来支持前端应用等等。 两种架构处理了不同范围的MSA障碍，并且它们从根本上用了不同的方法。Spring Cloud方法是试图解决在JVM中每个MSA挑战，然而Kubernetes方法是试图让问题消失，为开发者在平台层解决。 Spring Cloud在JVM中非常强大，Kubernetes管理那些JVM很强大。同样的，它就像一个自然发展，结合两种工具并且从两个项目中最好的部分受益。 可以看到，里面差不多一半关注点是和运维相关的。这么看来，似乎拿spring cloud和kubernetes比较有点不公平，spring cloud只是一个开发框架，对于应用如何部署和调度是无能为力的，而kubernetes是一个运维平台。 分析下来，可以替换的组件包括网关（gateway 或者 Zuul，由Ingress gateway 或者 egress 替换），熔断器（hystrix，由SideCar替换），注册中心（Eureka及Eureka client，由Polit，SideCar 替换），负责均衡（Ribbon，由SideCar 替换），链路跟踪及其客户端（Pinpoint 及 Pinpoint client，由 SideCar 及Mixer替换）。 这是我们在 Spring Cloud 解析中需要完成的目标：即确定需要删除或者替换的支撑模块。 （编辑：济源站长网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |
