中国应用性能管理行业盛宴——2016中国应用性能管理大会（简称APMCon2016）于8月18日至19日在北京新云南皇冠假日酒店隆重召开。APMCon由听云、极客邦和InfoQ联合主办的作为国内APM领域最具影响力的技术大会，首次举办的APMCon以“驱动应用架构优化与创新”为主题，致力于推动APM在国内的成长与发展。

群脉网平台架构师房玉峰于基于云架构的性能优化专场发表了题为《依靠“全方位”的云服务，初创产品的快速迭代和“云端”优化之路》的演讲，现场分享了在构建初创产品过程中利用云服务来演进的经验和踩过的坑。

以下为演讲实录：

房玉峰：大家好，感谢今天有机会可以跟大家分享一下三年来我们的产品从无到有的过程。刚刚七牛的朋友分享了七牛的整个直播，其实我们也是七牛的客户，因为我们从产品第一天开始上线就依赖于各种各样的云服务，所以今天刚好趁这个机会和大家一起来看一下，这三年的过程中我们是如何利用一些云上的服务来快速迭代以及演进我们的产品的。

首先介绍一下我自己。在IT行业混了十年，几乎从来没有在任何大会的场合来分享自己的经验。我在群硕差不多做了十年，2006年毕业就加入这家公司。十年的过程中做过了很多企业级的项目，比如美国的Motorola公共安全系统，它是美国的911系统，现在已经在美国的几十个城市上线了。它是一个公共安全领域方面的系统，相当于说你在整个城市任何一个地方，如果出了一些火警、抢劫这种事件后可以通过这个平台快速调度你周边的消防员、警察。这是一个很大型的、企业级的一套软件系统。

我后面做过CNTV国家网络电视台，当时我是带了一个团队在北京做了将近一年多的时间，和央视整个团队一起构建CDN节点、转码队列以及整个视频分发的系统。这次来北京又和央视的朋友在聊，他们告诉我很快就会把之前构建的视频转码系统迁移到七牛上面了，我觉得这也是云带给我们的一个转变，当年的团队做了很长时间，到现在有一些更好的云服务之后，他们也会做一些这方面的转变。后面也做过第一财经、SMG等，帮他们构建了新一轮的管理平台和第一财经的手机客户端。

然后，又做了移动车辆管理系统，这是美国的一个大型系统。因为美国有很多的法案，所有的卡车只要在公路上跑，必须符合美国的一些法律法规，所以我们就会有一些小型的设备连在卡车的引擎上面，实时收集所有卡车引擎的数据，这些数据会通过这些设备传输到智能手机终端上，然后把这些数据再实时传回到后端的SaaS 平台，相当于是一套从移动终端到整个SaaS平台一体化的系统。现在我主要负责群脉SCRM SaaS平台，带着团队差不多做了将近三年时间，这也是今天和大家分享的一个重点。

展开全文

简单介绍一下我们的产品，因为后面会讲到在云服务上的架构演变都和这个产品有关系。

微信出来以后改变了很多人的生活，站在我们自己的角度，微信除了是和朋友交流的工具，也是我们每天看文章或者订阅资讯一个新的阅读方式。比如你去餐厅或者去商场，你只要扫一个码就会给你优惠，这是站在我们用户的角度来使用这个平台。

站在企业的角度，整个微信对他们的冲击还是很大的。以前可能你买一个冰箱也好或者买一个空调也好，然后你扔在家里就算了，这些服务商是没办法真正触及到你的。但是因为微信的出现给这些企业很多的机会，用一种新的方式来触及到自己的客户，通过一些公众平台上的交互，比如我的产品出了问题，我需要客服支持，我需要预约整个售后的过程。站在企业的角度会看到，这个客户和我互动过多少次，购买我的产品出现过什么问题，他对哪方面的东西比较感兴趣，对整个企业来说相当于增加了一个新的渠道来触及到自己的客户，也方便他日后的营销以及客户经营。群脉就是这样的平台，我们帮很多大的客户群，像联合利华、日赢、永达、上海迪士尼都在使用这套系统来做他们的客户管理和日常运营的工作。

