傳統伺服器 V.S. 無伺服器！如何找出適合自己的架構？

前言

隨著雲端技術蓬勃發展，現今有越來越多的企業、個人使用者，開始轉而運用這項新興的技術，成為使用者建構各項系統、功能的一大幫手。有別於以往，當使用者如果需要取得 IT 資源時，大多是由使用者自己架設機房、購買實體設備、設置網路，並自行管理、維運；有了雲端，使用者可以將剛剛所提到的準備工作、維護的程序，交給雲端供應商託管，甚至雲端供應商有可能可以提供比自己先前所擁有來得更加多、更強大的 IT 資源。

在過去，傳統的地端機房相當普遍。由小型機房只有個位數台 Server，至數十、數百台 Server 的大型機房都有；而 Server 可視為由一個核心處理器來連接多個裝置到主要資料庫的運算單位。從概念上來看，感覺非常簡單，但這其中卻需要花費不少的時間、人力、金錢來做維護及調整。以此觀點出發，讓許多技術人員開始轉向雲端的懷抱。

我想用聽的：Spotify Podcast、Apple Podcast、Google Podcasts、KKBOX Podcast

雲端的三個服務層次

在 Cloud Computing Model 中的 Service Model，雲端可分為三個服務層級，依據託管程度不同，主要可分為 IaaS、PaaS、SaaS 三種。簡單來說，託管的層級越多，意味著使用者需要自己操心的項目越少了；而使用者可根據自己的需求，選擇不同層級的服務來使用。

圖片來源：Iaas、Pass、Saas 傻傻分不清楚

而近年，更是發展出 Serverless 的概念，也有人以新的層次：FaaS (Function as a Service)，來描繪 Serverless 以一個個系統功能，或是一個個程式函式為單位所發展出來的實作方式。

什麼是 Serverless？

「這項技術的目的並不是為了實現真正意義上的「無服務器」，而是指由第三方雲計算供應商負責後端基礎結構的維護，以服務的方式為開發者提供所需功能，例如數據庫、消息，以及身份驗證等。簡單地說，這個架構就是要讓開發人員專注代碼的運行而不需要管理任何的基礎設施。程序代碼被部署在諸如 AWS Lambda 這樣的平台上，通過事件驅動的方式去觸發對函數的調用。」

節錄自 AWS 官方 Blog：从 IaaS 到 FaaS —— Serverless 架构的前世今生

Serverless 並非沒有 Server，而是對於使用者來說，並不需要管理任何底層架構，就好像 Server 不存在一樣。以此比喻 Serverless 能夠幫助開發者擺脫運行後端應用程序所需的 Server 設備的設置和管理工作，讓開發者專注在系統核心功能、程式碼設計上。也就是 「專注在應用，而不是架構」。

另外，Serverless／FaaS 具有幾項特點：

事件觸發（event-triggered）：當有需要時，才會觸發函式執行。而觸發的來源可自定義，可能源於其他服務及功能，或是從 Client 端來的請求。
無狀態（stateless）：每次執行皆是獨立的，不會受到前一次執行內容／結果影響
生命週期短（ephemeral）：每次執行完畢就關閉，等待下次事件發生時，再次觸發，啟動並執行函式。
擴展性高（scalable）：根據觸發的頻率，也就是流量，自動擴展所需要的 IT 資源。使用者不需預先擴展資源，而是由服務自動調整。

Serverless 範例架構圖

在 AWS 上，有關於 Serverless 的服務分別有以下幾個：

AWS Lambda（最為著名的 Serverless 服務）
Amazon S3
AWS Fargate
Amazon EFS
Amazon DynamoDB
Amazon RDS
Amazon API Gateway
Amazon SNS
Amazon SQS
…

比較差異性

Serverless

優點：
- 價格：由於只有在觸發／使用的時候才會收取費用，因此其餘時間也不會產生額外的成本。
- 減少維護成本：由於背後驅動的伺服器，交給雲端供應商管理，因此使用者本身不需額外花費人力去維護架構。
- 可擴充性：當運算資源不足時，使用者不需預先擴展資源，而是由服務自動調整。
- 加速產品開發：幫助開發者專注在應用，而不是架構。省去管理 Server 的程序，便可加速整體開發、測試的效率。
缺點：
- 較難彈性調整：由於將大多管理程序交由雲端供應商託管，因此如果想調整特定參數、設定，須看雲端供應商是否支援；而如果提供服務的 API 改變，也需要隨之調整程式碼設計的方式。
- 冷啟動（Cold Start）：一般 Serverless 透過多個 micro-containers 當作背後驅動的運算個體。當有一個事件觸發時，函數會去查看有沒有 Container 可以執行。如果有可以用的 Container，就可以馬上執行；如果沒有，便會重新開啟一個 Container。此時就叫作 Cold Start，這會有些微的延遲時間。
- 第三方支援不足：有些使用者特定愛用的第三方套件／程式語言的版本，雲端供應商不一定有支援，這時候使用者就需要選擇別的工具。

Server

