Sidecar

Sidecar(边车)模式是一种将应用功能从应用本身剥离出来作为单独进程的方式。该模式允许我们向应用无侵入添加多种功能，避免了为满足第三方组件需求而向应用添加额外的配置代码。

在云环境下，技术栈可以是多种多样的。那么如何能够将这些异构的服务组件串联起来，成为了服务治理的一个重大课题。而Sidecar模式为服务治理，提供了一种解决方案。
将应用程序的组件部署到单独的进程或容器中，以提供隔离和封装。此模式还可以使应用程序由异构组件和技术组成。因为它类似于连接到摩托车的边车，所以也叫边车模式。在该模式中，边车附加到父应用程序并为应用程序提供支持功能。
sidecar还与父应用程序共享相同的生命周期，与父项一起创建和退役。

边车服务不一定是应用程序的一部分，而是与之相关联。它适用于父应用程序的任何位置。
Sidecar支持与主应用程序一起部署的进程或服务。这就像是如上图所示的边三轮摩托车那样，将边车安装在一辆摩托车上，就变成了边三轮摩托车。每辆边三轮摩托车都有自己的边车。类似同样的方式，边车服务共享其父应用程序的主机。对于应用程序的每个实例，边车的实例被部署并与其一起托管。

使用边车模式的优点包括：

• 在运行时环境和编程语言方面，边车独立于其主要应用程序，因此不需要为每种语言开发一个边车。
• 边车可以访问与主应用程序相同的资源。例如，边车可以监视边车和主应用程序使用的系统资源。
• 由于它靠近主应用程序，因此在它们之间进行通信时没有明显的延迟。
• 即使对于不提供可扩展性机制的应用程序，也可以使用边车通过将其作为自己的进程附加到与主应用程序相同的主机或子容器中来扩展功能。

Sidecar模式通常与容器一起使用，并称为边车容器。

编写Sidecar微服务
1、创建项目，添加Eureka、Sidecar的依赖：

<dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-netflix-sidecar</artifactId>
</dependency>
<dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-starter-eureka</artifactId>
</dependency>

2、启动类上加上@EnableSidecar注解。

这是一个组合注解，它整合了三个注解，
分别是@EnableCircuiBreaker和@EnableDiscoveryClient。

3、在配置文件中加入端口号、服务名称、Eureka地址以及Web项目的端口以及健康检查地址，如：

server.port=8887
spring.application.name=sidecar-mylife-service
eureka.client.serviceUrl.defaultZone=http://localhost:8881/eureka/
eureka.client.instance.prefer-ip-address=true
sidecar.port=8080
sidecar.health-uri=http://localhost:8080/health
eureka.instance.hostname=localhost

Sidecar的一些端点

以下是Sidecar的常用端点：

• /hosts/{serviceId} 指定微服务在Eureka上的实例列表
• /ping 返回OK字符串
• /{serviceId} 请求对应的微服务

Sidecar 代理服务注册发现

下图为异构服务通过sidecar接入注册中心。异构服务本身可能为非Java或传统应用，接入困难。
异构服务本身不会和注册中心有请求调用，而是通过sidecar代理注册接入注册中心，获得服务注册、发现等功能。

Sidecar 代理异构服务发起服务调用

异构服务本身不和注册中心有直接联系，所以异构服务的调用也需要走sidecar，通过sidecar进行服务发现调用，sidecar收到异构服务的请求后通过服务发现和负载均衡选中目标服务实例，转发请求至目标服务。

异构服务如何被调用

如果异构服务为服务提供方（会被其它服务调用），服务发起方会先注册中心发现sidecar代理注册的实例信息，将请求发送到Sidecar，Sidecar将请求转发给异构服务完成调用请求。

Sidecar模式是如何工作的

服务网格层可以存在于与应用程序一起运行的Sidecar容器中，每个应用程序旁边都附有相同的Sidecar副本。
来自单个服务的所有传入和传出网络流量，都流经Sidecar代理。因此，Sidecar能够管理微服务之间的流量，可收集数据并实施相关策略。
从某个角度来说，应用并不需要了解网路外部的系统，只需要知道附加的Sidecar代理，这就是Sidecar模式：Sidecar工作模式的本质：将网络依赖抽象为Sidecar。

在服务网格中，有数据平面和控制平面的概念：

• 数据平面：职责是处理网格内部服务间的通信，并负责服务发现、流量管理、健康检查等功能。
• 控制平面：职责是管理和配置Sidecar代理，以实施策略并收集遥测。

在Kubernates和Istio世界中，可以将Sidecar注入Pod内，Istio使用代用Envoy的Sidecar模型作为代理。

来自Lyft的Envoy是为云原生应用程序设计的最流行的开源代理。Envoy依附着每项服务运行，并以平台无关的方式提供必要的功能，所有的服务流量都通过Envoy代理流动。