ITPub博客

快狗打车CTO沈剑:开源框架VS自研框架,企业该如何选择?

原创 数据架构 作者:胡孟依 时间:2018-09-29 09:50:42 0 删除 编辑

【导语】 快狗打车(原58速运),是以短途货运为切入点,实现基于用户位置下单、司机系统派单、在线支付及服务评价的全流程交易闭环的同城货运交易服务平台。为了解快狗最新的技术发展,本期名人堂专访嘉宾就是快狗打车CTO沈剑,他将和我们分享如何有效快速实现数据库架构设计的一致性最佳实践。

【嘉宾简介】

沈剑:互联网架构技术专家,“架构师之路”公众号作者。曾任百度高级工程师,58同城高级架构师,58同城技术委员会主席。15年调至58到家任高级总监,技术委员会主席,负责基础架构,技术平台,运维安全,信息系统等后端技术体系搭建。现任快狗打车任CTO,负责快狗打车技术体系的搭建。本质,技术人一枚。

好的架构不是设计出来的而是演进出来的


大多数企业在创建之初,架构并不是完整的,都是随着业务的发展和需求一步步演进而来的。


沈剑表示自己曾面试过 “纸面架构师”,面试的时候总是拿着同一套架构方案,往不同的业务或者同一个业务的不同阶段上生搬硬套,懂技术的面试官其实对这其中的套路心知肚明。架构是服务于业务的,旨在解决问题,不同的业务有不同的特点,应当用最合适的业务架构来解决不同的业务问题。业务的不同阶段,诉求与特点也不一样,不能期望用同一套架构方案来解决所有问题。


拿58同城和快狗打车举例,两者的业务特点不同,架构设计时考虑的点也不一样。58同城的本质是一个信息平台,它的特点是用户多,数据量大,并发量大,架构设计需要重点考虑容量设计,如何保持好扩展性,承载海量的数据与并发。而快狗打车是一个在线打车业务平台,它的特点是闭环,在下单、推送、抢单、中单、完单、支付这整个流程中都是封闭的,对架构的稳定性要求更高。


如果58同城发布不了帖子了,不影响用户浏览帖子、搜索帖子,并不影响58同城的整体业务流程。但快狗打车由于是闭环订单系统,中间任何一个环节出现问题,这个订单业务就无法正常运行。


快狗打车至今经历了四年的发展,对比当下的架构与四年前的架构,是很大区别的。初期公司业务的发展有很大的局限性和未知性,这就要求架构必须能够“快速迭代”,能够跟上的业务的需求变更。但随着时间推移,数据量日益增加,并发量也越来越高,之前架构的功能无法满足现阶段业务的要求了,这就需要重塑架构和优化架构,这个过程就是架构随着业务的发展,而进行同步演进。


开源框架vs 自研框架


开源技术在当下掀起了一阵风潮,有不少企业在框架选择方面也开始走向开源,而面临开源和自研框架企业该如何选择呢?其实可以总结为以下两点:


1、如果公司业务不复杂,研发人数比较少,技术实力相对有限,一定不要自研框架组件;

2、如果公司业务复杂,研发人数比较多,技术能力能够胜任,建议自研部分框架组件;


早期企业投入研发的人数较少,公司的未来发展方向也不是很确定,业务相对简单,架构应以快速迭代为目标,这时企业应该以“自己熟悉的技术”作为选型,在研发语言方面,熟悉哪款编程语言便选择哪款语言;在框架组件方面:熟悉Ruby on Rails选ROR,熟悉ThinkPHP选ThinkPHP……等等,这个时期不需要纠结选型,而是选择公司擅长的熟悉的,以能进行快速迭代为优先,以能够及时跟上业务的发展为目标,让公司先生存下来。


而随着业务需求变化,研发人员的增加,如果每个leader都选择自己擅长的框架,就会出现这样的情况:


(1)站点框架,team A用着SSH,team B用着其他;

(2)服务框架,team C用着REST,team D用着dubbo,team E用着thrift

(3)数据库访问,team X用着mybatis,team Y用着DAO,team Z用着jdbc

(4)…


对于整体架构而言,跨部门的调用越来越麻烦,重复造的轮子越来越多,技术效率逐步降低,研发、测试和后期运维成本都越来越高。

此时,可以适当的造一些轮子,来解决各个研发团队的通用痛点:


(1)有站点,监控服务的可用性,处理时间监控需求;

(2)有告警需求;

(3)有自动化发布,自动化运维需求;

(4)有服务治理,服务自动发现需求;

(5)有调用链跟踪需求

(6)有SQL监控需求

(7)有系统层面数据收集与可视化展现的需求;


此时开源的框架可能满足不了业务发展的复杂化需求,如果研发技术实力具备,可以统一研发一些框架和组件,解决所有技术团队的通用痛点,满足所有技术团队的通用需求。


数据库架构中一致性最佳实践


在企业中,寻求发展必然就会产生变化,业务会越来越复杂,数据量和并发量会越来越大,所以数据库往往最先成为系统的瓶颈。而要解决数据库的瓶颈问题,最常用的优化手段是:主从同步,读写分离;增加缓存;数据冗余,反范式设计;分库存储更大量的数据等等。


但使用了上述优化手段之后,会带来新的问题:


(1)主从的延时,容易导致数据不一致;

(2)数据库与缓存,也容易出现数据不一致;

(3)冗余多份的数据,也可能出现数据不一致;

(4)分库之后,多库无法保证一致性;


这些都是在架构演进过程中很常见的的问题,也是大家在进行架构设计过程会遇到的问题,而这些问题该如何解决呢?请继续看下去!


由 IT168 旗下 ITPUB 企业社区平台主办的第十届中国系统架构师大会(SACC2018)。2018 年 10 月 18 日,核心业务系统架构设计专场,快来享受技术人的盛宴。本次数据库架构专场会有:


(1)快狗打车的架构师,会有一致性的专题演讲

(2)腾讯的架构师,会有NoSQL方面的分享

(3)瓜子的架构师,会有业务系统数据库架构设计的分享

(4)最重磅的,数据库大神,阿里的何登成老师,会分享阿里自研的X-DB的架构设计

(5)…


这些话题,能够让大家了解到,典型业务数据库架构如何设计,如何进行数据库与NoSQL的设计折衷,如何解决数据库架构设计中遇到的典型问题,也能够了解到数据库内核。


更多的细节,欢迎来SACC,数据架构设计专场进行面对面的交流!本专场日程如下,精彩议题持续更新中!

抢票入口: http://sacc.it168.com/goupiao.html 

   undefined

▲长按识别二维码或点击阅读原文 立即购票

大会官网: http://sacc.it168.com

来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/31547542/viewspace-2215217/,如需转载,请注明出处,否则将追究法律责任。

请登录后发表评论 登录
全部评论
公众号

注册时间:2018-07-26

  • 博文量
    29
  • 访问量
    37900