基於Spring Boot和Spring Cloud實現微服務架構學習--轉

時間 2019-11-08

標籤基於 spring boot cloud 實現微服架構學習欄目 Spring 简体版

原文原文鏈接

原文地址：http://blog.csdn.net/enweitech/article/details/52582918html

看了幾周spring相關框架的書籍和官方demo，是時候開始總結下這中間的學習感悟。java

首先，最想說的是，當你要學習一套最新的技術時，官網的英文文檔是學習的最佳渠道。由於網上流傳的多數資料是官網翻譯而來，不少描述的重點也都偏向於做者自身碰到的問題，這樣就很容易讓你理解和操做出現誤差，最開始我就進入了這樣誤區。官網的技術導讀真的描述的很詳細，雖然對於咱們看英文很費勁，但若是英文不是不好，請選擇沉下心去讀，你必定能收穫好多。個人學習是先從Spring boot開始的，而後接觸到微服務架構，固然，這一切最大的啓迪仍是感謝個人一個老師，是他給我指明瞭新的道路，讓我眼前一亮，再次感謝。node

Spring 頂級框架

談及微服務，做爲當前主流的企業框架Spring，它提供了一整套相關的頂級項目，能讓開發者快速的上手實現本身的應用，今天就介紹下Spring旗下各個頂級項目：mysql

Spring IO platform:用於系統部署，是可集成的，構建現代化應用的版本平臺，具體來講當你使用maven dependency引入spring jar包時它就在工做了。android

Spring Boot:旨在簡化建立產品級的 Spring 應用和服務，簡化了配置文件，使用嵌入式web服務器，含有諸多開箱即用微服務功能，能夠和spring cloud聯合部署。nginx

Spring Framework:即一般所說的spring 框架，是一個開源的Java/Java EE全功能棧應用程序框架，其它spring項目如spring boot也依賴於此框架。git

Spring Cloud：微服務工具包，爲開發者提供了在分佈式系統的配置管理、服務發現、斷路器、智能路由、微代理、控制總線等開發工具包。github

Spring XD：是一種運行時環境（服務器軟件，非開發框架），組合spring技術，如spring batch、spring boot、spring data，採集大數據並處理。web

Spring Data：是一個數據訪問及操做的工具包，封裝了不少種數據及數據庫的訪問相關技術，包括：jdbc、Redis、MongoDB、Neo4j等。redis

Spring Batch：批處理框架，或說是批量任務執行管理器，功能包括任務調度、日誌記錄/跟蹤等。

Spring Security：是一個可以爲基於Spring的企業應用系統提供聲明式的安全訪問控制解決方案的安全框架。

Spring Integration：面向企業應用集成（EAI/ESB）的編程框架，支持的通訊方式包括HTTP、FTP、TCP/UDP、JMS、RabbitMQ、Email等。

Spring Social：一組工具包，一組鏈接社交服務API，如Twitter、Facebook、LinkedIn、GitHub等，有幾十個。

Spring AMQP：消息隊列操做的工具包，主要是封裝了RabbitMQ的操做。

Spring HATEOAS：是一個用於支持實現超文本驅動的 REST Web 服務的開發庫。

Spring Mobile：是Spring MVC的擴展，用來簡化手機上的Web應用開發。

Spring for Android：是Spring框架的一個擴展，其主要目的在意簡化Android本地應用的開發，提供RestTemplate來訪問Rest服務。

Spring Web Flow：目標是成爲管理Web應用頁面流程的最佳方案，將頁面跳轉流程單獨管理，並可配置。

Spring LDAP：是一個用於操做LDAP的Java工具包，基於Spring的JdbcTemplate模式，簡化LDAP訪問。

Spring Session：session管理的開發工具包，讓你能夠把session保存到redis等，進行集羣化session管理。

Spring Web Services：是基於Spring的Web服務框架，提供SOAP服務開發，容許經過多種方式建立Web服務。

Spring Shell：提供交互式的Shell可以讓你使用簡單的基於Spring的編程模型來開發命令，好比Spring Roo命令。

Spring Roo：是一種Spring開發的輔助工具，使用命令行操做來生成自動化項目，操做很是相似於Rails。

Spring Scala：爲Scala語言編程提供的spring框架的封裝（新的編程語言，Java平臺的Scala於2003年末/2004年初發布）。

Spring BlazeDS Integration：一個開發RIA工具包，能夠集成Adobe Flex、BlazeDS、Spring以及Java技術建立RIA。

Spring Loaded：用於實現java程序和web應用的熱部署的開源工具。

Spring REST Shell：能夠調用Rest服務的命令行工具，敲命令行操做Rest服務。