我简单介绍一下联合利华的故事，在没有微信之前或者说没有这种工具之前，联合利华每年和批发商的管理全部是通过电话或者其他一些比较古老的方式。他有二级经销商、三级经销商，这些经销商每天都有计划，我希望今年向联合利华进行多少采购以及采购达到目标之后每年会给你多少折扣。去年他们把整个经销商的管理平台全部迁到微信上，经销商在微信里面可以直接进行整个产品的采购以及季度的汇报，甚至到年底时候一些返利的执行。还有每年在联合利华的调味料瓶子上面都会印二维码，之前所有的厨师只要用到联合利华的商品，就会把二维码揭下来放到信封里面寄给他们，他们收到之后把返利返回去，现在都是通过微信的二维码。每年在年底的时候说某个品牌有1亿的出货量，需要1亿张二维码，他把二维码提前准备好，直接发给这些厂商，他拿到东西以后打开微信关注扫码，然后完成整个对厨师的优惠或者说折扣的返现。

接下来我会介绍一下，三年里面我们的产品整个架构上面的三次转变。1.0就是两三年前，我们是一个很小的团队，我们唯一的目标就是要快，希望可以生存下来。把我们之前自建的机房开始往云上做迁移，我们希望我们的研发团队可以快速的利用云服务来加速我们整个产品的迭代。

在 2.0的时候，差不多一年之后我们有很多客户进来，不断有各种各样的需求进来，我们也经历了一个快速发展的过程。所以在2.0我们就会遇到很多很多技术上的一些问题，这些问题有些我们是可以通过架构的重构来解决，有些很多的问题我们会优先利用云上的方案，云上的一些技术或者说其它的一些SaaS服务，让我们能快速的解决我们当前的问题，这是2.0的现状。简单来说就是借助云的一臂之力快速的迭代以及演进产品。

不管1.0还是2.0，其实我们都是在做1+1等于2的事情，有一个客户需要10个人，来一个新的客户可能就是20个人。3.0也是我们现在在思考以及正在做的事情，我们希望做一些1+1可以大于2的事情，用一个小的团队来服务于多个客户。这个阶段我会有一些想法和大家简单分享一下。

一、产品架构 1.X

在1.0版本，我们开始从自建到云的转变，很重要一个就是团队因素。三年前互联网大潮在中国蓬勃发展，我们也希望加入，但是我们的团队并没有这方面的经验，不管以前我们是帮助SMG构建他们的整个软件平台也好，还是帮助央视CNTV做他们的平台也好，我们所有的模式就是帮你把软件做好。如果你希望用我们做好的软件来提供整个硬件的基础设施，那SMG的时候是我们帮他们一起，他们会寻找一些硬件厂商，会一起来建机房，最后把我们的产品部署到他们的机房里面。CNTV的时候也是一样，一起提一些硬件的需求，每一个节点里面需要多少台服务器，每个服务器是什么样的配置，所有这些方式都是我们在提供一些软件的服务，整个基建的建设是我们的客户在构建。对于我们来说这就是我们比较欠缺的一点，所以如果我们要快速的做我们的产品，这方面我们几乎是没有经验的。

另外一个就是需求的因素，我们要快，快了才能活下来。你不可能做两年的时间，最终才来交付你的产品。另外，在那个时间刚好国内的云环境开始起步，简单来说可能天时地利人和，这是好听一点的话，难听一点的话就是用云上的服务，我们是没有别的选择，就是被当时的现状所逼的。

昨天晚上和阿里云的朋友聊天，他问我说三年前你为什么会选择阿里云，我说你看现在阿里云发展得这么好，所以当年我们选择了阿里云。其实在那个时候我们也不知道，各个大的厂商都在做一些云服务，有阿里云、腾讯云、盛大云，Ucloud我们当时还没有听说，四五个月之后才知道有这家公司，以及新浪云。一个简单的评估，不管阿里还是腾讯都是大厂商，在国内他们是值得信任的。另外，我们觉得像淘宝和支付宝的这种模式以及他们在系统内的经验以后可能会慢慢的融入到阿里云上面来，应该会帮到我们。腾讯当年就是做QQ聊天，可能和我们的产品不太一致，所以我们就选择了阿里云，一直用到现在。

