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

分享到:  QQ好友和群QQ好友和群 QQ空间QQ空间 腾讯微博腾讯微博 腾讯朋友腾讯朋友 微信微信
查看查看81 回复回复1 收藏收藏 分享淘帖 转播转播 分享分享 微信
查看: 81|回复: 1
收起左侧

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

[复制链接]
攻城狮 发表于 2016-10-30 05:33:52 | 显示全部楼层 |阅读模式
快来登录
获取优质的苹果资讯内容
收藏热门的iOS等技术干货
拷贝下载Swift Demo源代码
订阅梳理好了的知识点专辑

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

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

专业技术顾问王庆友:大型App服务端架构演化及最佳实践 - 敏捷大拇指 - 专业技术顾问王庆友:大型App服务端架构演化及最佳实践





1、架构历史和问题

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

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




2、最新服务端2.0架构

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




3、App架构总结

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




4、架构本质的理解

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

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

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

都看到这里了,就把这篇资料推荐给您的好朋友吧,让他们也感受一下。

回帖是一种美德,也是对楼主发帖的尊重和支持。

*声明:敏捷大拇指是全球最大的Swift开发者社区、苹果粉丝家园、智能移动门户,所载内容仅限于传递更多最新信息,并不意味赞同其观点或证实其描述;内容仅供参考,并非绝对正确的建议。本站不对上述信息的真实性、合法性、完整性做出保证;转载请注明来源并加上本站链接,敏捷大拇指将保留所有法律权益。如有疑问或建议,邮件至marketing@swifthumb.com

*联系:微信公众平台:“swifthumb” / 腾讯微博:@swifthumb / 新浪微博:@swifthumb / 官方QQ一群:343549891(满) / 官方QQ二群:245285613 ,需要报上用户名才会被同意进群,请先注册敏捷大拇指

嗯,不错!期待更多好内容,支持一把:
支持敏捷大拇指,用支付宝支付10.24元 支持敏捷大拇指,用微信支付10.24元

评分

参与人数 1金钱 +10 贡献 +10 专家分 +10 收起 理由
Anewczs + 10 + 10 + 10 32个赞!专家给力!

查看全部评分

jswift 发表于 2016-11-3 15:45:22 | 显示全部楼层
Mark.
您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

做任务,领红包。
我要发帖

分享扩散

都看到这里了,就把这资料推荐给您的好朋友吧,让他们也感受一下。
您的每一位朋友访问此永久链接后,您都将获得相应的金钱积分奖励
关闭

站长推荐 上一条 /3 下一条

热门推荐

合作伙伴

Swift小苹果

  • 北京治世天下科技有限公司
  • ©2014-2016 敏捷大拇指
  • 京ICP备14029482号
  • Powered by Discuz! X3.1 Licensed
  • swifthumb Wechat Code
  •   
快速回复 返回顶部 返回列表