一文看懂静态资源服务沉浮及其在携程的演进( 八 ) _静态资源服务

这一次我们放弃了静态应用的执念，大胆采用了 Nginx + Node.js + CEPH 的应用架构。作为一种分布式对象存储系统， CEPH 的读写性能、可用性和可扩展性，都合乎静态资源内容存储的需求。而选择 Node.js ，是因为它更靠近前端技术栈，并且携程的技术团队在利用 Node.js 开发 Web 应用方面也已经积累了不少经验。为了将两者相结合，我们事前作了认真的准备，开发了以下 NPM 模块：
(1) ceph
云存储访问 SDK 。基于 CEPH Web API ，提供对象读写和查询功能，目前已兼容 AWS S3 和 Aliyun OSS 。
(2) ceph-sync
云存储同步 SDK 及命令行工具。可在本地文件系统和云存储之间、以及不同厂商的云存储之间实现容器级别的数据同步，支持断点续传。
(3) ceph-cli
云存储管理工具。提供在命令行中完成容器创建和清理、对象查询和删除、文件（对象）上传和下载等功能。
(4) ceph-agent
云存储浏览器。该模块可以启动一个Web 服务，方便开发者在浏览器中浏览存储中的内容。
上述模块目前都已开源。
所谓欲善其事，先利其器。这些工具在我们的工作发挥了重要的作用。利用 ceph-sync ，我们顺利完成了千万量级静态资源文件的上云，差错率接近于零。在携程， ceph 模块日均完成数以万次计的对象写入和数以亿次计的对象读取操作，没有成为瓶颈，其可靠性也经受住了考验。
使用携程私有云存储的过程中所积累的经验，为过渡到公有云存储铺平了道路。现在，我们已经实现了 Ceph（携程私有云）+ AliyunOSS（境内）+ AWS S3（境外）三位一体的静态资源同步存储方案。

文章插图

基于存储的源服务架构
经过这次重构，静态资源服务也完成了另一种意义上的动静分离，即数据（资源文件）和应用的分离，从而实现了应用的标准化，可以借助携程的 PaaS 系统轻松完成应用部署。换句话说，源站应用也真正地上云了。有了基于 Node.js 开发的源站应用，我们足以应对有关静态资源服务的种种个性化需求，再也不需要在中间件配置这个逼仄的空间中苦苦挣扎。原先分拆的若干应用，也重新合兵一处，不仅节约了可观的硬件资源，也终于消化了长期以来的运维压力。大家都松了口气。
七、国际化背景下的布局随着携程业务日趋国际化，境外用户的访问体验越来越受到重视。在新的背景下，用户的地域分布越来越广泛，而集中程度疏密不一，如何面向全球用户提供更好的静态资源服务，需要我们作出一些改变。
尽管 CDN 可以显著提升终端用户获取静态资源的速度，但是它不可能卸载所有的请求，仍然有一部分请求需要回源。同时，在新场景、新业务的需求驱动下，应用程序的迭代更快，相关的静态资源也在不断推陈出新，从而触发更多的回源请求。针对回源请求的优化，是一个长尾问题。美洲、欧洲、非洲国家与我国地理上的遥远距离，无论怎么优化路由，网络响应都存在100~200毫秒的延时。虑及于此，我们决定将源站建在离CDN 边缘节点更近——也就是离我们的终端用户更近——的地方。
2019年中，依托于 AWS 公有云平台，携程的前端基础设施团队已在法兰克福、蒙特利尔、新加坡城部署静态资源源站，分别连接欧洲和非洲、美洲、东南亚地区的 CDN 边缘节点，形成了一个微型的内容传输矩阵。上一节中提到过三位一体的静态资源同步存储方案，其中位于 AWS S3 的部分包括三个相应区域（Region）的存储容器，就是作为上述源站应用的配套数据源而存在的。这些源站虽然不直接面向终端用户，但确实改善了一部分人的访问体验，也减缓了发布期间的网页性能波动。