Android和Docker的一致架构设计(3)：建立核心集装箱

Android和Docker的一致架构设计(3)

-- 建立企业主的<核心集装箱>

 

By 高焕堂 (台灣Docker論壇 主席)

misoo.tw@qq.com  2015/03/05 

 

高煥堂的相關文章：

A01、从「集装箱」思考Docker风潮：Docker潮流下的赢家策略

A02、Docker：从容<器>到集装箱设计之<道>

B01、Android和Docker的一致架构设计(1)：追求今天决策的未来性

B02、Android和Docker的一致架构设计(2)：包装<跨集装箱>的通信协议

B04、Android和Docker的一致架构设计(4)：<分合自如>的设计模式

 

前言

 　　在需求、数据和软件愈来愈碎片化的趋势下，集装箱包装了微服务(Micro-Service)成为主流。这些微服务在运行时间（Run-time）经常需要动态性组合成为各式各样的App来支撑企业多变的业务流程(Business Process)。在本文里，就拿上述的＜动态组合＞需求为例，展示企业App层的＜核心集装箱＞的角色。为了促进＜端与云＞架构设计概念的一致性，本文一方面借镜于Android核心进程（即SystemServe）的设计和角色；一方面运用Docker核心引擎来妥善管理集装箱，可迅速替各企业主设计出其独特的核心集装箱，来协助创造业务App模块之间，极为迅速的、瞬间的动态组合，来支撑企业流程和活动。     

• Android终端的服务厂商，很可能成为Docker平台最活耀的业主。 
• Android终端用户群，将成为Docker集装箱服务的主要消费群体。          

　　其实，业务App模块之间的动态组合，只是本文的应用范例而已。本文的真正目的是要藉这应用范例来呈现出企业主＜核心集装箱＞的角色和意义。并将Android平台的核心进程概念引用进来，落实为Docker集装箱，也创造＜Android + Docker>一致性的端＆云整合架构，迈向一致、整体的美感。

 

1、简介＜动态组合＞范例

  Linux操作系统有它的核心，称为Linux Kernel。而Docker也有它的核心，称为Docker Engine。

   

　   图-1、两个基础平台的核心

同样地，在云平台上，各企业主也都可以建立一个自己的核心集装箱。

   

    图-2、替企业建立它的核心集装箱 

  于是，形成一个＜三合一＞的企业云平台核心。

       　　　

     图-3、形成三合一的核心架构

 　其中，Docker核心的主要任务是管理集装箱的布署信息。例如，掌握集装箱（镜像）之间的相依性（Dependency）。而企业云核心则掌管集装箱内部Ａpp的业务模块（Business Module）之间的相依性，以及它们之间的动态性组合（Dynamic Composition）。 举例来说，在游戏业务里，有三个业务模块，分别由不同团队开发，并各自打包成为Docker集装箱，如下图：

  

   图-4、一款游戏里的三个模块

 　在这个游戏里，玩家操控飞机，携带摄像头（Camera）飞越港口上空，游戏画面会出现摄像头所拍到的景象。如下图：

  

　　 图-5、飞到港口上空所拍摄到的景象

 　这三项企业模块之间的动态結合(Association)关系，并非布署时间（Deployment-time）的相依性，並不属于Docker核心所掌管的范围。当飞机继续飞到另一个城市上空时，将会动态結合另一个集装箱的＜城市3D图＞，飞机所携带的摄像头会拍到新的城市景象。如下图：

  

　　

   图-6、飞到另一个城市上空所拍摄到的景象

 　顾名思义，”Docker”是：码头上的集装箱搬运工。Docker不仅要把集装箱搬运到不同平台（码头），还要搭配业务模块的动态组合而及时建立或删除集装箱，例如，飞机即将到某个城市上空之前，必须及时将＜城市3D图＞集装箱建立起来；此外，也可能立即将＜港口3D图＞集装箱删除了。这意味着，在App执行期间（Run-time）可能些业务模块必须及时将最新状态通知Docker Engine核心。但是，又不能让各业务模块开发者都随意使用Docker Engine的API，以避免各业务模块里处处充斥着Docker API，业务模块才不会被Docker绑住。

　于是，有必要特别建立一个业务模块的核心集装箱，内含各种管理型的软件模块，如App Manager模块。

                 

       图-7、业务层的核心集装箱

   由它来统一负责与Docker核心的通信与合作。

 

