问大型项目的关键因素有哪些？

15年加盟到家后，框架/组件/基础服务/技术平台，正好也是自己负责范围的一部分，开源还是自研，谈一谈自己的想法。

其一，早期不建议自研。

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

（1）研发语言：熟PHP选PHP，熟Java选Java；

（2）数据库：熟MySQL选MySQL，熟SQL-server选SQL-server；

（3）框架组件：熟Ruby on Rails选ROR，熟ThinkPHP选ThinkPHP，熟Spring boot才选；

（4）…

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

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

58早期选型是微软技术体系，后来数据量增大，并发量增大，机器数据库越来越多，性能扛不住，成本也扛不住，后来CTO带领大家转型开源阵营，虽然阵痛了1-2年，但长远来说，绝对是正确的决策。

如今，如果你再创业，选云，选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；

（4）…

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

即使不自研，技术栈也请尽量统一。

其三，统一了技术栈，建议浅浅的封装一层。

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

String Memcache::get(String key)

String Memcache::set(String key, String value)

String Memcache::del(String key)

浅浅的封装一层，会变成这样：

String DaojiaKV::get(String key) {

         String result = Memcache::get(key);

         return result;

}

String DaojiaKV::set(String key, String value) {

         String result = Memcache::set(key, value);

         return result;

}

String DaojiaKV::del(String key) {

         String result = Memcache::del(key);

         return result;

}

这有什么好处呢？

（1）对上游屏蔽底层实现的细节，调用方不用关注缓存是memcache还是redis，调用方只关注DaojiaKV；

（2）底层变化的时候，对上游透明，当memcache不能满足需求，要切换为redis时，所有调用方不需要大的变化，升级一个最新的DaojiaKV即可，DaojiaKV的接口不变，实现变为：

String DaojiaKV::get(String key) {

         String result = Jedis::get(key);

         return result;

}

String DaojiaKV::set(String key, String value) {

         String result = Jedis::set(key, value);

         return result;

}

String DaojiaKV::del(String key) {

         String result = Jedis::del(key);

         return result;

}

（3）统一实现一些通用的功能，就不需要每一个上游升级了，例如，要实现一个缓存访问时间统计的功能，所有调用方不需要大的变化，升级一个最新的DaojiaKV即可：

String DaojiaKV::get(String key) {

         Long startTime = now();

         String result = Jedis::get(key);

         Long endTime = now();

         reportKVTime(startTime- endTime);

         return result;

}

String DaojiaKV::set(String key, String value) {

         Long startTime = now();

         String result = Jedis::set(key, value);

         Long endTime = now();

         reportKVTime(startTime- endTime);

         return result;

}

String DaojiaKV::del(String key) {

         Long startTime = now();

         String result = Jedis::del(key);

         Long endTime = now();

         reportKVTime(startTime- endTime);

         return result;

}

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

其四，随着规模的进一步扩大，需要适当的造一些轮子。

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

（1）有站点，监控服务的可用性，处理时间监控需求；

（2）有告警需求；

（3）有自动化发布，自动化运维需求；

（4）有服务治理，服务自动发现需求；

（5）有调用链跟踪需求；

（6）有SQL监控需求；

（7）有系统层面数据收集与可视化展现的需求；

（8）…

此时，开源的框架可能满足不了需求了：

（1）开源框架/组件太重了，我们需要的可能只是一个轻量级的框架/组件；

（2）开源框架/组件，只能满足我们的一部分需求；

（3）不了解开源框架/组件的设计理念，要二次开发成本更高（维护dubboX的同学，维护数据库中间件Atlas的同学可以出来说两句）；

（4）有些通用的需求是和业务紧密结合的，开源框架/组件可能满足不了；

（5）…

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

总结：复用开源，还是造轮子自研？

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

长远建议：

（1）统一技术栈；

（2）浅浅封装一层；

（3）适当造轮子；

当然是先用开源的。

开源的，凡上比较流行的项目，都已经被很多人很多场景验证了。稳定的代码不是写出来的，是跑出来的。

对于流行的开源项目，如果你发现一个Bug，并修复了，建议给主游提PR，这样，相当于即为开源项目做了贡献，又相当于整个开源社区都在为你打工。

有一些开源代码，可能框架很好，但你要做很多改造才能适合你的业务，给上游提PR因为改造太大肯定无法合并。这时候，你有两个选择：1）Fork一个，自己成为开源主导者；2）闭源（注意在遵守开源协议的前提下）。

总之，站在巨人的肩膀上是没有错的。很多号称自研的系统其实也不是从头自研的，只不过有的不是站在肩上，而是站在巨人的腰上或腿上。

但如果你的项目无法跟开源协议兼容，那就只好自研了。如你所说自研“大型项目”而不用一点开源代码，那将是一个大型的工程。

就一句：站在巨人的肩膀上！

使用成熟的开源方案，能避开太多坑，减少大量不必要的损耗。

如果商业上允许，法务上合规，优秀的开源项目自然是最好的选择。我看到过太多各种理由的自建轮子，理由都是站不住脚的，可能是为了取悦自己让自己觉得搞出一个轮子有成就感，可能为晋升加点火药，可能说开源的项目扩展性不好不适合自己的业务（深究一下会发现可能他根本没仔细研究清楚）。