Bmob云服务是如何做到稳定性99.5%
Bmob作为国内早期Baas，是如何做到稳定性99.5%，这篇介绍性能核心问题解决。
稳定性的升级，在用户层感知是不明显的，这就跟微服务的概念一样，只要API层不变，底层技术将变得不那么重要，至少对于开发人员是这样的。你不需要关系，容器是什么、虚拟机是什么、只需要它们使用RESTful API就可以了。无论是android、ios、nodejs、C#等等SDK，在Bmob他们都是基于RESTful API.
稳定性主要一下几个大方面
- 平台技术成熟度 （Bmob Baas发展很多年，几乎不存在这问题）
- 机房网络故障率 （线路因素，本地电信，网通出现不稳定）
- 机房机器故障率 （物理宕机故障）
- 工作人为因素 （代码发布失败）
- 服务器性能不足，运行不稳定。
多年来累积的运维经验前面4项，几乎可忽略不计，一年难得出现一次。影响稳定性问题最大原因是服务器性能瞬间不足，从而影响稳定。这可能是所有IT企业面临的一个问题，如果没大并发，每个企业都能做到稳定。
性能不足、这里我们看一个典型用户案例
服务器性能不足原因，这个代表性的用户，出现的原因是DB 瞬间负载过高就像下面这样。
他这个应用是个正常应用，我们联系他，他说他的业务就是这样，我们告诉他，你是应用影响到其他开发者应用了，最开始他不是很理解，连续几天影响到跟他同一台机器的免费版应用。由于其他用户的投诉的厉害，我们不能为让其他用户这个时段没法用，决定联系他、并与他们技术开始与我们沟通，最终我们给他应用做了压力测试，定制了一套技术方案、来应对这种经常流量爆发的应用。目前这个应用每天还是这样运行者。
这个应用再也没出过故障，也没影响其他人。这个真实事件绝不只是一个应用，每天都可能出现这类奇怪的应用。
这样我们找到了问题的关键点：瞬间高并发。
（我们之前的架构与下面58同城的架构是一样的，这篇暂时不讨论之前的技术细节）
为解决经常瞬间高并发影响大部分人，我们策划了企业版与企业Pro版本完全隔离。实现了定制企业版，300天零事故的成绩。
为免费版瞬间爆发，我们也制定了下面方案。大大提高了解决问题的效率与稳定性
以Bmob的运维经验，云DB服务器的CPU，跟云主机的CPU监控是不一样的，云服务器DB的CPU到60%基本已经读取不到DB里面的数据，而云主机CPU到90% 程序还能正常跑。为了冗余一般我们把DB负载控制在3%左右，像下面这样
提高稳定性，主要是提高DB机器的处理能力，当DB机器，CPU大于10%，我们就能收到警报，进入机器查看是哪个应用异常，观察一段时间，如果其他人没受影响，发现该应用资源占有还是居高不下，我们会把他隔离到企业版本临时服务器，观察他2天，如果正常则迁移回来，不正常则通知开发者关闭应用。如果其他人直接受影响，我们当场会临时关闭这个应用。
提高稳定性，我们也做过一些其他尝试
性能不足主要出现在数据库身上，这个在最初我们以为加内存，加机器可以解决，最终发现是个无底洞。因为你无法知道所有开发者的业务。
免费的开发者在意的是短时间内立刻把我应用恢复正常访问，你怎么处理好，他并不在意。升级DB硬件需要重启，强制重启DB最低需要一小时，而且危险度高。问题根源没解决，重启后可能几分钟内有挂了。加机器是一样的道理，新机器加入负载，需要长时间的数据同步，短时间也没法恢复业务。同步好后加入负载还是可能几分钟内有挂了。因为你并没法预算处客户的瞬间并发是多少。
为了提高稳定性，我们调整过技术架构，升级了固态硬盘，优化过db存储，推出过容器服务。也走过非常多的弯路，经过不断思考试验与技术迭代，最终决定将应用进行服务划分。
分为三类
- 免费+专业版
- 企业版
- 企业pro+版
通过服务划分与预警来提升稳定性
A类用户（企业PRO）、B类用户（企业）、C类用户（专业+免费），A、B 用户类用户稳定性直线上升，C类用户由于一个副本集有几百上千个应用，还是有可能出现瞬间爆发，这边内部加强了一些监控，以及形成一套标准的问题快速解决办法，整体稳定性也提高几倍。
稳定性一直是Baas 不能逃避的问题
为此Baas厂商开发好基础服务后，都在不断的在为此努力。毕竟没稳定性就没后续服务可言，用户都用不了了，人家也不可能应用一直放你这里，我们也在为此事业不断努力。
此文只代表个人观点，如有疑问可以留言或私信
评论 (0)