簡單軟體架構的一些好處 - Dan

Wave是一家擁有70名工程師的17億美元的公司，其產品是一個加減數字的CRUD應用程式。為了與此保持一致，我們的架構是一個標準的CRUD應用架構，一個Python單體在Postgres之上。從一個簡單的架構開始，並儘可能用簡單的方法解決問題，使我們能夠擴充套件到這樣的規模，而工程師們大多專注於為使用者提供價值的工作。

Stackoverflow擴大了單體架構的規模，取得了良好的效果（2013年架構/2016年架構），最終以18億美元的價格被收購。

如果我們看的是流量而不是市值，Stackoverflow是網際網路上流量最高的前100個網站之一

我們沒有大量的網路流量，因為我們是一個移動應用程式，但Alexa仍然把我們的網站放在前75000名。

將一個簡單的單體架設在枯燥的資料庫之上，可能不適合一些應用型別的需求，但是，對於大多數應用型別來說，即使是在前100個網站的流量水平上，計算機的速度也足夠快，它們可以用簡單的架構來提供服務，這通常可以比複雜的架構更便宜，更容易建立。

儘管簡單架構的效果不合理，但大多數媒體都關注複雜架構。

例如，在最近的一次通才技術會議上，有六場關於如何構建或處理複雜的、基於微服務的架構的副作用以及如何構建一個簡單的單體應用的零討論。最近在 SF 舉行的面向企業的會議就處理複雜架構的複雜性進行了兩位數的討論，而關於如何構建簡單的單體應用則為零。

我們的架構非常簡單，我甚至不會為架構圖而煩惱。相反，我將討論我們所做的一些無聊的事情，以幫助我們保持無聊。

我們目前正在使用無聊的Python同步鎖，這意味著我們的伺服器程式在等待 I/O 時會阻塞，例如網路請求。

我們之前嘗試過 Eventlet，這是一個非同步框架，理論上它可以讓我們從 Python 中獲得更高的效率，但是遇到了很多錯誤，以至於我們認為等待事件的 CPU 和延遲成本與痛苦處理 Eventlet 不成比例。從某種意義上說，我們為在網路請求期間只做等待的 CPU 付費，但由於我們每月只處理數十億個請求（目前），即使使用慢速語言，如 Python，並支付零售公共雲價格。我們工程團隊的成本完全支配了我們運營的系統的成本。

與其承擔使我們的單體架構變成複雜的非同步性，不如把長期執行的任務（我們不希望響應阻塞）交給一個佇列。

。。。點選標題更多

通過使我們的應用程式架構儘可能簡單，我們可以將複雜性（和人數）預算用於有利於我們業務的複雜性的地方。

除非有充分的理由增加複雜性，否則儘可能簡單地做事的想法使我們能夠建立一個相當大的業務，儘管經營著非洲金融業務，但工程師人數並不多，這通常被認為是一項艱難的業務進入。

Reddit網友討論

在許多情況下，單體架構可能是最佳的。Crud 應用程式似乎是最好的用例。藉助負載均衡器、簡單的 api 層、可分片的底層資料庫，也許還有記憶體快取層，一個 crud 應用程式可以支援數百萬使用者。

但是，並非所有應用程式都是雜亂無章的應用程式。許多應用程式都有搜尋和聚合等要求。許多應用程式的讀寫比率差異很大，這使得快取更容易或更難。還有資料一致性要求和分析。

甚至隨著時間的推移，一個簡單的 crud 應用程式也可以長出許多附屬物。

在這些情況下，一個簡單的單體可能是一個糟糕的決定。

當 CI 構建時間變得非常長時，通常會變得非常明顯，並且釋出過程變得越來越複雜以適應 crud 應用程式的相對複雜性。

微服務目的並非為了解決技術問題，它是為了解決組織問題。

單體非常適合一個小型的專門團隊。就像在初創公司中看到的那樣。

當肉湯變得足夠大以至於你需要很多廚師來攪拌它時，問題就開始了。

當團隊變大時，它就會失去凝聚力，程式碼庫也是如此。

在大型單體應用中執行標準非常困難：有足夠多的功能時，就很難區分什麼功能是什麼，這就可能開始影響穩定性。做出改變變得越來越難。我已經看到它發生在多個公司。這總是同樣的故事。

微服務（或僅僅是領域服務）不會神奇地使一切變得更好。

但如果做得好的話，它們至少可以讓我們更容易適應變化。