您可以捐助,支持我们的公益事业。

1元 10元 50元





认证码:  验证码,看不清楚?请点击刷新验证码 必填



  求知 文章 文库 Lib 视频 iPerson 课程 认证 咨询 工具 讲座 Model Center   Code  
会员   
   
 
     
   
 订阅
  捐助
一个可供创业公司参考的移动APP服务端架构演进方案
 
来源:InfoQ 发布于:2017-6-16
   次浏览      
 

随着智能设备普及和移动互联网发展,移动端应用逐渐成为用户的新入口,重要性越来越突出。但企业一般是先有PC端应用,再推APP,APP 1.0版的功能大多从现有PC应用平移过来,没有针对移动自身特点考虑APP的架构。随着APP越来越复杂,功能和非功能要求越来越高,架构的先天不足逐渐成为大型APP升级的瓶颈。

本文作者结合大型移动应用的落地实践,从服务端架构设计角度,阐述如何进行升级优化,为后续APP做大做强奠定架构基础,供大家参考。

本文主要内容包括:

1.V1架构

2..问题分析

3..V2架构

4..智能升降级

5..总结

V1架构

APP可以分为手机端和服务端,手机端负责UI,相对简单,服务端负责提供数据和业务逻辑,相对更为关键。APP 1.0版的服务端架构比较简单,一般在原有PC端web应用的基础上增加无线接口,供APP调用,如图一所示。

服务端系统一方面以web应用的方式提供给PC端浏览器访问,另一方面为支持移动,在web应用基础上增加一些REST接口直接供APP访问。相应地,无线接口和web应用作为同一工程开发,作为同一个应用部署,这种设计思路是很直接和自然的,可以快速把PC端功能复制到APP。

问题分析

上述设计是在现有web应用上打补丁,体现的是PC思维无线化,把APP简单作为PC端应用的翻版,并把两者物理上捆绑在一起,带来一系列的问题:

1、紧密耦合

无线接口和web应用紧耦合,web端的修改会影响无线接口,web端的发布导致无线接口被动连带发布,web端的bug影响无线接口的可用性,反过来也一样,无线接口的任何变化会影响web应用。

2、重复开发

无线接口除了给APP提供业务数据,还需要考虑一系列非功能性因素,如通讯协议和数据格式封装、安全控制、日志记录,性能监控等,这些对每个无线接口都适用。如果APP和后端系统直连,意味着每个后端系统都需要单独支持这些通用功能,导致重复开发。一旦这些通用需求有变化(如对数据传输进行加密增强),所有后端系统都要强制同步修改和上线,给项目管理带来很大挑战。

3、稳定性

APP和多个后端系统直连,只要一个系统出问题,就会影响APP的可用性,缺乏故障隔离机制,导致APP非常脆弱。

这些问题本质上是因为没有把web应用和APP做清晰隔离,导致相互影响,一损俱损。

那么如何实现有效隔离呢?首先两者共享核心的业务逻辑,所以核心业务逻辑要独立出来,以一致的方式供APP和web调用;同时,无线接口服务于APP,和web前端没有任何关系,需要进一步对它们进行剥离,单独维护和部署,经过拆分后架构如图二所示。

V2 架构

除了APP和web应用拆分,架构改造还必须考虑APP自身的特点。APP一方面需要从服务端各个系统获取数据,这个是个性的,面向业务;另一方面所有调用需要非功能性的通用处理,这个是共性的,并且和业务无关。架构上需要做到统分结合,共性统一处理,个性分散处理。

最后,结合APP/web拆分需求和APP自身特点,新的APP架构方案如图三所示。

1、对等隔离

APP实际上和PC端浏览器是对等的,PC端应用有服务端,APP也需要自己独立的服务端,两个服务端都需要针对自身的特点,独立开发,独立部署,同时实现逻辑和物理层面的解耦,从架构层面彻底摆脱PC思维无线化。

2、统一服务

核心逻辑从web应用剥离出来,进行服务化改造,服务实现时不区分PC和无线,APP和web应用都依赖于这些服务,一套接口,多方调用。

3、统一网关入口

提供统一的无线网关,所有APP调用指向此网关,网关包括通用层、接口路由层、适配层。

通用层

