分散式系統設計 - 正體中文版翻譯記事


去年翻譯了這本書: 分散式系統設計 (Designing Distributed Systems, DDS) 在 2019/05/20 上市了。以下純粹是譯者自己的筆記與心得,非官方。


初衷

翻譯書的初衷是學習。

分散式系統 (Distributed Systems) 一直是我很感興趣的主題,特別是在過去幾年的工作經驗中,花費大量時間在研究 雲計算、公有雲 (AWS / GCP) 的技術實踐、解決方案。研讀了不少技術文件、實踐方法、設計實務,也實際應用在工作。但在這過程,心裡難免會有所疑惑:這樣主軸會不會過於限制?不夠一般化?用今天的名詞來說,叫做 Vender Lock-in。而這也違反大部分熱愛 OSS (Open Source Software) 的原則,也不符合我個人的理念。

在這過程中,新興實踐架構 微服務 (Microservices) 正流行,也研讀過不少經典的書,像是:

同時,加上這幾年我在維運 (Ops) 上的經營與研究,像是 DevOps、CI/CD/Pipeline、SRE、持續交付 … 等,以及過去在 軟體測試 的實務經驗,這些總結起來,回到現在看到微服務,以因果論來看,微服務是個時代的必然物,也就是在整個趨勢來看,有這樣的架構實踐,是早晚的事,但這只是一種實踐的方式,最後還是會回歸到 本質性的問題

微服務的本質是什麼?

思索這問題的過程中整理了 『聊聊分散式系統』 一文,嘗試將探索的方向做收斂。

回想

學生時代,因緣際會,一位曾經在 昇陽 (Sun Microsystems) 工作的教授跟我分享一段故事:

透過 Sun 的 Solaris ,十台 Workstation 可以連起來工作,透過分散式運算達到 9.5 台的效果。

當時的我,不是很清楚這是怎麼一回事,那是怎麼辦到了,但對於分散式系統有了初步的想像。

同樣的,學生時代在玩編曲的時候,在那年代軟體取樣音源 (Sample) 剛起步,但卻讓編曲玩家趨之若鶩。編曲 (MIDI) 完成後,進入混音階段前,需要把每個 Track 分別從 MIDI 轉換成 Wave,這個過程稱為 過帶 (Tracking) 程序,這程序需要大量的運算與 I/O。那時候業界流行透過星狀網路,連結多台電腦分工作處理音源處理與轉換,達到加速的效果。我沒有實際跑過,但知道怎麼做,但也因此,分散式運算的也再次在我心裡埋下探索的因子。


這本書雖然叫做 分散式系統設計 (Designing Distributed Systems),但實際上這本書對於 分散式系統 基礎概念並沒有太多著墨,像是 一致性問題共識演算法分散式鎖分散式治理 … 等,整本書的核心在於透過類似 Design Pattern 與物件導向程式設計 (OOD) 的概念,淬煉出來的三大類設計樣式,搭配 Kubernetes 實踐當作範例。重點在於這些可重用的 樣式 (Patterns),而這正是這本書的精髓所在。

翻譯原則

  • 我沒有寫 譯者序,因為這不是這本書要傳達的。
  • 沒有 譯者介紹,理由同上,想認識我可以 點這裡
  • 譯者不是作者,所以原則就是傳達作者的意念,所以盡可能不要有譯者過多個人的 渲染,反客為主。
    • 概念原則來自於 作曲編曲
  • 翻譯盡可能簡單,用詞以 正體中文 為主。

探索

2016 年研究 AWS DynamoDB 背後原理 時,發現其理論基礎源自於 Dynamo: Amazon’s Highly Available Key-value Store, 2007Eventually Consistent 與 Dynamo NWR 模型,循著這個思路不斷地探索,也找到 Google 三大經典論文:Google File System (GFS)MapReduceBigTable ,以及這幾年逐漸成形 NewSQL 產品:CockroachDBGoogle SpannerAWS Auroa

在工作上這幾年經常遇這些名詞:Paxos、Raft、Shard、Node、Replica、Partition、Locked、Message,一些著名的 Middlewares,像是 Redis、Memcached、Hazelcast、Elastic Search、MongoDB、MySQL、etcd、consul .. 他們的文件都一再出現前述名詞與概念。在 SRE 領域 更常出現的是 HA、Scale、Mesh、Rate Limit …

研讀的過程,覺得要收斂一個範圍,因為繼續挖下去,會變成無上限的發散,所以我開始思考收斂的方向。2017 年中,我在組織內推行一種用物件導向概念的架構思維方式,讓大家能夠都用 OOP 與 Design Patterns 概念來思考架構,特別是在討論架構的過程,如果可以以此為依據,團隊的產能與架構的效能應該會很容易提升。下圖是我後來自言自語的紀錄:

物件導向的架構思維,在 2018 年 DevOpsDays 的 演講:從緊急事件 談 SRE 應變能力的培養 有提到基本概念。

幾個月後,約莫 2017 年 12 月,K8s 架構師 Brendan Burns 發表了這本書。讀了前面幾張之後,發現與我的想法很雷同,決定以這本書作為起始點,收斂自己的方向。


結論

很多年前在設計 Test Framework and Architecture 的時候,那時候的架構需求,要能處理、且自動分配每天晚上執行的自動化測試程式,這些程式如何好好利用那兩櫃的機器,平行執行,並且不會相互干擾,資源有效最大化的利用,當時思考底下:

  • 有多少資源可以利用?
  • 每個 Testcase 如何分配資源?如何重跑?
  • Testcase 在跑的時候,如合做到重新部署、與 testcase 的配置?
  • 如果 Testcase 沒跑完的機器,資源如何釋放?

這個架構雖然是設計給自動化測試的,但實際上同樣的概念類似於批次處理 (類似 AWS Batch)、工作流程 (類似 AWS Step Functions、Simple Work Flow)、資源分配策略 (AWS ECS Task Placement Strategies, K8s Deployment Strategies)。這個實作的心路歷程,讓我對 分散式系統 (Distributed Systems) 埋下了探索的因子,而藉由翻譯這本書,算是讓我真正開啟探索與入門之旅。

  • 前述的測試架構有一個核心功能: 資源分配策略控制器,有興趣的朋友來玩玩看看,說明放在 GitHub
  • Study Notes - Step Functions 一文也分享了一些關於分散式架構的想法。

延伸閱讀

站內延伸

相關論文


Comments