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

<?xml version="1.0" encoding="utf-8"?>

<manifest xmlns:android="http://schemas.android.com/apk/res/android"

  package="com.misoo.pkm">

  <uses-permission xmlns:android="http://schemas.android.com/apk/res/android" 

                   android:name="android.permission.INTERNET">

  </uses-permission>

  <application android:icon="@drawable/icon" android:label="@string/app_name">

  <activity android:name=".myActivity" android:label="@string/app_name">

       <intent-filter>

          <action android:name="android.intent.action.MAIN" />

          <category android:name="android.intent.category.LAUNCHER" />

       </intent-filter> </activity>

  <service android:name=".myService" android:process=":remote">

         <intent-filter>

             <action android:name="com.misoo.pkm.REMOTE_SERVICE" />

         </intent-filter> </service>

  </application>

</manifest> 

 

　　则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

<?xml version="1.0" encoding="utf-8"?>

<manifest xmlns:android="http://schemas.android.com/apk/res/android"

  package="com.misoo.pkm">

  <uses-permission xmlns:android="http://schemas.android.com/apk/res/android" 

                   android:name="android.permission.INTERNET">

  </uses-permission>

  <application android:icon="@drawable/icon" android:label="@string/app_name">

  <activity android:name=".myActivity" android:label="@string/app_name">

       <intent-filter>

          <action android:name="android.intent.action.MAIN" />

          <category android:name="android.intent.category.LAUNCHER" />

       </intent-filter> </activity>

  <service android:name=".myService" >

         <intent-filter>

             <action android:name="com.misoo.pkm.REMOTE_SERVICE" />

         </intent-filter> </service>

  </application>

</manifest> 

　　

并且重新布署之后，这些类都会在同一个进程里运行了。

  

     图-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]