框架组件,究竟要不要自研?究竟要不要建设自研技术体系。15年加盟58到家后,框架/组件/基础服务/技术平台,正好也是自己负责范围的一部分,故谈一谈自己的想法。早期研发人数较少,公司也不确定能走多远,业务相对简单,业务以“快速迭代”为最高优先级,此时一般会选择“自己熟悉的技术”作为选型:(1)研发语言:熟PHP选PHP,熟Java选Java(2)数据库:熟MySQL选MySQL,熟SQL-server选SQL-server(3)框架组件:熟Ruby on Rails选ROR,熟ThinkPHP选ThinkPHP,熟Spring boot才选此时千万不要纠结选型,选自己熟悉的,业务以快速迭代为最优先,公司得先生存下来。多说一句,此时对于技术合伙人的技术视野就有一定要求,如果早期方向不对,等公司发展若干年,数据量并发量上涨很多倍,成本以及未来的技术应对恐怕会有麻烦。58同城早期选型是微软技术体系,后来数据量增大,并发量增大,机器数据库越来越多,性能扛不住,成本也扛不住(你猜一个SQL-server的licence一年多少钱?),后来CTO带领大家转型开源阵营,虽然阵痛了1-2年,但长远来说,绝对是正确的决策。如今,如果你再创业,选云,选LAMP或者Spring,八成不会走太大的弯路。随着业务越来越复杂,研发人数越来越多,如果每个leader都选择自己擅长的框架,就会出现这样的情况:(1)站点框架,team A用着SSH,team B用着Spring+SpringMVC+Mybatis;(2)服务框架,team C用着REST,team D用着dubbo,team E用着thrift;(3)数据库访问,team X用着mybatis,team Y用着DAO,team Z用着jdbc;对于整体而言,跨部门的调用越来越麻烦,重复造的轮子越来越多,技术效率会逐步降低,研发+测试+运维成本都越来越高。统一了技术栈以后,如果不封装,redis官方Java客户端Jedis可能有这样一些接口:String Memcache::get(String key)
String Memcache::set(String key, String value)
String Memcache::del(String key)
String 58DaojiaKV::get(String key) {
String result = Memcache::get(key);
return result;
}
String 58DaojiaKV::set(String key, String value) {
String result = Memcache::set(key, value);
return result;
}
String 58DaojiaKV::del(String key) {
String result = Memcache::del(key);
return result;
}
(1)对上游屏蔽底层实现的细节,调用方不用关注缓存是memcache还是redis,调用方只关注58DaojiaKV;(2)底层变化的时候,对上游透明,当memcache不能满足需求,要切换为redis时,所有调用方不需要大的变化,升级一个最新的58DaojiaKV即可,58DaojiaKV的接口不变,实现变为:String 58DaojiaKV::get(String key) {
String result = Jedis::get(key);
return result;
}
String 58DaojiaKV::set(String key, String value) {
String result = Jedis::set(key, value);
return result;
}
String 58DaojiaKV::del(String key) {
String result = Jedis::del(key);
return result;
}
(3)统一实现一些通用的功能,就不需要每一个上游升级了,例如,要实现一个缓存访问时间统计的功能,所有调用方不需要大的变化,升级一个最新的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, String value) {
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执行时间,也可以用类似的方法。第二个观点:第三方库,不但要统一,还可以浅浅的封装一层,预留未来的扩展性。随着规模的进一步扩大,为什么需要适当的造一些轮子?业务进一步发展,研发团队进一步扩张,虽然使用了统一的技术栈,但不同研发团队的痛点是极其类似的:(1)有站点,监控服务的可用性,处理时间监控需求;(1)开源框架/组件太重了,我们需要的可能只是一个轻量级的框架/组件;(3)不了解开源框架/组件的设计理念,要二次开发成本更高(维护dubboX的同学,维护数据库中间件Atlas的同学可以出来说两句);(4)有些通用的需求是和业务紧密结合的,开源框架/组件可能满足不了;此时,如果技术实力具备,可以统一研发一些框架和组件,解决所有技术团队的通用痛点,满足所有技术团队的通用需求。初期建议:不自研,用熟悉的,业务快速迭代为优先,需要一定技术视野。(1)你猜一个SQL-server的licence一年多少钱?