http://www.ox-holdings.com

于是很快便定位到某一集群由于突发硬件故障而引起存储服务中断,使用更接近业务和应用层面的云服务来开发产品

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

在这次事故中没有发生服务器端数据的丢失或损坏。

摘要即时通讯云服务商LeanCloud 2016年7月13日因由于突发硬件故障,导致雪崩致使即时通讯服务瘫痪48分钟之久!以下消息来自LeanCloud官方:7 月 13 日早上 9 点左右,我们内部在使用中国节点的应用控制台时遇到报错,于是很快便定位到某一集群由于突发硬件故障而引起存储服务中断,经过抢修问题得以解决。大约一小时后正当我们在继续对该集群进行加固处理时,突然遇到流量高峰,该集群的性能逐渐下降并再次发生了故障。此次故障影响到中国节点上 20% 的应用无法使用存储及其依赖服务,如实时通信、云引擎等。美国节点不受影响。故障时间及范围08:49

具体使用 LeanCloud

来举个具体例子。在 LeanCloud 中想要实现一套账号系统共分为三步:注册账号、创建一个应用、下载对应的 SDK。就这三步?难道不用写代码吗?是的,不用写代码你其实已经拥有了一套支持 ACL(访问权限控制)、支持短信验证注册、支持邮件注册这样具备完整安全体系的账号系统,客户端工程师只需直接使用即可。例如,Web 前端通过 JavaScript SDK 在浏览器使用账户系统,具体代码如下:

// 创建一个实例
const user = new AV.User();
// 设置用户名
user.set('username', 'wangxiao');
// 设置密码
user.set('password', 123456789);
// 注册
user.signUp().then(user => {
  // 注册成功
}, error => {
  // 注册失败
});

再如经常被使用的短信验证功能,你不需要去找服务端工程师去开发一个专用接口,而是直接在浏览器中调用 JavaScript SDK 的方法(支持模板来定制短信内容),具体代码如下:

// 发送手机验证码
AV.Cloud.requestSmsCode({
  mobilePhoneNumber: '182xxxx5548'
}).then(() => {
  // 发送成功
}, error => {
  // 发送失败
});

// 校验验证码
AV.Cloud.verifySmsCode('1234', '182xxxx5548')
.then(() => {
  // 验证成功
}, error => {
  // 验证失败
});

// 短信模板
AV.Cloud.requestSmsCode({
  mobilePhoneNumber: '182xxxx5548',
  template: 'Template_Name',
  ttttName: '自定义模板变量名'
}).then(() => {
  // 发送成功
}, error => {
  // 发送失败
});

短信验证仅仅是 LeanCloud 所开放的众多功能中的一项,你还可以使用 SDK 轻松实现数据存储、文件存储(CDN)、推送、即时聊天等实用功能。如此以来你的开发效率会大幅提升,服务器端对于你来说完全是透明的,这样就能把所有精力集中到研发核心产品上去,而后续的数据运营和管理工作可以直接在 LeanCloud 的控制台中进行,甚至在初期你都不需要给运营人员编写一个对应的管理后台。

图片 1

控制台中的数据管理界面

