左耳听风_055_54_管理设计篇之边车模式
你好，我是陈浩网名猪耳朵house.那今天呢我们来讲一下编车模式啊，也就是sidecar模式。
那所谓的编车模式呢，它对应于我们生活中熟知的边三轮摩托车。
也就是说呢，我们可以通过一个给摩托车加上一个编车的方式，来扩展现有的服务和功能。
那这样呢就可以很容易的做到控制和逻辑的分离。
也就是说呢，我们不需要在服务中实现控制面上的东西，比如监视日志记录、限流、熔断服务、注册协议、适配转换等。
这些属于控制面上的东西，而只需要专注的做好和业务逻辑相关的代码，然后呢由编车来实现这些与业务逻辑没有关系的控制功能。
首先呢我们来谈一谈边车模式的设计。
那具体来说呢，你可以理解为边车啊就有点像一个服务的agent.那这个服务所有对外进出的通讯呢都通过这个agent来完成。
那这样呢我们就可以在这个agent上面啊做很多的文章了。
但是呢我们需要保证的是，这个agent要和应用程序啊一起创建一起停用。
那编车模式呢有时候也叫搭档模式啊，或者伴侣模式，或者呢是跟班模式。
就像我们在编程范式游记中所看到的那样，编程的本质呢就是将控制和逻辑分离和解耦。
而编车模式呢也是异曲同工。
能同样是让我们在分布式架构中做到逻辑和控制的分离。
那对于监视日志、限流、熔断服务、注册协议转换等等这些功能啊啊其实都是大同小异，甚至啊完全是可以做成标准化的组件和模块的那一般来说呢我们有两种方式，一种呢是通过SDK lib啊或者framework软件包的方式，在开发的时候与真实的应用程序啊集成起来。
那另一种呢就是通过像sidecar这样的方式，在运维的时候，与真实的应用服务啊集成起来。
那这两种方式啊各有优缺点，以软件包的方式呢可以和应用密切集成，有利于资源的利用和应用的性能。
但是呢对应用有侵入，而且啊受应用的编程语言和技术限制。
同时呢当软件包升级的时候，需要重新编译并重新发布应用。
而以set card的方式呢对应用服务啊没有侵入性，并且呢不用受到应用服务的语言和技术的限制，而且呢还可以做到控制和逻辑的分开升级和部署。
但是呢这样一来啊，却增加了每个应用服务的依赖性，也增加了应用的延迟，并且啊也会大大的增加管理托管和部署的复杂度。
注意啊，对于一些老的系统呢，因为代码太老了，改造不过来，我们呢又没有能力去重写。
比如一些银行里很老的用c语言或者cople语言写的子系统。
那我们呢想把它变成分布式系统，就需要对它呀进行协议的改造和进行相应的监控和管理。
那这个时候呢set car的方式啊就很有价值了。
因为没有侵入性，所以呢就可以很快的低风险的改造。
三个car服务在逻辑上和应用服务啊部署在一个节点中，它和应用服务有相同的生命周期。
那对比于应用程序的每个实例呢都会有一个sedcard的实例。
Set car可以很快也很方便的的对应用服务啊进行扩展，而不需要对应用服务进行改造。
比如呢第一sed car可以帮助服务注册到相应的服务发现系统，并且呢对服务做相关的健康检查。
那如果服务不健康呢，我们就可以从服务发现系统中啊，把服务实例移除掉。
那第二呢，当应用程序要调用外部服务的时候，sed car可以帮助从服务发现中找到相应外部服务的地址，然后呢做服务路由。
第三呢，sidcar接管了进出的流量，我们呢就可以做相应的日志监视，调用链跟踪，还有流控熔断等等。
那这些呢都可以放到sedecar里面去实现。
然后呢服务控制系统可以通过控制sidecar来控制应用服务啊，比如流控还有下线等等。
于是呢我们的应用服务啊就可以完全做到专注于业务逻辑。
你可以参看文中我展示的这幅图要注意。
如果把side car这个实例和应用服务部署在同一台机器中呢，那么其实side card的进程啊，在理论上来说呢，是可以访问应用服务的进程所能访问的资源的。
比如sidecar是可以监控到应用服务的进程信息的。
另外呢，因为两个进程部署在同一台机器上，所以两者之间的通信呢不存在明显的延迟。
也就是说呢，服务的响应延迟虽然会因为跨进程调用而增加，但是这个增加完全是可以接受的那另外呢我们可以看到这样的部署方式啊，最好是与docker容器的方式一起使用的那为什么docker一定会是分布式系统或者云计算的关键技术？啊，相信你从我的这一系列文章中啊，已经看到了它简化架构的部署和管理的重要作用。
否则啊这么多的分布式架构模式啊，实施起来会有很多的麻烦。
那最后呢我们来说一说编车设计的重点。
首先呢我们需要知道编车模式重点解决什么样的问题。
那第一呢是控制和逻辑的分离。
那第二呢是服务调用中上下文的问题。
我们知道熔断路由服务发现、计量流控、监视、重试密等，还有健全等等。
控制面上的功能和它相关的配置更新，本质上来说呢和服务的关系啊并不大。
但是呢传统的工程做法呢是在开发层面完成这些功能。
那这样呢就会导致各种维护上的问题，而且呢还会受到特定语言和编程框架的约束和限制。
而随着系统架构的复杂化和扩张，我们呢需要更统一的管理和控制这些控制面上的功能。
所以传统的在开发层面上完成控制面的管理啊，会变得非常的难以管理和维护。
那这就使得我们需要通过sidecar模式来架构。
我们的系统编程模式呢从概念上理解起来是比较简单的。
但是呢在工程实现上来说呢，需要注意这么几点。
那第一呢进程间的通讯机制啊是这个设计模式的重点。
千万不要使用任何对应用服务有侵入的方式啊，比如通过信号的方式啊或者共享内存的方式。
那最好的方式呢就是通过网络远程调用的方式啊，因为都在幺二七点零零幺上通讯，所以呢开销并不明显。
那第二呢，在服务协议方面也请要使用标准统一的方式。
那这里呢有两层协议，一个是side car到service的内部协议。
那另一个呢是side car到远程side car或者service的外部协议。
那对于内部协议呢，需要尽量靠近和兼容本地service的协议。
那对于外部协议呢，需要尽量使用更为开放、更为标准的协议。
但无论是哪种啊，都不应该使用与语言相关的协议。
那第三呢，使用这样的模式，需要在服务的整体打包构建部署、管控。
运维上设计好使用docker容器方面的技术，可以帮助你全面的降低复杂度。
那第四呢，seatcar中所实现的功能啊，应该是控制面上的东西，而不是业务逻辑上的东西。
所以呢请尽量不要把业务逻辑涉及到sedecar当中。
那第五呢我们需要小心在sidecard中包含通用功能可能会带来的影响啊，比如重试操作。
那这个呢可能不安全啊，除非所有操作都是幂等的。
另外呢我们还要考虑允许应用服务和sed card的上下文传递的启示。
例如包含HTTP请求标头，以选择退出重试或者指定最大重试次数等等这样的信息交互，或者是seatar告诉应用服务限流发生啊，或者呢是远程服务不可用等信息。
那这样呢可以让应用服务和sid car配合的更好。
那当然呢我们需要清楚set car适用于什么样的场景。
那这里呢我罗列几个。
那第一呢比较明显的场景就是对老应用系统的改造和扩展。
那第二呢就是对多种语言混合出来的分布式服务系统进行管理和扩展。
那第三呢就是其中的应用服务啊，由不同的供应商所提供。
那第四呢就是把控制和逻辑分离标准化，控制面上的动作和技术，从而提高系统整体的稳定性和可用性，同时呢也有利于分工。
因为并不是所有的程序员都可以做好控制面上的开发的那同时呢我们还要清楚sidecar不适用于什么样的场景。
那这里呢我也罗列几个。
那第一呢就是架构啊并不复杂的时候，我们不需要使用这个模式，直接使用API gateway或者engines和HA proxy就可以了。
那第二呢，就是服务间的协议不标准，而且无法转换的时候。
那第三呢就是不需要分布式的架构的场景。
好了，我们来总结一下今天分享的主要内容。
首先呢我介绍了什么是编车模式。
为了把监视日式限流等这样的控制逻辑与业务逻辑分离解耦，我们呢就可以采用编车模式，与之对应的另一种实现控制逻辑的方式呢是库或者框架。
虽然相对来说啊鞭策模式资源消耗比较大，但控制逻辑不会侵入业务逻辑，还能适应遗留老系统的低风险改造。
那编车作为另一个进程，可服务进程呢部署在同一个起点中，通过一个标准的网络协议，比如HTTP来进行通信。
那这样呢就可以做到低延迟和标准化。
那同时呢用docker来打包编车和服务，两者就可以非常方便的部署。
那最后呢我指出了编车模式适用和不适用的场景。
在下节课中呢，我们会讲述服务表格，希望对你有帮助，也欢迎你来分享一下。
你实现服务的同时啊，有没有实现编车模式呢？有没有用到docker来打包编车和服务这两个呢？国末呢我给出了分布式系统模式系列文章的目录啊，希望你能在这个列表里啊找到自己感兴趣的内容。