新一代微服务知识充电
前言
科普一下相关名词解释
- 注册中心：服务提供者将自己提供的服务以及地址登记到注册中心，服务消费者则从注册中心查询所需要调用的服务的地址，然后发起请求。
- 服务注册，将提供某个服务的模块信息（通常是服务的ip和端口）注册到1个公共的组件上去（如 zookeeper）。
- 服务发现，将新注册的这个服务模块能够及时的被其他调用者发现。新增和删减都能实现自动发现。
- RPC：全称是 Remote Procedure Call 是一种进程间通信方式。A服务器上应用，想要调用B服务器上应用提供的函数或者方法，可以通过RPC框架的实现来解决
- 熔断：当某个服务发生故障时，通过熔断该服务的调用，可以避免故障扩散到其他服务，从而保护整个系统的稳定运行。适用于高并发、高负载场景，可以避免因个别服务的故障导致整个系统负载过高。
- 降级：在服务器压力剧增的情况下，根据实际业务情况及流量，对一些服务和页面有策略的不处理或用一种简单的方式进行处理
- 服务网关：API网关，服务网关可以作为服务的统一入口，提供身份校验、动态路由、负载均衡、安全管理、统计、监控、流量管理、灰度发布、压力测试等功能
- SOA（Service Oriented Architecture）：面向服务的架构，是一种设计理念，包含多个服务，服务之间通过相互依赖最终提供一系列完成的功能。
一、传统微服务的弊端
1.1 代码侵入高
需要花费大量精力与框架和SDK进行结合，来提高框架在业务中融合，学习曲线陡峭。
1.2 开发语言单一
微服务提倡根据需求选择不同的开发语言进行开发，传统微服务架构多语言支持难度大，例如SpringCloud支持Java。
1.3 维护成本高
对老旧的系统来说，维护、治理、监控难度大，过渡期需要多个团队维护。
面对异构系统，需要大量精力进行维护。
二、新一代微服务
为了解决上述的传统弊端，ServiceMesh出现。
2.1 耦合阶段
在微服务架构中，服务发现、负载均衡、熔断等能力是微服务架构中重要的组成部分。微服务化之后，服务更加的分散，复杂度变得更高，起初开发者将诸如熔断、超时等功能和业务代码封装在一起，使服务具备了网络管控的能力。
优：
- 易于实现
劣：
- 基础设施功能（如：服务发现，负载均衡、熔断等）和业务逻辑高度耦合。
- 每个微服务都重复实现了相同功能的代码。
- 管理困难。如果某个服务的负载均衡发生变化，则调用它的相关服务都需要更新变化。
- 开发者不能只关注于业务逻辑开发。
2.2 公共库SDK
为基础设施功能设计为一个公共库 SDK，让服务的业务逻辑与这些公共功能降低耦合度，提高重复利用率，更重要的是开发者只需要关注公共库 SDK 的依赖及使用，而不必关注实现这些公共功能，从而更加专注于业务逻辑的开发，比如 Spring Cloud 框架是类似的方式。
优：
- 降低了服务的耦合度，提高代码利用率
- 开发者可以更好的关注业务逻辑开发
劣：
公共库 SDK学习成本较高，需要耗费一定的时间和人力与现有系统集成，甚至需要考虑修改现有代码进行整合。
公共库 SDK 一般都是通过特定语言实现，缺乏多语言的支持，在对现有系统整合时有一定的局限性。
公共库 SDK 的管理和维护依然需要耗费开发者的大量精力，并需专门人员来进行管理维护。
1.3 Sidecar模式(边车)
把框架作为一个代理，服务通过这个透明的代理完成所有流量的控制。
这就是典型的 Sidecar 代理模式，也被翻译为”边车”代理，它作为与其他服务通信的桥梁，为服务提供额外的网络特性，并与服务独立部署，对服务零侵入，更不会受限于服务的开发语言和技术栈，如下图所示。
优：
- 基础实施层与业务逻辑的完全隔离
- 真正的基础设施层与业务逻辑层的彻底解耦。
- 更灵活的扩展，而不需要应用服务的大量改造。
Sidecar主要功能：
- 服务注册： 帮助服务注册到相应的服务注册中心，并对服务做相关的健康检查。
- 服务路由： 当应用服务调用其它服务时，
Sidecar可以帮助从服务发现中找到相应的服务地址，完成服务路由功能。 - 服务治理 ：
Sidecar可以完全拦截服务进出的流量，并对其进行相应的调用链跟踪、熔断、降级、日志监控等操作，将服务治理功能集中在Sidecar中实现。 - 集中管控： 整个微服务架构体系下的所有服务完全可以通过
Sidecar来进行集中管控，完成对服务的流控、下线等。
1.4 Service Mesh
把 Sidecar 模式充分应用于一个庞大的微服务架构系统，为每个应用服务配套部署一个 Sidecar 代理，完成服务间复杂的通信，最终就会得到一个如下图所示的网络拓扑结构，这就是 Service Mesh，又称之为“服务网格“。
三、Service Mesh
在Service Mesh部署网络结构图中，绿色方块为应用服务，蓝色方块为 Sidecar，应用服务之间通过Sidecar进行通信，整个服务通信形成图中的蓝色网络连线，图中所有蓝色部分就形成了Service Mesh。其具备如下主要特点：
- 应用程序间通讯的中间层
- 轻量级网络代理
- 应用程序无感知
- 解耦应用程序的重试/超时、监控、追踪和服务发现
3.1 Service Mesh 功能
- 动态路由。 可通过路由规则来动态路由到所请求的服务，便于不同环境、不同版本等的动态路由调整。
- 故障注入。 通过引入故障来模拟网络传输中的问题（如延迟）来验证系统的健壮性，方便完成系统的各类故障测试。
- 熔断。 通过服务降级来终止潜在的关联性错误。
- 安全。 在
Service Mesh上实现安全机制（如TLS），并且很容易在基础设施层完成安全机制更新。 - 多语言支持。 作为独立运行且对业务透明的
Sidecar代理，Service Mesh很轻松地支持多语言的异构系统。 - 多协议支持。 同多语言一样，也支持多协议。
- 指标和分布式链路追踪。
主要体现在以下 4 个方面：
- 可见性： 运行时指标遥测、分布式跟踪。
- 可管理性： 服务发现、负载均衡、运行时动态路由等。
- 健壮性： 超时、重试、熔断等弹性能力。
- 安全性： 服务间访问控制、
TLS加密通信。
3.2 Service Mesh 解决的问题
基础设施层是Service Mesh的定位，致力于解决微服务基础设施标准化、配置化、服务化和产品化的问题。服务间通信是Service Mesh技术层面对的问题，对微服务屏蔽通信的复杂度，解决微服务的通信治理问题。
主要解决如下 3 个维度的痛点需求：
- 完善的微服务基础设施
- 开发者无需关心通信层的具体实现，也无需关注
RPC通信。像本地调用一样使用微服务，通信相关的一起工作直接交给Service Mesh。
- 开发者无需关心通信层的具体实现，也无需关注
- 语言无关的通信和链路治理
Service Mesh改变的是通信和服务治理能力提供的方式，通过将这些能力实现从各语言业务实现中解耦，一种更加通用和标准化的方式提供，屏蔽不同语言、不同平台的差异性
- 通信和服务治理的标准化
3.3 Service Mesh 原理
Service Mesh 的核心是数据平面 Sidecar 与控制平面 Control Plane，如下图：
数据平面Sidecar：
与服务部署在一起的轻量级网络代理，用于实现服务框架的各项功能（如，服务发现、负载均衡、限流熔断等），让服务回归业务本质。
数据平面可以认为是将
Spring Cloud、Dubbo等相关的微服务框架中通信和服务治理能力独立出来的一个语言无法的进程，并且更注重通用性和扩展性。在Service Mesh中，不再将数据平面代理视为一个个独立的组件，而是将这些代理连接在一起形成一个全局的分布式网格。服务节点只做业务逻辑自身的功能，服务之间的调用只需交给
Sidecar，由Sidecar完成注册服务、服务发现、请求路由、熔断限流、日志统计等业务无关功能。这个大型的服务网格并不是完全自治的，它还需要一个统一的控制节点
Control Plane。
控制平面 Control Plane：
是用来从全局的角度上控制 Sidecar，相当于 Service Mesh 架构的大脑，控制着 Sidecar 来实现服务治理的各项功能。
- 它负责所有
Sidecar的注册，存储统一的路由表，帮助各个Sidecar进行负载均衡和请求调度； - 它收集所有
Sidecar的监控信息和日志数据。
1 | 本文为个人知识学习，非原创！非作者！如本博客有侵权行为，请与我联系。 |