视频访谈： 陈涛:基于开源项目的高可用架构，十倍容量防止业务过载

陈涛： 我们业务场景上来说是非常重视这个稳定性，技术圈内大家比较了解的可能是阿里双十一，有一个著名的零点的洪峰，它针对这个做很多事情，包括也开源很多的技术。我们云通讯场景下，比如说以个人为例的话，你的手机能不能发短信，打电话，因为平时它都是稳定的，没有感觉，但是突然有一天发不了短信，打不了电话的时候，你其实是非常的焦虑的，那我们其实是作为一个企业服务，to B的，那么企业在用我们的产品的时候，如果遇到这样的问题，他可能不是短信资产上几毛钱、几分钱的损失，它可能是一个业务上的重大的损失。在这个背景下，我们云片在做架构的时候非常重视稳定性这一块，我们也做了非常多的工作，所以来和大家分享一下。

3. 稳定性取决于哪些不稳定的因素？

陈涛： 高压系统的话，比如说像我们这个PaaS应用平台来说，它的入口就经过我的这个平台最终出去，这个稳定性有三个大的方面，首先是这个基础环境，比如说你在阿里云，那么阿里云的这个多可用区有没有用起来，其次还有本身的这个架构，主流里业务代码的稳定性，依赖的ZK，依赖的MySQL，这些东西是不是高可用的，最后一个就是出去的时候，你的外围，有没有去监控它的稳定性，如果跟我们业务相关的话主要是这三块，但是每块都可以有非常多的展开来讲。

陈涛： PaaS本身是通用的，我们是上面的一个云通讯的一个业务，它的一个特点就是说，它对稳定性要求非常高。举一个例子，有一次有少量的短信，响应时间达到两三秒，客户马上就发现、反馈，另外就是非常早期的时候我们可能有些短信没有发出去，客户马上就有很大的感受和意见，因为他是明面上损失不大，但是实际上这个损失是非常大的，影响到他的业务。所以稳定性是非常敏感的，而且跟阿里不一样的场景是，像阿里0点洪峰，他的策略是保护自己，我只能处理每秒11万比交易，那如果超过的话多余我会拒绝掉，会对自己有这个保护，但是对于我们来说，肯定是不能拒绝的，我们一定是说尽量保证首先容量的支持，其次我们在开发的过程中，保证自身的稳定性。

陈涛： 这方面现在还没有，我们现在最早的这个同步主流层就出去了，这里面会有稳定性的问题，后面我们的架构是完全异步化，异步化以后，那么就不会依赖于外部资源，就可以做非常多的调控，包括提到Docker，因为我们在发展过程中运维能力包括快速部署的能力现在都有一定具备了，再加上我们稳定性要求这么高的一个场景下，我们现在还没有说急着去说使用这个东西，但是我们现在也有在做研究，比如它对标准环境的一些支持，可能会在测试环境先试用一下。

6. 有没有出现业务过载的情况，你们是如何应对？

陈涛： 我们最直接的答案就是没有，我们的业务场景是不能拒绝别人，所以我们平时的容量是10倍的容量，再加上我们的业务场景，除了营销类的短信，会非常的高以外，验证码还是比较平滑的，所以到现在也没有出现一个过载的情况。

陈涛： 我们首先使用的是RocketMQ，选型的时候，最早的时候，在我加入公司之前就已经在用了RabbitMQ，然后当时也遇到一些问题，比如RabbitMQ的堆消息，比如说堆了10万，100万的数据的时候，它就会有一个流控，请求block，但是这个问题一直没有解决，另外还需要一个延时消息场景，就是这个消息放进去两个小时之后才能出来，类似这样的场景。然后我加入公司以后，就说就用RocketMQ，因为跟RabbitMQ对比起来，他的优势还是比较明显的。为什么没有选Kafaka，一方面是说，我的这个阿里的这个背景，因为在2015年的时候，RocketMQ也没有说像现在像要成为一个Apache顶级项目，也没有很火，但是首先我非常了解它在阿里的应用，用在交易这种非常高可靠的一个场景，所以我觉得他的质量是非常OK。还有一个就是我也非常了解他们的这个开发团队，他们也非常的靠谱，所以说这个背景下，另外Kafaka的topic非常多的话，也会有性能问题，所以我们最后还是选择RocketMQ。

