使用Spring Cloud實戰微服務 微服務簡介 單體架構
缺點： 1.複雜性高
以一個百萬行級別的單體應用為例，整個專案包含的模組非常多，模組的邊界模糊，依賴關係不清晰，程式碼質量參差不齊，混亂的堆砌在一起……整個專案非常複雜。每次修改程式碼都心驚膽顫，甚至新增一個簡單的功能，或者修改一個BUG都會造成隱含的缺陷。
2.技術債務
隨著時間推移、需求變更和人員更迭，會逐漸形成應用程式的技術債務，並且越積越多。“不壞補修 (Not broken,don’t fix)”，這在軟體開發中非常常見，在單體應用中這種思想更甚。已使用的系統設計或程式碼難以修改，因為應用程式的其他模組可能會以意料之外的方式使用它。
3.部署頻率低
隨著程式碼的增多，構建和部署的時間也會增加。而在單體應用中，每次功能的變更或缺陷的修復都會導致我們需要重新部署整個應用。全量部署的方式耗時長、影響的範圍大、風險高，這使得單體應用專案上線部署的頻率較低。而部署的頻率低又導致兩次釋出之間會有大量的功能變更和缺陷修復，出錯概率較高。
4.擴充能力受限
單體應用只能作為一個整體進行擴充，無法結合業務模組的的特點進行伸縮。例如，應用中有的模組是計算密集型的，它需要強勁的CPU；有的模組則是IO密集型的，需要更大的記憶體。由於這些模組部署在一起，我們不得不在硬體的選擇上做出妥協。
5.阻礙技術建立
單體應用往往使用統一的技術平臺或方案解決所有問題，團隊的每個成員都必須使用相同的開發語言和框架，想要引入新的框架或技術平臺會非常困難。例如，一個使用Struts2構建的100萬行程式碼的單體應用，如果想要換用Spring MVC,切換成本無疑是非常高的。
架構的演進 單體架構
SOA（分散式，面向服務架構）
微服務
微服務架構 www.martinfowler.com/articles/mi… In short, the microservice architectural style is an approach to developing a single application as a suite of small services, each running in its own process and communicating with lightweight mechanisms, often an HTTP resource API. These services are built around business capabilities and independently deployable by fully automated deployment machinery. There is a bare minimum of centralized management of these services, which may be written in different programming languages and use different data storage technologies.
翻譯：簡而言之，微服務架構風格這種開發方法，是以開發一組小型服務的方式來開發一個獨立的應用系統的。其中每個小型服務都執行在自己的程式中，並經常採用HTTP資源API這樣輕量的機制來相互通訊。這些服務圍繞業務功能進行構建，並能通過全自動的部署機制來進行獨立部署。這些微服務可以使用不同的語言來編寫，並且可以使用不同的資料儲存技術。對這些微服務我們僅做最低限度的集中管理。
微服務特性： 1.每個微服務可獨立執行在自己的程式裡；
2.一系列獨立的微服務共同構建起整個系統；
3.每個服務為獨立的業務開發，一個微服務只關注某個特定的功能，例如訂單管理、使用者管理等；
4.微服務之間通過一些輕量級的通訊機制進行通訊，例如通過REST API進行呼叫；
5.可以使用不同的語言與資料儲存技術；
6.全自動的部署機制。
一個微服務只關注一個特定的業務功能，所以它的業務清晰、程式碼量較少。開發和維護單個微服務相對是比較簡單的。而整個應用是由若干個微服務構建而成的，所以整個應用也會維持在可控狀態。
2.單個微服務啟動較快
單個微服務程式碼量較少，所以啟動會比較快。
3.區域性修改容易部署
單體應用只要有修改，就得重新部署整個應用，微服務解決了這樣的問題。一般來說，對某個微服務進行修改，只需要重新部署這個服務即可。
4.技術棧不受限
在微服務中，我們可以結合專案業務及團隊的特點，合理的選擇技術棧。例如某些服務可以使用關係型資料庫MySQL;某些微服務有圖形計算計算的需求，我們可以使用Neo4J;甚至可以根據需求，部分微服務使用JAVA開發，部分微服務使用NodeJS進行開發。
5.按需伸縮
可以根據需求，實現細粒度的擴充。例如：系統中的某個微服務遇到了瓶頸，我們可以結合這個微服務的業務特點，增加記憶體、升級CPU或者是增加節點。
6.DevOps
微服務架構的挑戰： 1.運維要求較高
更多的服務意味著更多的運維投入。在單體架構中，只需要保證一個應用的正常執行；而在微服務中，需要保證幾十個甚至是幾百個服務的正常執行與協作，這個專案的運維帶來了很大的挑戰。
2.分散式固有的複雜性
使用微服務構建的是分散式系統。對於一個分散式系統，系統容錯、網路延遲、分散式事務等都給我們帶來了很大的挑戰
3.介面挑戰成本高
微服務之間通過介面進行通行。如果修改某一個微服務的API，可能所有使用了該介面的微服務都需要做調整。
4.重複勞動
很多服務可能都會使用到相同的功能，而這個功能並沒有達到分解為一個微服務的程度，這個時候，可能各個服務都會開發這一功能，從而導致程式碼重複。
微服務設計原則 單一職責
ref:en.wikipedia.org/wiki/SOLID_…
服務自治
每個微服務應該具備獨立的業務能力、依賴於執行環境
輕量級通訊
介面明確
每個服務的對外介面應該明確定義，並儘量保持不變。
微服務開發框架淺談 Spring Cloud：projects.spring.io/spring-clou…
Dubbo：dubbo.io
Dropwizard：www.dropwizard.io
Consl、etcd &etc.
Spring Cloud簡介 簡介 projects.spring.io/spring-clou…
快速構建分散式系統的工具集
版本 服務註冊與發現 建立呼叫關係的微服務
使用Eureka實現服務註冊與發現
Coding 客戶端負載均衡Ribbon
宣告式的Http Client Feign 如果構造的URL是： www.baidu.com/s?ie=utf-8&… 怎麼辦？
微服務容錯 雪崩效應
使用斷路器 試想一下，如果家庭裡沒有斷路器，電流過載了（例如功率過大、短路等），電路不斷開，電路就會升溫，甚至是燒斷電路、起火。有了斷路器之後，當電流過載時，會自動切斷電路（跳閘），從而保護了整條電路與家庭的安全。當電流過載的問題被解決後，只要將關閉斷路器，電路就又可以工作了。 同樣的道理，當依賴的服務有大量超時時，再讓新的請求去訪問已經沒有太大意義，只會無謂的消耗現有資源。譬如我們設定了超時時間為1秒，如果短時間內有大量的請求（譬如50個）在1秒內都得不到響應，就往往意味著異常。此時就沒有必要讓更多的請求去訪問這個依賴了，我們應該使用斷路器避免資源浪費。 斷路器可以實現快速失敗，如果它在一段時間內偵測到許多類似的錯誤（譬如超時），就會強迫其以後的多個呼叫快速失敗，不再請求所依賴的服務，從而防止應用程式不斷地嘗試執行可能會失敗的操作，這樣應用程式可以繼續執行而不用等待修正錯誤，或者浪費CPU時間去等待長時間的超時。斷路器也可以使應用程式能夠診斷錯誤是否已經修正，如果已經修正，應用程式會再次嘗試呼叫操作。 斷路器模式就像是那些容易導致錯誤的操作的一種代理。這種代理能夠記錄最近呼叫發生錯誤的次數，然後決定使用允許操作繼續，或者立即返回錯誤。 斷路器開關相互轉換的邏輯如下圖：
Zuul API Gateway github.com/netflix/zuu…
Coding 統一配置中心 配置的管理 /{application}/{profile}[/{label}] /{application}-{profile}.yml /{label}/{application}-{profile}.yml /{application}-{profile}.properties /{label}/{application}-{profile}.properties
配置的重新整理 /refresh /bus/refresh ===> amqp
最終架構
Spring Cloud特點 約定優於配置 開箱即用、快速啟動 適用於各種環境 PC Server 雲環境 容器(Docker) 輕量級的元件 服務發現 Euraka 元件的支援很豐富，功能很齊全 配置中心 註冊中心 智慧路由 選型中立 服務發現 Eureka Zookeeper Consul 需要的技術儲備 JAVA Scala/Groovy 構建工具 Maven Gradle(如何將Maven專案轉為Gradle專案?maven -gradle gradle init –type pom) Spring Boot 服務提供者與服務消費者 概念 服務提供者：服務的被呼叫方（即：為其他服務提供服務的服務）
服務呼叫者：服務的呼叫方（即：依賴其他服務的服務）
使用者–購票–>電影微服務—查詢使用者資訊–>使用者微服務
編寫一個服務提供者
服務發現
服務註冊 服務註冊很好理解，就是服務啟動時，將服務的網路地址註冊到服務登錄檔中；
健康檢查 服務發現元件會通過一些機制定時檢測已註冊的服務，如果發現某服務無法訪問了（可能是某幾個心跳週期後），就將該服務從服務登錄檔中移除。
服務發現的方式 客戶端發現 Eureka ZK 伺服器端發現 Consul+nginx 術語解釋 目前市面上的書籍，服務註冊、服務發現、註冊中心，在很多場景下，都可以理解為是服務發現元件。
微信掃碼領取java全套資料哦~
