标签: BaaS

什么是Serverless?阿里云腾讯云都在发力「无服务器架构」

要说目前软件架构中热度十二分的话题,当属Serverless。

通常我们会将其翻译为“无服务器架构”。

尽管成天被称为“无服务器”,但该架构与传统架构不同,显然并不是真的不需要服务器。

而是选择将服务器等基础设施的管理“隐藏”起来,计算资源作为服务而不是作为服务器的概念出现。

兼具事件触发、短暂以及完全被第三方管理等多重属性,其中开发者只需关注业务逻辑即可。

那一年,也就是2012,TA首次出现在技术人的视野之中。

就在崭露头角之后的短短两年,号称云计算“3A巨头”之一的AWS,就于当年年底正式推出了Lambda 产品,标志着Serverless的商业化进程隆重被开启。

当时的Lambda曾被大家如此描述:这是一种计算服务,可以根据时间来运行用户的代码,无需关心底层的计算资源。

 

从2012年到2014年,Lambda着实不算早到。

但就像云计算PaaS初出茅庐时的说法一样:用户只管业务就好,底层IaaS就交给我们吧!

Serverless与PaaS带给人们的理念是如此惊人的相似。

随后的两年时间内,Google Cloud Function 和微软 Azure Function 在技术圈子的成功,也就顺理成章将 Serverless推进了热化阶段。

从架构变迁聚焦Serverless内涵

对于众多开发者而言,显然仅仅知道“Serverless被定义为无服务器架构”的概念完全不够,如何将Serverless的理解更具象化一些?

恐怕还是要从软件应用架构演进的角度说起。

或许你可能了解,在十几年前,单体应用作为*主流的应用架构形式被广泛认可。

依靠一台服务器外加一个数据库,就能让服务可用性达到峰值状态。

但随着服务器老化性能下降甚至自身损坏的情况,再加上企业业务量的逐渐扩大,单体架构再也不是“一招鲜吃遍天”。

哪怕在流量入口加入负载均衡器,让单体应用可以部署在多台服务器上来增加弹性,也不能完全解决由代码无物理边界所带来的大量冲突。

至此,单体应用架构*次有机会进化成微服务架构,而此时的架构师们也就不得不直面分布式带来的新挑战。

例如那些年的缓存服务 Redis、状态协调服务ZooKeeper、消息服务 Kafka等。

我们可以简单理解为,将一个大系统划分为多个业务模块,其中的业务模块又需要分别部署在不同的服务器上,各个业务模块之间通过接口进行数据交互,这件事儿似乎没那么简单。

当然除了分布式环境的特殊性以外,微服务架构也给运维带来了不小改变。

具体实践中,由于微服务可以部署在不同的服务器上,也可以部署在相同的服务器却不同的容器上,包括应用分发标准、生命周期标准以及自动化弹性等能力在内的重要性也就一一凸显出来。

转眼到了众所周知的云原生时代,业务直接上云不说,还能提供标准化的应用托管服务,包括版本管理、发布、上线后的观测、自愈等,价值红利得到进一步彰显。

而此时Serverless也正迎着这波技术红利闯入了大众的视线,得到关注。

可以看出,在架构的演进中,无论是研发还是运维人员都逐渐将着眼点从机器向平台系统转移,而不是单纯用人去管理,这或许是对于Serverless原理*朴素的阐释。

总结一下,Serverless的出现其实是将主机管理、操作系统管理、资源分配等,甚至是应用逻辑全部组件都集成为服务。

如果将其放在当下的云计算场景中,就不能单纯狭义理解为“不用关心服务器”那么简单,毕竟上云的资源除了服务器之外,还涉及基础计算、存储资源、网络资源等诸多,也包括数据库、缓存以及消息队列等更上层的范畴。

Serverless架构类同FaaS,又做何解?

提及 Serverless,很多人的*反应都是 FaaS+BaaS。

的确,这是 Serverless的一种实现形式,也是一种比较主流的理解。

所谓“FaaS+BaaS ”,其实就是函数即服务与后端即服务的结合体。

具体来说,BaaS(Backend as a Service)可以被解释为“后端即服务”。

一般是API调用后端或别人已经实现好的程序逻辑,通常用来管理数据。

例如,亚马逊RDS可以替代自己部署的MySQL,当然其中还有各种其它数据库、中间件的作用。

FaaS(Functions as a Service)则是函数即服务,作为无服务器计算的一种形式,当前使用*广泛的当属AWS的Lambada。

