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

去年翻譯了這本書： 分散式系統設計 (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, 2007、Eventually Consistent 與 Dynamo NWR 模型，循著這個思路不斷地探索，也找到 Google 三大經典論文：Google File System (GFS)、MapReduce、BigTable ，以及這幾年逐漸成形 NewSQL 產品：CockroachDB、Google Spanner、AWS 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

About

著作

演講

Facebook

AWS Certifications