第 161 期 - 我才不會用世足賽之類的當週刊名稱呢

Created on 2022-12-06

本週專欄

設計模式作為一種語言：物件導向的語法要素

大家好！這週的專欄是 Starbugs Writers Ken 所發表的「設計模式作為一種語言：物件導向的語法要素」。閱讀這篇文章前三段的時候，突然有種被拉回當初翻開 GoF 設計模式的感覺！舉的例子和譬喻都非常生動且深奧 😂

文章內容圍繞著語法元素與設計模式之間的關係，在例子中，分別用了 C、Java 和 Go 三種不同的語言循序漸進解說語法要素對整個系統造成的影響也超讚。另外在小結中有一句我有很喜歡的話「設計者需要先理解領域語言，才能設計出正確的系統。而我們可以把設計模式本身當作一套語言」，這是我從來沒有思考過的部分，作者最後也提到「當我們汲取了設計模式的組成規則，且能看懂其他架構師的設計時，也差不多是藝術的起點了。」看到這裡我才想說，這篇文章本身早已是藝術了！OK，既然推薦序都打完了，那我要去買碗排骨酥湯邊喝邊再看一次了。

前端開發

The State of Frontend in 2022

2022 又要過了，在一年如十年的前端領域中，不曉得前端工程師們都過得如何，在文章中分別從「哪些前端工程師做了問券」、「前端工程師的工作環境」、「工程實作」、「技術」、「工具」和「Vendors」等種類整理許多精彩的問題，裡面也包含了作者對結果的分析。

An Interactive Guide to Flexbox

通常像這種介紹排版的文章，就是看程式碼然後搭配圖和解說了解呈現的效果，但這篇文章則是用互動式的方式，讓你可以透過按鈕操作，看看在不同的屬性和寬度下頁面上的元素會如何排列。

JavaScript: Understanding CustomEvent and dispatchEvent

在這篇文章中會介紹如何用 Event、CustomEvent 和 dispatchEvent() 來建立和監聽事件，且作者還分享了如何，以及在哪些情境下會使用到自定義的事件。

Backend

Prevent Http Ddos With Cloudflare - 黑五檔期 Ddos 防禦筆記

最近黑五的檔期剛過，而在這段時間，作者的公司網站也遭遇了 DDoS 攻擊。所以作者在文章中提到了他是怎麼設定 Cloudflare 來防禦 DDoS，整篇文章圖文並茂講解得非常詳細，如果你的產品也有遇到 DDoS 攻擊，可以參考一下這篇文章。

6 Simple and Useful PostgreSQL Features that I wish I knew when I started

這篇文章介紹了 PostgreSQL 幾個比較少人知道的功能，這些功能都是作者在使用的過程中發現的，而且這些功能都非常實用，不管你是正要開始學習怎麼用 PostgreSQL 或是已經使用有一段時間了，都很推薦這篇文章～

MySQL🐬 InnoDB 教我的事：最近最少使用 LRU 串列的優化

這篇文章分享了 MySQL 的儲存引擎 InnoDB 內部是怎麼對 LRU(Least Recently Used) 演算法做最佳化，雖然涉及演算法難度比較高一點，不過如果你對 MySQL 的儲存引擎有興趣，可以看看這篇文章。

Kubernetes

Kubernetes 1.26 – What’s new?

K8s 1.26 也差不多要正式發佈了，讓我們跟著 sysdig 來看看這一版有什麼重要更新吧！這一版有 37 個增強功能，對比於 1.25 有 40 個，1.24 有 46 個，這 37 個裡面有 11 個會升到穩定版本，10 個的功能還需要持續改善，16 個全新的功能，其中底下幾個是 sysdig 覺得比較重要的更新，更詳細內容可以參閱內文：

