第 163 期 - 身邊朋友都要出國玩了，沒關係，我有網路就好！

Created on 2022-12-20

本週專欄

初探 Linux Kernel 中的 BPF 與 XDP 技術：以 Tiny Load Balancer 為例

大家好，這週的專欄是由 Starbugs Writer Ian 所發表的「初探 Linux Kernel 中的 BPF 與 XDP 技術：以 Tiny Load Balancer 為例」。

聽過 BPF 跟 XDP 的人也許不多，但在這個微服務當道的世代，eBPF 與 XDP 其實已經被廣泛應用到許多成熟的專案上。如果你對這兩個底層技術如何增進 Load Balancer 的效能有興趣，而且也熟悉 Linux 跟 C 語言，那一定要趕快點進來看看這週的專欄～

前端開發

Optimize Interaction to Next Paint

Interaction to Next Paint (INP) 是用來測量回應速度的指標，如果使用者在網頁上進行操作但頁面沒有任何回應的話，那就這個使用者體驗就是差的。而 INP 就是要觀察頁面對使用者做的每一項操作回應的延遲時間。在這篇文章裡面會告訴你該如何測量、分析以及改善 INP 較差的問題。

Vite 4.0 is out!

Vite 3 在發布之後，每週的下載量暴增到 250 萬，且根據今年 Jamstack Conf 的問卷顯示，在社群內的使用率也提高到 32%，滿意度也維持在 9.7 高分。那在前作如此好評的狀況下，Vite 4 增修了以下幾點：

瀏覽器的支援度
將 .css 作為 string import
如果環境變數中有 # 或 ` 則需要用 “ 包起來
減少打包後的尺寸
升級到 Vite Core

更詳細的內容就快點進去官方的公告看看吧！

Web Performance Calendar

這篇文章列舉了幾點在 Web 界用來處理效能的酷炫 API：

作者也有在每個 API 下快速介紹並附上目前的支援度，是一篇很好去吸收名詞的好文章！

Golang

New in Go 1.20: wrapping multiple errors

如果沒意外的話，Go 在明年二月就會發佈新版本 1.20。從 Go 1.20 開始，我們可以用 errors.Join(err1, err2) 把多個錯誤 join 成一個錯誤、而且 fmt.Errorf 也可以用來把多個錯誤格式化輸出成一個錯誤，讓 Go 的錯誤回傳、處理可以寫得更漂亮

Test parallelization in Go: Understanding the t.Parallel() method

維持寫測試的習慣固然是好事，但隨著專案中的測試越來越多，每次跑測試所需要的時間也會越來越久。這篇文章介紹了 Go 的平行化測試功能，如果每個測試都是完全獨立、且不影響彼此，那可以試試看用 t.Parallel() 來同時執行多個 test case！

Making a Go program run 1.7x faster with a one character change

在這篇文章中，作者介紹了他如何使用 Go 的 pprof 跟 flamegraphs 工具來分析效能，並且最後只改了一個字元（其實是兩個XD）就提升了 1.7 倍的效能。如果你已經有 Go 的開發經驗，又對效能最佳化感興趣，那麼這篇文章絕對值得一讀！

DevOps

How DoorDash Secures Data Transfer Between Cloud and On-Premise Data Centers

處理底層網路一直都不是簡單的事，DoorDash 因為業務需要跟供應商做介接，但因為供應商敏感的資料不適合暴露於公開的網路，所以評估 AWS Site-to-Site VPN 和 Direct Connect。確定使用 Direct Connect 的實體光纖線路後，發現供應商防火牆的規則會擋掉所有來自內網的 CIDR 範圍，例如 10.0.0.0 到 10.255. 255.255 (Class A) 172.16.0.0 到 172.31. 255.255 (Class B) 192.168.0.0 到 192.168. 255.255 (Class C)，確保流量是來自外部。於是 DoorDash 只好使用 NAT Gateway 嘗試解決，但發現在 Virtual Private Gateway 時沒辦法抓到 NAT Gateway 的 Elastic IP，所以最後使用 Private NAT Gateway 才得以解決。然後 DoorDash 在靠 AWS Transit Gateway 把 Direct Connect 的環境以中心點串到各個 AWS 帳號去。

