一、微服務概述與SpringCloud

一、微服務概述與SpringCloud

1、微服務與微服務架構

• 微服務強調的是服務的大小，它關注的是某一個點，是具體解決某一個問題/提供落地對應服務的一個服務應用,狹意的看,可以看作Eclipse裏面的一個個微服務工程/或者Module
• 微服務架構是一種架構模式，它提倡將單一應用程序劃分成一組小的服務，服務之間互相協調、互相配合，爲用戶提供最終價值。每個服務運行在其獨立的進程中，服務與服務間採用輕量級的通信機制互相協作（通常是基於HTTP協議的RESTful API）。每個服務都圍繞着具體業務進⾏構建，並且能夠被獨立的部署到生產環境、類生產環境等。另外，應當儘量避免統一的、集中式的服務管理機制，對具體的一個服務而言，應根據業務上下⽂，選擇合適的語言、工具對其進行構建。

技術維度理解

微服務化的核心就是將傳統的一站式應用，根據業務拆分成一個一個的服務，徹底地去耦合,每一個微服務提供單個業務功能的服務，一個服務做一件事，從技術角度看就是一種小而獨立的處理過程，類似進程概念，能夠自行單獨啓動或銷燬，擁有自己獨立的數據庫。

微服務的優點：

每個服務足夠內聚，足夠小，代碼容易理解這樣能聚焦一個指定的業務功能或業務需求；

開發簡單、開發效率提高、一個服務可能就是專一的只幹一件事；

微服務能夠被小團隊單獨開發，這個小團隊是2-5人的開發人員組成；

微服務是松耦合的，具有功能意義的服務，無論是開發階段或部署階段都是獨立的；

微服務能使用不同的語言開發；

易與和第三方集成，微服務允許容易且靈活的方式集成自動部署，通過持續集成工具，如Jenkins,Hudson,bamboo;

微服務允許你利用融合最新技術；

微服務只是業務邏輯的代碼，不會和html,css或其他界面組件混合；

每個微服務都有自己的存儲能力，可以有自己的數據庫，也可以有統一數據庫。

微服務的缺點：

開發人員要處理分佈式系統的複雜性；

多服務運維難度，隨着服務的增加，運維壓力增加；

系統部署依賴

服務間通信成本

數據一致性

系統集成測試

性能監控

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

爲什麼選擇springcloud作爲微服務架構？

可從：1、整體解決方案和框架成熟度，2、社區熱度，3、可維護性，4、學習曲線

當前IT公司用的微服務架構有哪些？

阿里Dubbo/HSF、京東JSF、新浪Motan、噹噹網DubboX

3、SpringCloud入門概述

官網說明：

• SpringCloud，基於SpringBoot提供了一套微服務解決方案，包括服務註冊與發現，配置中心，全鏈路監控，服務網關，負載均衡，熔斷器等組件，除了基於NetFlix的開源組件做高度抽象封裝之外，還有一些選型中立的開源組件。

• SpringCloud利用SpringBoot的開發便利性巧妙地簡化了分佈式系統基礎設施的開發，SpringCloud爲開發人員提供了快速構建分佈式系統的一些工具，包括配置管理、服務發現、斷路器、路由、微代理、事件總線、全局鎖、決策競選、分佈式會話等等,它們都可以用SpringBoot的開發風格做到一鍵啓動和部署。

• SpringBoot並沒有重複製造輪子，它只是將目前各家公司開發的比較成熟、經得起實際考驗的服務框架組合起來，通過SpringBoot風格進行再封裝屏蔽掉了複雜的配置和實現原理，最終給開發者留出了一套簡單易懂、易部署和易維護的分佈式系統開發工具包

簡單來說：SpringCloud=分佈式微服務架構下的一站式解決方案，是各個微服務架構落地技術的集合體，俗稱微服務全家桶。

1）springboot和springcloud是什麼關係？

• SpringBoot專注於快速方便的開發單個個體微服務。（微觀）
• SpringCloud是關注全局的微服務協調整理治理框架，它將SpringBoot開發的一個個單體微服務整合並管理起來，爲各個微服務之間提供，配置管理、服務發現、斷路器、路由、微代理、事件總線、全局鎖、決策競選、分佈式會話等等集成服務；（宏觀）
• SpringBoot可以離開SpringCloud獨立使用開發項目，但是SpringCloud離不開SpringBoot，屬於依賴的關係.
• SpringBoot專注於快速、方便的開發單個微服務個體，SpringCloud關注全局的服務治理框架。

2）Dubbo是怎麼到SpringCloud的？哪些優缺點讓你去技術選型？

• 目前成熟的互聯網架構（分佈式+服務治理Dubbo）

在這裏插入圖片描述

springcloud和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源碼+周邊的一整套解決方案，並不是每一個公司都有阿里的大牛+真實的線上生產環境測試過。

3）總結Dubbo和Cloud

問題：
曾風靡國內的開源 RPC 服務框架 Dubbo 在重啓維護後，令許多用戶爲之雀躍，但同時，也迎來了一些質疑的聲音。互聯網技術發展迅速，Dubbo 是否還能跟上時代？Dubbo 與 Spring Cloud 相比又有何優勢和差異？是否會有相關舉措保證 Dubbo 的後續更新頻率？

人物：Dubbo重啓維護開發的劉軍，主要負責人之一

劉軍，阿里巴巴中間件高級研發工程師，主導了 Dubbo 重啓維護以後的幾個發版計劃，專注於高性能 RPC 框架和微服務相關領域。曾負責網易考拉 RPC 框架的研發及指導在內部使用，參與了服務治理平臺、分佈式跟蹤系統、分佈式一致性框架等從無到有的設計與開發過程。

Dubbo的定位始終是一款RPC框架，而SpringCloud的目標是微服務框架下的一站式解決，在面臨微服務框架選型時Dubbo和SpringCloud只能二選一。

參考網站：https://www.springcloud.cc/