作为开发对一个新技术的学习 主要方式有三❓，what？、why？、how？
以下资料来源于网络整理
what服务网格？
服务网格（Service Mesh）是处理服务间通信的基础设施层。它负责构成现代云原生应用程序的复杂服务拓扑来可靠地交付请求。在实践中，Service Mesh 通常以轻量级网络代理阵列的形式实现，这些代理与应用程序代码部署在一起，对应用程序来说无需感知代理的存在。
service mesh的特点
- 应用程序间通信的中间层
- 轻量级网络代理
- 应用程序无感知
- 解耦应用程序的重试/超时、监控、追踪和服务发现
是不是听的迷迷糊糊，没事往下看
why服务网格？
说起服务网格免不了要提一下微服务，因为service mesh就是在微服务体系上发展起来。我们知道架构的演变是从单体架构->分布式->微服务。
微服务的核心思想便是应用功能拆分与解耦，降低业务系统实现复杂性。微服务强调将应用功能拆解为一组松耦合服务，每个服务遵守单一责任原则。微服务架构解决了传统单体式架构存在的几个固有问题：每个服务可以独立部署和交付，大大提升了业务敏捷性；每个服务可以独立横向扩展、收缩，应对互联网规模的挑战。
微服务也不是“银弹”，在解决问题的同时也带来了不小的复杂度，为了实现微服务，每个服务都需要处理很多与业务无关的通用功能，例如服务发现、负载均衡、限流熔断。本来引入微服务是为了解决问题，能支撑业务的快速发展，结果实现的时候发现还有如此多的非功能性需求，甚至拖慢了研发进度，大不如前。于是市面上出现了类似 Spring Cloud 的框架来避免代码的重复，以类库的形式集成到每个服务。目前这种主流的做法属于一种侵入式的方案，虽然在一定程度上屏蔽了复杂度，但是仍然有很多自己的痛点，比如学习门槛高–每个组件都需要投入时间精力来学习、功能不全、无法跨语言和升级困难。以上每个痛点都削弱了微服务所带来的好处。
微服务为我们提供了很多好处但是也带来了一些问题
缺点：
服务治理方式不统一：不同服务治理的方式会引入不同的中间件，而这些中间件的技术标准和维护标准都不同。因此运维人员或者架构人员必须掌握每种中间件的使用方法，很多时候这对一个人力资源有限的科技公司并不现实。
重复造轮子：微服务架构是允许多语言栈、多技术栈的，但不同的技术栈针对通信、支撑服务、服务安全、服务监控、熔断/降级/限流等通用技术问题却需要各自的解决方案，实在是成本的浪费。
服务治理缺乏标准化：由于服务治理缺乏标准化，因此微服务治理的好坏全依靠技术人员个人的能力、经验和水平，这就有点像手工作坊时代，器物优质全靠工匠。但是无标准化显然不符合科技发展的轨迹。
为了解决上述问题，于是服务网格出现了。
既可以无侵入、透明、用户无感知的插入到现有的分布式微服务架构中，同时又可以解决一些通信所必须考虑的普遍问题（服务发现、负载均衡、超时重试、熔断/限流、监控、访问控制、认证授权等），将这些问题的解决方案统一下沉到平台层，而不再依靠引入第三方中间件（zookeeper、nginx、sentinal、hystrix、pinpoint/zipkin、spring security），并且所有的维护方式统一且标准化
这样我们可以给服务网格一个好理解的定义了
- 服务网格就是应用程序或者说微服务间的 TCP/IP，负责服务之间的网络调用、限流、熔断和监控。
how服务网格？
服务网格目前的具体解决方案开源项目有Istio 、Linkerd、consul connect、kuma等等
介绍下Istio
Istio是一个开源平台，提供了对整个服务网格的行为洞察和控制能力，是一个服务网格的完整解决方案。通过Sidecar的模式为每一个业务容器注入一个伴生容器，伴生容器接管了所有的流量处理，以做到无侵入的服务治理实现。
- 本文标题： 服务网格相关知识
- 文章作者： sherryriver（木木三可）
- 发布时间： 2021.09.23
- 本文链接： https://sherryriver.github.io/2021/09/23/服务网格相关知识/
- 许可协议： "署名-非商用-相同方式共享 4.0" 转载请保留原文链接及作者。