微服務的危害

圍繞微服務有很多炒作，而抨擊巨石型應用程式似乎在 HackerNews 和 Reddit 上蔚為風潮。很高興聽到 DHH 讓一些理智回歸對話。

大型公司通常有非常好的理由積極地將應用程式分解為 Centi、Milli 和微服務。對於工程師團隊人數為個位數或兩位數的情況，這簡直是胡鬧。

微服務解決了什麼問題

微服務從根本上解決了大型工程師團隊中的協調問題。

它們使獨立部署較大應用程式的不同部分變得容易。它們也將問題分解為小的複雜性單元，這些單元可以被理解、測試和修復，而無需了解整個系統。

一旦你得到一個龐大的巨石型應用程式，將其分解也可以大大提高開發人員的生產力，因為如果你只在單個服務的範圍內工作，編譯、程式碼檢查和測試時間將大大縮短。

它們還通過部署機制而不是約定在單個程式碼庫中使用程式庫來強制執行這種分離。這使得人們更難打破你的程式碼的封裝，通過強迫他們通過發布的 API 來使用它。

諷刺的是，它們也解決了公司政治中長期存在的與他人良好合作的問題。現在你可以忽略整合問題，只需指向你的微服務並說「所有測試都通過了，而且它能工作！」並在你的下次考核中看起來表現良好。

解決你實際遇到的問題

太棒了。聽起來像是針對一個高效能、大型工程團隊在一個政治複雜的大型場所遇到的問題的絕佳解決方案。

這描述的是你目前的問題嗎？如果你是一家典型的早期新創公司，你的問題應該看起來像

• 驗證產品是否為其目標用戶提供服務
• 找出客戶獲取策略，並在促進此策略的產品邊緣快速迭代
• 通過使部署更容易且不易出錯來獲得更多睡眠時間
• 幫助公司其他過勞的員工完成他們的工作

那麼...將應用程式分解為服務到底能給你帶來什麼好處呢？

巨石型應用程式是早期新創公司的理想選擇

部署很簡單。設定 CI，自動化部署並經常部署。使用巨石型應用程式，你可以知道它是否已部署。

系統範圍的變更可以在一個地方完成，你不需要顯式地對破壞性變更進行版本控制，因為所有程式碼都在一個地方。這使得迭代新功能更快。

一切都在一個地方。雖然這意味著有更多的東西需要理解，但有一種奇怪的觀點認為，將程式碼分散在 10 多個儲存庫中，不知何故使人們更容易理解整個系統。當然，對於初級開發人員來說，查看單個服務並理解它更容易。但是，認為創建數十個服務的心智模型不知何故比單個程式碼庫中等效的模組更容易，這簡直是胡說八道。當然，當你達到 100 萬行以上的程式碼時，情況會變得瘋狂，但這不是你現在遇到的問題。

微服務的分析後果

因此，除了長期存在的「有人在網路上犯錯」的問題之外，為什麼這篇文章會出現在 Metabase 部落格上？嗯，主要是因為在你的分析能力方面，使用微服務有一個非常嚴重的後果。

如果你有一個解耦的資料模型，在某些時候你會想要很好地...將其重新耦合在一起，以便你可以分析你的業務狀況。微服務的主要支持者往往是大型公司的工程師（他們有小型的資料工程師團隊來將事物縫合在一起...你有嗎？）、顧問（任何使個人顧問看起來不錯並在以後增加計費時間的事情都是好事），或者是不想與公司其他人協調的工程師。

如果你在微服務之上堆疊「為工作選擇正確的資料庫」的額外瘋狂行為，情況會更糟。在這裡，你突然需要有一個跨所有這些閃亮的小雪花的穩定 ETL 故事。

為什麼要在意？

嗯，大多數時候，當你是一家早期新創公司時，你並不知道確切要構建什麼。你會有一個想法，希望有一些早期用戶和一個夢想。為了改進你的產品，你需要了解正在發生的事情、哪些產品功能在起作用、哪些不起作用、用戶的行為方式等等。

根據定義，你也會有太少的人來完成工作。因此，為了經營業務，你需要讓非工程師（或在這種情況下，除了編寫微服務的人以外的任何人）更容易提取資料。

在某些時候，程式碼庫的大小將促使你將其分解為服務，並承擔隨之而來的所有運營麻煩。在那之前，盡可能長時間地使用簡單而乏味的巨石型應用程式。

簡而言之 - 微服務解決了你作為早期新創公司沒有的問題，並使迭代更加困難。盡可能長時間地使用巨石型應用程式。