架构实战案例解析
王庆友
前 1 号店首席架构师
18817 人已学习
新⼈⾸单¥59
登录后,你可以任选4讲全文学习
课程目录
已完结/共 23 讲
架构实战案例解析
15
15
1.0x
00:00/00:00
登录|注册

05 | 可扩展架构案例(二):App服务端架构是如何升级的?

你好,我是王庆友。
上一讲,我与你介绍了电商平台从单体架构到微服务架构的演变过程。那么今天,我会通过一个 1 号店 App 服务端架构改造的例子,来具体说明架构的演变过程,让你能更深入地理解架构演变背后的原因。
好,先让时间拨回到 2012 年,当时随着智能设备的普及和移动互联网的发展,移动端逐渐成为用户的新入口,各个电商平台都开始聚焦移动端 App。这个时候,1 号店也开始试水移动端购物,从那时起,1 号店 App 的服务端架构一共经历了三个版本的变化。
接下来,我就为你具体介绍 App 服务端架构变化的过程以及原因。

V1.0 架构

我先说说最开始的 1.0 版本。当时的情况是,App 前端的 iOS 和 Android 开发团队是外包出去的,而 App 的服务端是由 1 号店内部一个小型的移动团队负责的,这个团队主要负责提供 App 前端需要的各个接口,接口使用的通信协议是 HTTP+JSON。
具体的架构如下图所示:
这个架构比较简单,App 的服务端整体上就一个应用,由移动团队来维护所有对外接口,服务端内部有很多 Jar 包,比如商品搜索、商品详情、购物车等等,这些 Jar 包包含了各个业务线的业务逻辑及数据库访问,它们由各个业务线的开发者负责提供。
你可以看到,这个 1.0 版本的服务端,实际上就是一个单体应用,只是对外的接口和内部 Jar 包分别由不同的团队来提供,这个架构的优点和缺点同样都非常明显。
确认放弃笔记?
放弃后所记笔记将不保留。
新功能上线,你的历史笔记已初始化为私密笔记,是否一键批量公开?
批量公开的笔记不会为你同步至部落
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线
笔记
复制
AI
  • 深入了解
  • 翻译
    • 英语
    • 中文简体
    • 中文繁体
    • 法语
    • 德语
    • 日语
    • 韩语
    • 俄语
    • 西班牙语
    • 阿拉伯语
  • 解释
  • 总结

1号店App服务端架构的演变过程展示了从单体架构到微服务架构的升级过程。文章首先介绍了1.0版本的架构存在的问题,如移动服务端对Jar包的紧密依赖、移动团队的职责过分复杂以及团队并行开发困难。随后,文章详细介绍了V2.0架构的升级,强调了业务线团队的生产力得到释放,但也带来了移动端和PC端互相干扰、重复开发和稳定性等问题。最后,文章提到了V3.0版本的架构演变,强调了针对移动端自身特点的架构设计。V3.0版本的架构包含了两个大的升级,对每个业务线的服务端进行拆分,让App接口和PC端接口各自在物理上独立,但它们共享核心的业务逻辑。架构改造还考虑了移动端自身的特点,将共性的系统级功能进行集中处理,把个性化的业务功能进行分散处理。移动网关的内部实现分为通用层、接口路由层和服务适配层。架构升级达到了App端和PC端彻底独立、核心业务的复用、系统级功能的强化以及团队分工更明确等实际效果。通过这次架构改造,1号店实现了基础业务的复用,系统的平台化改造,解放了业务线,提升了系统的稳定性,使得移动端可以做大做强。整体而言,本文通过1号店App服务端架构的演变过程,展示了架构升级的必要性和技术挑战,为读者提供了深入了解架构演变背后原因的视角。

仅可试看部分内容,如需阅读全部内容,请付费购买文章所属专栏
《架构实战案例解析》
新⼈⾸单¥59
立即购买
登录 后留言