经过长期实践我们认为,Serverless架构可以提供一种更加“代码碎片化”的软件架构范式,而所谓的“函数”(Function),则是提供相比微服务更加细小的程序单元。

进一步来说,究竟该如何理解“函数即服务”的概念?

大致上是开发者先将函数定义封装在容器中,通过调用函数来实现调用后端存储等服务。

本质上,FaaS是一种事件驱动的由消息触发的服务。

与传统的服务器端软件的不同,经应用程序部署到拥有操作系统的虚拟机或者容器中,一般需要长时间驻留在操作系统中运行。

而FaaS则可以直接将程序部署上到平台上,当有事件到来时触发执行,执行完了就可以消灭。

更重要的一点,FaaS产品不需要对特定框架或库进行编码。

还是以AWS Lambda函数为例,函数可以在Javascript、Python、Go等,也就是任何JVM语言(Java,Clojure,Scala等)或.NET语言中实现;但与此同时,Lambda函数还可执行与其部署工件捆绑在一起的另一个进程。

在FaaS环境中,用户将函数功能代码上传到FaaS提供商,其中对的水平扩展是完全自动弹性的。

而“函数”还可以代表客户所要执行的每个操作,即每个函数完成一个相对简单的业务逻辑,一个完整的应用由若干个函数组成,主要包括创建、读取、更新以及删除等。

 

目前,函数即服务(Function as a Service,FaaS)是当下Serverless实现的技术基础。

因为FaaS和Serverless之间关系密切,所以FaaS的特点也可以被认为是Serverless平台的特点,但如果单纯认为Serverless就是FaaS,就比较狭义了。

BaaS 时代仅仅以 API 的方式提供应用依赖的后端服务;而在 FaaS 时期,用户与开发者不再关注底层,这么说Serverless繁荣也是合理有据的事儿。

使用Serverless,也是一把双刃剑

据实际观察,一直以来企业使用 Serverless 通常会涉及几方面因素,其中“减少运营成本”被认为是*直观有效的原因之一。

的确,应用Serverless后,企业就无需再为潜在的流量高峰买进大部分时间都可能空闲的服务器机架,而是根据流量进行自动伸缩,采用按请求量来付费的灵活方式。

此外“自动按需扩展”可以发挥到*致:随时扩展到当前的使用量,消除了意外或者季节性流量高峰的困扰。

更重要的是,Serverless 不需要关心内存泄露,还具备将云数据库、云消息队列等服务囊括在内的完善配套设施,*大减少工作量。

哪怕企业中大部分的开发人员都出身软件,对修复保护以及管理并不擅长,一样可以做到专注软件开发,Serverless*对没问题。

基于此,一直以来国内外都有很多企业致力于提供基于Serverless 框架的能力服务,接受程度更是水涨船高,简单盘点下,尤其是几家大型的公有云厂商。

例如里程碑式的AWS Lambda。

作为AWS针对Serverless架构推出的FaaS云服务,AWS Lambda自2014年上线以后就受到广泛关注,除了满足大家对Serverless的期望之外,更重要的是AWS平台的成功。

AWS Lambda的优势可以简单总结为:

成熟度高:*个在主流公有云平台上的Serverless FaaS平台,已经有数年的发展和沉淀用户基数大:AWS Lambda有较大的用户基数,参考案例很多活跃的社区:目前开源社区有很多围绕AWS Lambda展开的开源项目AWS的整合:AWS Lambda天然和AWS平台上的服务有良好集成紧随其后,Microsoft Azure也在2016年推出了事件驱动的函数式云计算服务Azure Functions。

其支持用户以多种语言进行函数开发,包括Java、Node.js、PHP、C#、F#、Bash及Microsoft Windows的PowerShell脚本等。

此外,Azure Functions除了提供公有云的版本之外,还提供私有化(On-premises)部署的版本Azure Functions Runtime。

产品功能也是可圈可点:

完整性:Azure Functions是一个功能比较完备的Serverless FaaS平台整合:Azure Functions天然与Azure云平台上各类服务有良好的集成平台:对于使用微软体系产品和工具构建IT能力的企业而言,Azure Functions是Serverless转型的首选平台私有化:提供带有商业支持的私有化部署版本,可满足不同层面的用户的需求同样是在2016年,Google Cloud Platform推出了Google Cloud Functions平台,也同时加入Serverless领域的竞争序列。

