58 赶集集团迟学奎:野心媲美能力,掌控移动架构大舞台

  • 陈兴璐

2016 年 6 月 30 日

话题:语言 & 开发架构

一个产品要么由多个业务组成,要么由一个业务的多个模块组成,要么是两者混合的。而 58 的 APP 多数都是由多个业务线,每个业务线又由多个模块组成。在初期,移动端团队承担多业务开发工作,而随着业务的不断发展,越来越多的业务线有独立的移动开发团队。多业务团队并行开发刻不容缓。

2016 年 7 月 15-16 日,ArchSummit 全球架构师峰会将在深圳举行,本届大会,我们邀请了 58 赶集集团移动架构师迟学奎老师,前来分享《58 同城 APP 多团队并行开发架构实践》的内容。移动端架构经历了从单团队到多团队并行开发的发展和变化。随之而来的问题也应运而生:push 落地页如何分发?上百个类目的发布页如何实现?IM 聊天如何适应各业务线的个性化?线上问题如何收集与修复?

我们借此机会采访了迟学奎老师,他分享了从传统 PC 行业走到移动互联网行业的一路体会。

InfoQ:可以介绍一下自己的从业经历吗?

迟学奎:毕业后我做的第一个产品是 MIS 系统,闷头做了 3 年,与企业客户打了 3 年交道,基本属于即做 PM 又做 RD 的工作,做得也很开心。

我是一个野心很大的人,不甘心一辈子在一个小城市,2005 年来北京谋求更大发展。刚来北京很艰苦,没什么积蓄,住在一个叫六圈的村里,像大杂院一样的院子里住了十几户,每月 60 块钱一间平房,每天起早坐 1 个多小时公交上班,地铁还很少只有 1、2 号线。来北京第一份工作是车载黑匣子、GPS 监控系统,面向物流运输公司等企业。第二份工作是银行外围系统研发,我主要负责做插件,给中软之类的大型服务商提供插件解决方案。第三份工作是股票交易分析软件,给新华社提供金融系统开发等,开始转入移动设备开发,那时候主要是 symban 和 Windows mobile 平台。如今在 58 赶集集团,从移动开发转到移动互联网行业了。

每份工作行业跨度有点大,整体上大概经历了传统 PC 软件开发、移动开发、移动互联网三个阶段。

InfoQ:沈剑分享过,好的架构不是设计出来的,而是演进出来的。那么,58 同城移动端的架构发展也是逐步演进的吗?经过了哪些阶段,面临过哪些挑战?如何解决?

迟学奎:沈剑老师说的很有道理,设计和演进还是有区别的。设计可以是根据需求想像出来的,演进是需求实施过程中不断遇到问题解决问题而沉淀下来的,实践性很强。而技术本身就是实践性很强的。58 同城移动架构也不例外,也是一步一步演进过来的,基本上分为 4 个阶段。

第一阶段:先入为主,跑步前进(Native)。最快的速度上线,纯原生开发,基本处于无设计阶段。

第二阶段:解决主要矛盾(H5)。实时上线,满足业务快速迭代,漫长的审核流程无法忍受,采用 H5。

第三阶段:回头,思考,再出发(Native+H5)。回头看一下走过的路,再看看存在问题,经过思考,回归用户体验。H5 性能不是很好,用户体验明显不如原生。App 的用户体验非常重要,尤其是用户端 App。于是功能转 Native,运营相关采用 H5 的混合开发模式。

第四阶段:组件化平台。搭建组件化公共平台,支撑多业务并行开发。

InfoQ:现在是移动互联网时代,移动架构师的工作与典型架构师的工作是否不一样?区别在哪里?

迟学奎:我们暂且将移动架构师分为广义的移动架构师和狭义的 App 架构师。

移动架构师与传统架构师:移动互联网时代的架构师对高并发、海量大数据的处理,高可靠、高稳定性、高度可扩展能力要求更高,很多 App 动不动就百万、千万的 QPS,并发处理能力一定要足够强才能支撑起业务需要;每天几个 TB 的数据存储与检索,传统的算法是搞不定的;百万、千万的日活用户,系统不够稳定,海量的用户投诉就来了,大量的用户可能就流失了;目前 App 迭代周期都比较短,甚至会短到 2 周发一个版本,可扩展性要求很高,产品需求来了,我花半个月重新设计架构,那不现实。