2、设计一个业务层的<核心集装箱>

   兹回忆一下之前的文章：《Android和Docker的一致架构设计：追求今天决策的未来性》，曾经说明了如何降低集装箱之间的相依性，以便创造出具有高度弹性的系统架构。例如下图：

   

    图-8、如何提升A的复用性？

  其中的A集装箱与B1、B2、B3等诸多集装箱之间，可做动态性的组合。

   

    图-9、与Ｂ的动态组合可提升A的复用性

  我在之前的文章：《Android和Docker的一致架构设计：追求今天决策的未来性》里，借镜于Android而设计一个具有高度未来性的设计，如下图：

   

    图-10、动态组合的基本架构

  基于这项设计，能创造各式各样的组合关系。如下图：

   

    图-11、动态创建形形色色的组合

   在动态组合的情境中，这些B1、B2、B3等诸多集装箱，并非事先就全部创建完成的，而是需要使用到的时候，才动态创建的。如下图，在Run-time动态创建了B集装箱，然后才能去调用它内部的App服务。

   

    图-12、也常动态创建Docker集装箱

  在C集装箱里的绿色模块担任了<组合者>的角色，是合理的。但是它必须情求Docker Engine来协助创建(Build)这个B集装箱。然后才能去调用B集装箱内部的App服务。如下图：

   

    图-13、绿色模块(组合者)请求Docker Engine来协助

  表面上看来，上图里的设计是合理的。其实不然，因为Docker Engine的API相关代码会被写在C集装箱的绿色模块里。导致C集装箱与Docker Engine的API产生高度的相依性(Dependency)，不是一项有效的(有未来性的)美好设计!!

   

    图-14、但却让绿色模块高度依赖于Docker Engine的API

  此时，就设计出一个新的<核心集装箱>，让它负责与Docker Engine通信的任务，有效降低其他各集装箱与Docker Engine的相依性，大幅提升企业软件的跨平台(如Docker平台)的能力。如下图：

   

    图-15、将Docker Engine的API相关代码移出绿色模块

  这种效益，随着企业的业务模块的成长，会显得更加亮丽。例如下图里，C集装箱内部的业务模块成长了、变复杂了，却完全被Docker集装箱隔离了，让C集装箱具有极高度的跨平台性，更加实践了Docker集装箱的无限美意。不仅仅跨越OS操作系统平台，更能跨越Docker集装箱平台。

   

   图-16、各个组合模块皆独立于Docker Engine的API

   一般而言，企业主在云平台上，只需要一个像M这种<核心集装箱>，所以当Docker Engine的API改版了，或Docker Engine被抽换掉了，只需要改写M集装箱里的红色模块而已，非常简单容易。这个M就通称为企业主的<核心集装箱>。

 

3、观摩Android的架构设计

3.1 基本架构

 Linux平台有其核心(即Linux Kernel)，而Docker平台也有其核心(即Docker Engine)。一样地，Android平台也有其核心(即SystemServer)。在本节哩，就来借镜于Android核心进程(Process)，来引导我们思考如何设计各企业主的云平台核心集装箱。在Android平台哩，SystemServer进程就扮演着Android平台的核心角色。如下图：

   

     图-17、SystemServer是Android的核心进程

  在Android里，Activity主要是提供UI画面的布局(Layout)与设计，来支持人机交互的需要。在这人机交互的过程中，Activity常常需要动态地去启动一个或多个Service。而Service主要是提供幕后的服务，例如播放游戏的背景音乐、从网络上下载图片或影片等任务。这些Activity和Service经常是由不同的团队分别开发、并在不同的进程里执行。举例来说，在Run-time期间，当上图里myActivity需要去调用myService的服务时，就会发出bindService信息给SystemServer进程里的AMS(即ActivityManagerService)模块，目的是去绑定myService。此时，这个myService的进程可能尚未创建，也可能已经存在了。如果，还不存在的话，AMS就会透过Zygote进程来发出信息给Linux Kernel，要求创建一个新进程。如下图：

   

    图-18、AMS发出信息给Linux Kernel

