一、场景引入

如果我们前期的微服务没有相关的服务治理功能，要对所有的微服务做一些升级该如何下手？主要包括服务治理：监视、日志记录、限流、熔断、服务注册、协议适配转换等。

下面介绍的边车模式就是很好解决该问题的一个方法之一。

二、什么是边车模式

边车模式也叫搭档模式、伴侣模式或跟班模式。生活中的原型就是在原来二轮摩托车旁边增加一个座位成了三轮摩托车,增加的一部分称为边车，如图：

三、边车模式设计思想

边车（Sidecar）模式设计思想的核心是将控制和逻辑分离，常用于我们在分布式架构中的逻辑和控制分离设计。迁移到我们的分布式架构中就是：我们不需要在服务中实现控制面上的东西，如监视、日志记录、限流、熔断、服务注册、协议适配转换等这些属于控制面上的东西，而只需要专注地做好和业务逻辑相关的代码，然后，由“边车”来实现这些与业务逻辑没有关系的控制功能。

以 Sidecar 的方式，对应用服务没有侵入性，并且不用受到应用服务的语言和技术的限制，而且可以做到控制和逻辑的分开升级和部署。但是，这样一来，增加了每个应用服务的依赖性，也增加了应用的延迟，并且也会大大增加管理、托管、部署的复杂度。注意，对于一些“老的系统”，因为代码太老，改造不过来，我们又没有能力重写。比如一些银行里很老的用 C 语言或是 COBAL 语言写的子系统，我们想把它们变成分布式系统，需要对其进行协议的改造以及进行相应的监控和管理。这个时候，Sidecar 的方式就很有价值了。因为没有侵入性，所以可以很快地低风险地改造。Sidecar 服务在逻辑上和应用服务部署在一个结点中，其和应用服务有相同的生命周期。对比于应用程序的每个实例，都会有一个 Sidecar 的实例。Sidecar 可以很快也很方便地为应用服务进行扩展，而不需要应用服务的改造。比如：Sidecar 可以帮助服务注册到相应的服务发现系统，并对服务做相关的健康检查。如果服务不健康，我们可以从服务发现系统中把服务实例移除掉。当应用服务要调用外部服务时， Sidecar 可以帮助从服务发现中找到相应外部服务的地址，然后做服务路由。Sidecar 接管了进出的流量，我们就可以做相应的日志监视、调用链跟踪、流控熔断……这些都可以放在 Sidecar 里实现。然后，服务控制系统可以通过控制 Sidecar 来控制应用服务，如流控、下线等。

注意，如果把 Sidecar 这个实例和应用服务部署在同一台机器中，那么，其实 Sidecar 的进程在理论上来说是可以访问应用服务的进程能访问的资源的。比如，Sidecar 是可以监控到应用服务的进程信息的。

另外，因为两个进程部署在同一台机器上，所以两者之间的通信不存在明显的延迟。也就是说，服务的响应延迟虽然会因为跨进程调用而增加，但这个增加完全是可以接受的。

另外，我们可以看到这样的部署方式，最好是与 Docker 容器的方式一起使用的。为什么 Docker 一定会是分布式系统或是云计算的关键技术，相信你从我的这一系列文章中已经看到其简化架构的部署和管理的重要作用。否则，这么多的分布式架构模式实施起来会有很多麻烦。

四、边车模式注意事项

边车模式着重需要关注控制和逻辑的分离、服务调用中上下文的问题。然后还需要注意如下一些事项：

1、进程间通讯机制是这个设计模式的重点，千万不要使用任何对应用服务有侵入的方式，比如，通过信号的方式，或是通过共享内存的方式。最好的方式就是网络远程调用的方式（因为都在 127.0.0.1 上通讯，所以开销并不明显）

2、服务协议方面，也请使用标准统一的方式。这里有两层协议，一个是 Sidecar 到 service 的内部协议，另一个是 Sidecar 到远端 Sidecar 或 service 的外部协议。对于内部协议，需要尽量靠近和兼容本地 service 的协议；对于外部协议，需要尽量使用更为开放更为标准的协议。但无论是哪种，都不应该使用与语言相关的协议