当时云的整个生态发展也算刚刚起步，又拍云、七牛云这些面向开发者发生的云的服务就开始萌芽。什么叫面向开发者发生？我们做SMG 的时候，会去谈如何介入整个CDN，他们就是CDN，我把文件放上面就可以了。当时我们有一个很强的需求，我们的图片怎么办？我们的图片有不同的尺寸，有不同质量的要求，按照以往的经验是一张高清的图上面做各种尺寸的剪裁和处理，每当有需求变化的时候，要把整个图片处理一遍，但利用这些云上提供的像开发者发生的东西就可以很好的支持我们，就一张最原始的高清图片就可以了，我在什么地方用，通过加一些参数实时做一些图片的展现就OK了。我们当时对云还是比较懵懂，认为和VPS差不多，就是不用买服务器、不用托管机房，这是在三年前比较懵懂的认知。

我们的架构也比较简单，那个时候云上面只有主机，所以所有的服务我们都构建ECS，我们都自己构建数据库和缓存。云服务是当时唯一的选择，对我们这种小团队来说只有一点，你需要整个系统没有单点，你需要的是模块化，当你的量上来的时候你只需要加ECS放上去就可以了。对于数据库很简单，开始的时候买一个4核 8G的，量上来之后整个配置往上翻，能支持往前走就够了。

差不多几个月之后阿里云上会有一些新的服务，比较典型的就是有了负载均衡，有了日志服务，所以我们在云上做一些运维的时候会简便很多，有了一些数据的备份和存储的服务。

现在来回顾1.0之前的想法或者做法，就是比较快的开发，不管任何的产品需求，需要在最快的时间内完成上线。但是在运维上面我们是比较慢的，所谓慢不是它的部署驱动很慢，而是因为云上有一些便利的基础设施，所以我们在构建整个运维团队的时候节奏比较慢。一开始20个人的研发团队只有一到两个人做运维的支持就够了，我们满足当前的需求能正常的往前走。这是8/2原则，我希望在云服务的时候，只要能满足80%的需求就够了，可能有20%的需求满足不了，但是我比较看重这80%，它会极大的减少我开发的工作量，可以让我整个运维更方便，所以我就会用云服务，其他的20%我可以选择做一些折中。比如我们当时用SLB来替换Nginx反向代理的时候就会有很多问题，它不支持针对不同的路径做一些反向的负载支持，我们会选择一些方案，会加不同的域名，开多个负载均衡来达到这个目的。一开始我们会买一个很大的磁盘放在一起，我们所有的图片都往上丢，后来我们把整个图片的东西都托管到七牛上面来加速我们的迭代，为此我们会在整体的架构或者结构上做一些调整，但是我们愿意付出这样的一些工作。

虽然我们在云上用了这么久但它也不是一个云端，还是有很多问题需要注意。简单分享几个我们的经验。

第一，我们利用SLB遇到的第一个问题就是SLB太简单了，我只要加一个SLB拿到一个VIP把我整个后端的服务器挂上去就可以了。但是它有一个健康检查，我们也不知道该怎么配就简单配了一个，后来发现那个健康检查都没通过。所以你要把健康检查调到你可以接受的阀值，还要注意在后端服务器上把不必要的日志都关掉。 关于TCP的转发还是HTTP的转发？两个选择各有优点，TCP是基于LVS FULLNAT，所以它的性能会高一点，但是在整个后端的负载上面不是那么均衡，HTTP的均衡性更好，但是它的性能会比TCP弱一点。

关于全网通的问题。我们遇到的第一个问题是，上海移动的某些线路到它负载均衡的线路有很多问题。然后一直有上海的一些客户反馈在手机上访问很慢。最后我们和上海移动以及阿里云的工程师一起来排查这个问题，发现在某些线路上丢包非常严重。现在我们还在排查另外一个很严重的问题，因为我们是在微信做一些开发，微信的报警做得非常非常严格，5秒之内如果得不到服务器的响应，就会给你的客户的公众号上群发报警，每次我们的客户看到这种报警就很紧张，说你的服务有问题，5秒钟丢失了140个或者300个，有时候更多用户的点击事件、用户的关注事件你要去处理，我们花了很多时间解决这个问题。

