框架组件，究竟要不要自研？究竟要不要建设自研技术体系。
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)redis
String Memcache::set(String key, String value)数据库
String Memcache::del(String key)缓存
String 58DaojiaKV::get(String key) {微信
String result = Memcache::get(key);mybatis
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一年多少钱？