喝杯咖啡，一起了解一下微服務
通常而言，微服務架構是一種架構模式或者說一種架構風格，它提倡將單一應用程式劃分成一組小的服務，每個服務執行在其獨立的程序中，服務之間互相協調、互相配合，為使用者提供最終的價值。服務之間採用輕量級的通訊機制（通常是基於HTTP的RESTful API）。每個服務都圍繞著具體業務進行構建，並且能夠被獨立地部署到生產環境、類生產環境等。另外，應儘量避免統一的、集中式的服務管理機制，對具體的一個服務而言，應根據業務上下文，選擇合適的語言、工具對其進行構建，可以有一個非常輕量級的集中式管理來協調這些服務，可以使用不同的語言來開發這些服務，也可以使用不同的資料儲存。
1. 微服務是什麼
微服務化的核心就是將傳統的一站式應用，根據業務拆分成一個一個的服務，徹底去掉耦合，每一個微服務提供單個業務功能，一個服務只做一件事。
從技術角度講就是一種小而獨立的處理過程，類似與程序的概念，能夠自行單獨啟動或銷燬，可以擁有自己獨立的資料庫。從理論角度，這裡有篇微服務架構的提出者馬丁福特的論文（本文的圖片也是出自於該作者的文章之中，版權歸原作者所有。）：
論文中提到了微服務和傳統架構的區別，傳統架構（單機系統），一個專案一個工程：比如商品、訂單、交易、庫存等等，統一部署，一個程序。如下圖所示：
微服務架構（分散式系統），各個模組/服務，各自獨立出來，“讓專業的人幹專業的事”，獨立部署。分散式系統中，不同的服務可以使用各自獨立的資料庫。如下圖所示：
2. 微服務的優缺點
優點：
1.每個服務足夠內聚，足夠小，程式碼容易理解。這樣能聚焦一個只當的業務功能或業務需求。
2.開發簡單、開發效率提高，一個服務可能就是專業的只幹一件事
微服務能夠被小團隊單獨開發，這個小團隊可以是2到5人的開發人員組成。
3.微服務是鬆耦合的，是有功能意義的服務，無論是在開發階段或部署階段都是獨立的。
4.微服務能使用不同的語言開發。
5.易於和第三方整合，微服務執行容易且靈活的方式整合自動部署，通過持續整合工具，如Jenkins，Hudson，bamboo。
6.微服務易於被一個開發人員理解、修改和維護，這樣小團隊能夠更關注自己的工作成果，無需通過合作才能體現價值。
7.微服務允許你利用融合最新技術。
微服務只是業務邏輯的程式碼，不會和HTML/CSS或其他介面元件混合，即前後端分離。
8.每個微服務都有自己的儲存能力，可以有自己的資料庫，也可以有統一資料庫。
缺點
開發人員要處理分散式系統的複雜性。
3. 微服務的技術棧
微服務的技術棧都有哪些呢？
| 微服務條目 | 落地技術 |
|---|---|
| 服務開發 | SpringBoot、Spring、SpringMVC |
| 服務配置與管理 | Netfllix公司的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等傳送接收訊息） |
| 事件訊息匯流排 | SpringCloud Bus |
| …… | …… |
4. 為什麼選擇SpringCloud
當前微服務架構，Dubbo和SpringCloud比較火，另外還有Thrift、gRPC等等，下面把這些做一個比較，即可看出SpringCloud的強大之處。
| 框架 | SpringCloud | Dubbo/DubboX | gRPC | Thrift | Motan |
|---|---|---|---|---|---|
| 功能定位 | 完整的微服務框架 | 服務框架 | RPC框架 | RPC框架 | RPC框架，但整合了Zookeeper或Consul（有耦合），實現叢集環境的基本的服務註冊與發現 |
| 支援REST | 是，Ribbon支援多種可插拔的序列化選擇 | 否 | 否 | 否 | 否 |
| 支援RPC | 否 | 是 | 是 | 是 | 是 |
| 支援多語言 | 是（REST形式） | 否 | 是 | 是 | 否 |
| 服務註冊與發現 | 是（Eureka） | 是 | 否 | 否 | 是（Zookeeper/Consul） |
| 負載均衡 | 是（服務端Zuul+客戶端Ribbon）Zuul-服務，動態路由 雲端負載均衡 Eureka（針對中間層伺服器） | 是（客戶端） | 否 | 否 | 是（客戶端） |
| 配置服務 | Netflix Archaius SpringCloud Server集中配置 | 否 | 否 | 否 | 是（Zookeeper提供） |
| 服務呼叫鏈監控 | 是（Zuul） Zuul提供邊緣服務，API閘道器 | 否 | 否 | 否 | 否 |
| 高可用/容錯 | 是（服務端Hystrix+客戶端Ribbon） | 是（客戶端） | 否 | 否 | 是（客戶端） |
| 典型應用案例 | Netflix | alibab | Sina | ||
| 社群活躍程度 | 高 | 高 | 高 | 一般 | 一般 |
| 學習難度 | 中等 | 低 | 高 | 高 | 低 |
| 文件豐富度 | 高 | 高 | 一般 | 一般 | 一般 |
| 其他 | SpringCloud Bus為我們應用程式帶來了更多管理端點 | 實踐的公司比較多 | Netflix內部在開發整合gRPC | IDL定義 | 支援降級 |
老技術用Dubbo比較多，新技術一般會選Spring Cloud。Dubbo沉睡了5年，Spring Cloud像獵豹一樣追上來了~可以看出，Spring Cloud現在非常火爆，而且很有競爭力，以後的分散式架構使用Spring Cloud也很廣泛，後面會寫一些使用Spring Cloud的相關部落格。
歡迎關注我的微信公眾號：【程式設計師私房菜】
回覆：“資源”、“架構”等關鍵詞獲取海量免費學習資料。