arron (青云QingCloud)

一个小攻略：如何最大化利用青云 QingCloud 特价机型

arron — Sat, 23 Jan 2021 19:45:59 +0800

最近青云 QingCloud 在搞特价促销，最便宜的一款主机（VM Instance）已经低至年费只需 89.9 元人民币，味千拉面现在都得 51 块一碗了…，买来之后可以做什么呢？有人搭博客、有人跑 Git、有人做测试，我这里提供一个思路，可以最大程度的榨取这款机器的价值，且解决工作与生活中的实际问题和需求。

从 2007 年逐渐兴起的移动互联网让我们每个人手头都有多款电子设备，比如我自己的日常设备：

Android Phone - 电话（随时）
iPad Pro - 移动办公辅助设备（差旅）
Mac Book Pro - 移动办公主力设备（差旅）
PC with Arch Linux - 固定办公设备（办公室或家）

还有更多人在使用 Windows 设备，由此可见日常工作和生活中我们跨设备之广。为了解决在这么多不同厂商、不同操作系统的设备之间保持数据同步及一致，大家条件反射会想到 Dropbox 和百度网盘，但是：

前者在墙外，翻墙是个强技术活儿、且也不适合用来做数据同步、花销高、还有额外 xx 风险…；
后者存在严重的隐私和用户数据安全问题；
如果你的数据比较多，免费版将无法支持的了，而付费，则将大大超过 89.9 元。

著名的开源项目 Nextcloud 可以很容易地完美解决此需求，而且因为是自部署（self-hosted），所以不存在隐私问题、免费版限制等问题。当然，Nextcloud 绝不仅仅是一个网盘和文件同步功能，通过其插件体系可以很容易实现一个完整的生产力平台。

以下操作使用的是一台位于广东 2 区的 Arch Linux 主机，你可以选择自己喜欢的 Region 和 Linux 分发版。创建主机我就不描述了，随着向导走即可。

1. 准备工作环境

1.1. EIP

主机创建完成之后，需要 EIP（弹性公网 IP 地址）连接互联网。在 Web Console 导航栏中进入 网络与 CDN -> 公网 IP，然后申请一个 IPv4 EIP，绑定到你的主机上即可。

1.2. Docker

修改 pacman 镜像源：

/etc/pacman.d/mirrorlist

Server = http://mirrors.tuna.tsinghua.edu.cn/archlinux/$repo/os/$arch

刷新操作系统：

pacman -Syyu
reboot

安装 Docker：

pacman -S docker

配置 Docker Daemon：

/etc/docker/daemon.json
{
    "experimental": true,
    "bridge": "none",
    "registry-mirrors": [
        "https://docker.mirrors.ustc.edu.cn/"
    ]
}

启动、启用 Docker：

systemctl start docker
systemctl enable docker

2. 运行 nextcloud

创建工作目录：

mkdir -p /srv/nextcloud/{server,data}

拉取最新稳定版、并启动 nextcloud server：

docker pull nextcloud:latest

docker run --name nextcloud --restart unless-stopped \ 
    -v /srv/nextcloud/server:/var/www/html \
    -v /srv/nextcloud/data:/var/www/html/data \
    --network host -d nextcloud:latest

然后打开浏览器，输入地址 http://your-eip-address，即可开始对 nextcloud server 进行初始化配置。该模版默认使用 TCP 80 端口，请记得去安全 -> 防火墙，确保 TCP 下行 80 端口为开启状态。

初始化配置很简单，只有三个项目：

在初始化界面里，创建的第一个用户拥有管理员权限；
保持 Storage & database 不变；
取消 (uncheck) Install recommended apps。

然后点击 Finish Setup，等待完成即可。

3. 优化 nextcloud

Nextcloud 是一个庞大的系统，可以调教优化的地方非常多，我这里仅仅指出两点比较适合小团体或个人使用的网盘及文件同步功能的优化，毕竟大家在促销时通常也是购买低配置的机型。

3.1. 禁止没啥用的 apps

使用上一步初始化时创建的 nextcloud 管理员账号登陆后，打开 apps 配置页，地址是 http://your-eip-address/settings/apps，禁用以下 apps：

Accessibility
Activity
Collaborative tags
Federation
First run wizard
Nextcloud announcements
Privacy
Recommendations
Support
Usage survey

3.2. cron job

Nextcloud 有一系列的工作是在后台工作的，新建以下两个配置文件：

/etc/systemd/system/nextcloud-cron.service

[Unit]
Description=Nextcloud cron.php job

[Service]
ExecStart=docker exec --user www-data nextcloud php -f /var/www/html/cron.php

/etc/systemd/system/nextcloud-cron.timer

[Unit]
Description=Run Nextcloud cron.php every 10 minutes

[Timer]
OnBootSec=5min
OnUnitActiveSec=10min
Unit=nextcloud-cron.service

[Install]
WantedBy=timers.target

启用、启动：

systemctl daemon-reload
systemctl enable nextcloud-cron.timer
systemctl start nextcloud-cron.timer

然后，以管理员账号登陆 nextcloud，进入 Settings -> Administration -> Basic settings -> Background jobs，选中 Cron 这个项目，即可。

4. nextcloud 客户端

Nextcloud 客户端支持市面上全部的操作系统，包括 Windows、Linux、Mac OS X、Android、iOS、iPadOS，从其官网或各移动应用市场均可下载安装。

5.（可选的）极致省钱操作

合理使用青云 QingCloud 的一些免费政策，花点儿技术配置时间，可以天长日久的极致省钱，以下举两个例子。

5.1. 使用 IPv6 EIP

若你的日常网络环境（办公室、家庭等）有 IPv6 支持的话，强烈建议在以上配置结束后使用 IPv6 的 EIP 地址替代 IPv4 的，因为青云 QingCloud IPv6 地址是免费的。目前在中国多数情况下，IPv6 是默认部署了的，以北京电信为例，其 ADSL 宽带和手机 4G 网络都已良好支持 IPv6，且局方默认均开启。

注意，由于 IPv6 地址无法直接在浏览器地址栏使用，所以必须使用 FQDN 域名解析到 IPv6 地址，青云 QingCloud 提供了免费的 DNS 权威解析服务，位于 Web Console 导航栏的 网络与 CDN -> DNS。

5.2. 使用对象存储

青云 QingCloud 的对象存储在 10GB 容量以内是免费的，而且跟位于同一 Region 的主机之间的流量是内网，速度稳定高速、且完全免费，在 Web Console 导航栏中进入存储 -> 对象存储，然后创建一个 bucket。

Nextcloud 可以支持 S3 对象存储作为 external storage，而青云 QingCloud 对象存储完全兼容兼容 S3 APIs，只需以下三步操作：

在管理员界面的 apps 里启用 External storage support。
在 Settings -> Administration -> External storages 中选中 All user to mount external storage、并确保 Amazon S3 是被选中的子项。
在 Settings -> Personal -> External storages 中选择 Amazon S3，然后输入相应的青云 QingCloud 对象存储的信息。

这样就多了 10GB 免费空间了。

更多玩法，大家可以挖掘，have fun !

数字化转型，我们需要什么样的超融合

arron — Thu, 29 Oct 2020 21:54:46 +0800

内容摘要

经市场验证后，超融合呈现出了多层次的产品价值，从最基础的提供计算虚拟化能力，到传统数据中心现代化升级，再到面向业务、面向应用的全栈云平台。
数字化业务对 IT 服务能力提出了更高的要求，仅具备基础 IaaS 的超融合产品将面临挑战。如何从超融合破茧成蝶升级到云平台，需要纳入企业 IT 建设的中长期规划中。
自主设计、统一架构、功能解耦，可以作为超融合产品选型时的标准，评估它是否能够在未来平滑升级至云平台。避免交付风险，实现应用无缝迁移、系统无限扩展，可以伴随用户业务成长，持续交付价值。

青云 QingCloud 的超融合产品具备“云基因”品质，从云上来，向云生长：可以持续演进满足数据中心不同阶段的需求；可以成为分支机构、边缘侧等场景下的计算节点，搭建起立体互联的云网边端体系；也可成为构建混合云的重要一环，支持公有云和数据中心内部之间应用的无缝迁移，将不同的应用部署在适合的位置。

从 2016 年“超融合元年”到 2020 年的 5 年时间里，超融合产品不断成熟，业务场景完成了从边缘向核心的迈进，正朝着广义云计算的方向发展。市场热度也一路攀高，从厂商苦口婆心向用户介绍“什么是超融合”，转换为用户主动询问厂商有没有超融合，收集比较各家方案特点。

在被用户认可的同时，市场规模也在快速增长。IDC 数据显示，中国超融合市场规模从 2016 年 10 亿元，2017 年 28 亿元，2018 年 52 亿，扩大到 2019 年 68 亿元。仅 4 年时间市场整体规模扩大了近 7 倍。数字化新基建浪潮的推动下，IDC 预计今年国内市场规模有望冲击 100 亿元。

在这种快速增长的数字背后，超融合市场都经历了怎样的变化？

需求升级，价值分层

超融合，作为新一代数据中心基础架构，解决了传统三层架构中的诸多问题，具有成本节约、管理简单、扩展方便等特点。超融合产品，通过软件定义的方式，将计算、存储、网络、安全等功能虚拟化，并提供统一的管理界面，在同一套 X86 设备中进行融合交付。

经过这些年的发展，用户选择超融合的理由变得多样，侧重于产品的不同价值，由低到高大致分为以下几层：

提供虚拟化能力。长期以来，商业虚拟化市场一直被 VMware 垄断，高企的采购成本和复杂的部署及运维方式，令许多中小企业望而却步。超融合自带的 KVM 提供了低成本和易运维的计算虚拟化解决方案，在企业数据中心得到了广泛的普及。
替换集中式存储。这是最早一批超融合厂商的创业起点，以软件定义的方式交付分布式存储产品，对接 VMware 等传统虚拟化平台。这解决了集中式存储，由于机头难以扩展，导致的性能瓶颈问题。由于分布式存储的引入，使得用户的采购和运维成本开始显著下降。
数据中心现代化。以软件定义数据中心为理念，对硬件资源进行抽象和池化，通过一体机的方式进行融合部署，提供 IaaS 服务。这种互联网式架构能够在一个 UI 界面完成管理和运维操作，快速弹性地交付资源，提升数据中心自动化水平。
构建云计算平台。随着数字化进程的不断深入，企业业务越来越依赖于数字化基础设施，加之新冠疫情加快了企业转型的速度。以超融合为基础架构构建云计算平台，从基础 IaaS 功能升级到完整 IaaS 功能，再到具备丰富的 PaaS 服务，直至面向广义云计算场景提供解决方案，为企业数字化转型赋能。

超融合价值分层

这些不同层次的价值同时存在于市场中，满足各类用户的需求，也可能对应于同一用户的不同业务阶段。在这 4 层价值中包含了两类视角：

前 3 层价值，是从传统数据中心的视角出发，资源是重点，交付的是超融合产品，强调更好地管理和使用资源。由于具有类似云的敏捷和弹性等特性，成为传统企业基础设施上云的第一步，推动信息化建设升级。
第 4 层价值，是从云计算中心的视角出发，应用是中心，提供的是超融合架构，围绕更快地交付和更新应用展开。通过“IaaS+PaaS+ 应用市场”方式进行全栈交付，支持应用和系统上云，成为数字化转型的新基建。

选错起点，失去未来

相比信息化场景下 ERP、CRM、OA 等传统应用，数字化场景下 IoT、AI、大数据等新型应用，在应用模式、资源类型、管理方法等方面都提出了新要求，业务的复杂程度不可同日而语，对 IT 设施提出新挑战。

超融合产品是传统企业上云的第一步。从最小 3 节点规模起横向扩展，集群规模不断扩大，但这并不会带来系统能力的质变，更多是传统 IT 能力的加强。传统超融合产品仅有的基础 IaaS 功能，显然难以满足数字化转型的需求。

在超融合的基础上再往前走一步。云平台的全栈能力，具备了提供 IaaS 和 PaaS 等各项服务的能力，可以支撑起更加复杂的、具有云特性的应用架构，满足大规模复杂场景的管理运维要求。

比如在 IaaS 层，部署边界路由大幅提升跨 VPC 之间的网络通讯能力，构建大规模高性能的应用网络；通过负载均衡器集群消除单节点故障，确保大规模场景下服务的稳定性。在 PaaS 层，应用和资源的弹性伸缩，可以快速响应业务的动态变化，确保业务连续性；利用编排实现应用的快速部署和管理自动化，更好地支撑业务发展。

从超融合产品升级至云平台，并不是简单的软件版本的更新，会涉及到整个软件栈的变更和部署方式的调整，整个升级过程犹如破茧成蝶。

从图中能看到，相较于超融合产品，云平台拥有全面的软件栈：完整的 IaaS 功能、丰富的 PaaS 服务、应用平台、全面的安全功能、自动化的运维能力、多用户类型门户等，提供与公有云一致的使用体验。

全栈云升级

基于超融合架构的云平台，部署方式也会和超融合产品有所不同。为了全面适应各类业务对资源的不同要求，提升管理效率，因此将计算和存储进行分离部署，形成各自的资源池，管理节点也会单独安排至物理节点上设置。

在升级准备的过程中，不少企业发现，已经形成一定部署规模的超融合集群，几乎无法平滑升级到云平台。这是他们最早做超融合产品选型时始料未及的。导致这种困难的原因大致有 2 个：

