1. 首頁 > 生活 > >

阿里云api網關使用 阿里云api網關 收費標準

小知識



文章插圖
阿里云api網關使用 阿里云api網關 收費標準

文章插圖
最近關于 Serverless 的討論越來越多 ?？此婆c前端關系不大的 Serverless，其實早已和前端有了頗深淵源，并且將掀起新的前端技術變革 。此次分享根據個人理解和總結，從前端開發模式在serverless的演進、Serverless 常見服務商提供的解決方案以及 基于Serverless 的前端開發模式等方面，與大家探討 Serverless 中的前端開發模式 。
一、前端開發模式的演進
image.png
首先回顧一下前端開發模式的演進，我覺得主要有四個階段 。。
1、基于模板渲染的動態頁面2、基于 AJAX 的前后端分離3、基于 Node.js 的前端工程化4、基于 Node.js 的全棧開發
基于模板渲染的動態頁面
在早起的互聯網時代，我們的網頁很簡單，就是一些靜態或動態的頁面，主要目的是用來做信息的展示和傳播 。這個時候開發一個網頁也很easy，主要就是通過 JSP、PHP 等技術寫一些動態模板，然后通過 Web Server（nginx，apache） 將模板解析成一個個 HTML 文件，瀏覽器只負責渲染這些 HTML 文件 。這個階段還沒有前后端的分工，通常是后端工程師順便寫了前端頁面 。
JSP: Java Server Page: Java服務端頁面，在html頁面中編寫Java代碼的頁面WebServer：網站服務器或web服務器
基于 AJAX 的前后端分離
2005 年 AJAX 技術的正式提出，翻開了 Web 開發的新篇章 ?；?AJAX，我們可以把 Web 分為前端和后端，前端負責界面和交互，后端負責業務邏輯的處理 。前后端通過接口進行數據交互 。我們也不再需要在各個后端語言里面寫著難以維護的 HTML 。網頁的復雜度也由后端的 Web Server 轉向了瀏覽器端的 JavaScript 。也正因如此，開始有了前端這個職位 。
基于 Node.js 的前端工程化
2009年 Node.js 的出現，對于前端來說，也是一個歷史性的時刻 。隨著 Node.js 一同出現的還有 CommonJS 規范和 npm 包管理機制 。隨后也出現了 Grunt、Gulp、Webpack 等一系列基于 Node.js 的前端開發構建工具 。
在 2013 年前后，前端三大框架 React.js/Angular/Vue.js 相繼發布第一個版本 。我們可以從以往基于一個個頁面的開發，變為基于一個個組件進行開發 。開發完成后使用 webpack 等工具進行打包構建，并通過基于 Node.js 實現的命令行工具將構建結果發布上線 。前端開發開始變得規范化、標準化、工程化 。
基于 Node.js 的全棧開發
Node.js 對前端的重要意義還有，以往只能運行在瀏覽器中的 js 也可以運行在服務器上，前端可以用自己最熟悉的語言來寫服務端的代碼 。于是前端開始使用 Node.js 做全棧開發，開始由前端向全棧的方向轉變 。這是前端主動突破自己的邊界 。另一方面，前端在發展，后端也在發展 。也差不多在 Node.js 誕生那個時代，后端普遍開始由巨石應用模式向微服務架構轉變 。這也就導致以往的前后端分工出現了分歧 。隨著微服務架構的興起，后端的接口漸漸變得原子性，微服務的接口也不再直接面向頁面，前端的調用變得復雜了 。于是 BFF（Backend For Frontend）架構出現了，在微服務和前端中間，加了一個 BFF 層，由 BFF 對接口進行聚合、裁剪后，再輸出給前端 。而 BFF 這層不是后端本質工作，且和前端的關系最大，所以前端自然而然選擇了 Node.js 來實現 。這也是當前 Node.js 在服務端較為廣泛的應用的原因 。
巨石應用：大部分web工程是將所有的功能模塊(service side)打包到一起并放在一個web容器中運行，很多企業的Java應用程序打包為war包微服務架構：微服務架構是一種架構理念，是指將功能分解到離散的各個服務當中，從而降低系統的耦合性，并提供更加靈活的服務支持 。把一個大型的單體應用程序和服務拆分為數個或數十個的微小型服務，它可擴展單個組件而不是整個的應用程序堆棧，從而滿足服務等級協議 。下一代前端開發模式
說完了這幾個階段，可以看到，每一次前端開發模式的變化，都因某個變革性的技術而起 。先是 AJAX，而后是 Node.js 。那么下一個變革性的技術是什么？不言而喻，個人覺得就是 Serverless 。
什么是serverless
image.png
【阿里云api網關使用 阿里云api網關 收費標準】CNCF，全稱Cloud Native Computing Foundation（云原生計算基金會），成立于 2015 年7月21日（于美國波特蘭OSCON 2015上宣布），其最初的口號是堅持和整合開源技術來讓編排容器作為微服務架構的一部分，其作為致力于云原生應用推廣和普及的一支重要力量，不論您是云原生應用的開發者、管理者還是研究人員都有必要了解 。
目前行業可能更多處在容器 Docker+Kubernetes, 利用IaaS、PaaS和SaaS 來快速搭建部署應用
基礎架構即服務（Infrastructure as a Service，IaaS）、平臺即服務（Platform as a Service，PaaS）以及軟件即服務（Software as a Service，SaaS） 。
Docker是一個平臺，它主要是提供一些服務，任何一臺裝有docker的機器你都可以建立、發布、運行你的應用程序，使用docker很省錢省時 。簡單的介紹Kubernetes 。它就是一套成熟的商用服務編排解決方案 。Kubernetes定位在Paas層，重點解決了微服務大規模部署時的服務編排問題 。其實 Serverless 早已和前端產生了聯系，只是我們可能沒有感知 。
1、CDN: 相信大家都使用過 CDN，我們開發完成之后，直接將靜態文件部署到 CDN 上，通過 CDN 進行內容分發、網絡加速，在這個過程中，前端不需要關心 CDN 有多少個節點、如何做負載均衡，也不需要知道 CDN 的 QPS 是多少 。所以從這個角度來說，CDN 是一種 serverless 的實現 。
2、再比如對象存儲，和 CDN 一樣，我們只需要將文件上傳到對象存儲，就可以直接使用了，不需要關心它如何存取文件、如何進行權限控制，所以對象存儲對前端來說是 Serverless 。3、甚至一些第三方的 API 服務，也是 Serverless，因為我們使用的時候，不需要去關心服務器 。
image.png
當然，有了體感還不夠，我們還是需要一個更精確的定義 。從技術角度來說，Serverless 就是 FaaS 和 BaaS 的結合 。
簡單來講，FaaS（Function as a Service） 就是一些運行函數的平臺，比如阿里云的函數計算、AWS 的 Lambda 等 。
BaaS（Backend as a Service）則是一些后端云服務，比如云數據庫、對象存儲、消息隊列等 。利用 BaaS，可以極大簡化我們的應用開發難度 。
Serverless 則可以理解為運行在 FaaS 中，使用了 BaaS 的函數 。
Serverless 的主要特點有：
1、事件驅動—-函數在 FaaS 平臺中，需要通過一系列的事件來驅動函數執行 。2、無狀態—-因為每次函數執行，可能使用的都是不同的容器，無法進行內存或數據共享 。如果要共享數據，則只能通過第三方服務，比如 “`Redis“ 等 。
Redis（全稱：Remote Dictionary Server 遠程字典服務）是一個開源的使用ANSI C語言編寫、支持網絡、可基于內存亦可持久化的日志型、Key-Value[數據庫]，并提供多種語言的API 。從2010年3月15日起，Redis的開發工作由VMware主持 。從2013年5月開始，Redis的開發由Pivotal贊助 。
3、無運維—-使用serverless我們不需要關心服務器，也不需要關心運維，這也是serverles思想的核心；4、低成本—-使用 Serverless 成本很低，因為我們只需要為每次函數的運行付費 。函數不運行，則不花錢，也不會浪費服務器資源過度
？？？？哪些公司平臺提供這些功能???現有的服務商 云平臺 亞馬
二 Serverless 常見服務商提供的解決方案
image.png
1、上圖是當前主要的一些 Serverless 服務，以及對應的服務解決方案 。2、從下往上，分別是基礎設施、開發工具和應用場景 。亞馬遜-微軟-谷歌3、基礎設施主要是一些云計算廠商提供，包括云計算平臺和各種 BaaS 服務，以及運行函數的 FaaS 平臺 。前端主要是 Serverless 的使用者，所以對前端來說，最重要的開發工具這一層，我們需要依賴開發工具進行 Serverless 開發、調試和部署 。4、框架（Framework）如今還沒有一個統一的 Serverless 標準，不同云計算平臺提供的 Serverless 服務很可能是不一樣的，這就導致我們的代碼，無法平滑遷移 。Serverless 框架一個主要功能是簡化 Serverless 開發、部署流程，另一主要功能則是屏蔽不同 Serverless 服務中的差異，讓我們的函數能夠在不改動或者只改動很小一部分的情況下，在其他 Serverless 服務中也能運行 。常見的 Serverless 框架有 Serverless Framework、ZEIT Now、Apex 等 。不過這些基本都是國外公司做的，國內還沒有這樣的平臺 。5、Web IDE和 Serverless 緊密相關的 Web IDE 主要也是各個云計算平臺的 Web IDE 。利用 Web IDE，我們可以很方便地在云端開發、調試函數，并且可以直接部署到對應的 FaaS 平臺 。這樣的好處是避免了在本地安裝各種開發工具、配置各種環境 。常見的 Web IDE 有 AWS 的 Cloud9、阿里云的函數計算 Web IDE、騰訊云的 Cloud Studio 。6、當然，目前最主要的開發方式還是在本地進行開發 。所以在本地開發 Serverless 的命令行工具也必不可少 。命令行工具主要有兩類，一類是云計算平臺提供的，如 AWS 的 aws、 Azure 的 az、阿里云的 fun；還有一類是 Serverless 框架提供的，如 serverless、now 。大部分工具如 serverless、fun 等，都是用 Node.js 語言來實現的 。7、應用場景在開發工具上面一層，則是 Serverless 的一些垂直應用場景 。除了使用傳統的服務端開發，目前使用 Serverless 技術的還有小程序開發，未來可能還會涉及到物聯網領域（IoT） 。
不同 Serverless 服務的對比
上圖從支持語言、觸發器、價格等多個方面對不同 Serverless 服務進行了對比，可以發現有差異，也有共性 。
1、比如幾乎所有 Serverless 服務都支持 Node.js/Python/Java 等語言 。
2、從支持的觸發器來看，幾乎所有服務也都支持 HTTP、對象存儲、定時任務、消息隊列等觸發器 。當然，這些觸發器也與平臺自己的后端服務相關，比如阿里云的對象存儲觸發器，是基于阿里云的 OSS 產品的存取等事件觸發的；而 AWS 的對象存儲觸發器，則是基于 AWS 的 S3 的事件觸發的，兩個平臺并不通用 。這也是當前 Serverless 面臨的一個問題，就是標準不統一 。
S3:Amazon Simple Storage Service (Amazon S3) 是一種對象存儲服務，提供行業領先的可擴展性、數據可用性、安全性和性能
從計費的角度來看，各個平臺的費用基本一致 。在前面也提到，Serverless 的計費是按調用次數計費，執行時長 。
三 基于 Serverless 的前端開發模式serverless 開發流程
1、在開始具體的案例之前，先看一下傳統開發流程 。在傳統開發流程中，我們需要前端寫頁面，后端工程師寫接口 。后端寫完接口之后，把接口部署了，再進行前后端聯調 。聯調完畢后再測試、上線 。上線之后，還需要運維工程師對系統進行維護 。整個過程涉及多個不同角色，鏈路較長，溝通協調也是一個問題 。
2、而基于 Serverless，后端變得非常簡單了，以往的后端應用被拆分為一個個函數，只需要寫完函數并部署到 Serverless 服務即可，后續也不用關心任何服務器的運維操作 。后端開發的門檻大幅度降低了 。因此，只需要一個前端就可以完成所有的開發工作 。當然，前端基于 Serverless 去寫后端，最好也需要具備一定的后端知識 。涉及復雜的后端系統或者 Serverless 不適用的場景，還是需要后端開發 。
serverless帶來的價值
1．降低運營復雜度
Serverless架構使軟件應用和服務器實現了解耦，服務器不再是用戶開發和運營應用的焦點 。在應用上線前，用戶無須再提前規劃服務器的數量和規格 。在運維過程中，用戶無須再持續監控和維護具體服務器的狀態，只需要關心應用的整體狀態 。應用運營的整體復雜度下降，用戶的關注點可以更多地放在軟件應用的體驗和改進以及其他能帶來更高業務價值的地方 。2．降低運營成本服務器不再是用戶關注的一個受管資源，運營的復雜度下降，應用運營所需要投入的時間和人力將大大降低 。在最好的情況下，可以做到少數幾個應用管理員即可管理一個處理海量請求的應用系統 。
3、縮短產品的上市時間在Serverless架構下，應用的功能被解構成若干個細顆粒度的無狀態函數，功能與功能之間的邊界變得更加清晰，功能模塊之間的耦合度大大減小 。這使得軟件應用的開發效率更高，應用開發的迭代周期更短 。
serverless實踐基于 Serverless 的 BFF (Backend For Frontend)
傳統 BFF (Backend For Frontend) 架構
1、一方面，對不同的設備需要使用不同的 API，另一方面，由于微服務導致前端接口調用的復雜，所以前端開始使用 BFF 的方式，對接口進行聚合裁剪，以得到適用于前端的接口 。2、最底層的就是各種后端微服務，最上層就是各種前端應用 。在微服務和應用之前，就是通常由前端開發的 BFF 。-手機端-web端-嵌入式-這樣的架構解決了接口協調的問題，但也帶來了一些新的問題 。
傳統 BFF (Backend For Frontend) 的痛點
比如針對每個設備開發一個 BFF 應用，也會面臨一些重復開發的問題 。而且以往前端只需要開發頁面，關注于瀏覽器端的渲染即可，現在卻需要維護各種 BFF 應用 。以往前端也不需要關心并發，現在并發壓力卻集中到了 BFF 上 ?？偟膩碚f運維成本非常高，通常前端并不擅長運維 。
Serverless 則可以幫我們很好的解決這些問題 。用Serverless，我們可以用一個個函數來實各個接口的聚合裁剪 。前端向 BFF 發起的請求，就相當于是 FaaS 的一個 HTTP 觸發器，觸發一個函數的執行，這個函數中來實現針對該請求的業務邏輯，比如調用多個微服務獲取數據，然后再將處理結果返回給前端 。這樣運維的壓力，就由以往的 BFF Server 轉向了 FaaS 服務，前端再也不用關心服務器了 。
基于 Serverless 的 BFF 架構
上圖則是基于 Serverless 的 BFF 架構 。為了更好的管理各種 API，我們還可以添加網關層，通過網關來管理所有 API（比如阿里云的網關），比如對 API 進行分組、分環境 ?；?API 網關，前端就不直接通過 HTTP 觸發器來執行函數，而是將請求發送至網關，再由網關去觸發具體的函數來執行 。API Gateway在沒有API網關作為統一出口的情況下，需要調用方自己組合各種服務，而且容易讓調用方感知后端各種服務的存在，各個需要各個做很多相同的工作 。加入API Gateway之后的作用一般也會把路由，安全，限流，緩存，日志，監控，重試，熔斷等都放到 API 網關來做，然后服務層就完全脫離這些東西，純粹的做業務，也能夠很好的保證業務代碼的干凈，不用關心安全，壓力等方面的問題 。
基于 Serverless 的服務端渲染傳統服務端渲染
基于當下最流行的三大前端框架（React.js/Anguler/Vue.js），現在的渲染方式大部分都是客戶端渲染 。頁面初始化的時候，只加載一個簡單 HTML 以及對應的 JS 文件，再由 JS 來渲染出一個個頁面 。這種方式最主要的問題就是白屏時間和 SEO 搜索引擎優化
為了解決這個問題，前端又開始嘗試服務端渲染 。本質思想其實和最早的模板渲染是一樣的 。都是前端發起一個請求，后端 Server 解析出一個 HTML 文檔，然后再返回給瀏覽器 。只不過以往是 JSP、PHP 等服務端語言的模板，現在是基于 React、Vue 等實現的同構應用，這也是如今的服務端渲染方案的優勢 。
但服務端渲染又為前端帶來了一些額外的問題：運維成本，前端需要維護用于渲染的服務器 。
基于serverless的服務端渲染
Serverless 最大的優點就是可以幫我們減少運維，那 Serverless 能不能用于服務端渲染呢？當然也是可以的 。
傳統的服務端渲染，每個請求的 path 都對應著服務端的每個路由，由該路由實現對應 path 的 HTML 文檔渲染 。用于渲染的服務端程序，就是這些集成了這些路由的應用 。使用 Serverless 來做服務端渲染，就是將以往的每個路由，都拆分為一個個函數，再在 FaaS 上部署對應的函數 。這樣用戶請求的 path，對應的就是每個單獨的函數 。通過這種方式，就將運維操作轉移到了 FaaS 平臺，前端做服務端渲染，就不用再關心服務端程序的運維部署了 。
基于 Serverless 的小程序開發
1、目前國內使用 Serverless 較多的場景可能就是小程開發了 。具體的實現就是小程序云開發，支付寶小程序和微信小程序都提供了云開發功能 。2、在傳統的小程序開發中，我們需要前端進行小程序端的開發；后端進行服務端的開發 。小程序的后端開發和其他的后端應用開發，本質是是一樣的，需要關心應用的負載均衡、備份冗災、監控報警等一些列部署運維操作 。如果開發團隊人很少，可能還需要前端去實現服務端 。但基于云開發，就只需要讓開發者關注于業務的實現，由一個前端就能夠完成整個應用的前后端開發 。因為云開發將后端封裝為了 BaaS 服務，并提供了對應的 SDK 給開發者，開發者可以像調用函數一樣使用各種后端服務 。應用的運維也轉移到了提供云開發的服務商 。下面分別是使用支付寶云開發的一些例子，函數就是定義在 FaaS 服務中的函數 。
負載均衡（Load Balance）其意思就是分攤到多個操作單元上進行執行，例如Web服務器、FTP服務器、企業關鍵應用服務器和其它關鍵任務服務器等，從而共同完成工作任務備份冗災：就是為了防止出現自然或者社會滅害帶來的對存儲設備的損害而造成對數據丟失,而采取的備份.
通用 Serverless 架構
基于上述幾個 Serverless 開發的例子，就可以總結出一個通用的 Serverless 架構 。
其中最底層就是實現復雜業務的后端微服務（Backend） 。然后 FaaS 層通過一系列函數實現業務邏輯，并為前端直接提供服務 。對于前端開發者來說，前端可以通過編寫函數的方式來實現服務端的邏輯 。
同時不管是在后端、FaaS 還是前端，我們都可以去調用云計算平臺提供的 BaaS 服務，大大降低開發難度、減少開發成本 。小程序云開發，就是直接在前端調用 BaaS 服務的例子 。
一句話總結serverless – less is more
使用 Serverless，我們不需要再過多關注服務端的運維，不需要關心我們不熟悉的領域，我們只需要專注于業務的開發、專注于產品的實現 。我們需要關心的事情變少了，但我們能做的事情更多了 。