全部留言(29)

  • 最新
  • 精选
  • 小杰
    置顶
    老师,能对网关那块做详细讲解么,我是后端业务开发,提供dubbo接口给api网关层。从代码级别我知道controller在api那面实现,其余的理解很少了,希望老师从整体点播下

    作者回复: 网关本质是一个web应用。 1. 网关先根据配置的拦截器,调用它们的filter接口挨个处理,如果有严重错误,就直接返回前端异常。 2. 处理完后,根据请求的URL找到对应的适配器,调用适配器的adapter方法,传入请求参数。 3. 从服务的调用角度看,adapter就是服务的调用方,它把用户的参数封装成服务的调用参数,然后调用服务,解析返回信息,构建前端需要的响应,交给网关返回。

    2020-03-09
    3
  • 川杰
    置顶
    老师,问个小问题:为什么您在画图的时候,要把 无线接口 和 WEB 分开,他们在细节上有什么区别吗?我理解都是一个webApi啊?

    作者回复: 当时web端还没有前后端分离,web端还负责页面渲染,它给浏览器返回的是数据和html内容。

    2020-03-02
  • Din
    置顶
    老师好! 1. 在3.0架构中,网关中的适配层是不是和BFF层职责一样? 2. 适配器是 Jar 包的形式,由各个业务线研发团队提供。会不会存在一个聚合服务不能落在某一个业务应用服务中,最终还是需要多一层聚合服务? 3. 为什么PC端没有网关层呢?

    作者回复: 和BFF类似。 业务线团队包括这个业务线端到端的场景,他们负责app过来的接口调用,会在jar包里对服务做聚合。 当时前后端没分离,PC端有自己的web应用,在这里可以做很多功能。

    2020-03-02
    3
  • 虚竹
    置顶
    老师好,今天的课程讲的非常好,帮我理清了脉络,感谢,我是一名一线的业务开发人员,目前我们这边类似老师讲的V3.0架构,请教下, 1.如果进一步发展,web端使用前后端分离了,跟APP端一样http+json,那对于各业务线来说,是又从3个服务变成1个服务了吗?(当然1个业务服务内部可能是有很多业务侧微服务组成的) 2.业务线提供的api,除了给网关使用(外),还有供其他业务线调用的(内),以及前后端分离后自己的前端APi(自己),每部分会有各自的适配逻辑,但也都共享底层业务逻辑,在实际架构中,这部分不同的api 是放在同一个服务中通过包或类区分还是拆分为几个服务更合适? 3.进一步的发展应该就是微服务,中台了,老师还会继续实际演化的实例的吧?非常期待~

    作者回复: 1.如果进一步发展,web端使用前后端分离了,跟APP端一样http+json,那对于各业务线来说,是又从3个服务变成1个服务了吗?(当然1个业务服务内部可能是有很多业务侧微服务组成的) 如果象现在流行的前后端分离,那么无论是app,浏览器还是小程序都通过网关访问服务端,由网关统一路由到背后的服务。 2.业务线提供的api,除了给网关使用(外),还有供其他业务线调用的(内),以及前后端分离后自己的前端APi(自己),每部分会有各自的适配逻辑,但也都共享底层业务逻辑,在实际架构中,这部分不同的api 是放在同一个服务中通过包或类区分还是拆分为几个服务更合适? 这部分api是定制的,经常变,本质上不是服务,是应用,当然你也可以认为应用服务,这部分要分开。 3.进一步的发展应该就是微服务,中台了,老师还会继续实际演化的实例的吧?非常期待~ 后面会有深入介绍。

    2020-03-02
    3
    2
  • 探索无止境
    置顶
    老师您好,在V3.0架构中,通用层里面的协议适配,安全,日志,监控这几块具体做什么,怎么落地,能否提供一个推荐的方案?

    作者回复: 安全比如对进来的请求进行签名校验,请求和响应里有sign字段,确保它的值和其他业务请求参数匹配。 日志比如在网关里记录request/response到ELK。 监控比如用APM工具跟踪请求,这里作为链路监控的开始。 协议适配比如对外输出时,使用protobuf提高传输效率。 这些功能和业务无关,并且相互独立的,非常合适作为拦截器实现,比如spring cloud 的zuul网关可以提供很好的落地。

    2020-03-02
    10
  • Geek_a04165
    “服务适配层 最后是服务适配层。我们知道,外部接口的请求格式,往往和内部服务接口的格式是不一样的。具体到 1 号店当时的情况,外部接口是 HTTP+JSON 格式,内部服务是 Hessian+ 二进制格式。” 服务适配器是单独部署的一个服务吗,由业务团队还是移动端团队开发?app端的个性化需求在也是在adapter开发吗,我对adapter的职责有些困惑🤓 在我理解应该将app端的业务层和网关层独立开来;app业务层可以对多个服务聚合,可以提供个性化需求,由业务团队负责;网关层的职责就是打造通用非功能性需求;不知道是否正确,请老师指导一二🤓

    作者回复: 你的理解是正确的,网关层负责系统级功能,包括协议转换,接口路由,日志监控,和具体业务无关;app业务层是聚合层,站在app角度,对后端服务进行聚合。 专栏里说的网关是广义的,在后端服务和app端建立桥梁,已经包含了上面说的网关层和app业务层。

    2022-07-24归属地:上海
    1
  • Cheney
    App 前端会通过移动网关来访问服务端接口。这里的网关主要就是负责处理通用的系统级功能,包括通信协议适配、安全、监控、日志等等;网关处理完之后,会通过接口路由模块,转发请求到内部的各个业务服务,比如搜索服务、详情页服务、购物车服务等等。对于 PC 端浏览器来说,它直接访问对应的 Web 应用,如搜索应用、详情页应用等,然后这些应用也是访问同样的内部服务。 请教老师,无线网关为什么只能针对APP,不能把WEB应用也管理起来,难道WEB应用就不需要包括通信协议适配、安全、监控、日志等等功能么。

    作者回复: 也可以的,但当时的情况是,web先行,已经有类似一套东西。另外app端情况更特殊一点,比如通信协议,为提供传输性能,数据会采取压缩,还有特别的签名等加强安全。

    2021-04-18
    1
  • Geek_35c0ff
    请问网关是无状态的,这里的状态是什么含义呢?可否举一个现实的例子说明一下,谢谢老师

    作者回复: 当前的请求处理和上一个请求没有关系,也就是处理请求的逻辑只依赖于请求自带的参数,全局共享的内容(数据库或缓存等),和当前web机器没有关系。 一个请求分发给A机器或B机器,都不影响返回结果。

    2020-09-28
    1
  • jian
    老师,请问为什么外部接口的请求格式,往往和内部服务接口的格式是不一样的?如果一样都是二进制格式,效率都高,而且不用适配。

    作者回复: 有很多原因,导致外部接口和内部接口不一致。 1. 外部接口安全起见,一般走http协议,也不会用二进制,否则导致前端构造请求和解析响应困难。内部服务可以从提高性能考虑走rpc协议和二进制。 2.另外外部接口的还会有一些额外参数,比如签名(sign),token等。 3. 最后,内部有些老服务由于历史原因,方法和参数命名往往不规范,不适合直接暴露出去,需要按照统一的命名方式。

    2020-05-23
    1
  • 小洛
    请教下老师网关数据缓存的设计以及如何保证一致性

    作者回复: 主要是针对一些静态数据,比如商品详情数据,根据url和商品详情内容缓存,url会自带商品ID。 这里的缓存主要是提供可用性,在商品详情服务有问题的情况下,仍旧可以给前端接口提供返回,一致性不是重点。

    2020-03-15
    1
收起评论
显示
设置
留言
29
收藏
沉浸
阅读
分享
手机端
快捷键
回顶部