沉思於軟體架構從整體到微服務

我最近一直在計畫一些個人專案，而這個主題引起了我的注意。我已經看到了太多關於微服務的炒作，因此我需要將自己的想法放到視野中。我知道微服務是乙個非常有效的架構模型，並且一旦擴充套件就可能是雲軟體開發的必然階段……

但是我認為從乙個新專案開始就使用微服務架構風格是乙個壞主意。我看到微服務架構在基礎架構上增加了巨大的複雜性開銷，並且開發人員需要採取許多與**不直接相關的額外步驟來完成其工作，即通訊和協調。

基本上，您不僅需要乙個團隊來構建微服務架構，而且還需要乙個非常優秀的團隊。構建不良的微服務架構非常容易，因為它涉及非常高階的任務，這些任務對於普通開發人員或基礎架構經理而言並不直觀。

我看到小型公司試圖向微服務「躍進」，但它們不符合這種飛躍的標準，它們像亞馬遜和netflix這樣的大公司也有所作為。

前段時間，我讀過一篇有趣的文章，內容涉及試圖模仿大型公司的小型公司，這是：乙個叫oz nova的人「 you are not google」。

我並不是說微服務僅適用於有巨大需求的大公司，我的意思是，您需要真正有必要實現微服務的飛躍，並且擁有合適的人員和專有技術，否則事情會非常艱難。錯誤很快。

不要僅僅因為其他人正在這樣做而這樣做。

糟糕的微服務架構比好的單片架構要糟糕得多。

還應考慮到執行微服務的成功公司已經開始使用整體應用程式。

我相信公司生產的軟體架構必須反映其通訊結構。嚴重的是，如果公司只有乙個只有十個人的團隊而沒有專業知識，那麼它的軟體應該是乙個整體的應用程式，或者應該盡可能的接近。我認為不可避免的是，人數應與應用程式的增長成比例地增加。

因此，當需要時，考慮到最佳團隊規模（十人），將拆分並壯大單個團隊，然後有必要開始拆分整體應用程式以反映這一點。

每個團隊最好負責一項服務。

可以肯定的是，軟體和組織將一起發展，並且在某個時候，組織將需要更多的團隊，並且在這種情況下最有效的軟體架構將是微服務。因此，如果軟體足夠成功，最終將需要微服務。

從整體到微服務的這種自然發展必須得到最佳結果，並且您應該花時間培訓開發人員，並確保他們知道自己在做什麼（如果您沒有專業知識的話）。

不要因為其他大公司正在這樣做而直接進入您不知道的事情。

開發軟體完全是關於實用主義，謹慎和耐心的。偉大的軟體不是構建出來的，而是像生物體一樣生長，**，合併，再**。

這是管理非常複雜的系統的複雜性的遊戲，還有什麼比自然界更好的老師？

只是環顧四周，有時我們提出的問題已經被大自然或文明回答。

觀察人類組織如何成長和專業化以優化文化和溝通。細胞如何生長，然後**為更多的細胞，以構建更複雜的東西。優雅地，理想地，生物如何誕生，生長，繁殖然後死亡。

leonardo venturini是來自巴西的年輕開發人員和數字企業家，曾從事小型erp和crm系統的開發。

他對企業家精神，程式設計，資料建模和軟體體系結構有著極大的熱情。

：kaique rocha跳上聯運貨櫃的人

from:

沉思於軟體架構 從整體到微服務