收益 or 挑戰？Serverless 究竟給前端帶來了什麼

導讀：前端開發者是最早享受到 “Serverless” 好處的群體，因為瀏覽器就是一個開箱即用、甚至無需為計算付費的環境！Serverless 把前端開發體驗帶入了後端，利用 FaaS 與 BaaS 打造一套開箱即用的後端開發環境。本文作者將從前端角度出發，為你講述 Serverless 帶來的收益及挑戰。

引言

1. 會改變前後端介面定義規範；
2. 一定會改變前後端聯調方式，讓前端參與伺服器邏輯開發，甚至 Node Java 混部；
3. 大大降低 Nodejs 伺服器維護門檻，只要會寫 JS 程式碼就可以維護 Node 服務，無需學習 DevOps 相關知識。

1. 未來伺服器部署更彈性，更省錢；
2. 部署速度更快，更不易出錯。

精讀

• FaaS - Function as a service

• BaaS - Backend as a service

• PaaS - Platform as a service

• DaaS - Data as a service

• IaaS - Infrastructure as a Service

• SaaS - Software as a Service

• 容器

• NoOps

• DevOps

從做一款遊戲說起

// ... UI 部分，畫出一個倒數計時伐木場建造進度條
const currentTime = await requestBuildingProcess();
const leftTime = new Date().getTime() - currentTime;
// ... 繼續倒數計時讀條
// 讀條完畢後，每小時木頭產量 + 100，更新到客戶端計時器
store.woodIncrement += 100;

// 每次登陸時，校驗當前登陸
const currentTime = new Date().getTime()
// 獲取伐木場當前狀態
if ( /* 建造中 */) {
  // 返回給客戶端當前時間
  const leftTime = building.startTime - currentTime
  res.body = leftTime
} else {
  // 建造完畢
  store.woodIncrement += 100
}

配置同步

export const buildings = {
  wood: {
    name: "..",
    maxLevel: 100,
    increamentPerLevel: 50,
    initIncreament: 100
  }
  /* .. and so on .. */
};

在 Serverless 環境下做遊戲

// 根據建築建造時間判斷建築狀態
export const getBuildingStatusByTime = (instanceId: number, time: number) => {
  /**/
};
// 判斷建築生產量
export const getBuildingProduction = (instanceId: number, lastTime: number) => {
  const status = getBuildingStatusByTime(instanceId, new Date().getTime());
  switch (status) {
    case "building":
      return 0;
    case "finished":
      // 根據 （當前時間 - 上次開啟時間）* 每秒產量得到總產量
      return; /**/
  }
};
// 前端 UI 層，每隔一秒呼叫一次 getBuildingProduction 函式，及時更新生產資料
// 前端入口函式
export const frontendMain = () => {
  /**/
};
// 後端 根據每次開啟時間，呼叫一次 getBuildingProduction 函式併入庫
// 後端入口函式
export const backendMain = () => {
  /**/
};

.
├── client    # 前端入口
├── server    # 後端入口
├── common    # 共享工具函式，可以包含 80% 的通用遊戲邏輯

前後端的視角

• 對於前端開發者而言，會發現後臺服務變簡單了；
• 對於後端開發者而言，發現服務做厚了，面臨的挑戰更多了。

更簡單的後臺服務

• 可以在伺服器安裝資料庫等服務，本地直聯伺服器的資料庫進行開發；
• 可以本地安裝 Docker 連線本地資料庫服務，將環境打包成映象整體部署到伺服器；
• 將前後端程式碼分離，前端程式碼在本地開發，服務端程式碼在伺服器開發。

更厚的後臺服務

• Serverless 各廠商實現種類很多，想讓業務做到多雲部署，需要抹平差異；
• 成熟的 PaaS 服務其實是偽 Serverless，後續該如何標準化；
• FaaS 冷啟動需要重新載入程式碼、動態分配資源，導致冷啟動速度很慢，除了預熱，還需要經濟的優化方式；
• 對於高併發（比如雙 11 秒殺）場景的應用，無需容量評估是很危險的事情，但如果真能做到完全彈性化，就省去了煩惱的容量評估；
• 存量應用如何遷移。業界的 Serverless 服務廠商大部分都沒有解決存量應用遷移的問題；
• Serverless 的特性導致了無狀態，而複雜的網際網路應用都是有狀態的，因此挑戰在不改變開發習慣的情況下支援狀態。

• 推進前後端一體化。進一步降低 Node 寫服務端程式碼的門檻，免除應用運營的學習成本。筆者曾經遇到過自己申請的資料庫服務被遷移到其他機房而導致的應用服務中斷，以後再也不需要擔心了，因為資料庫作為 BaaS 服務，是不需要關心在哪部署，是否跨機房，以及如何做遷移的；
• 提高資源利用效率。杜絕應用獨佔資源，換成按需載入必然能減少不必要的資源消耗，而且將服務均攤到叢集的每一臺機器，拉平叢集的 CPU 水位；
• 降低雲平臺使用門檻。無需運維，靈活擴充，按價值服務，高可用，這些能力在吸引更多客戶的同時，完全按需計費的特性也減少了使用者開銷，達到雙贏。

利用 Serverless 嘗試服務開放

Serverless 應用架構設計

• 將業務函式抽象成一個個 FaaS 函式，將資料庫、快取、加速等服務抽象成 BaaS 服務；
• 上層提供 Restful 或事件觸發機制呼叫，對應到不同的端（PC、移動端）；
• 想要擴充平臺能力，只要在端上做開放（元件接入）與 FaaS 服務做開放（後端接入）即可。

收益與挑戰

雖然可以通過定期執行 FaaS 服務來保證程式一直 Online，但筆者認為這還是違背了 Serverless 的理念。

總結

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/69947441/viewspace-2662098/，如需轉載，請註明出處，否則將追究法律責任。