GripNewsMay 24
🌘 從 RPC 到交易與持久化執行 – Pramod Biligiri
➤ 探討系統設計中數據一致性和容錯性的演進之路
✤ https://www.pramodb.com/index.php/2025/05/21/from-rpc-to-transactions-and-durable-executions/
本文探討了從遠程程序呼叫 (RPC) 到現代持久化執行引擎 (如 Temporal) 的演進歷程，並深入研究了交易、分散式交易以及容錯系統建構的相關概念。作者追溯了相關技術的發展，從最早的二階段提交 (2PC) 協議、企業整合模式 (EIP)，到 Java 交易 API (JTA) 和後來基於 Web Service 的標準 (WS-AtomicTransaction、WS-BusinessActivity)，分析了每種方法的優缺點以及為何它們未能廣泛普及。文章強調了在複雜系統中實現數據一致性和容錯性的難度，並指出這些問題的根本難度在數十年中一直存在。
+ 這篇文章深入淺出地分析了分散式系統中交易的演進，讓我對 Temporal
#分散式系統 #交易 #持久化執行 #軟體架構
From RPC to transactions and durable executions – Pramod Biligiri

GripNewsApr 2
🌘 多線程設計總是錯誤的選擇
➤ 拋棄多線程迷思，擁抱單線程高效能
✤ https://unetworkingab.medium.com/multi-threading-is-always-the-wrong-design-a227be57f107
本文指出，儘管許多人認為多線程能提升效能，但實際上它往往會降低CPU的使用效率並增加程式碼的複雜性。作者認為，將問題分解成獨立的部分，並在單一線程中處理，通常比使用線程池更有效率，尤其是針對現代CPU架構。這種方法能更好地利用NUMA系統和CPU快取局部性，避免快取一致性問題、記憶體障礙和不必要的同步開銷。作者以Node.js的設計為例，強調其隔離問題、單線程處理的優勢，並批評了Golang、Scala等Actor模型的可擴展性。
+ 這篇文章顛覆了我一直以來的觀念，我總認為多線程是提升效能的關鍵，但作者的論點很有說服力，讓我開始重新思考我的程式設計方式。
+ 作者的觀點雖然很有趣，但實際應用中，並非所有問題都能簡單地分解成獨立的部分，因此單線程方法可能不適用於所有情況。
#軟體架構 #多線程 #CPU效能
Multi-threading is always the wrong design - uNetworking AB - Medium

Say what you want about Node.js. It sucks, a lot. But it was made with one very accurate observation: multithreading sucks even more. A CPU with 4 cores doesn’t work like you are taught from entry…

Medium
GripNewsMar 29
🌗 我為什麼不再和建築師談論微服務
➤ 微服務的概念與實際應用之間的困境
✤ https://blog.container-solutions.com/why-im-no-longer-talking-to-architects-about-microservices
在軟體架構評審會議上，作者對於微服務的討論感到沮喪。微服務的定義不明確，討論常偏離實際業務目標。作者認為對於微服務的抽象討論無助於解決具體挑戰和問題。
+ 這篇文章指出了軟體開發中常見的問題，強調了將注意力轉向解決實際問題的重要性。
+ 微服務在組織上的挑戰被提出，突顯了技術討論應該與業務目標緊密結合。
#軟體架構
Why I'm No Longer Talking to Architects About Microservices

I'm done talking about microservices: the term is confusing, discussions are abstract, and without organisational change, microservices are pointless

GripNewsFeb 5
🌘 康威法則
➤ 認識康威法則的影響
✤ https://martinfowler.com/bliki/ConwaysLaw.html
康威法則指出，系統的架構通常與開發團隊的組織結構相似。這一觀察表明，團隊的溝通方式會影響軟體設計，因此若架構與團隊結構不一致，可能會導致系統架構的緊張和不協調。注意這一法則的存在，並適當調整團隊架構，有助於促進所需的軟體架構設計。
+ 這篇文章讓我意識到團隊溝通的重要性，原來架構設計不僅僅是技術問題，還涉及人與人之間的互動。
+ 我從來沒聽過康威法則，這讓我重新思考了我工作的組織方式。這真的很有啟發性。
#軟體架構
bliki: Conway's Law

Systems are constrained to follow the communication patterns of their designers.

martinfowler.com
GripNewsJan 22
🌘 里斯科夫替換原則：繼承的真實意義
➤ 確保LSP合規的實用建議
✤ https://cekrem.github.io/posts/liskov-substitution-the-real-meaning-of-inheritance/
里斯科夫替換原則（LSP）是SOLID原則中最常被誤解的部分，該原則強調如果S是T的子類型，則T的對象可以被S的對象替代，而不改變程式的期望行為。具體而言，這涉及繼承和行為的相容性問題，並以長方形和正方形的例子說明LSP的違反。通過合成和介面而非繼承，可以更好地設計程式結構。
+ 這篇文章解釋得非常清楚，讓我明白了繼承中的潛在問題！
+ 我以前對LSP的理解不深，現在知道應該如何避免違反原則，感謝分享！
#軟體架構 #SOLID #繼承
Liskov Substitution: The Real Meaning of Inheritance

Part 3 of our Clean Architecture series, exploring the 'L' in SOLID

