BT

如何利用碎片时间提升技术认知与能力? 点击获取答案

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

| 作者 陈兴璐 关注 0 他的粉丝 发布于 2016年7月1日. 估计阅读时间: 13 分钟 | QCon上海2018 关注大数据平台技术选型、搭建、系统迁移和优化的经验。

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

评价本文

专业度
风格

您好,朋友!

您需要 注册一个InfoQ账号 或者 才能进行评论。在您完成注册后还需要进行一些设置。

获得来自InfoQ的更多体验。

告诉我们您的想法

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我
社区评论

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

讨论

登陆InfoQ,与你最关心的话题互动。


找回密码....

Follow

关注你最喜爱的话题和作者

快速浏览网站内你所感兴趣话题的精选内容。

Like

内容自由定制

选择想要阅读的主题和喜爱的作者定制自己的新闻源。

Notifications

获取更新

设置通知机制以获取内容更新对您而言是否重要

BT