andy-yu發表於 2018-08-26一旦您的應用程式成為了乙個龐大、複雜的單體，您的開發組織可能會陷入了乙個痛苦的境地，敏捷開發和交付的任何一次嘗試都將原地徘徊。乙個主要問題是應用程式實在非常複雜。對於任何乙個開發人員來說顯得過於龐大，這是可以理解的。最終，正確修復 bug 和實現新功能變得非常困難而耗時。此外， 這種趨勢就像是往下的螺旋。如果基本**都令人難以理解，那麼改變也不會變得正確，您最終得到的將是乙個巨大且不可思議的大泥球。
應用程式的規模也將減緩發展。應用程式越大，啟動時間越長。我調查過開發者們的單體應用的大小和效能，一些報告的啟動時間為 12 分鐘。我也聽說過應用程式啟動需要 40 分鐘以上的怪事。如果開發人員經常要重啟應用伺服器，那麼很大一部分時間都是在等待中度過，他們的生產力將受到限制。
另乙個大問題是，複雜的單體應用本身就是持續部署的障礙。如今， saas 應用發展到了可以每天多次將變更推送到生產環境中。這對於複雜的單體來說非常困難，因為您需要重新部署整個應用程式才能更新其中任何一部分。 聯想到我之前提到的漫長啟動時間，這也不會是什麼好事。此外，因變更所產生的影響通常不是很明確，您很可能需要做大量的手工測試。因此，持續部署是不可能做到的。
當不同模組存在資源需求衝突時，單體應用可能難以擴充套件。例如，乙個模組可能會執行 cpu 密集型影象處理邏輯，理想情況下是部署在 amazon ec2 compute optimized 例項中。另乙個模組可能是乙個記憶體資料庫，最適合部署到 ec2 memory-optimized 例項。然而， 由於這些模組被部署在一起，您必須在硬體選擇上做出妥協。
單體應用的另乙個問題是可靠性。因為所有模組都執行在同一程序中。任何模組的乙個 bug，比如記憶體洩漏，可能會拖垮整個程序。此外，由於應用程式的所有例項都是相同的，該錯誤將影響到整個應用的可用性。
最後但同樣重要，單體應用使得採用新框架和語言變得非常困難。例如，我們假設您有 200 萬行**使用了 xyz 框架編寫。如果使用較新的 abc 框架來重寫整個應用，這將非常昂貴（在時間和成本方面），即使框架非常好。因此，這對於採用新技術是乙個非常大的障礙。在專案開始時， 您無論選擇何種新技術都會感到困擾。
總結一下：您有乙個成功的關鍵業務應用程式，它已經發展成為乙個只有少數開發人員（如果有的話）能夠理解的巨大單體。它使用了過時、非生產性技術編寫，這使得招聘優秀開發人員變得非常困難。應用程式變得難以擴充套件，不可靠。因此敏捷開發和應用交付是不可能的。
微服務 微服務簡介
什麼是微服務 顧名思義，就是粒度較小的服務，不再侷限於系統與系統之間的藉口呼叫，也不侷限於某種具體的服務形式。系統中凡是可被復用的功能模組都可以被 服務化 轉變為 服務 這些服務可以對外暴露，也可能僅限於再系統內部使用。由於服務數量更多，粒度更小，因此管控難度會更大，對效能的要求也更高。微服務的好處...
微服務簡介
1.什麼是單體應用程式 單體應用程式就是所有的業務模組都是在乙個應用程式中，訪問乙個資料庫，我們平時一般使用的就是單體應用程式 2.什麼是微服務 微服務就是把單體應用程式中的各個業務模組分為各個服務系統，服務之間提供rest api 供外界訪問，每個服務對應各自的資料庫，手機端通過api gatew...
微服務簡介
單體架構是什麼 乙個歸檔包包含了應用所有功能的應用程式，我們通常稱之為單體應用。架構單體應用的架構風格，我們稱之為單體架構，這是一種比較傳統的架構風格。單體架構存在的缺點 複雜性逐漸變高 技術債務逐漸上公升 部署速度逐漸變慢 阻礙技術創新 無法按需伸縮 架構的演進 單體架構 soa微服務 什麼是微服...