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个方面来做。
代码健壮性。除了代码规范外，要有核心代码的设计和Review。
自测＋QA测试。工程师要保证自测case全部通过，再交由QA集成测试。
监控平台＋热修复。服务接口监控，网络监控，crash监控，第一时间发现问题，当发现问题后及时通过热修复技术完成修复，尽量做到用户无感知。
InfoQ：移动端的产品迭代非常快速，58同城的每个APP迭代周期是多长？如何才能满足产品快速迭代的需求？
迟学奎： 58同城的每个App迭代周期差不多都是1个月一个大版本，小版本半个月。而框架会直接影响到迭代速度，比如，框架可扩展性。举个例子，上一个版本需求是发一张图片，这个版本要改成发多张图片，那如果框架设计就考虑到了未来扩展能力的话，那只需要把1改成N就ok了，很容易完成迭代；相反，那可能需要改动框架，弄不好还会影响其他业务线，测试工作量也会加大，那小版本迭代就会变成大版本迭代了。
往往很多团队不是很重视技术框架，只要实现了需求就ok，同样一个功能有N种实现方法，表面看框架也许不会给你本次需求带来大的益处，但是未来会直接影响到下一版或是下几版的版本迭代，甚至需要重构。
InfoQ：多年从事移动架构的工作，有什么感悟和经验可以和大家分享吗？
迟学奎： 是我个人的一点见解，希望和大家多交流。
架构经常是被很多人忽视的东西，包括管理者、产品人员、测试人员很少了解架构是什么，也很少关心架构能给他们带来什么，自然也就不愿意给你时间去针对需求设计一个合理架构。更多的是匆匆忙忙要求你在某个时间点完成开发。这也无可厚非，因为业绩压力嘛。所以做架构的同学经常没有归属感，表面上看App完成开发和你没有半毛钱关系，但实际上框架起到的作用是巨大的，如果说一个App是一部电影，那么架构师就是导演，而吸引眼球光鲜亮丽的是主演。
架构没有大小，并不是说很大很复杂的一个架构图才可以是架构，一个很小的需求，也可以有架构，架构不仅关注大的模块，也会关注细节。上面我举过一个发图片的例子。
抛开业务谈架构、谈技术是不合理的，任何技术架构都是解决业务需求的，在实践中不断打磨改进沉淀出架构。没有业务架构做什么呢？凭空想象一个架构没有任何意义。
架构没有好与坏，只有适合与不适合，再好的架构它不适合你的业务场景，对你来说这个架构一点意义都没有。
架构对团队的稳定是有利的，每个技术人都不希望进入一个没有架构的项目里，招进来人，一看代码，完全是堆代码的节奏，这个人很难留下来的，留下来对他的成长也没什么好处，和你一起堆代码吗？呵呵。
合理的架构让擅长的人做所擅长的的事。解耦是架构最大的作用，但不仅仅是简单的解耦，解耦带来的一个好处就是熟悉业务的人做业务相关的，业务无关的不用他们来做，提高整体效率。
InfoQ：感谢你接受我们的采访。期待你在ArchSummit全球架构师峰会上的分享。