Sec-1：Android与Docker的设计模式

693579551

　　Android和Docker的一致架构设计(4)
-- 的设计模式(Design Pattern)
ee                                                   ee
[Back]

Sec-1、Android与Docker的设计模式
1.1 前言
  集装箱的威力来自于它的三项特质(或称特性)：。反过来说，无论是实物上或概念上(思维上)的东西，只要能兼具这三项特性者，都可称为集装箱。并非所有都兼具有这三项特性，至于Docker Container的目标上是想追求兼具这三项特质，所以Docker公司一直以码头工人自居，标举了他们向往的不是一般的，而是心怀这三项特质，力求真正的软件集装箱。
  基于上述的第三项特质，集装箱可以组合出形形色色更大的集装箱。俗语说：天外有天。同样的，可说：集装箱外有集装箱。当然也可说：集装箱内有集装箱。由内到外，层层相迭，而且层层皆无限组合，而组合出多采多姿的大自然风光。例如，玫瑰花就是一个造形，规范了花瓣、花蕊、花衬叶等有限元素的组合规律。同时它无限重复也大大影响（和简化）了整体树系统的组合规律。这项造物法则，提升了掌握自然界复杂多变的能力，唯有熟谙此道，才能创造架构(Architecture)和产品(Production)的未来性。所以，在我写的《思考软件，创新设计：A段架构师的思考技术》一书里，我提到了，架构师的核心思维有4个元素：愿景、组合、创新、未来性，如下图：
         
      图-8、架构师的核心思维
   对于客户（或企业）而言，愿景是目标，组合创新是手段；然而对于架构师而言，愿景则是手段，组合创新是目的。至于用户需求则代表现实性。愿景和需求都随时间而变，所以架构决策必须具有未来性。苹果乔布斯（Steve Jobs）说：
     “你不可能在眺望未来时把生活中的点点滴滴连接起来，只有在回顾时能才连点成线。”
   架构师清晰的愿景(Vision)并非要准确预测世界的未来景象，未来世界是不可知的。但是我们的目前决策会影响世界未来的发展轨迹。所以愿景是期望的未来景象；对架构师而言，它是手段，不是目的。真正的目的是：要找出有助于实现愿景的目前决策，这样的决策才真正具有未来性。刚才说过了，对于架构师而言，愿景则是手段，组合创新是目的。因此，本文就从的设计模式出发，发挥Docker集装箱的特质，为各企业开创出与众不同、气象万千的架构和产品，有效捕捉稍纵即逝的商机。
　　1.2 认识设计模式(Design pattern)
　　   围棋有棋谱、烹饪有食谱、武功有模式、战争有兵法，..... 皆是专家的精湛手艺，以及高手的惯用招式。模式(或称招式)运用得好，能化解冲突为详和，问题也迎刃而解，自然令人感到舒畅。好的设计师以流畅的方式将令人舒畅的模式组合而成气象万千的独特作品，其设计品自然令人感到快活。所以模式就是在某个领域(Domain)里的专家，针对经常出现的问题(Problem)，其常用的解决之道(Solution)。因为出自专家，所以模式是高质量的。因为它经常出现，所以有学习及推广的价值。因为从经验萃取而得，所以具有高度实用价值。
　　   杰出的设计品必需融入环境因素，并使环境与设计品构成和谐的整体。在设计过程中，常会面临环境的各种需求和条件，来自不同方面的需求可能会互相冲突而呈现不和谐的现象。因而不断运用模式来化解冲突使其变为均衡和谐，亦即不断把环境因素注入模式中而产生有效的方案来使冲突之力量不再互相激荡。有效的设计专家，会大量运用其惯用之模式，比较少一切从头创造新方案(Reinvent the wheel)。这并不意味着，使用模式是缺乏创意。因为模式是抽象的，运用时必须视环境(Context)的特殊性而修正，然后才产生具体的方案。模式会引导设计师的创意，使其融合别人的智慧，并充分考虑外在环境的独特性。例如，食谱并未限制厨师的创新，反而常激发厨师的新创意。所以模式告诉您理想的方案像什么、有那些特性﹔同时也告诉您些规则，让您依循之，而产生适合于环境的具体方案。当规则的掌握不灵活、或无法充分融入外在环境因素，可能无法得到具体有效的方案。因而新的设计师们经由模式的引导，成长会加速，具有建设性。
　　   模式的组合就如同写作文章，模式是字汇或成语，而设计品就如同写作出来的句子或文章。写作文章时，人们依循文法规则及风格而将字汇成语流畅地组合成句子，再流畅地组合成文章。每位作家皆有各自的一套规则和风格来写作文章。同理，每位设计家皆各有其惯用手法来将模式流畅地组合成为设计品。每位音乐家皆各有其惯用手法来将旋律模式流畅地组合成为乐章。每位诗人皆各有其惯用手法来将诗歌模式流畅地组合成为诗篇。
1.2 设计模式之例：校园交通
   刚才说过，模式是抽象的典范，引导着您去套用它、修正它，再加上外在环境因素，就能得到具体可行的方案(Solution)。它告诉您理想的方案像什么、有那些特性；同时也告诉您一些规则，让您依循之，进而在您的脑海里产生适合于环境的具体方案。只要灵活掌握规则、充分融入大环境因素，即能瞬间得到具体有效的方案。所以建筑大师亚历山大(Christopher Alexander) 做了如下之定义﹕
   「模式(Pattern)是某外在环境(Context) 下，对特定问题(Problem)的惯用解决之道(Solution)。」
首先，兹举一个例子。在平坦的校园里(即Context)，下述两项需求是互相冲突的﹕