我曾经和国内某大型的传统软件公司的技术经理聊过这个事情,他们做移动互联网项目的时候,招聘有移动架构经验的高级人才来做,公司内的架构师搞不定海量大数据高并发,没有这种经历,实践经验不足。我们可以想像一下,中国最大的集团公司能有多少人?给他们开发一个系统 QPS 能有多少?能产生多少数据?相比较千万的 QPS,千万的日活就是一个天文数字啊。

App 架构师与传统的架构师:App 架构师只有一个移动设备(手机/pad),没有多服务器、集群那么高大上的设备;移动架构师面对的硬件资源限制比较大,无论是处理器、内存、显示等方面和计算机相比都相差很远。对架构的要求,对 RD 的要求也会更高更细。不合理的代码逻辑、过渡渲染都会不够流畅,内存占用过高会闪退,大大降低用户体验。

而移动互联网时代,恰恰 App 的体验非常重要,当用户面临很多选择的时候,用户耐心很差,非常容易放弃而卸载你的 App,导致用户流失,收到不好的口碑和评价,减少了你的潜在用户,且几乎没有回流的可能。所以在 App 时代,性能优化的作用被无限放大,大有性能比需求更加重要,体验比功能更加重要的趋势!

InfoQ:在 58 同城大型 APP 多团队中,你能描述一下你作为移动架构师的角色职责吗?

迟学奎: 职责主要有 4 个方面。

1. 整体框架的构建。

2. 解决技术难题。

3. 熟知业务。

4. 工程师的调配。

各个公司对架构师的职责要求各有不同,提到架构师这个角色,大部分人第一反应是纯做技术的,基本和业务不搭边的。其实我一直认为,脱离开业务去搞技术,是不现实的,任何架构都是要支撑业务而存在的。也许大家认为我说的第 4 点有点不着边际,通常情况下大家会认为架构师就是做技术的,人和你没关系,可是我认为最需要有工程师调配权的应该是架构师,他需要工程师帮他实现框架,他更能合理分配工程师资源。架构师带领一个技术团队更利于技术团队的发展,无论对工程师还是对项目本身。如果说业绩取决于管理者,团队影响力更多取决于架构师。

InfoQ:58 同城旗下的 APP 非常多,有 58 同城、58 配配、58 招才猫、58 车商通、58 帮帮、58 转转等,每个业务线是否独立,或者是否有交叉?如何针对不同的业务线,快速且准确地设计出不同的 APP 架构?

迟学奎: 两年前就只有 58 同城和 58 帮帮两个 App。最近两年业务线垂直 App 比较多,有 58 招才猫、58 车商通、58 转转等垂直的 App。58 配配是完全不同于现有业务的创新 App,是社交类的 App。58 帮帮是唯一的商家端 App,是多业务线的商家端,能满足企业招聘、二手车商、房产经纪人等的商家需要。架构设计为多业务团队并行开发的框架,求同存异,尽可能多地提供通用的组件和服务,业务线独有的个性化需求由各业务线完成。

目前演进为多业务团队并行开发平台,可自由定制需要的组件和服务,分分钟快速搭建起一个 App 的基础框架。58 配配、58 招才猫,58 车商通,以及一些即将推出的 App 都是快速构建起来的 App。58 配配,只要 20 天就完成 App 上线。

InfoQ:高并发大流量下移动架构如何设计?APP 端即时通信踩过哪些坑,有什么优化经验,如何提高稳定性?

迟学奎: 高并发大流量的架构设计主要是:

1. 要保证可用性。通常通过冗余来保证高可用。

2. 高性能。多线程并发,异步等技术,硬件上多服务器,甚至是集群。

3. 稳定性。代码的质量,QA 的测试,还有非常重要监控,第一时间发现问题,解决问题,尽量做到用户无感知。

