专业技术顾问王庆友--大型APP服务端架构演化及最佳实践

原创
云计算
在WOT2016移动互联网技术峰会上,王庆友前1号店首席架构师兼独立技术顾问为我们讲述APP服务端的变化过程。王庆友老师从四个方面为我们讲述:架构历史和问题、最新服务端2.0架构、APP架构总结及架构本质的理解。

【51CTO.com原创稿件】  在WOT2016移动互联网技术峰会上,王庆友前1号店***架构师兼独立技术顾问为我们讲述APP服务端的变化过程。王庆友老师从四个方面为我们讲述:架构历史和问题、***服务端2.0架构、APP架构总结及架构本质的理解。

[[174715]]

  架构历史和问题

  最初架构,可以称为0.1版本,架构本身非常简单了。首先有一个无线接口模块,统一对接APP的请求,内部是利用各个业务开发team提供架包完成业务逻辑返回结果。这个架构有两色,一个是集中式架构,另外是架包物理耦合。对于一开始提供一个简单的APP还是非常有利,但是后续弊端很明显,主要有两块:***,这是物理架包耦合,各个业务team负责架包开发,开发完需要同步给服务端开发team,经常导致双方通讯出问题,导致架包版本不一致,出现各种各样的坑。第二,对服务端开发team也很有挑战,他拿到架包,架包太原始了,需要对架包在基础上做很多梳理整合,汇总数据,提供给客户端,相当要理解所有1号店的业务逻辑,这个挑战性非常大。

  1.0架构,功能越来越多,对各个业务研发team,负责这个接口,一般情况下还是以PC端为主,不会提供单独应用实现无线功能,会在PC端Web系统提供简单的处理,无非还是HTTP请求,相当于在Web系统开了一个无线小窗口来满足APP的请求需要。这个架构对于提供业务功能还是很有利的,因为每个业务team非常熟悉本领域的业务逻辑,但是因为散带来后续一系列问题。***个问题,紧耦合,虽然不是架包物理耦合,无线小窗口跟Web系统耦合在一起,有两块独立的需求。第二问题,每个业务team拿到接口以后,更多关注业务功能开发,通用功能不大会关注,无线也有自身的特点,需要一些通用功能开发,包括无线协议分装、安全、性能监控、日志等等。

  ***服务端2.0架构

  在2.0架构,无线端处理过程跟Web端处理过程,两个完全相互独立,以前无线总体上是依附于Web系统,现在是完全独立的。接下来具体介绍一下无线网关内部三个层的设计。每个具体功能又是相对独立的,分装成拦截器的形式,各个拦截器共同组成处理链,分为Inbound进来的处理链跟outbound出去的处理链。一个请求过来首先经过Inbound处理,再进行具体业务处理,又反过来进行outbound处理,这里业务处理不是属于通用层,放上去只是为了更好说明目的。如果一个拦截器处理完以后,产生一些结果,后续拦截器想利用这个结果,是通过统一上下文对象传递信息。

  APP架构总结

  路由层,根据无线请求过来的URL里有路径信息,转发到具体的适配器。适配层,定位是各个业务系统在无线前端代理,是起到代理的作用,是根据预处理过的、通用处理过的请求,转发到后端实际业务系统做进一步处理,主要是适配和转发目的。具体接口也是把参数清晰分为两类:一类是偏业务参数,一类是偏设备参数。在无线网关系统级功能在通用层得到很好的处理,业务逻辑也是通过适配器做代理,后续也是得到很好的处理。服务升降级,中心化对外提供服务,每个无线请求过来,是用Java线程,都会有线程去对应做相应的处理,这部分资源是共享的。

  架构本质的理解

  一个系统开始比较简单、比较清晰,随着功能越来越多,像机房一样布线越来越多,慢慢整个体系非常混乱,架构整个系统混乱度增加,慢慢失控了。在物理上热力学有个很著名的熵增加理论,一个分配系统如果人为不对它进行干预,自然情况下慢慢会从有序变成更加无序,它的熵不断增加,这个熵是衡量一个系统的无序度。这时就需要架构介入,对系统进行有序化重构,为这个系统建立一个秩序体系。在这个秩序体系里,每个模块、每个功能都有一个清晰的定位,都是有序的,通过这个架构改善,最终减少系统的熵,使系统能够不断进化。架构改造的手段其实很简单,就是分和合。分首先把大的系统打散,成一个具体的子系统或者模块,这个打散不能是随意的,一定要根据每个子系统模块、定位,根据定位才能找到边界,才能进行合理切割,每个模块或子系统内部是高内聚的,模块、系统之间是松耦合的。最终可以根据具体业务需求有机组合起来,打造一个有机的系统,如果需要一个大的业务创新,可以简单调整一下,重新整合,可以快速满足业务需要。

  ***从分和合的角度,对服务端架构重新回顾一下。0.1架构是这个形状,很类似单体架构,我称之为形不散神散,形不散很好理解,神散是神比较散的,内部模块、子系统之间是非常紧密的耦合,如果想改一个地方就牵一发动全身,类似单体架构一样,神是比较散的。1.0架构,非常类似简单分布式架构,是直上直下烟囱型结构,这个称之为形散神也散。从单块来说还是有神的,端到端处理,但是总体上看神是比较散的,之间缺乏一个有机关联。2.0架构,有点类似于搭积木,这个称之为形散神不散,形散是很直观的,为什么说神不散?神体现在首先网关每一层有清晰的定位,各个层之间通过一致的数据格式、接口规范有机串接在一起,***完成端到端的功能。具体对通用层,通过拦截器链把各个拦截器有机结合起来,从单个拦截器来看功能很散,但是总体来看每个拦截器是一环扣一环,形成一个有机的总体,共同完成一个系统级的处理,所以是有它的神,很类似SOA架构。特别是最近比较热门的微服务架构,微服务形肯定是很散的,但神散不散?微服务架构需要一个重点考量的地方,微服务一定要把系统核心灵魂体现出来,如果只是打造成一个服务,微服务反而是一点价值没有,整个系统变成形散神也散的系统。不管是0.1架构、1.0架构还是2.0架构,需要提供的功能都是那么多,是由业务本性属性决定,少不了。但是通过一个有效重新分和合有机组合起来,整个架构给系统建立一个很清晰的秩序,在这个秩序下每一块都有明确的定位。有序化带来的结果,系统开发成本、开发效率,系统可用性、系统可扩展性都大大提高,这是架构带来的价值。

  一个好的架构必须像优美的散文一样,一定是形散神不散。

【51CTO原创稿件,合作站点转载请注明原文作者和出处为51CTO.com】

责任编辑:关崇 来源: 51CTO
相关推荐

2016-07-27 14:08:03

构架师APPWOT2016

2009-03-12 11:08:00

技术顾问职场杂谈

2018-03-08 15:00:45

2015-10-22 10:35:06

2022-02-18 11:13:53

监控架构系统

2024-04-01 13:18:15

App架构服务端

2016-08-04 14:41:21

架构java服务端开发

2014-09-26 09:53:41

系统架构架构架构演变

2016-12-05 15:09:43

2022-12-29 08:56:30

监控服务平台

2012-01-05 19:10:53

微软

2021-04-26 13:20:06

Vue服务端渲染前端

2024-05-16 13:13:39

微服务架构自动化

2018-07-20 14:50:31

水滴筹

2011-10-18 13:31:24

IE9TechEd 2011亓光宇

2021-09-28 09:27:37

Linux选举开发者

2015-11-27 13:57:16

数据中心机房

2024-03-06 14:58:52

客户端微服务架构

2024-05-27 00:00:00

PHP阿里云OSS

2016-03-18 09:04:42

swift服务端
点赞
收藏

51CTO技术栈公众号