微服務概述

微服務架構4個核心問題：

服務很多，用戶端怎麼通路？
這麼多服務，服務之間如何通信？（一般使用RPC或Http）
這麼多服務，如何治理？
服務挂了怎麼辦？

問題原因：網絡不可靠！！

解決方案：

1）spring cloud 生态！

Spring Cloud NetFlix 一站式解決方案
解決通路：api網關，zuul元件
解決通信：Feign — HttpClient ---- Http通信方式，同步，阻塞
解決治理：服務注冊發現Eureka
解決挂了：熔斷機制Hystrix
…

2）Apache Dubbo Zookeeper 半自動，需要整合别人的

解決通路：api沒有，需要第三方，或者自己實作
解決通信：Dubbo ---- RPC通信
解決治理：服務注冊發現Zookeeper
解決挂了：沒有，需要第三方，借助Hystrix

3）Spring Cloud Alibaba 一站式解決方案，更加簡單了

新概念：服務網格 Service Mesh

一、什麼是微服務

微服務（Microservice Architecture）是最近幾年流行的一種架構思想，關于它的概念很難一言以蔽之。

究竟什麼是微服務呢？我們在此引用 ThoughtWorks 公司的首席科學家 Martin Fowler 于2014年提出的一段話：

- 原文：https://martinfowler.com/articles/microservices.html

- 譯文：https://www.cnblogs.com/liuning8023/p/4493156.html

● 就目前而言，對于微服務，業界并沒有一個統一的，标準的定義

● 但通常而言，微服務架構是一種架構模式，或者說是一種架構風格，它提倡将單一的應用程式分成一組小的服務，每個服務運作在其獨立的自己的程序内，服務之間互相協調，互相配置，為使用者提供最終價值。服務之間采用輕量級的通信機制互相溝通，每個服務都圍繞着具體的業務進行建構，并且能夠被獨立的部署到生産環境中，另外，應盡量避免統一的，集中式的服務管理機制，對具體的一個服務而言，應根據業務上下文，選擇合适的語言，工具對其進行建構，可以有一個非常輕量級的集中式管理來協調這些業務，也可以使用不同的語言來編寫服務，也可以使用不用的資料存儲。

從技術次元來了解：

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

二、微服務與服務架構

● 微服務

強調的是服務的大小，它關注的是某一個點，是具體解決某一個問題/提供落地對應服務的一個服務應用，狹義的看，可以看做是IDEA中的一個個微服務工程，或者Moudel。

① IDEA 工具裡面使用 Maven 開發的一個個獨立的小 Moudel ，它具體是使用 SpringBoot 開發的一個個小子產品，專業的事交給專業的子產品來做，一個子產品就做着一件事。

② 強調的是一個個的個體，每個個體完成一個具體的任務或者功能！

● 服務架構

一種新的架構形式，Martin Fowler，2014年推出

微服務架構是一種架構模式，它提倡将單一的應用程式分成一組小的服務，服務之間互相協調，互相配置，為使用者提供最終價值。每個服務運作在其獨立的自己的程序内，服務之間采用輕量級的通信機制互相溝通，每個服務都圍繞着具體的業務進行建構，并且能夠被獨立的部署到生産環境中，另外，應盡量避免統一的，集中式的服務管理機制，對具體的一個服務而言，應根據業務上下文，選擇合适的語言，工具對其進行建構。

三、微服務優缺點

● 優點：

1）單一職責原則
 2）每個服務足夠内聚，足夠小，代碼容易了解，這樣能聚焦一個指定的業務員功能或業務需求
 3）開發簡單，開發效率提高，一個服務可能就是專一的隻幹一件事
 4）微服務能夠被小團隊單獨開發，這個小團隊是2-5人的開發人員組成
 5）微服務是松耦合的，是有功能意義的服務，無論是在開發階段或者部署階段都是獨立的
 6）微服務能使用不同的語言開發
 7）易于和第三方內建，微服務允許容易且靈活的方式內建自動部署，通過持續內建工具，如 jenkins、hudson，bamboo
 8）微服務易于被一個開發人員了解，修改和維護，這樣小團隊能夠更關注自己的工作成果。無需通過合作才能展現價值
 9）微服務允許你利用融合最新技術
10）微服務隻是業務邏輯的代碼，不會和 HTML、CSS 或其它界面混合
11）每個微服務都有自己的存儲能力，可以有自己的資料庫，也可以有統一的資料庫

● 缺點：

1）開發人員要處理分布式系統的複雜性
 2）多服務運維難度，随着服務的增加，運維的壓力也在增大
 3）服務部署依賴
 4）服務間通信成本
 5）資料一緻性
 6）系統內建測試
 7）性能監控...

四、微服務技術棧

五、為什麼選擇 SpringCloud 作為微服務架構

● 選型依據

1）整體解決方案和架構成熟度
 2）社群熱度
 3）可維護性
 4）學習曲線

● 目前各大IT公司使用的微服務架構

1）阿裡：Dubbo + HFS
 2）京東：JSF
 3）新浪：Motan
 4）當當網：DoubboX
 n）...

● 各位服務架構對比

功能點 / 服務架構	Netflix / SpringCloud	Motan	gRPC	Thrift	Doubbo / DoubboX
功能定位	完整的微服務架構	RPC架構，但整合了ZK或Consul，實作叢集環境的基本服務注冊/發現	RPC架構		服務架構
支援Rest	是，Ribbon支援多種可拔插的序列化選擇	否
支援PRC		是（Hession2）	是
支援多語言	是（Rest形式）？
負載均衡	是（微服務zuul+用戶端Ribbon）， zuul-服務，動态路由，雲端負載均衡Eureka（針對中間層伺服器）	是（用戶端）
配置服務	Netflix Archaius SpringCloud Config Server集中配置	是（Zookeeper提供）
服務調用鍊監控	是（zuul），zuul提供邊緣服務，API網關
高可用/容錯	是（服務端Hystrix+用戶端Ribbon）
典型應用案例	Netflix	Sina	Google	Facebook
社群活躍度	高	一般			2017年後重新開始維護，之前中斷了五年
學習難度	中斷	低
文檔豐富程度
其它	SpringCloud Bus為我們的應用程式帶來了更多管理端點	支援降級	Netflix内部在開發內建gRPC	IDL定義	實踐的公司比較多