原有的超融合产品厂商，没有云计算平台。系统将长期处于缺乏完整的 IaaS 功能和丰富的 PaaS 服务的状态，无法提供全面的云计算服务，或者找其他云平台厂商提供解决方案。
原有的超融合产品厂商，提供云计算平台，但是两款产品架构不统一，无法平滑升级，需要将业务中断迁出后，进行云平台的全新部署。待测试完成后，再将业务回迁系统上线。

以上情况均等同于替换原来的超融合集群，又重新部署一套云计算平台。这个过程中的风险有多大，对业务的影响有多严重，让企业心有戚戚，犹豫不前。

升级，似乎成了不可能完成的任务。

破解难题，自由升级

对于前面提到的场景，我们认为要平滑升级至云平台，在超融合产品的选型上需要关注以下几点：

自主设计：确保产品平滑升级，降低系统演进风险；基于开源构建的超融合产品，从阉割版升级到完整版，或者进行跨版本升级的时候，存在大量不确定因素，风险不可控；新需求和新技术无法交付的情况常有。
统一架构：做到应用无缝迁移，免去业务兼容顾虑；确保了超融合和云平台之间，使用体验上的一致性；在超融合上的应用被迁移至云计算平台后，不需要再做业务的二次测试，减少了上云升级的各种不确定性。
功能解耦：保障平台按需对接，满足业务长期发展；系统提供统一的 API 接口，可任意拆解接驳；系统提供无限的扩展能力，加速对接上下游生态，整合新技术不断向前演进，跟上业务的发展脚步。

超融合选型标准

以上考量分别从升级前、上线中、交付后三个方面着手，确保了最终升级成功，为企业交付一个可以伴随业务成长的云平台，支撑数字化转型不断深入。

从云上来，向云生长

传统企业对“真正的云”的向往，促使超融合厂商不断完善产品的软件栈，升维做加法，提供各种面向云服务的框架和组件，做到“类公有云的使用体验”。公有云厂商则利用自身在云计算领域的技术积累，降维做减法，或者与合作伙伴推出超融合产品，作为企业上云第一步。

青云 QingCloud 的超融合产品——青立方，和公有云、私有云是同一架构，均是自主设计和研发的产品。私有云是公有云服务的本地化部署，功能解耦标准化交付，共同经历了数万企业用户的大规模验证。青立方超融合则是基于云平台为简单业务场景量身定制而成，这使得他成为一款内置了“云基因”的超融合产品。

从云上来，向云生长。超融合可以作为建设私有云的起点，在企业准备好下一阶段数字化转型时，只需要将超融合平滑升级为云平台，建成“真正的云”，和“公有云一致的使用体验”。这使得数据中心可以持续演进，满足各个阶段的需求，不用担心未来变化带来的挑战。

广义云计算环境下，青立方超融合也可以成为分支机构、边缘侧等场景下的计算节点，构建起立体互联的云网边端体系。青立方也可以作为混合云建设的重要一环，支持公有云和数据中心内部之间应用的无缝迁移，将不同的应用部署在适合的位置。

优秀的超融合，生而为云。

学习最新最全的云计算技术干货

请关注公众号：QingCloud-IaaS

或访问官网：https://www.qingcloud.com/

免费送课啦～让程序员多活几年的 Region 及多活方案分享：)

arron — Tue, 30 Oct 2018 15:31:21 +0800

免费送课啦～让程序员多活几年的 Region 及多活方案分享：）

1024 活动刚刚过去，但我们的干货&福利放送正要开始哟

本期知行学院我们邀请了青云 QingCloud 云计算基础平台研发工程师 Cipher，带来真正多活，不惧宕机——Region 及同城多活方案的主题课程

与大家分享作为云服务提供商，我们如何能够在基础设施层面提供更便捷、高效的高可用服务能力？作为云服务的受益者，您如何能够更优雅地利用基础设施构建稳定的生产级服务？本次课程将介绍 Region 的多可用区架构是如何实现的，以及如何构建同城多活系统。

给同学们的提问福利：

听课中提出问题的同学将有机会获得青云 QingCloud T 恤一件。数量有限，赶快来提问吧～

地点：千聊知行学院，扫码即可报名👇

运维工程师的逆袭——云资源的管理与维护

arron — Thu, 20 Sep 2018 14:06:24 +0800

主题：运维工程师的逆袭——云资源的管理与维护

时间：9 月 27 日 20:00 —— 21:30

地点：千聊知行学院，扫码即可报名👇

讲师：

严芬（Ephen），青云 QingCloud 产品经理

负责 QingCloud 控制台的功能设计及改进，持续优化用户体验。曾任中国电信 OCS 业务验收测试负责人、世纪互联 CloudXNS 高级产品运营经理，熟悉 Web、DNS、计费等业务及相关技术。技术博客：https://ephen.me

本期内容介绍：

当企业随着业务的扩展，使用的资源越来越多的时候，如何高效的去管理一个或数个庞大的资源集群，使运维工作变得更加容易简单灵活？

一套优秀的云资源自动化管理工具，可以体现出云计算在企业级解决方案中相对于传统运维的巨大优势，云资源分组归类，隔离与授权，使用最高效的运维工具（监控告警，自动伸缩）等，提升企业的 IT 运维效率。

Project 实现 QingCloud 控制台资源的整合及多用户合作，是在原有的“资源协作”功能上做的升级。本课程将全面介绍 Project 功能的使用及其最佳实践，让 QingCloud 控制台使用者们逐步适应基于项目理念的协同工作。具体内容如下：

Project 功能介绍及演示

Project 周边功能调整

Project 功能升级展望

提问福利：

听课中提出问题并被采纳的同学将有机会获得青云 QingCloud T 恤一件。数量有限，赶快来提问吧～

扫描下方二维码加入课程咨询群

入群请完整备注“姓名 - 公司 - 职务”

来聊聊对象

arron — Wed, 05 Sep 2018 17:45:27 +0800

真的是今年最全面的对象存储内容分享，大兄弟来看看嘛！

对象存储作为一种新型存储解决方案，相对于传统的 NAS、SAN 存储，具有无限扩容、安全可靠、简单易用、高性能、低成本等特点，可以通过 SDK、HTTP RESTFul API、S3 等方式和企业服务集成，提供高效高性能的存储服务，以供企业丰富的上层业务和数据分析系统使用，帮助企业能够持续最大化的利用数据的价值。

本期「知行学院」课程我们安排在 9 月 13 日 20:00 - 21:00，邀请了 QingStor 对象存储研发工程师马毅，带来

《QingStor 对象存储场景化开发实践》 的主题分享。

本次分享会详细介绍对象存储的产品特性以及如何使用对象存储应对常见的业务场景，提高开发效率。

具体内容包括：

对象存储架构概览

对象存储的功能以及特性

对象存储中的异步数据处理框架

常见应用场景介绍及分析

对象存储周边工具及应用

点这里，有对象

除了实践干货，还有精美礼品可以拿

arron — Tue, 26 Jun 2018 17:07:16 +0800

除了实践干货，还有精美礼品可以拿

干货云集，让你不虚此行

10 场分论坛深度探讨
7 款重磅产品发布
50 位业界大咖精益分享
30 场行业实践破局认知点这里，科技洞见未来

你将收获什么

行业：聚焦多行业应用实践、内容维度更深入

与行业领袖们一起把握数字化时代的脉搏，共同分享探讨科技力量如何推动业务快速创新升级的最佳实践，推动云计算、大数据在更大范围、更多领域创新应用，助推企业的数字化转型。

能力：核心技术拆解、认知提升更全面

容器、微服务、多云管理、音视频技术等技术论坛，与行业领袖们一起把握数字化时代的脉搏，共同分享探讨科技力量如何推动业务快速创新升级的最佳实践，推动云计算、大数据在更大范围、更多领域创新应用，助推企业的数字化转型。

前瞻：把握产业走向和发展趋势。

介绍目前全球云生态发展现状，分析云计算产业未来的发展前景与投资机会，探索云商业模式与创新机会，展望云计算发展未来。通过大量的数据支撑以及精准的分析，让您全面、准确地把握产业走向和发展趋势。

人脉：深度沟通，解锁行业人脉圈

50 余行业技术管理者，10 场深度交流论坛，在互动与分享中思想碰撞，解锁行业人脉圈。

点这里，科技洞见未来

适合人群

银行、保险、证券等金融机构技术负责人
零售、交通、制造等传统企业信息化负责人、CIO
互联网公司 IT 负责人、运维工程师、架构师、CTO
对技术感兴趣的开发者
PaaS、SaaS、DevOps 专业服务提供商
想了解靠谱的云知识的朋友和 QingCloud 爱好者

现在报名还有惊喜等你拿

构建下一代企业级架构，开启全模云时代。1月10日在深圳等你来一探究竟

arron — Tue, 19 Dec 2017 17:09:07 +0800

免费抢票：https://www.bagevent.com/event/704242?bag_track=rubychina

会议简介

双区升级，全球互联

——青云 QingCloud 广东 2 区&亚太 2 区发布会

👉官网： www.qingcloud.com

2013 年青云 QingCloud 公有云正式上线，至今已度过近 5 年时间。在这期间我们不断成长，对外开放的自营数据中心迅速增长到 12 个，实现了华北、华东、华南地区全覆盖，并对外辐射亚太市场，为全球超过 80,000 家企业级客户提供敏捷与可靠的云服务。