举个例子，因为里约奥运会，我们的客户NIKE在奥运会做了很多活动，他们希望服务不要出问题，但是有一天他们的团队收到了微信的报警，说5分钟之内有几百个请求没有响应，然后我们很快速的排查了服务器上所有的错误日志发现都是好的，那个时间点所有的监控数据都是正常的。然后我提交了一个工单给阿里云，阿里云告诉我说我们也排查了确实是好的，我们整个SLD当时的负载也看过了也是好的。他说可能是微信的一些链路到我们的链路有些问题，但是客户并不接受这样的事实，所以现在我们还在跟踪这样的问题。我们的做法很简单，如果是某些线路有问题，我们在整个负载均衡的地方开了20多个负载均衡的VIP，我们在整个 DNS的地方来配置，一条线路配一个，如果你是北京的网通是IP A，如果你是上海移动是IP B，我们希望在微信报警的时候可以抓出来，到底是哪条线路和我们的服务器对接过程中有比较严重的延时问题。所以一个经验是对你比较关键的业务，还是在上线之前要做全链路的测试会比较好一点。

第二，对于像我们这种初创的小产品团队来说，可能最不注意的就是安全。我只要有一台服务器丢到云上面或者开机就够了，反正你前面有云盾，有防火墙可以帮我解决很多事情。直到有一天我们收到很多报警，我们有12台服务器被当了肉机直接被攻破掉。因为登陆的信息被注入了，很严重，所以我们回过来开始审视，我们要不要在服务器安全上做一些加强？我们就做了一些调整，我们创建了很多的安全组策略，默认是B原则，我开一台主机出来放到一个默认的安全组里面，所有的服务都是不可以对外访问的，然后依次基于安全组优先级的策略开放一些，有些服务公司是可以访问的，有些服务是某一个跳板机临时可以访问的，服务和服务之间默认不互通的，如果需要服务之间互通就需要通过安全组进行配置，这是关于安全。以前你自己搞一个机房扔进去，如果不重视的话可能你的服务器被人当了肉机你也不知道，但是利用这样的服务，你在第一时间就可以知道什么时候出了什么问题，什么时候你的服务器在什么地方被人访问过，可能你会有一些漏洞等等，这方面的提醒对于我们在安全方面能力比较弱的团队来说是非常非常重要的。

第三，可能和云没有太多的关系，就是你的流程规范以及你是不是要做自动化的运维，或者说有没有时间，你觉得这个东西重要还是不重要。我们从一开始就会比较重视这方面的事情，原因很简单，就是有一个150%的原则，什么意思？比如我现在团队里面有10个人，这10个人每天可以写 1000行代码，当团队有15个人的时候，我希望这15人可以写1500行代码，是一个成正比的往前走，这里有一个前提就是我需要有一些流程和规范来保障，你的代码规范是什么样的？你的merge、request的规范是什么样的？一开始可能感觉我只要写一个东西能运作就好了，但是当你的团队规模越来越大的时候，你就会碰到很多的问题，有一天你会发现团队没法很好的往前走了。

另外一个就是关于自动化运维，我们有一些自动化运维的工具，但一开始我们并没有把它构建得非常庞大，因为我们的团队有限，我只要能满足我当前的需求就可以。最开始的时候可能只有十几台机器，我们通过shell写一些自动化的部署，到后面因为我们的机器更多，shell维护起来会遇到很大的问题，经常在调试一个shell脚本的时候花费非常多的时间，然后我们切到了Firebird，Firebird给我们带来了很大的便利，后来我们的机器越来越多，我们会用了一些开源方案来加速产品的迭代。再到后面我发现我们的研发团队、不同角色的团队也越来越多了，每加这样的角色都要帮他写一些自动化的脚本、工具，我们就重新审视了一下我们整个用到的服务，开始对我们的平台做一些规范。我们现在还希望可以提供一些Web界面，可以让不同的研发团队看到整个自动化部署的状态，这些我们还没有做，但是是我们正在计划的内容，对于我们来说这不是最紧急的，因为现在已经完全满足我们的需求了。

中间的一个重点就是Balance，我们希望在时间、研发的周期以及你做出来的功能上达到一个平衡，能满足现在，同时超出现在的50%，然后用一个比较小的研发来完成。

