最近有機會重新架構一個新的專案，大家討論之後覺得想要試試 Clean Architecture 的架構，就稍微花了點時間學習了一下。不過因為只有粗略地翻過其中的一些章節，因此還只有在比較高層次概觀的理解，對於部份細節的實作還不是相當熟悉。這裡稍微紀錄一下目前為止理解的東西。
2021年1月14日 星期四
2020年4月19日 星期日
Replications
本篇為 Designing Data-Intensive Applications: The Big Ideas Behind Reliable, Scalable, and Maintainable Systems [1] 的讀書筆記。
Replication 指的是在分散式系統中將一份資料複製並存放在多個節點上，以帶來幾個可能的好處：
- 將資料複製到距離使用者較近的節點，以減少 latency
- 提高 availability
- 增加讀取的 throughput
一般討論分散式系統的 replication 時，關注的困難點都是如何處理資料的變化。因為若資料不會變化，那只要整個複製貼上就完工了，沒什麼困難點。但若資料會變化，那麼就會需要考慮多個節點間要如何控管資料的變化了。
2019年9月16日 星期一
2019年3月6日 星期三
Shuffle Sharding：AWS 如何最小化 blast radius？
在 AWS 社群看到有趣的研究，在講述 AWS 的架構中如何讓 blast radius（爆炸的影響範圍）最小？或者說當服務節點出問題時，讓受到影響的客戶端影響最小。以客戶端來說，狀況的假設是客戶端發出 request，request 透過某種 Routing 送進後端的服務節點，不過因為某種原因 request 造成了服務節點崩潰。此時客戶端會繼續嘗試重發 request，然後如果 Routing 的機制沒有特別地設計的話，終究客戶端的 request 會一台一台地把所有後端服務節點全部弄掛，導致整個服務中斷。
2019年2月27日 星期三
(書籤) 微服務的管理
微服務在最近幾年蠻盛行的，嗯…或者該說是非常盛行？不過概念上我目前的認知是，它把本來巨大的服務拆解成很多比較小的服務，以達成讓每個比較小的服務容易維護的目的。但同時這會帶來副作用，也就是微服務之間的管理成本會大幅提昇 [1]。實際上這也是很容易想像的事情，因為本來我們認為巨大的服務內部有混亂的互相呼叫的關係（Spaghetti Code [2] 的一種），讓程式碼變得難以維護；而當我們把它拆解成比較小的服務時，各個微服務內就會比較沒有那麼混亂的關係，進而讓每個微服務變得容易維護。但到這裡其實我們根本沒有解決問題！微服務跟微服務之間依然需要互相呼叫，也就是那些所謂的 Spaghetti Code 的關係並沒有被消除，只是被從程式碼內拿到程式碼外而已。所以雖然每個微服務的維運變容易了，但那些混亂又複雜的關係依然存在，而且變成存在於微服務和微服務之間，從程式碼問題變成是架構問題。這點在 [1] 這本書中開頭就有明確地提到，微服務是一種取捨、而不是 silver bullet，它不會解決所有的問題。當我們選擇微服務時，必須同時意識到它將要帶來的缺陷，並且要明確地確認組織能夠處理這個缺陷，才能夠往微服務發展。
在 TWJUG 的活動 [3] 中聽到 Apache Camel 這個工具，雖然說嚴格來講覺得沒有真的打到點，不過再看到最近社群到處轉貼的文章 [4]，就覺得好像有點靈光一閃 (?)，所以就先做個紀錄 XD。
參考資料
訂閱：
文章 (Atom)