微服務框架SpringBoot簡單驗證
首先摘錄部分IBM網站部分內容對框架做一個簡單說明
http://www.ibm.com/developerworks/cn/java/j-lo-spring-boot/
Spring 框架對於很多 Java 開發人員來說都不陌生。自從 2002 年發佈以來，Spring 框架已經成爲企業應用開發領域非常流行的基礎框架。有大量的企業應用基於 Spring 框架來開發。Spring 框架包含幾十個不同的子項目，涵蓋應用開發的不同方面。
如此多的子項目和組件，一方面方便了開發人員的使用，另外一個方面也帶來了使用方面的問題。每個子項目都有一定的學習曲線。開發人員需要了解這些子項目和組件的具體細節，才能知道如何把這些子項目整合起來形成一個完整的解決方案。在如何使用這些組件上，並沒有相關的最佳實踐提供指導。
對於新接觸 Spring 框架的開發人員來說，並不知道如何更好的使用這些組件。Spring 框架的另外一個常見問題是要快速創建一個可以運行的應用比較麻煩。Spring Boot 是 Spring 框架的一個新的子項目，用於創建 Spring 4.0 項目。它的開發始於 2013 年。2014 年 4 月發佈 1.0.0 版本。它可以自動配置 Spring 的各種組件，並不依賴代碼生成和 XML 配置文件。Spring Boot 也提供了對於常見場景的推薦組件配置。Spring Boot 可以大大提升使用 Spring 框架時的開發效率。本文將對 Spring Boot 進行詳細的介紹。
SpringBoot框架簡介
從 Spring Boot 項目名稱中的 Boot 可以看出來，Spring Boot 的作用在於創建和啓動新的基於 Spring 框架的項目。它的目的是幫助開發人員很容易的創建出獨立運行和產品級別的基於 Spring 框架的應用。Spring Boot 會選擇最適合的 Spring 子項目和第三方開源庫進行整合。大部分 Spring Boot 應用只需要非常少的配置就可以快速運行起來。
Spring Boot 包含的特性
- 創建可以獨立運行的 Spring 應用。
- 直接嵌入Tomcat 或 Jetty 服務器，不需要部署 WAR 文件。
- 支持一鍵啓動，不需要預先部署應用服務器或Web容器，本身可以內嵌。
- 提供推薦的基礎 POM 文件來簡化 Apache Maven 配置。
- 儘可能的根據項目依賴來自動配置 Spring 框架。
- 提供可以直接在生產環境中使用的功能，如性能指標、應用信息和應用健康檢查。
- 沒有代碼生成，也沒有 XML 配置文件。
- 可靈活的通過註解的方式將內部的API接口發佈爲http rest接口服務
而我們看到一個框架要選擇做爲微服務模塊開發用，其必須要具備的幾個特點
1)足夠輕：其中包括了編碼，配置，部署，乃至後期的運維監控都足夠輕量和獨立。
2)接口開放容易：內部API方法應該能夠很容易開放爲Rest風格的API接口
從這兩點來看Spring Boot完全滿足，而且支持的很好，雖然Spring Boot缺少微服務網關的諸多能力（註冊，安全，監控，日誌審計，路由，流控）等，但是該框架仍然是一個微服務架構開發的可選入門框架。
通過 Spring Boot，創建新的 Spring 應用變得非常容易，而且創建出的 Spring 應用符合通用的最佳實踐。只需要簡單的幾個步驟就可以創建出一個 Web 應用。下面在本機參考網上一篇文章進行簡單驗證
http://blog.csdn.net/lxhjh/article/details/51711148
整個驗證過程相當簡單，注意按文章要求建立好目錄結構，同時手工新建三個文件放到指定目錄，上述blog文章有詳細描述，如下：
pom.xml
Application.java
Example.java
在通過Eclipse環境（實現已經安裝了Maven插件）通過Import方式導入Maven項目。在導入的時候，由於需要遠程下載Maven需要等待一段時間。下載完成後即可以進行編譯和運行。
在select Java Aplication中選擇“Application -com.example.myFirstProject”
運行起來後，打開瀏覽器輸入打開瀏覽器，輸入http://localhost:8080
可看到輸出結果 helloworld 對應代碼文件 home 方法
輸入http://localhost:8080/hello/SpringBoot
可看到 hello SpringBoot輸出，對應代碼文件 index方法
可以看到整個過程相當簡單，編碼和配置，包括後續的部署啓動都相當簡單和容易。我們沒有寫任何服務接口和發佈的代碼，而只是在Java方法上增加了註解，即可以將內部的方法很容易的發佈爲一個Http Rest服務，這就是SpringBoot框架很大的一個優勢了。
任何開發的事情變簡單了，就會導致服務發佈的隨意性和濫用，導致後續Rest接口暴增而無法管理，這也是在使用這些微服務框架時候必須要考慮的事情。簡單來說就是不能因爲使用了簡單易用的微服務框架而忽略了SOA治理的重要性。
另外一個SpringBoot的在線課程可參考：http://www.roncoo.com/article/detail/124661
微服務框架-基礎框架
上面一篇文章對SpringBoot框架做了一下簡單驗證，在文中也寫到SpringBoot重點還是在單個微服務模塊的開發，已經對於微服務接口開放的便捷性上，而對於微服務基礎架構和管控治理層面沒有太多支持。
那什麼叫微服務基礎框架？
對於微服務基礎框架可以看作是微服務治理架構的核心內容，包括了對微服務模塊的全生命週期管理能力，這個能力包括了微服務網關APP，DevOps，Docker和雲集成，安全，負載均衡，服務註冊和發現等諸多能力。微服務基礎框架確實不是簡單的微服務網關，而是對整個微服務基礎環境的支撐和管控。
對於微服務基礎框架，建議參考InfoQ的一篇文章如下：
http://www.infoq.com/cn/articles/basis-frameworkto-implement-micro-service/
對於這篇文章的一些重點做如下一些說明：
1. 服務註冊和發現
第一種方案爲集中式LB方案，對剛開始實施微服務架構時候仍然建議採用該方案，特別是有負載均衡硬件設備如F5，Array等，在加上硬件本身的HA，不會在LB上出現任何性能問題和可靠性問題。
對於第二種進程內LB方案是趨勢，當前微服務框架的主流方案，Netflix和Dubbo等均採用該方案，那這種時候服務註冊庫相當存粹，只是實時準確提供可用服務註冊列表和地址信息即可，但是這種方案我們可看到一般不會對調用的日誌流進行審計和跟蹤。
第三種方案實際上是一種折中的方案，即在每個微服務節點都需要部署相對比較重的獨立進程外LB模塊，這種方案最大的問題仍然是在於整體基礎架構體系偏重同時後續維護工作量大。
2. 服務前端路由-微服務網關
此處核心能力即使微服務網關，不僅僅是實現服務代理和前端路由，還需要實現安全，限流，監控等擴展能力。可以看到對整個微服務環境的治理管控，微服務網關會起到重要作用，具體摘錄原文描述如下：
- 服務反向路由，網關要負責將外部請求反向路由到內部具體的微服務，這樣雖然企業內部是複雜的分佈式微服務結構，但是外部s系統從網關上看到的就像是一個統一的完整服務，網關屏蔽了後臺服務的複雜性，同時也屏蔽了後臺服務的升級和變化。
- 安全認證和防爬蟲，所有外部請求必須經過網關，網關可以集中對訪問進行安全控制，比如用戶認證和授權，同時還可以分析訪問模式實現防爬蟲功能，網關是連接企業內外系統的安全之門。
- 限流和容錯，在流量高峯期，網關可以限制流量，保護後臺系統不被大流量沖垮，在內部系統出現故障時，網關可以集中做容錯，保持外部良好的用戶體驗。
- 監控，網關可以集中監控訪問量，調用延遲，錯誤計數和訪問模式，爲後端的性能優化或者擴容提供數據支持。日誌，網關可以收集所有的訪問日誌，進入後臺系統做進一步分析。
- 其它能力：實現線上引流，線上壓測，線上調試(Surgical debugging)，金絲雀測試(Canary Testing)，數據中心雙活(Active-Active HA)等高級功能。
要注意到在微服務架構裏面的集羣和負載功能其實有兩層，第一層是在微服務網關上面的分佈式集羣部署，可以減輕單個API GateWay節點的併發訪問壓力；另外一個是在微服務模塊上層的負載均衡部署，重點是實現在同一個微服務模塊集羣部署後能夠進行負載均衡。
在講第一點服務註冊和發現的時候可以看到，對於LB是可以下沉到服務消費端的，那麼在LB下移後對於微服務網關層的能力是否也可以完全下沉到微服務模塊節點（不管是進程內部署還是進程外部署），以實現完全意義上的去中心化分佈式架構？
我在下面這篇文章曾經談到過去中心化的微服務網關構建思路，可以參考：
http://blog.sina.com.cn/s/blog_493a84550102wcmw.html
3. 服務容錯
該部分主要還是講服務的限流和流量控制機制，而對於熔斷只是在發現問題和異常後所採用的操作。對於服務容錯功能本身功能的重要性就在於，在複雜的微服務架構環境下，服務關聯和依賴相當多，當發生大量的服務異常調用的時候，極其容易引起雪崩效應，導致整個微服務環境完全崩潰。
對於服務的容錯，在考慮限流機制前，還可以考慮對服務進行分域，將不同域的服務單獨部署到不同的JVM容器中，這樣至少可以保證在A域的JVM完全崩潰的時候，不會影響到B，C等其它服務部署域。這個有點類似文章最佳實踐談到的艙壁隔離模式(Bulkhead Isolation Pattern)。
要實現服務的容錯管理i，首先要有實時的採集和統計服務運行數據，包括服務運行時間，次數等，這些是服務容錯，限流或容錯策略計算的基礎。
對於服務容錯需要分幾個層面來談：
首先來說是服務限流，即當出現超出預設的大併發服務調用的時候，直接在網關處控制服務的流入速度，即讓消費方調用在外面等待和排隊，然後慢慢的放進來，當然如果調用再大則會引起服務調用超時。注意這是服務消費方調用超時，而不是原始服務提供方，這種超時網關是不清楚的。
其次即開始不限流，服務全部放進來，但是服務提供方可能處理不過來大併發，這種情況下會出現服務超時調用，服務響應時間超過預設值，那麼在這種情況下就啓動服務限流，控制流入速度。注意在服務限流後可能仍然無法解決服務超時或響應慢的問題。那麼這個時候就必須進行服務熔斷處理，即禁止對該服務所有訪問。對於文中也談到了熔斷的彈性恢復機制，這也是一個相當關鍵的內容。
對於服務流量控制本身也有多個層級，可以針對所有服務，一個域的所有服務，單個服務都可以。即對服務調用總量或單個服務併發量都能夠進行靈活的限流規則定義，以確保整個微服務架構基礎環境的穩定性。
Netflix將上述容錯模式和最佳實踐集成到一個稱爲Hystrix的開源組件中，凡是需要容錯的依賴點(服務，緩存，數據庫訪問等)，開發人員只需要將調用封裝在Hystrix Command裏頭，則相關調用就自動置於Hystrix的彈性容錯保護之下。Hystrix組件已經在Netflix經過多年運維驗證，是Netflix微服務平臺穩定性和彈性的基石，正逐漸被社區接受爲標準容錯組件。
4.Netflix的微服務框架
在原來談SOA和ESB的時候，我們一般會談兩個內容，即ESB服務總線和基於ESB總線的SOA管控和治理平臺。而對應到微服務框架也一樣的道理：
其一是：微服務網關(服務註冊發現，代理路由，安全，限流，日誌，監控）
其二是：基於微服務網關的完整微服務框架（客戶端和服務端集成，DevOps，雲集成）
注意在這裏我還是將服務註冊發現，日誌等能力統一劃歸到一個完整的微服務網關應該具備的能力，雖然在實現中可能會分爲多個子系統或組件，但是本身是屬於GateWay應該具備的能力。
Netflix是一家成功實踐微服務架構的互聯網公司，幾年前，Netflix就把它的幾乎整個微服務框架棧開源貢獻給了社區，這些框架和組件包括：
- Eureka: 服務註冊發現框架
- Zuul: 服務網關
- Karyon: 服務端框架
- Ribbon: 客戶端框架
- Hystrix: 服務容錯組件
- Archaius: 服務配置組件
- Servo: Metrics組件
- Blitz4j: 日誌組件
下圖Fig 11展示了基於這些組件構建的一個微服務框架體系，來自recipes-rss。
Netflix的開源框架組件已經在Netflix的大規模分佈式微服務環境中經過多年的生產實戰驗證，正逐步被社區接受爲構造微服務框架的標準組件。Pivotal去年推出的Spring Cloud開源產品，主要是基於對Netflix開源組件的進一步封裝，方便Spring開發人員構建微服務基礎框架。
對於一些打算構建微服務框架體系的公司來說，充分利用或參考借鑑Netflix的開源微服務組件(或Spring Cloud)，在此基礎上進行必要的企業定製，無疑是通向微服務架構的捷徑。
另外推薦下作者的另外一篇文章：每個架構師都應該瞭解下康威定律
http://www.infoq.com/cn/articles/every-architect-should-study-conway-law
前面一篇文章談到微服務基礎框架，而Netflix的多個開源組件一起正好可以提供完整的分佈式微服務基礎架構環境，而對於Spring Cloud正是對Netflix的多個開源組件進一步的封裝而成，同時又實現了和雲端平臺，和Spring Boot開發框架很好的集成。
Spring Cloud是一個相對比較新的微服務框架，今年(2016)才推出1.0的release版本. 雖然Spring Cloud時間最短, 但是相比Dubbo等RPC框架, Spring Cloud提供的全套的分佈式系統解決方案。
Spring Cloud 爲開發者提供了在分佈式系統（配置管理，服務發現，熔斷，路由，微代理，控制總線，一次性token，全居瑣，leader選舉，分佈式session，集羣狀態）中快速構建的工具，使用SpringCloud的開發者可以快速的啓動服務或構建應用、同時能夠快速和雲平臺資源進行對接。
我們先簡單闡述下Spring Cloud中文社區對四個基礎關鍵組件的描述：
社區地址：http://springcloud.cn/
Spring Cloud Config配置中心
Spring Cloud Config就是我們通常意義上的配置中心。Spring Cloud Config-把應用原本放在本地文件的配置抽取出來放在中心服務器，本質是配置信息從本地遷移到雲端。從而能夠提供更好的管理、發佈能力。
Spring Cloud Config分服務端和客戶端，服務端負責將git（svn）中存儲的配置文件發佈成REST接口，客戶端可以從服務端REST接口獲取配置。但客戶端並不能主動感知到配置的變化，從而主動去獲取新的配置，這需要每個客戶端通過POST方法觸發各自的/refresh。
Spring Cloud Netflix 服務發現
Spring Cloud Eureka提供在分佈式環境下的服務發現，服務註冊的功能。
Spring Cloud Netflix，該項目是Spring Cloud的子項目之一，主要內容是對Netflix公司一系列開源產品的包裝，它爲Spring Boot應用提供了自配置的Netflix OSS整合。
通過一些簡單的註解，開發者就可以快速的在應用中配置一下常用模塊並構建龐大的分佈式系統。它主要提供的模塊包括：服務發現（Eureka），斷路器（Hystrix），智能路由（Zuul），客戶端負載均衡（Ribbon）等。
Spring cloud Hystrix 熔斷器
斷路器(Cricuit Breaker)是一種能夠在遠程服務不可用時自動熔斷(打開開關)，並在遠程服務恢復時自動恢復(閉合開關)的設施。
斷路器(Cricuit Breaker)是一種能夠在遠程服務不可用時自動熔斷(打開開關)，並在遠程服務恢復時自動恢復(閉合開關)的設施，Spring Cloud通過Netflix的Hystrix組件提供斷路器、資源隔離與自我修復功能。
Spring Cloud Zuul 服務網關
Spring Cloud Eureka提供在分佈式環境下的服務發現，服務註冊的功能。
Spring Cloud Netflix，該項目是Spring Cloud的子項目之一，主要內容是對Netflix公司一系列開源產品的包裝，它爲Spring Boot應用提供了自配置的Netflix OSS整合。通過一些簡單的註解，開發者就可以快速的在應用中配置一下常用模塊並構建龐大的分佈式系統。它主要提供的模塊包括：服務發現（Eureka），斷路器（Hystrix），智能路有（Zuul），客戶端負載均衡（Ribbon）等。
當然Spring Cloud還有額外擴展的其它很多組件，包括了服務鏈路監控和跟蹤（很關鍵的一個功能），消息總線，數據流處理，批量任務處理等。而對於整個Spring Cloud微服務框架簡單來說，即是：
你只要劃分到你的微服務組件和模塊，並定義好需要暴露的API接口，那麼剩下的整個開發和傳統方式沒有太大的區別，你開發完成的組件集成起來就是一個分佈式可擴展的微服務環境。裏面設計到的接口發佈，服務註冊，服務調用和路由，服務監控，健康檢測和流控等都會由微服務框架來幫你完成。
正是有了成熟的微服務框架，我們才更應該將微服務架構設計重心從技術底層轉移到組件劃分和接口設計上。
SpringCloud和Dubbo的區別問題
對於兩者的區別在如下文章有詳細描述可以參考：
http://blog.didispace.com/microservice-framework/
可以看到SpringCLoud能夠提供的基礎能力要多於Dubbo，Dubbo可以看作是SpringCLoud簡單實現。
Dubbo是RPC服務治理框架，和Spring Cloud一樣具備服務註冊、發現、路由、負載均衡等能力。但是沒有配置中心，完整的好用全鏈路監控，需要採用開源的解決方案定製或者自研。Spring cloud的配置中心，全鏈路監控等組件。從目前來看，Spring Cloud國內中小型企業用的比較多，大型企業可能需要對其需要的組件進行定製化處理。
但是也需要看到Spring Cloud基於註解的服務發現，服務治理等功能具有代碼侵入性，dubbo沒有代碼侵入性，業務開發人員不需要通過註解的方式去關注框架級別的處理。從中間件或者做基礎架構的角度來看，其實服務治理等功能對普通的業務程序員應該是透明的，業務程序員不需要關注服務治理框架的使用，專注於業務代碼即可。
基於SpringCLoud微服務框架的實踐
對於基於SpringCLoud框架的具體實踐，建議參考翟永超博客的系列文章，具體如下：
- 服務註冊和發現：http://blog.didispace.com/springcloud1/
- 服務消費：http://blog.didispace.com/springcloud2/
- 服務熔斷機制：http://blog.didispace.com/springcloud3/
- 服務配置中心：http://blog.didispace.com/springcloud4/
- 服務網關：http://blog.didispace.com/springcloud5/
- 高可用服務註冊中心：http://blog.didispace.com/springcloud6/
- 消息總線：http://blog.didispace.com/springcloud7/
服務註冊和發現
注意這裏仍然使用的是SpringBoot框架，並和SpringBoot框架進行了集成，在pom.xml配置文件中增加了對SpringCLoud相關包和組件的依賴。在原有的接口API定義的基礎上，我們增加@EnableDiscoveryClient註解後，即可以讓服務註冊中心很輕鬆的發現服務提供方以及提供的服務。
服務消費
方式1 - Ribbon是一個基於HTTP和TCP客戶端的負載均衡器。Ribbon可以在通過客戶端中配置的ribbonServerList服務端列表去輪詢訪問以達到均衡負載的作用。當Ribbon與Eureka聯合使用時，ribbonServerList會被DiscoveryEnabledNIWSServerList重寫，擴展成從Eureka註冊中心中獲取服務端列表。
方式2 - Feign是一個聲明式的Web Service客戶端，它使得編寫Web Serivce客戶端變得更加簡單。我們只需要使用Feign來創建一個接口並用註解來配置它既可完成。它具備可插拔的註解支持，包括Feign註解和JAX-RS註解。Feign也支持可插拔的編碼器和解碼器。Spring Cloud爲Feign增加了對Spring MVC註解的支持，還整合了Ribbon和Eureka來提供均衡負載的HTTP客戶端實現。
斷路器
首先在pom.xml文件中增加引入對hystrix依賴，同時在消費端Application主類上增加@EnableCircuitBreaker註解開啓斷路器功能。注意原有的服務消費方式也涉及到修改，增加了服務Callback的回調函數。
服務網關
服務網關是微服務架構中一個不可或缺的部分。通過服務網關統一向外系統提供REST API的過程中，除了具備服務路由、均衡負載功能之外，它還具備了權限控制等功能。Spring Cloud Netflix中的Zuul就擔任了這樣的一個角色，爲微服務架構提供了前門保護的作用，同時將權限控制這些較重的非業務邏輯內容遷移到服務路由層面，使得服務集羣主體能夠具備更高的可複用性和可測試性。