Spring cloud子項目

目前來講spring主要集中於spring boot（用於開發微服務）和spring cloud相關框架的開發，咱們從幾張圖着手理解，而後再具體介紹：

spring cloud子項目包括：

Spring Cloud Config：配置管理開發工具包，可讓你把配置放到遠程服務器，目前支持本地存儲、Git以及Subversion。

Spring Cloud Bus：事件、消息總線，用於在集羣（例如，配置變化事件）中傳播狀態變化，可與Spring Cloud Config聯合實現熱部署。

Spring Cloud Netflix：針對多種Netflix組件提供的開發工具包，其中包括Eureka、Hystrix、Zuul、Archaius等。

Netflix Eureka：雲端負載均衡，一個基於 REST 的服務，用於定位服務，以實現雲端的負載均衡和中間層服務器的故障轉移。

Netflix Hystrix：容錯管理工具，旨在經過控制服務和第三方庫的節點,從而對延遲和故障提供更強大的容錯能力。

Netflix Zuul：邊緣服務工具，是提供動態路由，監控，彈性，安全等的邊緣服務。

Netflix Archaius：配置管理API，包含一系列配置管理API，提供動態類型化屬性、線程安全配置操做、輪詢框架、回調機制等功能。

Spring Cloud for Cloud Foundry：經過Oauth2協議綁定服務到CloudFoundry，CloudFoundry是VMware推出的開源PaaS雲平臺。

Spring Cloud Sleuth：日誌收集工具包，封裝了Dapper,Zipkin和HTrace操做。

Spring Cloud Data Flow：大數據操做工具，經過命令行方式操做數據流。

Spring Cloud Security：安全工具包，爲你的應用程序添加安全控制，主要是指OAuth2。

Spring Cloud Consul：封裝了Consul操做，consul是一個服務發現與配置工具，與Docker容器能夠無縫集成。

Spring Cloud Zookeeper：操做Zookeeper的工具包，用於使用zookeeper方式的服務註冊和發現。

Spring Cloud Stream：數據流操做開發包，封裝了與Redis,Rabbit、Kafka等發送接收消息。

Spring Cloud CLI：基於 Spring Boot CLI，可讓你以命令行方式快速創建雲組件。

【參考詳解】爲何選擇Spring Boot做爲微服務的入門級微框架-CSDN.NET http://www.csdn.Net/article/a/2016-05-12/15838098

WHAT - 什麼是微服務

微服務簡介

此次參加JavaOne2015最大的困難就是聽Microservice相關的session，不管內容多麼水，只要題目帶microservice，一定報不上名，可見Microservice有多火。最喜歡其中一頁。關於這個典故，能夠參考this，此圖適用於一切高大上的名字——技術有SOA，Agile，CLOUD，DevOps等等，古代有道，氣，八卦等等。此類名詞的最大特色就是一解釋就懂，一問就不知，一討論就打架。

微服務的流行，Martin功不可沒，這老頭也是個奇人，特別擅長抽象概括和製造概念，我覺的這就是最牛逼的markting啊，感受這也是目前國人欠缺的能力。

Martin Fowler是國際著名的OO專家，敏捷開發方法的創始人之一，現爲ThoughtWorks公司的首席科學家.福勒（Martin Fowler），在面向對象分析設計、UML、模式、軟件開發方法學、XP、重構等方面，都是世界頂級的專家，現爲Thought Works公司的首席科學家。Thought Works是一家從事企業應用開發和集成的公司。早在20世紀80年代，Fowler就是使用對象技術構建多層企業應用的倡導者，他著有幾本經典書籍：《企業應用架構模式》、《UML精粹》和《重構》等。—— 百度百科

先來看看傳統的web開發方式，經過對比比較容易理解什麼是Microservice Architecture。和Microservice相對應的，這種方式通常被稱爲Monolithic（比較難傳神的翻譯）。全部的功能打包在一個 WAR包裏，基本沒有外部依賴（除了容器），部署在一個JEE容器（Tomcat，JBoss，WebLogic）裏，包含了 DO/DAO，Service，UI等全部邏輯。

Monolithic比較適合小項目，優勢是：

開發簡單直接，集中式管理
基本不會重複開發
功能都在本地，沒有分佈式的管理開銷和調用開銷

它的缺點也很是明顯，特別對於互聯網公司來講（不一一列舉了）：

開發效率低：全部的開發在一個項目改代碼，遞交代碼相互等待，代碼衝突不斷
代碼維護難：代碼功能耦合在一塊兒，新人不知道何從下手
部署不靈活：構建時間長，任何小修改必須從新構建整個項目，這個過程每每很長
穩定性不高：一個微不足道的小問題，能夠致使整個應用掛掉
擴展性不夠：沒法知足高併發狀況下的業務需求