Linux Kernel接到AMS的请求之后，它就去创建一个新的进程，并且把Service的代码载入(Load)到这个新进程里。如下图：

    

     图-19、Linux Kernel创建一个新进程

 　然后，AMS就要求Service进程的myService模块，回传IBinder接口。这过程就通称为：绑定(Bind)了myService。其目的是要建立myActivity与myService之间的联结(Connection)。AMS取得myService的IBinder接口之后，就回调(Callback)这myActivity模块，把IBinder接口递交给myActivity，就完成了绑定myService的任务了。也就是myActivity成功地建立了与myService之间的联结了。

    

     图-20、myActivity绑定了myService

  一旦取得myService的IBinder接口，myActivity就能透过IBinder接口而调用myService的服务了。如下图：

    

      图-21、myActivity调用myService的服务

   关于App软件的进程都是由AMS来掌握，如果需要新的进程，AMS就会透过Zygote要求Linux Kernel来创建。所以SystemServer就扮演Android平台的核心角色，而AMS是SystemServer进程里的重要模块之一。我们可以看到，无论是Docker或Android平台架构里都有其核心进程(集装箱)。在云平台上，可借镜于Android架构，也设计出企业主的核心进程(集装箱)，将是非常有帮助的。

 

3.2 Android的应用程序代码

  兹建立Android开发项目：

  

  此程序的执行画面如下：

  

  其源代码如下： 

// myActivity.java
package com.misoo.pk01;

public class myActivity extends Activity implements OnClickListener {
　　　//………
　　　public void onCreate(Bundle icicle) {
　　　　　//………
　　　　　bindService(new Intent("com.misoo.pk01.REMOTE_SERVICE"),　mConnection, Context.BIND_AUTO_CREATE);
　　　}
　　　private ServiceConnection mConnection = new ServiceConnection() {
　　　　　@Override

　　　　　public void onServiceConnected(ComponentName className, IBinder ibinder) {
　　　　　　　ib = ibinder;
　　　　　}

　　　};
　　　public void onClick(View v) {
　　　　　　// ………
　　　　　　ib.transact(1, data, reply, 0);
　　　　　　// ………
}}

// myService.java
public class myService extends Service implements Runnable {
　　　// ……….
　　　@Override public void onCreate() {
　　　　　　super.onCreate();
　　　　　　mBinder = new myBinder();
　　　　}
　　　@Override public IBinder onBind(Intent intent) {
　　　　　　return mBinder;
}}

// myBinder.java
package com.misoo.pk01;
// ........
public class myBinder extends Binder{
　　　@Override
　　　public boolean onTransact(int code, Parcel data, Parcel reply, int flags)
　　　// …….
　　　myService.h.sendMessage(msg);
　　　// ……
}}

　　兹说明上述的软件程序，首先看代码：

　　　bindService(new Intent("com.misoo.pk01.REMOTE_SERVICE"), mConnection, Context.BIND_AUTO_CREATE);

   就是myActivity调用父类Activity的bindService()函数，然后由Activity转而调用AMS的bindService()函数。这就是上图-18所呈现的情形。接着，如果需要创建新的进程，AMS就会透过Zygote要求Linux Kernel创建一个新进程。这就是上图-19所呈现的情形。 此时，有了myService进程，AMS就访问这个myService进程，转而执行到myService模块的onCraete()和onBind()函数，这段代码就是：

　　　@Override public void onCreate() {
　　　　　　mBinder = new myBinder();
　　　　}
　　　@Override public IBinder onBind(Intent intent) {
　　　　　　return mBinder;
　　　　}

其中，onBind()函数就将IBinder接口回给AMS。接着AMS就回调(Callback)到myActivity模块，把IBinder接口地交给myActivity。这项回调的代码如下：

　　　private ServiceConnection mConnection = new ServiceConnection() {
　　　　　　@Override
　　　　　　public void onServiceConnected(ComponentName className,　IBinder ibinder) {
　　　　　　　　　ib = ibinder;
　　　　}};

这就是上图-20所呈现的情形。此时，myActivity就接到IBinder接口了。myActivity就可调用 IBinder接口的transact()函数。这段代码如下：

　　　public void onClick(View v) {
　　　　　　// ………
　　　　　　ib.transact(1, data, reply, 0);
　　　　　　// ………
　　　　}

