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

92 阅读 0 评论 61 点赞

我是靠谱客的博主火星上盼望，最近开发中收集的这篇文章主要介绍中小企业的研发团队是选择自研、用开源，还是拥抱云原生和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了。在高并发的业务中，我总结就是内存数据库和消息队列是大杀器，既能大大降低底层数据库的存储压力，又能提高系统的吞吐量能力。

在离线数据处理方面，我们开始是自建了一套Hive系统，用来做离线数据的运算。我记得我在阿里的时候翻译过hive的环境搭建的文章，当时基本也算是当时国内比较早接触hive技术的了，当时放在我的个人博客上，阅读和分享数还是挺高的。Hive我们主要用来处理离线的大数据处理，比如统计客户的日发送量、月发送量、发送的人群区域等等。没有使用太高大上的UI界面，自己写脚本，定时触发任务。

而在实时数据处理方面，我们选择了jstorm，他是阿里巴巴基于twitter开源的 storm重新用Java语言重写的一个开源实时计算平台，当时是还没有flink那一套，用起来也还好，在发现性能上有瓶颈的时候，我们基本都是优化我们自己的统计分析程序。比如实时计算UV，从用内存、到用内存数据库的集合，再到用一些数学算法（放弃一定的精度，获得巨额的性能提升）等等。

在CICD系统方面，我们采取了自研的方式。在有这套系统之前，我们都是登陆到服务器上去用脚本来做发布，有了系统之后，就是系统帮我们登陆到系统上去触发某个脚本，解决了发布效率的问题。包括了在早期迭代过程中会经常发现要回滚的问题，之前的脚本回滚由于人工操作，容易回滚错，而上了这套系统之后，就比较方便快捷了，每次发布的包我们都会备份和记录，回滚是直接把之前的包拿出来再发布，而不是代码方面做回滚。

由于我们内部有很多的管理系统，每个系统用户名密码虽然都是同一套，但是在多系统操作的时候还是挺麻烦，后来我们就自研了一套单点登陆系统。当然还有其他很多的开源软件我们都在用，比如订阅中心zookeeper、http服务器nginx等等，这里就不再多讲了。所以大家看，我们早期的路线，基本都是采取了开源产品自己搭建或者加上一些我们自己研发的系统，来打造我们整个的技术底座的。

这些经历，说明我们团队研发实力还可以，在系统不多的时候，支撑我们早期2-3年的业务发展是没问题的。

但是，凡是都有但是，随着越来越多的系统孵化出来，我们开始面对各种各样的挑战。

首先，系统越来越多，我们开发搞不过来，就招了专职的运维工程师（原来都是后端兼的），但运维工程师也耗不过系统越来越多，特别是每个系统没有统一的标准，也没有很好的梳理系统间的关系链路，会导致运维上压力非常大。有时候系统挂了，运维去看可能一时搞不定，开发看一看就定位到并解决了，还是没有释放开发的压力。

然后是稳定性挑战也开始显现。我们知道，很多系统早期都是单体状态的，你要维护系统的稳定只要维护一套就行，但随着系统的越来越松散，出问题的概率越来越高，因为系统变多了。

还有呢，就是安全合规上的挑战。比如tomcat安全漏洞，log4j漏洞等等，开源、自研系统中的安全漏洞不断被爆出，处理耗时耗力。这里的漏洞库如果是我们自研的代码中引用到的库到时好解决，更头疼是用了开源中间件里依赖了这些有漏洞的库，排查和改造的成本都不小。

接下来，我们从我们自身的技术迭代过程，给大家分享一下，那些年我们踩过的自研和自建开源的坑。

还是从上面的案例讲起吧！

我们第一个踩坑的是应用发布与CI/CD系统

我们第一个发布系统是2015年做好的，在那之前的几年我们都是靠脚本，工程师都受不了每次都要弄脚本，万一敲错了还容易出问题（这个我们还真出现过，发布脚本的时候，发错了应用，结果浪费一堆时间去排查）。所以决心自己研发一套发布平台，美其名曰万一做的好了还能商业化（相信很多工程师在搞一些内部的平台的时候，还有有这么一个心态的），当时我们开发语言依然还是Java，所以顺理成章用了Spring MVC来开发，当然现在看，spring mvc已经有点老旧了，此外遇到比较多问题的发布界面不流畅，经常会发布失败或者整个系统卡死。这个系统很简单，就是选择业务线，再选择应用，然后选择环境（测试、预发、线上），再进行发布。权限控制只给到应用层面，并没有控制环境的发布权限。也就是你是应用owner，你想发哪个环境就发哪个环境，还是比较简单粗暴的。针对一些无状态高可用的应用，我们也支持批量发布，批量回滚等等。