儲存功能: 透過 VolumeSnapshot 功能，從不同 Namespace 的儲存快照建立新的儲存空間
驗證功能: 構築於 1.25 引進用來驗證 CRD 的 Common Expression Language (CEL)，現在 admission controller 多了一個 ValidatingAdmissionPolicy 型別，讓使用者可以在沒有 webhook 的情況下達成驗證機制
監控功能: 不再需要透過 Prometheus Exporter，可以直接在 /metrics/slis 提供 Kubernetes 的 SLI Metric
監控功能: 開始從 CRI API 來獲取 Container 的資訊 (例如 CPU, Memory 使用量)，而不是 cAdvisor，這也意味著會慢慢的將 cAdvisor 給淘汰掉，畢竟 Container Runtime 才是最清楚知道 Container 運行狀況的角色
管理功能: 既有的 Resource Management 只能針對 CPU 和 Memory 去設定 Limit 和 Request (之後還可以針對 Storage)，不過對於需要做初始化和清理的硬體資源，如 FPGA，或是想要限制硬體資源被存取，如共享的 GPU，這次新增了新的 ResourceClaimTemplate 和 ResourceClass 物件來達成這些需求，讓資源更動態地去分配
管理功能: 讓 Topology Manager 對於 multi-NUMA (NUMA: non-uniform memory access) 的 Kubernetes 節點有更好的控制權，例如透過控制使用哪一顆實體的 CPU 核心來避免 Memory 在不同晶片暫存或是 Socket 間跳躍，用以獲得大幅度的效能改善
管理功能: StatefulSet 多了掌控起始 Replica 數目的設定 (spec.ordinals.start)，主要的應用情境會是在跨 Namespace 或是叢集搬遷 StatefulSet 可以達成 0 Downtime 的需求 (建議同時搭配 PodDistruptionBudgets 去做使用)
管理功能: 讓 Kubernetes 的使用者可以透過 Auth API 獲得自己的使用者資訊，例如有什麼樣的權限，位於哪一些群組…等
效能改善: 讓 kubernetes-apiserver 提供 API 的完整清單，這樣一來呼叫 kubernetes-apiserver 的 client 就不用自己去查找有哪一些 API 和這些 API 有哪一些版本可以使用

Kubernetes Labels: Expert Guide with 10 Best Practices

透過 Kubernetes 於資源內所下的 Label，可以讓管理者更快地查找問題，一次將組態變更集體套用到多個資源，用來監控資源的使用狀況與成本，所以這篇文章要跟大家介紹 10 個使用 Label 的最佳實踐