通讯协议适配、数据封装、安全、监控、日志这些系统级功能,每个接口调用都需要同样逻辑,这些功能统一由网关前置处理,避免重复开发。具体实现时,每个通用处理逻辑封装成拦截器,遵循统一的过滤接口,并且做到可配置,网关依次调用这些拦截器,这样可以支持通用逻辑的灵活扩展。

拦截器接口定义如下:

Object filter(Object input) throws Exception

接口路由

经过通用逻辑预处理后,无线接口请求将进一步分发给后端处理(各个Adapter)。URL和Adapter在配置文件里做映射,分发逻辑根据请求中的URL信息,找到对应的Adapter,然后把请求交给Adapter处理。

配置例子如下:

www.website.com/search SearchAdapter

www.website.com/detail DetailAdapter

服务适配

外部无线接口和内部SOA接口的输入输出格式以及通信协议很可能不一样,比如前者经常是HTTP+JSON格式,后者可能是Hessian+二进制格式,Adapter首先用于无线接口和内部SOA接口的适配,除此之外,Adapter还可能对多个SOA服务做聚合,对APP提供粗粒度的数据,以减少远程网络调用次数。实现上一般每个业务系统有一个Adapter,负责本系统无线接口的调用适配。

Adapter接口定义如下:

Object adapter(Object input) throws Exception

Adapter物理上是jar包,由各个业务线研发团队提供,作为相应SOA服务的前置,最终所有Adapter集中部署在网关,网关本身支持水平扩展。

智能升降级

网关支持集中管控的同时,也带来单点问题。假设后台某个服务接口,由于某种原因,性能有严重问题,对应Adapter处理很慢,那么网关所在服务器的线程很快被耗尽,导致单个接口拖垮整个系统。这种问题,单纯通过加机器,水平扩展网关数量是解决不了的,实践中,我们引入智能升降级机制快速隔离单个接口的影响,如图四所示:

针对特定一个接口,如果在一定时间间隔内(比如5秒钟),它的超时失败率到了一定比例(比如2%),网关会对该接口做降级处理,随机抛弃部分流量,比如只允许50%流量通过。下一个5秒再评估,如果失败率还没有改善,允许通过的流量降到25%,以此类推。

如果成功率好转,网关对该接口做升级处理,提升通过的流量比例,为了快速恢复,一般提升到原流量4倍,然后在下一个时间段再评估是否触发升降级。

整个过程全自动智能处理(为防止误判,可支持人工干预),这样单个接口出问题,不会影响整个网关的处理能力。

总结

APP服务端架构通过一系列的拆分和整合,既优化了公司整体应用架构,又为APP做大做强奠定良好基础,其带来的好处是全方面的:

1.实现PC端应用和移动端应用分离,使两者彻底解耦,各自独立发展,APP从寄生藤变成并蒂莲。

2.底层核心的SOA服务基于统一业务规则提供逻辑和数据,接口不区分PC、无线或其他渠道(如Open API),避免重复开发,避免业务逻辑被污染。所有前端一母同胞,本是同根生。

3.根据无线本身的特点,支持系统层面的集中处理和业务层面的分散处理。通用逻辑支持插件化扩展,可以根据需要逐步补充;Adapter实现内外部接口的无缝转换,可以针对无线场景,做逻辑增强(如服务聚合)。前面师傅领进门,后面修行靠各妈。

4.移动研发团队和各业务线研发团队各司其职,每个团队专注于自己擅长部分,移动团队负责APP客户端和网关通用逻辑处理,各业务线研发团队负责底层SOA服务及前端Adapter适配。上帝的归上帝,凯撒的归凯撒。

如果用一个字描述APP架构,V1是“爪”,年幼依托各家;V2是“丫”,长大独立成家。

新架构,大型APP应用的成年礼,你“Y”准备好了吗?

   
次浏览       
相关文章

企业架构、TOGAF与ArchiMate概览
架构师之路-如何做好业务建模?
大型网站电商网站架构案例和技术架构的示例
完整的Archimate视点指南(包括示例)
相关文档

数据中台技术架构方法论与实践
适用ArchiMate、EA 和 iSpace进行企业架构建模
Zachman企业架构框架简介
企业架构让SOA落地
相关课程

云平台与微服务架构设计
中台战略、中台建设与数字商业
亿级用户高并发、高可用系统架构
高可用分布式架构设计与实践