不是專案起步就該做到 Microservices, 而是循序漸進, 慢慢轉變

[ChaoLiou]

其實此篇文章並無過多艱深的專知(專有知識), 只是簡單闡述為何不應該無腦地跟風 microservice 架構. 基本上, Software 領域的技術皆是日新月異, 不管檯面上的技術多熱門, 都該理性客觀地分析適不適合自家專案.

[name=Chaol Liu][time=20181102] derived from...

Microservices Are Something You Grow Into, Not Begin With

nickjanetakis.com

[name=Nick Janetakis] [time=Tue, 21 Aug 2018 04:00:00 GMT]

---

來聊聊甚麼時候該開始用 microservices. 暴雷警告: 每種專案的情況都不盡相同

• 身為軟體開發一員, 都有一項相當有趣的職業病. 我們會開開心心 coding 一整天, 然後讀一篇文章, 突然間, 你就開始質疑自己剛寫完的程式是否落伍. 例如: Netflix 當時帶領了一股運用 microservice 架構的風潮, 網路上有許多文章, 造成各家工程師花費大筆成本改寫.
• 就如同那件事, 由一個獨立個體, 或一間公司的某一項意見, 就讓你開始質疑你這幾年所做的事, 甚至你原本做得已經很優秀了, 你還是會質疑自己.

你不是 Google

• 當我們瀏覽 HackNews 和其他 news outlet(新聞出處)時, 經常會看到 Google, Netflix, Amazon 和 Facebook 的技術文章, 他們都樂意分享, 因為 microservices, 執行了上百或上千個 service 而帶來多少好處. 過去幾年都流行大公司分享技術.
• 但面對事實吧. 你大概不會有一個專案有 1,000 位開發者同時進行, 而且專案還要超過 10年以上歷史.
• 只因為 Google 這樣做, 不代表你也應該要這樣做.
• 我們幾乎是在宇宙不同銀河系上, 不同檔次. Google 面對的問題, 很有可能我們這輩子永遠不會碰到, 同時也代表, Google 需要解決問題, 而我們卻不用.

大部分的軟體專案都是怎樣開始的?

• 大部分專案起步都是由一人做完所有程式工作. 現實中, 有上百萬件案例, 但我們看 Shopify 就好. Shopify 最初就是由 Tobias Lütke 一人開始寫的(底層是 Ruby on Rails, 現在仍是).
• 你覺得當時 Tobias 寫每行程式前, 都會癱坐在那, 煩惱要如何精心設計好每個完美的 microservice 嗎?
• 當然不會. 他在開發第一版的 Shopify 時, 我雖然不在現場. 但當時的版本只是一個賣滑雪用具的電商平台, 如果他跟我一樣(是一個典型的開發者), 大概會發生以下的事情:
  1. 在專案起步時, 會學一項全新的技術.
  2. 寫一些不習慣/綁手綁腳, 但運行完全正常的程式碼.
  3. 看著程式量逐漸增加會感到興奮.
  4. Refactor 去除那種 "該放火燒死" 的程式
  5. 每當要加入 production 一項新功能, 就再重複一次 loop
• 這看起來是一個很單純的 loop, 但對我來說, 我花了超過 20年才真正理解這 cycle 是如此深刻人心.
• 身為一位 PG, 你不會只因為外界謠傳需要具備甚麼最佳設置, 因而變強. 你要變強只能透過寫很多很多的程式, 而且都有確切意圖. 未來, 一旦你能開始第一手面對真實問題, 再用更好的寫法取代.
• 那些你取代的程式並不是浪費時間精力. 它能證明你有所成長.

來聊聊何謂 Code Abstractions

• 身為開發者, 我們都聽過一句話 "DRY: don't repeat yourself", 一般情況遵循它很合理, 但時常更適合先暫時 repeat yourself.
• 因為如果你要去 abstract 某個你不太理解的東西, 會造成 leaky abstraction(抽象洩漏).
• 我一般寫重複 code 到 3次以前都不會去想 refactor. 但當到第4次, 第5次, 就會去做.
• 是因為在你知道甚麼該改成變數, 甚麼該移除改寫成 inline 以前, 需要多看看這些 code 幾次, 看它們在不同情況下會怎樣.
• abstraction 層級, 從 inline 到 external libraries
  1. Write inline code(coding 成同一行)
  2. Duplicate code a few times in different spots(少數幾次在不同地方, 有重複 code)
  3. Extract duplicate code into functions/etc.(將重複 code 抽進 function)
  4. Use your abstraction(s) for a while(短時間暫時用你的 abstraction)
  5. See how that code interacts with other code(看看 code 彼此間作用會變怎樣)
  6. Extract common functionality into internal library(抽出常用功能到 internal library)
  7. Use internal library for extended periods of time(先一段時間用 internal library 當做擴充)
  8. Really understand how all of the pieces come together(確實理解每個部分, 與彼此的關係)
  9. Create external library(open source, etc.) if it makes sense(建立 external library)