二、产品架构 2.0

1.0 我们开发很快，我们也遇到了很多问题，所以就有很多问题需要我们快速解决。比如开发速度慢下来，你就需要重新审视慢下来的苗头是什么？比如因为团队的结构，团队人数越来越多，我们整个代码的冗余非常严重，在数据层面我们整个数据的耦合也非常厉害，经常会出现一个问题修掉，第二天第三天上去之后客户又发现了其他相关的问题，大家处于一种救火的模式。所以我们就需要重新来看如何解决这样的现状。

另外，我们整个产品里面或者整个代码里面有很多小架构，所谓小架构就是指今天这个客户需要这个功能，这个功能就加上去了，那第二个客户他也需要这样一个功能，但他会有一点点不一样的地方，那第二个客户可能就会直接加一些Index，对团队来说是最好的方式，第三个客户Index可能解决不了问题，所以就会做一些抽象。比如我们有很多不同的功能模块，我希望能嵌到整个微信的菜单里面，我提供客服的他也需要，提供商城的他也需要，开始的时候我帮你加这个菜单出来，但到后面我们有一些预约、订票的系统他也需要，怎么办？我们就会做一些小的架构，就是定一些规范。当我们整个系统跑的时候我们会看，你的模块里面会有以什么文件名或者以什么格式命名的函数，我们会基于要求的数据格式反馈给我们，自动帮你加到某一个菜单去，这就是比较小的架构。这种小的架构散落在整个代码里面遍地都是。

而且，差不多一年多之后整个云上的生态发展非常快。云上出现了很多应用层面支持你整个研发的服务。所以当我们在解决1.0遇到的问题时，我们会重新审视哪些需要自己做，哪些云上的一些解决方案可能已经满足我们了，我们就会直接采纳这些方案。

因为我们的客户越来越多，为了快我们需要打磨一些通用的功能。可能在同一个行业里面，客户A也需要这些功能，客户B也需要这样的功能，我们会把通用的功能抽象出来，但是我又要针对大客户提供私人定制的服务。基于这样的变化或者策略，会驱动我们整个研发团队做一些调整。我们把整个团队从角色上分开，有一个团队是标准的产品，专注于解决在一个行业或者两个行业里面这些客户都需要的通用功能。对于比较大的客户有一些定制的需求，我们有专门定制的团队来支持。刚刚已经讲过了云上的各种生态刚好有各种各样的服务，所以在解决这些问题的过程中，我们会借力于这些服务来快速的往前跑。

因为客户需求或者说团队结构的变化，我们需要快速解决一些问题。

•首先就是团队层面的问题。我们有多个团队，有标准产品的团队，针对不同的大客户也有一些定制的团队，但不管是标准团队还是定制团队他们整体还是一个大的团队，他们需要有一个比较好的方式相互配合，这样标准团队专注于标准产品做的事情，定制团队又可以在标准产品之上对一些客户提供不一样的功能。

基于这两点考虑我们做了模块化的改变，我们有想过两种方式：第一种，我们有在Facebook上开发一些Facebook的App，研究了Facebook 是如何让开发者做plugin-in的。在某些方面他会有一些方式你可以托管到自己的服务器上面，通过提交一个App指定你自己服务器的地址，对用户来说访问的是Facebook，但对某些功能点其实是访问自己的服务器。另外一种方式就是像WordPress一样，我们是不是也可以像这样？不同的团队像开发一些WordPress的plugin-in一样，需要什么功能只要基于整个架构写plugin-in就可以，针对不同的客户有不一样的功能点。

最后我们选择了第二种，在当前，因为完成时间很快。我们整个团队在一个月的时间就可以把这个框架搭出来，定义一些模块的规范，定义一些通用的API，标准产品就变成一个容器，所有这些定制模块的开发者只要基于规范创建plugin-in丢到代码库里面，我们的代码库通过一些构建工具自动把整个模块放到生产环境，就可以对不同客户提供不同的功能。

