第 20 期 - YAML Engineer 的愛恨情仇

Created on 2020-03-17

本週專欄

Helm 3 踹踹看 — YAML Engineer 的愛恨情仇

雖然使用 K8S 會讓人變成充滿怨念的 YAML Engineer，不過我想這也是他可以變成主流 Container Orchestration 的原因之ㄧ，因為不管是開發或是維運人員，只要將運行在 K8S 內的應用服務使用 YAML 檔案格式定義好就可以一起使用，這一週想要分享如何把 Helm2 升級到 Helm3，除此之外也會介紹自己常用的 Helmfile

神 Q 超人

Storybook | addons 與他的快樂夥伴

好不容易寫好了一個自己相當滿意的 Component，但又對再另外花時間描述該 Component 的使用方法感到疲憊，有時候又很難以文字表現出該 Component 的行為或操作方法，而 Storybook 拯救了這一切！它可以記錄你所建構的元件擁有什麼樣的功能，就像一本故事書一樣，描述著屬於該 Component 的故事：）

The Best Developer Communities to Join in 2020

在 2020 年，開發者絕不能錯過這 20 個最讚的技術社群，一起吸收這世界都在用程式討論哪些事情！當然除了他們以外也別忘了還有 StarBugs 陪著大家 😉。

YouTube 怎麼禁止手機使用者背景播放的？透過 Chrome 開發者工具深度尋訪 YouTube 的前端程式碼

很喜歡作者說「YouTube 的 Front-end Engineer 也不是用魔法在寫 code ，所以勢必是透過 JavaScript 、 Browser 的 API 所賦予的能力」，任何在網頁上面看見的東西、酷炫的技巧等等，都有辦法被你創造出來（除了動畫啦 😂）！就從這篇文章開始當個偵探，以後看見喜歡的神奇功能時，就能試著瞧瞧他們是怎麼做到的！

Larry Lu

Database basics: writing a SQL database from scratch in Go

這篇教你怎麼用 Go 從無到有寫出一個簡單的 DB，並且提供 CREATE、SELECT 跟 INSERT 指令，如果你對 DB 的內部構造有興趣的話，這篇文章很適合你讀

Go 原本的併發模型是 CSP(Communicating Sequential Processes)，也就是透過輕量的 thread(goroutine) 來做到併發，thread 之間的溝通則是使用 channel。但透過把 goroutine 當成一個有狀態的 actor，並且以 channel 來傳遞 message，可以在 Go 裡面實現類似 Elixir 的 Actor model，挺有趣的

Early Impressions of Go from a Rust Programmer

這是一篇 Rust 開發者去學 Go 之後寫的心得文，也是我看過最平衡的比較文，Rust 跟 Go 其實可以是好朋友，不需要再比哪個語言比較好，找到適合自己的就可以了

LukaTW

你要的 React 面试知识点，都在这了

什麼是聲明式語言？聲明式語言是一種語言範式，它關注的是你要做什麼，而不是如何做。它表達邏輯而不顯式地定義步驟。這意味著我們需要根據邏輯的計算來聲明要顯示的組件。它沒有描述控制流步驟。聲明式語言的例子：HTML、SQL等

React Hooks 详解【近 1W 字】+ 项目实战

什麼是 Hooks？React 一直都提倡使用函數元件，但是有時候需要使用 state 或者其他一些功能時，只能使用類元件，因為函數元件沒有實例，沒有生命週期函數，只有 Class 元件才有。Hooks 是 React 16.8 新增的特性，它可以讓你在不編寫 class 的情況下使用 state 以及其他的 React 特性。如果你在編寫函數元件並意識到需要向其添加一些 state，以前的做法是必須將其它轉化為 class。現在你可以直接在現有的函數元件中使用 Hooks。凡是 use 開頭的 React API 都是 Hooks。

React源码解析(一):组件的实现与挂载

當我們能夠熟練運用React進行前端開發時，不免會對React內部機制產生濃厚的興趣。元件是什麼？是真的DOM嗎？生命週期函數的執行依據又是什麼呢？本篇，我們先來研究React組件的實現與掛載。

smalltown