后来由于这个系统的bug和问题确实非常多，我们19年的时候，又开发了一套新的系统。这套和版本控制平台（比如gitlab）能更好的结合，同时权限控制方面做的比较好（例如上线的操作要让测试工程师来做，而不是开发工程师，也就是我们所有改动要上线是需要测试工程师同意的）。这套平台采用了当时流行的微服务架构开发，具备了初级的cmdb能力，完善了发布流程审批、具备权限管理、代码安全扫描、运行包版本管理能力。当然也引入了一些新问题，例如对老的应用不兼容，需要应用层面做好相关的改造才能使用新系统的持续集成能力，对应用方来说，是存在迁移成本的。此外，因为人员变动，这两个系统都难以维护，已知的使用问题得不到改进，出了问题只能运维手工做一些临时处理。

20年初我们上线了纯海外的项目，由于系统架构采用微服务管理，与老系统又没有太多耦合，所以我们直接上了一套基于jenkins的系统来做持续集成的支撑，让我们更多转注在我们云通讯平台的研发上。这个版本采用了jenkins，jenkins+容器编排打造的CICD平台在我们另一块物联网业务已经验证了1年多了，整体维护都比较简单，无需我们参与太多的二次开发，这样把我们这块的研发人员也解放出来了。目前我们出海通信品牌ycloud就是基于这条系统进行持续集成和发布的，整体效率比较高，当然这也要求我们软件架构上采用更松散解耦的微服务架构才能实现。当然这一套也是存在的没有兼容老应用，特别是不是微服务架构的一些应用，需要改造成本也是比较高的。

那么，坑在哪里呢？

目前来说，由于历史的技术包袱，三套系统其实共存着，部分应用用最初的老版本，部分应用用第二个版本发布，新应用都用最新的这个jenkins做管理了。这也就导致了整体的维护、和改造的的成本极高。这其实是非常值得反思的，为什么会有三套系统做类似的事情？在第一个系统在决定自研的时候，是否考虑过市面上能解决这些问题的产品？第二个的产品说改进有改进，但又没有做的非常好，而且跟老应用不兼容，也是有问题的。第三个系统是否就是未来的最佳选项？这些都是我们要思考的问题，也是很多中小研发团队在技术迭代的过程中无法回避的问题，大家可以多思考思考。

第二个案例也是上面提到的，统一权限管理系统（含统一登录）

这个系统，是为了解决我们各种内部系统都需要用到的共性的一些能力，第一个是登陆，第二个是权限管理。在这个系统之前，我们也有一个简单的权限系统，由于开发时间早，系统内的权限没有合理的管理，功能和代码耦合在某一个管理系统上，导致很多权限无法精确的分配到人或者部门或者角色上，所以我们在17年的时候，决定重新做一套系统来解决这些问题。由于这个系统比较独立，当时前端团队有工程师愿意接手，用的是python作为后端语言，前端用了vue + element技术栈，总体上开发出来的产品基本把我们在权限管理方面的效率提升了几个层次。甚至还支持了saml和ldap登陆，为登陆外部的服务系统提供了有力的帮助。

但是这个系统的坑在哪呢？

因为这个系统不是公司的主要业务方向所在，所以工程师在开发上投入的时间不是很充足，功能的实现也是点到为止，而且由于是一个人独立从前端到后端完成的，甚至连代码的文档都没有很完善，有的只是使用文档和一些系统运维文档。整个系统在使用上属于基本满足状态，但并没有满足一些国家的信息安全标准，后面在做一些常规的安全测试上找出不少漏洞，整改起来成本也比较大。所以后来我们在21年的时候，开始采用专门做这类统一登录和权限管理的第三方服务来承载。

这个系统的研发决策，也值得我们反思：第一是开发语言的选择，我前面提到我们的后端技术栈是Java，使用和熟悉Python的人不多，如果这个工程师离职或者被调动去做其他更重要的事情后，这个系统就会陷入无人维护状态，这个问题是很大的。当时选择自己开发，也没有参考一些成熟的实现。一些影响时间久的问题，也迟迟得不到解决（因为投入的资源不可控）。这几个问题，也是我们在技术演进过程中应该思考的。

