【SDCC讲师专访】架构师王小雪:解析快的打车的高可用架构

CSDN年度技术盛宴 “SDCC 2015中国软件开发者嘉年华”将于2015年11月19-21日在北京召开。CSDN软件研发频道将采访一些与会讲师,谈谈他们将在会上分享的内容。

本期我们采访的讲师是来自快的打车架构师王小雪,他在阿里巴巴工作了4年。从无到有组建了快的打车基础服务团队,主持研发、引进了众多基础框架和服务,推进快的架构升级,从稳定性、可用性、性能、安全、监控多方面体系化的建设了快的高可用架构。对高并发分布式系统架构、实时数据处理、网络通信和Java中间件有比较深厚的经验积累。

快的打车

王小雪

CSDN:请简单介绍下您和目前的工作,以及关注的领域、技术积累。

王小雪:我毕业后在深圳工作了4年,然后在阿里巴巴工作了4年,2014年年初到快的打车工作,在快的基础研发部门负责基础服务和中间件的工作,例如分布式消息、服务、无线开放平台、数据平台等,参与了实时计算平台、监控、安全、数据架构方面的建设,还有其他方面的事情,主持了快的多个大型营销活动的技术架构。

快的和滴滴合并后,按照集团的分工,最近一段时间,原快的基础研发部门十几个人全部转换了工作方向,基础研发部门后面的工作重心是集团的大数据架构、在线数据实时处理和机器学习。这对我们来说是一个新的挑战,所以目前我们的工作重心和学习方向就是在这一方面了。

关于关注的领域,当前我比较关注实时计算、机器学习、容器与虚拟化这三个大方向,也算是这个行业未来的热门和趋势吧。

关于技术的积累,我在阿里巴巴工作之前主要是负责企业系统的,虽然没有什么太大的流量和性能挑战,但是对于需求分析、产品思维、扩展性设计方面的要求还是有些要求的。在阿里巴巴我先后经历了搜索、无线、大流量Web系统等方面的工作,自己也比较喜欢学习和思考吧,对阿里的很多中间件源码都深入的研究过,在高并发大流量分布式系统架构、Java中间件(例如分布式RPC、消息、通信、容器、模板引擎等)、实时/流式计算和存储等方面有些积累,对Storm和HBase有过比较深入的研究。

2. 您对架构是怎样的理解?以及您对于架构师是如何定义的?

王小雪:架构和架构师我分开来说:

  • 关于架构

其实我很少跟别人谈论架构和架构师应该怎么做,因为这个话题比较容易引起口水战,但你问到这个问题我就说下我的拙见吧。

我想很多人对架构这两个的定义是比较模糊的,这里我只说下我的个人看法,没有一种架构能解决所有问题,但大的指导原则总是在的,我认为的架构要点很朴素,事实上每个展开是一个很大的话题:

  1. 可用性:这是最重要的,系统不可用什么都是浮云。这里要考虑的点很多,例如单点、性能瓶颈、可能的风险、快速发现故障、快速定位问题原因等
  2. 扩展性:基于高度的复用抽象,能够快速灵活的满足业务需求
  3. 伸缩性:系统服务能力是否可以随着加机器得到线性的提升
  4. 安全性:不给外部钻空子的机会
  5. 技术栈:在一个公司里,过多的语言选型或者同一个领域过多的架构选型,不是一件好事,除非是的确有必要,否则会花巨大的成本在内部系统整合上,因为语言不一样,很多东西很难复用,也很难集中力量对某个语言生态有深度的掌握,这是没有必要的。不是说架构师不应该多学习几门编程语言,而是要注意公司内部多语言开发的成本与内耗,目前快的打车系统以java为主,也在用python、golang、c,但基本都是工具的开发。
  • 关于架构师

以下是我认为架构师在设计时应该秉承的一些原则吧。

  1. 业务为王:技术只是手段,业务才是根本,这句话可能对技术人有些打击,但这是事实。不能为了玩技术而技术,要解决实际的问题,直接或间接的产生技术价值。
  2. 发散思考:架构不是仅解决问题就行。无论大小或简单复杂,有些点是必须要考虑的:例如单点、性能瓶颈、可能的风险、快速发现故障、快速定位问题原因、快速响应业务需求。
  3. 适度设计:架构是不断迭优化的。特别是在互联网这个行业,充满了很多机遇,也充满了很多不确定性,业务经常需要快速试错,发展速度也相当快。不能想当然的设计一套大而全的方案,期望解决所有的问题,而要随着业务的场景和发展,秉承一些基本的设计原则同时,解决最重要的问题。

CSDN:你认为具备哪些素质才能称为是出色的架构师?

王小雪:出色的架构师 = 一个优秀的程序员+半个产品经理+半个项目经理。

对应的能力:扎实的技术,较好的产品思维,较好的沟通能力与管理能力。

CSDN:这几年快的,有哪些技术架构的节点性事件?能否就各阶段从稳定性、可用性、性能、安全、监控等多方面来阐述快的高可用架构。以及作为架构师,你的工作重点有哪些?

王小雪:你这是一句话问好几个问题啊,而且都挺复杂,我简单说下吧,更详细的在分享上会有。快的打车的技术大概分为3个阶段:基本功能可用、核心链路性能优化、体系化的架构设计。快的打车的技术架构从2014年4月份开始做体系化的设计。

  • 关于稳定性和可用性方面

