天猫网站内容架构分析(阿里系总结的好：开发模式升级手机天猫的解耦之路)

　　天猫网站内容架构分析(阿里系总结的好：开发模式升级手机天猫的解耦之路)

　　做同样的事情，感觉阿里系总结的很好：

　　首先要说的是：惭愧，惭愧。这本来是今年夏天在北京GMTC的分享，但早就应该写下来了。哎，癌症晚期的症状迟迟没有缓解，只是找了个借口去做双11，到此为止。

　　本次分享的信息可以在GMTC官网下载：

　　视频直播上线：“手机天猫脱钩之路”现场

　　这篇文章的标题是脱钩。有很多方法可以谈论解耦。本文以架构演进为线索，分享移动天猫的解耦之路。我认为，在移动天猫的成长过程中，一些玄学的思考和沉淀当然对大家有价值，工具和解决方案更值得借鉴。因此，本文将较少关注过程和原因，而更多地关注工具和解决方案。

　　是什么推动了进化

　　作为一个技术团队，我们升级技术架构的原因是多方面的，哪些因素是最关键的，进化的原因又是什么？

　　当然，更重要的是如何平衡快速升级技术架构的好奇心和仅仅满足业务和团队的需求。过分追求技术架构创新，过分追求新技术，不仅不能促进业务和团队的发展，反而会导致灾难。所以，作为一个优秀的技术团队，做多做少总是一个权衡。

　　架构如何演变

　　架构演进体现在哪些方面，作为一个技术团队，我们如何实现架构演进？这个问题因项目、团队和方向而异。本文仅介绍手机天猫开发过程中与解耦相关的演进过程。

　　开发模式升级

　　移动天猫团队已经从三个终端不到十人的小团队成长为近200人的大团队。下面详细介绍一下开发模式发生了怎样的变化？

　　整个模式升级基本经历了以下几个阶段：

　　一路走来，一步一个脚印，最终实现完全解耦。在这个过程中，我们积累了很多方法论和最佳实践。我觉得有两个工具值得介绍，下面会详细介绍。

　　解耦工具箱

　　工人要做好工作，首先要磨利他的工具。每个人都这么说，但不是每个人都能做到。一个有工具文化的团队，在质量和效率上都会有很大的优势。

　　一个项目从最初的状态迅速扩张到现在的天猫规模，其依赖比想象的要复杂。

　　在这个膨胀过程中，我将耦合分为三类：

　　接口耦合是指在用户操作过程中，从首页-到搜索-到详情-到店铺，这些接口的跳转都是硬编码的依赖耦合。顾名思义，两个模块之间的依赖就是耦合工程耦合。每个模块都有自己的生命周期和运行时，每个模块在生产环境中都需要依赖主项目的运行时

　　Beehive 是一个运行时框架，主要解决依赖耦合和工程耦合。

　　说到耦合，对于手机上的天猫这样的app来说，各种依赖肯定是非常复杂的，模块之间的耦合必然是千丝万缕的。我们需要做的不是对这些依赖耦合进行一一处理，而是将不合理的部分梳理出来解决，使整个项目处于健康合理的依赖耦合范围内。基本上有以下几种有问题的依赖关系：

　　模块循环依赖 层间反向依赖 非强函数依赖

　　下图是依赖关系*敏*感*词*。

　　有几条虚线的依赖是我认为有问题的，同时抽象出有问题的模块

　　引入 Beehive 后，依赖关系会引出几条红线到 Beehive 模块，而 Beehive 模块是独立于每一层的。

　　Beehive 的原理是每个提供外部服务的模块都需要向 Beehive 提供的 Interfaces（接口池）注册一个抽象接口。请注意，此池中只有抽象接口。

　　在开发阶段，调用者依赖接口池中响应的接口，以接口为参数，通过Beehive提供的工厂方法获取一个服务实例，该实例可以正常服务。

　　在运行阶段，Beehive 工厂方法根据服务的注册配置构造一个服务实例。如果：当前运行环境不依赖于提供服务的模块，则返回空；if：当前运行环境有完整的依赖，会开始构建服务并返回。

　　通过这样的方案，可以实现模块之间的解耦。

　　统一跳协议和重写引擎

　　统一调整协议是基于URL的重定向方案，配合Rewrite引擎实现所有app调用的解耦。之前有文章对Apple Core的详细介绍，这里不再赘述。

　　Beehive 和 Unijump & Rewrite 的区别

　　Beehive 的目的和统一跳转协议是解耦的，那么两者的侧重点就不同了。统一跳转主要针对接口解耦服务，业务对接口链接动态性要求强；Beehive 是针对模块解耦的，解决了强模块依赖带来的开发阶段痛点。

　　以上就是我们这几年在整个手机天猫经历的脱钩过程。在这个过程中，我们思考了很多，踩了很多坑，当然也积累了很多有用的工具。希望以后有更多的机会和大家分享，也欢迎大家与我们交流，互相学习。

　　感谢徐川审阅本文。