移动应用整体技术覆盖分析

移动应用能力体系设计分析彭彬浙江大学城市学院2016年3月移动互联网条件下的开发方法移动化应用的体系设计如果类比于传统的BS系统，从应用层次上进行设计的切入点有很大的相同点，但是由于移动条件下端平台的差异极大，以及用户量和应用升级等方面的不同要求，导致的问题将远远大于当前BS结构的应用开发。移动互联网条件下的开发方法使用的技术构成是松散的，一个最典型的技术要素如下图所示：移动互联网条件下的开发方法

技术选择下表进一步说明了移动互联网条件下导致实现技术更加松散（使用Native

Apps）工作端开发基础主流框架数据交互AndroidJavaADKJSON/XMLiOSObjectC/SwiftiOSSDKJSON/XMLWebJavascriptJquery/Bootstrap/BackboneJsReactJsHTML/CSS/JsServer(ForNativeClient)JavaRestful(Jersey）JSON/XMLServer(Web)JavaSSHHTML/CSS/JsServer(BizLogic)JavaHardCode/Rule/WorkflowXMLDBJavaORMapping(Hibernate/Cayenne)DB移动互联网条件下的开发方法

技术选择即使采用了混合开发模式，也只是在客户端部分的减少了Native代码的使用（使用Hybrid

Apps）*即使相同平台还需要考虑布局的适应性（即在布局和CSS层面同样需要考虑@media等标签构造自适应UI）,部分本地功能还会部分涉及到移动端本地语言工作端开发基础主流框架数据交互AndroidJs/CordovaJquery/Bootstrap/BackboneJsJSON/XMLiOSJs/CordovaJquery/Bootstrap/BackboneJsJSON/XMLWebJs/CordovaJquery/Bootstrap/BackboneJsHTML/CSS/JsServer(ForNativeClient)JavaRestful(Jersey）JSON/XMLServer(Web)JavaSSHHTML/CSS/JsServer(BizLogic)JavaHardCode/Rule/WorkflowXMLDBJavaORMapping(Hibernate/Cayenne)DB移动互联网条件下的开发方法

工程方法影响快速迭代为基础的各种敏捷开发方法的实施；比如以FDD（特性驱动的开发方法）为例，*图来自nebulonPty.Ltd移动互联网条件下的开发方法

工程方法最佳实践的时间分配1）由于移动条件下构建结构的庞杂和各个环节缺少统一的处理标准，将会导致快速迭代困难；相同特性在不同平台上的实现，测试等都会消耗较多时间，同时导致服务端可能需要不同的业务服务接口和方式；2）由于不同平台上使用不同的开发方式可能导致模型的表达会有差异（比如AndroidNative倾向于在App端研究后进行后台交互，而Web平台倾向于服务器端验证）；*数据来自nebulonPty.Ltd应对新挑战多样化移动端支持（Android，iOS，微信公众号，钉钉内置应用，移动网站，PC网站）；多样化的端导致的服务化设计；数据存储与访问；架构持续演进；挑战1：多样化的移动端支持多样化的端支持—混合模式当前由于端的多样性，对开发能力造成很大挑战，常见的端包括：Android，iOS，微信公众号（钉钉内置应用，移动网站等H5移动站）和PC浏览器当前的主流的解决方案是混合模式（HybridApp），其核心就是将App转换为基于H5的web开发，核心技术是Cordova+Js前端框架多样化的端支持—混合模式Cordova:Js和本地服务的“胶水”层，并提供了将本地功能嵌入整体应用的插件机制，提供完整的App结构;Js前端框架：解决js端的模块化，降低js复杂App的构造难度;之前的Jquery+Bootstrap的模式还只能视为js前端工具箱，不能称之为前端框架，当前具有代表性的前端框架：AngularJsReactJsionicAngularJs

ReactJs

ionic

docs/components/多样化的端支持—其他模式通过抽象化模型，将跨平台模型抽象为一个特定语言，然后通过语言编译转换的方式来在不同平台上运行；最有代表性的包括ReactNative：LearnOnce,WriteAnywhereTitanium:createcrossplatformnativemobileapplicationsusingexistingJavascriptskillsReactNative

ReactNative—RuntimeModel

Weex

Weex—Architecture

Titanium

Titanium—RuntimeModel

挑战2：服务化设计后端服务架构单一应用架构当网站流量很小时，只需一个应用，将所有功能都部署在一起，以减少部署节点和成本。此时，用于简化增删改查工作量的

数据访问框架(ORM)

是关键。垂直应用架构当访问量逐渐增大，单一应用增加机器带来的加速度越来越小，将应用拆成互不相干的几个应用，以提升效率。此时，用于加速前端页面开发的

Web框架(MVC)

是关键。分布式服务架构当垂直应用越来越多，应用之间交互不可避免，将核心业务抽取出来，作为独立的服务，逐渐形成稳定的服务中心，使前端应用能更快速的响应多变的市场需求。此时，用于提高业务复用及整合的

分布式服务框架(RPC)

是关键。流动计算架构当服务越来越多，容量的评估，小服务资源的浪费等问题逐渐显现，此时需增加一个调度中心基于访问压力实时管理集群容量，提高集群利用率。此时，用于提高机器利用率的

资源调度和治理中心(SOA)

是关键。

以Dubbo为例Dubbo是Alibaba开源的分布式服务框架，它最大的特点是按照分层的方式来架构，使用这种方式可以使各个层之间解耦合（或者最大限度地松耦合）。从服务模型的角度来看，Dubbo采用的是一种非常简单的模型，要么是提供方提供服务，要么是消费方消费服务，所以基于这一点可以抽象出服务提供方（Provider）和服务消费方（Consumer）两个角色。

以Dubbo为例—总体结构服务集成成为趋势移动时代同时也是云时代，服务化的发布模式为应用程序的开发设计带来极大便利和效率产生了大量的云服务商，提供从短信服务，及时通讯，账号服务，统计服务，缓存服务，存储服务等等几乎所有app开发的所有基础设施

服务集成—百度Api集市

服务集成—阿里百川

挑战3：数据存储数据存储当数据量上升，服务持续集成变化的时候，对数据存储提出了新的要求：严格的关系化数据模型很难适应变化以及大数据量的优化，非关系性数据库崛起；优化数据访问速度开始引入分布式的缓存系统；cassandraetoApacheCassandra™TheApacheCassandradatabaseistherightchoicewhenyouneedscalabilityandhighavailabilitywithoutcompromisingperformance.

Linearscalability

andprovenfault-toleranceoncommodityhardwareorcloudinfrastructuremakeittheperfectplatformformission-criticaldata.Cassandra'ssupportforreplicatingacrossmultipledatacentersisbest-in-class,providinglowerlatencyforyourusersandthepeaceofmindofknowingthatyoucansurviveregionaloutages.Cassandra'sdatamodelofferstheconvenienceof

columnindexes

withtheperformanceoflog-structuredupdates,strongsupportfor

denormalization

and

materializedviews,andpowerfulbuilt-incaching.

cassandra模式灵活：可以在系统运行时随意的添加或移除字段；可扩展性：Cassandra是纯粹意义上的水平扩展。为给集群添加更多容量，可以指向另一台电脑；多数据中心：多副本保存；分布式写操作：有可以在任何地方任何时间集中读或写任何数据。并且不会有任何单点失败。

cassandraehcacheEhCache是一个纯Java的进程内缓存框架，EhCache的主要特性有：快速；简单；多种缓存策略；缓存数据有两级：内存和磁盘，因此无需担心容量问题；缓存数据会在虚拟机重启的过程中写入磁盘；可以通过RMI、可插入API等方式进行集群；具有缓存和缓存管理器的侦听接口；支持多缓存管理器实例，以及一个实例的多个缓存区域；挑战4：架构持续演进架构持续演进由于移动服务具有持续性迭代，不断提供新服务的特点，软件架构的持续可演进非常重要；架构设计的方法非常多，但是核心是：基础设施稳固：比如数据存储，缓存系统等；服务粒度的定义：服务定义，发现等机制需要良好设计；服务调度：服务调度和组合应该自由和低耦合服务调度--kafka基于消息系统的服务调度设计，通过生产者消费者模型进行解耦

移动应用体系的教育要求（整体实践设计的覆盖）移动应用体系设计不同于传统的BS应用系统，必然导致课程建设内容上和组织上的极大差异