Spring Cloud
微服務入門核心概念
什麼是微服務
微服務 (Microservices) 是一種軟件架構風格，它是以專注於單一責任與功能的小型功能區塊 (Small Building Blocks) 爲基礎，利用模組化的方式組合出複雜的大型應用程序，各功能區塊使用與語言無關 (Language-Independent/Language agnostic) 的 API 集相互通訊。微服務的起源是由 Peter Rodgers 博士於 2005 年度雲端運算博覽會提出的微 Web 服務 (Micro-Web-Service) 開始，Juval Löwy 則是與他有類似的前導想法，將類別變成細粒服務 (granular services)，以作爲 Microsoft 下一階段的軟件架構，其核心想法是讓服務是由類似 Unix 管道的存取方式使用，而且複雜的服務背後是使用簡單 URI 來開放界面，任何服務，任何細粒都能被開放 (exposed)。這個設計在 HP 的實驗室被實現，具有改變複雜軟件系統的強大力量。2014年，Martin Fowler 與 James Lewis 共同提出了微服務的概念，定義了微服務是由以單一應用程序構成的小服務，自己擁有自己的行程與輕量化處理，服務依業務功能設計，以全自動的方式部署，與其他服務使用 HTTP API 通訊。同時服務會使用最小的規模的集中管理 (例如 Docker) 能力，服務可以用不同的編程語言與數據庫等元件實作。
微服務核心概念
微服務是一種以業務功能爲主的服務設計概念，每一個服務都具有自主運行的業務功能，對外開放不受語言限制的 API (最常用的是 HTTP)，應用程序則是由一個或多個微服務組成。
微服務的另一個對比是單體式應用程序。單體式應用表示一個應用程序內包含了所有需要的業務功能，並且使用像主從式架構 (Client/Server) 或是多層次架構 (N-tier) 實作，雖然它也是能以分散式應用程序來實作，但是在單體式應用內，每一個業務功能是不可分割的。若要對單體式應用進行擴展則必須將整個應用程序都放到新的運算資源（如：虛擬機器） 內，但事實上應用程序中最喫資源、需要運算資源的僅有某個業務部分（例如跑分析報表或是數學算法分析），但因爲單體式應用無法分割該部分，因此無形中會有大量的資源浪費的現象。
微服務運用了以業務功能的設計概念，應用程序在設計時就能先以業務功能或流程設計先行分割，將各個業務功能都獨立實作成一個能自主執行的個體服務，然後再利用相同的協定將所有應用程序需要的服務都組合起來，形成一個應用程序。若需要針對特定業務功能進行擴充時，只要對該業務功能的服務進行擴展就好，不需要整個應用程序都擴展，同時，由於微服務是以業務功能導向的實作，因此不會受到應用程序的干擾，微服務的管理員可以視運算資源的需要來配置微服務到不同的運算資源內，或是布建新的運算資源並將它配置進去。
雖然使用一般的服務器虛擬化技術就能應用於微服務的管理，但容器技術 (Container Technology) 如 Docker 會更加地適合發展微服務的運算資源管理技術。
Spring Cloud 前言
Spring Cloud是基於Spring Boot的一整套實現微服務的框架。他提供了微服務開發所需的配置管理、服務發現、斷路器、智能路由、微代理、控制總線、全局鎖、決策競選、分佈式會話和集羣狀態管理等組件。最重要的是， 跟spring boot框架一起使用的話，會讓你開發微服務架構的雲服務非常好的方便。SpringBoot旨在簡化創建產品級的 Spring 應用和服務，簡化了配置文件，使用嵌入式web服務器，含有諸多開箱即用微服務功能
微服務架構是互聯網很熱門的話題，是互聯網技術發展的必然結果。它提倡將單一應用程序劃分成一組小的服務，服務之間互相協調、互相配合，爲用戶提供最終價值。雖然微服務架構沒有公認的技術標準和規範或者草案，但業界已經有一些很有影響力的開源微服務架構框架提供了微服務的關鍵思路，例如 dubbo 和 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，可以讓你以命令行方式快速建立雲組件。
微服務主要的優勢如下:
1.降低複雜度
將原來偶合在一起的複雜業務拆分爲單個服務，規避了原本複雜度無止境的積累。每一個微服務專注於單一功能，並通過定義良好的接口清晰表述服務邊界。每個服務開發者只專注服務本身，通過使用緩存、DAL 等各種技術手段來提升系統的性能，而對於消費方來說完全透明。
2.可獨立部署
由於微服務具備獨立的運行進程，所以每個微服務可以獨立部署。當業務迭代時只需要發佈相關服務的迭代即可，降低了測試的工作量同時也降低了服務發佈的風險。
3.容錯
在微服務架構下，當某一組件發生故障時，故障會被隔離在單個服務中。 通過限流、熔斷等方式降低錯誤導致的危害，保障核心業務正常運行。
4.擴展
單塊架構應用也可以實現橫向擴展，就是將整個應用完整的複製到不同的節點。當應用的不同組件在擴展需求上存在差異時，微服務架構便體現出其靈活性，因爲每個服務可以根據實際需求獨立進行擴展。
微服務架構優勢
複雜度可控：在將應用分解的同時，規避了原本複雜度無止境的積累。每一個微服務專注於單一功能，並通過定義良好的接口清晰表述服務邊界。由於體積小、複雜度低，每個微服務可由一個小規模開發團隊完全掌控，易於保持高可維護性和開發效率。
獨立部署：由於微服務具備獨立的運行進程，所以每個微服務也可以獨立部署。當某個微服務發生變更時無需編譯、部署整個應用。由微服務組成的應用相當於具備一系列可並行的發佈流程，使得發佈更加高效，同時降低對生產環境所造成的風險，最終縮短應用交付週期。
技術選型靈活：微服務架構下，技術選型是去中心化的。每個團隊可以根據自身服務的需求和行業發展的現狀，自由選擇最適合的技術棧。由於每個微服務相對簡單，故需要對技術棧進行升級時所面臨的風險就較低，甚至完全重構一個微服務也是可行的。
容錯：當某一組建發生故障時，在單一進程的傳統架構下，故障很有可能在進程內擴散，形成應用全局性的不可用。在微服務架構下，故障會被隔離在單個服務中。若設計良好，其他服務可通過重試、平穩退化等機制實現應用層面的容錯。
擴展：單塊架構應用也可以實現橫向擴展，就是將整個應用完整的複製到不同的節點。當應用的不同組件在擴展需求上存在差異時，微服務架構便體現出其靈活性，因爲每個服務可以根據實際需求獨立進行擴展。
什麼是 Spring Boot
Spring Boot是由Pivotal團隊提供的全新框架，其設計目的是用來簡化新Spring應用的初始搭建以及開發過程。該框架使用了特定的方式來進行配置，從而使開發人員不再需要定義樣板化的配置。用我的話來理解，就是Spring Boot其實不是什麼新的框架，它默認配置了很多框架的使用方式，就像maven整合了所有的jar包，Spring Boot整合了所有的框架（不知道這樣比喻是否合適）。
Spring Boot簡化了基於Spring的應用開發，通過少量的代碼就能創建一個獨立的、產品級別的Spring應用。 Spring Boot爲Spring平臺及第三方庫提供開箱即用的設置，這樣你就可以有條不紊地開始。Spring Boot的核心思想就是約定大於配置，多數Spring Boot應用只需要很少的Spring配置。採用Spring Boot可以大大的簡化你的開發模式，所有你想集成的常用框架，它都有對應的組件支持。
Spring Cloud 都做了哪些事
Spring Cloud是一系列框架的有序集合。它利用Spring Boot的開發便利性巧妙地簡化了分佈式系統基礎設施的開發，如服務發現註冊、配置中心、消息總線、負載均衡、斷路器、數據監控等，都可以用Spring Boot的開發風格做到一鍵啓動和部署。Spring並沒有重複製造輪子，它只是將目前各家公司開發的比較成熟、經得起實際考驗的服務框架組合起來，通過Spring Boot風格進行再封裝屏蔽掉了複雜的配置和實現原理，最終給開發者留出了一套簡單易懂、易部署和易維護的分佈式系統開發工具包
微服務中必備的核心組件
-
配置管理
-
控制總線
-
集羣管理
-
安全機制
-
Session管理
-
Failback
-
智能路由
-
網關管理
-
服務發現
三者之間的關係
微服務是一種架構的理念，提出了微服務的設計原則，從理論爲具體的技術落地提供了指導思想。Spring Boot是一套快速配置腳手架，可以基於Spring Boot快速開發單個微服務；Spring Cloud是一個基於Spring Boot實現的服務治理工具包；Spring Boot專注於快速、方便集成的單個微服務個體，Spring Cloud關注全局的服務治理框架。
Spring Boot/Cloud是微服務實踐的最佳落地方案。
Spring Cloud 和 Dubbo 對比
1）從兩個公司的背景來談：Dubbo，是阿里巴巴服務化治理的核心框架，並被廣泛應用於中國各互聯網公司；Spring Cloud是大名鼎鼎的Spring家族的產品。阿里巴巴是一個商業公司，雖然也開源了很多的頂級的項目，但從整體戰略上來講，仍然是服務於自身的業務爲主。Spring專注於企業級開源框架的研發，不論是在中國還是在世界上使用都非常廣泛，開發出通用、開源、穩健的開源框架就是他們的主業。
2）從社區活躍度這個角度來對比，Dubbo雖然也是一個非常優秀的服務治理框架，並且在服務治理、灰度發佈、流量分發這方面做的比Spring Cloud還好，除過當當網在基礎上增加了rest支持外，已有兩年多的時間幾乎都沒有任何更新了。在使用過程中出現問題，提交到github的Issue也少有回覆。
相反Spring Cloud自從發展到現在，仍然在不斷的高速發展，從github上提交代碼的頻度和發佈版本的時間間隔就可以看出，現在Spring Cloud即將發佈2.0版本，到了後期會更加完善和穩定。
- 從整個大的平臺架構來講，dubbo框架只是專注於服務之間的治理，如果我們需要使用配置中心、分佈式跟蹤這些內容都需要自己去集成，這樣無形中使用dubbo的難度就會增加。Spring Cloud幾乎考慮了服務治理的方方面面，更有Spring Boot這個大將的支持，開發起來非常的便利和簡單。
4）從技術發展的角度來講，Dubbo剛出來的那會技術理念還是非常先進，解決了各大互聯網公司服務治理的問題，中國的各中小公司也從中受益不少。經過了這麼多年的發展，互聯網行業也是湧現了更多先進的技術和理念，Dubbo一直停滯不前，自然有些掉隊，有時候我個人也會感到有點可惜，如果Dubbo一直沿着當初的那個路線發展，並且延伸到周邊，今天可能又是另一番景象了。
Spring 推出Spring Boot/Cloud也是因爲自身的很多原因。Spring最初推崇的輕量級框架，隨着不斷的發展也越來越龐大，隨着集成項目越來越多，配置文件也越來越混亂，慢慢的背離最初的理念。隨着這麼多年的發展，微服務、分佈式鏈路跟蹤等更多新的技術理念的出現，Spring急需一款框架來改善以前的開發模式，因此纔會出現Spring Boot/Cloud項目，我們現在訪問Spring官網，會發現Spring Boot和Spring Cloud已經放到首頁最重點突出的三個項目中的前兩個，可見Spring對這兩個框架的重視程度。
如何實施微服務？
1、服務組件化
組件，是一個可以獨立更換和升級的單元。就像PC中的CPU、內存、顯卡、硬盤一樣，獨立且可以更換升級而不影響其他單元。
在“微服務”架構中，需要我們對服務進行組件化分解。服務，是一種進程外的組件，它通過http等通信協議進行協作，而不是傳統組件以嵌入的方式協同工作。服務都獨立開發、部署，可以有效的避免一個服務的修改引起整個系統的重新部署。
2、按業務組織團隊
當我們開始決定如何劃分“微服務”時，通常也意味着我們要開始對團隊進行重新規劃與組織。按以往的方式，我們往往會以技術的層面去劃分多個不同的團隊，比如：DBA團隊、運維團隊、後端團隊、前端團隊、設計師團隊等等。若我們繼續按這種方式組織團隊來實施“微服務”架構開發時，當有一個有問題需要更改，可能是一個非常簡單的變動，比如：對人物描述增加一個字段，這就需要從數據存儲開始考慮一直到設計和前端，雖然大家的修改都非常小，但這會引起跨團隊的時間和預算審批。
在實施“微服務”架構時，需要採用不同的團隊分割方法。由於每一個微服務都是針對特定業務的寬棧或是全棧實現，既要負責數據的持久化存儲，又要負責用戶的接口定義等各種跨專業領域的職能。因此，面對大型項目時候，對於微服務團隊拆分更加建議按業務線的方式進行拆分，一方面可以有效減少服務內部修改所產生的內耗；另一方面，團隊邊界可以變得更爲清晰。
3、做“產品”的態度
實施“微服務”架構的團隊中，每個小團隊都應該以做產品的方式，對其產品的整個生命週期負責。而不是以項目的模式，以完成開發與交付並將成果交接給維護者爲最終目標。
開發團隊通過了解服務在具體生產環境中的情況，可以增加他們對具體業務的理解，比如：很多時候一些業務中發生的特殊或異常情況，很可能產品經理都並不知曉，但細心的開發者很容易通過生產環境發現這些特殊的潛在問題或需求。
所以，我們需要用做“產品”的態度來對待每一個“微服務”，持續關注服務的運作情況，並不斷地分析幫助用戶來提升業務功能。
4、輕量化通信機制
在單體應用中，組件間直接通過函數調用的方式進行交互協作。而在“微服務”架構中，服務由於不在一個進程中，組件間的通信模式發生了改變，若僅僅將原本在進程內的方法調用改成RPC方式的調用，會導致微服務之間產生繁瑣的通信，使得系統表現更爲糟糕，所以，我們需要更粗粒度的通信協議。
在“微服務”架構中，通常會使用這兩個服務調用方式：
第一種，使用HTTP協議的RESTful API或輕量級的消息發送協議，來實現信息傳遞與服務調用的觸發。
第二種，通過在輕量級消息總線上傳遞消息，類似RabbitMQ等一些提供可靠異步交換的結構。
在極度強調性能的情況下，有些團隊會使用二進制的消息發送協議，例如：protobuf。
5、去中心化治理
當我們採用集中化的架構治理方案時，通常在技術平臺上都會做統一的標準，但是每一種技術平臺都有其短板，這會導致在碰到短板時，不得不花費大力氣去解決，並且可能還是因爲其底層原因解決的不是很好。
在實施“微服務”架構時，通過採用輕量級的契約定義接口，使得我們對於服務本身的具體技術平臺不再那麼敏感，這樣我們整個“微服務”架構的系統中的組件就能針對其不同的業務特點選擇不同的技術平臺，終於不會出現殺雞用牛刀或是殺牛用指甲鉗的尷尬處境了。
6、去中心化管理數據
我們在實施“微服務”架構時，都希望可以讓每一個服務來管理其自有的數據庫，這就是數據管理的去中心化。
在去中心化過程中，我們除了將原數據庫中的存儲內容拆分到新的同平臺的其他數據庫實例中之外（如：把原本存儲在MySQL中的表拆分後，存儲多幾個不同的MySQL實例中），也可以針對一些具有特殊結構或業務特性的數據存儲到一些其他技術的數據庫實例中（如：把日誌信息存儲到MongoDB中、把用戶登錄信息存儲到Redis中）。
雖然，數據管理的去中心化可以讓數據管理更加細緻化，通過採用更合適的技術來讓數據存儲和性能達到最優。但是，由於數據存儲於不同的數據庫實例中後，數據一致性也成爲“微服務”架構中急需解決的問題之一。分佈式事務的實現，本身難度就非常大，所以在“微服務”架構中，我們更強調在各服務之間進行“無事務”的調用，而對於數據一致性，只要求數據在最後的處理狀態是一致的效果；若在過程中發現錯誤，通過補償機制來進行處理，使得錯誤數據能夠達到最終的一致性。
7、基礎設施自動化
近年來雲計算服務與容器化技術的不斷成熟，運維基礎設施的工作變得越來越不那麼難了。但是，當我們實施“微服務”架構時，數據庫、應用程序的個頭雖然都變小了，但是因爲拆分的原因，數量成倍的增長。這使得運維人員需要關注的內容也成倍的增長，並且操作性任務也會成倍的增長，這些問題若沒有得到妥善的解決，必將成爲運維人員的噩夢。
所以，在“微服務”架構中，請務必從一開始就構建起“持續交付”平臺來支撐整個實施過程，該平臺需要兩大內容，不可或缺：
自動化測試：每次部署前的強心劑，儘可能的獲得對正在運行軟件的信心。
自動化部署：解放繁瑣枯燥的重複操作以及對多環境的配置管理。
8、容錯設計
在單體應用中，一般不存在單個組件故障而其他還在運行的情況，通常是一掛全掛。而在“微服務”架構中，由於服務都運行在獨立的進程中，所以是存在部分服務出現故障，而其他服務都正常運行的情況，比如：當正常運作的服務B調用到故障服務A時，因故障服務A沒有返回，線程掛起開始等待，直到超時才能釋放，而此時若觸發服務B調用服務A的請求來自服務C，而服務C頻繁調用服務B時，由於其依賴服務A，大量線程被掛起等待，最後導致服務C也不能正常服務，這時就會出現故障的蔓延。
所以，在“微服務”架構中，快速的檢測出故障源並儘可能的自動恢復服務是必須要被設計和考慮的。通常，我們都希望在每個服務中實現監控和日誌記錄的組件，比如：服務狀態、斷路器狀態、吞吐量、網絡延遲等關鍵數據的儀表盤等。
9、演進式設計
通過上面的幾點特徵，我們已經能夠體會到，要實施一個完美的“微服務”架構，需要考慮的設計與成本並不小，對於沒有足夠經驗的團隊來說，甚至要比單體應用發付出更多的代價。
所以，很多情況下，架構師們都會以演進的方式進行系統的構建，在初期系統以單體系統的方式來設計和實施，一方面系統體量初期並不會很大，構建和維護成本都不高。另一方面，初期的核心業務在後期通常也不會發生巨大的改變。隨着系統的發展或者業務的需要，架構師們會將一些經常變動或是有一定時間效應的內容進行“微服務”處理，並逐漸地將原來在單體系統中多變的模塊逐步拆分出來，而穩定不太變化的就形成了一個核心“微服務”存在於整個架構之中。