1.什麼是微服務？
從官方博文了解（馬丁·福勒）
通常而言，微服務架構是一種架構模式或者說是一種架構風格，它提倡将單一應用程式劃分成一組小的服務，每個服務運作在其獨立的程序中，服務之間互相協調，互相配合，為使用者提供最終價值。服務之間采用輕量級的通信機制互相溝通（通常是基于HTTP的RESTfull API）。每個服務都圍繞着具體業務進行建構，并且能夠被獨立的部署到生産環境，類生産環境等。另外，應盡量避免統一的，集中式的服務管理機制，對具體的一個服務而言，應根據業務上下文，選擇合适的語言，工具對其進行建構，可以有一個非常輕量級的集中式管理來協調這些服務，可以使用不同的語言來編寫服務，也可以使用不同的資料存儲。
注：dubbo的通信機制是基于RPC，cloud是基于HTTP的RESTfull API
從技術次元了解
微服務化的核心就是将傳統的一站式應用，根據業務拆分成一個一個的服務，徹底的去耦合，每一個微服務提供單個業務功能的服務，一個服務做一件事，從技術角度來講就是一種小而獨立的處理過程，類似程序概念，能夠自行單獨啟動或銷毀，擁有自己獨立的資料庫。
-
傳統的單機架構體系（All In One）
以eclipse來說 ，我們可以看作裡面有一個大工程，作者稱這種架構為：巨石。
主要子產品有：商品/訂單/交易/庫存。
單體架構的不足：
- war包之間互相依賴，牽一發而動全身。 - 随着版本更新的疊代，維護成本變高，代碼可讀性大大降低。 - 開發人員分工不明确。
【初識微服務】SpringCloud學習筆記01 - 微服務架構
微服務架構的優勢：
- 各個子產品/服務，各自獨立開來，分竈吃飯
- 各自微小的一個程序，讓專業的人負責專業的子產品，來做專業的事情。
- 獨立部署，各個服務之間利用RESTfull API來互相調用。
- 微服務系統是分布式系統，業務與業務之間完全解耦，随着業務的增加可以根據業務再拆分，具有極強的橫向擴充能力。
面對高并發的場景可以将服務叢集化部署，加強系統負載能力。
當然分布式架構對資料存儲也做了決策，除了關于概念模型的分散決策之外，微服務還分散了資料存儲決策。雖然單一應用程式更喜歡使用單個邏輯資料庫來存儲持久性資料，但企業通常更喜歡在一系列應用程式中使用單個資料庫 - 其中許多決策是通過供應商圍繞許可的商業模型來實作的。微服務更喜歡讓每個服務管理自己的資料庫，可以是同一資料庫技術的不同執行個體，也可以是完全不同的資料庫系統 - 這種方法稱為Polyglot Persistence。您可以在整體中使用多語言持久性，但它在微服務中更常出現。
2.微服務與微服務架構
-
微服務
強調的是服務的大小，它關注的是某個點，是具體解決問題的/提供落地對應服務的一個服務應用，狹意的看，可以看作Eclipse裡面的一個個微服務工程/或者Moudule
-
微服務架構
微服務架構是一種架構模式，它提倡将單一應用程式劃分為一組小的服務，服務之間互相協調，互相配合，為使用者提高最終價值。每個服務運作在獨立的程序中，服務與服務間采用輕量級的通信機制互相協作（通常是基于HTTP協定的RESTfull API）。每個服務都圍繞着具體業務進行建構，并且能夠被獨立的部署到生産環境，類生産環境等，另外，應當避免統一的，集中式的服務管理機制，對具體的單一服務而言，應根據業務的上下文，選擇合适的語言以及開發工具等進行建構。
3.微服務的優缺點
-
優點
1.每個服務足夠内聚，足夠小，代碼容易了解這樣能聚焦一個指定的業務功能或業務需求
2.開發簡單，開發效率高，一個服務可能就是專一的隻幹一件事
3.微服務能夠被小團隊單獨開發，這個小團隊是2-5人的開發人員組成
4.微服務是松耦合的，是有功能意義的服務，無論是在開發階段還是部署階段都是獨立的
5.微服務能夠使用不同的語言進行開發
6.易于與第三方內建，微服務允許容易且靈活的方式內建自動部署，通過持續內建工具，如：Jenkins，Hudson，bamboo
7.微服務易于被一個開發人員了解，修改和維護，這樣小團隊能夠更關注自己的工作果，無需通過合作才能提現價值
8.微服務隻允許你利用融合最新技術
9.微服務隻是業務邏輯的代碼，不會和HTML,CSS或其他界面元件混合
10.每個微服務都有自己的存儲能力，可以有自己的資料庫，也可以有統一的資料庫
- 缺點
- 開發人員要處理分布式系統的複雜性
- 多服務運維難度，随着服務的增加，運維的壓力也增大
- 系統部署依賴
- 服務間通信的成本
- 資料一緻性問題
- 系統內建測試變得複雜
- 性能監控變得複雜
4.微服務技術棧有哪些
技術棧：多種技術的集合體
| 微服務條目 | 相關的技術 |
|---|---|
| 服務開發 | Spring，SpringBoot，SpringMVC |
| 服務配置與管理 | 阿裡的Diamond，Netflix公司的Archaius等 |
| 服務注冊與發現 | Eureka，Consul，Zookeeper等 |
| 服務調用 | Rest，RPC，gRPC |
| 服務熔斷器 | Hystrix，Envoy等 |
| 負載均衡 | Ribbon，Nginx等 |
| 服務接口調用（用戶端調用服務的簡化工具） | Feign |
| 消息隊列 | RabbitMQ，Kafka，ActiveMQ等 |
| 服務配置中心管理 | SpringCloudConfig，Chef等 |
| 服務路由（api網關） | Zuul等 |
| 服務監控 | Zabbix，Nagios，Metrics，Spectator等 |
| 全鍊路監控 | Zipkin，Brave，Dapper等 |
| 服務部署 | Docker，OpenStack，Kubernetes等 |
| 資料流操作開發包 | SpringCloudStream（封裝與redis，rabbit，kafka等發送接收消息） |
| 事件消息總線 | SpringCloudBus |
5.什麼是SpringCloud
- SpringCloud是微服務架構下的一站式解決方案，是各個微服務架構落地技術的集合體，俗稱微服務全家桶
-
SpringCloud和SpringBoot是什麼關系呢？
SpringBoot專注于快速友善的開發單個個體微服務
SpringCloud是關注全局的微服務協調整理治理架構，它将SpringBoot開發的一個個單體微服務整合并管理起來，為各個微服務之間提供，配置管理，服務發現，斷路器，路由，微代理，事件總線，全局鎖，決策競選，分布式會話等等內建服務。
SpringBoot可以離開SpringCloud獨立使用開發項目，但是SpringCloud離不開SpringBoot，屬于依賴關系。
6.springcloud 和 springboot是什麼關系
SpringBoot專注于快速友善的開發單個個體微服務。
SpringCloud是關注全局的微服務協調整理治理架構，它将SpringBoot開發的一個個單體微服務整合并管理起來，
為各個微服務之間提供，配置管理、服務發現、斷路器、路由、微代理、事件總線、全局鎖、決策競選、分布式會話等等內建服務
SpringBoot可以離開SpringCloud獨立使用開發項目，但是SpringCloud離不開SpringBoot，屬于依賴的關系.
SpringBoot專注于快速、友善的開發單個微服務個體，SpringCloud關注全局的服務治理架構。
7.Dubbo 是怎麼到SpringCloud的？都有哪些優缺點。
（1）.Dubbo VS SpringCloud 技術對比。
| Dubbo | SpringCloud | |
|---|---|---|
| 服務注冊中心 | Zookeeper | Eureka |
| 調用方式 | RPC | REST API |
| 服務監控 | Dubbo-monitor | Spring Boot Admin |
| 斷路器 | 不完善 | SpringCloud Netflix Hystrix |
| 服務網關 | 無 | SpringCloud Netflix Zuul |
| 分布式配置 | 無 | SpringCloud Config |
| 服務跟蹤 | 無 | SpringCloud Sleuth |
| 消息總線 | 無 | SpringCloud Bus |
| 資料流 | 無 | SpringCloud Stream |
| 批量任務 | 無 | SpringCloud Task |
| … | … | … |
最大差別：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源碼+周邊的一整套解決方案，并不是每一個公司都有阿裡的大牛+真實的線上生産環境測試過。
備注：SpringCloud學習書籍
官網
API說明
springcloud中文網
springcloud中國社群