标签：服务 Service Kubernetes SpringCloud 终极目标 单体 Mesh ServiceMesh 架构
单体架构->微服务(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。
以上就是本人对于微服务演化路径的一些理解，关于k8s和Istio的架构的详细介绍，本人理解的也有限所以不在此讨论，网上有很多相关文章，我就不班门弄斧了。
欢迎各位看官留言讨论。
参考资料：
1、《凤凰架构》后微服务时代
2、《Kubernetes中文指南/云原生应用架构实践手册(201910)》理解ServiceMesh
Service Mesh 服务网格 - 《Kubernetes中文指南/云原生应用架构实践手册(201910)》 - 书栈网 · BookStack
3、宜信微服务架构落地及其演进|分享实录
宜信微服务架构落地及其演进|分享实录 - 宜信技术学院 (creditease.cn)
标签：服务,Service,Kubernetes,SpringCloud,终极目标,单体,Mesh,ServiceMesh,架构 来源： https://blog.csdn.net/liuyouzhang89/article/details/120117061
本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享； 2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关； 3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关； 4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除； 5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。