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

一个产品要么由多个业务组成，要么由一个业务的多个模块组成，要么是两者混合的。而 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 全球架构师峰会上的分享。