大多數公司不需要Netflix/Uber風格的微服務？ - copyconstruct

banq發表於2021-03-16
微服務Struct

微服務很難，構建可靠且可測試的微服務比大多數人認為的要難得多，有效地“測試”微服務需要大量的工具和遠見。-許多（或大多數）公司組織都不需要Netflix / Uber風格的微服務。
宏服務Macroservices？
  • -並非整體/單體monolith
  • -有不超過20個開發人員/ 3個團隊從事該服務（5個披薩規則？）
  • -可能需要或不需要Monorepo。服務/儲存庫越少，依賴關係管理就變得容易得多（儘管仍然很簡單）
  • -更好的可觀察性，除錯

 
網友討論：
去年，我們就Micro與Macro進行了廣泛的討論。儘管“千篇一律”的方法行不通，但關鍵是要了解並預見什麼對業務至關重要。
需要考慮的幾件事：
  • -垂直與水平縮放
  • -技術債務的嚴重程度
  • -多少服務
  • -API架構/基礎設施/效能
  • -服務的使用者/客戶使用情況

更大且可擴充套件（宏）的服務比小型和複雜的服務（微型）更好。
 
我認為人們仍糾結於部署模型的關注點分離和解耦。用micro / macro字首的服務也無濟於事。我們需要考慮有界的上下文，而不是大小。
 
此外，透過網路進行越來越多的分散式分發意味著您要冒資料完整性的風險。似乎範例已在轉向事件溯源，事件溯源eventsourcing建立在資料庫如何處理資料完整性的基礎上。
 
我同意。我還注意到，當人們談論ms時，他們首先想到的是可伸縮性。但是，我傾向於將ms視為擴充套件團隊而不是系統的一種方法。例如，我可以提到兩個披薩亞馬遜的規則。
 
大多數認為自己需要微服務的人都希望兩件事中的一項：
  1. 能夠輕鬆地水平擴充套件
  2. 圍繞功能邊界分離開發團隊。

這些都不需要微服務解決方案。是那些做起微服務很酷的開發者很危險。
 
微服務並不難，只需遵循12個要素，我們就可以完成並部署到dev，qa和prod docker和k8s。測試就可進行。
 
建議：當一個團隊維護許多獨立服務時，這是有問題的。當許多獨立團隊維護一項服務時，那也是錯誤的。因此，當這兩中情況（不可避免地）成為現實時，需要懷疑：我們正確地劃分了我們的服務嗎？
 
微服務並非難事，分散式應用程式並非難事。我要說的是，如果您需要跟蹤，那麼您將遭受分散式系統工程的困擾，而不是微服務的痛苦。
 
我的想法：整體→SOA→微服務。根據域和最佳化需求進行分解，並使事情變得更細化。
 
這全都與粒度有關...如果我們確定正確的粒度，則Micro或macro都是無關緊要的。服務發現，斷路器或閘道器服務，特定於服務的資料庫隔離等都是必不可少的。
 
分散式整體是等待發生的FLP故障。
 
微服務最難的不是技術。這是因為他們需要實際的開發人員自治權才能做好，而大多陣列織只是不想真正做到這一點。
真正的自治權要求每個團隊複製很多東西：包括模式，商品元件，基礎架構和工具。這並不便宜，並且使團隊脫離了核心業務需求。透過dedup可節省資金，但會消除自主權並導致依賴。
 
按照這個定義，宏服務難道不是一堆透過共享程式碼在相對寬泛的範圍內耦合的微服務嗎？

 

相關文章