微服務概述
微服務是什麼
微服務架構提出者馬丁福勒論文
就目前而言，對於微服務業界並沒有一個統一的、 標準的定義(While there is no precise definition of this architectural style)。
但通常而言，微服務架構是一種架構模式或者說是一種架構風格，它提倡將單一應用程序劃分成一組小的服務，每個服務運行在其獨立的自己的進程中，服務之間互相協調、互相配合，爲用戶提供最終價值。服務之間採用輕量級的通信機制互相溝通（通常是基於HTTP的RESTful API）。每個服務都圍繞着具體業務進行構建，並且能夠被獨立地部署到生產環境、類生產環境等。另外，應儘量避免統一的、 集中式的服務管理機制，對具體的一個服務而言，應根據業務上下文，選擇合適的語言、工具對其進行構建，可以有一個非常輕量級的集中式管理來協調這些服務， 可以使用不同的語言來編寫服務，也可以使用不同的數據存儲。
技術維度理解
微服務化的核心就是將傳統的一站式應用，根據業務拆分成一個一個的服務，徹底地解耦合，每一個微服務提供單個業務功能的服務，一個服務做一件事，從技術角度看就是一種小而獨立的處理過程，類似進程概念，能夠自行單獨啓動或銷燬，擁有自己獨立的數據庫。
微服務與微服務架構
微服務
強調的是服務的大小，它關注的是某一個點， 是具體解決某一個問題/提供落地對應服務的一個服務應用，狹意得看，可以看作Eclipse裏面的一個個微服務工程/或者Module
微服務架構
微服務架構是一種架構模式，它提倡將單一應用程序劃分成一組小的服務，服務之間互相協調、互相配合，爲用戶提供最終價值。每個服務運行在其獨立的進程中，服務與服務間採用輕量級的通信機制互相協作（通常是基於HTTP協議的RESTful API）。每個服務都圍繞着具體業務進行構建，並且能夠被獨立的部署到生產環境、類生產環境等。另外，應當儘量避免統一的、 集中式的服務管理機制，對具體的一個服務而言，應根據業務上下文，選擇合適的語言、工具對其進行構建。
微服務強調的是個體，微服務架構強調的是宏觀整體，用哪些方式把一個個的微服務組裝拼接起來，對外形成一個整體。
微服務優缺點
優點
每個服務足夠內聚、足夠小，代碼易理解，這樣能聚焦一個指定的業務功能或業務需求；
開發簡單、開發效率提高，一個服務可能就是專一的只幹一件事；
微服務能夠被小團隊單獨開發，這個小團隊是2到5人的開發人員組成；
微服務是松耦合的，是有功能意義的服務,無論是在開發階段或部署階段都是獨立的；
微服務能使用不同的語言開發；
易於和第三方集成，微服務允許容易且靈活的方式集成自動部署，通過持續集成工具，如Jenkins, Hudson, bamboo；
微服務易於被一個開發人員理解，修改和維護，這樣小團隊能夠更關注自己的工作成果，無需通過合作才能體現價值；
微服務允許利用融合最新技術；
微服務只是業務邏輯的代碼，不會和HTML、CSS或其他界面組件混合；
每個微服務都有自己的存儲能力，可以有自己的數據庫。也可以有統一數據庫；
缺點
開發人員要處理分佈式系統的複雜性
多服務運維難度，隨着服務的增加，運維的壓力也在增大
系統部署依賴
服務間通信成本
數據一致性
系統集成測試
性能監控
微服務技術棧
| 微服務條目 | 落地技術 |
|---|---|
| 服務開發 | 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作爲微服務架構
選型依據
- 整體解決方案和框架成熟度
- 社區熱度
- 可維護性
- 學習曲線
當前各大IT公司用的微服務架構
- 阿里Dubbo/HSF（Dubbo停更多年又重啓；HSF是分佈式的高速框架 可理解爲第二代dubbo）
- 京東JSF
- 新浪微博Motan
- 噹噹網DubboX
各微服務框架對比
| 功能點/服務框架 ######### | Netflix/Spring cloud | Motan | gRPC | Thrift | Dubbo/DubboX |
|---|---|---|---|---|---|
| 功能定位 | 完整的微服務框架 | RPC框架,但整合了ZK 或Consul,實現集羣環境的基本的服務註冊/發現 | RPC框架 | RPC框架 | 服務框架 |
| 支持Rest | 是 Ribbon支持多種可插拔的序列化選擇 | 否 | 否 | 否 | 否 |
| 支持RPC | 否 | 是(Hession2) | 是 | 是 | 是 |
| 支持多語言 | 是(Rest形式)? | 否 | 是 | 是 | 否 |
| 服務註冊/發現 | 是(Eureka) Eureka服務註冊表，Karyon服務端框架支持服務自注冊和健康檢查 | 是(zookeeper/consul) | 否 | 否 | 是 |
| 負載均衡 | 是(服務端zuul+客戶端Ribbon) Zuul-服務，動態路由 雲端負載均衡 Eureka(針對中間層服務器) | 是(客戶端) | 否 | 否 | 是(客戶端) |
| 配置服務 | Netflix Archaius SpringCloud Config Server集中配置 | 是(zookeeper提供) | 否 | 否 | 否 |
| 服務調用鏈監控 | 是(zuul) Zuul提供邊緣服務,API網關 | 否 | 否 | 否 | 否 |
| 高可用/容錯 | 是(服務端Hystrix+客戶端Ribbon) | 是(客戶端) | 否 | 否 | 是(客戶端) |
| 典型應用案例 | Netflix | Sina | |||
| 社區活躍程度 | 高 | 一般 | 高 | 一般 | 已經不維護了 |
| 學習難度 | 中等 | 低 | 高 | 高 | 低 |
| 文檔豐富度 | 高 | 一般 | 一般 | 一般 | 高 |
| 其他 | Spring Cloud Bus爲我們的應用程序帶來了更多管理端點 | 支持降級 | Netlix內郵在開發集成gRPC | IDL定義 | 實踐的公司比較多 |
SpringCloud入門概述
概述
SpringCloud，基於SpringBoot提供了一套微服務解決方案，包括服務註冊與發現，配置中心，全鏈路監控，服務網關，負載均衡，熔斷器等組件，除了基於NetFlix的開源組件做高度抽象封裝之外，還有一些選型中立的開源組件。
SpringCloud利用SpringBoot的開發便利性巧妙地簡化了分佈式系統基礎設施的開發，SpringCloud爲開發人員提供了快速構建分佈式系統的一些工具，包括配置管理、服務發現、斷路器、路由、微代理、事件總線、全局鎖、決策競選、分佈式會話等等。它們都可以用SpringBoot的開發風格做到一鍵啓動和部署。
SpringBoot並沒有重複製造輪子，它只是將目前各家公司開發的比較成熟、經得起實際考驗的服務框架組合起來，通過SpringBoot風格進行再封裝屏蔽掉了複雜的配置和實現原理，最終給開發者留出了一套簡單易懂、易部署和易維護的分佈式系統開發工具包。
SpringCloud=分佈式微服務架構下的一站式解決方案，是各個微服務架構落地技術的集合體，俗稱微服務全家桶。
SpringCloud與SpringBoot
SpringBoot專注於快速方便的開發單個個體微服務。
SpringCloud是關注全局的微服務協調整理治理框架，它將SpringBoot開發的一個個單體微服務整合並管理起來,
爲各個微服務之間提供 配置管理、服務發現、斷路器、路由、微代理、事件總線、全局鎖、決策競選、分佈式會話等等集成服務。SpringBoot可以離開SpringCloud獨立使用開發項目，但是SpringCloud離不開SpringBoot，屬於依賴的關係。
SpringBoot專注於快速、 方便的開發單個微服務個體，SpringCloud關注全局的服務治理框架。
SpringCloud與Dubbo
對比
| SpringCloud | Dubbo | |
|---|---|---|
| 服務註冊中心 | Spring Cloud Netflix Eureka | Zookeeper |
| 服務調用方式 | REST API | RPC |
| 服務監控 | Spring Boot Admin | Dubbo-monitor |
| 斷路器 | Spring Cloud Netflix Hystrix | 不完善 |
| 服務網關 | Spring Cloud Netflix Zuul | 無 |
| 分佈式配置 | Spring Cloud Config | 無 |
| 服務跟蹤 | Spring Cloud Sleuth | 無 |
| 消息總線 | Spring Cloud Bus | 無 |
| 數據流 | Spring Cloud Stream | 無 |
| 批量任務 | Spring Cloud Task | 無 |
| …… | …… | …… |
最大區別：SpringCloud拋棄了Dubbo的RPC通信，採用的是基於HTTP的REST方式。
嚴格來說，這兩種方式各有優劣。雖然從一定程度上來說，SpringCloud犧牲了服務調用的性能，但也避免了上面提到的原生RPC帶來的問題。而且REST相比RPC更爲靈活，服務提供方和調用方的依賴只依靠一紙契約， 不存在代碼級別的強依賴，這在強調快速演化的微服務環境下，顯得更加合適。
就像品牌機與組裝機的區別：
很明顯，SpringCloud的功能比DUBBO更加強大、涵蓋面更廣，而且作爲Spring的拳頭項目，它也能夠與Spring Framework、Spring Boot、 Spring Data、 Spring Batch等其他Spring項目完美融合，這些對於微服務而言是至關重要的。使用Dubbo構建的微服務架構就像組裝電腦，各環節我們的選擇自由度很高，但是最終結果很有可能因爲一條內存質量不行就點不亮了，總是讓人不怎麼放心，但是如果你是一 名高手，那這些都不是問題，而Spring Cloud就像品牌機，在SpringSource的整合下，做了大量的兼容性測試，保證了機器擁有更高的穩定性，但是如果要在使用非原裝組件外的東西，就需要對其基礎有足夠的瞭解。
社區支持與更新力度：
最爲重要的是，DUBBO停止了5年左右的更新，雖然2017.7重啓了。對於技術發展的新需求，需要由開發者自行拓展升級（比如噹噹網弄出了DubboX） , 這對於很多想要採用微服務架構的中小軟件組織顯然是不太合適的，中小公司沒有這麼強大的技術能力去修改Dubbo源碼+周邊的一整套解決方案，並不是每一個公司都有阿里的大牛+ 真實的線上生產環境測試過。
總結
Dubbo重啓維護開發的劉軍（主要負責人之一）：
兩者所解決的問題域並不一樣——
Dubbo的定位始終是一款RPC框架，而SpringCloud的目標是微服務架構下的一站式解決方案。
如果非要比較的話，我覺得Dubbo可以類比到Netflix OSS技術棧，而Spring Cloud集成了Netflix OSS作爲分佈式服務治理解決方案，但除此之外Spring Cloud還提供了包括config、stream、security、sleuth等等分佈式問題解決方案。