现在执行到IBinder接口的transact()函数，其转而调用myBinder的onTransact()函数，就执行到代码如下：
　　　public class myBinder extends Binder{

　　　　　@Override　
　　　　　public boolean onTransact(int code, Parcel data, Parcel reply, int flags)
　　　　　　　// …….
　　　　　　　myService.h.sendMessage(msg);
　　　　　　　// ……
　　　}}

 = => 请看完整源代码

   这onTransact()就转而调用myService的服务了。当您仔细观察上述Android应用程序代码，统统看不见与AMS、Zygote及Linux Kernel的API接口的相关代码。都是集中并封装于SystemServer的核心集装箱(进程)里。这种优越的架构设计替企业主带来了极大的利益，不仅仅让企业的App模块可以跨OS平台，也能更进一步跨Docker平台。 

 

4、一致的架构：应用于Docker集装箱

   无论是Linux、Docker或Android都各有它自己的核心部分。而且Docker和Android都以进程为沙盒空间(也可称为集装箱)，例如，Docker的核心进程是Docker Daemon；而Android的核心进程是SystemServer。基于一致性的架构设计，我们也可以替企业主，在其云平台上建立一个业务层软件的核心。

   从上述Android的平台架构，可以看出来，其核心进程(SystemServer)是蛮复杂的，而且还包装了与底层平台(如Linux Kernel)的API相关代码，所以核心进程的内部(代码)是既复杂又多变。也就是因为它的复杂多变，更需要集装箱的<序中有乱>的特质来将它的复杂多变包装起来，呈现出简单的次序。因之，Docker集装箱恰可派上用场，它让我们更能做出好的系统核心，包括企业云平台的核心集装箱。首先从Docker核心(Docker Engine)谈起，如下图：

 　

  　图-22、提供三个镜像给Docker Engine

 　Docker Engine依据M的镜像(Image)来创建一个Ｍ集装箱。它就扮演核心集装箱的角色。如下图：

　　

　　　图-23、创建了核心集装箱（Ｍ）

 　在核心集装箱（Ｍ）里，可以添加一些＜管理型＞的软件模块，例如上图里的App Manager模块，担任插件（Plug-in）的管理等任务。此外，未来也可以逐渐添加更多的插件模块。至于这M核心集装箱里该摆入那些模块，就是我们的职责了，就是：依据平台、技术、业务等不同需求或条件限制来考虑，然后设计出来的。通常这种核心进程都是常驻型的集装箱，也算是守护进程(Daemon)。接下来，企业主还可以透过Docker Engine来创建其他的集装箱来跑各式各样的业务App模块。例如，基于A的镜像来建立A集装箱，如下图：

　　

 　　图-24、创建一个A集装箱

 　在A集装箱的执行时（Run-time），如果需要动态性去绑定S集装箱里的myServive服务，就可发送信息给M（核心）集装箱里的App Manager模块，由它来请求Docker Engine创建一个S集装箱，如下图：

 

 　　　　 　图-25、A委托M来创建S集装箱

 　然后，App Manager就去绑定S集装箱里的myService服务，并取得myService的接口。这过程就通称为：绑定了myService，如下图。其目的是要让A集装箱建立起与S集装箱的连结联机(Connection)，也就是支持两个集装箱之间的动态组合。

 

 　　　　　　图-26、A委托M来绑定Service模块

 　App Manager取得myService的接口之后，就回调这绿色模块，把myService的接口递交给绿色模块，就完成了绑定myService的任务了。一旦取得myService的接口，myActivity就能透过该接口而调用myService的服务了。如下图：

 

　　　　　　　图-27、A与S交换信息或数据

 　　从这图里可看到，目前已经成功建立了A集装箱的绿色模块与S集装箱的myService之间的动态组合。在执行过程中，可能需要再创造一个动态组合，例如在下图里，黄色模块想与Service-x模块进行动态组合。此时，就可透过Ｍ核心集装箱里的App Manager来绑定Service-x模块，如下图：

 

 　　　　　　图-28、A和S集装箱内部随着企业需求而变化

   App Manager取得Service-x接口之后，就回调这黄色模块，把Service-x的接口递交给黄色模块，就完成了绑定Service-x的任务了。一旦取得Service-x的接口，黄色模块就能透过该接口而调用Service-x的服务了。如下图：

　

　　　　　　　　图-29、随着企业需求变化而动态组合

 　　其中，Docker Engine负责管理集装箱本身，而企业主的M核心集装箱则负责建立业务模块之间的关系；两者相辅相成，创造云平台的美好次序（Order）。

 

5、结语

