框架组件，究竟要不要自研？

会员服务 ·

框架组件，究竟要不要自研？

2018 年 1 月 18 日 架构师之路 58沈剑

一、问题的提出

询问框架组件，是否需要自研？

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;

}