薄情先生|Docker，容器，编排，和基于容器的系统设计模式( 四 ) 都2020年了

主要有以下几种设计模式。
Sidecar pattern（边车模式）边车，这个词可能很多人没听过（包括我了解这个东西之前）。我们先来贴一下边车的图，
边车就是摩托车旁边的那个小车，在某些环境下（比赛，我猜的），旁边车上的人可以给车手递水、食物等操作。
边车模式也是类似的，即在主服务（的容器， main container）身边提供一个辅助容器，帮助主服务做一些脏活累活。
比如一个web应用，它会将日志信息写入到磁盘中，这时候我们就可以新增加一个日志采集的边车，协助web服务完成日志采集的工作。就像下面这样：
还是挺好理解的，这样的好处，相信了解过设计模式的童鞋随随便便就能列举几个，不过这里还是从容器的角度详细介绍下：

容器是资源分配的一个单元。将边车服务分离后，可以更加灵活地通过cgroup配置资源，或者一些动态调节资源的操作（比如忙时给web服务更多资源而边车更少资源）。
容器是最小的打包单位。有助于不同服务的责任划分和测试。
容器可以是复用的单位，比如可以将日志服务用语其他服务。
提供了错误边界，可以使系统可以正常降级，比如日志服务出错，不会导致web服务出错。
容器是最小的部署单位，可以为每个服务升级，和回滚。但这也可能是缺点，因为服务一多难以管理。

因为分离所以多了这些好处，听起来还是蛮诱人的~
Ambassador pattern（外交官模式）外交官模式，提供一个容器作为代理与主服务（main container）通信。
就相当于在通信口出做多一层代理，比如主服务以为是与一个本地redis通信，但实际上代理会真正与一个redis集群交互。

外交官模式的好处是，让主服务与外部组件之间相互隔离。只通过代理的话，那么外部组件可以无缝进行替换，而这一切主服务都是无感知的。然后是方便测试和复用，其实就是服务之间解耦的好处啦，和上面边车模式是有点类似的。
Adapter pattern（适配器模式）前面说的两种模式，主要是为了帮助主服务（main coninter）更专注于自己的职责。而适配器模式则是为了方便其他组件。
举个例子，假设你有多个服务（web ，数据库，缓存服务等），然后需要一个监控监控这几个组件是否正常。正常情况下，需要让监控系统获取不同服务之间的指标信息，然后才能进行监控。
但这样的问题是，如果增加或减少服务，那么对监控系统来说会很麻烦。适配器模式能够解决这种困扰。
如果多个服务， web ，数据库，缓存等都提供一个统一的对外接口，那么我们就能够使用一个适配器容器，统一获取这些服务的指标信息，然后由监控系统通过这个适配器容器统一获取所有的指标信息。如下图所示。

OK ，那么以上就是单节点协作情况下的三种设计模式，下面再看看多节点的协作模式。
多节点协作模式这部分内容会比较简单一些，这里就不花太多篇幅进行讲述。