第三个案例是我们在SaaS软件上开发的CDP系统

简单说一下CDP，CDP就是customer data platform，也就是客户数据平台，用来沉淀客户的用户数据的，可以认为是CRM的底层服务。这套平台引入了开源组件Presto，该组件屏蔽了底层数据库的实现，把所有查询都统一成一种查询语言，用于解决不同数据源的统一查询问题。不得不说，这个组件的引入还是有存在一些架构师的个人喜好上的，因为我们当时的业务实际上没有复杂到必须搞多种异构数据源的程度，没有充分考虑市面上已有的其他方案，导致该对系统喜好的人员离开之后，维护成为更大的问题。大家知道，中小的研发团队，引入大家都共识上熟悉的组件，问题不大，但是引入一些只有少部分人了解的组件，可能会埋下大坑。随着数据量的增大，这个系统的稳定性越来越不可控，所以后来我们重新改成用阿里云的odps来实现。

上面提了很多值得我们反思的问题，那么这些问题的共性在哪呢？

我们总结了一下，主要有以下三点：

1.技术选型决策没有很好的结合公司实际业务和资源情况去考量。

2.技术方案的决策依据不充分，部分依赖了开发人员或者架构师的喜好。

3.没有对内部开发的产品进行生命周期管理，通常是开发完上线就结束了，没有考虑后续维护问题，而这些问题都需要投入巨大的成本去解决的。

所以我们慢慢从自研+开源模式，开始拥抱第三方服务。还是那句话，专业的人干专业的事，我们公司核心业务是做云通讯，理论上应该集中精力把云通讯的能力做大做强，而不是去做一些我们能做但是实际上不是我们擅长的方向的内部产品。短期内看起来不需要采购外部资源，长期看由于不是业务重心，总会有投入不到位的时候。其实我们作为2B的云通讯厂商，被客户选择也是一样的道理，客户没必要在自己不擅长的通讯上专门养团队去开发一个产品，直接选择我们这种更专业的第三方服务就好了。

我们目前已有一些服务陆续在转向采用第三方，不是说第三方就没问题，而是要充分评估第三方在我们系统里的关键依赖程度，能容忍一些偶发的性能问题发生，又能解决大部分的其他问题的，其实第三方也是合适的。

这些是我们在使用三方服务上的一些成功案例，每个公司都不一样，大家可以参考，但不用照搬。

1.非实时数据分析采用阿里云的maxcompute

2.采用商用且成熟的报表软件来开发报表

3.采用云日志，一来我们不用担心磁盘刷爆，二来日志本身的搜索分析原来也需要elasticsearch等东西来维护，成本不低

4.实时数据分析采用阿里云的blink，性能更强悍，服务的稳定性也不需要我们担心

5.容器化的运维服务采用阿里云的ack和镜像仓库

6.线上数据库的管理UI从yearning换成阿里云的dms。

这些都是一些案例，里面的产品基本上市面上都有很多家服务商在提供，每个公司应该结合自己的现状做选择。例如你用腾讯云的，没必要就非得用阿里云的这些服务，我们用这些只不过是因为我们服务器都在阿里云上而已。

可以看到，随着研发团队的发展，我们不会再限于自研系统，而是会充分拥抱云原生服务和第三方服务。充分拥抱不是说无脑选择，评估的时候还是得充分。

我们考量的点主要是：功能完备性、文档完备性、持续的技术支持和迭代能力、能否节省运维和开发的精力。

以上说了这么多，都是根据我们公司的经历过的一些案例，总结出来的经验，那么我们作为一个中小规模的研发团队，在自研、开源、第三方服务商应该如何做选择呢？下面会给一些建议，不一定全对，希望对中小规模的研发团队有一定帮助。

首先看自研产品：

我们有句话叫，痛并快乐着，但是痛苦多还是快乐多，可能自己亲身经历了才知道。在做一些公司内部的管理系统的时候，应该考虑清楚，开源也好、第三方也好，他们的服务肯定都不能100%fit你的所有场景，但是不是因为无法满足百分百的需求，就必须得走自研的路线？