使用 Kubernetes 本身推薦的 Label (Reference) 來對物件分群: K8s 推薦使用 app.kubernetes.io/name 和 app.kubernetes.io/instance 來代表應用程式的名稱和實例；假如是公司內部的應用服務，就可以使用自己公司的 subdomain 來取代 app.kubernetes.io 然後來客製化對應的 Label
注意 Label 的語法正確性: Label 是 Key Value 的組合，你必須使用 <Prefix>/<Name> 的格式來命名，其中 Prefix 是選擇性的，但假如要使用的話，要注意它必須是 DNS Subdomain 的格式，字數限制為 253 個字元，他可以讓團隊使用多個 Label 而不會產生命名衝突 (試想那些存在於第三方套件的 Label…)，其中 kubernetes.io 和 k8s.io 是 Kubernetes 針對內部核心元件所保留的 Prefix；Name 就是 Label 屬性名稱，例如可以使用 environment 來代表運行的環境，值得部分就可以用 production 或是 testing，Name 有一些使用需求，例如他不能是空的，字數限制為 63 個字元，開頭和結尾必須使用字母與數字 ([a-z0-9A-Z])，中間可以使用字母與數字和 -, _, . 符號混合
標準化的 Label 命名規則: 不同的團隊間必須要使用一致性的命名規則，不然花在維護 Label 的努力將會白費掉
避免不必要的 Label 變更: Label 是用來識別和選擇 K8s 中的資源用以達成排程，部署或是管理的目的，所以變更 Label 會造成深遠和不可預見的影響，例如你把某一群 Pod 的 App Label 從值 frontend 修改成 backend，K8s 就會認為你要把這些 Pod 重新部署到 backend 的節點上，這有可能會造成這些 Pod 開始 Crach，最終無法被存取；所以只要在絕對必要時才去修改 Label，並且在進行任何修改之前仔細的評估可能造成的後果，避免遭遇到不可預期的狀況
使用 Label Selector 來選擇資源: 透過使用相等性或是集合的操作來對資源做選擇，以相等性來說， = 和 == 都代表相等，!= 代表不相等，也可以透過逗號 , 將添加的多個 Label 區隔開來一起使用；而集合的操作有點像是 SQL 語法中的 IN，例如 app in (frontend, backend) 代表 app Label 擁有 frontend 或是 backend 的資源都會被選擇出來
不要將應用程式的資訊寫入 Label: K8s Label 主要是用來儲存物件的 Metadata，而不是用來當作應用程式的資料儲存區，因為 K8s 的資源的使用時間通常很短，而且跟應用程式沒有緊密的關係，Label 很快就會變的不同步而毫無用處
不要將機敏資訊寫入 Label: 假如有心人士可以存取你的 K8s 叢集，而你又把諸如密碼， API Credential 或是其他的機敏資訊寫入了 Label，那麼這些資訊就可以在明碼的情況下被輕易取得；建議應該要存放在 K8s Secret 而不是 Label 內，因為在 Secret 內至少是被編碼過的，而且只有需要的 Pod 才能夠去取得它，這樣一來，即使有心人士可以存取你的 K8s 叢集，也不會有機會直接看到這些儲存於 Secret 的機敏資訊 (自己覺得 K8s Secret 還是不夠安全，建議整合第三方的 Secret Management 工具，如 HashiCorp Vault)
將 Label 加到 Pod Template: 將必要的 Label 添加到運行資源的 Pod Template 中，如此一來 K8s Controller 便可以如你所期望地建立 Pod；目標是只建立對團隊可以帶來價值的 Label 就好，而不是浮濫的建立一堆沒有用處的 Label，建議從小處著手，一開始先在 Template 中建立一個必要 Label 的清單，例如用來識別資源的擁有者，資源運行的環境以及發布資訊
將 Label 的添加過程自動化: 自動化可以節省大量時間，當然對於標籤的管理也不例外，假如平常就有在使用 CI/CD Pipeline 的話，就可以輕鬆自動化為某些 Label 做橫向的管理工作；使用 CD 工具來添加 Label 是很明智的選擇，因為它可以確保 Label 的一致性，並且提高工程師的生產力，除此之外，也建議通過 CI 工作來檢查 Label 是否正確無誤，當 Label 遺失時就應該讓 CI 工作失敗並且通知相關負責的團隊來處理
使用 Label 來做成本監控: 標籤對於了解 K8s 的雲端使用成本很有幫助，其實不管是成本監控，資源分配和管理其實都仰賴著妥切的 Label 策略；當多個團隊共享同一個 K8s Cluster 時 (Multi-Tenant)，你就會需要使用相關 Label 來建立成本分佈報告，因為這樣做才可以獲知特定團隊，服務或是應用服務所耗費的成本，這對調查突然激增的使用成本相當地有幫助

Deploying Kubernetes resources in a specific order using Helm or werf

假如希望部署 K8s 資源時可以使用某種順序去部署的話，通常是有點挑戰性的，有時候甚至必須要等待外部資源準備完成，假設今天你要部署一個應用服務好了，那就要先等一個外部的 Operator 建立好動態的 K8s Secret，再來開始初始化和設置資料庫，最後才能夠部署應用服務，這篇文章就要跟大家介紹如何使用 Helm 或是 werf 來解決這個問題

使用 Helm: 主要是透過 initContainers 來達成，透過 init container 來讓不同的元件之間有順序性的部署，講白話一點就是有個插入一個 until xxx; do sleep 1 done 的 shell script，這個 script 會一直去檢查某個相依資源是否存在，如果存在就會可以部署主體資源，如果不存在就會一直等待，直到相依資源存在為止，這樣就可以達到等待某個相依資源的目的
使用 werf: 首先必須要在 K8s 資源定義中加入 werf 相關的 annotations，這些 annotations 會告訴 werf 這些資源的權重，werf 會根據這些權重來決定資源的部署順序，這樣就可以達到資源部署的順序性