我们将系统按照业务域做了拆分,实现了服务化的改造,以前快的系统全都在一个大工程里,核心功能和非核心功能相互影响,稳定性不是太好,服务化后各个业务系统都是独立的,可以分别开发、发布、扩容,系统的稳定性和开发效率得到非常大的提升。

我们在系统全局的容量规划上也做了很多事情,我们压测出线上系统的容量极限,通过监控记录各个量级下的系统指标,能够比较精确估算我们是否要扩容或者缩容,因此面对大型营销活动或者快速增长的业务量,我们可以做到提前规划系统的服务能力。

我们消除了所有的单点,仔细排查了各个节点的故障恢复能力,比如网络闪断重连后,这个节点或组建是否能正常工作,review每个应用的JVM配置并且有针对性的GC优化。

我们还在做数据层面做了很大的改造,分库分表、基于binlog的数据同步平台、基于HBase的实时数据中心。

  • 关于安全方面

大概的说一下。网络层面,我们通过阿里云盾防范DDos攻击。应用都做了基本的XSS、CSRF、SQL注入等防范。在无线请求接入方面,我们建设了无线网关,对访问者IP、用户ID都做了流量限制,对后端服务做了容量保护。我们所有内部系统的登录都是需要真实的员工手机验证的。我们建设了风控平台,打击作弊行为。

  • 关于监控方面

我们收集了全网日志,并且将请求链路上的日志通过标识串联起来,通过ElasticSearch实现实时索引和查询,极大的提高了故障定位的效率。

我们建设了自己的实时计算平台,在这个平台之上我们又建设了监控平台,我们能够分钟级别知道每个系统的运行情况和资源开销,知道当前时间的业务数据,比如当前这一分钟的乘客发单量、司机接单量、支付量等等。可以看到历史数据,可以观察选定时间段的曲线图。

这个过程我们整个基础研发团队做了非常多的努力,大家一起齐心协力做了很多事情,也取得了不错的成果。这里面我的主要工作是基础服务和中间件,因为做上层改造必须要有下层的可靠支持,例如NIO通信、文件存储、分布式协调服务、服务框架、分布式消息、配置中心、数据同步、无线网关等,推动这些基础服务在业务系统落地;另外也协同CTO与基础研发负责人一起制定公司的技术规划,参与其他基础研发工作的设计,参与一些应用架构的优化。

CSDN:可否请您简单介绍一下快的整体架构的一些架构特点?

王小雪:高频的地理位置计算;大量的TCP长连接通信;大量的数据存储;系统实时性要求很高,能够缓存的场景很少,必须快速定位故障;时刻要面临刷单、攻击等问题。

CSDN:快的成立已来,业务高速发展的同时,研发团队规模也是有了惊人的变化,作为从无到有的团队组建者,最大的挑战是什么?以及,现在您所负责的研发团队人员搭配是怎样的?

王小雪:最大的挑战倒不是解决系统问题,而是寻找合适的人才。

基础研发分为:中间件和基础服务,业务架构,数据架构,监控,运维。虽然做了很多事情,实际上快的基础研发团队人很少,整个基础研发团队到现在包括运维只有20个人,但是大部分人是去年年底和今年刚来的,这其中包括7个我们校招过来的应届生。去年最辛苦的时候只有10个人:基础研发总监,中间件和基础服务2个人,业务架构1个人,数据架构2个人(包括DBA),监控1个人,IT和运维一共3个人,我负责中间件和基础服务,监控原来也在我这里,后来我实在忙不过来就剥离出去了,我现在下面也只有5个人。去年的时候我们非常的辛苦,凌晨下班非常正常,经常通宵,大家虽然分工明确,但是互相帮忙互相鼓励,结下了非常深厚的兄弟情谊。

CSDN:如今,您又是如何安排自己的新技术学习、研发团队管理、编程、生活等时间的?

王小雪:我一直都在写代码,不是为了练手,就是实实在在的编码,做一些核心设计和review方案。简单说吧,白天编码和团队同学沟通,事实上也谈不上团队管理,大家都是非常靠谱和成熟的工程师,自驱性很强,我只是关注大家的工作和学习方向就行,当然也兼做一些后勤的工作:)比如给团队同学介绍女朋友啊;晚上学习自己感兴趣的东西;生活就在周末。这样的安排我自己觉得还行。

CSDN:您在本次SDCC 2015大会上想分享的话题是?

王小雪:快的打车架构实践。在快的从小到大的过程中,我们走过的路,我们踩过的坑,我们的笑,我们的哭,我愿意真诚的分享给大家,给所有在创业路上奋斗的同行。

CSDN:您最期待在SDCC 2015大会上看到哪些内容?

王小雪:容器和虚拟化;在线学习;创业公司的干货实践。

  • 架构师应该战斗在一线。不是要事无巨细的解决所有问题,而是要保持对业务的敏感度,否则居高堂之上坐而论道,你怎么能设计一个接地气的方案去解决问题呢?
  • 架构师应该理解业务。架构师是业务和技术的纽带,对业务充分了解才能解决业务痛点。
  • 架构师应该做好权衡。架构设计事实上也是一种平衡的艺术,没有固定的模式判定哪个方案是最优解,很多事情都具有两面性,利弊的取舍得看问题场景和业务的发展现状。

 

发表评论

:?: :razz: :sad: :evil: :!: :smile: :oops: :grin: :eek: :shock: :???: :cool: :lol: :mad: :twisted: :roll: :wink: :idea: :arrow: :neutral: :cry: :mrgreen:

目前评论:1   其中:访客  1   博主  0

  1. SmileSky 5

    已看,努力,成长