• 学生需要交通工具代步。
  
• 校园空气必须保持清洁。
  

就产生问题了，该如何化解呢﹖当您想到好的妙招时，可依据亚历山大所建议的格式，撰写如下：
    校园交通模式(一)
      Intent: 维护一个安静又可交流智慧的学习环境。
      Force 1: 学生需要交通工具代步。
      Force 2: 校园空气必须保持清洁。
      Solution: 规定在校园中只能骑自行车，不能骑有污染的机车和汽车。
      Consequences: 在广大平坦的校区里，获得安静又安全的读书环境。

   此解决之道是否有效，是取决于外在环境。例如，在不平坦的新竹清华大学校园中，上述解决之道就无效用了。这是因为外在环境不一样，因此必须修正既有模式，而成为新的模式，如下：
    校园交通模式(二)
      Intent: 维护一个安静又可交流智慧的学习环境。
      Force 1: 学生需要交通工具代步。
      Force 2: 校园空气必须保持清洁。
        Solution: 规定在校园中只能骑自行车或电动机踏车，不能骑有污染的机车或汽车。
      Consequences: 如果配合方便的充电站，在广大校区里，获得安静又安全的读书环境。

   模式运用得好，能化解冲突为详和，问题也迎刃而解，自然令人感到舒畅。好的设计师以流畅的方式将令人舒畅的模式组合而成设计品，其设计品自然令人感到快活。
　　
1.3 设计模式之例：红绿灯
　　   接着，再举一个例子。在市区街道上，汽车和行人是两种个体(模块)，经常在路上发生冲突，导致社会(整体)不和谐了。如下图：
　　   
　　     图-9、人车冲突的景象 (摘自百度图片)
　　人们不喜欢这样的混乱次序，专家们就去(创新)设计了一个模式：。于是问题就化解了，整体(社会)就和谐了。
   
　　    图-10、红绿灯 (摘自百度图片)
可依据亚历山大所建议的格式，撰写如下：
    街道交通模式
     Intent: 有个和谐的街道交通。
     Force 1: 汽车要快速行驶于街道马路上。
     Force 2: 行人要安全过马路。
            Conflict：汽车常常撞到行人。
     Solution: 在十字路口建置红绿灯和斑马线。
     Consequences: 汽车规律行驶，行人安心过马路。

模式运用得好，能化解冲突为详和，问题也迎刃而解了，大家感到舒畅。如下图。
　　   
　　    图-11、红绿灯 + 斑马线(摘自百度图片)
　　
1.4 设计模式之例：皮鞋与Docker
　　   接着，再举一个例子。有一位国王在它的国境里视察，因为路面崎岖不平，还有很多碎石头，刺得国王的脚又痛又麻。
　　   

　　    图-12、赤脚国王(摘自百度图片)
　　回到王宫后，他下了一道命令，要将国内所有的道路都铺上一层牛皮。于是，让他自己和]全国的人走路不再受刺痛之苦。可依据亚历山大所建议的格式，撰写如下：
     赤脚国王的
       Intent: 国王很舒服走在道路上。
       Force 1: 有一位国王常常去他的国境里视察。
         Force 2: 路面崎岖不平，还有很多碎石头。
       Conflict：刺得国王的脚又痛又麻。
       Solution: 将国内所有的道路都铺上一层牛皮。
       Consequences: 国王走路不再受刺痛之苦。

　　   此解决之道是否有效，是取决于实际环境。例如，在大多数王国，即便杀尽国内所有的牛，也凑不到足够的牛皮来铺路，而且花费昂贵。在此环境中，上述解决之道就无效用了。即使有足够的牛皮，其成本也是非常大的。同样地，在云计算的虚拟平台上，过去的(旧模式)都是在实体平台上，铺上上了Guest OS(例如VMware)，让App跑在Guest OS上。这就如同国王要求将所有的道路都铺上一层牛皮一样，让人人的脚都踩在牛皮上；我们在各实体平台上，都铺上VMware，让各App都跑在VMware上。藉助于这的范例，就不难领悟到，这种旧模式并不是最具经济效益的。
　　   由于受限于实际环境：即便杀尽国内所有的牛，也凑不到足够的牛皮来铺路。于是，大家尝试去修正上述模式，或创造一个新模式。这时，一个聪明的仆人向国王建言：可以试着用牛皮将脚包起来，大王的脚就不会忍受痛苦了。国王听道而顿悟了，便收回命令，采纳了建议，于是，皮鞋就这样发明了出来了。
　　   

　　     图-13、国王的皮鞋(摘自百度图片)
可依据亚历山大所建议的格式，撰写如下：
    赤脚国王的
      Intent: 国王很舒服走在道路上。
      Force 1: 有一位国王常常去他的国境里视察。
      Force 2: 路面崎岖不平，还有很多碎石头。
      Conflict：刺得国王的脚又痛又麻。
      Solution: 用牛皮将国王的脚包起来。
             Consequences: 国王走路不再受刺痛之苦。
　　
　　   刚才已经提过了，在过去的旧模式(铺牛皮)里，我们在各实体平台上，都铺上牛皮(如VMware)，让各App都跑在牛皮上上。反之，在今天的新模式(皮鞋)里，各App都装入Docker集装箱，集装箱跑在Host OS(如Windows)上。把它对应到上述范例，就是：各App(人脚)都装入Docker集装箱(皮鞋)里，集装箱(皮鞋)跑(走)在Host OS(道路)上。这样子，更经济实惠，不必担心凑不到足够的牛皮来铺路了，人人的脚(穿着皮鞋)走在石头路上也不会痛了。
~ End ~
[Back]