DevOps

How We Use Terraform At Slack

Slack 使用 Terraform 時也是早期從單一個 AWS 帳號逐漸擴展，也會把大型服務拆成多個 Terraform state files 管理，也會分配不同 AWS IAM 權限來提供 sandbox 環境，使用文法檢查工具來輔助 Terraform 多版本讓環境可以逐一升級，Terraform module 從原本相對路徑逐漸改成用 git 抓下來到最後開發工具只可惜更難做測試，也開發了 Terraform Smart Planner 讓還沒 merge 的測試結果印出 output 讓 reviewer 更好審視。這篇文章的結語也說們的 Terraform 之旅離完美還很遠，也不忘在文章最後偷偷徵才。

How to Mentor Interns to Become Skillful Engineers

如何讓讓實習生快速進入狀況也是 DevOps 的一環，Slack 就分享除了要注意分配給實習生要做什麼專案外，他的 onboarding 流程跟資源是否能讓他快速進入狀況？如何測量實習生的實習成效是成功的？如果實習生有多位 mentors 該怎麼確保他可以溝通順暢？文章對於制定這些計畫有個詳細的紀錄，即使用在正職員工上也很受用。

A Day in the Life of a Cloud Engineer at Slack Australia

在澳洲的 Slack 的雲端工程師分享他的一天行程，Slack 的雲端團隊有三種分別是 Foundation、VM 和 containers，在 VM 團隊的他表示在每週開會時可以了解其他團隊的事務。公司的溝通風格基本上還是以非同步為主，code review 也是如此，這也有助於跟北美的同事做溝通。

StarBugs Weekly

StarBugs Weekly 由一群不寫文章就會想要亂花錢，但是又沒有那麼多錢，只好繼續寫文章的開發者所創立。
內容包含 Web 前端、中端、後端、DevOps、產品開發、精實創業，一切跟產品有關的知識，都是我們的守備範圍！
不想漏追科技新聞的人，趕緊把 StarBugs Telegram Bot 訂閱起來 https://t.me/starbugs_weekly_bot (對機器人說 /subscribe 即可)

另外，為了讓 Starbugs 的專欄有更多豐富、優質的內容，我們決定要開始誠徵 Writer 了。如果你本來就有在寫文章，對於文章的品質有要求、而且也樂於分享討論技術，那很歡迎你以 Writer 的身份加入我們。請動動手指頭私訊我們粉專星巴哥技術週刊，並附上自我介紹跟最近寫的文章，就有機會加入我們唷 🙌

Writers:

@HannahLin - 從台灣到矽谷，熱愛前端的工程師女孩。
@KyleMo - 雜食性軟體工程師，喜歡的技術我都想學。
@Airwaves - Hi~我是 Airwaves，熱愛研究如何造輪子的前端工程師。
@Andy - 目標成為用嘴巴工作的工程師，專長為網頁開發以及 K8s。
@lazypro - 從 embedded 到 kernel，從 device 上雲端，程式無涯、無法靠岸，軟體的求道者。
@ianchen0119 - 5G 領域研究生，同時也是喜歡學習不同領域技術的工程師。
@00-talk - 我是 00，脖子痠痛的前端生命鬥士。
@Ken - 興趣是符號學的軟體開發者，喜歡探索事物的本質，偶爾會寫點東西。

Maintainers:

@GQSM - Hi！我是神 Q 超人，一個先衝再說的男人。
@LarryLu - 我是 Larry，傳說中的 0.1 倍工程師！
@LukaTW - 一名全身都是死角的工程師。
@smalltown - 熱愛鑽研各種可以提升雲端服務品質及增進團隊開發效率的開源技術。
@RicoChen - 熱愛許多技術且努力看透技術的本質，如果有什麼好玩的技術，還請各位歡迎直接找我聊聊。

Feedback

本週呈現主題方式做了一些改變，希望讓讀者能夠更快速精準的找到自己要的資訊。也加入社群活動這個區塊，每週更新社群活動的資訊。如果有任何建議，歡迎私訊星巴哥技術週刊 FB 粉絲專頁與我們聯繫。