•另外就是系统层面的问题。因为用户越来越多，不管是联合利华还是NIKE，每个品牌都有几百万的粉丝数据。所以我们也需要支持比较大的并发，一些大的数据量的调整。我们也做了系统层面的改进，比如消息中间件，因为和微信这边对接的量很大，只要任何一个人访问你的公众号或者和你有互动，微信都会把这个通知到我们的服务器。我们发现 Tomcat在高峰时段就没有响应，因为我们要做很多事情。当有一个粉丝的互动数据进来之后，我要写到DB里面，做一些统计的逻辑，而且在我们整个平台之上还有一些开发者，我需要把这些事件转给第三方，所以在数据量上来之后会很慢，在瞬间就会有一些不响应，微信的报警也会有很多。所以我们第一个改变就想找一些消息中间件，微信的消息进来之后我们把同步的调用变成异步的方式，很多事情可以通过后来的队列去处理。我们当时研究了几个可以选择的代替品，第一个就是Kafka，我们做了一些测试，同时我们也会看在云上面有没有直接来托管Kafka的云的服务，如果有的话就可以直接用，不用自己做整个分布式的Kafka系统了，但在国内除了轻云其他的云服务上没有看到。因为我们已经在阿里云上了，我是不是可以有些服务用其他的厂商？但对我们来说维护起来太麻烦。所以我们就想看下云上有没有相关的产品，我们就看了两个东西，一个是阿里云的SLS现在支持了logtail，然后我们又去看了阿里云的消息队列和消息服务，从功能点上觉得可以满足我们的需求，而且经历过双11的淘宝和支付宝的考验，至少对我们来说我们的量也不会大到那样子，应该能满足我们的需求。我们就联系了阿里云的团队，在和他们团队沟通，这两个服务到底应该选择用哪个？最后我们找到了消息队列开源的版本RabbitMQ，因为我们有些客户有一些私有部署的需求，他们用你的产品，但是希望可以部署到自己的服务器上。基于这样的原则，我们选择了消息队列。当有一天我们要迁出来的时候，或者说我们要帮某一个客户迁出来的时候，至少可以用一个开源的版本去做这件事情，多一个选择。

因为数据量越来越大，对我们这种团队经常会觉得两眼一抹黑，什么意思呢？你也不知道昨天你和微信或者说和你整个第三方平台到底有多少API调用，有多少成功了，有多少失败了，失败率有多高。所以我们就看了一下，如何用云上的服务快速的构建一个API的监控，我们就通过logtail把我们所有的日志直接打到SLS，通过数据格式的定义直接同步到ODPS里面，然后通过ODPS做数据的统计和分析，最终把结果呈现在运维平台上面，差不多花了两个月时间就可以把整个API的调用包括哪些客户有多少量，什么时间有多少量，什么地方成功率比较高，失败率比较高，这些数据都集中到我们的管理平台。

我们在解决客户的问题时也会遇到很多问题，客户说什么东西不工作了，我们需要把所有相关服务器上的日志全部过一遍，很慢。所以我们把整个环境里面所有的错误日志都集中在SLS，然后基于SLS又做了一个平台，当有客户说我们出了问题，可以快速的搜索到在哪台服务器上，什么服务，出了什么错，快速的解决我们生产环境的问题。

这是我们在2.0上做的一个调整，比1.0会稍微复杂一点点。右边是和微信、社会平台对接的一套系统。前面有公网的SLB，后面有API集群，这些集群会把数据直接打到分布式队列里面，会有不同的后台处理不同的事情。我们把串性做的事情全部并行化，该做统计分析的做统计分析，该做索引的做一些索引的服务，包括针对一些高并发的、读写要求比较高的地方做缓存的更新。底层会用到像SLS做日志相关的统计分析，当然也会用云上的一些性能测试工具，有一个新的服务上线或者说当我有一些活动的时候会通过云上的性能压测压一下整个系统的能力。网页端我们就做了一个模块化的调整，有微商城、积分商城、票务、服务预约所有的东西都是通过模块的方式有不同的团队专门维护，但是他们之间通过我们定义好的协议或者框架做支持，让他们可以并行的去迭代。

其实我们用了很多很多云上的东西，昨天和阿里的讲师聊的时候我说，其实在两年前只要阿里云出一个新的服务我都会马上看一遍，然后拿到第一批的要求，然后把整个服务做一下评估，知道以后我做什么业务场景的时候这个服务可能会帮到我。但是今天几乎已经做不了这件事情了，因为你们的服务太多了，你的服务的发展已经超过了我可以评估的阶段。