優點：
- 可控因素較多：由於伺服器由自己管理，所以在某些層面，可以去做詳細的掌控，如：API timeout 時間、底層資源的調用等等，且在記憶體上方面，也不會受到服務上面的限制，可調用的資源更加多元。
- 依賴性低：不需依賴任何的套件，只要想要用，任何套件即可使用，開發的架構相對來說會輕鬆許多。
- 資訊較容易取得：當應用程式出現錯誤，使用者可以自行把需要的資訊，從系統中推播出來，幫助偵錯。
缺點：
- 維護成本：在維護方面就需要人員來定期檢查 Server 的安全，或是更新 Server 的套件，以利系統的運行。
- 固定成本：在成本方面，由於需要機器隨時等候，故要 24 小時不間斷開著，所以在成本方面就會相對 Serverless 貴上不少。

Serverless 轉型成功案例：可口可樂

可口可樂開發的團隊，在過往，會花費大量的人力資源在處理一些突發的一些狀況處理或是維運上面，導致真正在處理真正有價值的開發上佔不到 5 成的時間上，也就是說，團隊將一半以上的時間浪費在對企業毫無價值的問題。

於是在 2016 年時，從 Michael Connor 決定從一般雲端的 EC2 的 Server 架構中，嘗試轉型成 Serverless 的架構，改變其開發模式，專心注重在實際的開發功能上面。最終帶來以下效益：

開發效率：不需要花費過多的人力在處理維運方面相關的事情，給予更多人力在主要開發功能上。
花費：從原本約需要花費每年 $13000 美金，降到每年 $4500 美金

Serverless 實作

實作目的：架設一個遊戲網站，並將遊戲資料結果儲存至資料庫內部

架構圖

步驟

步驟一

目的：我們要建立一個資料庫空間，以利後面我們可將網站的資料存到裡面
請先在進入 DynamoDB 內建立資料庫
- Table name: mora
- Primary key: name
如建立完畢後，即可看到剛剛所創建好的資料庫

步驟二

目的：建立後端，主要將遊戲的執行結果寫入到資料庫內部
創建 Lambda
- 進入到 Lambda 首頁後，建立一個 function
- 選擇 python 3.6 的環境，並配置一個可寫入資料到 DynamoDB 的 IAM Role
- 完成後，請將以下的程式碼貼至頁面中的編譯器內部
<

pre>import json import boto3

client = boto3.client(‘dynamodb’, region_name=”us-east-1″)

def lambda_handler(event, context): name = event[‘name’] player_score= event[‘player_score’] computer_score = event[‘computer_score’] add_item(name, player_score, computer_score) return { ‘statusCode’: 200, }

def add_item(name, player_score, computer_score): response = client.put_item( TableName=’mora’, Item={ “name”:{“S”: name}, “player_score”: {“N”: player_score}, “computer_score”: {“N”: computer_score}, } ) return response

*   如下圖：
<p style="text-align:center;">
  <img src="https://i.imgur.com/2OlL8OP.jpg" width="85%" />
</p>

建立 API Gateway
- 建立自己的 API Gateway，並將 API Gateway 連結到剛剛寫好的 Lambda
- 設定所需要的 Method 為 Post
- 完成後，將 API delopy 出去後，便可以使用了

步驟三

目的：將頁面放入至 S3 內部，利用 S3 的 Static Website 來建立前端（建立靜態網頁）
進入 Amazon S3 內，創建自己的 Bucket
下載網頁檔案，並解壓縮

網頁檔案來源至：GitHub – skcshubham/rock-paper-scissors

將檔案內部的 game.js 的第14 行的 url 後的字串，修改成先前在 API Gateway 部署後的 url

並將檔案上傳至剛剛的 Bucket 裡面

設定完後，記得要將 Bucket Policy 開成 Public 才可存取 Bucket 裡頭的資料
最後去 S3 Property 裡面設定 Static Website Hosting，並把網站首頁指向 index.html。

成果

完成後，打開 S3 提供的網頁的 endpoint，可以看到遊戲的頁面，就可以在上面玩剪刀石頭布了！

每玩完一次後，會將資料透過剛剛設定的 API 存進我們的資料庫內部

總結

根據上面的介紹與比較後，可以更了解到 Traditional Server 與 Serverless 架構的差異，並透過 Serverless 實作，可以了解到他的實際應用場景，了解當前的最新技術與以往的不同之處。

而對於要如何選用哪種架構是基於團隊上面的考量，選擇 Traditional Server 基於方便、依賴性低、所有的事情都是獨自處理，而在 Serverless 裡，則便宜、不需管理 Server。對此而言，不論哪種架構沒有優劣之分，都是基於專案方面的需求去思考，並選擇所需的架構，也不一定只選用某種特定的架構，可考慮同時使用兩種的架構，結合兩者的優點。例如：將一般的 API 架構至 Serveless 內，而若需要特殊需求，再使用 Traditional Server，讓各個架構優的點發揮至極致，建設出屬於自己的專案。

對此而言，或許你也可以考慮一下，目前你手邊的專案是否也有此類的問題呢？不妨可以考慮一下自己的架構是否能做更好得調整呢？

作者：Tina Wang

傳統伺服器 V.S. 無伺服器！如何找出適合自己的架構？