同为FaaS平台,Google Cloud Functions与AWS Lambda和Microsoft Azure在功能上*大的区别有啥?

细数以后,可能在于Google Cloud Functions目前仅支持JavaScript作为函数开发语言,运行环境为Node.js。

2018年7月,Google又顺势公布了开源项目Knative,定位为Kubernetes的Serverless插件,推出后得到了Pivotal、IBM以及Red Hat的大力支持。

国外争先恐后,国内也是蜂拥而至。阿里云作为国内*批推出Serverless平台的公有云厂商,其FaaS平台产品被称为阿里云函数计算。

如果从事件触发、支持语言以及用户体验等方面考量,该产品也有很多数据值得关注:

事件触发:阿里云函数计算可以被阿里云上的服务事件触发,例如阿里云对象存储(OSS)支持语言:阿里云函数计算目前支持的开发语言为Node.js,并计划后续将支持Java及Python整个函数代码的部署包大小不能超过50MB,部署包解压后的代码不能超过250MB用户体验:阿里云函数计算提供了基于Web的控制台和SDK;用户可以通过Web控制台管理函数应用,也可以通过交互式的命令行来操作服务规格:一个服务下*多包含50个函数和10个触发器。在运行时,函数*长的运行时间为300s,即5min,一个函数的*大并发数为100同为国内云计算竞争的翘楚,无服务器云函数(Serverless Cloud Function,SCF)是腾讯云推出的函数式计算平台,根据官方的资料,其发布时间是2017年4月26日。

 

总结下腾讯云Serverless平台的特点:

函数运行时:腾讯云SCF目前支持Python、Java及Node.js作为函数的开发语言用户可以以压缩包的形式从本地上传代码,也可以引用腾讯云对象存储中的代码文件事件触发:目前腾讯云SCF支持的事件触发源有腾讯云对象存储COS、定时器、腾讯云消息服务CMQ,以及用户手动通过API及控制台触发服务规格:每个函数将在一个基于CentOS Linux的环境中被执行。函数执行的内存范围为128MB至1536MB,单个区域支持的*大函数定义数量为20个,函数执行的*大时长为300秒,*大的并发数为5以上我们探讨的基本是大型公有云服务商针对Serverless的技术实践。

其实与公有云相比,在私有环境中构建Serverless平台,在技术上并没有什么太多障碍,自然也有不少*的技术尝试,对于此我们会专门成文详细探讨。

可以发现,哪怕是拥有世界范围影响力的公有云服务商针对Serverless的技术探究似乎也出现了缺乏统一认知以及相应标准,无法适应所有的云平台的情况,例如支持的开发语言不同,事件触发的机制有差异等。

毕竟Serverless从来都不是一款产品,也不是一个工具,而是一整套能力的合集。

甚至在实践中还会出现业务轻量化困难、难以在秒级甚至毫秒级别扩容出业务实例;基础设施响应能力不足导致服务发现和日志监控系统等问题。

进而带来大量其他web服务器托管提供商可能会倒闭,很多SaaS平台受到冲击以及运维和实施人员的生存空间进一步缩小等行业现象。

但不容规避的一点,Serverless 架构的兴起使“去服务器化”真正造福了开发者,让基础设施管理出现了新契机。

随着技术上对去中心化以及轻量虚拟化的需求越发强烈,这种“全云化”的模式似乎预示着真正的云时代正在到来,不是吗?
————————————————

看懂 Serverless,这一篇就够了

1. 无服务器(Serverless)计算是什么

%title插图%num

云计算涌现出很多改变传统IT架构和运维方式的新技术,比如虚拟机、容器、微服务,无论这些技术应用在哪些场景,降低成本、提升效率是云服务永恒的主题。

过去十年来,我们已经把应用和环境中很多通用的部分变成了服务。Serverless的出现,带来了跨越式变革。Serverless把主机管理、操作系统管理、资源分配、扩容,甚至是应用逻辑的全部组件都外包出去,把它们看作某种形式的商品——厂商提供服务,我们掏钱购买。

过去是“构建一个框架运行在一台服务器上,对多个事件进行响应”,Serverless则变为“构建或使用一个微服务或微功能来响应一个事件”,做到当访问时,调入相关资源开始运行,运行完成后,卸载所有开销,真正做到按需按次计费。这是云计算向纵深发展的一种自然而然的过程。