摘要即时通讯云服务商LeanCloud 和 腾讯云团队经过数月的共同努力与紧密合作,为腾讯云用户打造的 腾讯云移动开发解决方案 正式发布了。以下消息来自LeeanCloud官方:我们很高兴地宣布 LeanCloud 和腾讯云团队经过数月的共同努力与紧密合作,为腾讯云用户打造的腾讯云移动开发解决方案正式发布了。该解决方案能够显著地降低开发难度和成本,加快移动应用、智能硬件、智能家居、SaaS 服务等各类产品的开发进程,大大缩短产品的上市时间(time-to-market)。腾讯云移动开发解决方案提供了数据存储、云引擎、实时通信、推送通知、数据统计等诸多服务,每项服务均在腾讯云的基础设施之上由 LeanCloud 的技术提供。使用更接近业务和应用层面的云服务来开发产品是大势所趋。随着 Apple 和 Google 分别在各自的生态圈大力推动 CloudKit 和 Firebase 的发展,AWS 也推出了 Lambda 和 API Gateway 等更高层的服务以顺应无服务器架构(Serverless Architecture)的发展趋势。LeanCloud 是这个领域起步最早的实践者之一,已经支撑了近十万个应用、网站、游戏和硬件产品,LeanCloud 美国节点正式发布仅仅数月,也已经为出海的中国科技公司带来了实际的价值和便利。越来越多的产品不再选择从服务器开始从零构建自己的线上能力,而是使用 LeanCloud 这样更贴近业务和场景的服务让产品尽快面市,并在快速迭代中拉开与竞争对手的距离。通过与腾讯云的合作,我们可以把 LeanCloud 的各项服务以及 LeanCloud 所代表的更高效的产品开发方式带给更多的用户。我们也期待在未来能够进一步与腾讯云在基础设施和网络资源方面开展合作,为用户提供更好的产品和服务。腾讯云移动开发解决方案与 LeanCloud 保持基本一致的价格体系,服务于腾讯云用户体系,并使用腾讯云的账号和财务系统。LeanCloud 主站将不受这次合作影响,所有账号、应用和数据都仅存放于 LeanCloud 的自有服务器。我们理解此次合作可能会为 LeanCloud 的用户及关注者带来一些疑虑,因此有必要在此进行说明。LeanCloud 是一个中立、独立的云服务平台,与任何第三方的合作都以此为基础。LeanCloud 注重保护数据隐私和安全、维护用户利益的原则和价值观也被我们的合作伙伴和用户所认同。LeanCloud官网:

LeanCloud 的多项服务在六月六日周六下午发生了大约四个小时的中断或不稳定。其中 16:10 到 19:09 为故障阶段;19:09 到 20:17 为限流恢复阶段。

  • 09:08:存储服务内部某一集群发生硬件故障,导致 20% 的应用的存储服务中断(约 19 分钟)。09:53 - 10:22:该集群受到流量冲击后性能降低并再次瘫痪(约 29 分钟)。前后共持续约 48 分钟。事故过程08:49:应用控制台出现报错,立即进行排查。08:56:发现某个集群硬件故障,导致集群性能不断降低,响应过于缓慢,到几乎不可用。09:08:隔离故障机器,重启相关服务后,集群慢慢恢复了正常。09:53:有大量连接涌入,堵塞了存储系统的读写队列,使得该集群性能再次下降。09:58:该集群响应过于缓慢,几乎不可用。开始阻断连接,扩充集群并重启集群上的相关服务。10:22:集群服务逐步恢复,并重新开放连接。后续改进措施加强对集群硬件失败的监控和报警。提高自动化故障处理能力,降低系统 downtime 时间。尽快升级底层存储系统的存储引擎,减少读写队列拥塞的可能性,进一步提升服务性能。LeanCloud官方地址:

不是很了解 LeanCloud(LeanCloud)的开发者经常会问「LeanCloud 与已有的很多云服务有什么区别呢?」下面我们就以国内比较有代表性的阿里云为例,跟 LeanCloud 做下对比。

改进措施更新 MongoDB 节点内存报警值,预留更多响应时间。(已完成)在 MongoDB 节点暂停使用 mesos-slave。(已完成)设置各服务 OOM 优先级,意外情况发生导致剩余内存不够时重启低优先级服务以保护高优先级服务。(已完成)MongoDB 集群增加硬件资源。拆分 MongoDB 集群为多个小集群,降低单个集群里的数据库数量。这也让我们可以对 MongoDB 进行滚动升级,降低风险。在重要系统升级前进行更多事故恢复的测试,并以滚动方式在较长时间内逐步完成升级。降低 MongoDB 启动时间。进行阶段性的 MongoDB 压测及故障恢复模拟。status.leancloud.cn 从主站拆分,让用户得到更准确的故障信息。改进 API 服务线程池分配机制,避免因为一个 MongoDB shard 异常而堵塞线程池。改进 API 服务流量控制,紧急情况时做到可以仅切断对应特定 MongoDB shard 的请求。在发生线上事故时,我们将在 Blog 上开通直播贴,实时向用户通报进展。结语

产品的区别

