中小企业的研发团队是选择自研、用开源，还是拥抱云原生和SaaS服务？｜干货分享

研发团队的技术演化，很长程度上影响着企业创新发展的速度与力度，尤其是对于中小企业的研发团队来说，从自研、用开源，到拥抱云原生和SaaS服务，每个阶段往往有着不同的需求。

如何正确利用第三方提供的中间件和支撑系统、乃至核心的应用技术架构和运维能力为中小企业研发团队提质、降本、增效，为企业创造源源不断的核心价值，是很多人十分关注的议题。

7月13日，杭州云片网络科技有限公司联合创始人、CTO吴佳钊受白鲸出海邀请来到白鲸出海技术栈直播间，结合云片技术团队的实际案例，为大家分享了中小研发团队技术选型以及有效利用自研和第三方技术能力赋能团队的实战经验，以下为分享实录：

---

我个人曾在阿里巴巴淘宝网做过几年的技术研发，后来和几个合伙人出来创业，一干就是10年，这10年来我们的研发团队一直维持在中小规模，期间的技术演化也踩过了不少坑，今天和大家来聊一聊一个中小规模的研发团队，在技术上选型是如何演化的以及踩过那些坑，希望对大家有一些帮助，少走一些我们走过的坑。

我们总体的研发的技术栈基本都是基于开源的产品来做的，我们知道开源产品很流行，各大云厂商也有对应的服务，有些系统是要自研的，还有一些第三方的收费服务，那么作为一个中小规模是技术团队，对一些产品的的选则该如何决策，我下面会结合我们公司这么多年走过的路（有很多是弯路啊），跟大家做一下分享。

先大致说一下背景：我们云片团队的早期研发成员都是来自与大厂的研发背景（有阿里的、有腾讯的），是国内最早把云通讯能力作为PaaS服务开放的团队之一。大概在12/13年左右，那个时候国内的云厂商还没现在这么强大和全面，大多数还是在超卖虚拟机服务为主，配套的其他中间件类的服务比较少。所以我们一开始选择的路线是基于开源产品的二次开发，来发展我们自己的底层技术栈。首先是开发语言，我们几个创始人都在阿里出来的，对Java比较熟，同时Java开发人员也比较多，整个的技术生态也比较全，所以虽然Java越来越繁重，但我们依然选择Java语言，而不是一上来就用很新奇的语言，这种可能懂的人写起来很爽，但是当你团队要扩大的时候，发现相关的人才非常少也是很头疼的。这里也会涉及到后面我们有些中间件的采纳、自研系统的更新，都会有一定的影响。选语言一方面要选团队擅长的，另一方面要选生态健全的，不仅仅是软件库多不多，还要看相关人才多不多。

我们做的是云通讯这个业务，在给客户交付层面，除了提供接口之外，还有很多技术上的要求，例如

1、接口的高可用性。不能用着用着就挂了，对客户来讲，接口挂了可能会影响他们用户转化率，从而影响他们的业务

2、接口的高并发性。那些年国内发展了很多的节日要搞促销，比如618、双十一双十二，在大促期间除了稳定性的要求就是能承接高峰时刻的高并发营销的量

3、此外由于是通讯类的业务，所有数据都要实时可查，至少保留6个月的数据。做个简单的计算，假如1天1千万条消息，1个月就有3亿条消息，6个月差不多18-20亿条消息，这些消息要经得住客户的实时查询。

所以，我们为了满足这些需求，主要选了以下几个核心的开源中间件加上一些我们自研的系统来构建我们的技术底座。

首先消息队列：消息队列的作用就是能让你接前端接一大堆的请求，后端慢慢排队处理，起到削峰填谷的作用。我们一开始选的是rabbitmq，因为那时候几类消息队列我们研究过，确定用rabbitmq纯粹是他的并发性能足够强。后来迁移到阿里的rocketmq，为什么呢？首先是rabbitmq在处理实时并发方面确实足够强，但是在处理队列排队堆积的时候，非常容易流控。一旦rabbitmq进入流控状态，业务基本是不可用的，写消息写不进去，读消息也很慢。后来刚好阿里开源了他们的metaq也就是后来的rocketmq，我们调研发现rocketmq理念和kafka有点类似，能堆积海量的消息（因为他的底层数据是顺序存储+游标的方式，堆积对读写性能都不影响），同时rocketmq也是Java写的，我们自己想做问题诊断和魔改对比rabbitmq使用的erlang来说方便太多，另外一个很重要的点阿里的这个产品团队的技术同学我们也熟，有问题可以找他们帮忙做诊断。

在Nosql数据库方面，对于文档存储，我们选择了mongodb，对于内存数据库我们选择了redis。mongodb是一个文档型的数据库，因为其灵活的schema能力，非常适合我们早期做开发迭代。但是由于mongodb的单数据库节点写性能比较差，我们当时自己开发了一套sharding的路由方案，提升了mongodb的并发写性能（当时是1.*版本，官方sharding的功能还没开发出来），同时支撑了几十亿条在线数据的查询。（由于业务的特殊性，我们消息记录的业务是写多读少的业务，所以没有引入类似elasticsearch 之类的搜索引擎做查询系统）。内存数据库方面我们早期也用的mencache，后来redis出来后发现其性能也不错，功能方面也强，后来就切换到redis了。在高并发的业务中&#x