SpringCloud學習筆記（二）：微服務概述、微服務和微服務架構、微服務優缺點、微服務技術棧有哪些、SpringCloud是什麼

從技術維度理解：

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

從專業維度理解：

業界大牛馬丁.福勒（Martin Fowler） 這樣描述微服務：
論文網址： https://martinfowler.com/articles/microservices.html

• 微服務
強調的是服務的大小，它關注的是某一個點，是具體解決某一個問題/提供落地對應服務的一個服務應用,
狹意的看,能夠看做Eclipse裏面的一個個微服務工程/或者Module

• 微服務架構


微服務架構 是⼀種架構模式，它提倡將單⼀應⽤程序劃分紅⼀組⼩的服務，服務之間互相協調、互相配合，爲⽤戶提供最終價值。每一個服務運⾏在其 獨⽴的進程中 ，服務與服務間採⽤輕量級的通訊機制互相協做（一般是基於HTTP協議的RESTful API）。每一個服務都圍繞着具體業務進⾏構建，而且可以被獨⽴的部署到⽣產環境、類⽣產環境等。另外， 應當儘可能避免統⼀的、集中式的服務管理機制， 對具體的⼀個服務⽽⾔，應根據業務上下⽂，選擇合適的語⾔、⼯具對其進⾏構建。

簡而言之，微服務架構風格[1]是一種將單個應用程序開發爲一套小型服務的方法，每一個小型服務都在本身的流程中運行，並與輕量級機制（一般是HTTP資源API）進行通訊。這些服務圍繞業務功能構建，可經過全自動部署機制獨立部署。這些服務至少集中管理，能夠用不一樣的編程語言編寫，並使用不一樣的數據存儲技術。

之前的工程all in one 單機系統
能夠當作eclipse中只有一個大的工程，包括商品、訂單、交易、庫存、物流等等，放入war包中。

如上圖，左邊的每一個方塊是tomcat在tomcat中有若干個服務，其中的一個服務出現問題，其餘的服務也會出現問題，跟着遭殃，因此出現了右邊的微服務架構，將tomcat中的每一個服務拆分開有各自獨立的進程互不干擾，下降了耦合度。
分佈式服務：各個模塊/服務，各自獨立出來，分竈吃飯；各自微笑的一個進程，讓專業的人專業的模塊，作專業的事情。獨立的部署。

如上圖，左邊的上面三個小人簡單理解爲開發、運維、產品在共同維護一個單一系統，包括許多服務，業務層是一個總體，三個不一樣的表在一個單一的數據庫中，耦合度很高。右邊的經過上面的「小紙條」即外部的配置，修改信息，自動修改配置，相互調用各自的數據庫，極大的下降了耦合度。

*拆分
*擁有各自獨立的進程
*擁有各自獨立的數據庫

微服務和微服務架構

上面已經介紹了微服務和微服務架構的詳細解釋，這裏總結一下:
微服務強調的是一個一個的個體，相似於醫院的一個一個的科室
微服務架構強調的是一個總體，將一個個的微服務組裝拼接起來，對外構成一個總體，對外暴露。五十六個民族就是微服務架構，每一個民族都是微服務。

微服務優缺點

優勢

每一個服務足夠內聚、租後小，代碼容易理解，這樣能聚焦一個置頂的功能和也無需求。
開發簡單、開發效率提升，一個服務可能就是專注的幹一件事。
微服務可以被小團隊單獨開發，這個小團隊是2到5人的開發人員組成。
微服務是鬆耦合的，是有功能意義的服務，不管是在開發階段仍是部署階段都是獨立的。
微服務能使用不一樣的語言開發。
易於和第三方集成，微服務容許容易且靈活的方式集成自動部署，經過持續集成工具，如kenkins，Hudson，banboo。微服務易於被一個開發人員理解，修改和維護，這樣的小團隊可以更關注本身的工做成果。無需經過合做才能體現價值。
微服務容許你李永榮和最新技術。
微服務只是業務邏輯代碼，不會和heml css和其餘的界面組件混合。
每一個微服務都有本身的fun出能力，能夠有本身的數據庫，也能夠有統一的數據庫。

缺點

開發人員要處理分佈式系統的複雜性
多服務運維難度，隨着服務的增長，運維的壓力也會增大
系統部署依賴
服務間通訊成本
數據一致性
系統集成測試
性能監控。。。

微服務技術棧有哪些

SpringCloud是什麼

比較常見的微服務框架

SpringCloud motan（新浪）、grpc（谷歌）、thrift（Facebook）、dubbo（阿里）\dubbox（噹噹）
對比：


什麼是SpringCloud？

官方：

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

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

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

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

SpringCloud和SpringBoot是什麼關係

SpringBoot專一於快速方便的開發單個個體微服務。

SpringCloud是關注全局的微服務協調整理治理框架，它將SpringBoot開發的一個個單體微服務整合並管理起來，
爲各個微服務之間提供，配置管理、服務發現、斷路器、路由、微代理、事件總線、全局鎖、決策競選、分佈式會話等等集成服務

SpringBoot能夠離開SpringCloud獨立使用開發項目， 可是SpringCloud離不開SpringBoot ，屬於依賴的關係.

SpringBoot專一於快速、方便的開發單個微服務個體，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源碼+周邊的一整套解決方案，並非每個公司都有阿里的大牛+真實的線上生產環境測試過。

學習網站：

官網：http://spring.io/projects/spring-cloud
參考書：https://springcloud.cc/spring-cloud-netflix.html
詳細中文文檔：https://springcloud.cc/spring-cloud-dalston.html
中國社區：http://springcloud.cn/
中文網：https://springcloud.cc/

國內使用狀況

阿里雲、華爲、聯通等，小公司居多，由於新興。