支持自研的人有几个出发点，我们可以看看：

1.从功能满足方面考虑，是的，毕竟自家的研发，完全可以开发一个适配自己公司业务场景的产品，但这些公司的特殊需求是否真的合理是我们需要考虑的。还有我们对开源产品或者第三方产品是否研究透了，是否真的无法支持？

2.有研发的工作不饱和，自研产品可以充分调用研发的积极性，节省成本。这个问题也是很多人遇到的，为了做事而做事，纯粹找事做，而且看起来短期节省了一个第三方服务的成本，长期来看如果要一直投入维护的话，成本并不低。

3.一些非业务类的系统，反正研发开发起来也熟，也不影响业务本身，可以给研发练手做玩具。从公司角度讲，这都是挺危险的事，就是技术的投入与业务的发展不匹配，而且很多研发同学也喜欢通过造轮子来证明自己的能力，有开源的产品也不用。

通过我们这么多年的经历，我们总结下来主要有两个观点：第一，如果是业务强相关的内部系统，自研是必然道路，也更合理：比如你的销售薪资算法，构成来源跟很多公司都不一样。CRM系统关注的业务流程也不一样。还有一些运营支撑BOSS系统的开发，核心的通道资源管理等等。第二个观点是，如果一个系统跟业务不是很相关的，在做自研还是开源的决策之前，一定要多看看、多想想现有的轮子是否能用，哪怕无法100%满足。

然后我们再来看开源产品：

开源世界是由自由软件推崇起来的，大多数开源软件都是能免费使用，有一些软件不允许商业化使用。像我们上面用到的各种开源软件的社区版，基本都是免费，而且我们也不是把软件拿过来改造后商业化，而是用于解决我们一些业务问题的，所以基本都还是免费的。但是，免费的不一定是最便宜的。这句话怎么理解，就像前几年互联网流行的话一样，免费的是最贵的，如果一个产品是免费的，那么用户本身就是该产品的一部分。当然开源软件的免费不太一样，他不通过广告收割开发者，但是会通过一些技术支持、顾问之类的来收费用。即使你不用他们的技术支持等服务，很多开源软件的社区版功能上往往会比商业版落后很多，而且稳定性会存在问题。如果遇到bug了，要么你自己魔改解决，要么你等社区提交补丁解决。当然大多数时候你等不了补丁，只能自己打。还有就是在运维上，挑战也不小，需要投入较多的运维人员去维护不同的开源中间件产品。如果一个开源产品在社区上足够成熟也足够稳定，理论上用起来问题很小，比如nginx，基本上很少会遇到他的bug。

我们总结，核心系统核心框架，在开源的选择上是必要的，比如用springboot这类框架，大可不必去开发一套自己的框架。而在核心系统之外的其他组件，开源是否依然具有最高性价比，这个还是要持一定的怀疑态度。

我们对开源产品的选择也有几个考量的维度：

1.该开源产品是否在持续更新维护，比如看看github上最近的提交时间线是否活跃；

2.我们自己的研发人员、运维人员的能力是否能cover这些组件，遇到问题是否能trouble shooting 3）业务类的组件，比如一些低代码的生产力工具，不能纯看价格，还是看产品的易用程度，因为这样才能真正的提高生产力。

我们再来看看云产品：

随着云技术的发展，云厂商的产品形态也越来越多样化，不再是以前仅仅是超卖一下服务器和数据库，他们会把很多的开源中间件做二次开发和封装，变成自己的产品和服务。那么云厂商提供的这些产品，对中小规模的开发团队来说，是福音还是陷阱呢？

这是某云厂商的产品能力，可以看到，基本能覆盖各行各业的基础开发的需求。

那么这么多云产品，我们应该如何选？我们总结下来还是得具体问题具体分析：

1.同一个厂商，对统一类型的场景，可能会提供多样的产品来应对，那么这些产品我们应该怎么选？这时候就要考量云厂商本身核心关注点，不要最后用了他们的边缘化的产品，面临他们产品下线的风险；

2.云服务本身的容量和规格应该怎么采买？我们总结的方式是按需购买，按量付费，因为大多数的业务都是有波动性的，没必要把一个高峰时期的系统配置变成日常的系统配置，需要的时候再扩容或者采用一些自动扩容的技术服务；当然这里的资源情况一定要结合自己业务的SLA承诺，如果你承诺给客户4个9、5个9的稳定性，那么很多时候你的服务的部署一般要做很多的冗余。如果承诺没那么高，也可以减一些配置，根据业务量来调整，具体问题具体分析。

