摩拜物联网架构演进之路|数据与架构齐驱,看摩拜创造奇迹

编辑手记

最近召开的首席技术官领袖峰会上,互联网不同行业顶尖技术领导者齐聚一堂,充分交流与碰撞最前沿的技术思想和实践,探讨技术创造商业价值的途径,推动商业变革与创新。会上有很多有价值的观点和实践经验,感谢iTechPlus的授权,我们在此将一些经典的内容重新编辑整理,分享给各位。希望对大家有帮助和借鉴意义。

今天我们拣选的是来自摩拜的技术副总裁张屹凌的分享。主题围绕摩拜的架构演进展开。

作者介绍

张屹凌 摩拜技术副总裁

历任微软、Google、房多多技术负责人,专注平台研发,数据挖掘10年

以下是分享的内容及解读:

什么是架构?

在Wikipedia上对架构的定义为The process and the product of planning,designing,and constructing structures.也就是规划、设计及构建的过程和产物。

架构有很多种,包括研发架构,团队架构各种,今天分享的主题主要围绕技术架构展开,具体来讲,是围绕摩拜的系统架构,一起探讨软件技术的演进和发展。

摩拜创建的时间并不久,不像许多已经过了早期的大公司。摩拜在过去一年的增长和发展非常快,一方面表现为用户数量的增加,已达到最初的500倍,团另一方面则表现为团队的增长,目前的团队规模也是以前的十倍。在这样的增速下,为了保持用户环境的稳定,提高服务的质量,摩拜的架构经历了几代的演进,也做了很多的功能和性能的优化。

在整个系统架构演进的过程中,我们本着进中求稳的理念,从两个方面不断优化改进:一方面是系统的速度和能力,另一方面是系统的稳定性和性能。两个方面相辅相成,互相促进,既从工具和架构层面不断创新,也结合流程规范不断优化。

“摩拜的系统架构的演进可以分为四个阶段”

第一阶段野蛮生长

我们去年8月份的时候开启了这个项目,项目开始得很顺利,我们用了一夜的时间上线了一套数据库,也没有测试,但上线后非常顺利没有出什么问题。跟CEO聊的时候,他谈起这件事情表现得很兴奋。

当时的系统架构组成为:LB+NGINX+Tomcat+Dubbo+DB。车辆业务端垂直切分,使用Monolith First算法,扩展能力有限,而数据库是单实例的。

但不久,在我们第二次聊天的中途,可能是因为车辆需求的增加, 服务器突然因为遭遇bug就宕机了,当时还是很严重了,整个系统都崩溃了,但在我们的努力下,最终把系统的bug修复了。

在当时,系统主要表现出三大特点:快、糙、猛。即简单快,随时发布,快速落地,多面手。

同时存在以下问题:从业务上来说,不能对各种用户需求和行为作出合理响应,功能上尚不完善。而性能上,也是常常捉襟见肘,在很多个方面遇到过性能瓶颈,只能在尝试中去改进,很多时候没有办法直接定位问题的根源。这些问题,跟我们上线之前的准备工作不充分有很大的关系。

我们团队是非常扁平的,这个扁平意思不只是说一个人管多少人,而是一个人既做研发又负责一些iot又做运维上线还要做测试。面对系统的多重问题,就对我们的技术人员提出了新的要求。

我们希望能够通过监控尽早发现问题,避免线上的误操作和效率问题,同时要不断增强系统的IOT容错能力。

第二阶段基础性能

从八月份到12月,用户增长很快,每月达到2X的速度。随着规模的扩大,系统在功能上逐渐完善,我们也更重视系统的性能问题。

于是我们开始设计第二代也就是V1的系统架构。V1的主要改进目标针对V0的问题做修复,并提高稳定性和基础性能。

从以下四个方面,我们可以看到系统的改进:

第三阶段性能优化

很快,业务的增长速度达到了3X每月,性能问题日益凸显。由于没有做很好的流量管控,整个服务是一套,如果这个加了一百个服务器以后,后面系统连接数就很多,很可能就爆掉,这时候再加机器也没用了。

于是我们设计了第三代架构 V2

我们把架构做成两层,先去Dubbo化,再服务拆分,拆完了以后我们发现整个监控也要简化,性能测试大大简化,发布影响也大大缩小了,之后是数据库的拆分,我们当时拆一个核心的库表,拆了一千多个库,再做的过程中发现不仅是拆的事情,而是把所有的业务都梳理一遍,拆一个库表一个月,我们后来就不坚持做这个策略了,我们就先拆地域,再分片,这个也是和我们业务有关系的。

