Martin Fowler 在 2015 年寫的 MonolithFirst,以及 Microservice 的問題

Hacker News Daily 上看到「MonolithFirst」這篇,是 Martin Fowler 在 2015 年寫的文章,對應在 Hacker News 上的討論「Monolith First (2015) (martinfowler.com)」也頗有趣的,可以一起翻。

tl;dr:他的文章就是在講新專案用 monolith,不要去碰 microservice。

文章開頭提到了就他觀察到的情況:第一點是,幾乎所有成功的 microservice 案例都是從 monolith 起頭,再轉到 microservice 環境;第二點是,幾乎所有一開始用 microservice 的案例,在後來都遇到嚴重的問題:

As I hear stories about teams using a microservices architecture, I've noticed a common pattern.

  1. Almost all the successful microservice stories have started with a monolith that got too big and was broken up
  2. Almost all the cases where I've heard of a system that was built as a microservice system from scratch, it has ended up in serious trouble.

This pattern has led many of my colleagues to argue that you shouldn't start a new project with microservices, even if you're sure your application will be big enough to make it worthwhile. .

文章接著有兩個猜測,試著去解釋為什麼。

第一點可能的原因是 Yagni (You Aren't Gonna Need It),在試驗市場時 PoC 或是 MVP 的商業邏輯反而不會那麼複雜,快速用 monolith 開發驗證比起擁抱 microservice 來的重要太多,而且可以快速修改。

第二點分成兩個現象:第一個現象是,即使是對產品的商業領域很有經驗的資深架構師,也很難一開始就切出正確的 BoundedContext;第二個現象是,在 microservice 裡,改架構的難度比起 monolith 高非常多 (i.e. 跨 boundary 的 refactoring)。這兩個現象加在一起就會造成一開始導入 microservice 的專案失敗。

文章接著想要提出一些建議,在一開始使用 monolith 可以注意的方向,這些注意的事項可能可以讓之後轉成 microservice 變得比較輕鬆。

第一種方式是在 monolith 架構下注意 API boundary 與 data 的儲存方式,當想要切換到 microservice 的時候就有機會比較簡單。

第二種是更常見的方式,一開始先是 monolith 架構,然後把 boundary 好切割的拆成 microservice,所以在過度期會是一組不那麼大的 sub-monolith 架構,然後週邊圍繞著很多 microservice。這個做久了就有機會轉成全部都是 microservice。

第三種方式就是砍掉重練。

第四種方式是一開始的時候不用 monolith,而是幾個很大包的 service (所以一開始不太能叫 microservice),當商業模式成熟穩定後,切出更細緻的 boundary 的時候再拆成 microservice。

把這篇文章拿去搜尋 Hacker News 上的討論,可以看到除了 2021 年的這次討論外,在 2017 年的時候就有一批討論也蠻有趣的,可以看到有些不同的風向:「Monolith First (2015) (martinfowler.com)」。

當然也未必要信 Martin Fowler 的看法,軟體工程這塊還是有很多不同的流派...

Elon Musk 退訂美國總統的 Twitter 帳號

先前因為 cjin 的這則推,跑去追蹤了 @BigTechAlert 這個帳號:

@BigTechAlert 這個帳號會把名人以及大企業的 Twitter 帳號所追蹤與推追蹤的行為找出來,然後發表在 Twitter 上面。

平常 @BigTechAlert 所抓出來的追蹤與退追大家也都習以為常,你去看 @BigTechAlert 的帳號也可以發現沒什麼 retweet & like。

但前幾天這則退訂通知讓不少人 retweet & like,因為是 Elom Musk 退追了 @POTUS 帳號 (也就是 President of the United States):

退追的真實原因不知道,但看到純粹覺得很有趣...

PHP 的 empty()

Nuzzel 上看到的文章,講 PHP 裡不應該使用 empty():「When to use empty in PHP? I’d say never」。

之前寫 PHP 時很習慣用 ===!== 比較,另外習慣用 is_type() 先判斷型態再去搭其他的判斷 (像是 is_array()is_string() 這類型態確認),算是避免了文章裡面提到的問題,而且也提高了程式的可讀性 (因為開發者看到 is_type() 可以預期型態)。

比較討厭的應該是偶而還是會搞混 + (數字相加) 與 . (字串串接),還有 + 對兩個數字字串是可以操作的 (然後會傳回 int):

$ php -a
Interactive mode enabled

php > var_dump('123' + '456');
int(579)
php >

用過都說幹 XD

Cloudflare 在 Argo 架構上推出 Tiered Cache Smart Topology

Cloudflare 在 Argo 架構上 (付費功能) 推出了 Tiered Cache Smart Topology:「Tiered Cache Smart Topology」、「Introducing: Smarter Tiered Cache Topology Generation」。

這邊提到的 Argo 是 Cloudflare 在 2017 年時提出來想要降低 Internet 的 routing (像是 BGP) 未必會走到最佳路徑上的問題,透過 Cloudflare 自家的骨幹網路,最佳化 latency & bandwidth & packet loss 產生的問題:「Introducing Argo — A faster, more reliable, more secure Internet for everyone」。

而 Tiered Cache 算是 CDN 行業裡面很常見的技術了,主要是要解決不同 data center 的 edge server 都去跟 origin server 要資料,而造成 origin server 的流量太大。

緩解的方式是在 edge server 與 origin server 中間疊一層 cache server,就可以大幅緩解 origin server 的流量。

origin server 流量問題在一般的應用來說還好:就算是 Windows Update 或是 iOS 更新這種基數超大的量,一開始也許會慢一點,但當 edge server 有 cache 後就不會再吃到 origin server 的頻寬。

另外也可以在公開上線前先 pre-warm,讓 edge server 都有 cache 後再上線,這樣 origin server 就不需要準備太多頻寬。

但在大型影音直播的時候就不一樣了,因為會一直產出新的內容 (之前玩的是走 HLS,所以會一直有新的 .ts 檔生出來),沒辦法先 pre-warm,這時候 origin server 就會需要大量的頻寬才有辦法支撐整個服務,所以需要 CDN 系統在中間疊一層 cache server,這個功能在各家 CDN 業者都有,只是名稱不太一樣。

記得當時用 Akamai 預設的 CDN 走直播時只有 95% 左右的 hit rate,這代表對外服務 20Gbps 就會對 origin server 產生 1Gbps 的量 (20:1),而打開 Tiered Distribution 後可以拉到 98% 甚至 99%+,相對於後端的壓力可以降到 50:1 到 100+:1。

AWSCloudFront 也有類似的架構,叫做 Regional Edge Caches:

不過這兩種架構都有一些缺點,像 Akamai 需要自己指定 cache server 的節點,這樣就不容易動態調整,或是使用者沒有設好導致 latency 偏高。

而像 AWS 這種已經已經先分好群的,就會遇到像是 origin server 與 edge server 都在台灣,但在 Regional Edge Caches 架構下必須先繞到日本 (或是新加坡),產生 latency 與 packet loss 偏高的問題。

這次 Cloudflare 在 Argo 架構推出的 Tiered Cache Smart Topology 的賣點 (Argo 本來就有提供 Tiered Cache),看起來是希望由系統自動選擇最佳的一個 data center 來當作 cache tier,不需要使用者額外設定。

不過一般網站應該還好,主力應該在電商網站與互動性很高的娛樂產業 (i.e. 操作起來要很流暢)...

PinePower 120W 充電器

在「PinePower 120W desktop power supply features display, USB PD, QC 3.0 and wireless charging」這邊看到 PinePower 120W 這個充電器:

提供了一個 Type-A QC 3.0 (18W) + 三個 Type-A 5V/3A (15W) + 一個 Type-C PD (65W),然後還有一個 Qi (10W),算了一下這些組合全部都跑滿要 138W,然後機器的上限提供 120W,這個集縮比超低,看起來也是頗猛的...

目前 out of stock,剛好可以等其他用過的人的評價...

LastPass 開始進入「殺」的階段,免費使用者只能在一個平台上使用

LastPass 進入了「套養殺」最後一個階段「殺」,宣佈縮減 LastPass Free 的可用範圍。在 2021/03/16 開始 (一個月後),LastPass Free 的使用者只能選擇一個平台使用,像是「桌機平台」,或是「行動平台」:「LastPass’ free tier will become a lot less useful next month」,官方的新聞稿則是在「Changes to LastPass Free」這邊。

官方有提供第一年的限時優惠 (換算起來應該是一年 USD$27),但不給既有用戶,現有的用戶如果要的話得自己換帳號 export & import,不然就是用原價殺 (一年 USD$36):

If you’d like unlimited device type access and email support, you can upgrade from Free to LastPass Premium for a limited time, for $2.25 per month (billed annually). *

*Additional Terms and Conditions: Advertised price valid for new users on their first year of LastPass Premium. Price not valid for renewals or existing customers and cannot be used for other LastPass plans, products or services.

不過這個優惠連結發現點下去是爛的:

話說回來,這種東西我自己還是偏好用 open source 方案,然後自己搭同步機制,不過目前看到的方案在跨桌機平台與行動平台的確是痛點... 有需求的人應該還是會選 LastPass 或是 1Password 這樣的方案。

把 AWS 的 Billing 資料接進 Grafana 上...

Twitter 上看到 Grafana 的帳號提到了一篇把 AWS Billing 資料接進 Grafana 上的文章:

這個想法還頗不賴的,有些東西剛好可以交叉比對拉出來...

Google Groups 把 comp.lang.c 給禁了...

Hacker News Daily 上看到的,Google Groupscomp.lang.c 給禁了,連到 https://groups.google.com/g/comp.lang.c 可以看到無法使用的訊息:

警告:內容已遭禁止
comp.lang.c 已被認定為包含垃圾內容、惡意軟體或其他惡意內容。

如要進一步瞭解 Google 網路論壇的內容政策,請參閱這篇關於濫用本服務的說明中心文章,以及我們的《服務條款》。

這樣連歷史資料都看不到了...

在 HTTP Header 裡面傳結構性資料

忘了在哪邊看到的,好像是 Twitter 上看到的,mnotphk 兩個人弄了一個新的 RFC 標準,可以在 HTTP header 裡面傳結構性資料:「Structured Field Values for HTTP」。

第一個最直接的問題就在「A.1. Why Not JSON?」這個章節說明,考慮了既有的限制,包括 JSON spec,以及市場上既有的 JSON library 的實做。

但也因為自己定義了資料結構,Serializing & Parsing 就得另外再開發 library 處理,這樣會有多少 framework 支援就是個問題了,而且對於開發者來說,直接塞 JSON 很好理解,這個標準的前景不知道會怎麼樣...

Dehydrated 取得憑證的預設演算法改成 secp384r1

這兩天弄 dehydrated,結果發現 v0.7.0 取得憑證的預設演算法改成 ECCsecp384r1 了:

Using EC secp384r1 as default certificate type

這會導致很多「稍微舊一點」的 client 失效 (瀏覽器與 library),不知道為什麼要預設... 目前避開的方法是強制在 /etc/dehydrated/config 內設定使用 rsa

KEY_ALGO=rsa

剛剛把公司一堆機器改上去,然後把自己的 server 也加一加...