考拉超收2.0设计改造 - Walker2020/-2.0- GitHub Wiki

前言 随着公司业务高速发展，业务的快速发展对技术支撑提出了更高的要求。为线上用户提供高稳定的服务体验,保障全链路业务和系统高可用运行的同时,要提升多入口业务的研发速度,推进App系统架构的合理演化,进一步提升跨部门跨地域团队之间的协作效率。而另一方面随着用户数与流量的高速增长业务逐渐有了流量平台的特征,子品牌业务纷纷尝试接入业务进行推广和发布,期望提供统一标准化服务平台。因此,基础能力标准化,推进多端复用,同时输出成熟稳定的技术服务平台,一直是我们技术团队追求的核心目标。

  多端复用的端 这里的“端”有两层意思： ·其一是相同业务的多入口 mpos业务在App下的业务入口有三个【收款宝】、【考拉超收】、【收款宝MAX】。 ·其二是指平台上各个业务线 MPOS及子品牌业务线都依赖MPOS基础业务,包括但不限于:商户进件、刷卡交易、扫码交易、设备管理等。考虑到标准化的范畴,这些基础能力也是需要多端复用的。 关于组件化 提到多端复用,不免与组件化产生联系,可以说组件化是多端复用的必要条件之一。大多数公司口中的“组件化”仅仅做到代码分库,使用Cocoapods的Podfile来管理,再在主工程把各个子库的版本号聚合起来。但是能设计一套合理的分层架构,理清依赖关系,并有一整套工具链支撑组件发版与集成的相对较少。否则组件化只会导致包体积增大,开发效率变慢,依赖关系复杂等副作用。

整体思路 A. 多端复用的概念 /images/超收网络库结构图.png

    多端复用的目标形态其实很好理解,就是将原有主工程中的代码抽出独立组件(Pods/Gradle) ,然后各自工程使用Podfile/Gradle依赖所需的独立组件,独立组件再通过podspec间接依赖其他独立组件。       B. 准备工作 前端开源库(网络、图片、布局)每个功能基本都有一个库业界垄断。公司内也存在一些对开源库二次开发或自行研发的基础库,即技术栈。不同的大组之间技术栈可能存在一定差异。如需要复用的端之间存在差异,则需要重构使得技术栈统一。(这里建议重构,不建议适配,因为如果做的不够彻底,后续很大可能需要填坑。) 1、移动金融平台基础功能组件主要包括网络库、数据加解密、人脸识别、OCR等。业务组件包括商户进件、商户信息、刷卡交易、扫码交易等。如下图所示：       2、超收除了引用移动金融平台基础功能组件外，主要还包括推送、分享、KoalaJS、crash统计、weexbridge、广告、定向业务等主要功能模块。如下图说是：       3、移动金融基础组件库封装步骤及使用以网络库为例可分为以下四步： 1、封装移动金融网络框架MFBPHTTP。 2、把MFBPHTTP放到移动金融平台基础组件库里面。 3、集成移动金融组件库到超收APP。 4、超收根据移动金融基础组件库MFBPHTTP封装自己的网络库。 网络库具体依赖关系如下图所示：               5、移动金融封装基础组件库基本可抽成以下4步来完成。     文档结构图 移动金融平台及考拉超收前端需要产出重要文档结构图如下：    

  总结

1、多端复用之后对PM-RD-QA都有较大的变化,我们代码复用率显著提高,让更多的PM投入到了新需求的吞吐中,但研发效率提升增大了QA的工作量。一个大的尝试需要RD不断与PM和QA保持沟通,选择三方都能接受的最优方案。 2、分清主次关系,技术架构等最终是为了支撑业务,如果一个架构设计的美如画天衣无缝,但是落实到自己的业务中确不能发挥理想效果,或引来抱怨一片,那这就是个失败的设计。并且在实际开发中技术类代码修改尽量选择版本间隙合入,如果与业务开发的同学产生冲突时,都要给业务同学让路,不能影响原本的版本送代速度。 3、时刻对“不合理”和“重复劳动"保持敏感。新增一个埋点常量要去改一下平台再发个版是否成本太大?实际开发中遇到别扭的地方多增加一些思考而不是硬者头皮过去,并且手动重复两次以上的操作就要思考有没有自动化的替代方案。