每天分享一個Java知識點，碼字不易，喜歡的可以關注一波，共同學習。20191205
軟件開發的歷史上充斥著大量開發項目的故事，這些項目是在投入了數百萬美元和數十萬軟件開發人員的時間後進行的。
這些龐大的項目往往遵循著大型傳統的瀑布開發方法，堅持在項目開始時定義所有應用程序的需求和設計。太多的重點放在了讓所有規格的軟件“正確”的，沒有什麼餘地來滿足新的業務需求，或重構和學習在發展的初期階段犯過的錯誤。
然而，實際情況是軟件開發不是定義和執行的線性過程，但這是一個漸進的過程，在開發團隊真正瞭解手頭的問題之前，需要經過幾次反覆的交流、學習和交付給客戶。
結合使用傳統瀑布方法的挑戰是很多次在這些項目中交付的軟件產品的粒度是：
1. 緊耦合：這大大增加了即使應用程序組鍵進行小的更改也可能破壞應用程序的其他部分並引入新bug的機會；
2. 洩漏：大多數大型軟件應用程序管理不同類型的數據。例如，客戶關係管理（CRM）應用程序可以管理客戶、銷售和產品信息。在傳統模型中，這些數據保存在一個數據模型中，並且存儲在同一個數據存儲中。儘管數據之間有明顯的界限，但通常來自一個域的團隊很容易直接訪問屬於另一個團隊的數據。
這種易於訪問的數據創建了隱藏的依賴關係，並允許一個組件的內部數據結構的實現細節洩漏到整個應用程序中。即使對單個數據庫表進行小的更改也可能需要在整個應用程序中有大量代碼更改和迴歸測試。
3. 單體/龐大：因為一個傳統的應用程序的大多數應用程序組件存在於一個單一的代碼庫，在多個團隊之間共享，任何時間更改代碼，整個程序必須重新編譯，通過整個測試周期重新運行，病蟲部署，即使是對應用程序代碼庫的小改動，不管是新的客戶需求還是bug修復，都會變得昂貴和耗時，而且大的更改幾乎是不可能及時完成的。
一個微服務架構採用了不同的方法來提供的功能。具體來說，微服務架構有以下特性：
1. 有限的：微服務職責單一、範圍有限。微服務擁抱Unix哲學：一個應用只不過是一個服務集合，每個服務做一件事，並且把一件事做的很好；
2. 松耦合：一個微服務應用就是一個小服務的集合，僅僅通過使用非專有的調用協議（例如，Http和Rest），不執行特定的接口相互作用。只要服務不改變接口，微服務的擁有者有比在傳統的應用架構更多的自由來對服務進行修改；
3. 分離的：微服務完全擁有自己的數據結構和數據來源。由微服務數據只能通過服務修改。對數據庫的訪問控制使微服務的數據被鎖定，僅允許這個服務訪問它；
4. 獨立的：在微服務應用程序中的每個微服務，可以獨立於應用程序中其他服務被編譯和部署。這意味著與更為相互 依賴的整體應用程序相比，更改可以更容易地隔離和測試。
為什麼這些微服務架構屬性對基於雲計算的開發是重要的？基於雲的應用程序一般有以下幾個特點：
1. 龐大多樣的用戶群：不同的客戶需要不同的特性，並且在開始使用這些特性之前，他們不需要等待長的應用程序發佈週期。微服務允許功能很快交付，因為每個服務是小範圍的，通過定義明確的接口訪問；
2. 極高的正常運行時間要求：因為微服務的分散性，微服務應用可以更容易地隔離應用程序地特定部分地故障和問題，而不必刪除整個應用程序。這降低了整體應用地停機時間，使他們提升了抵禦故障地能力；
3. 不均勻地大量需求：隨著時間地推移出現，在四面都是牆的企業數據中心部署的傳統應用程序通常具有一致的使用模式。這使得這些類型的應用程序的容量規劃變得簡單。但在一個基於雲的應用程序，在Twitter的一個簡單鳴叫或者是在Slashdot上張貼消息，都可以從最高限度驅動雲應用需求。
想獲取完整面試題及答案的同學請點贊、關注並轉發。私信樓主：“Java面試題”獲取完整資料，更有超全spring、jvm、linux、docker等電子書相送。更有整理的200多頁的面試重點知識點，非常全面，需要的私信。
本文引自《Spring微服務實戰（2016中文版）》
閱讀更多 你一生的故事2333 的文章
