Android和Docker的一致架构设计(4)
-- <分合自如>的设计模式(Design Pattern)
两支App分别跑在两个不同的集装箱里，然后透过 Docker平台的通信协议(如REST)来交互信息。有一天，维运人员为了节省资源而把这两地集装箱里的两支App加以<合并>到同一个集装箱里运行，却不需要开发者更改两支App的代码。
By 高焕堂 (台灣Docker論壇 主席)
misoo.tw@qq.com 2015/03/09
高煥堂的相關文章：
A01、从「集装箱」思考Docker风潮：Docker潮流下的赢家策略
A02、Docker：从容<器>到集装箱设计之<道>
B01、Android和Docker的一致架构设计(1)：追求今天决策的未来性
B02、Android和Docker的一致架构设计(2)：包装<跨集装箱>的通信协议
B03、Android和Docker的一致架构设计(3)：建立企业主的<核心集装箱>
前言：Docker集装箱的<分合自如>设计
本文是针对“DevOps”范围里的一个特别而有趣的议题。就是：在开发者的心智模式(Mental model)里，他撰写的两支App(或者是一支App里的两个模块)，分别跑在两个不同的集装箱里，然后透过 Docker平台的通信协议(如REST)来交互信息，而且都运行得很顺利。有一天，云平台的维运人员，为了节省资源而把这两地集装箱里的两支App加以<合并>到同一个集装箱里运行，却不需要通知开发者更改两支App(或两个模块)的代码。兹详细说明如下。
首先，为了运行集装箱，我们需要有个Docker 核心(即Docker Engine)。
图-1、Docker 核心
开发者依据他的心智模式，设想两个个模块分别在不同的集装箱上运行，然后就撰写了DockerFile脚本，并传递给云平台的维运人员，准备让Docker Engine来读取这个脚本文件。
图-2、Docker Engine会参考DockerFile脚本
于是，Docker Engine就依据这个脚本的配置指示(如下图里的Config. Script-A)来创建了两个集装箱。
图-3、依据Script-A而布署
这Script-A表达了开发者的意图：Client App与Server App之间是跨集装箱的通信和交互。有一天，维运人员想把两支App合并到同一个集装箱里运行，于是修改了脚本里的Config. Script指示。
图-4、改变了Config. Script内容
例如，将配置脚本改写为Config. Script-B(如下图所示)。然后，透过Docker Engine来重新布署。于是，Docker Engine就依据这个新脚本的配置指示来创建了一个新集装箱。
图-5、重新布署了
此时，并不需要要求开发者修改其源代码，甚至其代码镜像都可以保持原状，直接合并到同一个集装箱就行了。这种优越的架构设计，让维运者拥有更大的空间，也让“DevOps”合作体验更上层楼。
图-6、分合自如的“DevOps”合作体验
自然界生物之设计，其主要限制是：信息的有限性（Information Limitations）。由于这项限制，一个生物形体的造成，是出自一个概括性的计划：<单纯的造形>。随着生物的成长、与环境的交互信息越多，逐渐在细节上修修补补，就发展出<不同的内涵>。然后，基于单纯的造形，不断进行<重复的组合>。这就是集装箱三项特性(或特质)的来源。例如，漂亮的枫叶林，就是合乎“单纯造形、不同内涵、重复组合”三项特性。许多造形相同（且不同细节）的枫叶，组合出一遍美丽的树林，如下图：
图-7、重复组合出美丽
再如人们的手掌的造形也都极为相似，其细节纹路也各不相同，也满足上述三项特性。关于<信息的有限性>与自然造物法则，在生物学界的探讨论文已经非常多了。在此就不多叙述了。在软件设计方面，开发者也是受限于<信息的有限性>，必须透过优越的架构设计，来提供给后续维运人员依据布署环境的现实条件而进行修修补补。唯有开发者避免过度设计(Over-Designed)，不要冻结未来(Frozen Future)，才能认维运人员高度发挥Docker集装箱的潜能和魅力。本文内容包括下列三个小节，敬请继续阅读与指教：
ee ee
~ End ~
