框架组件,究竟要不要自研?

一、问题的提出

询问框架组件,是否需要自研?

18年规划系统介绍58到家的技术体系,15年加盟58到家后,架构部正好也是负责范围的一部分,故谈一谈自己的想法,个人观点:

  • 如果公司业务不复杂,研发人数比较少,技术实力相对有限,一定不要自研框架组件
  • 如果公司业务复杂,研发人数比较多,技术能力能够胜任,建议自研部分框架组件

二、为什么早期不建议自研?

早期研发人数较少,公司也不确定能走多远,业务相对简单,业务以“快速迭代”为最高优先级,此时一般会选择“自己熟悉的技术”作为选型:

  • 研发语言:熟PHP选PHP,熟Java选Java
  • 数据库:熟MySQL选MySQL,熟SQL-server选SQL-server
  • 框架组件:熟Ruby on Rails选ROR,熟ThinkPHP选ThinkPHP,熟SSH选SSH

此时千万不要纠结选型,选自己熟悉的,业务以快速迭代为最优先,公司得先生存下来。

多说一句,此时对于技术合伙人的技术视野就有一定要求,如果早期方向不对,例如选择了IOE或者微软技术体系,等公司发展若干年,数据量并发量上涨很多倍,成本以及未来的技术应对恐怕会有麻烦。

58同城早期选型是微软技术体系,后来数据量增大,并发量增大,机器数据库越来越多,性能扛不住,成本也扛不住(你猜一个SQL-server的licence一年多少钱?),后来老崔带领大家转型开源阵营:

  • Windows -> Linux
  • SQL-server -> MySQL
  • C# -> Java

虽然短痛了1-2年,但长远来说,绝对是正确的决策。

如今,如果你再创业,选云,选LAMP或者SSH,八成不会走太大的弯路。

三、随着规模的扩大,为什么要控制技术栈?

随着业务越来越复杂,研发人数越来越多,如果每个leader都选择自己擅长的框架,就会出现这样的情况:

  • 站点框架,team A用着SSH,team B用着Spring+SpringMVC+Mybatis
  • 服务框架,team C用着REST,team D用着dubbo,team E用着thrift
  • 数据库访问,team X用着mybatis,team Y用着DAO,team Z用着jdbc

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

第一个观点:即使不自研,技术栈也请尽量统一。

四、统一了技术栈,为什么建议浅浅的封装一层?

统一了技术栈以后,如果不封装,redis官方Java客户端Jedis可能有这样一些接口:

String Memcache::get(String key) 
String Memcache::set(String key, Stringvalue)
String Memcache::del(String key)

浅浅的封装一层,会变成这样:

String 58DaojiaKV::get(String key) {
         String result = Memcache::get(key);
         return result;
}
String 58DaojiaKV::set(String key, Stringvalue) {
         String result = Memcache::set(key, value); 
         return result;
}
String 58DaojiaKV::del(String key) {
         String result = Memcache::del(key); 
         return result;
}

这有什么好处呢?

  • 对上游屏蔽底层实现的细节,调用方不用关注缓存是memcache还是redis,调用方只关注58DaojiaKV
  • 底层变化的时候,对上游透明,当memcache不能满足需求,要切换为redis时,所有调用方不需要大的变化,升级一个最新的58DaojiaKV即可,58DaojiaKV的接口不变,实现变为:
String 58DaojiaKV::get(String key) {
         String result = Jedis::get(key);
         return result;
}
String 58DaojiaKV::set(String key, Stringvalue) {
         String result = Jedis::set(key, value); 
         return result;
}
String 58DaojiaKV::del(String key) {
         String result = Jedis::del(key); 
         return result;
}
  • 统一实现一些通用的功能,就不需要每一个上游升级了,例如,要实现一个缓存访问时间统计的功能,所有调用方不需要大的变化,升级一个最新的58DaojiaKV即可:
String 58DaojiaKV::get(String key) {
         Long startTime = now();
         String result = Jedis::get(key); 
         Long endTime = now();
         reportKVTime(startTime- endTime);
         return result;
}
String 58DaojiaKV::set(String key, Stringvalue) {
         Long startTime = now();
         String result = Jedis::set(key, value); 
         Long endTime = now();
         reportKVTime(startTime- endTime);
         return result;
}
String 58DaojiaKV::del(String key) {
         Long startTime = now();
         String result = Jedis::del(key); 
         Long endTime = now();
         reportKVTime(startTime- endTime);
         return result;

}

同理,如果要实现统一的告警,调用链跟踪,SQL执行时间,也可以用类似的方法。

第二个观点:第三方库,不但要统一,还可以浅浅的封装一层,预留未来的扩展性。

五、随着规模的进一步扩大,为什么需要适当的造一些轮子?