3.云厂商提供的这些产品是否已有业界的标准协议或者开源实现，如果有基本上他们不是独家的产品，可以多对比几家云厂商的优劣进行选择；厂商锁定也就是所谓的vendor-lockin的问题，小规模的团队来讲，不太需要关注，但随着你的业务量越来越大的时候，这些会变成风险。比如业务成长到需要多云环境服务的时候，你发现一些组件被厂商锁定了，就很难进行多云化的操作了。

4.还是得评估成本，成本的评估是多方面的，除了算力本身的，还有长期的存储成本，安全方面的成本，以及长期运维的成本，都应该考虑进去。

我们云片经过这10多年总结下来的经验就是，选择云产品，要结合团队自身的技术和架构经验，在对产品的特性了解清楚之后再做选择。一开始只需要服务器和简单的DB，随着业务的发展一定会面临着各种各样的组件出来，这时候一般不会全云服务，也不会全开源+自研，更多时候是多种组件共生的状态，一定要结合业务角度去做决策。

我们再来看看第三方的服务

除了云厂商，还有很多的一些软件厂商、SaaS服务厂商，也在提供很多服务，那么这些服务是否靠谱？我们觉得还是有靠谱的公司的，不然他们也活不长久。

我们目前用的一些第三方服务有报表系统、数据安全、身份认证以及wiki、研发管理流程等等的产品，对这些产品我们也有一些经验的分享：

在供应商的选择层面，要关注供应商的口碑、技术保障能力、服务响应能力以及产品的持续迭代能力等维度；在和供应商后续的合作，要保持开放的心态，有问题尽管提，让供应商来提供解决方案同时对他们来说也是获得了更好的产品能力提升，总体上是合作共赢的。

总结一下：

回到开篇提到的这个问题，自研，开源还是拥抱云原生和SaaS服务，相信大家心中应该都有了一个基本答案。随着云厂商的服务不断成熟，以及第三方企业技术服务（无论是否是SaaS模式）不断丰富，是否能充分利用这些服务降本增效、加速新产品开发，可能是决定一个公司在产品研发上是否能成功的一个关键因素。我们在这里分享了自身的经验教训，这些可能并不算是最佳实践，甚至可能是自曝家丑，也因为我们做的时候云平台和第三方服务还不是很成熟，很多我们要用的服务都没有，所以前期我们用开源+自研做的轮子比较多。但我们希望通过这些真实的例子，大家可以少踩一些坑。也希望能和大家深入交流相关话题，共同进步。

最后简单介绍一下我们云片。云片是一家全球CPaaS服务商（CPaaS就是通信平台即服务的意思），集成一站式的全球短信、全球语音、全球彩信、邮件、WhatsApp、身份验证和营销管理能力，把各种通讯能力通过API接口可编程化，为企业客户提供全球最佳验证和营销实践方案。我们有9年多的云通讯服务经验，6年出海及出海服务经验，目前全球累计已经服务过19万+家企业客户和开发者，帮助他们通过API实现场景化沟通。

问题互动

Q：看到云片现在也有在做海外通讯产品，当业务面向海外市场时，整个的技术服务选型要求和国内业务有什么共性和差异的地方？

A：面向海外业务的业务基础的技术选型和国内是类似的，因为这样可以复用国内有成熟的技术业务积累。

主要的差异是：

1. 海外业务从系统到业务是完全独立于国内的，相当于全新的系统，这让我们在拥抱云原生技术栈时历史包袱更小。我们的海外业务云原生化更彻底，中间件和基础服务，从存储、网络到安全服务，只要云原生产品适合都会首选云原生。

2. 海外业务对合规要求更高。除了云平台的原生服务，我们也会评估和引入成熟的第三方服务，如跨境支付使用stripe，他们的风控体系可以屏蔽掉很多欺诈的买家。我们在选用每项第三方产品时，都会评估：第一，这些产品本身的合规性如何，是否遵从GDPR要求；第二，这些产品对我们自己的产品的合规性有哪些促进作用。不仅合理使用第三方产品，且将这些产品的合规能力整合成自身的合规优势的一部分。