4月份做了一个周年的活动,那天基本达到了一个峰值,也被行业内攻击了一下,之后基本就开挂了,整个服务没有非常明显的宕机。

从以下四个方面,我们也实实在在看到系统在不断完善和优化:

对物联网,我们更多是做一些链路的分析,当时也是说性能问题很多是由用户的反馈过来的,我们每次报过来就让一个人查和分析链路是什么,这个事情非常重,当时稍微做了一些链路分析的工作,就把核心链路做了分析,就是开关锁的分析。

第四阶段并行迭代能力

现在又到了第四个阶段,这个时候我们的系统比较稳定了,但是我们性能稳定了,但是还是会宕机,宕机的原因很多,很多是因为业务复杂度导致的,业务复杂度是因为需求变多了,很多事情想做,这个架构必须确保很多人同时开包的时候,大家可以很稳定的合作,很稳定的上线,而不是说今天上线明天就回滚。

我们一方面考虑团队增长,需要确保团队的能力和兴趣匹配,需要一个比较好的结构支持这个事情。

同时整个系统在做更好调优,不是那么简单了,要做一个并发的研发环境,做业务无关的数据库分片方案,还有系统化的IOT方案,国际化的架构方案,我们需要做一些系统化的设计。

我们分为几步走,一个是基础架构的东西,做了一个核心业务的拆分,拆分不只是微服务化,更多是需要把一些相关的系统整合到一块,对子系统的整理。

同时我们还做了一个中间件层的收口,把一些底层依赖收起来。第三是数据库分片,IOT的核心功能,设备管理能力,请求链路分析,开关锁的统计分析,我们还有一个OTA的能力升级,从性能到能力。同时我们做了国际化设计,这是一个高频率发布的事情,有一套适合摩拜的代码管理的流程。

到了第三版,功能对比如下,这个迭代的过程,一步一步到今天这个状态,对我们来说,最重要的就是MoveFast,尽量用工具来提高这些效率。

原文发布于微信公众号 - 数据和云(OraNews)

原文发表时间:2017-10-13

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏Keegan小钢

小钢的架构思考:架构规划

上一篇简单聊了下什么是架构,还将架构划分为三个阶段:规划阶段、设计阶段和构建阶段,构建阶段其实也是架构实现的阶段。其实,三个阶段的界限并不明显,而占比最多的是设...

856
来自专栏ThoughtWorks

TW洞见 | 微服务—大企业是如何在实践微服务中成长的

文章作者来自ThoughtWorks:Imran Khan,译者来自ThoughtWorks:贺思聪。图片来自ThoughtWorks。 本文版权归【Thoug...

2607
来自专栏云计算D1net

关于SaaS和数据恢复的6大谬误

基于云计算的各种应用已经在全球范围内成为了企业业务及其运营的关键。但是作为SaaS(软件即服务)解决方案的领导者,Office 365、Box、G Suite(...

2655
来自专栏区块链大本营

BTA | 周政军:区块链中侧链和分片解决不了的扩容问题,交给DAG吧!

3307
来自专栏重庆的技术分享区

RIoT控制:了解和管理风险以及物联网

原文地址:https://internetofthingsagenda.techtarget.com/feature/RIoT-Control-Understa...

2975
来自专栏区块链学习

“区块链”说白了就是缓慢、昂贵的数据库

作者:Jimmy Song是区块链资本有限公司(Blockchain Capital LLC)的风投合伙人,向优秀程序员传授比特币和区块链技术,曾在不同的公司担...

47113
来自专栏BestSDK

区块链、机器学,2018有关云的5大预言

云2.0成为主流 对于今天云中出现的所有令人难以置信的创新,我们所做的绝大多数东西仍然是基本的计算和存储。是的,在创建第一类虚拟机管理程序后逾16年,超过85%...

33610
来自专栏云计算D1net

如何选择最佳的托管服务供应商

选择一个企业级云管理服务供应商并非易事,由于市场不断增长,产品已经变得越来越复杂而详细,其后果是也是很明显的。如果企业要将数据中心的应用程序、计算和数据迁移到云...

2907
来自专栏CDA数据分析师

译文|暗数据:企业的潜在威胁!

近年来有几个趋势对企业的影响就像大数据那般显著。各类规模和形态的公司在近几年都陆陆续续以极大的热情步入大数据时代,因为他们都意识到了大数据对他们的公司会有怎样的...

1866
来自专栏区块链大本营

用百万笔每秒,表示区块链性能?错!

1323

扫描关注云+社区