Kubernetes CI/CD Pipelines Explained

我想大家或許對 Kubernetes CI/CD 工具已經很熟了，但本篇依舊介紹不錯的工具之外，也介紹了最佳實踐，以及推薦自動化、團隊合作、資安和監控工具。是一篇要入門建置 Kubernetes CI/CD pipeline 很不錯的起點文章。

How to Build a Fintech App: Approach, Architecture, and Scalability

做金融科技的服務要如何選架構？地點決定法規、商業模式影響系統負載、是否很在意延遲、服務需不需要即時性和系統可靠性容錯率有多少，又或者單體架構（Monolith）、服務導向架構（service-oriented architecture）或微服務架構（Microservices）。作者是建議業務一開始可以循序漸進，因為微服務架構會花很多開發時間，等腳步穩了再改進即可。

Git

Monorepo Build Tools

最近在軟體開發的圈子中，使用 Monorepos 來管理程式碼有變流行的趨勢，Monorepos 指的是單一個 Repository 中包含著許多相關但是不同專案的程式碼，他有不少優點，但這樣的管理方式也帶來不少的挑戰，假設一個 Repo 中有數百個服務，彼此之間存在著相依性，當其中一個服務有變動時，如何讓其他的服務不會全部都被重新測試，編譯和部署？這時就可以依靠 Monorepos 專屬的工具來解決這個問題，在評估相關類型的工具時，通常會需要考慮以下幾個因素：

Programming Language Support: 確認選擇的工具支援你目前以及未來所使用的程式語言
Learning Curve: 每個工具的學習成本各有不同，評估工具的複雜度，確認是否適合你的團隊
Caching: 一個理想的建構工具，對於同一個 Build 不應該被執行兩次，應該要選擇具備在遠端分散式環境執行與支援快取的工具
Build Introspection: 能夠洞察被構建服務的流程和相依關係，允許工程師去查看構建圖，構建時哪個環節效率不佳，或是變更牽涉到哪一些專案
Versatility: 構建以外的附加功能，例如相依套件如何被安裝？整合測試如何運行？測試資料庫如何被還原？換句話說，除了從程式碼構建 Artifact 之外的其他問題都需要被考慮進去

而目前在這個領域中，作者介紹了四個工具供大家選擇，底下根據上面提的選擇要點來做比較 (不過這篇文章是 Earthly 所撰寫，所以不能全信XD):

Bazel:
- Programming Language Support: Java, C++, Python…等
- Learning Curve: 四個工具中最複雜
- Caching: 支援遠端快取和分散式執行 (開源 & 商用版本)
- Build Introspection: 透過 bazel query 和其他相關指令提供強大的 Introspection 功能
- Versatility: 相當受限，只可以在 run 的階段執行整合測試，至於環境設定和自動構建方面則是被認為不在此工具的支援範圍內
Pants:
- Programming Language Support: Go, Python, Java…等 (沒有 JavaScript)
- Learning Curve: 透過 Static Introspection，使得他比 Bazel 更易用一些
- Caching: 支援遠端快取和分散式執行 (開源 & 商用版本)
- Build Introspection: 透過 pants dependencies 指令提供良好的 Introspection 功能
- Versatility: 相當受限，環境設定和自動構建方面也是被認為不在此工具的支援範圍內
NX:
- Programming Language Support: Javascript, Go, Rust，還有 iOS 和 Android 執行器
- Learning Curve: 對於 JavaScript 開發者來說學習曲線最低
- Caching: 支援遠端快取和分散式執行 (商用版本)
- Build Introspection: 提供一些 Introspection 功能
- Versatility: 透過 npm 腳本支援不可快取的步驟和一次性的構建任務
Earthly:
- Programming Language Support: 任何可以運行在 Linux 環境的東西
- Learning Curve: 有點類似 Dockerfile，使用一連串的 RUN 指令來構建，學習曲線最低
- Caching: 支援遠端快取和分散式執行 (開源 & 商用版本)
- Build Introspection: 受限的 Introspection 功能
- Versatility: 透過包裝現有的工具來提供環境設定和自動構建的功能

