05 | 可扩展架构案例（二）：App服务端架构是如何升级的？
V1.0 架构
荧光笔
直线
曲线- 深入了解
- 翻译
- 解释
- 总结
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-093
川杰置顶老师，问个小问题：为什么您在画图的时候，要把 无线接口 和 WEB 分开，他们在细节上有什么区别吗？我理解都是一个webApi啊？作者回复: 当时web端还没有前后端分离，web端还负责页面渲染，它给浏览器返回的是数据和html内容。
2020-03-02
Din置顶老师好！ 1. 在3.0架构中，网关中的适配层是不是和BFF层职责一样？ 2. 适配器是 Jar 包的形式，由各个业务线研发团队提供。会不会存在一个聚合服务不能落在某一个业务应用服务中，最终还是需要多一层聚合服务？ 3. 为什么PC端没有网关层呢？作者回复: 和BFF类似。 业务线团队包括这个业务线端到端的场景，他们负责app过来的接口调用，会在jar包里对服务做聚合。 当时前后端没分离，PC端有自己的web应用，在这里可以做很多功能。
2020-03-023- 虚竹置顶老师好，今天的课程讲的非常好，帮我理清了脉络，感谢，我是一名一线的业务开发人员，目前我们这边类似老师讲的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-0232 
探索无止境置顶老师您好，在V3.0架构中，通用层里面的协议适配，安全，日志，监控这几块具体做什么，怎么落地，能否提供一个推荐的方案？作者回复: 安全比如对进来的请求进行签名校验，请求和响应里有sign字段，确保它的值和其他业务请求参数匹配。 日志比如在网关里记录request/response到ELK。 监控比如用APM工具跟踪请求，这里作为链路监控的开始。 协议适配比如对外输出时，使用protobuf提高传输效率。 这些功能和业务无关，并且相互独立的，非常合适作为拦截器实现，比如spring cloud 的zuul网关可以提供很好的落地。
2020-03-0210
Geek_a04165“服务适配层 最后是服务适配层。我们知道，外部接口的请求格式，往往和内部服务接口的格式是不一样的。具体到 1 号店当时的情况，外部接口是 HTTP+JSON 格式，内部服务是 Hessian+ 二进制格式。” 服务适配器是单独部署的一个服务吗，由业务团队还是移动端团队开发？app端的个性化需求在也是在adapter开发吗，我对adapter的职责有些困惑🤓 在我理解应该将app端的业务层和网关层独立开来；app业务层可以对多个服务聚合，可以提供个性化需求，由业务团队负责；网关层的职责就是打造通用非功能性需求；不知道是否正确，请老师指导一二🤓作者回复: 你的理解是正确的，网关层负责系统级功能，包括协议转换，接口路由，日志监控，和具体业务无关；app业务层是聚合层，站在app角度，对后端服务进行聚合。 专栏里说的网关是广义的，在后端服务和app端建立桥梁，已经包含了上面说的网关层和app业务层。
2022-07-24归属地：上海1
CheneyApp 前端会通过移动网关来访问服务端接口。这里的网关主要就是负责处理通用的系统级功能，包括通信协议适配、安全、监控、日志等等；网关处理完之后，会通过接口路由模块，转发请求到内部的各个业务服务，比如搜索服务、详情页服务、购物车服务等等。对于 PC 端浏览器来说，它直接访问对应的 Web 应用，如搜索应用、详情页应用等，然后这些应用也是访问同样的内部服务。 请教老师，无线网关为什么只能针对APP，不能把WEB应用也管理起来，难道WEB应用就不需要包括通信协议适配、安全、监控、日志等等功能么。作者回复: 也可以的，但当时的情况是，web先行，已经有类似一套东西。另外app端情况更特殊一点，比如通信协议，为提供传输性能，数据会采取压缩，还有特别的签名等加强安全。
2021-04-181- Geek_35c0ff请问网关是无状态的，这里的状态是什么含义呢？可否举一个现实的例子说明一下，谢谢老师
作者回复: 当前的请求处理和上一个请求没有关系，也就是处理请求的逻辑只依赖于请求自带的参数，全局共享的内容(数据库或缓存等)，和当前web机器没有关系。 一个请求分发给A机器或B机器，都不影响返回结果。
2020-09-281 
jian老师，请问为什么外部接口的请求格式，往往和内部服务接口的格式是不一样的？如果一样都是二进制格式，效率都高，而且不用适配。作者回复: 有很多原因，导致外部接口和内部接口不一致。 1. 外部接口安全起见，一般走http协议，也不会用二进制，否则导致前端构造请求和解析响应困难。内部服务可以从提高性能考虑走rpc协议和二进制。 2.另外外部接口的还会有一些额外参数，比如签名(sign)，token等。 3. 最后，内部有些老服务由于历史原因，方法和参数命名往往不规范，不适合直接暴露出去，需要按照统一的命名方式。
2020-05-231
小洛请教下老师网关数据缓存的设计以及如何保证一致性作者回复: 主要是针对一些静态数据，比如商品详情数据，根据url和商品详情内容缓存，url会自带商品ID。 这里的缓存主要是提供可用性，在商品详情服务有问题的情况下，仍旧可以给前端接口提供返回，一致性不是重点。
2020-03-151
