微服務分佈式架構基礎與實戰：基於Spring Boot + Spring Cloud

分佈式可以理解爲人體器官，人體可看成分佈式系統，大腦是註冊中心的集羣，四肢與器官是提供服務的微服務，前進的距離是微服務運行之後的返回值，消耗的體力是微服務中處理的邏輯，影響的記憶是某些微服務對數據庫的增刪改查。

工作需要，閱讀加上實踐，獲益良多

我收穫了分佈式架構的優與劣以及它的發展過程。 1.之所以使用分佈式系統，主要有兩方面原因，一是增大系統容量，二是加強系統可用 。 2.一方面，由於單個機器的性能無法滿足越來越大的任務量 ，應對大規模應用場景需要多臺機器 ，所以需要 垂直或拆分業務系統，使其變成一個分佈式架構 。 3.另一方面，當業務越來越關鍵時架構中不能夠存在單點故障 是一個系統因爲一臺機器的問題導致整體的不可用 所以需要分佈式架構 榮譽系統，消除單點故障，提高整個系統架構的可用性 。 3.除此之外，分佈式系統還有模塊重用度高 、開發和發佈速度快、擴展性更高，團隊協作流程 更完善等優勢。 4.然而，所有的技術方案都是有得有失，分佈式系統在解決上述問題的同時 也在系統設計，管理和運維等方面帶來了很多問題 。爲了解決這些問題以及衍生出來的子問題 就出現了 很多架構方式和 技術方法。 5.分佈式系統的發展，從上世紀的模塊化編程、面向世界設計、基於接口或構架設計自然演化出來了基於服務的架構基於服務的架構——SOA。 6.最開始的SOA架構與單體架構差別不大 服務和服務之間是高度耦合的。後來開始使用一個標準協議或中間件來聯動其他關聯的服務 。再後來出現了微服務架構 ，每個微服務都能獨立完成運行，單體的數據庫被微服務這樣的架構分散在不同的服務中 。 7.微服務在集成，測試，運維和，服務管理等方面比較麻煩 需要Paas層的支持 。

還好。起碼一個人寫的，前後風格統一。

讀者作爲Java開發人員。粗略學習了一個月，感覺收貨頗豐。一下是個人對於微服務的見解：傳統的基於單塊架構，對應傳統的基於瀑布模型的傳統軟件開發，已不能適應互聯網時代軟件開發的要求。互聯網應用的特點是，儘快發佈簡陋的版本，再根據外部反饋小規模快速迭代，擁抱變化。這就要求傳統的軟件工程要相應去哥新，以滿足新要求。對於互聯網公司的程序員/技術管理者/產品經理，一定要明白上面的道理，所謂的快速迭代絕對不只是版本發佈週期變快了，而是整個一套方法論和工程實踐都要調整。比如一週一個迭代版本，一週時間按傳統模式你需求文檔還沒有敲定呢，人家就要求新版本上線，程序員如何寫代碼，測試人員如何測試都要調整。如何調整，答案就是xxx。微服務架構，即儘量將無相關的業務分離成獨立的服務，通過RESTful互相間通信。讀者總結了微服務出現的背景： 1 互聯網軟件兩點特點：快速變化和用戶量大； 2 敏捷方法深入人心，小步快步，快速迭代； 微服務的優勢： 1 單個服務開發快速； 2 服務之間業務解耦； 3 總體架構可演進； 微服務的不足： 1 分佈式系統增加了總體系統的複雜性； 2 性能開銷變大； 3 運維複雜度高，測試、集成、發佈、監控； 微服務架構配套的DEVOPS開發運維模式 DEVOPS的核心就是，團隊垂直整合，內部充分信任，緊密溝通，可運行的產品大於文檔！DEVOPS工具集包括：Docker輕量級虛擬化、代碼靜態檢查工具、持續集成和持續發佈工具、日誌聚合工具、監控與告警機制、以及自動化測試。消息隊列是異常編程模式的一項重要技術！是遠程異步調用的基礎。在大型分佈式尤其是多層級分佈系統中，同步調用的時延將變得不可接受！REST：資源 表述 狀態轉移 統一接口，其中統一接口有4中操作方式。 GET，獲取資源；　OST，新建資源；　UT，更新資源；DELETE，銷燬資源。 使用微服務架構改造已有項目是一項複雜棘手的工作。一般建議優先採用逐步迭代切換的模式，一步一步替換直至最後全部變爲新的。總的來書，這本書的內容是值得去研究的。

以前沒有過分佈式經驗，不過尼瑪的成都面試全都要問分佈式，於是找了點分佈式的資料和書來看，說實話分佈式確實挺難的，一開始看文檔亂七八糟的資料網上太多了，也很雜，不過這本書由淺到深的講了分佈式架構，對很多東西進行了總結歸納，很合適剛入門和基礎稍微差一些的人閱讀，不用浪費時間去網上一堆東西里面去篩選適合自己的

編寫的形勢比較新穎，易於理解，也不會像一般的書那樣看久了就會覺得鼓譟，沒興趣了，書的內容不錯，講解的淺顯易懂，這是我最新好的一本書了