• 這就是為什麼你無法 "發明" 一個好的 library 或 framework. 幾乎每個我們今日使用的工具, 都來自現實世界上的專案, 而這個我們愛用的工具就是從 internal 抽出來的.
• Rails 就是最佳範例. DHH(Rails 的作者) 並不是某一天起床, 然後就說 "噗! 該是時候把專案分成 models/, controllers/ 和 views/ 資料夾了"
• 並不是. 他開發出 Basecamp(一項產品), 產出特定幾種的開發模式, 然後就從 Basecamp 轉移到 Rails. 今日仍然是以這樣的過程運作, 在我看起來, 這就是唯一的原因, 為什麼 Rails 到現在還是如此成功.
• 完整經過測試後的 abstraction, 讓你寫出吸引眾人目光的程式. 這也是為甚麼幾乎所有 "某個程式語言裡的 Rails", 這種概念的 framework 都會失敗. 他們都跳過關鍵的 abstraction chain 然後覺得就只要把 Rails 所做的事情複製過來就好了.

Code Abstraction 和 Microservices 的關係

• 我所認知的 microservices 只是另一層級的 abstraction. 我不會一定說它就是上述列的第10層, 因為並不是所有 libraries 都會成為 microservices.
• Microservices 不是你第一天開始會用到的技術, 就像是你不會在第一天, 連一行程式都還沒寫前, 就去建立一個 external library. 第一天你根本不知道你要做甚麼 library.
• 所謂架構上的 microservices 是你以 code base 日復一日解決問題, 逐漸演變成一項 microservices.
• 你可能從未遇到這些問題, 而這些問題也能夠透過其他辦法解決. 看看 Basecamp 和 Shopify. 它們是目前都做得不錯的 monolithic applications(整合型應用程式).

monolithic applications: 整合型應用程式裡面有許多邏輯服務, 而且都密不可分. 一旦其中一個服務不可用時, 就會造成另一個服務也無法使用. 因此常被拿來與 microservice 比較, 因為 microservice 彼此獨立自主, 並不會有這樣的問題.

• 我不認為任何人會稱它們是 small application. 沒錯, 它們的運作沒有大到像是 Google 的規模, 但我們可以用不同角度檢視.

Shopify 單月以一個 Monolithic App, 創造出超過 1700萬 美金的收入

這段省略, 只是在吹捧 Shopify

何時該用 Microservices?

• 那真的要看你和你的團隊如何決定. 如果你的情況下使用 microservice 很合理, 也不需要去 Google "microservices vs monolith". 你現在早已了解.
• 但有一種情況是, 如果你有很多開發者, 都適合在各自獨立的功能上工作. 那或許擁有很多團隊, 各自負責產品不同功能, 就會非常適用 microservices.
• 記住一點, 假如你有一個小團隊, 而團隊內成長緩慢, 可能從 1 或 2 個 microservices 後就停止繼續增加了. 而且大概不會想把所有 service 都轉成 microservices, 變成整合上百 service 的產品.

把 libraries 都轉成 microservices 值得嗎?

• 值得一提的是轉成 microservices 後, 會帶來本身的挑戰與問題. 你只是把問題轉移到另一個問題上, 所以需要評估優缺點, 看是否值得在專案上使用.
• 其中一項最大的問題是 monitoring. 你突然間會有很多 services, 橫跨在多台機器上執行, 被不同角色存取, 而你需要一個方法能窺探所有詳細資訊.
• 這個工作很難達成, 因為理想情況是你會用一個統一 service 聚集所有 services 並顯示這些 metrics 資訊.

部分段落省略

• 總而言之, monitoring 只是眾多挑戰之一, 但我覺得舉出這一點就夠了, 因為比起其他挑戰更難解決.

最終想法

省略