我们在2.0的时候，也是沿用这样的思路。可能有些东西我们没有找到最好的方案，但是当有些问题出现的时候我们会第一时间去看，你上面有哪些东西，这些场景是什么样的，能不能解决我的问题。我们几乎就是站在了一个巨人的肩膀上，他们可以把所有的高并发高响应都做好，我只要用就可以了。

我也经常和我们的团队讲，在做一个创业的小产品的时候你还需要架构师吗？因为云上的服务已经很好了，你真的不需要了。你只要看看做一下集成，你的产品就出来了。但是有可能在有一天你会需要一个云架构师，他和你说如何优化你的内核或者如何优化你的外部服务器，或者说当你提某一个产品需求的时候他会告诉你，其实在这个世界上有哪些服务你可以快速的去用，你只要五个人开发两周时间就可以做出来。

简单分享一下我们在2.0过程中遇到的问题。

1、和微信整合过程遇到的一些问题。

所有调用第三方API都会有一些API的rate limit。不管你在做产品定义或者产品实施或者你在研发的时候都不会注意这些事情，但是有一天发现用户走到一半卡住了，为什么？因为有些API的限制非常高，有些API一天只能调一百次，但是并没有从产品上杜绝这个问题，造成我们架构调整的时候代价很大。

另外会有一些白名单的限制，我们一开始觉得微信可以加20个白名单已经挺多了，但是这次里约奥运会，某一个客户上面已经超过了20台，所以我们做了一个调整，所有第三方调进来的可以水平扩容，但是所有调出去的地方都是通过专门的服务器调用微信的服务，保证调出去的IP不会受到限制。

我们也突破过微信每天群发一条的限制。有一天有一个客户群发了16条，我们和微信的团队一起来调这个问题。最后发现是他们有一个小bug，加上我们一个绕过这个bug的问题，触发了他们无限量的消息群发。当时这个客户发完之后，很多客户都问说，你们是不是和微信有专门的合作，所以你们可以绕过微信的限制发这么多，然后我们每次只能呵呵一笑。

另外我们做微信自动化测试很麻烦，所有一条消息通道都是从微信的客户端到微信的服务端，最后再调到我们的服务上面。当我们的量越来越多，功能越来越多的时候缺乏一些测试。所以现在我们也在构建一些基于微信自动化测试的东西，这是比较麻烦但又不得不做的事情。

2、我们在帮一些客户做运营时也遇到过一些薅羊毛，说起来都是血和泪的教训。所以我们也利用一些服务做薅羊毛的防范，通过整个数据的Logs到SLS，再到ODPS，到我的业务数据库做统计分析限流。像现在联合利华已经决定直接使用这些数据风控的服务，来解决潜在的安全或者被薅羊毛的风险。

我觉得主要就是重视，像我们在座的各位可能完全没有这方面的意识，大家觉得一个手机号收一个验证码，后来发现其实中国有很多的薅羊毛党，他的手机号是虚假的，但是可以收短信，只要收到短信就可以给他积分，可以完成整个活动，全部都可以自动化。

3、我们用了很多的云服务，我们也踩过云上很多的坑。但是整个团队，包括我们的团队和阿里云的团队或者说和我们用的服务商的团队，大家可以一起把问题很快解决掉。第一个就是有一天我们发现我们整个Redis一直在报警，当然在云上面DNS出了问题把内网解析到外网，所有调用第三方服务的时候都有超时，没有设超时的话平时毫秒级的延时，真正量上来以后可能就是几秒到十几秒，这是连锁的反应，整个服务全部就会宕掉。另外两个月之前我们从自建的MongoDB直接切到云的MongoDB，在切之前我咨询过一些云服务商，我问主节点和副节点的延迟多少，他说毫秒级，我说我需要关心吗，他说不需要关心，写进去马上读没问题的。从我们自己的感觉来说，这好像是不可能的事情，但是如果说我们就先试一试，我们就在某一次活动里面上了，但是当量上来的时候我们发现这个延迟有时候可能到1分钟到2分钟，最后没办法我们就切回来，简单粗暴的方式扛过了那次活动，很多时候还是要做折中的考虑。