2018 年 1 月 10 日我们将同时开放运营两个新的可用区——广东 2 区 (GD2）与亚太 2 区（AP2），进一步提升华南地区的基础设施规模和服务品质，并为国内企业业务出海助力，提供国际通路定点优化能力，使青云 QingCloud 公有云的全球版图得到进一步延伸，也标志着 QingCloud 整体服务能力再次全面提升。

每一个新区的上线，都是我们对服务更强更稳的承诺。

广东 2 区与亚太 2 区均将采用青云 QingCloud 最新技术与基础架构，在“全模云”理念下，以更加丰富的服务及产品组合，满足用户在不同的业务模式和场景下，兼顾“敏态”、“稳态”及“混合态“的不同 IT 需求，助力企业业务更加敏捷和稳健地发展。

在此重要时刻，我们在深圳，诚邀您共同参与、一起见证。

谁适合参加

正在或计划使用云服务，希望了解云计算领域前沿技术趋势的企业

已部署使用公有云或私有云服务，希望进一步了解如何构建混合云的企业

有大规模复杂的 IT 业务系统，并希望通过一套架构实现统一管理的企业

有计划面向华南市场开展业务和/或进行海外业务拓展的企业

会有哪些收获

了解关于云计算的最新产品和技术

了解如何通过「全模云」架构完美兼顾『敏态』和『稳态』

全方位了解青云海外服务，助力业务出海计划

获得最新的产品试用优惠券

欢迎各位大神前来参加

时间地点

时间：2018 年 1 月 10 日

地点：南山区南山大道南山文体中心 - 聚橙剧院（深圳市南山区南山大道南头街 62 号）

「我们本来就是一群很酷的人，为何不一起来做一些很酷的事情呢？」

arron — Thu, 25 May 2017 10:56:23 +0800

本文来自「雪梨笔记」，在读这篇文章的时候，让我又回到了活动的现场，再一次「参加」活动，来，快坐下，也一起听听！

写在前面

大概从半个月前开始，我的微信就开始被青云 QingCloud 要在武汉开第一场技术社区活动的宣传消息刷屏了，有朋友圈转发的，有社区大群里的，还有朋友私发给我的。作为心系大武汉互联网圈的 ITer，即便不是技术从业者，也被勾起了好奇心。于是，犹豫了很久，我战战兢兢地提交了报名表。什么，你问我为什么“战战兢兢”？因为我怕主办方看到我填的 title 是别的公司的 HR，会把我赶出去（微笑脸）。

你可能会觉得奇怪，一个非技术从业者为什么要来参加一场纯技术活动？我想说的是，除了技术内容，我更想知道圈子里的友商在做什么样的业务，他们是怎么办社区活动的，以及大家会被什么样的公司所吸引。再说，武汉本地没有几家做云计算的公司，既然青云先来了，怎么能不围观一下呢。

最终，我还是收到了参会的邀请函。所以结果证明，青云还是一家相当 open 的公司嘛。

利益不相关：博主既不和青云 QingCloud 有任何关系，也刚从 ThoughtWorks 招聘团队离开，完全站在中立的角度写了一些关于这次活动的心得，望周知。

第一次在公号上露脸，紧脏

我的感受

活动筹备：⭐️⭐️⭐️

不得不说，虽然是第一次在武汉办活动，但青云对整个活动的前期宣传还是挺到位的。对于真的关心武汉的技术社区动向同学们，青云这次活动的宣传应该覆盖了一大半。

但是，可能真的是因为第一次在武汉办活动，在筹备上确实还有些要优化的细节。活动的地点临时从氪空间改到了同一栋大厦的 25 楼，场地小的可怜，一百人挤在里面，体验确实不太好。前排的凳子既没有靠背也没有写字板，我弯着腰记了 5 个小时笔记，简直体会到了什么叫如坐针毡。中间时间控制也没有做得太好，导致最终超时了一个多小时。

然而，虽然嘴上吐槽几句，但看得出来，主办方确实是带着满满的诚意来组织这次活动的。主持人妹子开场的两句软软的“对不起”，还有结束时不忘关注每个参与者的体验，真的让人感到了热情和真诚。很明显，云计算领域对武汉 ITer 的吸引力还是很强的。目测这次活动大概吸引了 100 位左右的外部参与者，并且大家的参与度都很高，互动频繁，主办方还是能很好地 handle 住，实属不易。

还有一句题外话，就线下接触过国内的科技公司来看，个人认为青云的 VI 做得绝对算顶级的。周边礼品都很有设计感，戳中我的点，点个赞。

内容：⭐️⭐️⭐️⭐️

关于实践课堂的内容，青云给的 slogan 是：“我们不作秀，只想同认真好学的你分享最踏实的技术知识”。事实上，他们也确实做到了干货满满。云计算的业务模式决定了其技术壁垒，毕竟开一家店不难，但要做一个支撑起千千万万家门店运营的平台就不是那么简单了。青云的技术范围涉及了较多架构、虚拟化、数据分析方面的内容，对工具运用的要求比较高。更难得的是，几位嘉宾直接从自己的产品入手，现场手把手演示技术原理和应用，真心很有诚意。可能也是因为这一点，现场貌似也吸引了一些潜在客户，直接就开问私有云的解决方案在自家公司如何部署了，也是蛮可爱。

总的来说，主办方对这次内容的准备还是挺到位的，对受众群的定位也比较准确，加上大家积极的互动，整个活动从内容上来看还是很成功的。就在刚刚，也收到了主办方发过来的打包 PPT 资料，不得不说，青云确实是一家非常有技术情怀的科技公司。

讲师：⭐️⭐️⭐️⭐️⭐️

青云的整个团队都比较年轻，颜值高、科技范、很洋气，从气质上来看，其实还蛮相似的。对几位讲师印象也是蛮深刻的。

海泉，白净斯文的帅哥一枚，逻辑清晰、表达简练、台风镇定，对 Q&A 的回答很 make sense，非常技术范儿。所讲部分内容丰富，语言控制能力强，全程所讲和 slides 上对的非常吻合，应该私下练习过很多次。

梁波，看起来很机智的小哥，有点萌，从头到尾都很自然，应该是经常做技术活动。他主要从产品入手去讲 session，所以有很多可以互动交流的点，干货多，内容很有诚意。

四哥，台风活泼、非常 senior 的技术专家，讲话非常有激情，铿锵有力，善于和听众互动，举的例子通俗易懂，嗨范儿的萌大叔。

渊命&锦涛，两位都是长发飘飘的男子，艺术范儿十足。渊命讲话慢条斯理，温文尔雅，耐心且细致。锦涛内容讲的非常细，每个点都会深入进去讲，但是整体节奏却丝毫不乱，很佩服。我发现啊，搞技术的男人和搞艺术的男人在某种程度上还真挺相似的，毕竟，编程也是一门艺术啊。

青云这次应该是请出了技术团队核心的几个 Tech lead 来做活动，每一位嘉宾不管从硬实力还是软实力上来说都是 top 级的，如果能和这样的同事一起工作，真的是一种享受呢。

我们为什么需要技术社区？

从大概一年前左右，我开始参与一些技术社区的活动组织，主要是做主持人和志愿者。虽然对于活动的内容，我没有太多评价的话语权，但作为一个参与者，我是真的可以感受到技术社区的爱好者和其他人有那么一点点不一样的。不同在哪里？我觉得是好奇心和开放性。

对于企业来说，做社区活动，更多考虑的可能是 branding，或者更高阶一点的，像 ThoughtWorks 一样，考虑推动 IT 变革和软件卓越。那对于参与者个人来说，我们为什么要参与社区活动？我认为并不是单纯为了刷脸，或者看看新的工作机会，而是一种“看世界”的态度。我们需要知道身边正在发生着什么样的变化，以及自己在这样的变化中处于什么样的位置。我更期望在社区平台上，每个人都是带着问题和观点来的，并且带着开放的心态，看待其他人的观点，以及接受其他人的反馈。以前在面试的时候，我一定会了解候选人的技术热情和心态开放程度，而一个人在技术社区活动中的参与度，就是一个很好的体现方式。

讲真，其实我经常听北上广深回流的朋友吐槽，说武汉的互联网环境不是特别好。那么，什么叫互联网环境呢？互联网公司多就是环境好吗？我觉得未必。互联网精神，是开放、平等、协作、和分享。既然有人吐槽武汉的互联网环境，那这一块一定是有需求可挖的。为什么我觉得青云这次的活动难能可贵？因为从这次活动中，我真切感受到了开放和分享的互联网精神。也听到有参会的朋友陆续讨论，说以后请多一些这样有干货的活动。这样的声音很好，不过我也想说，我们身处一个大环境内，每个人也是可以做点什么的。因为接受和给予两两不可分割，渴望开放和分享的大环境，就先从咱们自己所在的团队开始吧。别光顾着自嗨，把你的嗨点告诉团队，也听一听他们的声音。从小到大，由点及面，来一场自下而上的改变，难道不是一件很酷的事情吗？

我们本来就是一群很酷的人，为何不一起来做一些很酷的事情呢？

-完-

『充电时间』实践课堂第三季已经开始了，

6 月 10 日，杭州，成都，6 月 15 日，昆明；6 月 17 日，上海、重庆！

本次课程内容仍以技术实践为主，以用户场景为切入，主要围绕 QingCloud 的技术理念、功能特性和使用技巧展开，话题将涵盖如何高效构建原生云应用，云端容器部署，微服务架构，应用感知，自动化运维等业内热点话题。

充电二维码：

青云 QingCloud 的每一个人都是很酷的人，那就让我们做一些酷酷的事情吧！

青云 QingCloud 实践课堂走进 [杭州、成都、重庆、上海、昆明] ，这里有关于容器、关于大数据、关于对象存储、关于企业级应用等等你想要的干货～

arron — Wed, 24 May 2017 19:22:51 +0800

【关于实践课堂】

QingCloud 实践课堂系列开始于 2014 年末，至今已经成功举办两季，是我们在全国范围内，为所有对技术有着极致追求的程序员和架构师们巡回举办的重要活动。迄今，已经走进了深圳、上海、广州、成都、杭州、北京、南京等全国各大城市。在这里，你不仅能偶听到 QingCloud 研发工程师的分享，还可以与他们进行面对面的交流，沟通经验、探讨问题。还有来自人民网、融云、泰捷视频、杏树林、元征科技等企业的架构师们同大家分享了精彩的云端实战经验。

【本季话题涵盖】

1、如何在云上构建复杂的企业级应用

2、超融合系统

3、对象存储开发实践及构建原生云应用

4, IaaS, PaaS

5、容器、微服务

6, SDN 2.0

7、对象存储上的创新与实践

还是那句话—— 我们不作秀，只想同对技术有极致追求的你分享最踏实的知识。

更多分站详情，请戳报名链接了解哦

【报名链接】

6 月 10 号成都站：http://www.bagevent.com/event/599038?bag_track=rubychina

6 月 10 号上海站：http://www.bagevent.com/event/598141?bag_track=rubychina

6 月 15 号昆明站：http://www.bagevent.com/event/605095?bag_track=rubychina

参会有惊喜

自动化代码生成工具 Snips 开发实践

arron — Wed, 21 Dec 2016 11:26:06 +0800

自动化代码生成工具 Snips 开发实践

前言

在开发工作中，经常会遇到新产品、服务上线后，需要将其 API 编写不用语言的 SDK。但不同语言 SDK 中都有很大一部分内容是用来进行 API 的描述，而且这部分代码量是最大的，手写起来也枯燥易错。所以我们需要一种 Data-Driven 的开发方式，通过工具（Snips）来自动化的生成准确、优雅的代码，让开发者减少重复无意义的工作，将更多精力放在产品以及业务上。

本文共 4420 字，阅读大概需要 18 分钟。

今天的内容包括： 

QingStor SDK 简介
QingStor SDK 开发流程的改变
API Specification
SDK 生成工具 Snips
场景化测试
使用 Snips 开发 QingStor Go SDK  ## 正文

大家好，我是青云 QingCloud 系统工程师 Aspire。今天我来和大家分享一下 QingStor SDK 以及自动化 SDK 生成工具 Snips 的开发经验。

今天交流的内容包括：

QingStor SDK 简介
QingStor SDK 的开发流程
API Specification
SDK 生成工具 Snips
场景化测试
使用 Snips 开发 QingStor Go SDK

1. QingStor SDK 简介

QingStor™ 对象存储为用户提供可无限扩展的通用数据存储服务，在 QingCloud Console（青云控制台）中可以直接创建、使用和管理对象存储 Bucket，可以方便的上传下载文件。我们也提供了命令行工具 (如 qingcloud-cli, qsctl) 来在各种场景下进行数据的存取。但是面对海量数据的操作时，图形化的界面和命令行工具是不够的。另外，我们的用户也需要在代码层面使用 SDK 或者直接请求 API 来接入 QingStor 对象存储。自上线以来我们就开放了一套标准、规范且简洁的 RESTful API，以及一个 Python 的 SDK。虽说 Python 的用户量非常大，但是显然只有这一种的 SDK 是无法满足用户需求的，再加上 QingStor 的 API 是遵循 RESTful 标准的，直接使用 API 来接入 QingStor 的成本也会高一些。（不过好在我们已在今年上半年兼容了 AWS S3 的 API，所以用户也可以使用 S3 的 SDK 来接入 QingStor。）

这里将 QingStor API 和 QingCloud IaaS 的 API 做个简单比较：

相比之下用户使用 API 来接入 QingStor 的难度会高一些，对 SDK 的需求也就更强烈。

目前 QingStor 提供了包括 Go、JavaScript、Ruby、PHP、Swift、Java、Python 在内 7 种语言的 SDK，已经可以做到覆盖主流编程语言，而且有了 Snips 的帮助，开发者也能够在短时间内开发出另一种语言的 SDK。

同时，此次我们将 QingCloud IaaS 和 QingStor 的 SDK 进行了拆分，例如 qingcloud-sdk-swift (尚未发布) 和 qingstor-sdk-swift。这样做主要是考虑到移动端对空间比较敏感，所引入的第三方库越小越好，由于 QingCloud IaaS 目前开放的 API 数量是 QingStor 的三倍，将两者合并为一个包会造成空间的浪费，对于一个仅需要 QingStor 做为存储的 App 来讲，只引入 QingStor 的 SDK 就足够了。

QingStor SDK 的中文使用文档可以参考 https://docs.qingcloud.com/qingstor ；另外这些 SDK 也已开源在 GitHub，可以访问 https://github.com/yunify 来获取，也欢迎大家给我们提 Issue 和 Pull Request。

2. QingStor SDK 的开发流程

首先可以回顾一下我们 Python SDK 的开发方式，就是在 API 发生改变之后，手动增加 SDK 中与之对应部分的代码，这种做法效率不高，维护起来也让人头疼。

再加上 QingCloud IaaS 和 QingStor 共有两百多个开放 API，并且不断有新的 API 伴随产品或功能上线，要做到 SDK 的实时跟进比较困难。而且现在只有一个 Python 的 SDK，如果再加上其他语言的，每种语言都手动维护，会耗费工程师很多不必要的精力。还有一个问题比较麻烦，如果有用户对一些小众语言的 SDK 有需求，我们也没法立即进行支持，这点行业内基本都有类似的情况。

要解决这些问题，就需要换一种思路。我们可以看到，不同语言的 SDK 中都有很大一部分内容是用来进行 API 的描述（或者叫定义），而且这部分代码量是最大的，手写起来枯燥易错。所以我们采用了一种新的 SDK 的开发流程，使用标准的数据来生成代码，之后通过场景化的测试来进行验证，其中用到了我们自己写的一个代码生成工具━━ Snips。

Snips 使用 API 的标准化描述和代码模版来生成各种语言 API 调用的那部分代码，除了生成出来的代码，还需要手动编写的代码，每种语言都不一样，不适合统一生成代码，比如错误处理，文件读写，网络请求等。这样做比起纯手工打造一个 SDK，需要开发的代码量会小很多，开发效率能够得到很大的提升。

上面是利用 Snips 开发一种新的语言的 SDK 的示意图。下面具体说明一下。

新增一种语言的 SDK：

手写哪些错误处理、网络请求等相关的的代码
编写代码模版
使用 Snips 生成代码
通过场景化测试
发布

更新 SDK：

更新 API 描述
重新生成代码
通过场景化测试
发布

这里的 API 的描述我们是通过 Git Submodule 的形式引入到各个 SDK 项目中，这样如果是 API 的变更，完全不需要手动编写 SDK 的代码就可以做到 SDK 的更新。

下面会逐个讲一下 API 描述规范（API Specification）、Snips 和场景化测试（Scenario Based Testing）这几个部分，我们是怎么做的。

3. API Specification

要实现上述的流程，得先有 API 的描述，我们花了很长时间来确定使用怎样的 API 描述规范，也走了一些弯路。

起初我们自己制定了一个 API Specification 的 Schema：

这个 Schema 的目标是描述 HTTP API
每一个 API Specification 文件呈现一个 Service（如 QingCloud IaaS 或者 QingStor）
Service 中可以有 SubService
同时 Service 和 SubService 中都包含 Metadata、Properties、Operations、Endpoint 等信息
Operation 是具体的 API 请求，其中包含 Request 和 Response 的描述以及其他基本信息
定义了 boolean、integer、timestamp、binary、list、object 等几种基本的数据类型，及自定义的数据类型 CustomizedType, CustomizedType 可以出现多级引用

之后使用这套 Schema，去描述了 QingStor 的所有 API，并且写了解析器，快速实现了从 API 描述生成 Go SDK 的代码。但是 Review 时我们发现这个自己定义的 Schema 还是太简陋，没有经过足够的数据进行验证，很多情况都没有考虑到，还有一些 Corner Case 也难以描述，并且这个 Schema 本身的校验效果也不理想。而且如果使用这套自己定义的 Schema 来描述 QingStor 和 QingCloud API，无论是在内部使用还是开放出去，都是让人比较难以接受的，这种自立门户的做法也没有太大意义。

然后我们对比了几个目前可以用到的几个 API Specification 的规范，最后选择了 Swagger。

Swagger 是一个描述 RESTful API 的规范，Swagger 具体的 Specification 大家可以访问它的网站来查看： http://swagger.io 。

今年的一月份 Swagger 更名为 OpenAPI Specification，由 Linux 基金会赞助成立了 OpenAPI Initiative 来继续 OpenAPI Specification 的开发。在 Google、Microsoft 等大厂的支持下，Swagger 俨然已经成了业界标准，相关的生态和工具也已比较齐全，用它来作我们 API 的描述规范再合适不过，所以我们最终选择了 Swagger 来重新描述了 QingStor APIs，并且实现了用 Swagger 描述规范来生成代码。

使用 Swagger 规范无疑是正确的，因为 Swagger 的工具和生态相对比较完善。以 Swagger Editor 为例，它是一个 API Specification 的 Web 编辑器，可以在编辑的同时提供代码补全、高亮和实时语法验证功能，感兴趣的朋友可以在 http://editor.swagger.io 体验一下。

Swagger 虽然发展的比较快，但并不是对所有 API 都友好。QingCloud IaaS 的 API，请求参数部分里会有数组（Array）和字典（Map）。例如 statics.n.router_static_name、statics.n.router_static_value 这种请求参数，用户实际提供的是一个由 Static 字典组成的数组，并且这个请求参数是位于 Request URL Query，SDK 会把数组和字典转换一下格式，构造出 statics.0.router_static_name=name&statics.0.router_static_value=value 这种形式的请求串。这样就会出现问题，在描述请求的时候需要定义数组和字典参数，由于 Swagger 的规范比较严格，Operation Parameter 不允许自定义类型出现，这时就只能将请求参数的描述放在 Request Body 里面来定义，这样就需要解析 Specification 的时候做一些特殊处理。

Swagger 标准也考虑到了 API 数量很多导致描述文件过长的情况，它支持使用 $ref 来引用其他文件，当然这个引用的功能其实是 JSON Reference 和 JSON Pointer 规范提供的，但是这里的 $ref，只支持同一个文件内的引用，或者是引用某个 URL 链接。我们测试的解析器，包括 Swagger 官方的 swagger-codegen 都不支持文件间的引用，更不用提 Circle Reference 这种常用的情况了。不过这个问题我们在 Snips 中也解决掉了，可以看到我们的 QingStor API Specs 中的 API 描述是拆分成了很多文件的，具体内容等下 Snips 的部分会提到。

使用 Swagger API Specification 规范来描述 API，其作用不仅仅可以用来生成代码，生成文档，更重要的是它的约束作用，它反过来可以规范 API 的开发和交付，进一步保证 QingCloud 的整体服务质量。对于 SDK 开发来讲则是一种 Data-Driven 的开发方式，这种思路可以让产出的各个 SDK 在功能上保持很强的一致性，不会出现某种语言的 SDK 缺失功能，或者是更新滞后，这种思路的优势也会随着更多产品和功能的上线变得越来越明显。

API Specification 文件本身也需要验证正确性，而使用 Swagger 标准可以轻而易举的使用 JSON Schema 来实现 Specification 数据的验证。

QingStor 的 API Specification 也放到了 GitHub，这里是地址 https://github.com/yunify/qingstor-api-specs 。

4. 代码生成工具 Snips

接着讲讲代码生成工具，对于 Swagger 来讲，有官方的代码生成器 swagger-codegen，还有其他的同类开源项目比如 go-swagger。

它们虽说可以生成代码，但是生成出来的代码可控性和可读性都不高，并不能满足我们的需求，定制起来也比较麻烦。

例如采用 swagger-codegen 得 fork 过来，改它的 Java 代码，而且每增加一种语言的 SDK 基本上都要去增加对应的 Java 代码，这对于 Java SDK 之外的开发者来讲是非常不友好的。

除此之外还有很多其他细节上的问题，例如我们 API 的遗留问题，上面说到的 QingCloud IaaS 的请求参数不标准；例如 swagger-codegen 和 go-swagger 不支持文件引用的解析；生成出来的代码大小写控制不严格（acl 被转换成了 Acl，而不是 ACL）等。

现有的代码生成器没有可以开箱即用的，都需要去进行不少的修改。但是去实现一个 Swagger 的解析器又太费时费力了，所以我们想到了一种折中的方案，使用开源的 Swagger 解析器来构建自己的生成器。

比对了几个开源项目之后，我们采用的解析器是 go-openapi/spec ( https://github.com/go-openapi/), 这个解析器的作者也是 go-swagger 的作者，go-swagger 是在这个解析器之上构建的。遗憾的是 go-openapi 也不支持文件引用，看到未来有支持文件引用功能的计划，不过不知道什么时候才会加上。于是我们简单熟悉了一下代码，之后提交了几个 PR 把这功能帮他们实现了，作者也欣然接受“With this PR go-swagger is the first library on go that fully supports json schema and ref resolving so very happy with it 👍”。

随后就有了代码生成工具 Snips，它是一个命令行工具，很好地支持着我们的 SDK 开发，以 Go 语言 SDK 为例，包括模版在内，手写的代码大约 6 千行左右，而生成出来的代码已经达到了 2 万多行，开发效率得到了不小的提升。

关于模版，Snips 会从指定路径加载模版文件，模版目录下需要有一个 manifest 文件，可以是 JSON 或者 YAML 格式，这个文件指定了一些生成规则，例如指定该目录下模版文件的格式，输出文件名的命名风格是 CamelCase 还是 snake_case；输出文件的扩展名和前后缀，可以参考 example 下的 manifest.yaml 来查看所有支持的规则。模版文件格式目前只支持一种，是 Go 语言的 template。

与代码生成有关的简单逻辑是放在模版里去实现的，同时生成器也提供了一些内置函数可以在模版中使用，如大小写风格的转换、字符串替换、数据传递等，从而做到了生成器与某种语言无关，新增语言不需要去修改生成器的代码。上文提到的 acl 转换成 Acl 的问题，使用 Snips 提供的函数就可以正确转换，例如 {{snakeCase "acl"}} 会转换成“ACL”。

关于多版本 API，Snips 也有解决方案。

通过 -n (--service-api-version) 参数来指定使用的 API 版本，然后将代码生成到不同的目录，例如 latest version 的代码在 service 目录，特定版本的代码可以在 service-2016-01-06 中，再根据语言的不同看是否还需要相应的调整。以 Go 语言为例，用户使用的时候 import 不同的路径的 service 即可切换不同版本的 API，如 import "github.com/yunify/qingstor-sdk-go/service-2016-01-06"。

Snips 目前已经开源，GitHub 地址： https://github.com/yunify/snips 。目前是针对 QingCloud IaaS 和 QingStor API 的代码生成工具，Snips 的思路和其他的 Swagger 生成器的思路不太一样，未来也可能会做成一个通用的代码生成器。

5. 场景化测试

SDK 开发出来了，除了单元测试之外，还需要在线上生产环境进行测试，保证交付的 SDK 可正常工作，我们称之为服务测试（Service Test）。

服务测试中我们采用 Cucumber ( https://cucumber.io)，它是一个 Behaviour-Driven Development (BDD) 工具。Cucumber 会读取通过自然语言描述的测试场景和数据，然后结合不同的测试实现去验证是否通过。Cucumber 可以被称作是一种测试方式，基本上每种语言都有它的实现。

举个例子：

获取一个 Object，Cucumber 描述是这样的：

Ruby 中对应的测试实现是这样的：

Cucumber 会检查代码场景执行过程中的数据是否满足预期，给出一个完成的测试结果

这样以使用者的角度来真实的测试 SDK，并且可以让所有 SDK 的测试用例保持一致，在保证 SDK 质量的同时，也可以做到各种语言 SDK 功能的一致性。

QingStor SDK 的测试场景也放在了 GitHub： https://github.com/yunify/qingstor-sdk-test-scenarios

6. 使用 Snips 开发 QingStor Go SDK

上面讲了整套的 QingStor 的 SDK 开发流程，下面用 QingStor Go SDK 来举例说明一下。

qingstor-sdk-go https://github.com/yunify/qingstor-sdk-go

首先需要实现 SDK 最基础的部分，比如网络请求和签名处理、文件读写、错误处理等等，然后再使用 Snips 生成 API 相关的代码。

假设基础部分现在已经完成了，并且经过了单元测试。

接下来安装 Snips，可以使用 go get -u github.com/yunify/snips 安装，或者直接访问 GitHub 下载编译好的二进制文件。

在代码仓库目录下以 git submodule 的形式引入 API Specification 和 Test Scenarios:

./specs/qingstor 引用 QingStor API specifications ./test/features 引用 QingStor 测试场景

然后便可编写代码模版，下图所示为 Go SDK 的模版文件:

具体的模板文件内容请见: https://github.com/yunify/qingstor-sdk-go/tree/master/template

模板编写完成后，即可利用模版和 API Specifications 来生成代码。下图为生成代码的命令，生成完的代码有可能会难看，可以格式化一下代码，当然如果模版控制的严格，生成出来的代码足够漂亮，可以跳过格式化的步骤。

之后便可使用这些生成好的代码，实现测试场景，具体的代码请见这里：https://github.com/yunify/qingstor-sdk-go/tree/master/test

最后运行测试

7. 开发者激励活动

目前 QingStor 已经提供了七种语言的 SDK（其中 Python SDK 的新版也会使用 Snips 来重新生成），覆盖了主流的编程语言，但还有一些编程语言的 SDK 我们没有来得及开发，为激励更多的开发者参与进来贡献其它语言的 SDK，我们特此发起 QingStor SDK 大赛活动，报名地址请见： https://jinshuju.net/f/0MB6w6

基于云计算的大数据平台基础设施建设实践排序

arron — Tue, 19 Jan 2016 23:51:03 +0800

大数据平台基础建设当前的趋势是云化与开放，这个平台需要可以提供各类大数据相关 PaaS 服务，也需要使各类服务间可以简单灵活的组合来满足多变及定制的需求。如何在云上提供弹性、敏捷，却不失稳定和高性能的大数据平台？如何高效的利用云计算的特点来开发大数据平台？

本期中国互联网技术联盟分享活动中青云 QingCloud 系统工程师周小四给大家带来基于云计算的大数据平台基础设施建设以及其架构特点的主题分享。

以下是分享原文。

——————

大家晚上好，我是周小四，英文名字 Ray，江湖尊称“四爷"，现在负责青云 QingCloud 大数据平台的开发。今天跟大家分享一下在云上建设大数据基础平台的问题，下面我提到的大数据是特指大数据基础平台，比如 Hadoop、Spark 等，而不是指上层应用。

我会从四个方面和大家交流一下：云计算与大数据，云上大数据平台建设的挑战，大数据基础平台，数据格式。

一、云计算与大数据

相信大家平时接触更多的是物理机方案的大数据，本来这个话题我并不想总讲，因为在我们看来大数据的发展方向是云化和开源，是一个顺理成章的事情，但是在实际实施中会遇到一些阻力，这是因为我们有相当一部分人还是物理机世界做大数据的思维，还有对云计算的不信任，稍微有风吹草动就怀疑云计算，这显然是不对的。怀疑大数据云化无外乎就是稳定性和性能，不过好消息是越来越多的人已经意识到也认可这个发展方向，相信以后这就不再是个话题了。

我们还是从大数据本身出发。我们在准备做一个大数据项目的时候，首先是确定需求，然后就是平台的选型，平台的选型是一个最难、最重要的、也是大家最困惑的环节，我遇到的客户基本上都在这个问题上有不同程度的纠结，这个完全可以理解，因为东西太多了，并且还有更多的新东西源源地不断地出来。

其实平台的选型完全取决于你的需求，你是实时计算还是离线计算，是处理结构化数据还是非结构化数据，你的应用有没有事务性要求等等。确定这些需求后就找相应的平台就行了，这就要求我们对每个平台的特点要了解。我们知道没有一个平台能解决所有的问题，Spark 再强大也没有存储，很多场景需要和 Hadoop / HBase / 对象存储等配合起来使用，更别说替换数据仓库了。

选择平台或工具不能赶时髦，适用才是最正确的，有些东西并一定就只有 Hadoop 或 Spark 才能解决，比如 redis 提供了一个很好的数据结构 hyperloglogs 用来统计独立事件，而内存最多只会用到 12k 字节，跟多少个独立事件无关，误差不超过 1 % ，那么用这个来统计每个时段的独立事情比如 UV 还是很不错的选择。

每个平台有自己特定的使用场景，我们不但要了解它，甚至很多时候我们还会对各个候选平台做个 POC 或 benchmark 测试，这个时候云计算就体现出优势了，你可以快速地、低成本地做试验。

当然云计算的优势不仅仅这些，大数据时代有很多不确定性的东西，能够说出半年之后你的数据量一定会增加到多少的人不会太多，云计算的弹性能很好地解决这个问题，需要多少就增加多少资源，还能释放过剩资源给其它业务使用，上下左右任意地伸缩，这些都可以通过鼠标点击几分钟完成。你甚至可以通过调用 API 的方式来操控这些平台，比如说我的程序里接收到数据，我启动我的 Spark 集群来处理这些数据，处理完之后我可以关闭集群；也可以通过定时器或自动伸缩功能去完成这些事情，从而极大的节约成本。

云计算不仅仅有弹性、敏捷性，还非常灵活，你可以任意搭配一些组件组成不同的解决方案。比如我们现在要做的一件事情就是基于数据任意切换计算引擎，因为我们知道大数据是计算跟着数据走，数据在那儿，计算跑到那儿，那么有的用户对 MapReduce 比较熟悉，他可能就是用的 Hadoop，但过段时间他想用 Spark 了，这个时候不能让用户去拷贝数据到 Spark 集群，而应该是换掉上面的 MapReduce 变成 Spark，数据还是原来的 HDFS。所有的这些都能帮我们把时间和精力放在业务层面，而不是去倒腾复杂的大数据平台。

二、云上大数据平台建设的挑战

可以看出云上的大数据能给我们带来无与伦比的体验，但是云上大数据最关键的并不是这些东西，而是稳定性和性能，这也是怀疑大数据云化最主要的两点。而这两点所依赖的是 IaaS 的能力，考验你的是虚拟化的技术好不好，不能压力一上来就 kenel panic，不过我们是从来没遇到过这个问题，所以我就不多说这个。

性能这个问题确实需要花大力气说，性能分磁盘 I/O 性能和网络性能，磁盘性能如果从相同配置的单节点来说，虚机确实没有物理机性能好，这是因为虚拟化总是有损耗的，但是，如果你虚拟化技术足够好，损耗可以降到很低，同时云计算是靠横向扩展解决复杂问题的，而不是靠纵向扩展，一个节点不行我多加一个节点。并且我们现在想到了更好的办法解决这个问题，让磁盘性能得到更大的提升。

网络性能在物理世界也存在，尤其是节点一多，如果一不小心网络配置不够好，性能一样会差。我们最近刚发布的 SDN 2.0 就帮我们的大数据解决了这个大问题，所有的主机之间网络通讯都是直连，跟节点多少没有关系，并且节点间带宽能达到 8 Gb，已经接近物理网卡单口的上限了。况且现在 25 Gb 的网卡成本也越来越接近 10 Gb 的网卡，所以网络不应该是问题，当然前提是你的 SDN 技术足够牛。

关于磁盘 I/O 的问题我再补充一点，我们知道 HDFS 默认的副本因子是 3，但是在云上就会变得不一样，你如果在一家云服务商上自己部署 Hadoop，就不应该设定 3 个副本因子。这是因为 Hadoop 设计第三个副本的初衷是防止整个机架出问题而把第三个副本放在另外一个机架上，你在别人家部署的时候你肯定不知道这个信息的，所以第三个副本是没有意义的，同时任何一家 IaaS 服务商一定会提供资源层面的副本的，数据的安全性能得到保障，所以更应该去掉第三个副本，去掉这个副本可以节省 1/3 的空间，性能还能得到提升。

但是，不能因为 IaaS 有副本就把 HDFS 降低到一个副本，原因是你需要业务层面的 HA，IaaS 的副本只能保证数据不丢，物理机出故障切换需要几分钟的时间，如果 HDFS 只有一个副本的话这个切换过程业务会受影响，所以 2 个副本还是必须的。即便这样其实还不是最优的方案，因为业务层 2 个副本加上 IaaS 层至少 2 个副本，加起来就至少 4 个副本了，比物理机方案的 3 个副本还是有差距。所以最好就是去掉底层的副本，在云上实现物理机世界的 3 个副本方案，然后加上 Rack awareness，这个就跟物理机部署一样了，但是是以云的方式交付给大家。这个工作 IaaS 提供商是可以做的，因为这些信息是可以拿到的。

三、大数据基础平台

接下来我们看看有哪些大数据平台以及它们的特点，从数据的生命周期来说分采集，传输，存储，分析计算以及展现几个阶段，上面这张图描述了这几个阶段现在比较流行的工具和平台。

首先讲讲计算，如 Spark、Storm、MapReduce 等，他们的区别主要在实时计算和离线计算，进而影响着各自的吞吐量。MapReduce 是老牌的大数据计算引擎，每个 Map、Reduce 阶段通过硬盘来进行数据的交互，对硬盘 I/O 要求比较高，速度也慢，所以适合离线计算，这就导致凡是跟 MapReduce 相关的东西都比较慢，比如 Hive。

Storm 实时性比较高，但吞吐量相对来说比较小，所以它适合实时小数据块分析计算场景。Twitter 号称 Heron 比 Storm 延迟更低，吞吐量更高，去年年底会开源，但我好像至今并没有看到更多的新闻，耐心期待吧。

Spark Streaming 更适合近实时较大数据块分析计算，Spark 是一个基于内存的分布式计算系统，官方上声称它比 Hadoop 的 MapReduce 要快 100 倍，其实 Spark 的核心是 RDD 计算模型以及基于全局最优的 DAG 有向无环图的编排方式，而 MapReduce 是一种着眼于局部的计算模型，直接导致了 Spark 即使基于硬盘也要比 MapReduce 快 10 倍。Spark 是一个很值得研究的平台，相信大家都知道它有多么优秀。

对于 SQL 分析来说现在主要分两大流派，基于 MPP 的数据仓库和 SQL-on-Hadoop。

现在看起来后者占了点上风，主要的原因之一是前者需要特定的硬件支持，不过 MPP 的数据仓库在传统行业还有很大市场，也很受传统行业的欢迎，因为它有 Hadoop 目前还没有的东西，比如真正意义上支持标准的 SQL，支持分布式事物等，使得 MPP 数据仓库能很好的集成传统行业现有的 BI 工具。另外，MPP 数据仓库也在向 Hadoop 靠拢，支持普通的 X86 服务器，底层支持 Hadoop 的存储，比如 Apache HAWQ。青云 3 月底的样子会提供 MPP 数据仓库服务，是由 HAWQ 的作者兼 GreenPlum 的研发人员和我们合作开发这个服务。SQL-on-Hadoop 就比较多了，比如 Spark SQL、Hive、Phoenix、Kylin 等等，Hive 是把 SQL 转换为 MapReduce 任务，所以速度比较慢，如果对运行速度有要求，可以尝试 Spark SQL，学起来也很简单，Spark SQL 1.6.0 的性能有很大提升，大家感兴趣可以体验一下。

还有基于 Hadoop 的 MPP 分析引擎 Impala、Presto 等等，我就不一一介绍了。需要注意的是有些项目还在 Apache 的孵化器里，如果想在生产环境中使用需加小心。这个地方有意思的是大家都跟 Hive 比，结论都是比 Hive 快多少倍，这个是肯定的，我们更想看到的这些新出来的 SQL 相互间比是怎么样的，别总拿 Hive 比，也许是小兄弟好欺负。

存储主要就是 Hadoop/HDFS、HBase、对象存储以及 MPP 数据仓库。Hadoop 是适合大文件一次性写入、多次读取的场景，不能写很多小文件，NameNode 很容易垮掉，如果非要写小文件的话可以网上搜一些小技巧。HBase 适合随机读写场景，它是一个 NoSQL 的分布式列式数据库，是一个 sparse、distributed、persistent、multidimensional sorted map，把每个单词理解透了就可以理解 HBase 是一个什么东西，它的底层用的还是 HDFS，不过在分析场景如 scan 数据的时候它的性能是比不上 Hadoop 的，性能差 8 倍还要多。HBase 强在随机读写，Hadoop 强在分析，现在 Apache 孵化器里有一个叫 Kudu 的“中庸”项目，就是兼顾随机读写和分析性能。HBase 想强调的一点的是数据模型的设计，除了我们大家都知道的 rowkey 设计的重要性之外，不要用传统的关系型数据库思维建模，在大数据领域里更多的是尽量 denormalize。

传输现在主流就是 Kafka 和 Flume，后者有加密功能，Kafka 需要在业务层做加密，如果有需求的话。Kafka 是一个分布式、可分区、多副本的高吞吐量低延迟消息系统，对于活跃的流式数据处理比如日志分析是最好不过的选择。

上图是我从一个真实客户的 kafka 实时监控图截取过来的，能看出流入流出的两个曲线完全重叠了，我们能看出它的延迟非常低（毫秒级别）。

但是我们不能滥用 Kafka，我曾经遇到过有人想用 Kafka 做分布式事务性的业务如交易，但 Kafka 并没有宣称它支持消息的传递是 exact once，它能做到是 at least once，所以分布式事务性的业务应该是不适合的，需要业务层做一些工作。

四、数据格式

最后一个我想强调的是数据格式，数据格式的正确选择对大数据怎么强调都不为过。选择错了会极大的浪费存储空间，大数据本来数据量就大，经不起成倍空间的浪费，性能也会因为格式选择错误急剧下降，甚至都无法进行。

数据格式要记住两点，可分割和可块压缩。可分割的意思就是一个大文件从中间切割，分析器还能不能单独解析这两个文件，比如 XML，它有 open tag 和 close tag，如果中间来一刀，XML Parser 就不会认识。但 CSV 就不一样，它是一个个的记录，每一行单独拿出来还是有意义的。

可块压缩指的是每个分割出来的块能否独自解压缩，这是因为前面说过的大数据是计算跟着数据走，所以每个节点的计算是分析本地的数据，从而做到并行计算。但有些压缩格式如 gzip，CSV 在解压的时候需要从第一分割块开始才能解压成功，这样就做不到真正的并行计算。

五、总结

最后总结前面讲的几个观点：大数据的发展方向是云化，云计算才是大数据基础平台最好的部署方案；大数据解决方案中应该根据你的需求来选择平台；数据格式的选择很重要，通常情况记住要选择可分割和可块压缩的数据格式。

陈海泉：SDN/NFV 2.0 架构的网络技术实践

arron — Mon, 18 Jan 2016 11:14:02 +0800

分享人： 陈海泉，青云 QingCloud 系统工程师

大家好，我是 QingCloud 的工程师陈海泉，今天给大家分享一些 SDN/NFV 2.0 架构的网络技术。

首先，说一下什么是 SDN，SDN 就是软件定义网络。当然也不是所有网络定制一定要软件来实现，因为有很多硬件方案也可以做到 SDN 的效果。

青云 QingCloud 用软件定义来实现虚拟网络，我们 2013 年的时候，在公有云上线了第一代产品。当时 SDN 还是一个比较新鲜的事情，用户用的还比较少，随着用户量越来越大，私有网络里面的 VM 数量超过一定的数量级的时候，我们发现性能就有一个比较大的损失，已经无法满足用户的需求。所以我们在去年下半年的时候，花了很大功夫去做 SDN/NFV 2.0 的事情。

VPC 是什么意思呢？VPC 网络是 QingCloud 环境内可以为用户预配置出的一个专属的大型网络。在 VPC 网络内，用户可以自定义 IP 地址范围、创建子网，并在子网内创建主机/数据库/大数据等各种云资源。

正是因为云计算需要虚拟网络，也需要 VPC。所以我们还需要定义一个 SDN 方案解决这两个需求，现有的 SDN 方案主要分成两个方向：

一是用软件来定义，但是用硬件来实现。比如某些带 SDN 功能的交换机，把它采购进来，部署到产品里，用硬件厂商提供的 API，在上面提供 SDN 功能。
二是 NFV，就是网络功能虚拟化，用软件的方式来实现，用软件的交换机和路由器，把他们组织起来成为一个软件实现的 SDN。其代表有 VMware NSX、Juniper OpenContrail 等等。

QingCloud 在 SDN 方案的选型上也做过讨论，用软件还是用硬件方案？其中考虑的问题主要是以下三个方面：

第一，成本。在公有云上面大家拼的是成本，谁的硬件成本低，谁就能把价格降到最低。如果我们采用现有的硬件方案，在网络设备上面增加了很多投资，并且我要采购的不是一个或者两个，而是一批。
第二，设备依赖。我们的私有云卖的是软件，客户可以按照偏好选择自己的硬件，假如 QingCloud 的 SDN 绑定了某款硬件产品，那我们在面对用户的时候，可能连招标的机会都没有，因为人家压根就没有办法用你的硬件。
第三，情怀。对于工程师来说，大家都想把产品做得更优秀。其实，软件跟传统快递行业非常的接近，为什么这么说。因为网络中的交换机、路由器，其实跟快递行业里的快递员和包裹集散中心非常相似，一般包裹给快递员以后，快递员会发给一个快递集散中心，这里可以查询包裹应该被送到哪个地方，然后再将包裹交给快递员，送到用户那里。顺丰在中国应该是最好的快递公司之一，因为它把转运环节都做全了，只有方方面面都能够控制才能实现压倒性的优势。因此，我们如果把数据包转发的每个流程都控制到，就有可能在系统上面做到最优，采用硬件设备使用这些功能的话，最后带来的是同质化，跟竞争对手相比不会有任何的优势。

综合以上三方面的原因，我们决定开发一套新的 SDN/NFV 2.0 方案，取代 1.0。

既然定了要自己做一套新的方案，怎么去实现？我们做了一些总结，新的产品需要满足传统 SDN 的需求。第一，数据封装。也就是实现一个基本的虚拟网络；第二，实现控制平面。二层、三层的网络数据进行路由规则的同步，然后下发到虚拟的交换机和路由器里面去，控制做到 ARP 泛洪抑制；第三，实现数据平面。除了 DVR 之外，还提供了虚拟边界路由器。

除此之外，还需要增加我们需要的 2.0 方面的功能。

第一，VPC 主机直接绑定公网 IP。私有云用户大量依赖基础网络，要求 VM 直接绑定公网 IP；
第二，负载均衡器。可对进入流量进行分流，出流量经由多台 Virtual Gateway (虚拟网关) 分担负载，单 IP 可承载 1 TB 出流量。同时，4—7 层完全透明；
第三，IP 不变。支持可以无限水平扩展的基础网络，并保持高可用及高性能，VM 任意迁移，IP 地址保持不变；
第四，VPC 和物理网络连接。

下面分别解释刚才说的那几个基础实现。

首先解释虚拟网络。在一些大公司里会提供一种叫内部邮递的服务。公司员工之间可以发送一种快递，比如要给财务部门某同事发一个报价单，会查他的工位，知道他坐在哪，比如 184-323-534。然后准备一个大信封，把要填的单子放在里面。我不需要知道这个人是在北京，还是在上海，我把这个信封交给公司的收发室，这个收发室会对这个信封进行重新封装，因为他有此员工的具体地址，然后把具有新地址的信封交给外包快递公司。放到云计算里，这就是一个虚拟网络。可以允许用户自己定义一个地址，然后进行传输，为了让它在三层网络里传输，可以再进行封装，再套一个包，写上新的地址。根据外包的内容和里层包的内容把这个数据包发送到对应的信息那里。

虚拟网络依赖于拆包、分包。现在采用的方案主要是比较流行的 VXLAN，因为 VXLAN 有一系列的优势。第一，隧道连接一组物理机，由于 VXLAN 的数据包在整个转发过程中保持了内部数据的完整，因此 VXLAN 的数据平面是一个基于隧道的数据平面；第二，使用 UPD 协议，当数据包交给网卡的时候，网卡根据这个数据的包头，用不同的网卡队列。这样把包交给不同的 CPU 处理，提升性能；第三，是比较有争议的 Flood & Learn 自动管理虚拟网络，VXLAN 可以进行泛洪学习，当 VTEP 收到一个 UDP 数据报后，会检查自己是否收到过这个虚拟机的数据，避免组播学习。

通过以上几点，我们觉得 VXLAN 不错，但是仔细的去想，就发现它有两个非常大的不足。一个是组播协议，大规模部署会受硬件设备组播路由限制；第二，泛洪学习的机制，会把原来在二层广播的 ARP 包扩大到三层网络，这样随着规模扩大，广播越来越多，会严重的浪费带宽资源。所以，我们既要使用 VXLAN，又要消灭它的不足，所以我们设置了 SDN 控制器，通过我们自己设置的规则，取代它自有的泛洪学习规则。

那么这个控制器需要多少个呢？我之前曾经了解过一些用户生产环境里用到的控制器，通常只有一个。它负责整个集群中所有节点的规则，这么做造成一个问题，当集群创建、销毁、迁移的时候，需要把规则同步到整个集群所有的节点中，这样随着用户秒级创建资源的需求，同步规则的流量就会相当相当大。所以我们做了一个分布式控制器，不仅把控制器分布到 VPC，还分布到虚拟网络里头。每个 VPC 有 253 个虚拟网络。

刚才说了虚拟网络和控制器，第三点 SDN 需要做的就是控制数据平面，其作用就是把数据包真的从一个地方拷贝到另外一个地方。传统的数据平面，比如 OpenStack 通常会用 OVS，OVS 会有一个问题，它会把数据交给另外一个程序，这样会带来一个性能的下降，而我们的方案完全改变了这个问题，自己做了一些 Kernel 的改动，将转发放到 Linux Kernel 上，而且我们是用 NFV 来实现的。

同时我们引入了一个新的功能叫做 DVR（分布式虚拟路由器）。通过上面的图解释一下我们为什么需要 DVR。左边是这张是物理拓扑图，物理世界中 A 和 B 通信，需要把信息发送到 A 的交换机，然后到路由器，然后路由器转给 B 的交换机，B 的交换机再发送给 B，A 和 B 通常需要 4 跳才能发一个数据包。

我们 1.0 的时候，也是用 NFV 实现的 SDN，我们会模仿物理世界，虚拟出虚拟的路由器和交换机提供给用户。如果 A、B、C、D、E 这五个设备分别位于五个不同的虚拟机上，在逻辑上 A 的包经过 C、E、D、B 才能到，逻辑上是四跳。但是虚拟设备每一跳都要通过物理设备去交换，而物理设备每一条四跳，这样总得转发量实际上需要 16 跳。这也就是为什么 1.0 的性能总是上不去。为了解决这个问题，我们引入了 DVR，从 A 到 B 还是这样，两个 DVR 之间直接交换一下数据就可以了，因为在逻辑上有一跳，所以总数跟原来物理设备一样，四跳完成一个数据包的转换，这样性能就可以非常接近物理机的性能，从而可以组成一个大的虚拟网络。

QingCloud 的 DVR 除了实现 VPC 简单的功能之外，它实际上是一个复杂的东西。因为除了保持自己跟自己的虚拟网络，还需要有其他四个方向：第一个就是网关需求，我们需要提高公网 IP 存储量，希望 DVR 把包发到公网网关；第二是 VPC 的虚拟机要能跟硬件设备进行高度的互访。因为我们私有云用户的机房里，不止有 QingCloud 的东西，还有 Oracle 的数据库、F5 的路由器等等，假如我们让用户把这些业务放到虚拟网络里，虚拟网络就要跟硬件网络进行高速的互访。第三是 VPC，可以让用户定义 255 个 C 段，加起来可以有 60000 多个虚拟机。第四是，我们还提供了一个边界路由器，可以让用户虚拟资源跟远程的 IDC 之间做一个互通。最后一个就是一个负载均衡器集群，我们的 DVR 就是一个平台，让用户的主机和负载均衡器直接相连。

我们做的最后一个功能就是负载均衡器集群。设计是这样，我们有一个网关集群连着因特网。比如我有一个 IP 1.1，实际上是绑定在 VG 1 这里，VG 1 会做第一次的流量转发，会把流量按照用户定义的负载均衡器节点数量转发到自己私有的负载均衡器节点里（1、2、3），它的特点就是，返回流量不需要经过进来的这个网关，而是经过自己对应的不同物理网关发送到因特网。因为当 VG 1 能力受到限制的时候，假如我们所有流量都从它回去的时候，它自己的网络带宽实际上就是整个集群的能力。而我们把它分散之后，就可以做到，出去的流量几乎是没有限制。只要我们的 VG 设备有多少，它的带宽就会有多少，因为流量不需要从默认的线路回去。同时随着用户拓展负载均衡器节点的数量，也扩展了 HTTPS 的卸载能力，并且我们做到了 4 层/ 7 层的完全透明，也就是说用户通过因特网访问到他们业务的时候，我们在所有转发过程中，都会保留其原地址，用户这边得到的包是直接来自因特网用户的 IP 地址。

[北京][2016年1月6日] QingCloud 2016 新年音乐会邀请你参加 (p.s. 暨庆祝 SDN/NFV2.0 发布)

arron — Mon, 21 Dec 2015 14:36:58 +0800

报名链接：http://www.huodongxing.com/go/qingcloud2016

忙忙碌碌又是一年。

忙碌的日子让我们更加丰富，成熟，接受了更多挑战，也取得了更大的成就。祝贺你所有的收获，更要道声：辛苦了！

2016 年新年伊始，我们诚挚邀请你参加 QingCloud 2016 新年音乐会，我们邀请了专业的交响乐团，为大家准备了将近 20 首经典曲目，包括电影大片与动画游戏，欢迎您来参加。

同时现场青云 QingCloud CTO Reno 还会分享 SDN/NFV 2.0 方面的相关技术实践。

QingCloud SDN/NFV 2.0

超大规模基础网络和私有网络
超高性能的网络通讯能力
更加强大和灵活的组网功能

这也是一场别开生面的发布会，我们精选了一场电影原声交响音乐会与你共贺新年。

时间 & 地点

会议时间：2016 年 1 月 6 日下午 13:30 签到会议地点：北京国际饭店（建国国际会议中心 - 紫金 B 厅）建国门内大街 9 号

一场惊喜等你邂逅。

百尺竿头，QingCloud 与你继续携手同行。

报名链接：http://www.huodongxing.com/go/qingcloud2016

雪球在股市风暴下的高可用架构改造分享 | 首席架构师亲述应对 30 倍峰值历程

arron — Sun, 16 Aug 2015 20:21:17 +0800

本文根据唐福林老师在“高可用架构”微信群所做的《股市风暴下的雪球架构改造经验分享》整理而成。

转自微信公众号 ArchNotes。

唐福林，雪球首席架构师，负责雪球业务快速增长应对及服务性能与稳定架构优化工作。毕业于北京师范大学，硕士学位。之前曾任微博平台资深架构师，微博技术委员会成员。长期关注并从事互联网服务后端性能及稳定性架构优化工作。

分享主题

一。雪球公司介绍二。雪球当前总体架构三。雪球架构优化历程四。聊聊关于架构优化的一些总结和感想

一。雪球公司介绍

雪球聪明的投资者都在这里。

web 1.0：新闻资讯，股价信息，K 线图
web 2.0：SNS 订阅，分享，聊天
web 3.0：移动 APP，交易闭环

雪球现在员工数还不到 100，其中技术人员占一半。去年 9 月 C 轮融资 4kw 刀。我们现在的技术栈由下列组件组成：Java，Scala，Akka，Finagle，Nodejs，Docker，Hadoop。我们当前是租用 IDC 机房自建私有云，正在往“公私混合云”方向发展。

在雪球上，用户可以获取沪深港美 2w+ 股票的新闻信息，股价变化情况，也可以获取债券，期货，基金，比特币，信托，理财，私募等等理财产品的各类信息，也可以关注雪球用户建立的百万组合，订阅它们的实时调仓信息，还可以关注雪球大 V。雪球当前有百万日活跃用户，每天有 4 亿的 API 调用。App Store 财务免费榜第 18 名。历史上曾排到财务第二，总免费榜第 19。

二。雪球当前总体架构

作为一个典型的移动互联网创业公司，雪球的总体架构也是非常典型的设计：

最上层是三个端：web 端，android 端和 iOS 端。流量比例大约为 2:4：4。web3.0 的交易功能，在 web 端并不提供。
接入层以及下面的几个层，都在我们的自建机房内部。雪球当前只部署了一个机房，还属于单机房时代。正在进行“私有云 + 公有云混合部署”方案推进过程中。
我们当前使用 nodejs 作为 web 端模板引擎。nodejs 模块与 android 和 ios 的 app 模块一起属于大前端团队负责。
再往下是位于 nginx 后面的 api 模块。跟 linkedin 的 leo 和微博的 v4 一样，雪球也有一个遗留的大一统系统，名字就叫 snowball。最初，所有的逻辑都在 snowball 中实现的。后来慢慢的拆出去了很多 rpc 服务，再后来慢慢的拆出去了一些 http api 做成了独立业务，但即便如此，snowball 仍然是雪球系统中最大的一个部署单元。
在需要性能的地方，我们使用 netty 搭建了一些独立的接口，比如 quoto server，是用来提供开盘期间每秒一次的股价查询服务，单机 qps 5w+，这个一会再细说；而 IM 服务，起初设计里是用来提供聊天服务，而现在，它最大的用途是提供一个可靠的 push 通道，提供 5w/s 的消息下发容量，这个也一会再细说。
雪球的服务化拆分及治理采用 twitter 开源的 finagle rpc 框架，并在上面进行了一些二次开发和定制。定制的功能主要集中在 access log 增强，和 fail fast，fail over 策略及降级开关等。finagle 的实现比较复杂，debug 和二次开发的门槛较高，团队内部对此也进行了一些讨论。
雪球的业务比较复杂，在服务层中，大致可以分为几类：第一类是 web1.0，2.0 及基础服务，我们称为社区，包括用户，帖子，新闻，股价，搜索等等，类比对象就是新浪财经门户 + 微博；第二类是组合及推荐，主要提供股票投资策略的展示和建议，类比对象是美国的 motif；第三类是通道，类似股市中的“支付宝”，接入多家券商，提供瞬间开户，一键下单等等各种方便操作的功能。
雪球的业务实现中，包含很多异步计算逻辑，比如搜索建索引，比如股票涨跌停发通知，比如组合收益计算等等，为此，我们设计了一个独立的 Thread/Task 模块，方便管理所有的后台计算任务。但随着这些 task 越来越多，逻辑差异越来越大，一个统一的模块并不是总是最佳的方案，所以，我们又把它拆成了两大类：流式的，和批量式的。
雪球的推荐体系包括组合推荐“买什么”和个性化推荐。我们最近正在重新梳理我们的大数据体系，这个感兴趣的话可以单聊。
最下面是基础设施层。雪球基础设施层包括：redis，mysql，mq，zk，hdfs，以及容器 docker。
线上服务之外，我们的开发及后台设施也很典型：gitlab 开发，jenkins 打包，zabbix 监控系统向 openfalcon 迁移，redimine 向 confluence 迁移，jira，以及内部开发的 skiing 后台管理系统。

** 三。雪球架构优化历程**

首先描述一下标题中的“股市动荡”定语修饰词吧：

上证指数从年初的 3000 点半年时间涨到了 5000 多，6 月 12 号达到最高点 5200 点，然后就急转直下，最大单日跌幅 8.48%，一路跌回 4000 点以下。最近一周都在 3900 多徘徊。

3 月最后一周，A 股开户 166 万户，超过历史最高纪录 2007 年 5 月第二周 165 万户。

4 月份，证监会宣布 A 股支持单用户开设多账户。

6 月底，证金公司代表国家队入场救市。

7 月份，证监会宣布严打场外配资。

7 月 27 号将近 2000 股跌停，IM 推送消息数超过平时峰值 300 倍

外网带宽消耗，一年 10 倍的增长

中国好声音广告第一晚，带来超过平时峰值 200 倍的注册量

挑战：小 VS 大：

小：小公司的体量，团队小，机器规模小大：堪比大公司的业务线数量，业务复杂度，瞬间峰值冲击

雪球的业务线 = 1 个新浪财经 + 1 个微博 + 1 个 motif + 1 个大智慧/同花顺。由于基数小，API 调用瞬间峰值大约为平时峰值的 30+ 倍。

挑战：快速增长，移动互联网 + 金融，风口，A 股大盘剧烈波动。

首先，在 app 端，在我们核心业务从 web2.0 sns 向 3.0 移动交易闭环进化的过程中，我们开发了一个自己的 hybrid 框架：本地原生框架，加离线 h5 页面，以此来支撑我们的快速业务迭代。当前，雪球前端可以做到 2 周一个版本，且同时并行推进 3 个版本：一个在 app store 等待审核上线，一个在内测或公测，一个在开发。我们的前端架构师孟祥宇在今年的 wot 上有一个关于这方面的详细分享，有兴趣的可以稍后再深入了解。

雪球 App 实践—构建灵活、可靠的 Hybrid 框架 http://wot.51cto.com/2015mobile/ http://down.51cto.com/data/2080769

另外，为了保障服务的可用性，我们做了一系列的“端到端服务质量监控”。感兴趣的可以搜索我今年 4 月份在环信 SM meetup 上做的分享《移动时代端到端的稳定性保障》。其中在 app 端，我们采用了一种代价最小的数据传输方案：对用户的网络流量，电池等额外消耗几乎为 0

每个请求里带上前一个请求的结果

succ or fail : 1 char
失败原因：0 - 1 char
请求接口编号：1 char
请求耗时：2 - 3 char
其它：网络制式，etc

炒股的人大多都会盯盘：即在开盘期间，开着一个 web 页面或者 app，实时的看股价的上下跳动。说到“实时”，美股港股当前都是流式的数据推送，但国内的 A 股，基本上都是每隔一段时间给出一份系统中所有股票现价的一个快照。这个时间间隔，理论上是 3 秒，实际上一般都在 5 秒左右。交了钱签了合同，雪球作为合作方就可以从交易所下属的数据公司那里拿到数据了，然后提供给自己的用户使用。

刚才介绍总体架构图的时候有提到 quote server，说到这是需要性能的地方。

业务场景是这样的，雪球上个人主页，开盘期间，每秒轮询一次当前用户关注的股票价格变动情况。在内部，所有的组合收益计算，每隔一段时间需要获取一下当前所有股票的实时价格。起初同时在线用户不多，这个接口就是一个部署在 snowball 中的普通接口，股价信息被实时写入 redis，读取的时候就从 redis 中读。后来，A 股大涨，snowball 抗不住了。于是我们就做了一个典型的优化：独立 server + 本地内存存储。开盘期间每次数据更新后，数据接收组件主动去更新 quote server 内存中的数据。后续进一步优化方案是将这个接口以及相关的处理逻辑都迁移到公有云上去。

对于那些不盯盘的人，最实用的功能就是股价提醒了。在雪球上，你除了可以关注用户，还可以关注股票。如果你关注的某只股票涨了或跌了，我们都可以非常及时的通知你。雪球上热门股票拥有超过 50w 粉丝（招商银行，苏宁云商）粉丝可以设置：当这支股票涨幅或跌幅超过 x%（默认 7%）时提醒我。曾经连续 3 天，每天超过 1000 股跌停，证监会开了一个会，于是接下来 2 天超过 1000 股涨停

原来做法：

股票涨（跌）x%，扫一遍粉丝列表，过滤出所有符合条件的粉丝，推送消息

新做法：

预先建立索引，开盘期间载入内存
1%：uid1，uid2
2%：uid3，uid4，uid5
3%：uid6
问题：有时候嫌太及时了：频繁跌停，打开跌停，再跌停，再打开。。。的时候

内部线上记录：

4 台机器。
单条消息延时 99% 小于 30 秒。
下一步优化目标：99% 小于 10 秒

IM 系统最初的设计目标是为雪球上的用户提供一个聊天的功能：

送达率第一
雪球 IM：Netty + 自定义网络协议
Akka：每个在线 client 一个 actor
推模式：client 在线情况下使用推模式
多端同步：单账号多端可登录，并保持各种状态同步

移动互联网时代，除了微信 qq 以外的所有 IM，都转型成了推送通道，核心指标变成了瞬间峰值性能。原有架构很多地方都不太合适了。

优化：

分配更多资源：推送账号 actor 池
精简业务逻辑：重复消息只存 id，实时提醒内容不推历史设备，不更新非活跃设备的 session 列表等等
本地缓存：拉黑等无法精简的业务逻辑迁移到本地缓存
优化代码：异步加密存储，去除不合理的 akka 使用

akka 这个解释一下：akka 有一个自己的 log adapter，内部使用一个 actor 来处理所有的 log event stream。当瞬间峰值到来的时候，这个 event stream 一下子就堵了上百万条 log，导致 gc 颠簸非常严重。最后的解决办法是，绕过 akka 的 log adapter，直接使用 logback 的 appender

线上记录：5w/s（主动限速）的推送持续 3 分钟，p99 性能指标无明显变化

7 月 10 号我们在中国好声音上做了 3 期广告。在广告播出之前，我们针对广告可能带来的对系统的冲击进行了压力测试，主要是新用户注册模块，当时预估广告播出期间 2 小时新注册 100 万

压测发现 DB 成为瓶颈：

昵称检测 cache miss > 40%
昵称禁用词 where like 模糊查询
手机号是否注册 cache miss > 80%
注册新用户：5 insert

优化：

redis store：昵称，手机号
本地存储：昵称禁用词
业务流程优化：DB insert 操作同步改异步

下一步优化计划：

将 sns 系统中所有的上行操作都改成类似的异步模式
接口调用时中只更新缓存，而且主动设置 5 分钟过期，然后写一个消息到 mq 队列，队列处理程序拿到消息再做其它耗时操作。
为了支持失败重试，需要将主要的资源操作步骤都做成幂等。

前置模块 HA：

合作方合规要求：业务单元部署到合作方内网，用户的敏感数据不允许离开进程内存
业务本身要求：业务单元本身为有状态服务，业务单元高可用

解决方案：

使用 Hazelcast In-Memory Data Grid 的 replication map 在多个 jvm 实例之间做数据同步。
java 启动参数加上 -XX:+DisableAttachMechanism -XX:-UsePerfData，禁止 jstack，jmap 等等 jdk 工具连接

关于前置模块，其实还有很多很奇葩的故事，鉴于时间关系，这里就不展开讲了。以后有机会可以当笑话给大家讲。

组合净值计算性能优化：

一支股票可能在超过 20 万个组合里（南车北车中车，暴风科技）
离线计算，存储计算后的结果
股价 3 秒变一次，涉及到这支股票的所有组合理论上也需要每 3 秒重新计算一次

大家可能会问，为什么不用户请求时，实时计算呢？这是因为“组合净值”中还包括分红送配，分股，送股，拆股，合股，现金，红利等等，业务太过复杂，开发初期经常需要调整计算逻辑，所以就设计成后台离线计算模式了。当前正在改造，将分红送配逻辑做成离线计算，股价组成的净值实时计算。接口请求是，将实时计算部分和离线计算部分合并成最终结果。

实际上，我们的计算逻辑是比较低效的：循环遍历所有的组合，对每个组合，获取所有的价值数据，然后计算。完成一遍循环后，立即开始下一轮循环。

优化：

分级：活跃用户的活跃组合，其它组合。
批量：拉取当前所有股票的现价到 JVM 内存里，这一轮的所有组合计算都用这一份股价快照。

关于这个话题的更详细内容，感兴趣的可以参考雪球组合业务总监张岩枫在今年的 arch summit 深圳大会上的分享：构建高可用的雪球投资组合系统技术实践 http://sz2015.archsummit.com/speakers/201825

最后，我们还做了一些通用的架构和性能优化，包括 jdk 升级到 8，开发了一个基于 zookeeper 的 config center 和开关降级系统

四。聊聊关于架构优化的一些总结和感想

在各种场合经常听说的架构优化，一般都是优化某一个具体的业务模块，将性能优化到极致。而在雪球，我们做的架构优化更多的是从问题出发，解决实际问题，解决到可以接受的程度即可。可能大家看起来会觉得很凌乱，而且每个事情单独拎出来好像都不是什么大事。

我们在对一个大服务做架构优化时，一般是往深入的本质进行挖掘；当我们面对一堆架构各异的小服务时，“架构优化”的含义其实是有一些不一样的。大部分时候，我们并不需要（也没有办法）深入到小服务的最底层进行优化，而是去掉或者优化原来明显不合理的地方就可以了。

在快速迭代的创业公司，我们可能不会针对某一个服务做很完善的架构设计和代码实现，当出现各种问题时，也不会去追求极致的优化，而是以解决瓶颈问题为先。

即使我们经历过一回将 snowball 拆分服务化的过程，但当我们重新上一个新的业务时，我们依然选择将它做成一个大一统的服务。只是这一次，我们会提前定义好每个模块的 service 接口，为以后可能的服务化铺好路。

在创业公司里，重写是不能接受的；大的重构，从时间和人力投入上看，一般也是无法承担的。而“裱糊匠”式做法，哪里有性能问题就加机器，加缓存，加数据库，有可用性问题就加重试，加 log，出故障就加流程，加测试，这也不是雪球团队工作方式。我们一般都采用最小改动的方式，即，准确定义问题，定位问题根源，找到问题本质，制定最佳方案，以最小的改动代价，将问题解决到可接受的范围内。

我们现在正在所有的地方强推 3 个数据指标：qps，p99，error rate。每个技术人员对自己负责的服务，一定要有最基本的数据指标意识。数字，是发现问题，定位根源，找到本质的最重要的依赖条件。没有之一。

我们的原则：保持技术栈的一致性和简单性，有节制的尝试新技术，保持所有线上服务依赖的技术可控，简单来说，能 hold 住。能用 cache 的地方绝不用 db，能异步的地方，绝不同步。俗称的：吃一堑，长一智。

特事特办：业务在发展，需求在变化，实现方式也需要跟着变化。简单的来说：遗留系统的优化，最佳方案就是砍需求，呵呵。当前，雪球内部正在推行每个模块的方案和代码实现的 review，在 review 过程中，我一般是这样要求的：

技术方案：

20 倍设计，10 倍实现，3 倍部署
扩展性：凡事留一线，以后好相见

技术实现：

DevOps：上线后还是你自己维护的项目，实现的时候记得考虑各种出错的处理
用户投诉的时候需要你去解释，实现的时候注意各种边界和异常
快速实现，不是“随便实现”，万一火了呢：性能，方便扩容

Q&A

Q1：im 能详细讲下吗？

关于雪球 im 和推模式，有群友问到了，我就再展开讲一下（其实下周我约了去给一家号称很文艺的公司内部交流 IM 实现）：雪球自己设计了一套 IM 协议，内部使用 netty 做网络层，akka 模式，即为每一个在线的 client new 一个 actor，这个 actor 里面保持了这个在线 client 的所有状态和数据。如果有新消息给它，代码里只要把这个消息 tell 给这个 actor 即可。actor 里面会通过 netty 的 tcp 连接推给实际的 client。

Q2：问一个小问题，App 的接口可用上报里如果是网络问题引起的故障怎么兼容？

app 如果发起一个请求，因为网络问题失败了（这其实是我们的上报体系设计时，最主要针对的场景），那么 app 会把这个失败的请求记录到本地内存，等下一次发请求时，把上次的这个失败请求结果及相关信息带上。如果连续多次失败，当前我们的做法是，只记录最后一次失败的请求结果，下次成功的请求里会带上它。

Q3：监控系统为何从 zabbix 切换到 openfalcon，原因是什么？

简单来说，机器数上百之后，zabbix 就会有很多问题，个人感受最大的问题是，新增 key 非常不方便。小米因为这些问题，自己做一个 falcon，然后开源了。我们碰到的问题很类似，看了看小米的，觉得可以不用自己再折腾了，就用它了。

Q4：前置模块的 Hazelcast In-Memory Data Grid 的稳定性怎么样，采用的考虑是什么呢？用 sharding redis 怎么样呢？

稳定性不能算很好，只能说还好。因为上线几个月，已经出了一次故障了。采用它，主要是开发简单，因为它就只有一个 jar 包依赖，不像其它备选项，一个比一个大。至于为什么不用 redis，因为这是要部署到别人的内网的啊，更新很麻烦的啊，运维几乎没有的啊，各种悲剧啊。我们当前为了做到“一键更新”，把 shell 脚本和所有 jar 包都打成一个自解压的文件这事我会随便说吗？

Q5：雪球 im 如何判断用户是否在线？要给给定的用户发消息，怎么找到对应的 actor？不在线的时候消息如何存储？

IM 用户在线判断（转化成指定的 actor 是否存在）和路由，这些都是 akka 内置提供的，感兴趣的，算了，我个人建议是不要去碰 akka 这货。用户不在线的时候，消息会进 mysql 和 redis

Q6：大师，为了支持失败重试，需要将主要的资源操作步骤都做成幂等。这个怎么理解，具体怎么玩？

举个例子：用户发一个帖子，api 调用的时候已经给用户返回成功了，但后端写 db 的时候超时了，怎么办？不能再告诉用户发帖失败了吧？那就重试重试再重试，直到写 db 成功。但万一重试的时候发现，上次写入超时，实际上是已经写成功了呢？那就需要把这个写入做成幂等，支持多次写入同一条记录。简单来说，db 层就是每个表都要有业务逻辑上的唯一性检查

Q7：另外用户对应的 Actor 需不需要持久化呢？

actor 不持久化。重启 server 的话，app 端会自动重连的

Q8：基于 zookeeper 的 config center 设计有什么指导原则或遇到什么坑吗？如何方便业务开发修改又不影响到其他？

我们的 config center 有两个版本：一个是参考 netflix 的 archaius，另一个是纯粹的 zk style。风格问题，我个人的回答是：大家喜欢就好。config center 本来就不影响业务开发修改啊？没有太明白问题点，sorry

Q9：刚才的追问下如果只报最后一次故障那么会不会不能准确评估影响？

不会的，因为这种情况一般都是用户进电梯或者进地铁了，呵呵

Q10：rpc 是怎么选的呢，比如为什么不用 thrift 呢？

finagle 底层就是 thrift 啊。就我个人而言，我个人对于任何需要预先定义 proto 的东西都深恶痛绝。所以现在我们也在尝试做一个基于 jsonrpc 的简单版本的 rpc 方案，作为我们后续微服务容器的默认 rpc

Q11：实质上是用 actor 包住了 netty 的 session 吧？不建议用 akka 的原因是量大了后承载能力的问题吗？雪球 im 的 dau 约在 50 万左右吧？

是的，actor 内部持有网络连接。不建议用 akka 的原因是：我个人的原则是，我 hold 不住的东西就不做推荐。就当前来说，我觉得我 hold 不住 akka：使用太简单太方便，但坑太多，不知道什么时候就踩上了，想用好太难了

Q12：唐老师您好，雪球的架构中，rabbitmq 主要用在哪些场景，rabbit 的负载是通过哪些手段来做呢？

当前我们的 mq 功能都是有 rabbitmq 提供的，我们在内部封装了一个叫 event center 的模块，所有的跟 queue 打交道的地方，只需要调用 event center 提供的 api 即可。我们对于 rabbit 并没有做太多的调优，大约也是因为现在消息量不大的缘故。后续我们的大数据体系里，queue 的角色会由 kafka 来承担

Q13：大师，能说说 akka 为啥不推荐么

看上面问题 12

Q14：唐大师，关于交易这块，能说下你们的账户体系吗？

股票交易跟支付宝模式还是很大不一样的，本质上，雪球上只是一个纯粹的通道：钱和股票都不在雪球内部。所以，我们当前的账户体系就像我们页面上描述的那样：将用户的券商账号跟雪球 id 做绑定

Q15：性能规划上有什么经验或者推荐资料阅读吗？谢谢。

通读 allthingsdistributed 上的精华文章 http://www.allthingsdistributed.com/

Q16：唐大师，雪球的 docker 是怎么用？怎么管理的？

参考雪球 sre 高磊在 dockercn 上的分享

Q17：追加一个问题：对业务合规要求的需求不是很了解，但是“-XX:+DisableAttachMechanism -XX:-UsePerfData”这样无法禁止“jstack -F”的吧，只是禁止了普通的 jstack。

应该是可以禁止的，因为 jvm 内部所有挂载机制都没有启动，jstack 加 -f 也挂不上去。要不我一会测一下再给你确认？

Q18：帮我问个问题：这么多系统，如何保证迭代保质保量按时交付？

这就要感谢我们雪球的所有技术，产品，运营同事们了 [Tongue]

Q19：为什么用 kafka 替换 rbt?

因为 rbt 是 erlang 写的啊，我不会调优啊，出了问题我也不会排查啊。事实上，event center 模块极偶发的出现丢消息，但我们一直没有定位到根源。所以，只好换了

Q20：请问百万活跃用户 session 是怎么存储的？怎么有效防止大面积退出登录？

用户登录 session 就存在 jvm 内部。因为是集群，只要不是集群突然全部挂，就不会出现大面积重新登录的

Q21：每个请求里带上前一个请求的结果，这个得和用户请求绑定上吧？

收集 app 端的访问结果，大部分情况下用于统计服务质量，偶尔也用于用户灵异问题的追逐

Q22：akka 的设计居然和 Erlang 的抢占式调度很像，也存在单进程瓶颈问题？

可以这么说，主要是它的 log actor 是单个的

Q23：集群环境下如何保存在 jvm 内部？各个 jvm 如何共享的？

我们的 im 系统其实分 2 层，前面有一层接入层，后面是集群。接入层到集群的链接是按 uid 一致性 hash。简单来说，一个用户就只连一个 jvm 服务节点。所以我们只在收盘后更新服务。在雪球，盘中严禁更新服务的

Q24：接入层的实现架构方便描述一下吗？

雪球 IM 的接入层分为 2 类：app 接入层和 web 接入层。app 接入层是一个 netty 的 server，开在 443 端口，但没有使用 ssl，而是自己用 rsa 对消息体加密。netty 收到消息后，解包，根据包里的描述字段选择发往后端的业务节点。web 接入层是一个基于 play 的 webserver，实现了 http 和 websocket 接口，供 web 使用。

青云 QingCloud 讨论组欢迎你：https://community.qingcloud.com

[北京][2015年7月22日] Future is Now | 和 QingCloud 一起，拥抱技术与爱

arron — Fri, 26 Jun 2015 13:18:43 +0800

再过一个月 qingcloud.com 就满两周岁了。2013 年 7 月，一个叫做“青云”的公有云平台悄然上线，一个没几个人关注的、叫做“青云 QingCloud”的公众小号在微博上喊出了一个大理想——“云计算将改变无序的、不合理的 IT 生态环境。”彼时，中国的云计算市场还是 VPS 的天下，CIO 们关于“云计算究竟是什么”的讨论正风生水起。

理想是一粒种子，在真诚与勤奋的浇灌下才会生根发芽。感谢你见证和陪伴我们的成长，同我们一起推动中国云计算行业的技术进步，建立市场信心。今天，我们真诚地邀请每一位家人共度 QingCloud 的节日，分享我们共同成长的故事，体会技术的魅力，展望科技创新的未来。

青是彩虹的颜色，云是天空的梦想。2015 年 7 月 22 日，北京千禧大酒店，“Future is Now. 首届 QingCloud 用户大会” ，QingCloud 邀你加入这场技术与爱的狂欢。

报名地址：http://www.huodongxing.com/event/6288231027000

大会亮点

QingCloud 多项重磅新功能和重要消息发布；

互联网各行业明星用户共话云计算与互联网金融、云生态与互联网创业等当下热门话题；

知名企业 IT 变革与创新先行者分享云计算促进企业 IT 转型和业务创新经验；

网络知名博主、技术大咖现身互动。

大会嘉宾更多嘉宾确认中

会议日程 - 上午 AM

3 位创始人携众多嘉宾为你讲述技术的故事

QingCloud 工程师倾情发布重量级新功能

QingCloud Family Recruitment

One more thing — Big News

会议日程 - 下午 PM

Forum A: Cloud Computing and Innovation

创新者行：QingCloud 携互联网各行业明星用户共话云计算与大数据、互联网金融、原生 App 与创业等话题，讲述创业故事；

Forum B: Cloud Computing, New Enterprise IT

先行者知：QingCloud 将邀请知名企业中 IT 变革与创新的先行者们分享云计算促进企业 IT 转型和业务创新的经验，共同展望“互联网+”和“DT”时代科技发展的新趋势。

更多惊喜

大会日期、地点

时间：2015 年 7 月 22 日（全天）

地点：北京千禧大酒店北京市朝阳区东三环中路 7 号

交通：地铁 10 号线金台夕照站 A 口出西行 100 米即到

购票说明

您可以使用邀请码免费参会。QingCloud 用户请查看注册邮箱查询（有可能散落在你的垃圾箱里，把它找回来吧）；

您也可以现在注册 QingCloud 用户免费参会，在 QingCloud 确认邮件中获取邀请码（可登录 qingcloud.com 注册）；

如果您选择付费购票，并在购票时输入 QingCloud 注册邮箱，活动当天签到确认后将获得票款 2 倍金额的 QingCloud 账户充值赠送。我们会在会议结束 10 个工作日内完成充值。同一个 QingCloud 账户最多可获得 100 元充值赠送。

arron (青云QingCloud)

一个小攻略：如何最大化利用青云 QingCloud 特价机型

1. 准备工作环境

1.1. EIP

1.2. Docker

2. 运行 nextcloud

3. 优化 nextcloud

3.1. 禁止没啥用的 apps

3.2. cron job

4. nextcloud 客户端

5.（可选的）极致省钱操作

5.1. 使用 IPv6 EIP

5.2. 使用对象存储

数字化转型，我们需要什么样的超融合

内容摘要

需求升级，价值分层

选错起点，失去未来

破解难题，自由升级

从云上来，向云生长

学习最新最全的云计算技术干货

免费送课啦～让程序员多活几年的 Region 及多活方案分享：)

给同学们的提问福利：

地点：千聊知行学院，扫码即可报名👇

推荐大家一个零基础音视频课程，贼详细

主题：零基础学习音视频技术及场景应用

时间：10 月 18 日 20:00 —— 21:30

地点：千聊知行学院，扫码即可报名👇

本期内容介绍：

提问福利：

看到这了难道还不来听课飙车嘛！干货&红包等你来拿呀！

运维工程师的逆袭——云资源的管理与维护

主题：运维工程师的逆袭——云资源的管理与维护

时间：9 月 27 日 20:00 —— 21:30

地点：千聊知行学院，扫码即可报名👇

讲师：

本期内容介绍：

提问福利：

来聊聊对象

具体内容包括：

点这里，有对象

点这里，有对象

除了实践干货，还有精美礼品可以拿

除了实践干货，还有精美礼品可以拿

干货云集，让你不虚此行

你将收获什么

行业：聚焦多行业应用实践、内容维度更深入

能力：核心技术拆解、认知提升更全面

前瞻：把握产业走向和发展趋势。

人脉：深度沟通，解锁行业人脉圈

适合人群

构建下一代企业级架构，开启全模云时代。1月10日 在深圳等你来一探究竟

「我们本来就是一群很酷的人，为何不一起来做一些很酷的事情呢？」

青云 QingCloud 实践课堂走进 [杭州、成都、重庆、上海、昆明] ，这里有关于容器、关于大数据、关于对象存储、关于企业级应用等等你想要的干货～

自动化代码生成工具 Snips 开发实践

自动化代码生成工具 Snips 开发实践

前言

1. QingStor SDK 简介

2. QingStor SDK 的开发流程

3. API Specification

4. 代码生成工具 Snips

5. 场景化测试

6. 使用 Snips 开发 QingStor Go SDK

7. 开发者激励活动

基于云计算的大数据平台基础设施建设实践 排序

一、云计算与大数据

二、云上大数据平台建设的挑战

三、大数据基础平台

四、数据格式

五、总结

更多内容community.qingcloud.com

陈海泉：SDN/NFV 2.0 架构的网络技术实践

[北京][2016年1月6日] QingCloud 2016 新年音乐会邀请你参加 (p.s. 暨庆祝 SDN/NFV2.0 发布)

报名链接：http://www.huodongxing.com/go/qingcloud2016

报名链接：http://www.huodongxing.com/go/qingcloud2016

QingCloud SDN/NFV 2.0

时间 & 地点

报名链接：http://www.huodongxing.com/go/qingcloud2016

雪球在股市风暴下的高可用架构改造分享 | 首席架构师亲述应对 30 倍峰值历程

[北京][2015年7月22日] Future is Now | 和 QingCloud 一起，拥抱技术与爱

构建下一代企业级架构，开启全模云时代。1月10日在深圳等你来一探究竟

基于云计算的大数据平台基础设施建设实践排序