5.1 　＜命令流与数据流的分离＞法则

    软件有两种主要流程：一种是命令流（Command flow），而另一种是数据流（Data flow）。许多软件人员常常误认为数据流才是最重要的。其实不然，在架构设计上，命令流程的设计更是关键。在我写的《思考软件、创新设计：A段架构师的思考技术》一书的第10章哩，也提出了云平台架构设计的十项法则，其中的第4项就是：命令流与数据流的分离法则。例如，下图里的软件交互调用流程就是命令流。

 

　　　　　　　　　　　　图-30、命令流之范例

 　这图里展现了命令流，它的目的是去建立绿色模块与Service-x之间的连结（Connection） 。以日常生活来比喻，这命令流是用来指挥各模块（如Docker Engine、App Manager）去合作搭建桥梁；而数据流则是让行人或车辆从搭好的桥梁上鱼贯地通过。例如下图：

 

　　　　　　　　　　　 图-31、数据流之范例

 　一般而言，命令流的软件逻辑常常比数据流要复杂许多，所以藉由Docker集装箱来将复杂多变包装起来，发挥了集装箱天赋的＜序中有乱＞特质，让我在设计企业主的＜核心集装箱＞时，变得简单许多了。此外，善加利用<命令流与数据流的分离>法则，可带来系统的弹性，并大幅提升数据流的执行效能。例如，控制手机摄像头（Camera）的信息是命令流；而传送预览（Preview）视像的是数据流。命令流指挥数据流，通常可以透过命令流API去通知两端的模块，动态启动两端插件，透过动态API（如Config文件提供）串接两端；静态Command API支撑动态Data API。

       例如，在建置大数据平台时采用Hbase。这Hbase是以Java开发的，其提供了Java基础接口，在C层则使用thrift机制。如果咱们的C层模块想存取Hbase时，使用的技术是：C调用jni，再调用Hbase的Java接口（亦即C->jni->Java），但这种架构方式，会导致性能下降，该如何解决这个议题呢？  这个议题可以将两种流程分离开来。并且厘清数据来原（Data Source）是在C层（可能是先已经从Hbase查询出来，放在C层了）或是在Java层的Hbase里。如果数据来源是在Hbase里，其thrift接口就是合适的数据来源接口。如此，数据来源接口在C层，而Client（即数据目的地）也在C层。于是：

• Data flow是C->C，不要经由Java层，效率就极高。
• Command flow可以经过Java层，有助于控制点放在Java层。
• Command flow：C->JNI->Java接口，要求Java模块把Hbase端的C接口传递给Client。这常常在编译时(At Compile-time)就已经安排的API，通称为静态配置的。此时，Java模块可动态读取Config配置文件，依其指示而把Hbase端的特定C接口(如thrift API)传递给Client，这通称为动态配置的。
• Data flow: Client就可调用上述动态配置的Hbase的C接口（若跨进程，可透过IBinder接口），进而顺利取得所需的数据。 

5.2 　带给企业无限活力

　　每一台电脑都有<主板>(简称Mother-Board)，它是IT产业人人都接触过的东西。它是一个集装箱，包容了极多样化的电脑芯片及相关模块。后来，人们就将全世界的电脑主板都连接起来，就成为当今风行的互联网（Internet）了。前面也提过了，在当今的需求和软件碎片化的大数据时代里，一个企业主的业务层App软件常常分布在各式各样不同的工有云或私有云上，我们可以协助众多企业主建立云平台上的核心集装箱，它就像一个电脑的主板，其控制着周边的相关模块。然后，再将这些分布于各云端的核心集装箱连结起来，成为企业主专属的大数据平台。

　　基于Docker集装箱的＜序中有乱＞特质，虽然核心集装箱内部的软件逻辑是复杂多变的，但集装箱的概念和操作接口是很简单的。也因为这项简单之美，带给它无限的生命力，也带给众多企业无限的活力。  

 

高煥堂的相關文章： 

 A01、从「集装箱」思考Docker风潮：Docker潮流下的赢家策略 

 A02、Docker：从容<器>到集装箱设计之<道>

 B01、Android和Docker的一致架构设计(1)：追求今天决策的未来性

 B02、Android和Docker的一致架构设计(2)：包装<跨集装箱>的通信协议

 B04、Android和Docker的一致架构设计(4)：<分合自如>的设计模式

 ~ End ~