第 137 期 - IE 辛苦了,以後我會用其他工具下載瀏覽器的

本週專欄

Explain Redlock in Depth

大家好,這週的專欄是 Starbugs Writers 的新成員 吳俊廷 所分享的「Explain Redlock in Depth」,也是我們成立兩年多以來第一篇英文專欄。

身為工程師,就算沒用過一定也多少聽過 Redis,而這週作者要跟大家說說為什麼他並不建議使用 Redlock(基於 Redis 的 distributed lock),文中仔細分析了 Redlock 的概念跟優缺點,就算你從來沒聽說過 Redlock,還是可以讀得懂哦~

Golang

Data Race Patterns in Go

Uber 的 Go 專案有超過五千萬行程式碼,工程師從以前到現在也修過超過一千個 data race(他們真的不考慮用 Rust 嗎XD)。而這篇文章就是他們修了這麼多 data race 之後,整理出來最可能犯錯的地方,非常值得讀的一篇文章~

Options Pattern in Golang

Options pattern 是 Go 裡面很常見的寫法,在很多框架裡面都能見到他的蹤影,一起來看看什麼情況下可以使用這樣的 pattern,以及有什麼好處吧

Effective Error Handling in Golang

Go 內建的 error 跟很多語言不一樣,不僅不支援傳統的 try catch,甚至不包含 stack trace,所以用起來有一些不便,但也因此更輕量。如果才剛開始學 Go,來看看如何好好的使用 Go 的 error 吧

前端開發

CSS Day 2022

這篇文章的作者是 CSS Day 2022 的其中一位講者,他在文章中分享了第一次參與 CSS Day 的過程,以及在這之中聽見的 CSS 有趣知識,如果沒有時間研究所有議程,可以參考這位講者他感興趣的主題。

How to Solve the Parking Lot Challenge in JavaScript

透過一些遊戲的做法來模擬解決現實中的問題,是學習程式語言中讓人感到不會枯燥的一部份,而且身為前端如果能夠再將寫好的核心邏輯已可視化的介面呈現那這個過程就會變得相當有趣。作者在文章中解釋它處理 Parking Lot Challenge 的過程及方式。

Do You Really Need a React State Management Library?

不論是要另外使用第三方的狀態管理工具(例如 redux),或是直接利用 React 提供的 context API,選擇這些解決方案的思考模式應該是來自於你對專案狀態的理解,熟悉各種解決方式它提供的優缺點,而不單單認為「這個比較好」。

Monitoring

Grafana OnCall OSS

Grafana 開源了 On Call 管理工具,就叫做 On Call XD 感覺滿值得一試的! On Call 需要的功能都已經包含其中,例如整合第三方 Calendar 與通知服務 (Slack, Telegram, Voice, SMS),Escalation 的設定,Alert 的 Grouping,一個集中化顯示 Alert 的地方…等,有興趣的人可以參考 Get Started 文件 和他的 GitHub Repository

What makes VictoriaMetrics the next leading choice for open-source monitoring

近幾年來談到開源的監控解決方案時,大家應該都會選擇 Prometheus Stack,其中由 Grafana, Alertmanager 和各種 Exporter 所組成,但作為一個快速成長的生態系,他有著一些問題,例如他是一個效能堪憂的單體式應用程式,從設計上就缺乏有關 HA 的考量,擴展性複雜與不足,當保存的資料超過 14 天時就會造成效能降低與擴展困難

所以作者最近在研究開源監控解決方案時,覺得監控系統應該要具備高效能,高可用,便宜,易擴展,能備份且儲存相對久時間週期的資料 ,再把 Thanos, Cortex, Grafana-Mimir 和 VictoriaMetrics 都拿出來比較過一輪之後覺得 VictoriaMetrics 應該會是最符合這些需求的贏家,想要知道為什麼的人可以參考詳細內文

How to Handle Terabytes of Metrics in Kubernetes Monitoring

在基礎設施中 Monitoring 當然是相當重要的一環,它能夠協助遇見事故的發生,並且避免服務產生不預期的 Downtime,在作者的公司 Holidu 因為不斷增加的客戶導致基礎設施的不斷增長,每秒所產生約 4 萬個 Metric 的樣本資料,導致監控設施不堪負荷且增加了營運的成本;在此挑戰之下,作者的公司顯然需要一個新的可擴展且穩定的監控系統,所以他們將原來使用的 Prometheus 架構透過 Thanos 重新改進,用以順利處理每秒 4 萬個 Metric 的樣本資料,想要知道詳細做法的話,可以參閱詳細內文

DevOps

A deep dive into OpenTelemetry metrics

OpenTelemetry 相信大家都不陌生,此篇文章從基本開始分享起,並且解釋收集 metrics 流程的細節,也有解釋同步與非同步的實作上的差異,另外文章裡的各種分類表和 OpenTelemetry SDK 範例也十分受用。

Troubleshooting Amazon EKS API servers with Prometheus

文章以圖文並茂的方式教大家怎麼 troubleshooting EKS API。其中提到的 LIST 和 WATCH 的差異,使用 WATCH 可以讓 Kubernetes 規模更大,不過當 object 或 worker nodes 越多也是有負擔,本文也有寫解決方法,另外當有些服務使用過多的 LIST 呼叫時務必加上 limit。維運人員也要注意服務詭異的行爲像是讀跟寫的次數不一致是否是預期的?API 優先程度可以根據服務有所調整,這樣就可以避免有些服務影響到 API server。

Why Is Everyone Ignoring the Day 2 Kubernetes Problem?

單純使用 Kubernetes 的 Deployment、Service 或 Ingress 並不難,最難的是如何持續的維運 cluster,比起技術上的使用,更多的是要了解 Kubernetes 的生態圈,然後在各個面向選擇適合組織的工具。例如:如何標準化 Kubernetes 的更新管理、使用者的權限管理與隔離、監控、審計以及如何整合第三方工具等等。

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。

Maintainers:

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

Feedback

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