终端与云平台的SOA架构设计 課程

高焕堂的招牌课程

    移动终端与大数据平台的SOA架构设计 课程

                                      

课程大纲：

一、架构设计的分类
l    <终端架构设计>与<云端架构设计>  案例：Android终端架构设计；Hadoop/Spark大数据云端架构。 l    与 案例：智能家庭客厅配件商业模式设计(A段)；智能家庭幼儿学习机器人架构设计(B段)。 l    <抽象分析型设计>与<创新组合型设计> 案例：以五子棋系统开发为例，先分析内容(如游戏规则)并抽象；然后藉由软件EIT造形来进行组合，创造独特的创新产品。 l    <基于需求而设计>与<设计爱上需求> 案例：传统Requirement-based瀑布式开发流程；谷歌公司”Creativity loves contraint”敏捷流程。 l   <业务应用架构设计>与<软硬整合架构设计> 案例：基于PhoneGap的Java业务框架设计；基于Android 的智能地毯软硬整合设计。
二、B段架构设计的思维、方法和模式
l            概念与技艺：以五子棋应用框架(App Framework)开发为例 n            深入认识控制反转机制   n            主控者是框架，而不是应用程序   n            框架的重要功能：提供默认行为(Default Behavior) l            抽象方法：以五子棋内容抽象模型为例 n            数据抽象 n            函数抽象 n            善用类的组合和继承结构 n            抽象是手段，组合是目的 l            分析与设计：以架构为中心(Architecture-Centric)需求探索为例 n            使用传统OOAD进行内容分析与抽象 n            运用EIT造形设计进行创新组合设计 l            接口API制定：掌握API，拥有话语权 n            如何定义接口(Interface) n            被动型API与主动型API n            API决定控制权 n            谁拥用接口的制定权，谁就掌握控制点，获得话语权 n            从API看控制力量的强弱等级 l            案例：制定电力EPGPS云服务的API n            EPGPS云平台提供函数让App调用，如下图： n            这种典型CS架构，Server端受制于App端，Server端对App端没有主导力量；Server端常常成为救火队而疲于奔命。 n            如果EPGPS平台人员加上简单的<基类/子类>结构，如下图：         n            像Facebook、Google GAE云平台也都如此，如何制定这种新的API呢? 您觉得有何优缺点呢?
三、从程序员到架构师的心灵鸡汤
l            区别(业务)内容与(软件)形式       n            程序员比较关注于(业务)内容 n            内容包括：业务流程、企业规则和运算逻辑等。 n            架构师比较关注于(软件)形式 n            形式的最佳比喻是：集装箱。 n            软件(集装箱)形式包括：造形(Form)、模式(Pattern)和框架(Framework)等。 l            软件造形的演进(历史)         n            1970年代的主要造形：函数(Function) n            1980年代的主要造形：类别(Class) n            2012年高焕堂提出的EIT造形   l            软件造形的组合         n            组合出和谐次序(Order) n            简单的形式+简单组合韵律=美的架构(Architecture) n            造形组合是儒家文化的缺陷吗? l            案例：基于EIT造形，包容两个模块之间<通信协议>的复杂多变 n            组合出和谐次序(Order)例如，智能城市里的两个子系统模块(Module)之间的网络通信技术日新月异，通信协议是善变的。 n            模块开发常常依赖于特定的通信协议，产生系统之间的高度偶合性(Highly-coupled)和相依性。因而，许多人力求通信协议的<标准化>；然而试图统一善变的科技，其效果是非常有限的。此时，可藉由两个基类的联合来包容通信协议内涵，例如：          n            此外，也可以进一步优化上述的架构；例如，可将上述架构转换如下：             n            于是，两个模块的开发就不再依赖于善变的通信协议了。
四、A段架构师的职责
l            主要职责         n            在A段，架构师面对环境迅速变迁下的产品策略规划； n            在B段，则面对团队的实践策略、执行能力和技术变迁。 n            A段获利思维，B段成本思维。 n            A段算计敌人，B段设计自己。 n            A段预见失败，B段势如破竹。 l          商业思维：规画商业模式&策略       n            A段架构师面对环境迅速变迁，必须具备鲜活的创新思维、睿智的策略思考、犀利的洞察力和灵活的战术，以便掌握稍纵即逝的商机。 n            然后，从复杂中找出简单，设计出有效的可实现计划（即A段架构设计），让高阶主管从简单中掌握复杂，做出正确决策。 l          创新思维：运用设计思考(Design Thinking)       n            溯因推理与创造性。 n            运用四项「假设」思维技巧。 n            第1项：不自觉的假设，放宽思维局限。 n            第2项：有待被检验的假定，激发愿景想象。 n            第3项：完成性的假设，想象最终结果。 n            第4项：万一性的假设，预留弹性空间。 l          案例-A：规划<智能TV软硬整合销售>新型商业模式       n            本范例以智能化家庭为范围，以智能电视（含TV/STB）为中心，对旧有的商业模式进行反思，建立新的愿景和商业模式：<内容创意在云端，捆绑销售在终端>。基于这项新商业模式，衍生出可短期获利的新商业策略：<软硬整合开发，硬硬结合销售>。 n            例如，许多彩电厂商的TV/STB产品的年产量也都是千万等级；这些都是非常好的主硬件代表作品，可搭配无数硬件小配件，捆绑销售。例如，机顶盒（STB）可搭配家庭里的无数智能型设备（如壁灯），如下图：             n            通过硬硬结合的产品创新策略，TV/STB手机、机顶盒等销售量可带动小配件（如家庭医疗的血糖仪、智能地毯、幼儿学习跳舞毯等）销售量的大幅提升、制造成本大幅下降，产生巨大利润。   l          案例-B：拟订智能终端(软件)产品的<跨平台>策略       n            <软硬整合>与<跨平台>就如同天平两端的砝码。透过调整砝码，就能有效规划出最有利于自己产品的商业策略。 n            在此范例里，兹拿<跨平台>为例，说明A段架构师如何运用溯因推理和四项假设性思维来拟订优越的跨平台产品策略，如下图：              n            于是，演练了溯因推理的创新思维；并发挥<四项假设性思维>的魅力，逐步推衍出智能终端平台的软硬整合产品策略。
五、智能终端应用的架构设计
l            如何掌握Android架构的知识体系呢? n            Android的多层框架体系。 n            Android架构里的重要机制，包括：线程模式、IPC跨进程通信和Binder Driver驱动程序。 l            Java与C/C++整合开发技术 n            JNI应用(1)：Native C如何调用Java函数 n            JNI应用(2)：Native C函数如何诞生Java对象 n            认识Android核心服务。 n            开发自己的Android核心服务。 l            观摩Android GPS(Location Service)服务框架体系 n            Java层框架基类及相关类别 n            JNI界面 n            Location  Service的C++层服务 & 驱动层 l            案例：开发一个GPS框架层服务和应用程序 n            App获取移动设备当前的地理位置。 n            手机App拍摄了一张风景照片，也获取了当前的地理位置。然后，采取H.264视频数据格式来将照片和地理位置一起传送给云服务器(Cloud Server)。 n            此App不直接调用getSystemService()函数，如下述的代码： locationManager = (LocationManager) this.getSystemService(Context.LOCATION_SERVICE);  而是使用新建立的LBS领域框架基类，再透过SeviceManager来绑定LocationManagerService。 n            于是，手机App就能拍摄了一张风景照片，也获取了当前的地理位置；然后将照片和地理位置一起传送给云服务器(Cloud Server)。请拿起你的画笔，在下图上绘出上述location变量值的数据流(Data  Flow)；同时也请画出这数据流幕后的控制命令流(Cammand Flow)。 n       撰写一个新的LBS服务。LocationManagerService是以Java写成的Android  Service。如果我们想保留这个LocationManagerService，而且想开发一个新的LocationManagerService_02服务。可以选择改用C++来撰写它。核心服务透过HAL衔接到Linux或底层GPS驱动程序。 n        于是，App可透过SM来绑定该服务，并透过JNI而呼叫核心服务。
六、云平台(&服务)架构设计
l            基础架构 n            Linux-based驱动架构 n            多层框架：强型态语言Java, 动态语言JS/Python> n            三种交易(Transaction)型态：长交易(如拨电话)、短交易(如Oracle DB存取)和一般交易(如调用命令) l            大数据架构 n          Hadoop Node功能与接口 n          活用Hbase的Thrift本地接口 n          Spark RDD/HBase与Hadoop  Node的衔接技术 l            案例：金融服务云平台的Hadoop/Hbase建置 n         软件有两种主要流程（Flow），一种是命令流（Command flow）；另一种是数据流（Data flow）。例如，控制手机摄像头（Camera）的信息是命令流；而传送预览（Preview）视像的是数据流。 n          命令流指挥数据流，通常可以透过命令流API去通知两端的模块，动态（At Run-time）启动两端插件，透过动态API（如Config文件提供）串接两端；静态Command API支撑动态Data API。例如，在建置大数据平台时采用Hbase。这Hbase是以Java开发的，其提供了Java基础接口，在C层则使用thrift机制。如果咱们的C层模块想存取Hbase时，使用的技术是：C调用jni，再调用Hbase的Java接口（亦即C->jni->Java），但这种架构方式，会导致性能下降，该如何解决这个议题呢？ n          这个议题可以将两种流程分离开来；并且厘清数据来原（Data Source）是在C层（可能是先已经从Hbase查询出来，放在C层了）或是在Java层的Hbase里。如果数据来源是在Hbase里，其thrift接口就是合适的数据来源接口。如此，数据来源接口在C层，而Client（即数据目的地）也在C层。于是： n          Data flow是C->C，不要经由Java层，效率就极高。 n          Command flow可以经过Java层，有助于控制点放在Java层。 n          Command flow：C->JNI->Java接口，要求Java模块把Hbase端的C接口传递给Client。这常常在编译时(At  Compile-time)就已经安排的API，通称为静态配置的。此时，Java模块可动态读取Config配置文件，依其指示而把Hbase端的特定C接口(如thrift API)传递给Client，这通称为动态配置的。 n          Data flow: Client就可调用上述动态配置的Hbase的C接口（若跨进程，可透过IBinder接口），进而顺利取得所需的数据。
七、端云整合应用案例&讨论
l            案例-A：如何设计云平台的API，支持<端云整合>开发 n          目的：让Client端开发者自己来撰写后台的插件，于是，后台成为一朵真正的云(Cloud)了，并基于一个C/C++平台可以搭配多个不同语言的框架。 n          做法：以Java为例，使用JNI(Java Native Interface)。例如，C/C++平台的<业务规则BR引擎>可以搭配一个Java框架。因为C/C++模块(如<业务规则引擎>)可以调用Java函数，所以C/C++平台仍然拥有主控权。插件包括3种：App(用户)插件、业务(业主)插件和平台插件。当插件增多了，需要设计插件管理机制。看似复杂的架构，却只是3个EIT造形的巧妙组合而已。 n          提供接口API给Client：通常，后台的业务或平台插件的开发者，与Client开发者是不同的；而且开发的时间点也不一样(插件常开发在先)。那么，当Client需要调用插件时，后台如何提工插件接口给Client开发者呢?即使Client端可以从文件中得知插件的接口，又如何调用呢?首先，后台提供一个通用型接口，内含一个通用型函数。然后，后台提供一个Proxy类别给Client。那么，又如何提供Proxy类别的代码给Client开发者呢? n          讨论：             ☆ 清晰而明确表述接口(Interface)              ☆ 尽快对接口进行检验和测试              ☆ 设计<通用性>接口，成为框架(Framework)核心要素              ☆ 如何提供<插件接口>给Client l            案例-B：手机与Android TV的多机整合系统设计与开发 n          目的：这是会议开幕时，嘉宾以自己的手机上网访问会议厅中Android TV里的i-Jetty网页，再通过Android App发出Zigbee信号，打开会议厅的主灯和电视墙，如图： n          做法：在这个范例里，为了让各种移动终端皆能来访问Android TV，就不特别去开发iPhone客户端的App了，而是直接采取通用的一般浏览器（Browser）作为这个案例的手机客户端软件了。 n          使用：由i-Jetty提供Servlet接口来与iPhone手机上的浏览器对接。在i-Jetty里，转换成为，doPost>接口，再经由来使用Context接口，调用它的startService()函数，来取得IBinder接口，进而通过IBinder接口与ZigbeeAppActivity&硬件驱动互相通信。通过3个现成的通用性接口的联合应用，就完成了iPhone手机与Android TV两端的对接与整合任务了。 n          讨论：云平台架构设计的十个法则   ☆ 法则-1. 好莱坞大明星原则(Don’t call me, I’ll call you back!)   ☆ 法则-2. <通用性接口>与<特殊性接口>的衔接法则   ☆ 法则-3. 协天子以令诸侯法则   ☆ 法则-4.  Command flow和Data flow分离法则   ☆ 法则-5.  集装箱式抽象法则   ☆ 法则-6.  基类创建子类对象法则   ☆ 法则-7.  把基类当礼物送别人法则   ☆ 法则-8.  从简单组合出复杂法则   ☆ 法则-9.  从简单中叫出复杂法则   ☆ 法则-10. 没钱就改版，改版就有钱法则

讲师：高焕堂

详细履历，请参考网页<认识高焕堂>：

          http://8204129.blog.51cto.com/8194129/1354869

~End ~