cekrem.github.io
GripNewsOct 18, 2024
🌘 連接器應該享有元類別地位
➤ 本文探討瞭如何以直接方式在程式實作中表達架構連接器，避免維護重複性描述所帶來的問題。
✤ https://dl.acm.org/doi/10.1145/3689492.3690052
本文提出了一種架構導向的程式語言Objective-S，運用超出程序調用的方法來表達組件連接器，以直接在實作中表達各種架構模式，進而避免維護重複性描述所產生的問題。
+ 這篇文章強調了在軟體架構中直接表達架構連接器的重要性。
+ 透過元對象協議實現多態連接器，確實有助於提升程式碼的通用性及易維護性。
#軟體架構
Beyond Procedure Calls as Component Glue: Connectors Deserve Metaclass Status | Proceedings of the 2024 ACM SIGPLAN International Symposium on New Ideas, New Paradigms, and Reflections on Programming and Software

ACM Conferences
GripNewsSep 16, 2024
🌘 百頁樓先行策略
➤ 從一體式系統到微服務的演進
✤ https://martinfowler.com/bliki/MonolithFirst.html
考慮到成功案例，將新應用程式起初建立為一體式系統可能更為明智，以避免微服務架構所需的巨額成本和設計複雜度。優先建置百頁樓可快速確認系統的有用性和適當邊界，避免後續微服務需面臨的問題。
+ 這篇文章提供了清晰的比較，幫助瞭解何時該選擇使用百頁樓先行策略。
+ 建議有興趣發展軟體架構的人士深入閱讀，可獲得重要見解和策略建議。
#軟體架構
bliki: Monolith First

Going directly to a microservices architecture is risky, so consider building a monolithic system first. Split to microservices when, and if, you need it.

martinfowler.com
GripNewsSep 3, 2024
🌘 事件驅動核心，請求-回應殼
➤ 不是每個系統都得全面事件驅動
✤ https://www.reactivesystems.eu/2024/08/31/event-driven-core-request-response-shell.html
事件驅動架構並非系統的每個層面都必須是事件驅動的。在系統的外殼中，與用戶、遺留系統或第三方系統進行介面時，如果必須使用請求-回應方式的溝通，仍可達成。但在系統核心，系統間的溝通應以事件為主。這樣能實現時間解耦，提高整個系統的可用性。儘管被限制在覈心範疇內，採用事件驅動依然有著很大的價值。
+ 這篇文章很清楚地闡述了事件驅動架構的核心價值，對於軟體開發者來說是一個很好的參考。
+ 通過事件驅動，系統的解耦合度會增加，有助於提高系統的穩定性。
#軟體架構
Event-Driven Core, Request-Response Shell

There’s much uncertainty and doubt (and maybe even fear?) around event-driven architecture. One example is the belief that it’s irrelevant for REST APIs, as using HTTP verbs is quite clearly not event-driven. But behold - you don’t always have to go all-in to win.

GripNewsAug 29, 2024
🌘 統一網格：我們如何為最大的客戶重構 Slack
➤ 從簡單架構到統一網格：Slack 的演進之路
✤ https://slack.engineering/unified-grid-how-we-re-architected-slack-for-our-largest-customers/
Slack 在 2013 年推出時擁有簡單的工作區架構，但隨著使用模式變化及 Enterprise Grid 的推出，使用者常需在多個工作區間切換，這促使我們開發統一網格（Unified Grid）來提供統一視圖及提高效能。統一網格的目標是改善使用體驗並消除因多工作區同步數據而產生的錯誤，這需要對 Slack 的核心架構進行重大更新。
+ "這篇文章很好地解釋了 Slack 如何通過重構架構來解決多工作區的問題，非常具有啟發性。"
+ "統一網格的介紹讓我對 Slack 的架構演變有了更深入的瞭解，期待看到這些改變如何提升實際使用體驗。"
#軟體架構 #技術創新
Unified Grid: How We Re-Architected Slack for Our Largest Customers - Slack Engineering

All software is built atop a core set of assumptions. As new code is added and new use-cases emerge, software can become unmoored from those assumptions. When this happens, a fundamental tension arises between revisiting those foundational assumptions—which usually entails a lot of work—or trying to support new behavior atop the existing architecture. The latter …

Slack Engineering
GripNewsAug 27, 2024
🌘 用防火牆保護你的代碼
➤ 引入精細的訪問控制以提高代碼安全
✤ https://lackofimagination.org/2024/08/firewalling-your-code/
在編寫代碼時，通常對公開的屬性和方法進行無限制訪問。近期，筆者探討瞭如何引入更精細的訪問控制，借鑒了網絡防火牆的概念，開發了一個 Node.js 庫 `firewall-js`。該庫通過文件系統結構限制對代碼部分的訪問，並展示瞭如何設置訪問規則以防止未經授權的調用，從而增強代碼的安全性和可維護性。
+ 這種基於文件系統的訪問控制方案對於大型專案是否也能有效呢？
+ 使用這種防火牆方法是否會影響代碼的性能或維護成本？
#軟體架構
Firewalling Your Code

When writing code, you can call any function as long as it’s public, and similarly, you can access any object’s public properties or methods. Usually, access to code is all or none – a piece of code can be either public or private. Lately, I’ve been thinking about ways to implement more fine-grained access controls and have looked to the networking world for inspiration…

Lack of Imagination