即时通信是比较复杂的项目,由于是长链接的,网络连接就变得很重要,必须要有重连机制保证用户有网络的情况下自动、快速重新建立连接。我们采用的二进制数据传输,减少数据量,可是 App 端偶尔会出现数据包不完整,有时候多有时候少,无法完成数据校验导致数据包被抛弃,消息丢失。不知道这些数据是怎么来的,更不知道数据包是不是我们的数据,怀疑是拆包或粘包导致的,但 Server 反馈说不会出现这种情况。于是我们调整了方案:收到数据包后不启动解析线程做解析,直接丢到一个数据缓冲池,解析线程扫描缓冲池中的数据,扫描到完整包再去解析,结果问题解决了。

稳定性对于 App 是很重要的,我们基本上从 3 个方面来做。

  1. 代码健壮性。除了代码规范外,要有核心代码的设计和 Review。

  2. 自测+QA 测试。工程师要保证自测 case 全部通过,再交由 QA 集成测试。

  3. 监控平台+热修复。服务接口监控,网络监控,crash 监控,第一时间发现问题,当发现问题后及时通过热修复技术完成修复,尽量做到用户无感知。

InfoQ:移动端的产品迭代非常快速,58 同城的每个 APP 迭代周期是多长?如何才能满足产品快速迭代的需求?

迟学奎: 58 同城的每个 App 迭代周期差不多都是 1 个月一个大版本,小版本半个月。而框架会直接影响到迭代速度,比如,框架可扩展性。举个例子,上一个版本需求是发一张图片,这个版本要改成发多张图片,那如果框架设计就考虑到了未来扩展能力的话,那只需要把 1 改成 N 就 ok 了,很容易完成迭代;相反,那可能需要改动框架,弄不好还会影响其他业务线,测试工作量也会加大,那小版本迭代就会变成大版本迭代了。

往往很多团队不是很重视技术框架,只要实现了需求就 ok,同样一个功能有 N 种实现方法,表面看框架也许不会给你本次需求带来大的益处,但是未来会直接影响到下一版或是下几版的版本迭代,甚至需要重构。

InfoQ:多年从事移动架构的工作,有什么感悟和经验可以和大家分享吗?

迟学奎: 是我个人的一点见解,希望和大家多交流。

  1. 架构经常是被很多人忽视的东西,包括管理者、产品人员、测试人员很少了解架构是什么,也很少关心架构能给他们带来什么,自然也就不愿意给你时间去针对需求设计一个合理架构。更多的是匆匆忙忙要求你在某个时间点完成开发。这也无可厚非,因为业绩压力嘛。所以做架构的同学经常没有归属感,表面上看 App 完成开发和你没有半毛钱关系,但实际上框架起到的作用是巨大的,如果说一个 App 是一部电影,那么架构师就是导演,而吸引眼球光鲜亮丽的是主演。

  2. 架构没有大小,并不是说很大很复杂的一个架构图才可以是架构,一个很小的需求,也可以有架构,架构不仅关注大的模块,也会关注细节。上面我举过一个发图片的例子。

  3. 抛开业务谈架构、谈技术是不合理的,任何技术架构都是解决业务需求的,在实践中不断打磨改进沉淀出架构。没有业务架构做什么呢?凭空想象一个架构没有任何意义。

  4. 架构没有好与坏,只有适合与不适合,再好的架构它不适合你的业务场景,对你来说这个架构一点意义都没有。

  5. 架构对团队的稳定是有利的,每个技术人都不希望进入一个没有架构的项目里,招进来人,一看代码,完全是堆代码的节奏,这个人很难留下来的,留下来对他的成长也没什么好处,和你一起堆代码吗?呵呵。

  6. 合理的架构让擅长的人做所擅长的的事。解耦是架构最大的作用,但不仅仅是简单的解耦,解耦带来的一个好处就是熟悉业务的人做业务相关的,业务无关的不用他们来做,提高整体效率。

InfoQ:感谢你接受我们的采访。期待你在 ArchSummit 全球架构师峰会上的分享。

语言 & 开发架构