转载

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

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

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

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

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

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

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

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

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

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

关于架构

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

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

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

关于架构师

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

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

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大会上看到哪些内容？

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