Sec-3：一致的架构，应用于Docker集装箱

美奇科技

　　Android和Docker的一致架构设计(4)
-- 的设计模式(Design Pattern)
ee                                                   ee
[Back]
　　
Sec-3、一致的架构：应用于Docker集装箱
3.1 复习：Android的＜分合自如＞架构
　　一个进程是一个独立的地址空间(Address Space)，在该空间里执行的App不会被正在其它进程里执行的App所侵犯。这种保护方法是Android的重要安全机制。那么，分别摆在不同进程里执行的App之间又如何相互沟通(通信)呢?这就是上一小节里已经介绍过的「跨进程」(Inter-Process Communication，简称IPC)机制了。换句话说，由于不同进程的地址空间不同，两支 App之间不能使用一般的函数调用(Function Call)途径来通信，所以就设计一个IPC通信机制了。例如，在上述范例程序里，我们写了AndroidManifest.xml配置文文件内容如下：
　　// AndroidManifest.xml
　　
　　
　　
　　
　　
　　
　　
　　
　　
　　
　　
　　
　　
　　
　　
　　

　　则Android会依据这个配置文文件而进行布署如下：
  
   图-24、PIC跨进程的交互通信
为了支持IPC跨进程通信，Android架构师设计了IBinder接口来包装底层Binder Driver通信机制，以及相关的Marshalling动作，而达成IPC通信。
  
    图-25、以Binder类和IBinder接口包装IPC通信协议
在表面上，myActivity调用IBinder接口的transact()函数，进而调用到myBinder的onTranscat()函数。然而，在实践机制里，myActivity与myService之调用是透过Linux底层的Binder Driver来达成的。
  
    图-26、IPC透过Linux底层的Binder Driver来达成
　只要把上述AndroidManifest.xml配置文文件里的红色文字删除掉，修改为：
　　// AndroidManifest.xml
　　
　　
　　
　　
　　
　　
　　
　　
　　
　　
　　
　　
　　
　　
　　
　　
　　
　　并且重新布署之后，这些类都会在同一个进程里运行了。
　　  
     图-27、合并到同一个进程
　　　布署完毕，重新执行这个程序。此时，再执行到代码：
　　// myActivity.java
　　public class myActivity extends Activity implements OnClickListener {
　　IBinder mb = null;
　　……..
　　    public void onCreate(Bundle icicle) {
　　……..
　　startService(new Intent("com.misoo.pk01.REMOTE_SERVICE"));
　　bindService(new Intent("com.misoo.pk01.REMOTE_SERVICE"), mConnection, Context.BIND_AUTO_CREATE);
　　……..
　　}
　　
　　　　此时，AMS就去绑定myService，调用myService的onBind()函数，就直接将Java层的IBinder接口回传给AMS。然后AMS进行回调(Callback)，就调用到myActivity里的代码：
　　private ServiceConnection mConnection = new ServiceConnection() {
　　public void onServiceConnected(ComponentName className, IBinder ibinder) {
　　mb = ibinder;
　　}};
　　
　　AMS就将Java层的IBinder接口回传，并指定给mb。然后，在执行到代码：
　　public void onClick(View v) {
　　……
　　mb.transact(…);
　　……
　　}}}
　　　　myActivity就直接调用到Java层的IBinder接口了。
   
     图-28、使用一般的Function call调用机制
　一旦取得myService的IBinder接口，myActivity就能透过IBinder接口而调用myService的服务了。如下图：
   
     图-29、进程分合自如，代码不需改变
　　　此时，不需要修改其源代码，直接合并到同一个进程，而且顺利调用和执行。

3.2 Docker平台上的一致性架构设计
  从上述的Android架构里，看到了myActivity与myService原来分别在不同的进程里执行。后来修改了AndroidManifest.xml配置文文件，而不需要修改其源代码，就能将两者合并到同一个进程里执行了，而且顺利交互通信。我们可以在Docker平台上采取一致的架构设计。首先建立企业App框架(包括下图的粉红色部分)，如下图：
   
    图-30、设计Docker集装箱里的App框架，来包装底层通信
  基于上述企业App框架，让众多开发者撰写其形形色色的App模块，例如下图里的 Client模块和Service模块。这些App模块并不直接跟Docker平台交互通信，而仅仅与App框架交互通信，如下图：
   
    图-31、Client透过App框架来绑定Service
   App Manager透过Docker平台来绑定Service，取得S框架的IB接口(类似于Android的IBinder接口)。然后，App Manager创建一个Proxy对象，它扮演S框架模块的分身(Proxy)，也提供一个IB接口。如下图：
   
    图-32、在Client集装箱里，创建一个S框架的分身(Proxy)
   于是，Client模块就能调用Proxy的IB接口了。这Proxy模块再透过Docker平台来调用到S框架的IB接口，然后转而调用到Service模块的函数了。如下图：
   
    图-33、Client使用Proxy的IB接口
  有一天，维运人员把两个模块合并到同一个集装箱里运行了。此时，App Manager在绑定Service时，就不会去创建Proxy模块了，而直接让Client去调用S框架的IB接口。如下图：
   
     图-34、合并到同一个Docker集装箱里，使用一般的函数调用
  无论Client调用Proxy的IB接口，或是Client直接调用S框架的IB接口，这Client模块的代码都是一样的。所以，从图-33布署于两个集装箱的分开运行，到图-35的合并运行，这Client和Service两个模块的代码都不需要改变。
   
     图-35、集装箱分合自如，代码不变
以上我们先展示了在Android平台内的架构，然后讨论Docker平台内的架构。基于一样的设计模式，设计出端云一致的架构，如下图：
  
    图-36、跨越终端与云端的设计
   只要IB接口不变，而且S框架与Service之间的接口也不变，则这Client和Service两个模块的代码都不需要改变。也就是，Proxy和S框架的外部接口(Interface)维持不变，只要改变其内部的实现(Implementation)代码，就行了。这Client和Service两个模块的代码都不需要改变。

3.3、结语
　　    传统上，架构设计思维里的主要元素有二：。而碎片化时代里的设计思维则增添一个新元素，成为三个：。此外，在技术上也改变了，其增添了一个新元素：「合」。苹果公司的乔布斯有句名言是：
　　    「创造无非就是把事物联结起来，…即若是非凡的创意通常也不过是对已有事物进行的新组合而已。」
　　  创新组合来自愿景(Vision)，而不是来自需求，这需求只是限制(Constraint)而已。当我们心怀，以及的设计愿景时，自然能设计出卓越的架构、呈现非凡的创意、打造出气象万千的独特产品了。
~ End ~
[Back]