服务网格基础
服务网络基础
目录
[toc]
前言
从今天开始我们将进入服务网格的学习，服务网格是微服务架构中的一种重要的技术，它可以解决微服务架构中的一些问题，比如服务发现、服务治理、服务监控等等，我们将从服务网格的基础开始，逐步深入，希望能够帮助大家理解服务网格。
1、应用架构的演进
要了解服务网格，我们需要从应用架构的演进说起。应用架构的演进过程就需要从单体应用开始说起，单体应用的优缺点，以及为什么需要拆分应用，拆分应用的优缺点，以及拆分应用的方式，最后引出服务网格的概念。
1.单体应用
在软件开发早期阶段，大家都在一个应用系统上开发。各个业务模块之间耦合也比较紧密。软件发布也是整体发布，或者对软件进行打包发布和部署，比如 java 可以打包成 war 部署。测试也很容易，因为代码都在一起，基本不需要引用外部的关联服务。
在软件开发早期，这种软件开发模式能适应业务的发展，软件应用也可以正常运行。如果你的业务发展良好，客户需求会变得越来越多，软件功能数也会随着客户的需求变多而变多。为了实现这些功能，你必须添加很多代码。而随着业务进一步发展，代码量势必也会越增越多。有可能 2 到 3 年后，软件代码量会变得非常巨大。那时软件就会变成一个非常庞大且复杂的单体应用。软件里面的功能多，代码错综复杂。
此时可能出现的问题：
- 打包编译会耗时很久，导致发布也很耗时。
- 代码可维护性变差，因为代码量大，逻辑复杂，只有少数老员工能全部理解。代码质量难以保证，复用性差等，代码腐化严重。
- 修改 BUG 和增加新功能会变得困难，可能牵一发而动全身。
- 软件扩展变得困难
- 软件可用性风险增加。可能一个 BUG 导致整个软件不可用。
那么应该如何解决上面的这些问题呢，俗话说：大事化小- 拆字诀。
第一步可能想到的就是拆分应用。把一个大型的单体应用按照业务功能进行拆分。比如电商应用，可能拆分为商品应用、订单应用、用户应用、商铺应用等等相对比较小的应用功能。
当随着业务规模进一步的发展，我们可能还要继续把上面的应用做进一步拆分，变成更小的应用，以服务的形式对外提供应用服务。应用慢慢的拆分为了比较小的服务 - 微服务。
2.微服务应用
这样应用就变成了微服务应用，每个微服务都是一个独立的应用，它们之间通过**网络(restful api或者grpc)**进行通信。那么微服务的具体定义是什么呢？
grpc：进程间通信协议。
- 维基百科定义：微服务 (Microservices) 是一种软件架构风格，它是以专注于单一责任与功能的小型功能区块 (Small Building Blocks) 为基础，利用模块化的方式组合出复杂的大型应用程序，各功能区块使用与语言无关 (Language-Independent/Language agnostic) 的 API 集相互通信。
- AWS 的定义：微服务是一种开发软件的架构和组织方法，其中软件由通过明确定义的 API 进行通信的小型独立服务组成。这些服务由各个小型独立团队负责。微服务架构使应用程序更易于扩展和更快地开发，从而加速创新并缩短新功能的上市时间。
- Thoughtworks 首席科学家的定义：微服务架构是一种架构模式，它提倡将单一应用程序划分为一组小的服务，服务之间互相协调、互相配合，为用户提供最终价值。每个服务运行在其独立进程中，服务与服务之间通常采用轻量级的通信机制相互沟通。每个服务都围绕具体的业务进行构建，并且能独立部署到生产环境中。
resilience n.回弹性；恢复力；
可观测性也是微服务里一个很重要的方面。
虽然不同的组织对微服务的定义不是完全一致的，但是它们的核心能力是一致的，即将单体应用拆分为多个小型服务，每个服务都是一个独立的应用，它们之间通过网络进行通信，每个微服务都有自己的代码库、数据库和运行环境。
那么在具体的实践中，使用微服务架构有哪些优势和劣势呢？
优势
- 应用小，可快速编译部署
- 单个微服务维护性变高，修改容易，因为每个团队独立负责一块功能。新功能交付变快，可以快速开发交付
- 扩展性变高，根据业务规模可以随时缩减/增加服务器规模
- 可靠性变强，可以部署很多独立的服务
- 业务解耦，按照业务边界拆分为多个独立的服务模块
- 提升研发效率，业务拆分后，服务模块变小，在一个团队内就可以独立编写、测试、发布，加快研发效率。
拆分后，单个微服务比较小，它只专注于做好一件事情。拆分的指导原则：高内聚，低耦合。
单一微服务有点像软件设计中的单一职责原则，Martin 对单一职责有一个论述：把因相同原因而变化的东西聚合到一起，而把因不同原因而变化的东西分离开来。
虽然微服务有这么多的好处，但是也需要注意的是，微服务架构并不是银弹，它同样也带来了很多的劣势（问题）。
劣势
- 整体复杂度变高，从哪些方面来管理这种复杂度？
- 运维变得复杂：微服务变多，怎么监控所有微服务，保证服务稳定？出了问题，怎么定位问题？
- 服务管理：微服务变多，管理复杂度变高，治理变得复杂
- 测试方面的挑战：你需要结合其他的微服务来进行集成测试
- 分布式问题：分布式数据一致性、分布式事务(尤其在做支付领域，这方面更加重要。)
- 服务可用性保障：一个服务出了问题，如何才能不影响其他服务？
根据上面微服务定义，这些服务都是由小型独立团队负责，那团队怎么划分？公司组织架构如何调整才能适应微服务的架构发展？这也给组织管理带来了变革的挑战。
例如：ddd：做微服务的划分。
还有微服务的微，多微才是好的微？也就是微服务怎么划分，如何确定边界？等等这些都是微服务面临的问题和挑战。
所以我们在使用微服务架构时，需要权衡微服务的优势和劣势，任何事物都有正反面，就像一枚硬币一样，所以思考问题要多样化，不能只思考一点。当我们享受微服务给开发和产品带来好处的同时，本身也会带来一系列的问题，如何克服这些问题，才是实施好微服务的关键所在。
随着技术的发展，软件架构的不断升级调整，上面我们遇到的这些问题大部分是可以解决的。比如需要建立运维开发基础设施来加以保障才能让微服务顺利运行，比如需要建设以 CI/CD 为基础的自动化交付流水线，到最后建设成从开发、测试、预发布、上线、运维等整个==研发流程自动化==的 DevOps 为目标。因为随着微服务的逐步建设，服务数量增多，上线服务次数必然增多，交付频繁会带来故障次数增多，所以我们必须建设自动化的工具链，来帮助我们快速无误的交付服务，实施好微服务项目。
而为了解决其他方面的问题，比如微服务的服务发现、熔断、降级、限流等等服务治理方面的问题，也有专门的技术栈来解决，比如 Spring Cloud、Dubbo(阿里的)等。
Spring Cloud 是在 Spring 基础上构建的，Spring 是一个全家桶，Spring Cloud 也是一个全家桶，它由很多技术框架组合而成，包括：
Circuit Breakers断路器。
服务治理
服务注册和发现：Netflix Eureka
当然我们也有其他的选择，比如 consul、etcd、zookeeper等
断路器：Hystrix
调用端负载均衡：Ribbon
REST 客户端：Feign
网关
API 网关：Zuul
当然我们也可以选择其他的，比如 Spring Cloud Gateway、kong、nginx+lua、apisix等
分布式链路监控
Spring Cloud Sleuth：埋点和发送数据
当然还有其他的比如 zipkin、pinpoint、skywalking(java里面最流行的)、jaeger(golang开发的)等
消息组件
Spring Cloud Stream
Spirng Cloud Bus
消息中间件的其他软件：RocketMQ、Kafka、RabbitMQ
配置中心
Spring Cloud Config
配置中心可以有其他的替代，比如 Apollo、Nacos（国内比较流行的2种方式） 等
安全控制
Spring Cloud Security
Spring Cloud 是一整套微服务体系，它是一个完整的微服务解决方案，Spring Cloud 社区强大，也很活跃，这也是现在比较主流的微服务技术栈。
但是 Spring Cloud 也有一些缺点，比如它是基于 Spring 的，所以它的技术栈都是基于 Java 的，如果你的团队不是 Java 的，那么你可能需要考虑其他的技术栈。另外，Spring Cloud 的技术栈比较多，学习成本也比较高，所以你需要考虑你的团队是否有能力学习和使用 Spring Cloud。Spring Cloud 微服务体系具体还有哪些缺点呢？
- 代码侵入性强 - 业务层中需要加入治理层代码，与治理层混淆在一起 （很多都是通过注释的方式加入）
- 组件多 - 组件多，学习成本就变高
- 治理功能不全 - 比如协议转换、动态请求路由、灰度发布等功能 （如果想做的话，可以把spring cloud部署到k8s里，k8s来做灰度等功能）
- 无法实现语言无关性 - 只能是一种语言或几种语言实现，无法做到与编程语言无关，这和微服务架构的初衷是相违背的
针对以上的一些问题，就出现了 服务网格(Service Mesh)这种架构，它作为一个基础设施层，真正做到与业务解耦，与语言无关，解决复杂架构下微服务应用与微服务应用之间通信网络相关问题，做到与业务解耦，让开发者专注于业务开发，而不是服务治理相关的问题。
3.服务网格
服务网格是一种==基础设施层==，它由一组网络代理组成，这些代理负责管理和协调服务之间的通信。服务网格可以提供服务发现、负载均衡、故障恢复、流量控制、安全等功能，从而简化了微服务架构中的一些问题。
服务网格的代理通常是以 sidecar 的形式部署在每个服务实例旁边。这些 sidecar 代理可以拦截服务之间的通信，并提供一些额外的功能，例如负载均衡、故障恢复、流量控制等。服务网格还可以提供一些高级功能，例如 A/B 测试、金丝雀发 布、蓝绿部署等。
服务网格的一个重要特点是透明性。服务网格的代理可以自动处理服务之间的通信，而不需要服务本身进行任何修改。这意味着我们可以在不影响服务本身的情况下，对服务之间的通信进行管理和控制。
这里最重要的是一种思维转变，不再将代理看成孤立的组件，而是将其组成的网络视为一种有价值的实体。
TCP 协议催生了分布式系统，分布式系统催生了微服务，Service Mesh 就是下一代微服务技术的代名词，是微服务时代的 TCP 协议。Service Mesh 以 Sidecar 形式，将服务治理从业务逻辑中剥离，并拆解为独立进程，实现异构系统的统一治理和网络安全。
为了能够对这些代理进行管理和控制，服务网格演进出了统一的控制平面（control plane）和数据面板（data plane，即边车代理）。
控制平面
控制和管理数据平面中的 Sidecar 代理，完成配置分发、服务发现、流量路由、授权鉴权等功能，以达到对数据平面的统一管理。控制平面不会直接解析请求数据包，通常提供 API 或者命令行工具可用于配置版本化管理，便于持续集成和部署。
数据平面
由整个网格内的 Sidecar 代理组成，这些代理以 Sidecar 的形式和应用服务一起部署。 这些代理负责协调和控制应用服务之间的所有网络通信。每一个 Sidecar 会接管进入和离开服务的流量，并配合控制平面完成流量控制等方面的功能。
总结一下，Service Mesh 具有如下优点：
- 屏蔽分布式系统通信的复杂性（负载均衡、服务发现、认证授权、监控追踪、流量控制等等），服务只用关注业务逻辑
- 真正的语言无关，服务可以用任何语言编写，只需和 Service Mesh 通信即可
- 对应用透明，Service Mesh 组件可以单独升级
当然，Service Mesh 目前也面临一些挑战：
- Service Mesh 组件以代理模式计算并转发请求，一定程度上会降低通信系统性能，并增加系统资源开销
- Service Mesh 组件接管了网络流量，因此服务的整体稳定性依赖于 Service Mesh，同时额外引入的大量 Service Mesh 服务实例的运维和管理也是一个挑战
最后我们简单对比下 Spring Cloud 与服务网格的区别：
| 能力 | Spring Cloud 生态系统 | Service Mesh 生态系统 |
|---|---|---|
| 服务注册与发现 | 开发简单方便，仅需一个简单的注解，支持多种注册中心。对开发人员来说，很容易在本地环境下完成编码和调试。 | **基于 K8s 的服务机制，并提供自己的注册中心。**开发人员需要理解 Kubernetes，而开发环境的设置并不容易。 |
| 故障容忍性 | Resilience4j的官方整合提供了完整的故障容忍机制。但服务需要与 SDK 整合。 | 通过使用 sidecar 架构，它是一个非侵入式的故障容忍机制，对服务完全透明。 |
| 可观察性 | Spring Cloud 内置，例如 spring micro-meter、Zipkin 等。所有服务内部的指标、追踪和日志都可以轻松收集，对开发者完全透明。 | 通过 sidecar 机制，它可以监控进出通信。没有可观察的服务内部，服务追踪可能是不完整的。 |
| 流量调度 | Spring Cloud 仅有非常基础的流量调度，例如，它基于 Ribbon 的负载均衡（从上一版本中删除）。 | 更多的流量调度方案，如金丝雀部署、蓝绿部署都可以轻松完成。 |
🚩
k8s里，pod里多个容器是共享网络命名空间的。
2、微服务、Kubernetes 与服务网格
随着现在云原生技术的发展，Kubernetes 已经成为了云原生的标准，它是一个开源的容器编排平台，它可以自动化地部署、扩展和管理容器化的应用程序。Kubernetes 可以帮助我们管理微服务架构中的服务，例如自动化部署、负载均衡、故障恢复等。同样服务网格和 K8s 的结合可以提供更强大的功能，服务网格可以提供服务发现、负载均衡、故障恢复、流量控制、安全等功能，而 K8s 可以自动化地部署、扩展和管理容器化的应用程序。通过将服务网格和 K8s 结合起来，我们可以更轻松地管理和控制微服务架构中的服务。
虽然 K8s 可以帮助我们管理微服务架构中的服务，但是它并不能解决所有的问题。K8s 主要关注的是容器编排和管理，例如自动化部署、扩展和管理容器化的应用程序。而服务网格则关注于服务之间的通信，例如服务发现、负载均衡、故障恢复、流量控制、安全等。
微服务、云原生、Kubernetes 和服务网格是现代应用开发和部署的关键概念，它们之间有着密切的关系。微服务和云原生强调应用程序的可扩展性、可维护性和可部署性，Kubernetes 可以帮助我们自动化地部署、扩展和管理容器化的应用程序，服务网格可以提供服务发现、负载均衡、故障恢复、流量控制、安全等功能，从而简化了微服务架构中的一些问题。
3、服务网格主流对比
在 servicemesh.es网站中详细的列出了主流服务网格的详细对比。
那么我们应该如何选择服务网格呢？
尽管服务网格对代码没有影响，但它们改变了操作流程，并需要熟悉新的概念和技术。因此，采用服务网格实现是一个长期决策，特别是在广泛支持服务网格之前。因此，应提前仔细比较和测试这些实现。
评估的目标是弄清楚哪些功能对你更重要，由于服务网格会影响延迟和资源消耗，这些不利因素也必须进行衡量。我们建议在决策过程中包括以下步骤：
- 作为团队，确定由服务网格解决的最重要的问题。
- 讨论你对简单性/易用性、性能和兼容性的要求。
- 根据你的功能和非功能要求，确定你的前两个或三个实现。
- 测试你的个别应用程序的延迟和资源开销。针对每个服务网格候选者，设置相同的测试环境并安装服务网格。设置一个额外的无网格环境。在所有环境中安装您的应用程序。使用 Locust 或 Fortio等工具在所有环境中进行负载测试，并测量请求延迟、CPU 和内存消耗。
如果你没有对这些服务网格技术做详细的评估了解，那么你可以从 Istio开始，它是一个开源的服务网格，它提供了一些强大的功能，例如流量管理、策略执行、服务间通信、可观察性等。Istio 是一个非常活跃的开源项目，它有一个非常活跃的社区，它的文档也非常丰富，可以帮助你快速上手 Istio，目前 Istio 是最好的选择。
4、Istio 基础架构
- isio官网
上次更新时间: