发生了因存储集群故障而致服务瘫痪,重新设计的 API在 v3 中我们改进的重点是 SDK

by admin on 2020年3月22日

摘要4月22日即时通讯云 LeanCloud
发生了因存储集群故障而致服务瘫痪,从事故原因中可以想够用的出目前LeanCloud这类即时通讯云厂商所面临的各种挑战。前言4月22日即时通讯云
LeanCloud
发生了因存储集群故障而致服务瘫痪,从事故原因中可以想象的出目前LeanCloud这类即时通讯云厂商所面临的各种挑战:当用户量持续增大,所面临的各种因大并发、高服务需求问题,时常导致整体服务品质的下降,这也侧面反映出,要做出可靠的云即时通讯服务,在没有现成方案可用的情况下,各厂商要走的路显然还很长。以下是官方事故通报情况2016
年 4 月 22 日 13:04 开始,LeanCloud
中国节点的后端存储集群出现问题,导致该节点上所有应用都出现了存储 API
访问故障,将近半小时后得到恢复。故障的详细经过通报如下。故障时间13:09-13:28
所有应用的数据存储服务都出现访问异常(持续 19 分钟)13:28-13:40
大部分应用已经恢复,但还有 20% 的应用依然无法正常访问(持续 12
分钟)影响范围中国节点上所有应用的存储服务都受到影响,同时依赖于数据存储的实时通信、云引擎服务也可能出现内部错误。美国节点不受影响,所有服务均工作正常。事故经过13:04
我们监控系统陆续发出报警,后端存储集群访问超时慢慢增多,工程师介入调查,并向用户发出了短信和邮件通知。13:10
整个集群的存储 API Server
不再响应外部请求。调查后确认是后端存储系统在做大量耗时的关系数据写入操作,导致系统失去响应。于是我们马上重启集群,并分批开放流量。13:28
部分存储分片(shard)得到恢复,80%
的应用访问恢复正常;发送第二次故障进度通知。13:40
所有应用恢复正常;发送故障解决通知。后续改进措施这一次故障的根本原因在于
AVRelation
模型的底层实现存在缺陷,某些特殊条件下会导致后端存储系统因忙于处理而失去响应。我们已完成替代方案的开发,正在测试中,下周会发布更合理的解决方案。(4
月 27
日周三完成)改进并发限制的算法,以便在异常条件下更好地限制故障的影响范围。(4
月 25
日周一完成)排查所有危险/耗时操作,在上层进行写入控制,避免对后端存储系统造成太大影响。(4
月 25 日周一完成)LeanCloud官网访问以下地址即可:leancloud.cn

摘要针对近期的服务稳定性问题,即时通讯云服务端LeanCloud进行相关优化,并在接下来的服务过程中启用改进和即时通讯云计费方式。以下为来自即时通讯云
LeanCloud官方的消息:LeanCloud
近期经历了比以往更频繁的稳定性方面的事故,其中有的是因为容量规划上的不足导致服务收到异常流量影响,有的是对上游服务商的域名攻击,有的是针对
LeanCloud 的 DDoS 攻击。LeanCloud
一直将服务的稳定性视为生命线,每次事故之后,都会严肃地总结并明确改进方案。我们也会把事故报告发布到博客上,确保用户们知晓事故原因和过程,以及后续我们要执行的改进措施。为让用户了解我们为此所做出的努力,我们想向大家通报一下在改进措施方面的进展。已经完成的改进措施有:为应对将来可能出现的上游服务商域名被攻击的情况,实现更灵活的域名动态切换,以便在必要时及时切换至其他域名,保证云服务对外服务的可用。完善应对
DDoS
攻击的策略和措施,把受攻击后恢复服务的时间缩短到分钟级。事故公告流程增加了短信通知渠道,确保开发者及时收到信息。(我们在最近的
DDoS
攻击的几十分钟内一共给所有用户发送了三次短信及时更新进展)。正在进行的措施有:增加新的监控措施,对前端网络入包量进行监控,防止网络转发量超过
VM 能力限制。调整前端 VM
配置,使用高包量机型,增大处理能力。改进前端服务器扩容方式,使用 docker
镜像来加快新节点部署上线的进度。API
服务对外增加多路备选域名,降低针对域名的攻击造成的影响。除了技术上的改进外,我们也对计费方式中的不合理之处进行了重新思考。过去我们的存储和即时通讯实时消息服务都是按照一个月的总使用量来计费的,这样造成了一些问题。比如如果一个应用在一个月里发生了
10 亿次 API
调用,我们并不区分这些调用是平均分布在整个月,还是集中在少数几天。而这两种情况对容量规划的要求是非常不同的,如果不做区分,就容易造成资源上的分配不及时,给运维工作造成风险和压力。另外由于存储和即时通讯实时消息是按月后付费,LeanEngine、LeanCache、短信是实时扣费,不同的计费周期和方式给很多用户造成了财务流程上的困扰。所以我们将把所有服务调整为一致的实时扣费的模式,并且存储和即时通讯实时消息服务将调整为按每天用户设定的容量上限收费,其中数据存储的计费依据将是并发请求数的上限,即时通讯实时消息服务的计费依据将是当日使用服务的用户数上限。这样用户可以自己调整预留的资源,确保满足需求。由于计费周期缩短到天,也能满足只在特定日期有超高流量的应用兼顾较低的预算和充足的资源。具体的方案和数字我们还在制定,会在第一时间与用户沟通。同时我们也会确保老用户有平滑的过渡体验。LeanCloud官方地址:

摘要即时通讯云 LeanCloud 下一代 JavaScript 即时通讯 SDK 的 3.0 beta
版本发布了!以下为来自即时通讯云 LeanCloud官方的消息:今天我们高兴地宣布
LeanCloud 下一代 JavaScript 实时通讯 SDK 的 3.0 beta
版本发布了!我们不仅为这一新版本(以下简称
v3)带来了性能提升,还加入了很多令人激动的新功能和改进,包括单点登录、未读消息通知、按条件查询对话、自动更新的对话和消息状态、自定义消息类型、更好的断线重连机制,以及重新设计的
API 等等。重新设计的 API在 v3 中我们改进的重点是 SDK
的易用性,为此我们设计了全新的
API。除了一些细小的命名与特性的区别,JavaScript SDK v3 的 API 与其他平台
SDK 的 API
已经统一。随着平台差异性的减少,开发者在为各平台应用设计与实现阶段所投入的工作量也会降低。相较于
v2,v3 API
对易用性的改进体现在以下几个方面:自动更新的对话和消息状态Promise
与异常处理新的事件模型可扩展的消息类型系统自动更新的状态v2
中封装了各种操作指令与事件,但是在真实的项目中,你仍然需要额外维护一些状态,这些状态包括了:对话:成员列表、未读消息数、最后消息时间、最后消息(如果有)消息:发送状态v3
中这些状态都会由 SDK
自动更新。这将大大简化业务逻辑的代码,比如当你使用类 MV*
框架时,你可以直接将这些实例与 View 层绑定,就像下面这个使用 Angular
展示消息列表的例子一样:<ul class=”list-group”> <li
class=”list-group-item” ng-repeat=”conversation in conversations”>
<span class=”badge”>{{conversation.unreadMessagesCount}}Live
demo:
与异常处理所有的异步 API 将返回 Promise 实例。相比于 v2
中回调的方式,Promise 将会避免回调嵌套过深的问题,同时解决了 v2
异步操作异常被 SDK 隐藏的问题。// 使用 Promise
以链式方法登录、创建会话、发送消息realtime
.createIMClient(‘three-bodies’) .then(tom => tom.createConversation({
member: [‘the-earth’] })) .then(conversation =>
conversation.send(new TextMessage(‘不要回答!’)) .then(message => {
/* 成功 */ }) .catch(error => { /* 处理异常 */ });新的事件模型v3
中的事件 API 使用的依然是 Node.js 中EventEmitter的设计。与 v2
中所有事件都在RealtimeObject上派发不同,v3
中不同类型的事件会在不同的层面派发:网络状态相关的事件在Realtime实例上派发。某个客户端相关的事件在该IMClient实例上派发。某个对话相关的事件在该Conversation实例上派发,同时也会在其隶属的IMClient实例上派发。详细的事件列表与描述,请参阅API
文档的 Events
部分。可扩展的消息类型系统自定义一个消息类型从来没有像现在这么简单:@AV.messageType(3)@AV.messageField(‘foo’)class
CustomMessage extends AV.TypedMessage { constructor(foo) { super();
this.foo = foo; }}Live
demo:
TypeScript 或者 Babel 才能运行。这里还有个ES5 的例子。同时,基于
LeanCloud 存储服务,SDK
还提供了常见的富媒体消息类型(文件、图片、视频、音频、位置)。为了避免实时通讯
SDK 与存储 SDK 的耦合,这些富媒体消息类型是一个独立发布的
package,关于富媒体消息的详细内容请参阅《JavaScript 实时通信开发指南 –
富媒体消息》。新增功能JavaScript 的 API 与其他平台 SDK 的 API
的统一意味着以下功能已得到支持:单点登录「未读消息通知」模式对话条件查询构造器(ConversationQuery)断线重连机制SDK
的连接层也被重新设计,断线重连机制变得更加可靠,存在于 v2 中的 crash
与漏报已被消除。除了disconnect与reconnect,v3
中增加了两个新事件schedule与retry,通过它们你就可以了解到 SDK
在断线重连的过程中正在做什么,进而向用户给出更友好的提示。关于断线重连机制的细节请参阅《JavaScript
实时通信开发指南 – 网络状态响应》。性能提升v3
还包含了一些底层上的改进:二进制协议 ProtoBuf
的引入使传输消息时的流量消耗减少了 70%。多个 Client
实例共享一个长连接的措施减少了 SDK 消耗的资源。从 v2 升级v3 API 不兼容
v2。对于正在使用 v2 的用户,尽管 v2 中所有的 API 在 v3
中有对应的实现(参见《JavaScript 实时通信 SDK v3
迁移指南》),我们仍然需要提醒,迁移到 v3
意味着一定的迁移成本。此外,必须指出的是,v3 去掉了对 IE10
及以前版本的支持,如果需要兼容这部分运行环境,请继续使用 v2。在 v3
正式发布后,v2 依然会得到至少 6
个月的安全更新。LeanCloud官网

相关文章

发表评论

电子邮件地址不会被公开。 必填项已用*标注

网站地图xml地图