Serverless

Serverless


  • You build it, you run it.
  • Serverless 不是真的沒有server, 而是不用在意server端的問題
  • Serverless -> less 即是 more
    • how to monitor lambda
    • how to debug lambda
    • 必須讓服務全部都是stateless
      • ex: no sticky session
  • 優點
    • 開發者只需要專注寫好 function
    • HA (High Availability)
    • 無法預判狀況時可以快速MVP
    • 使用適當可以 cost down
  • 缺點
    • 執行時間有限
    • 執行時間太長反而無法節省成本
    • 需要做的事情其實變更多
      • 如何debug
      • 如何監控
  • 常見的 serverless
    • AWS lambda function
    • GCP Cloud function
    • Azure Function
    • OpenFaaS (Function as a Service)
  • 應用案例分享
    • 可口可樂在飲料機上使用lambda串接金流
    • 無人機使用lambda即時將監控的畫面回傳

Ref: https://rickhw.github.io/2018/03/29/About/2018-Serverless-All-Star/









S3 + Event Source + Lambda發送SNS 



留言

張貼留言

這個網誌中的熱門文章

[翻譯] 介紹現代網路負載平衡與代理伺服器

圖片
原文(Source): https://blog.envoyproxy.io/introduction-to-modern-network-load-balancing-and-proxying-a57f6ff80236 什麼是網路負載平衡 (network load balancing) 與 代理伺服器的代理行為 (proxying)? 維基百科是這樣定義負載平衡的 > 負載平衡藉由工作量分配到多台運算資源, 例如: 主機, 主機叢集, 網路連結, CPU,  硬碟等. > 負載平衡盡量最佳化資源的使用, 最大化每個最大化每個資源的吞吐量(生產能力), 最小化反應時間, 避免單一資源工作量過重 > 使用多個資源來當負載平衡來提升可靠與高可用而不是單一個資源 > 負載平衡總是使用獨立的軟體或硬體, 例如獨立的 multilayer switch, 或是 DNS主機的程式 上面的定義用於各資訊領域的各方面, 不單單只有網路而已. 作業系統使用負載平衡在實體處理器去分配運算任務, 容器編排服務像是K8S使用負載平衡在不同的主機叢集中去分配任務, 而網路負載平衡器則是將網路上進來的任務分配給可用的後端主機們. 剩下的文章主要都是講解關於網路負載平衡. 圖1 圖1展示了從應用層來看網路負載平衡. 許多的用戶端(Client)透過只需要向 load balancer 請求, load balancer就會將這些request, 也就是上述提到的任務分配給可用的後端服務. Load balancer位於Client 與後端之間執行幾個重要的任務: 服務發現 (Service discovery) 後端的服務在系統的哪裡, 他們的IP(位置)是什麼? (也就是load balancer該如何與後端主機溝通) 服務的狀態檢查 (Health checking) 現在的服務是否是可接受請求的 負載平衡 (Load Balancing) 該用什麼樣的演算法去平均將request分配給可用的服務 在分散式系統使用負載平衡主要有幾個好處: 主機抽象 (Naming abstraction): 每個client 不需要知道每個後端服務在哪, 只需要利用預先定義好的機制向負載平衡器發出請求
閱讀完整內容

Grafana K6

圖片
Grafana K6 最近工作需要做壓力測試, 由於 api 有做自定義的加密 在挑選壓力測試工具的時候就先想到了 k6 安裝 K6 mac: brew install k6. 其餘的可以參考這裡: Installation 使用 K6 撰寫 壓力測試腳本 基本的入門測試可以參考網路上其他大神寫的文章 或是參考這裡: Running K6 這裡主要介紹, 如果要透過額外寫 Node.js 的邏輯上去該怎麼處理。 因為 K6 底層是由 Go 撰寫而成的，js 只是對應的介面， 所以要加入 Node.js 邏輯要額外透過 Webpack 處理！ 步驟 0 : 先建立對應的目錄 mkdir . / example - project && \ cd "$_" && \ npm init - y 步驟 1 : 安裝會用到的工具 npm install -- save - dev \ webpack \ webpack - cli \ @types / k6 \ babel - loader \ @babel / core \ @babel / preset - env \ core - js 步驟 2 : 設定 webpack.config.js const path = require ( 'path' ) ; const webpack = require ( 'webpack' ) ; // 這是新增的，要引入 webpack。 module . exports = { mode : 'production' , entry : { login : './src/login.test.js' , signup : './src/signup.test.js' , } , output : { path : path . resolve ( __dirname , 'dist' ) , // eslint-disable-line li
閱讀完整內容

Linux 事件驅動筆記

圖片
 I/O Model Synchronous I/O Blocking Non-Blocking I/O multiplexing Asynchronous I/O Blocking 跟 Non-Blocking 差異只差在 選擇 ! Blocking 以 read (read from a file descriptor) 來舉例, 從 user space 發出 read (kernel提供的 system call) 之後， 這時候就會切換到 kernel mode，kernel 會依據給定的 file descriptor 去判斷， 這個 fd 來自哪裡，接下來等待資料，因為 kernel space 跟 user space 本身就是 isolated， 這樣在 user space 的 process crash，也不會影響到 kernel space， 所以 kernel space 拿到資料之後，因為 isolated 的關係，要將資料複製到 user space 去。 在這個過程中，user space 的 read 基本上就是一直在等結果。 read 如果失敗會有 err number 可以注意 EAGAIN EWOULDBLOCK Non-blocking 就是類似一直來問 read 目前的狀態， kernel 回到 user space 可能裝置還沒準備好，或是要等之後的操作才會生效， 這時候就會發出 EAGAIN 的錯誤，EAGAIN 不代表是真的錯誤，再試一次可能就可以， I/O Multiplexing (這個邏輯跟數位邏輯的 mux 很像，故取做 IO multiplexing) multiplexing => 有多個輸入(input), 可以透過一個 select 去決定輸出 假設 Linux 要等待很多種資料, 就可以用這個概念，去監控哪個 fd 有資料， 有資料的話就挑選出來! 所以 I/O Multiplexing 本質還是 blocking，只是可以一次監聽多個 所以像網頁伺服器要監聽很多個 incoming request，就可以用這種方式處理 select 單個 process 可以被監聽的 fd 數量有限制 (跟這個 /proc/sys/fs/file-max 有關) 因為是一個一個詢問(輪詢)，所以監聽越多 f
閱讀完整內容