基于docker的设计模式

一. 面向对象和设计模式

设计模式（Design pattern）代表了最佳的实践，通常被有经验的面向对象的软件开发人员所采用。使用设计模式的目的：为了代码可重用性、让代码更容易被他人理解、保证代码可靠性。设计模式是在面向对象技术出现以后，由工程师们总结出来的宝贵经验。其中，最主要的23种设计模式，收录在【Design Patterns: Elements of Reusable Object-Oriented Software】一书中

设计模式的细节可能不同，但是总体的设计思想和原则都遵循如下：
单一职责原则 （Single Responsiblity Principle SRP）
开闭原则（Open Closed Principle，OCP）
里氏代换原则（Liskov Substitution Principle，LSP）
依赖倒转原则（Dependency Inversion Principle，DIP）
接口隔离原则（Interface Segregation Principle，ISP）
合成/聚合复用原则（Composite/Aggregate Reuse Principle，CARP）
最小知识原则（Principle of Least Knowledge，PLK，也叫迪米特法则）

二. 引入docker技术带来的新变化

随着docker技术和微服务的日趋成熟。怎样合理的设计container的边界职责和协作带来了新的挑战。这个问题和面向对象及其之上的设计模式要解决的问题十分类似。container 相当于object，image相当于Class定义

三. 3种抽象设计模式

1. single-container patterns for container management

• container本身提供了类似Object一样的封闭性
  container暴露的interface相当于类暴露的public方法
  例如，container的资源使用情况，健康情况，等等
  container生命周期的hooks，比如：created，started，before termination等等
  container的可复制性-replica：类似拷贝构造函数

2. single-node patterns of closely cooperating containers

• sidecar pattern
  在主要工作的container之外，挂载一个"保姆container"。二者一起提供某种服务。kubernetes中的pod实现了类似的思想。其中"保姆container"可以被复用。

  
  
  

  sidecar pattern
  
  

  上图中的"保姆container"提供了日志收集的功能，职责分离，可以分别单独测试，可以被复用
  这样设计的另一个好处是：可以分开升级，不相互影响。"保姆container"可以关闭，降级服务

• ambassador pattern
  代理模式。一个额外的代理container负责与外部的分布式服务通讯，简化、屏蔽了外部系统的复杂性。主container只需要假设和localhost的进程通讯即可

ambassador pattern

如上图，代理container可以负责与外部的分布式存储连接提供容错，负载均衡等功能。该container可以被复用

• Adapter pattern

  
  
  

  Adapter pattern
  
  

  如上图，adapter container 适配了不同的主container和统一的监控框架之间的信息差异。同样，adapter container 也可以方便的复用

3. multi-node patterns for distributed algorithms

• leader election pattern
  原来的选主操作需要application集成lib来实现，如：集成raft协议的lib来实现。另一个更好的选择是使用一组带leader election 功能的“保姆container”来实现。application需要区分主从的时候，依赖本pod的“保姆container”状态来区分。带leader election的container可以复用

• work queue pattern
  使用docker 灵活的启动消费Worker container来处理Queue中的Job
  一个真实Use Case：视频处理, 1pod分析处理1个mp4视频文件，并且使用gpu硬件加速

work queue pattern

灰色的worker container中基础框架部分，可以重用
kubernetes 原生支持此workload类型： Job

• scatter/gather pattern
  这种模式在搜索引擎中十分常见。整体后端服务，是一个树形的结构。根节点接收/分发query给不同的库，之后，整合，rank不同库的返回结果，返回给用户

scatter/gather pattern

如上图，灰色的container完成了并发的分发，和整合数据的复杂操作，可以复用。用户自定义的逻辑container可以方便的在之上做进一步操作处理

综合上述的3种设计模式。个人觉得，基于docker的设计模式有如下的优点
1）更好地拆分服务(模块，containers)给不同的team，支持各种语言，提高研发效率。微服务架构也是类似
2）更高级别的复用模块，如：一个container整体通过配置，可以很方便地添加到一套新的分布式系统中去，想拼积木一样，灵活插拔

四. 参考

1. 【Design patterns for container-based distributed systems】
2. 【Kubernetes Production Patterns and Anti-Patterns】