[云原生学习]演化的终极目标Service Mesh

最新推荐文章于 2024-10-31 17:13:10 发布

liuyouzhang

最新推荐文章于 2024-10-31 17:13:10 发布

阅读量125

点赞数

文章标签：微服务

本文链接：https://blog.csdn.net/liuyouzhang89/article/details/120117061

版权

单体架构->微服务(SpringCloud)->微服务(Kubernetes)->服务网格ServiceMesh(Istio)

以上路径，展示了从单体应用，到微服务架构的演化路径，我们可以看到，最终的演化终极目标是ServiceMesh。

那么，为什么会是此演化路径？此演化路径，后续的架构方案逐渐取代了之前的技术体系，能够解决什么问题？或者换个方式，有什么优点？

（1）单体架构 vs 微服务(SpringCloud)

这个我觉得应该不需要多说，微服务为什么要比单体架构更好，或者在高并发的互联网应用场景下能体现出什么优势，网上有很多相关的资料。最主要的，其在技术上解决了扩展性问题，在开发组织的协同方面，解决了小团队专注于某个业务领域，将其做精做细的问题。当然，从另一个方面来说，它解决了团队的开发力量可持续化问题，是一种搭积木的方式，干掉了在单体架构系统上必须依赖某几个业务或技术专家的局面，在技术上对并发大流量可扩展，在开发组织上面，实现了可持续，分布式，专而精。但是其也有缺点，技术架构复杂，对于技术人员的门槛提高。需要的团队人数需要增加。

所以，不论是在技术本身上的技术高级性上面，还是在大规模团队的可持续开发协助上面，其都带来了相对于传统单体架构的优势。不论是技术团队层面，还是公司技术人力组织层面，都能从微服务架构中得到好处。

这也是其能在短时间内，取代单体架构的原因。

（2）微服务(SpringCloud) vs 微服务(Kubernetes)

从SpringCloud到Kubernetes，这里面容器化，主要是Docker的崛起和流行，功不可没。微服务架构变复杂了，发布变成了一件痛苦的事情，并且基于细粒度的服务组件，其发布更新速度更快，对发布提出了更高的挑战。发布的频率更快了，运维人员变得痛苦了。或者本身一个系统的部署，变成了一件非常复杂的事情，传统的需要开发人员和运维人员去沟通一个个服务器的ip、所需要安装的组件、网络的权限等等这些事情，无法将运维人员解决出来。所以问了解决这些问题，随着DevOps的流行，容器化的逐渐兴起，成为了将运维人员和开发人员接放出来的最佳方案，逐渐变成了主流。

没有Kubernetes支持的容器管理和发布，是一件痛苦的事情，一开始是写shell脚本，后来有了Compose和Dockerfile，虽然其解决了编译成容器镜像的繁琐性问题，但是Docker的运行时管理，还是很不方便。然后，Kubernetes横空出世了。

（3）微服务(Kubernetes) vs 服务网格ServiceMesh(Istio)

服务发现、网关、限流、熔断、链路追踪、服务编排，这些问题，在SpringCloud有相关的组件来解决，但是其是要在应用层面实现，容器运行和管理组件Kubernetes，不负责解决这些问题。在这期间，蓝绿发布（或者称为灰度发布，金丝雀发布，A/B发布）逐渐流行（想想为什么会流行？为什么会有越来越多此方面的需求？）,对于应用层面自己来管理各服务组件，包括微服务的基础设施的配置集成，变得麻烦起来。试想，你想要切换30%的线上环境的流量，到新程序的版本上，70%的流量依然要到老版本，你要去一个个修改网关的配置，应用层面你得把这30%的流程切换到新版本上也需要相关的技术改动去实现，这次是基于用户ID，可能下一次是基于用户的区域（华东区），或者下一次是基于业务的范围（例如零售业务，刚好占30%，且相对不是重点业务，切过来）来划出这30%，这样事情就变得麻烦起来（大家也可以想想，没有服务网格的情况下，如何实现这些方案？）。

所以，到这里，微服务的基础设施，跟应用层面的紧密耦合，成为了必然的需求，必须要解决掉。

网上有很多此处，将ServiceMesh比作是SDN——软件定义网络（Software Defined Network，SDN）。

SpringCloud里面的那些微服务的基础组件，到了ServiceMesh这里，必然要成为一种对应应用层面进行支撑的基础设施。不能再是由程序员在代码里面实现的了。

我们想保留微服务架构的好处，但是我们又不想让在应用的代码层面处理过多的本应该由基础设施提供的功能，熔断、限流、链路追踪、可配置的动态的流量调整。并且这些复杂的机制，是需要由资深的开发人员来编码保障的，而随着团队的变大或者是精简（包含了人员的更替），不可能一直能保持良好的代码质量和简单的配置风格。

把代码里面，处理微服务基础设施角色的功能，包括网关的功能，提取出来，就是ServiceMesh的边车Sidecar。