大家好，我是 Snow Hide，作为《左耳听风》这个专栏的学员之一，这是我打卡的第 24 天，也是我第 24 次进行打卡这种操作。
今天我温习了该专栏里一篇叫《管理设计篇之“边车模式”》的文章。
关键词总结：边车模式设计（实现方式、优缺点）、边社设计重点（解决的问题）、边车设计注意事项（进程间通讯、服务协议标准化、应用容器技术、边车职责、边车操作、上下文传递机制）、边车设计适用的场景（扩展历史遗留系统、多语言环境、多个服务供应商、控制以及逻辑分离）、边社设计不适用的场景（架构不够复杂、服务间协议不统一、单体架构）。
所学总结：
边车模式设计
实现方式
- SDK、Lib 或框架的方式；
- 边车的方式。
优缺点
- 软件包：有侵入；
- 边车：无侵入、增加复杂度、服务注册及健康检查、帮助服务发现寻址、日志监控、调用链跟踪、流控熔断、易于服务控制系统操作。
边社设计重点
解决的问题
- 将控制和逻辑进行分离；
- 解决服务调用中上下文的问题；
- 对控制类的功能进行统一地管控。
边车设计注意事项
进程间通讯
使用无侵入的方式。
服务协议标准化
使用标准统一的方式进行沟通。
应用容器技术
借助容器来降低各种复杂度。
边车职责
让边车只实现控制类的功能。
边车操作
尽量避免在边车里包含重试操作，除非操作是幂等的。
上下文传递机制
允许应用服务和边车的上下文进行传递操作。
边车设计适用的场景
扩展历史遗留系统
在对老系统进行改造维护时。
多语言环境
在由多种语言所组成的分布式系统中。
多个服务供应商
在由不同供应商提供的服务中。
控制以及逻辑分离
将控制和逻辑进行分离的场景。
边社设计不适用的场景
架构不够复杂
不适用于架构没有特别的复杂的时候。绝大多数情况下可以借助 API 网关、负载均衡或高可用代理等系统来实现。
服务间协议不统一
不适用于服务间通讯协议不统一并且不容易转换的场景中。
单体架构
不适用于没有分布式系统或服务的架构中。
末了
重新总结了一下文中提到的内容：便车模式、控制逻辑与业务逻辑分理解耦、遗留老系统的低风险改造、进程间通讯、Docker 打包边车和服务、便车模式适用/不适用的场景。
来源：CSDN
作者：Snow Hide
链接：https://blog.csdn.net/stevenchen1989/article/details/103884645