时间：2023-07-28 06:30:01 | 来源：网站运营
时间：2023-07-28 06:30:01 来源：网站运营
基于Serverless的个人建站方案的实现：对象存储（Cloud Object Storage，COS）是腾讯云提供的一种存储海量文件的分布式存储服务，用户可通过网络随时存储和查看数据。腾讯云为其提供了多项技术进行辅助，以实现更好的性能优化，例如CDN。所以在本方案中Serverless主要代表了两个观点：前端项目的上线不再强依赖于服务器（面向服务器开发和运维），同时需要的原有后端服务交给Serverless服务商。
云存储是本次研究的核心内容之一。云存储如其字面含义，是基于云服务的存储服务，其功能是常见服务器的一部分：存储。通过云存储，可以实现静态资源在多个地域完成部署，配合CDN则可以实现非常优秀的访问体验。
内容分发网络（Content Delivery Network，CDN）是在现有网络中增加的一层新的网络架构，由遍布全球的高性能加速节点构成。这些高性能的服务节点都会按照一定的缓存策略存储您的业务内容，当用户向某一业务内容发起请求时，请求会被调度至最接近用户的服务节点，直接由服务节点快速响应，有效降低用户访问延迟，提升可用性。
分发网络是本次研究的另外一个核心内容，其技术也经常被使用在性能优化层面，而Serverless架构则无疑为CDN提供了更好的服务基础。通过CDN，可以实现快速的更换分发地域以及分发内容，始终保持极佳的状态以应对用户的访问。
CDN是一个非常复杂的技术，也有诸多学术论文和工程经验，在此不再过多阐述。
Serverless 计算是一种云计算执行模型，其中云提供商按需分配机器资源，代表其客户管理服务器[1]。严格来说，Serverless并没有一个绝对清晰的概念或定义，所以Serverless往往被扩展为两个类似但又不尽然的概念：Serverless计算（服务）与Serverless 架构。
Serverless并不是一个真实存在的软件服务或者是物理设备，而是一个理念和一种思维方式。受限于传统的B/S模式，的思维定式告诉一个部署上线的项目一定需要与之配套的服务器及其服务。而Serverless则打破了这种思维定式。在服务上，服务可以被通用或量化甚至是商业化，由传统的定制开发转化为通用开发；在结构上，则彻底“消除”服务器这一概念，转变为第三方服务商。
值得一提的是，Serverless实际上也是基于B/S模式的，其概念也并不是语义上的“无服务器”，而是指的是由其他的服务替代传统的服务器，从而减轻技术团队的后端开发压力，甚至是不再开发后端功能。
传统方式一般会将资源保存在本地服务器上，通过相对路径的方式进行访问。或者，会使用云服务来减缓服务器压力。
示例项目则不同，在Serverless的基础上，浏览器会通过一个entry.json文件访问云服务服务器。总结一下，
首先，示例项目是部署在云端的，这就意味着当想要对其进行修改或重新部署会有一定的不便，必须通过第三方服务平台进行相关操作。通常来说，这都意味着对一个项目进行重新打包，又或者是由平台的重新部署。这样做的隐患，则是当意识到项目出现bug或遇到错误时，无法像拥有后端服务器的项目一样直接修改相关内容，这可能会导致非常大的损失或安全问题。
为了规避这个隐患，示例项目将数据与视图再一次的分离，只不过这一次的分离是物理意义上的。当用户访问示例项目时，浏览器通过解析代码会向基础COS服务发送一个get请求，以获取到最新的entry.json文件。通过解析entry.json文件，浏览器会获得其他entry.json文件的地址，从而获得示例项目所需的所有静态资源的地址以及其他属性，至此框架即可按照其需求针对不同的组件获取不同的静态资源。对于访问CDN也是类似的方式，CDN与COS之间还有一套自有的回源方案，从而确保访问到正确的静态资源。
重要的是，在上文举出的例子中，开发者现在可以完全自由地修改任意一部分内容，因为这个方案在不经意间实现了完全解耦。当开发者想要修改页面样式和逻辑时，仅需要对代码仓库进行对应操作，而不需要处理静态资源；当开发者想要修改静态资源时，例如为示例项目的首页功能加入一个新的插图，又或者是在回答和文章中加入新的内容，开发者仅需要修改对应的entry.json，并维护COS和CDN即可，而不需要关心页面样式和逻辑。
至此，示例项目地静态资源已经可以基于COS和CDN成功托管，并通过entry.json实现解耦状态下的运维。对于用户来说，什么都没有改变；而对于开发者来说，一切都在云端。
因为entry.json是面向JavaScript的，所以将所有的数据存储为对象或树会更为实用。
Vercel是一个面向前端开发者的部署和协作平台。Vercel将前端开发者放在首位，为他们提供了构建高性能网站和应用程序的综合工具。[2]。如果你没怎么使用过Vercel并且也没看懂我说了什么，暂且认为Vercel非常强就可以了。
本研究的研究方向在Vercel中得到了完美的体现，而Vercel的业务也是向用户提供Serverless服务。其核心功能依然是类似GitHub Pages的静态资源部署功能，但实际上其拓展已经远远超越了GitHub Pages，例如其原生支持云函数、云数据库等公有云服务，同时支持商业服务。
Vercel的静态资源部署功能也与其他平台不同。对于GitHub等平台来说，部署的静态资源本质上是一个传统的基于HTML和CSS以及JS的简单站点。为了实现这一点，就需要开发者手动对其开发的项目进行打包，并再次进行托管后部署。
这种方式听起来并没有什么问题，因为传统的B/S模式中，在服务器上都是如此操作的（暂不讨论服务器渲染（SSR））。而这种部署方式的优点是可以保持源代码的稳定，防止在服务器端遭到攻击或篡改，源码将会被很好的隐藏。但对于本研究的Serverless方向，这种方式显得有些许捉襟见肘。例如，因为本研究的部署方式并不会有服务器操作，那么就会需要对项目源代码和项目打包文件开辟两个代码仓库进行托管，甚至是需要在腾讯云等平台的静态资源部署中维护一个额外的部署服务。此时，源代码依旧是在云端的，且当想要更新代码时，就需要重新操作部署服务。这种方式对于个人开发者来说显得过于沉重，甚至是在使用静态资源部署服务，这种已经使用了部分Serverless思想的部署方式时依然会带来不便。
Vercel解决了这个问题。Vercel除了支持部署这种经打包处理的代码以外，还支持直接对源代码进行部署。当通过GitHub授权后，Vercel会自动从GitHub拉取仓库代码，并在服务器端进行打包操作，并将打包后的代码部署到Vercel的服务器上，以供用户访问；当在GitHub端更新代码或合并分支后，Vercel也会对GitHub仓库进行监听和检测并执行上述操作，从而实现完全自动化的部署方式。
Vercel的功能是强大的，但是其业务更倾向于部署，而不是完整的公有云服务。Vercel也有一定的缺陷，其目前执行的是偏向于免费的开源策略，这导致其服务的具体范围受限，对于商业需求来说可能不是非常友好。Vercel也包含商业服务，因为其与本研究研究方向不符，故不在部署方式中进行研究。
GitHub Pages
GitHub Pages的设置相对来说较为简单。当用户在代码仓库托管了一个站点代码后（需要index.html文件作为入口），即可成功开启GitHub Pages功能。GitHub会在用户指定的代码分支中寻找index.html，并将该文件作为整个站点的入口，继而用户可以即可通过GitHub分配的域名访问。除了GitHub默认分配的域名，用户也可以根据自己的实际情况自定义域名，并在DNS中进行对应配置即可使域名生效。GitHub Pages是近些年兴起的一个全新产品，它为全球数以千万计的开发者提供了一个更为便捷的站点部署方式，适用于几乎所有的个人博客和开源项目主页，又或者是API文档等。GitHub Pages还可以和Hexo或VuePress等静态文档框架相结合，将枯燥的Markdown或其他类型的文档生成为生动形象的静态页面，并一键式的部署上线，广受好评。GitHub Pages自身也支持Jekyll主题。
GitHub Pages似乎非常符合本研究的目标，但遗憾的是，GitHub Pages因为其服务器问题，导致中国大陆访问十分不稳定。但即使如此，绝大多数开源项目和个人博客均采用了这种方式。
腾讯云（静态页面）
以腾讯云为代表的诸多公有云服务上几乎都提供了自家的静态页面部署服务，其核心内容与GitHub Pages类似，但使用起来略有不同。腾讯云没有打造自己的代码仓库，而是将静态页面服务部署到了自家的COS服务以及Serverless服务。在COS中，用户可以将站点部署，并开启静态页面功能，即可使用腾讯云分配的域名进行访问。
相对于GitHub Pages来说，公有云服务商提供的相关服务要远远强大得多。例如，虽然腾讯云也支持对域名进行自定义配置，但是腾讯云还可加入重定向规则和错误文档，而配合其他云服务使用还可以实现ECDN（全站加速服务，将整个站点分发给CDN而不是某个静态文件）。
腾讯云的静态页面服务并不是完全免费的。虽然腾讯云的功能更为强大，但是如果将一个开源项目的静态站点部署在腾讯云，则意味着必须有人承担对应的流量和存储费用。在2.4节中已经提到，本研究不会将具体的价格作为对比的因素之一，但是对于一项服务是否能够长时间免费提供，依然值得被开发者纳入讨论范围内。
GitHub + 腾讯云（COS与CDN）
将项目中的静态资源部署到腾讯云的COS服务中，并使用CDN以达到更好的性能，这也是目前一种常见的方式。绝大多数开源项目会使用额外的CDN服务以满足其他区域的访问问题，CDN服务可能来自于不同的服务商。
总体来说实际的部署与设计不会有非常大的差异，但非常重要的一点是开发者需要根据实际的业务选择是否要进行额外的Serverless分发方式。对于部分内容，例如由框架编译出的.js文件，几乎无法被存储与COS或CDN，这可能会对站点带来非常大的不确定性，而如果此时已经引发了性能问题，则原因极有可能出现在如GitHub Pages等服务商上。
这种部署方式非常适合一些用作展示的项目，例如一个在线的电子相册或是作品集。COS与CDN更适合去存储和分发一些高频使用，但又不会经常修改的中大型文件，最为常见的就是多媒体内容。如果浏览器因为许多个小文件而不断向远端发送请求，这本身也会导致用户客户端的性能问题。
混合使用的方式会带来较大的便利，现在开发者可以专心于开发新功能或更新新的静态资源，而不是同时去做两件事。
腾讯云（静态页面） + 腾讯云（COS与CDN）
因为COS特性，开发者其实可以将静态资源和站点部署在同一个存储桶内。
如果将代码托管（本节为部署）和Serverless服务选择为相同的运营商，则可能会带来如此的便利。腾讯云可以非常容易地对站点进行分发，又或者是对一些资源进行分发，并在加以其他的云服务或是Serverless服务，即可实现一个较好的展示方式。
当静态资源被部署在相同的桶内时，对于用户来说访问的过程依然是通过远端获取数据，这可能会导致网络不畅的用户遭遇到中国大陆用户使用GitHub Pages遇到的问题，这两个问题的本质是相同的，用户的网络性能受限于服务器与用户之间的物理距离。在使用额外的COS与CDN服务时，即可以针对不同的用户进行优化。但遗憾的是，如果CDN服务较为单一，用户则可能会面临着绕远或难以命中的状态。对于这种隐患，则需要开发者继续优化网络服务，选择扩大CDN服务的范围，或者是修改前端项目的业务逻辑，根据用户所处地域而强制分配访问的具体服务器。
GitHub + Vercel + 腾讯云（COS与CDN）
本节的内容，与其他小节的差异是巨大的。
GitHub，腾讯云，或者其他第三方服务商提供的静态页面部署服务的前提是，开发者必须将已经打包好的静态页面部署在服务商中.
而Vercel则与他们相反。Vercel的原理是，开发者将前端项目的源码进行部署，而由Vercel对源码进行打包和部署，实现了一种伪SSR（服务端渲染）的工作方式。部署方式如图11所示。
Vercel相对来说是一个对开发者十分友好地第三方服务平台，他完成了代码的自动部署和打包工作，让开发者可以更加专注于业务。开发者只需要完成第一次部署，就不再需要关心站点的部署问题。其实如果在现在重新思考这一节，Vercel就是一个针对个人开发者和小团队的自动化部署系统，甚至做大一点能接入GitHub能实现自动Merge……
开发者通过将源代码托管在GitHub，并根据开发情况对核心分支（也就是Vercel选择部署的分支）进行适时更新，Vercel就会察觉到这些变化并将最新的代码打包为新的站点，并部署在Vercel的服务器上。
Vercel的主要生态依然是GitHub。当Vercel用户将账户与GitHub账户绑定后，即可自动获取到该账户的仓库。同时，Vercel也支持针对一个第三方仓库进行部署。Vercel会在控制台中向开发者展示部署时服务器的实时状态。
Vercel也支持自定义域名的功能，其实现方式相对于GitHub和腾讯云更为自由和快速，不需要等待DNS响应生效。Vercel本身也提供了一定的Serverless服务，包括云函数等。
相对于GitHub，Vercel可以提供更好的网络性能，同时也可以极大程度的简化开发和部署流程。
本节将会通过对示例项目的不同部署方式进行性能测试。测试方法为由固定IP向目标站点发送访问请求，并通过工具记录相关加载时间。
通过测试数据的平均值判断不同部署方式之间的用户相对访问速度，通过测试数据的方差判断不同部署方式之间的用户相对访问稳定性。
由于访问速度直接受限于IP地址与服务器之间的物理距离，故不再针对不同区域的不同IP进行测试。
在测试结果中，访问速度和访问稳定性会是相对的结果。
在测试过程中，将会分别测试首页加载测试与静态资源加载测试。首页加载测试为直接访问首页进行测试，以模拟用户体验；静态资源加载测试为测试静态资源加载速度及在大负载的情况下部署方式的稳定性。
对于功能回答与文章，其设计目的为测试示例项目的架构稳定性，并已通过测试。由于其内容基于云端，无法做到本地化参与测试，故在本节将不会测试相关内容。
为了获取更为全面和真实的数据，本研究将使用Microsoft Edge浏览器的开发工具进行站点加载性能测试。测试过程中，将会使用固定IP地址向目标地址发送请求。每一个部署方式都将重复测试五次，并在每次请求后完全清除缓存与Cookie。
每一次请求统计将包括如下数据：
(1) 完成时间（毫秒）；
(2) DOM加载时间（毫秒）；
(3) 完全加载时间（毫秒）。
其中，完成时间是页面最后一个请求截止时间 ；DOM加载时间是DOM内容进行加载并解析完成的时间，即页面白屏时间；完全加载时间是页面所有的资源加载完成的时间[3]。
由于开发工具会对实际访问时间进行优化显示，导致无法在所有情况下读取到完整的数据。但考虑到当值被优化时其值已经足够大，测试中将忽略这一部分的精度差异。对于得到的值，将舍弃小数部分。
关键词：方案,实现
在线咨询
