溫馨提示×
您好，登錄后才能下訂單哦！
點擊 登錄注冊 即表示同意《億速云用戶服務條款》
您好，登錄后才能下訂單哦！
世界上大多數的應用程序，可能有90%，都是由單體結構（monolithic）完美地提供服務的。
Randy Shoup在Summit 2018年峰會上宣布，為了避免過度設計，我們應該從一個簡單的架構開始，并根據需要進行演進。在他最近發表的演講中，他描述了自己與在一些公司的項目經歷，這些公司起初規模很小，后來發展成為大型全球性互聯網公司，它們的架構在那段時間是如何演變的，以及他從IT的角度對新公司或新產品的建議。
Shoup曾在eBay、谷歌和Stitch Fix工作過，目前是WeWork技術副總裁。他的第一個例子是eBay，它于1995年作為一個為期三天的周末項目啟動，目的不是驗證商業概念(PoC)，而是為了看看是否有可能在網上做一些有趣的事情。今天，它已經是第五次完全重寫基礎架構，Shoup將該公司描述為一個多語言的微服務集合，并補充說Twitter和亞馬遜都經歷了類似的演變。
從某種形式的單體結構（Monolith）開始，以一組微服務結束，這對于Shoup來說是大公司的一種常見模式，并注意到這一模式中有兩個部分：
Shoup所提到的公司都非常龐大，在他們的規模下工作的架構對大多數公司來說是完全不合適的。大多數應用程序都是由單體結構提供服務的，Shoup在構建新應用程序或系統時的建議是，從簡單的開始，并根據需要改進整個系統的體系結構。
對于大多數公司和產品來說，一個常見的進展曲線包括：
根本不應該有任何花哨的架構——這個時點最關鍵的是原型。為了避免過度設計，我們應該不斷地問自己：“最想要解決的是什么問題？”這一階段的目標是盡可能快地探索解決方案，并以最小的成本來實現:
在這一階段，如果可能的話，不需要引入任何不必要的技術，例如使用谷歌廣告來查看是否有人點擊它，直接使用紙和筆或Excel電子表格就能解決大部分問題。
在構思及開始階段時，目標是滿足客戶的短期需求，并盡可能地降低成本。通常這個階段可以由一個4-6人組成的小團隊來進行快速迭代，項目時間一般很短，大概3-4個月，快速的探索解決方案。此時，通常很難預見將來要構建什么特性，因此只需要很少的架構，就足以讓我們快速前進。在這階段考慮的不是伸縮性的，而是應該使用簡單和熟悉的技術，并且絕對是單體架構——比如，一個應用程序和一個數據庫。而且基礎設施建議使用開發代價最小的，不要自己去構建；相反，可以使用平臺即服務(PaaS)或類似的技術服務。
在這一點上使用單體架構的優勢包括:
除了缺乏可伸縮性和單點故障外，單體架構的一個主要缺點是在模塊化方面不給力。但是在這個階段，這些都不是關注的重點。盡管如此，有意識地在單體架構中使用組件或模塊來遵守模塊化原則，為了后續的擴展提前做準備是值得的，這將簡化未來的服務拆分與系統重構。
什么時候需要重建這個龐然大物，以下是一些可供參考的征兆:
當我們進入擴展階段時，目標是領先于快速增長的業務，并保持應用程序正常運行。在組織環境中，這階段通常會增加團隊人員的數量，并在更長的時間范圍內工作，通常還需要引入可重復的標準化流程（例如，開發流程、發布流程）。
在技術方面，擴展階段通常意味著向可擴展的技術遷移。現在可以從整體上拆分單體服務，嘗試減少單個數據庫上的負載，例如創建一些數據的只讀副本實現讀寫分離。按業務拆分服務（例如，支付和計費服務），并引入中間件、消息服務等。
這個階段通常也是考慮是否應該將單體服務遷移到微服務的時候。此外還必須考慮存儲，使用單點主存儲是否仍然是存儲數據的正確方法。在QCon紐約2017大會上，Shoup展示了如何將單體應用程序增量遷移到不同領域的微服務和多個獨立存儲機制。
在《可伸縮性的藝術》一書中，描述了一個三維可伸縮性模型（AKF Scale Cube），其中三個軸表示不同類型的可伸縮性:
如果達到這個階段就是成功的標志。我們的目標是維持功能穩定，并且使用更少的資源以及更少的團隊。這個階段可能會有更長的時間跨度，比如2-5年。
重新構建一個系統是成功的標志，而不是失敗的標志。重構是由于業務發展的好，業務體量的增長對現有技術有了新的要求，而絕不是為了重構而重構。
今天就先講到這里。
如果看了這篇文章之后有所收獲，歡迎收藏轉發。
如果你有自己的見解，也歡迎在下方評論。
總之，你可以關注一下我，我會有許多干貨分享。
免責聲明：本站發布的內容（圖片、視頻和文字）以原創、轉載和分享為主，文章觀點不代表本網站立場，如果涉及侵權請聯系站長郵箱：is@yisu.com進行舉報，并提供相關證據，一經查實，將立刻刪除涉嫌侵權內容。
