微服務概述與SpringCloud
1.1 微服務與微服務架構
業界大牛馬丁.福勒（Martin Fowler） 這樣描述微服務：
論文網址： https://martinfowler.com/articles/microservices.html
_ 微服務
強調的是服務的大小，它關注的是某一個點，是具體解決某一個問題/提供落地對應服務的一個服務應用,
狹意的看,可以看作Eclipse裡面的一個個微服務工程/或者Module
_ 微服務架構
clip_image004.jpg
)
微服務架構是⼀種架構模式，它提倡將單⼀應⽤程式劃分成⼀組⼩的服務，服務之間互相協調、互相配合，為⽤戶提供最終價值。每個服務運⾏在其獨⽴的程序中，服務與服務間採⽤輕量級的通訊機制互相協作（通常是基於HTTP協議的RESTful API）。每個服務都圍繞著具體業務進⾏構建，並且能夠被獨⽴的部署到⽣產環境、類⽣產環境等。另外，應當儘量避免統⼀的、集中式的服務管理機制，對具體的⼀個服務⽽⾔，應根據業務上下⽂，選擇合適的語⾔、⼯具對其進⾏構建。
1.1.1 技術維度理解
微服務化的核心就是將傳統的一站式應用，根據業務拆分成一個一個的服務，徹底 地去耦合,每一個微服務提供單個業務功能的服務，一個服務做一件事， 從技術角度看就是一種小而獨立的處理過程，類似程序概念，能夠自行單獨啟動 或銷燬，擁有自己獨立的資料庫。
1.2 微服務技術棧有哪些
| 微服務條目 | 落地技術 | 備註 |
|---|---|---|
| 服務開發 | Springboot、Spring、SpringMVC | |
| 服務配置與管理 | Netflix公司的Archaius、阿里的Diamond等 | |
| 服務註冊與發現 | Eureka、Consul、Zookeeper等 | |
| 服務呼叫 | Rest、RPC、gRPC | |
| 服務熔斷器 | Hystrix、Envoy等 | |
| 負載均衡 | Ribbon、Nginx等 | |
| 服務介面呼叫(客戶端呼叫服務的簡化工具) | Feign等 | |
| 訊息佇列 | Kafka、RabbitMQ、ActiveMQ等 | |
| 服務配置中心管理 | SpringCloudConfig、Chef等 | |
| 服務路由（API閘道器） | Zuul等 | |
| 服務監控 | Zabbix、Nagios、Metrics、Spectator等 | |
| 全鏈路追蹤 | Zipkin，Brave、Dapper等 | |
| 服務部署 | Docker、OpenStack、Kubernetes等 | |
| 資料流操作開發包 | SpringCloud Stream（封裝與Redis,Rabbit、Kafka等傳送接收訊息） | |
| 事件訊息匯流排 | Spring Cloud Bus | |
| ...... |
1.3 SpringCloud是什麼
1.3.1 官網說明
clip_image006.jpg
SpringCloud，基於SpringBoot提供了一套微服務解決方案，包括服務註冊與發現，配置中心，全鏈路監控，服務閘道器，負載均衡，熔斷器等元件，除了基於NetFlix的開源元件做高度抽象封裝之外，還有一些選型中立的開源元件。
SpringCloud利用SpringBoot的開發便利性巧妙地簡化了分散式系統基礎設施的開發，SpringCloud為開發人員提供了快速構建分散式系統的一些工具，包括配置管理、服務發現、斷路器、路由、微代理、事件匯流排、全域性鎖、決策競選、分散式會話等等,它們都可以用SpringBoot的開發風格做到一鍵啟動和部署。
SpringBoot並沒有重複製造輪子，它只是將目前各家公司開發的比較成熟、經得起實際考驗的服務框架組合起來，通過SpringBoot風格進行再封裝遮蔽掉了複雜的配置和實現原理，最終給開發者留出了一套簡單易懂、易部署和易維護的分散式系統開發工具包
1.3.2 SpringCloud=分散式微服務架構下的一站式解決方案
是各個微服務架構落地技術的集合體，俗稱微服務全家桶
1.3.3 SpringCloud和SpringBoot是什麼關係
SpringBoot專注於快速方便的開發單個個體微服務。
SpringCloud是關注全域性的微服務協調整理治理框架，它將SpringBoot開發的一個個單體微服務整合並管理起來，
為各個微服務之間提供，配置管理、服務發現、斷路器、路由、微代理、事件匯流排、全域性鎖、決策競選、分散式會話等等整合服務
SpringBoot可以離開SpringCloud獨立使用開發專案，但是SpringCloud離不開SpringBoot，屬於依賴的關係.
SpringBoot專注於快速、方便的開發單個微服務個體，SpringCloud關注全域性的服務治理框架。
1.3.4 Dubbo對比SpringCloud優缺點
目前成熟的網際網路架構（分散式+服務治理Dubbo）
我們把SpringCloud VS DUBBO進行一番對比
最大區別：SpringCloud拋棄了Dubbo的RPC通訊，採用的是基於HTTP的REST方式。
嚴格來說，這兩種方式各有優劣。雖然從一定程度上來說，後者犧牲了服務呼叫的效能，但也避免了上面提到的原生RPC帶來的問題。而且REST相比RPC更為靈活，服務提供方和呼叫方的依賴只依靠一紙契約，不存在程式碼級別的強依賴，這在強調快速演化的微服務環境下，顯得更加合適。
品牌機與組裝機的區別
很明顯，Spring Cloud的功能比DUBBO更加強大，涵蓋面更廣，而且作為Spring的拳頭專案，它也能夠與Spring Framework、Spring Boot、Spring Data、Spring Batch等其他Spring專案完美融合，這些對於微服務而言是至關重要的。使用Dubbo構建的微服務架構就像組裝電腦，各環節我們的選擇自由度很高，但是最終結果很有可能因為一條記憶體質量不行就點不亮了，總是讓人不怎麼放心，但是如果你是一名高手，那這些都不是問題；而Spring Cloud就像品牌機，在Spring Source的整合下，做了大量的相容性測試，保證了機器擁有更高的穩定性，但是如果要在使用非原裝元件外的東西，就需要對其基礎有足夠的瞭解。
社群支援與更新力度
最為重要的是，DUBBO停止了5年左右的更新，雖然2017.7重啟了。對於技術發展的新需求，需要由開發者自行拓展升級（比如噹噹網弄出了DubboX），這對於很多想要採用微服務架構的中小軟體組織，顯然是不太合適的，中小公司沒有這麼強大的技術能力去修改Dubbo原始碼+周邊的一整套解決方案，並不是每一個公司都有阿里的大牛+真實的線上生產環境測試過。
總結Cloud與Dubbo
問題：
曾風靡國內的開源 RPC 服務框架 Dubbo 在重啟維護後，令許多使用者為之雀躍，但同時，也迎來了一些質疑的聲音。網際網路技術發展迅速，Dubbo 是否還能跟上時代？Dubbo 與 Spring Cloud 相比又有何優勢和差異？是否會有相關舉措保證 Dubbo 的後續更新頻率？
人物：Dubbo重啟維護開發的劉軍，主要負責人之一
劉軍，阿里巴巴中介軟體高階研發工程師，主導了 Dubbo 重啟維護以後的幾個發版計劃，專注於高效能 RPC 框架和微服務相關領域。曾負責網易考拉 RPC 框架的研發及指導在內部使用，參與了服務治理平臺、分散式跟蹤系統、分散式一致性框架等從無到有的設計與開發過程
1.4 參考資料
官網
http://projects.spring.io/spring-cloud/
參考書
https://springcloud.cc/spring-cloud-netflix.html
springcloud中國社群
springcloud中文網
轉載自：https://www.jianshu.com/p/8c1da051fbe4