进入阿里云网站可以看到阿里云的产品介绍。产品列表有弹性计算、数据库、存储与 CDN、网络、大规模计算、云盾、管理与监控、应用服务、互联网中间件、移动服务、域名与网站等,每个选项下面又有非常多的子产品列表,提供的服务种类繁多。个人感觉几乎开发中需要使用的服务器产品,阿里云应该都提供了。这些产品更偏向于较底层的服务,用户要想使用起来需要具备一定的能力。

图片 2

阿里云官网部分截图

LeanCloud 则完全不同。它提供了四项产品,分别是 LeanStorage(数据、文件存储及云引擎)、LeanMessage(短信、推送及实时通讯服务)、LeanAnalytics(统计分析服务)、LeanModules(各种其他通用组件)。看起来很精简却有些抽象,那这些产品具体又能满足什么需求呢?

图片 3

为了更好地解释这次事故,我想先简单介绍一下 LeanCloud 的后端架构。以下是一个简化版的架构图。

概念上的区别

阿里云提供的是类似于 AWS(亚马逊的云服务)一样的传统云服务。使用了阿里云你就不用再去操心那些与硬件和底层运维相关的事情,比如硬盘损坏、主机托管、服务器配置网络等等。

但如果想要开发一个自己的 App,你仍然需要在阿里云上购买机器,选择部署到哪个机房,还要购买数据库,选择数据具体是怎样的规格,然后还要对这台机器进行完整的配置。虽然比没有云服务的日子已经轻松了许多,但这些操作仍然需要一个专业的工程师才能很好地完成。

而使用 LeanCloud 用户却不需要操心这些事情,可以说基本上不用考虑服务器的细节。

LeanCloud 提供的是 BaaS 服务(Backend as a Service 后端即服务),又被称为云服务 2.0。简而言之,云服务 1.0 解决的是不再让你担心服务器,而 BaaS 的目标是帮你解决全部服务器运维,甚至是部分后端业务逻辑。那 LeanCloud 究竟是怎么做到的呢?回答这个问题之前,我们看下一个 App 一般都是什么样子。

图片 4

以 LeanCloud 的用户「懂球帝」为参考,不论什么产品基本上都需要一套账号系统,目前较通用的做法是使用手机号码注册,发送短信验证;基于这个账号还要存储一些数据项,如昵称、头像等信息,再到真正的主业务逻辑,需要通过服务器基于某个逻辑运算出结果交给客户端做展示。

那么我们再考虑一个问题,为什么我们每次做一个产品都要反反复复地开发这些差不多一样的逻辑呢?比如账号系统、数据存储、短信验证、邮件验证、推送服务甚至是即时聊天,有没有办法让这些东西拿来就用,让自己能够最快速地投入开发呢?当然有办法,这就是 LeanCloud 所做的事情。

在 LeanCloud 的最前端,除了负载均衡之外就是 API 服务集群,也就是实现 RESTful API 的部分。客户端应用通过 SDK 或直接调用 API 和它通讯。根据请求的类型,API 服务再调用后端的各个系统完成所需的功能。比如如果是统计服务的请求,事件信息会被发送到统计服务并最终被保存到 HBase 集群;如果是数据存储服务的请求,那么 API 服务就会调用 MySQL 和 MongoDB 集群完成数据访问。因为 MongoDB 存储了每个应用的大部分数据,所以不少服务都需要从这里获取一些信息,是整个系统中很重要的组件。

成本的区别

选择传统的云服务,你可能需要更多地去了解服务端的结构,要综合考虑在云服务上搭建出一套自己的系统所付出的成本,还需要找到合适的工程师去维护这些服务,找到后端工程师来开发服务端很多通用的业务逻辑。

如果使用 LeanCloud 这些事情都不用去考虑,直接使用相应的服务即可。同时 LeanCloud 所提供的服务均按照使用量计费,并提供了一定额度的免费使用量,在初期用户量少的时候基本不会产生什么费用,只有当用户量增长到一定量级时才会产生相应的费用。总之使用 LeanCloud 不仅仅省去了后期运维的成本,还减少了后端工程师的工作量,加速产品迭代。

郑重声明:本文版权归新匍京a奥门-最全网站手机版app官方下载所有,转载文章仅为传播更多信息之目的,如作者信息标记有误,请第一时间联系我们修改或删除,多谢。