3、使用这样的模式，需要在服务的整体打包、构建、部署、管控、运维上设计好。使用 Docker 容器方面的技术可以帮助你全面降低复杂度

4、Sidecar 中所实现的功能应该是控制面上的东西，而不是业务逻辑上的东西，所以请尽量不要把业务逻辑设计到 Sidecar 中

5、小心在 Sidecar 中包含通用功能可能带来的影响。例如，重试操作，这可能不安全，除非所有操作都是幂等的。

6、另外，我们还要考虑允许应用服务和 Sidecar 的上下文传递的机制。例如，包含 HTTP 请求标头以选择退出重试，或指定最大重试次数等等这样的信息交互。或是 Sidecar 告诉应用服务限流发生，或是远程服务不可用等信息，这样可以让应用服务和 Sidecar 配合得更好

五、边车模式使用场景

使用场景：

一个比较明显的场景是对老应用系统的改造和扩展。

另一个是对由多种语言混合出来的分布式服务系统进行管理和扩展。

其中的应用服务由不同的供应商提供。

把控制和逻辑分离，标准化控制面上的动作和技术，从而提高系统整体的稳定性和可用性。也有利于分工——并不是所有的程序员都可以做好控制面上的开发的。

不适应场景：

架构并不复杂的时候，不需要使用这个模式，直接使用 API Gateway 或者 Nginx 和 HAProxy 等即可。

服务间的协议不标准且无法转换。

不需要分布式的架构。

分布式设计之边车模式（Sidecar）相关推荐

分布式系统治理-边车模式 sidecar
所谓的边车模式,对应于我们生活中熟知的边三轮摩托车.也就是说,我们可以通过给一个摩托车加上一个边车的方式来扩展现有的服务和功能.这样可以很容易地做到 " 控制 " 和 " ...
分布式服务之边车模式
边车模式边车:就是在原来二轮摩托车旁边增加一个座位成了三轮摩托车,增加的一部分称为边车边车模式:对现有的服务增加额外的功能,这些功能并不影响业务逻辑,例如增加日志,限流.熔断.服务的注册和服务发现 ...
istio学习笔记2:边车模式sidecar
Sidecar 是什么将本将属于应用程序的功能拆分成单独的进程,这个进程可以被理解为sidecar.在微服务体系内,将集成在应用内的微服务功能剥离到了sidecar内,sidecar提供了微服务发现 ...
转载 -- 边车模式（sidecar）和服务网格（server mesh）
不羡鸳鸯不羡仙,一行代码调半天.原创:小姐姐味道(微信公众号ID:xjjdog),欢迎分享,转载请保留出处. 哎,又堵车了. 记性好的同学,一定记得我们那辆敞快明亮的JMC .拥有一辆JMC,任嘶吼的 ...
ServiceMesh的关键：边车模式（sidecar）；又要开车了
不羡鸳鸯不羡仙,一行代码调半天.原创:小姐姐味道(微信公众号ID:xjjdog),欢迎分享,转载请保留出处. 哎,又堵车了. 记性好的同学,一定记得我们那辆敞快明亮的JMC .拥有一辆JMC,任嘶吼的 ...
老九学堂之分布式设计教材
老九学堂之分布式设计教材作者:老九-技术大黍原文:分布式系统设计教材社交:知乎公众号:老九学堂(新人有惊喜) 特别声明:原创不易,未经授权不得转载或抄袭,如需转载可联系笔者授权前言本文由老 ...
基于Spring Cloud + MyBatis的分布式架构网约车平台（DD 打车）后端原型系统设计与实现
资源下载地址:https://download.csdn.net/download/sheziqiong/85638879 资源下载地址:https://download.csdn.net/downl ...
分布式设计与开发（四）------数据拆分
一个大型系统里各个环节中最容易出性能和可用性问题的往往是数据库,因此分布式设计与开发的一个重要领域就是如何让数据层具有可扩展性,数据库的扩展分为Scale Up 和Scale Out,而Scale U ...
系统和分布式设计专题
1.模块化的好处那么什么是模块化呢?< Java 应用架构设计:模块化模式与 OSGi >一书中对它的定义是:模块化是一种处理复杂系统分解为更好的可管理模块的方式.为什么模块间解耦,复用 ...

分布式设计之边车模式（Sidecar）