因此，如今主流的設計通常會採用Microservice Architecture，就是基於微服務的架構。簡單來講，微服務的目的是有效的拆分應用，實現敏捷開發和部署。

用《The art of scalability》一書裏提到的scale cube比較容易理解如何拆分。你看，咱們叫分庫分表，別人總結成了scale cube，這就是抽象的能力啊，把複雜的東西用最簡單的概念解釋和總結。X軸表明運行多個負載均衡器以後運行的實例，Y軸表明將應用進一步分解爲微服務（分庫），數據量大時，還能夠用Z軸將服務按數據分區（分表）

微服務的具體特徵

先看看最官方的定義吧

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.
-- James Lewis and Martin Fowler

把Martin老頭的定義大概的翻譯一下就是下面幾條，這個定義仍是太抽象是否是，那就對了，就是要務虛，都說明白了誰還找他付費諮詢啊，這麼貴。
1. 一些列的獨立的服務共同組成系統
2. 單獨部署，跑在本身的進程裏
3. 每一個服務爲獨立的業務開發
4. 分佈式的管理

Martin本身也說了，每一個人對微服務均可以有本身的理解，不過大概的標準仍是有一些的。

分佈式服務組成的系統
按照業務而不是技術來劃分組織
作有生命的產品而不是項目
Smart endpoints and dumb pipes（個人理解是強服務個體和弱通訊）
自動化運維（DevOps）
容錯
快速演化

SOA vs Microservice

除了Smart endpoints and dumb pipes都很容易理解對嗎？相信不少人都會問一個問題，這是否是就是SOA換了個概念，掛羊頭賣狗肉啊，有說法把Microservice叫成 Lightway SOA。也有不少傳統磚家跳出來講Microservice就是SOA。其實Martin也沒否定SOA和Microservice的關係。

我我的理解，Microservice是SOA的傳承，但一個最本質的區別就在於Smart endpoints and dumb pipes，或者說是真正的分佈式的、去中心化的。Smart endpoints and dumb pipes本質就是去ESB，把全部的「思考」邏輯包括路由、消息解析等放在服務內部（Smart endpoints），去掉一個大一統的ESB，服務間輕（dumb pipes）通訊，是比SOA更完全的拆分。

HOW - 怎麼具體實踐微服務

聽上去好像都不錯，具體怎麼落地啊？這須要回答下面幾個問題：

客戶端如何訪問這些服務？
服務之間如何通訊？
這麼多服務，怎麼找?
服務掛了怎麼辦？

客戶端如何訪問這些服務？

原來的Monolithic方式開發，全部的服務都是本地的，UI能夠直接調用，如今按功能拆分紅獨立的服務，跑在獨立的通常都在獨立的虛擬機上的 Java進程了。客戶端UI如何訪問他的？後臺有N個服務，前臺就須要記住管理N個服務，一個服務下線/更新/升級，前臺就要從新部署，這明顯不服務咱們拆分的理念，特別當前臺是移動應用的時候，一般業務變化的節奏更快。另外，N個小服務的調用也是一個不小的網絡開銷。還有通常微服務在系統內部，一般是無狀態的，用戶登陸信息和權限管理最好有一個統一的地方維護管理（OAuth）。

因此，通常在後臺N個服務和UI之間通常會一個代理或者叫API Gateway，他的做用包括

提供統一服務入口，讓微服務對前臺透明
聚合後臺的服務，節省流量，提高性能
提供安全，過濾，流控等API管理功能

個人理解其實這個API Gateway能夠有不少廣義的實現辦法，能夠是一個軟硬一體的盒子，也能夠是一個簡單的MVC框架，甚至是一個Node.js的服務端。他們最重要的做用是爲前臺（一般是移動應用）提供後臺服務的聚合，提供一個統一的服務出口，解除他們之間的耦合，不過API Gateway也有可能成爲單點故障點或者性能的瓶頸。

通常用過Taobao Open Platform的就能很容易的體會，TAO就是這個API Gateway。

服務之間如何通訊？

由於全部的微服務都是獨立的Java進程跑在獨立的虛擬機上，因此服務間的通行就是IPC（inter process communication），已經有不少成熟的方案。如今基本最通用的有兩種方式。這幾種方式，展開來說均可以寫本書，並且你們通常都比較熟悉細節了，就不展開講了。

同步調用
- REST（JAX-RS，Spring Boot）
- RPC（Thrift, Dubbo）
異步消息調用(Kafka, Notify, MetaQ)