陈涛： 我们技术栈都是依赖各种开源项目，就是像MySQL，MongoDB，RocketMQ、ZK这些东西，然后我们其实也一直想回馈社区，我们公司最近两年一直有捐助一letsencrypt.org，它能够颁布免费证书的一个东西，所以我们也一直也有通过捐助的形式来回馈。因为做开源的建设，像之前有一个段子，出现了Heartbleed漏洞，是一个非常底层的基础依赖，然后很多都要升级，最后去看谁后在维护的时候，发现它也是一个开源公益性的组织在维护，然后才开始有很多人捐款之类的。我们其实一直有在做这类捐助

陈涛： 对，这一定把开源的东西回馈给社区，包括分支这一块的话，基本上，还是跟着开源社区的版本走，不会隔很多的版本。因为隔很多版本以后，要升级，这个问题就非常多。

陈涛： 阿里的话它是非常大的，在里面做的是比较深的一块，可以看到很多阿里的分享，它一个点就可以做一个topic非常深的讲下去，也是一个比较好的积累，在云片的话，首先是在广度上，比如刚才提到的架构、怎么部署、依赖是不是高可用、devops等，就是你要关注点非常多，深度也要求不低，不能说稍微了解就够了，这在高稳定下是不可能的，有两个区别，一个是非常深的，一个是广度+深度，然后我觉得各有各的好，我觉得这都是非常棒的体验。

陈涛： 微服务的话，我一开始知道的时候，因为我在阿里是维护微服务的框架的，像Dubbo这样的东西，2014年Martin提出这个概念的时候，后面就开始火起来，我开始知道这个概念的时候，一开始的反应是说觉得，因为阿里09年就用了，觉得这是一个比较“老“的技术，怎么突然这么火了，后来我又去看了资料想了，首先非常好的贡献是，他把一个原来不是那么一个概念化的东西，把它概念化了，整体化，方便大家学习，现在你出去和大家聊你会发现知道的人非常多，也有很多人一直在学习这块，概念上比较整体，我觉得这个过程是非常值得我们学习的，非常好的地方。其次关于实践方面来说的话，其实还是想泼点冷水，不要太着急做这个事情，因为平时也聊很多面试者，比如我用了Dubbo ，我就是微服务化了，这完全是为了微服务而微服务。伴随着微服务，你的监控体体系、devops这个体系，没有很强的支撑的话问题会很多，当然有些可能是因为业务没有做起来，用微服务就是体验一下，但是如果真的是用在高可用的场景下还是要慎重一点，不要特别急的推进，过程要稳一点。

还有我们公司目前主要是异步的架构，它的好处和微服务是比较类似的，所以也没有说很急着要改，再引入微服务的因素，因为我们怕给主流程带来一些影响。

容器这一块，背景是我们前面几年积累了一些devops的能力，包括快速发布、扩容这方面的能力，就是说需求没有那么强烈，但是我们确实看到它的一些优点，比如说标准化环境，发布等，就整个标准化了，我们现在正在测试环境下准备去试用。

陈涛： DevOps这一块对我们云片来说，首先我们公司一开始是没有运维的，是开发兼运维，后来来了新的运维同学，他和开发同学也有很紧密的交互，所以这一块从文化上来说是比较好的。另外是从组织上来说会有稳定性小组的概念，里面的角色有运维同学，架构师同学，大家会定期去总结一些问题。所以不管在文化上、组织上我们都有比较好的DevOps的氛围。另外DevOps这个词给人听了感觉就像是把develop和operation合起来造成了一个词，给人感觉一开始是分开的，到现在来把他合起来，我其实比较喜欢像你说的SRE的概念，（Site Reliability Engineer），然后他Reliability的概念已经可以说明它的工作，他不是说开发和运维分开，另外还有一个关键点就是说，你的开发用于50%的这个保证，而不能说一直在做运维，会逼着你去做一些工程化的事情，所以我会比较喜欢SRE的这个概念，并且我们也有在实践这一块。