The Wordcel’s Guide to Shape Rotation using the Git Commit Graph

活在 2022 年快要結束的這個當下，應該沒有人會質疑 Git 在軟體開發領域的地位，幾乎每個人都需要使用它，但不一定每個人都真的了解他，這篇文章的作者坦承他一開始費了很大的勁去使用 Git，透過了很長時間的研究和練習之後才總算比較會使用一些，也才有辦法分享這篇文章給對於 Git 還不熟的人；文章中使用淺顯的例子加上容易理解的示意圖來解釋了 Git 常用的功能與知識，如 Git Commit, Branch, Merging, 至於 Rebase 呢？作者在最後説 Rebase 一個不被信任的黑暗工具，請大家使用 Merge 就好XD

How to Close a Pull Request - Merge Commit vs Squash vs Rebase on GitHub

當要把 Pull Request Branch 合併到 Main Branch 的時會看到三個選項，分別是 “Create a merge commit”, “Squash and merge” 以及 “Rebase and merge”，這三個選項分別會如何將 PR Branch 合併到 Main Branch 呢？而究竟哪一個選項是最好的呢？

Create a Merge Commit: Merge Commit 是在 GitHub 最常用也是預設的選項，也是執行 git merge 時的預設行為，PR Branch 中的所有 Commit 歷史都完整地被保留在 Main Branch 中，然後會有一個額外的 Commit 將 PR Branch 的所有變更內容合併到 Main Branch；優點就是可以很容易追蹤到被修改的那一行程式碼是在哪一個 Commit 中，缺點就是當有很多的 Commit 在很多不同的 Branch 時，最終整個 Commit 的歷史紀錄會變得很雜亂，追蹤變更軌跡會是個相當大的挑戰
Squash and Merge: 但你真的需要追蹤每一個變更的 Commit 嗎？包含打錯字，漏掉檔案，格式錯誤…等，假如答案是否定的，那你應該考慮使用 Squash Merge，他會忽略掉 PR Branch 中所有的 Commit，然後將所有的變更內容合併成一個 Commit 合併到 Main Branch 中，如此一來，你可以放心的在 PR Branch 中提送任何你想要的 Commit，因為最終只會有一個 Commit 被合併到 Main Branch 中
Rebase and Merge: 當你不需要一個額外的 Commit 來得知 Merge 的發生時，而且希望最終所有的 Commit 都線性在單一個 Branch 中時，就可以使用 Rebase and Merge，他會保留所有的 Commit，而且在合併時不會有額外的 Commit；缺點就是在 Rebase 遇到合併衝突時，很容易在無意間遺失部分的程式碼，而且假如你需要追趕上多個 Commit 時，你最後可能需要為每一個 Commit 解決合併衝突，而不像其他的 Merge 選項，只需要解決一次合併衝突

而究竟要選擇哪一個比較好，作者覺得假如 PR Branch 不會開著很久的話，那麼 Squash Merge 是個不錯的選擇，而他本身並不是 Rebase 的粉絲，因為他覺得使用 Rebase 很容易造成失誤，但是在決定要採用哪一個之前，可以先想想看自己和團隊需要去看歷史 Commit 的頻率有多高，團隊中有多少個成員，使用的 CI 工具是否需要完整的 Commit 歷史

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 - 興趣是符號學的軟體開發者，喜歡探索事物的本質，偶爾會寫點東西。
@ChesterMo - 我是Chester，還在求道的後端工程師，相信努力就會有回報。

Maintainers:

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

Feedback

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