Serverless是一种构建和管理基于微服务架构的完整流程,允许你在服务部署级别而不是服务器部署级别来管理你的应用部署。它与传统架构的不同之处在于,完全由第三方管理,由事件触发,存在于无状态(Stateless)、暂存(可能只存在于一次调用的过程中)计算容器内。构建无服务器应用程序意味着开发者可以专注在产品代码上,而无须管理和操作云端或本地的服务器或运行时。Serverless真正做到了部署应用无需涉及基础设施的建设,自动构建、部署和启动服务。

国内外的各大云厂商 Amazon、微软、Google、IBM、阿里云、腾讯云、华为云相继推出Serverless产品,Serverless也从概念、愿景逐步走向落地,在各企业、公司应用开来。

2. 理解Serverless技术—FaaS和BaaS

Serverless由开发者实现的服务端逻辑运行在无状态的计算容器中,它由事件触发, 完全被第三方管理,其业务层面的状态则被开发者使用的数据库和存储资源所记录。Serverless涵盖了很多技术,分为两类:FaaS和BaaS。

2.1 FaaS(Function as a Service,函数即服务)

FaaS意在无须自行管理服务器系统或自己的服务器应用程序,即可直接运行后端代码。其中所指的服务器应用程序,是该技术与容器和PaaS(平台即服务)等其他现代化架构*大的差异。

FaaS可以取代一些服务处理服务器(可能是物理计算机,但*对需要运行某种应用程序),这样不仅不需要自行供应服务器,也不需要全时运行应用程序。

FaaS产品不要求必须使用特定框架或库进行开发。在语言和环境方面,FaaS函数就是常规的应用程序。例如AWS Lambda的函数可以通过Javascript、Python以及任何JVM语言(Java、Clojure、Scala)等实现。然而Lambda函数也可以执行任何捆绑有所需部署构件的进程,因此可以使用任何语言,只要能编译为Unix进程即可。FaaS函数在架构方面确实存在一定的局限,尤其是在状态和执行时间方面。

在迁往FaaS的过程中,唯一需要修改的代码是“主方法/启动”代码,其中可能需要删除顶级消息处理程序的相关代码(“消息监听器接口”的实现),但这可能只需要更改方法签名即可。在FaaS的世界中,代码的其余所有部分(例如向数据库执行写入的代码)无须任何变化。

相比传统系统,部署方法会有较大变化 – 将代码上传至FaaS供应商,其他事情均可由供应商完成。目前这种方式通常意味着需要上传代码的全新定义(例如上传zip或JAR文件),随后调用一个专有API发起更新过程。

FaaS中的函数可以通过供应商定义的事件类型触发。对于亚马逊AWS,此类触发事件可以包括S3(文件)更新、时间(计划任务),以及加入消息总线的消息(例如Kinesis)。通常你的函数需要通过参数指定自己需要绑定到的事件源。

大部分供应商还允许函数作为对传入Http请求的响应来触发,通常这类请求来自某种该类型的API网关(例如AWS API网关、Webtask)。

2.2 BaaS(Backend as a Service,后端即服务)

BaaS(Backend as a Service,后端即服务)是指我们不再编写或管理所有服务端组件,可以使用领域通用的远程组件(而不是进程内的库)来提供服务。理解BaaS,需要搞清楚它与PaaS的区别。

首先BaaS并非PaaS,它们的区别在于:PaaS需要参与应用的生命周期管理,BaaS则仅仅提供应用依赖的第三方服务。典型的PaaS平台需要提供手段让开发者部署和配置应用,例如自动将应用部署到Tomcat容器中,并管理应用的生命周期。BaaS不包含这些内容,BaaS只以API的方式提供应用依赖的后端服务,例如数据库和对象存储。BaaS可以是公共云服务商提供的,也可以是第三方厂商提供的。其次从功能上讲,BaaS可以看作PaaS的一个子集,即提供第三方依赖组件的部分。

BaaS服务还允许我们依赖其他人已经实现的应用逻辑。对于这点,认证就是一个很好的例子。很多应用都要自己编写实现注册、登录、密码管理等逻辑的代码,而对于不同的应用这些代码往往大同小异。完全可以把这些重复性的工作提取出来,再做成外部服务,而这正是Auth0和Amazon Cognito等产品的目标。它们能实现全面的认证和用户管理,开发团队再也不用自己编写或者管理实现这些功能的代码。

3. 无服务器(Serverless)计算如何工作?

与使用虚拟机或一些底层的技术来部署和管理应用程序相比,无服务器计算提供了一种更高级别的抽象。因为它们有不同的抽象和“触发器”的集合。