通常同步調用比較簡單，一致性強，可是容易出調用問題，性能體驗上也會差些，特別是調用層次多的時候。RESTful和RPC的比較也是一個頗有意思的話題。通常REST基於HTTP，更容易實現，更容易被接受，服務端實現技術也更靈活些，各個語言都能支持，同時能跨客戶端，對客戶端沒有特殊的要求，只要封裝了HTTP的SDK就能調用，因此相對使用的廣一些。RPC也有本身的優勢，傳輸協議更高效，安全更可控，特別在一個公司內部，若是有統一個的開發規範和統一的服務框架時，他的開發效率優點更明顯些。就看各自的技術積累實際條件，本身的選擇了。

而異步消息的方式在分佈式系統中有特別普遍的應用，他既能減低調用服務之間的耦合，又能成爲調用之間的緩衝，確保消息積壓不會沖垮被調用方，同時能保證調用方的服務體驗，繼續幹本身該乾的活，不至於被後臺性能拖慢。不過須要付出的代價是一致性的減弱，須要接受數據最終一致性；還有就是後臺服務通常要實現冪等性，由於消息發送出於性能的考慮通常會有重複（保證消息的被收到且僅收到一次對性能是很大的考驗）；最後就是必須引入一個獨立的broker，如果公司內部沒有技術積累，對broker分佈式管理也是一個很大的挑戰。

這麼多服務，怎麼找?

在微服務架構中，通常每個服務都是有多個拷貝，來作負載均衡。一個服務隨時可能下線，也可能應對臨時訪問壓力增長新的服務節點。服務之間如何相互感知？服務如何管理？這就是服務發現的問題了。通常有兩類作法，也各有優缺點。基本都是經過zookeeper等相似技術作服務註冊信息的分佈式管理。當服務上線時，服務提供者將本身的服務信息註冊到ZK（或相似框架），並經過心跳維持長連接，實時更新連接信息。服務調用者經過ZK尋址，根據可定製算法，找到一個服務，還能夠將服務信息緩存在本地以提升性能。當服務下線時，ZK會發通知給服務客戶端。

客戶端作：優勢是架構簡單，擴展靈活，只對服務註冊器依賴。缺點是客戶端要維護全部調用服務的地址，有技術難度，通常大公司都有成熟的內部框架支持，好比Dubbo。
服務端作：優勢是簡單，全部服務對於前臺調用方透明，通常在小公司在雲服務上部署的應用採用的比較多。

這麼多服務，服務掛了怎麼辦？

前面提到，Monolithic方式開發一個很大的風險是，把全部雞蛋放在一個籃子裏，一榮俱榮，一損俱損。而分佈式最大的特性就是網絡是不可靠的。經過微服務拆分能下降這個風險，不過若是沒有特別的保障，結局確定是噩夢。咱們剛遇到一個線上故障就是一個很不起眼的SQL計數功能，在訪問量上升時，致使數據庫load彪高，影響了所在應用的性能，從而影響全部調用這個應用服務的前臺應用。因此當咱們的系統是由一系列的服務調用鏈組成的時候，咱們必須確保任一環節出問題都不至於影響總體鏈路。相應的手段有不少：

重試機制
限流
熔斷機制
負載均衡
降級（本地緩存）

這些方法基本上都很明確通用，就不詳細說明了。好比Netflix的Hystrix：https://github.com/Netflix/Hystrix

WHY - 微服務的應用

這裏有一個圖很是好的總結微服務架構須要考慮的問題，包括

API Gateway
服務間調用
服務發現
服務容錯
服務部署
數據調用

微服務的優勢和缺點（或者說挑戰）同樣明顯。

優勢
- 開發簡單
- 技術棧靈活
- 服務獨立無依賴
- 獨立按需擴展
- 可用性高
缺點（挑戰）
- 多服務運維難度
- 系統部署依賴
- 服務間通訊成本
- 數據一致性
- 系統集成測試
- 重複工做
- 性能監控

沒有最好的，只有適合本身的。

對於大的互聯網公司，微服務架構是血液，是習慣，每家公司都有本身的套路和架構，細節有不一樣，可是核心理念是通的。
對於通常的公司而言，實踐微服務有很是大的技術挑戰，因而乎纔有了這麼多IT供應商考慮這裏的商機。微服務比較適合將來有必定的擴展複雜度，且有很大用戶增量預期的應用，說人話就是新興的互聯網公司。創業初期，不可能買大量的機器或者很貴的機器，可是又必須考慮應對成功後的巨量的用戶，微服務架構成了最好的選擇。