05 _ 可扩展架构案例（二）：App服务端架构是如何升级的？

最新推荐文章于 2024-01-12 16:42:29 发布

原创

最新推荐文章于 2024-01-12 16:42:29 发布 · 1k 阅读

CC 4.0 BY-SA版权

文章标签：

本文通过1号店App服务端架构从V1.0到V3.0的演变，阐述了架构升级的原因和实际效果。初期的单体架构简洁但存在依赖问题，随后演变为分布式架构，各业务线独立，但移动端与PC端相互干扰。最终，通过引入移动网关实现服务化，解决了系统级功能的强化和团队分工问题，提升了系统稳定性和开发效率。

本章将会通过一个1号店App服务端架构改造的例子，来具体说明架构的演变过程，进而能更深入地理解架构演变背后的原因。

好，先让时间拨回到2012年，当时随着智能设备的普及和移动互联网的发展，移动端逐渐成为用户的新入口，各个电商平台都开始聚焦移动端App。这个时候，1号店也开始试水移动端购物，从那时起，1号店App的服务端架构一共经历了三个版本的变化。

接下来，我就为你具体介绍App服务端架构变化的过程以及原因。

我先说说最开始的1.0版本。当时的情况是，App前端的iOS和Android开发团队是外包出去的，而App的服务端是由1号店内部一个小型的移动团队负责的，这个团队主要负责提供App前端需要的各个接口，接口使用的通信协议是HTTP+JSON。

具体的架构如下图所示：

这个架构比较简单，App的服务端整体上就一个应用，由移动团队来维护所有对外接口，服务端内部有很多Jar包，比如商品搜索、商品详情、购物车等等，这些Jar包包含了各个业务线的业务逻辑及数据库访问，它们由各个业务线的开发者负责提供。

你可以看到，这个1.0版本的服务端，实际上就是一个单体应用，只是对外的接口和内部Jar包分别由不同的团队来提供，这个架构的优点和缺点同样都非常明显。

它的优点是简单方便。App前端的外包团队只需要对接后端的一个移动团队就可以了，然后移动团队通过现成的Jar包，封装各个业务线的功能。至于这些Jar包，业务线团队也无需额外去开发。

为什么呢？我们知道，早期的电商平台都是先有PC端应用，再推App，App最开始的功能，大多是从已有的PC端平移过来的。因此，这些Jar包直接从PC端应用里拿过来就可以了，如果Jar包版本有更新，由业务线团队直接同步给移动团队即可。

那这个架构设计是不是很完美啊？当然不是，不知道你发现了没有，其实这里也存在了很多问题。

移动团队负责对外接口，但他们非常依赖业务团队提供的Jar包来实现业务逻辑，这是一种物理上的紧耦合依赖关系。

如果业务团队根据PC端的需求，修改了应用代码后，Jar包也会随之修改。那么在实践中，经常会出现这样的情况：业务团队很多时候，要么忘了同步新的Jar包给移动团队，要么是新的Jar包调整了类的接口，导致了App服务端的功能有问题，或者直接不可用。

服务端为App提供的是粗粒度接口，而业务团队的Jar包提供的是细粒度的接口。

因此，移动团队在Jar包的基础上，还需要做很多的业务逻辑聚合，很多时候，这些逻辑还跨多个业务线，导致移动团队对所

1 条评论