拿计算来讲,这种抽象有一个特定函数和抽象的触发器,它通常是一个事件。以数据库为例,这种抽象也许是一个表,而触发器相当于表的查询或搜索,或者通过在表中做一些事情而生成的事件。

比如一款手机游戏,允许用户在不同的平台上为全球顶级玩家使用高分数表。当请求此信息时,请求从应用程序到API接口。API接口或许会触发AWS的Lambda函数,或者无服务器函数,这些函数再从数据库表中获取到数据流,返回包含前五名分数的一定格式的数据。

一旦构建完成,应用程序的功能就可以在基于移动和基于 Web 的游戏版本中重用。

这跟设置服务器不同,不是必须要有Amazon EC2实例或服务器,然后等待请求。环境由事件触发,而响应事件所需的逻辑只在响应时执行。这意味着,运行函数的资源只有在函数运行时被创建,产生一种非常高效的方法来构建应用程序。

4. 无服务器(Serverless)适用于哪些场景?

%title插图%num

在现阶段,Serverless主要应用在以下几个场景。首先在Web及移动端服务中,可以整合API网关和Serverles服务构建Web及移动后端,帮助开发者构建可弹性扩展、高可用的移动或 Web后端应用服务。在IoT场景下可高效的处理实时流数据,由设备产生海量的实时信息流数据,通过Serverles服务分类处理并写入后端处理。另外在实时媒体资讯内容处理场景里,用户上传的音视频到对象存储OBS,通过上传事件触发多个函数,分别完成高清转码、音频转码等功能,满足用户对实时性和并发能力的高要求。无服务器计算还适合于任何事件驱动的各种不同的用例,这包括物联网,移动应用,基于网络的应用程序和聊天机器人等。这里简单说两个场景,方便大家思考。

4.1 场景一:应用负载有显著的波峰波谷

Serverless 应用成功与否的评判标准并不是公司规模的大小,而是其业务背后的具体技术问题,比如业务波峰波谷明显,如何实现削峰填谷。一个公司的业务负载具有波峰波谷时,机器资源要按照峰值需求预估;而在波谷时期机器利用率则明显下降,因为不能进行资源复用而导致浪费。

业界普遍共识是,当自有机器的利用率小于 30%,使用 Serverless 后会有显著的效率提升。对于云服务厂商,在具备了足够多的用户之后,各种波峰波谷叠加后平稳化,聚合之后资源复用性更高。比如,外卖企业负载高峰是在用餐时期,安防行业的负载高峰则是夜间,这是受各个企业业务定位所限的;而对于一个成熟的云服务厂商,如果其平台足够大,用户足够多,是不应该有明显的波峰波谷现象的。

4.2 场景二:典型用例 – 基于事件的数据处理

视频处理的后端系统,常见功能需求如下:视频转码、抽取数据、人脸识别等,这些均为通用计算任务,可由函数计算执行。

开发者需要自己写出实现逻辑,再将任务按照控制流连接起来,每个任务的具体执行由云厂商来负责。如此,开发变得更便捷,并且构建的系统天然高可用、实时弹性伸缩,用户不需要关心机器层面问题。

5. Serverless 的问题

对于企业来说,支持Serverless计算的平台可以节省大量时间和成本,同时可以释放员工,让开发者得以开展更有价值的工作,而不是管理基础设施。另一方面可以提高敏捷度,更快速地推出新应用和新服务,进而提高客户满意度。但是Serverless不是完美的,它也存在一些问题,需要慎重应用在生产环境。

5.1 不适合长时间运行应用

Serverless 在请求到来时才运行。这意味着,当应用不运行的时候就会进入 “休眠状态”,下次当请求来临时,应用将会需要一个启动时间,即冷启动时间。如果你的应用需要一直长期不间断的运行、处理大量的请求,那么你可能就不适合采用 Serverless 架构。如果你通过 CRON 的方式或者 CloudWatch 来定期唤醒应用,又会比较消耗资源。这就需要我们对它做优化,如果频繁调用,这个资源将会常驻内存,*次冷启之后,就可以一直服务,直到一段时间内没有新的调用请求进来,则会转入“休眠”状态,甚至被回收,从而不消耗任何资源。

5.2 完全依赖于第三方服务