业务进一步发展,研发团队进一步扩张,虽然使用了统一的技术栈,但不同研发团队的痛点是极其类似的:

  • 有站点,监控服务的可用性,处理时间监控需求
  • 有告警需求
  • 有自动化发布,自动化运维需求
  • 有服务治理,服务自动发现需求
  • 有调用链跟踪需求
  • 有SQL监控需求
  • 有系统层面数据收集与可视化展现的需求

此时,开源的框架可能满足不了需求了:

  • 开源框架/组件太重了,我们需要的可能只是一个轻量级的框架/组件
  • 开源框架/组件,只能满足我们的一部分需求
  • 不了解开源框架/组件的设计理念,要二次开发成本更高(维护dubboX的同学,维护数据库中间件Atlas的同学可以出来说两句)
  • 有些通用的需求是和业务紧密结合的,开源框架/组件可能满足不了

此时,如果技术实力具备,可以统一研发一些框架和组件,解决所有技术团队的通用痛点,满足所有技术团队的通用需求。

未来介绍监控平台、服务治理、调用链跟踪系统、数据收集中心的时候,大家能够更深刻的理解到“造一些轮子”的好处。

第三个观点:适当造一些轮子。

六、58到家自研的框架组件有哪些?

通用框架+服务

  • WEB框架,Daojia-Web-Framework,DWF
  • Service框架,Daojia-Service-Framework,DSF
  • 消息队列,Daojia-Msg-Queue,DMQ

基础组件

  • 缓存访问组件DMemcache,DJedis
  • 数据库访问组件DAO
  • 分库分表组件DShard

还有一些日志,消息的组件,这些组件的架构与细节,未来再和大家细聊。

七、总结

框架组件,是否需要自研?

初期建议:不自研,用熟悉的,业务快速迭代为优先,需要一定技术视野。

长远建议

  • 统一技术栈
  • 浅浅封装一层
  • 适当造轮子

原文发布于微信公众号 - 架构师之路(road5858)

原文发表时间:2018-01-18

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

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏Java技术栈

爱上 Java 的10 大理由,Python 弱爆了!

Java和JVM已经存在了很长一段时间了,基于这个事实,一些程序员开始将很多事情视为理所当然。今天我们就来说一说“Java之所以能够成为并将继续是软件项目领先平...

1304
来自专栏杨建荣的学习笔记

改和看别人的代码是一种什么感受

工作里面可能会沉淀下来很多的东西,比如文档,代码/脚本,或者图片,甚至你留下的趣事或者“案底”。 对于修改代码,我很多年前就体验过一次,是修改自己写的代码,记...

3918
来自专栏非著名程序员

微信团队的又一开源力作,让设计师和开发者更佳高效的使用 Sketch

最近国内大的互联网公司在开源的世界磨刀霍霍,一时间江湖上传言四起,大家要在开源的世界中华山论剑,看看哪家的互联网公司技术更加强大。我们大家作为IT江湖中的一份子...

2737
来自专栏SDNLAB

SDN实战团分享(二十五):博科SDN控制器BSC介绍

首先 BSC与 ODL 的本质一样,同样的内核软件,同样的架构。我们下面看这张图说明一下BSC控制器和ODL控制器的关系: ? 下面蓝色的部分就是ODL的实质,...

3537
来自专栏云端架构

【云端架构】程序员常用四十个小技巧

4、注释贵精不贵多。杜绝大姨妈般的“例注”。漫山遍野的碎碎念注释,实际就是背景噪音。

4499
来自专栏北京马哥教育

Linux 内核学习经验总结

学习内核,每个人都有自己的学习方法,仁者见仁智者见智。以下是我在学习过程中总结出来的东西,对自身来说,我认为比较有效率,拿出来跟大家交流一下。

6102
来自专栏牛客网

百度 提前批C++ 一面 二面 三面

【每日一语】当你厌恶你身边的人,你表达厌恶最好的方式不是和他们争吵,而是自己勤快点儿,加把劲离开他们。那样,他们就永远从你的生活中消失,和死了差不多。

2083
来自专栏码神联盟

高效编程所需要做的那点事

聊聊如果才能高效编程 计划(Plan) 所谓Plan,其实就是对应于编程中的设计阶段,当然,这里的Plan并不像设计那样重量级。它要求我们程序员在正式...

2809
来自专栏Java架构师进阶

Java程序员:从菜鸟码农到架构师六步走

在外人眼里,程序员这个职业总是被打上高薪、高大上的标签。可是鬼知道我们经历了什么,付出了多少。但是付出终会有收获的,IT这个行业,多数都是从程序员开始,小编也是...

1283
来自专栏大数据文摘

去IOE的另外一条路径:全内存数据库弯道超车

1988

扫码关注云+社区

领取腾讯云代金券