每次在云上出问题时我们有些客户会说，云这么不稳定还要用云吗？就像我们给你们提供一些服务一样，因为你付钱，所以你觉得只要付钱一定是100%的。但是，如果不用云你自己自建会有问题吗？我觉得一定会的。以前我们自建的时候也会遇到很多问题，可能一年里面比你用云服务遇到的问题更多，因为你是自建的，所以当你出问题的时候你就会觉得这个苦水只能自己咽下去。但是用了云服务，哪怕出了一点点问题，在一年里面服务他非常非常好的，但是哪怕出一次也会很生气，然后也会偷骂你一顿。所以可能还是看你有一种什么心态吧，对于我们来说因为被骂多了，我们会保留一种心态，我们觉得你会越来越好，因为我们觉得我们提供的服务也越来越好，所以我们还是继续用，可能会遇到一些问题，但是你自己做你也会遇到各种各样的问题。

我们整个从1.0到2.0或者说到感触比较深的地方，对于我们小的团队，遇到一些问题可能会有一些短平快的粗暴方案去解决。比如我们有一些搜索的需求，当搜索变慢的时候加索引，当需求变更的时候改索引，它是可以满足我们一个当前的业务场景。我们也遇到过一些统计数据丢失，突然有一天一些客户说昨天我的用户互动的统计数据没有了，但是我们发现我们自己的一些服务上面都是好的，只有个别客户丢失了，怎么办？出现第一次的时候我们会专门再跑一遍，告诉客户说数据有了。第二次我们觉得不好意思，所以我们会说，当出问题的时候我比客户先知道，所以在我们统计的地方加了一个短信的提醒，如果早上七点我收到一个短信说哪个客户，哪个微信的服务号统计数据失败了，我们会在客户发现之前第一时间解决掉。但是这种折中的方式累计多了之后你还会欠很多债。比如说搜索推荐总有一天你没办法再加索引了，像我们有些粉丝的表放某一个客户可能一开始几百万进来，后来越来越大，他希望根据客户的交互时间，根据互动的时间各种条件进行搜索，就没法满足，所以我们会切到 OpenSearch专门构建一个平台做搜索。客户越来越多，你会发现每天你都会收到一个报警，只是是不同的客户，只能停下来解决这些问题，必须要花精力彻底的解决掉，而不是一直在救火。

代码和冗余越来越严重，对于优惠券的模块或者商场模块，客户说希望这个界面颜色可以和我的logo颜色像一点，另外一个客户说我希望在下单的时候可以多加一点。所以我们通过整个后台控制哪些客户可以看到哪些模块，会有一些代码冗余，当这种东西越来越多，你会发现你在修这些问题的时候就会变得越来越头大。

然后我们有一些自动化的监控，发展到后面代码量越来越多，模块越来越多，每次部署时间很久，所以我们也需要急剧的解决自动化优化的问题。还有数据隔离和丢失，我们在分库分表上做的还不够灵活，会有一些问题，也需要我们快速的去解决，因为它已经阻碍了我们的脚步。生产环境问题的跟踪越来越困难，虽然有错误日志的平台可以方便的看到错误，但是监控数据分散在各个地方，有的在云监控上面，有些是在消息队列服务上面，为了解决这个问题你会四处对一些报表，这些是到现在为止我们希望能快速解决的问题。目前我们也在尝试APM的服务，报警的时候当然希望知道哪一行代码在哪一行出了什么样的问题，到底是慢还是抛了异常。现在也在和像听云做一些前期的对接，看我们怎么样利用他们的方案解决我们这方面的问题。

所以3.0我们不会做大的调整，但是会做一些变化。比如模块里面的耦合太严重，我们可能会开始做一些微服务让模块和模块之间都是独立的，他们之间通过RPC或者系统的调用解决之前的耦合。

最终其实我们希望有一天也能提供一些云的服务来反哺整个云的生态，在底层就是整个云的基建设施，中间有很多SaaS服务，在我们的服务站有很多开发者，可以方便的来利用各种各样的云、SaaS服务快速迭代自己的产品。这是我今天主要和大家分享的。