陈涛： 研发这一块还是想快，也会产生一些新技术，质量这一块它是一个比较宽泛的问题。首先我们在研发阶段，我们公司主要的技术栈是Java，大家会有统一代码规范的共识，一个是说我写代码的风格规范，可以通过自动化解决，我们有这样的 工具 强制大家使用，这样在规范这个层面就没什么问题了。另外还有有一些代码的注意点，一方面我们会把这个文档沉定下来给开发看，另外也会给codereview的同学去看，因为对于codereview这个环节，不同经验的工程师review的结果会非常不一样，比如某个工程师在一个地方踩过坑，他可能在看这一块的时候就特别的仔细。然后我们就有这样一个沉淀，大家有一个统一的共识，比如说并发，哪几块是要特别注意的。另外我们如果在哪里踩过坑，我们会直接关联到这个故障关联系统，以后有什么新的同学进来，他可以直接看到，这个地方曾经造成过什么样的影响，也有非常深刻的体验。这是开发这一块，具体到交付上线这一块，我觉得的主要还是灰度这块，还是要有一个过程。新技术使用的话，基本上公司本身还是比较开放的，我们还是鼓励去使用技术，就像刚才提到的稳定性小组会来评审一下说，一个是说你这个新技术有没有必要以及会不会带来一些问题，然后在这方面会把控一下。

15. 刚才提到踩过很多的坑，跟我们分享几个坑？

陈涛： 这方面主要还是还是基础组件，自建的，像ZK，MongoDB，都踩过一些坑，像 MongoDB 最多的就是OOM问题，内存大户，这个其实是软件本身的一个bug，到最近的版本才有一个彻底的解决，所以说我们之前也是比较痛苦，但是我们架构上做了一些比较好的兼容，也是有replication，可以切换。所以他会挂，但是对我们主流程不影响，大概是前几个月，更新的新版本，就很好了。另外像RocketMQ ，我们使用的比较早，其实最早开源版本文档比较少，我们在部署的时候确实踩了一些坑，比如broker要注册nameserver，加nameserver的时候部分broker忘记加了，造成了类似于像脑裂的问题，现在也都是我们的一些沉定。

16.

陈涛： 另外像Redis，也不能算是一个坑，就是一个架构需要注意的问题，还是刚才说的单点的问题，还是要保持高可用，起码要能够自动切换。之前和一些人聊天说我已经做了主备，好像就可以了，但是他的主备挂了是不能自动切的，需要手动切的，不能够达到一个高可用的这个阶段，所以起码要有sentinel的机制，也就是哨兵。这个背景是说我们梳理这主流层的时候。我们看依赖的东西是不是高可用，首先是前面代码环节不要出问题，其次就是你的依赖会不会出现问题，其实也是会引起故障，后来我们梳理下来发现，Redis只有一个主备，就没有实现一个自动切换，最终做了一个改造，这个改造完了以后确实发生了一些问题，特别是大促的时候，事后回想当时没有发现这个问题的话，那么影响就会非常的大。

陈涛： 最早在2014年选择加入有一个大的背景，有一个创业热，整体创业氛围都是比较活跃，然后自己想做一点东西，云片里有一些我以前阿里的同事，也跟他们聊的很熟，我知道这群人比较靠谱，然后就选择加入进去。现在来看，相对阿里可能没那么复杂的业务，当时我们在创业过程中，一直在追求更大的东西，像我们现在做的就是云通讯行业，也会做一些像物联网，之类的通过流量的方式切入，尝试一些更大的扩张，所以说我觉得这个还是非常靠谱的一个创业公司吧。没有大家想想的那种创业风险，但是一直是在发展。如果现在还有同学想创业的话，还是不要盲目，像我是知道团队，有交流，如果完全不知道的话我建议还是要冷静一点，然后想好了再去做。

18. 这些新的东西，比如AliSQL你们有没有去试过？

陈涛： 确实有，比如我们最近遇到的一个问题，在短信场景下发一条记录就进行一次扣费，如果你发的QPS是3000，那么这意味着针对单行的用户余额进行每秒3000次的更新，减余额的操作，这个其实对应的实质问题就是大量的单行更新。后来阿里开源了AliSQL，这个和阿里的秒杀场景很像，然后AliSQL说对秒杀场景做了一些优化，我们就马上就去试了，实际压测的结果没有想象的好，没有压出效果，一开始我们自己这边查了很多，看是不是我们的问题，也没什么发现，后面跟AliSQL那边联系上了，说这个开源版本也有一些保留，也就是说这个feature没有开出来，以后会开出来。后来我们就想，单行扣费优化其实就是一个队列的过程，我们就换一种方式，在应用层做这个队列，比如队列是100，另外会有一个线程，会一次性拿出100条，批量更新，结果把100次改为1次更新，来解决了我们的问题。