🏆 服务网格历史
❓ 什么是微服务？
微服务是在2012（33rd degree Conference）年被提出**，**一种软件开发技术- 面向服务的体系结构（SOA）架构样式的一种变体(是但是又不是，我觉得微服务不是 SOA的变体，在写这篇笔记的时候可能那时候我都还不晓得什么是 SOA，但是我尊重当时的我)，它提倡将单一应用程序划分成一组小的服务，服务之间互相协调、互相配合，为用户提供最终价值。每个服务运行在其独立的进程中，服务与服务间采用轻量级的通信机制互相沟通（通常是基于 HTTP的 RESTful API）。每个服务都围绕着具体业务进行构建，并且能够独立地部署到生产环境、类生产环境等。另外，应尽量避免统一的、集中式的服务管理机制，对具体的一个服务而言，应根据上下文，选择合适的语言、工具对其进行构建
SOA（面向服务的架构）定义了一种可通过服务接口复用软件组件的方法。 此类接口会使用通用的通信标准，这些标准能够快速合并到新应用程序中，而不必每次都执行深度集成、
⭐️微服务的核心业务的技术特征：
- 在结构上，将原有的从技术角度拆分的组件，升级为从业务角度拆分的独立运行的服务，这些服务具备各自的实现平台，并且独占自有数据，在服务之间以智能端点和哑管道的方式通信。
- 在工程上，从产品而非项目的角度进行设计，强调迭代、自动化和面向故障的设计方法。
微服务的核心业务和技术特征
来自周志明: 《凤凰架构》
- 围绕业务能力构建：有什么样的结构、能力、规模的团队就有什么样的结构、能力、规模的产品
- 分散治理：服务对应的开发团队有选择某种对应服务处理对应功能的权力
- 通过服务来实现独立自治的组件
- 产品化思维： 避免把软件研发视作要去完成的任务，而是要视作一种持续改进、提升的过程
- 数据去中心化： 微服务提倡不同领域的数据应该分散管理
- 强终端弱管道：弱管道这个就是反对SOA的通讯机制，在SOA中有一种事件驱动架构，他就是将服务都连接一个管道，从管道中拿取数据，强终端表明，你的某个服务需要某些额外的通信方法就应该只在服务自己的endpoint内解决而不是集成与全部服务
- 容错性设计： 不在虚幻的追求服务的永远稳定，而是接收服务会出错的现实，表明在微服务的设计中需要有自动机制可以对其依赖的服务进行快速的故障检测并且恢复（
Kubernetes） - 演进式设计：承认服务会被报废或者淘汰
- 基础设施自动化: CI/CD
微服务的好处与坏处：
2.1 好处
- 提高应用的伸缩性
- 方便部门或业务之间的协作
- 提高自动化程度，减少增耗
2.2 坏处
- 实例数量急剧增长，对部署和运维自动化要求更高
- 使用网络调用API，因此对网络依赖更强
- 调用链路变长，分布式跟踪成为必选（当然你不选，谁也没有办法）
- 日志分散，跟踪和分析难度加大
- 服务分散，易受攻击
- 自动伸缩、路由管理、故障控制、存储共享等。
因此出现了kubernetes解决微服务架构产生的一些问题。在进程级别为微服务提供了部署、调度、伸缩、监控、日志等功能 。但是通信和联系更加复杂了，其中的观测和服务质量保障成为微服务方案的短板，因此service mesh登场了。
⭐️ 什么是服务网格，它从何而来？
ps:最近几天都在学习服务网格和
Istio，在之前学习过，不过学习了个一知半解的，这几天决定下个决心给他解决
首先直接推荐看这篇文章就足够了: https://dzone.com/articles/whats-a-service-mesh-and-why-do-i-need-one
服务网格是一个基础设施层，无需更改代码即可为应用程序提供零信任安全性、可观察性和高级流量管理等功能。
服务网格是用于处理服务到服务通信的专用基础设施层。它负责通过构成现代云原生应用程序的复杂服务拓扑可靠地交付请求。在实践中，服务网格通常实现为一组轻量级网络代理，这些代理与应用程序代码一起部署，应用程序无需感知。
服务网格作为单独层的概念与云原生应用程序的兴起有关。在云原生模型中，单个应用程序可能包含数百项服务;每个服务可能有数千个实例;并且这些实例中的每一个都可能处于不断变化的状态，因为它们是由
Kubernetes 等编排器动态调度的
服务网格是一种网络模型，位于 TCP/IP 之上的抽象层。它假设底层 L3/L4 网络存在并且能够从点到点传输字节。（它还假设此网络与环境的所有其他方面一样不可靠;因此，服务网格也必须能够处理网络故障。
凤凰架构: 服务网格并不是什么难以理解的黑科技，它只是一种处理程序见通信的基础设施，典型的存在形式就是部署在应用旁边，一对一为应用提供服务的边车代理以及管理这些边车代理的控制器；
⭐️ SerivceMesh相关发展历程：
Spring Cloud
2015年，Spring Cloud诞生。它定义了一系列的标准特性，如智能路由、熔断机制、服务注册与发现等。并提供了对应的库和组件来实现这些标准特性。
但Spring Cloud缺点也有，如下所示：
- 用户需要学习和熟悉各组件的“语言”并分别运维，增加了应用门槛。
- 需要在代码给别对组件进行控制，不能够多语言协作。
- 自身没有对调度、资源、Devops的相关支持。
Linkerd
2016年年初，由两位Twitter工程师开发了Linkerd项目，并打出了“The services must mesh”的口号，成为了Service Mesh的第一批布道者。
Linkerd 很好地结合了Kubernetes 所提供的功能，以此为基础，在每个KubernetesNode 上都部署运行一个Linkerd 实例，用代理的方式将加入Mesh的Pod 通信转接给Linkerd ，这样Linkerd 就能在通信链路中完成对通信的控制和监控。
Linkerd相比先前说的Spring Cloud完成了以下：
- 无须侵入工作负载的代码，直接进行通信监视和管理。
- 提供了统一的配置方式，用于管理服务之间的通信和边缘通信。
- 对kubernetes的支持，当然还支持其它底层平台。
Istio：
2017年5月，Goolge、IBM、Lyft宣布了 Istio的诞生。Istio 以 Envoy 为数据平面，通过 Sidecar 的方式让 Envoy 同业务容器一起运行，并劫持其通信， 接受控制平面的统一管理，在此基础上为服务之间的通信提供丰富的连接、控制、观察、安全等特性
官网介绍：
istio 是最受欢迎、功能最强大和最受信任的服务网格。Istio 由 Google、IBM 和 Lyft 于 2016 年创立，是云原生计算基金会的一个毕业项目，与 Kubernetes 和 Prometheus 等项目并列。
Istio 确保云原生和分布式系统具有弹性，帮助现代企业跨不同平台维护其工作负载，同时保持连接和保护。它支持安全和监管控制，包括 mTLS 加密、策略管理和访问控制，为 Canary 部署、A/B 测试、负载均衡、故障恢复等网络功能提供支持，并增加对整个资产中流量的可观察性。
Istio 并不局限于单个集群、网络或运行时的边界——在 Kubernetes 或 VM、多云、混合或本地上运行的服务可以包含在单个网格中。