当你所在的企业云环境已经有大量的基础设施的时候,Serverless 对于你来说,并不是一个好东西。当我们采用某云服务厂商的 Serverless 架构时,我们就和该服务供应商绑定了,那么我们再将服务迁到别的云服务商上就没有那么容易了。

我们需要修改一下系列的底层代码,能采取的应对方案,便是建立隔离层。这意味着,在设计应用的时候,就需要隔离 API 网关、隔离数据库层,考虑到市面上还没有成熟的 ORM 工具,让你既支持Firebase,又支持 DynamoDB等等。这些也将带给我们一些额外的成本,可能带来的问题会比解决的问题多。

5.3 缺乏调试和开发工具

当我使用 Serverless Framework 的时候,遇到了这样的问题:缺乏调试和开发工具。后来,我发现了 serverless-offline、dynamodb-local 等一系列插件之后,问题有一些改善。然而,对于日志系统来说,这仍然是一个艰巨的挑战。

每次你调试的时候,你需要一遍又一遍地上传代码。而每次上传的时候,你就好像是在部署服务器,并不能总是快速地定位出问题在哪。后来,找了一个类似于 log4j 这样的可以分级别记录日志的 Node.js 库 winston。它可以支持 error、warn、info、verbose、debug、silly 六个不同级别的日志,再结合大数据进行日志分析过滤,才能快速定位问题。

5.4 构建复杂

Serverless 很便宜,但是这并不意味着它很简单。AWS Lambda的 CloudFormation配置是如此的复杂,并且难以阅读及编写(JSON 格式),虽然CloudFomation提供了Template模板,但想要使用它的话,需要创建一个Stack,在Stack中指定你要使用的Template,然后aws才会按照Template中的定义来创建及初始化资源。

而Serverless Framework的配置更加简单,采用的是 YAML 格式。在部署的时候,Serverless Framework 会根据我们的配置生成 CloudFormation 配置。然而这也并非是一个真正用于生产的配置,真实的应用场景远远比这复杂。

6. 总结

云计算经过这么多年的发展,逐渐进化到用户仅需关注业务和所需的资源。比如,通过K8S这类编排工具,用户只要关注自己的计算和需要的资源(CPU、内存等)就行了,不需要操心到机器这一层。

Serverless架构让人们不再操心运行所需的资源,只需关注自己的业务逻辑,并且为实际消耗的资源付费。可以说,随着Serverless架构的兴起,真正的云计算时代才算到来了。

任何新概念新技术的落地,本质上都是要和具体业务去结合,去真正解决具体问题。虽然Serverless很多地方不成熟,亟待完善。不过Serverless自身的优越特性,对于开发者来说,吸引力是巨大的。相信随着技术的飞速发展,Serverless在未来还有无限可能!

友情链接: SITEMAP | 旋风加速器官网 | 旋风软件中心 | textarea | 黑洞加速器 | jiaohess | 老王加速器 | 烧饼哥加速器 | 小蓝鸟 | tiktok加速器 | 旋风加速度器 | 旋风加速 | quickq加速器 | 飞驰加速器 | 飞鸟加速器 | 狗急加速器 | hammer加速器 | trafficace | 原子加速器 | 葫芦加速器 | 麦旋风 | 油管加速器 | anycastly | INS加速器 | INS加速器免费版 | 免费vqn加速外网 | 旋风加速器 | 快橙加速器 | 啊哈加速器 | 迷雾通 | 优途加速器 | 海外播 | 坚果加速器 | 海外vqn加速 | 蘑菇加速器 | 毛豆加速器 | 接码平台 | 接码S | 西柚加速器 | 快柠檬加速器 | 黑洞加速 | falemon | 快橙加速器 | anycast加速器 | ibaidu | moneytreeblog | 坚果加速器 | 派币加速器 | 飞鸟加速器 | 毛豆APP | PIKPAK | 安卓vqn免费 | 一元机场加速器 | 一元机场 | 老王加速器 | 黑洞加速器 | 白石山 | 小牛加速器 | 黑洞加速 | 迷雾通官网 | 迷雾通 | 迷雾通加速器 | 十大免费加速神器 | 猎豹加速器 | 蚂蚁加速器 | 坚果加速器 | 黑洞加速 | 银河加速器 | 猎豹加速器 | 海鸥加速器 | 芒果加速器 | 小牛加速器 | 极光加速器 | 黑洞加速 | movabletype中文网 | 猎豹加速器官网 | 烧饼哥加速器官网 | 旋风加速器度器 | 哔咔漫画 | PicACG | 雷霆加速