來瞧瞧看 Uber 怎麼測試與開發內部的 Microservice

Uber 工程師的績效評估來自於多快將新功能部署到 Production 環境中，在 Microservice 架構中搭配著快速地開發節奏要如何確保高 SLA 便成為不小的挑戰，而 Uber 解決問題的方式為貫徹 Multi-Tenant ！此文分享從測試，部署，開發時要注意哪些事情

測試的選擇與挑戰
- Parallel Testing：準備一個跟 Production 一樣的測試環境 (這應該是最常見的做法)
  - 額外的建置成本：畢竟要準備另外一套完整的環境，資料庫，機器…等，都是要多燒錢的
  - 同步問題：如何確保測試環境跟 Production 環境一直保持一致性
  - 測試的不可靠性：譬如自己想要測試 Service A，但是 Service B 上了一包爛 Build 導致你不能測試…
  - 不確定的服務負載：在測試環境中作效能測試的結果要如何評估到真實環境中
- Testing in Production：讓 Production 環境的服務具有 Multi-Tenant 的能力來允許接受來自測試和 Production 的請求
  - 請求的導流：必須要可以根據請求是來自測試或是正式環境來做導流
  - 隔離性：測試和 Production 的資源要具有良好的隔離性，測試環境不能影響到正式環境
部署的方式
- Canary Deployment：就算新版的 Build 已經過詳細的 Review 和 Testing，還是不想要一次讓所有的請求都直接使用新版本，而是在 Multi-Tenant 的架構下，將 Canary 視為一個獨立的 Tenant ，然後再根據請求的使用者屬性 (用路類型，產品類型…等) 把部分請求導流到 Canary 中
- Capture/Replay and Shadow Traffic：將 Production 環境中的正式流量給錄製擷取下來當作整合測試使用，其實就像上面提過的架構一樣，所以可以相對輕易地將 Production 環境的請求導流至想要測試的 Microservice
實作與開發
在 Multi-Tenant Microservice 架構中，每個 Tenant 都被視為 First Class Object 然後根據各種靜態和請求中的動態資料來組成 Context，整個系統便是根據這些 Context 來決定請求該被導流到哪邊去
- Tenancy Context：Tenancy Context 要在請求進入 Edge Gateway 時就被附加上去，而且在其生命週期中都不再會被改變
- Context Propagation：必須讓請求發出時同時傳遞 Context，而大部分的服務可能不需要查看 Context，但是某些可能會需要透過評估 Context 來決定要不要繞過某些業務邏輯，譬如某些跟金流相關的請求，假如是發生在測試請求時，就不需要真的跟銀行要求轉移資金之類的，而且請求的 Context 有時也需要被傳遞到靜態跟動態的資料物件中
- Tenancy-Based Routing：一旦系統有能力可以把請求 Tag 成某一個 Tenancy，那就可以決定要將其導流到測試環境，上面提到用來做整合測試的錄製流量，Canary Deployment…等，一般來說在服務的 egress 和 ingress 都可以把 Tenancy-Based Routing 給實作進去，而且在選擇解決方案還滿重要的，目前有一些 Service Mesh 的開源專案，例如 Envoy 或是 Istio 就可以考慮看看，因為可以利用 Side Car 的特性來幫忙導流請求
- Data Isolation：必須要有辦法根據不同的 Tenancy 將 Logging, Metrics, Storage, Message Queues, Caches 跟 Configuration 給切開來

StarBugs Weekly

StarBugs Weekly 由一群不寫文章就會想要亂花錢，但是又沒有那麼多錢，只好繼續寫文章的開發者所創立。
內容包含 Web 前端、中端、後端、DevOps、產品開發、精實創業，一切跟產品有關的知識，都是我們的守備範圍！

Curators:

@GQSM - Hi！我是神 Q 超人，一個先衝再說的男人。
@Larry850806 - 我是 Larry，傳說中的 0.1 倍工程師！
@LukaTW - 一名全身都是死角的工程師。
@smalltown - 熱愛鑽研各種可以提升雲端服務品質及增進團隊開發效率的開源技術

Feedback

想看什麼內容，告訴我們！點我回饋意見