微服務架構解析(附思維導圖)

思維導圖

介紹

微服務架構（Microservice Architecture）是一種架構概念

旨在通過將功能分解到各個離散的服務中以實現對解決方案的解耦

將功能分解到離散的各個服務當中，從而降低系統的耦合性，並提供更加靈活的服務支持。

傳統開發模式和微服務的區別

優點

• 開發簡單，集中式管理
• 基本不會重複開發
• 功能都在本地，沒有分佈式的管理和調用消耗

缺點

1. 效率低：開發都在同一個項目改代碼，相互等待，衝突不斷
2. 維護難：代碼功功能耦合在一起，新人不知道何從下手
3. 不靈活：構建時間長，任何小修改都要重構整個項目，耗時
4. 穩定性差：一個微小的問題，都可能導致整個應用掛掉
5. 擴展性不夠：無法滿足高併發下的業務需求

微服務架構特徵

官方的定義：

1. 一些列的獨立的服務共同組成系統
2. 單獨部署，跑在自己的進程中
3. 每個服務爲獨立的業務開發
4. 分佈式管理
5. 非常強調隔離性

大概的標準

1. 分佈式服務組成的系統
2. 按照業務，而不是技術來劃分組織
3. 做有生命的產品而不是項目
4. 強服務個體和弱通信（ Smart endpoints and dumb pipes ）
5. 自動化運維（ DevOps ）
6. 高度容錯性
7. 快速演化和迭代

SOA和微服務的區別

• SOA喜歡重用，微服務喜歡重寫
• SOA喜歡水平服務，微服務喜歡垂直服務
• SOA喜歡自上而下，微服務喜歡自下而上

【聲明：轉載請註明出處
獨立：http://wangnan.tech
簡書：http://www.jianshu.com/u/244399b1d776
CSDN:http://blog.csdn.net/wangnan9279】

實踐微服務

客戶端如何訪問這些服務

一般在後臺N個服務和UI之間一般會一個代理或者叫API Gateway

作用：
- 提供統一服務入口，讓微服務對前臺透明
- 聚合後臺的服務，節省流量，提升性能
- 提供安全，過濾，流控等API管理功能

每個服務之間如何通信

• REST（JAX-RS，Spring Boot）
• RPC（Thrift, Dubbo）

服務發現服務註冊

• zookeeper
• dubbo

服務掛了，如何解決

• 重試機制
• 限流
• 熔斷機制
• 負載均衡
• 降級（本地緩存）

參考：Netflix的Hystrix

優缺點

• 優點
  複雜度可控，獨立按需擴展，技術選型靈活，容錯，可用性高
• 缺點
  多服務運維難度，系統部署依賴，服務間通信成本，數據一致性，系統集成測試，重複工作，性能監控等

思考

微服務對我們的思考，更多的是思維上的轉變。對於微服務架構：技術上不是問題，意識比工具重要。

關於微服務的幾點設計出發點：
1. 應用程序的核心是業務邏輯，按照業務或客戶需求組織資源（這是最難的）
2. 做有生命的產品，而不是項目
3. 頭狼戰隊，全棧化
4. 後臺服務貫徹Single Responsibility Principle（單一職責原則）
5. VM->Docker （to PE）
6. DevOps (to PE)

同時，對於開發同學，有這麼多的中間件和強大的PE支持固然是好事，我們也需要深入去了解這些中間件背後的原理，知其然知其所以然，在有限的技術資源如何通過開源技術實施微服務？

最後，一般提到微服務都離不開DevOps和Docker，理解微服務架構是核心，devops和docker是工具，是手段。

參考

http://www.cnblogs.com/imyalost/p/6792724.html?hmsr=toutiao.io&utm_medium=toutiao.io&utm_source=toutiao.io

http://www.jianshu.com/p/77ce2dbd1d6e

http://kb.cnblogs.com/page/520922/

http://www.infoq.com/cn/articles/seven-uservices-antipatterns

http://www.csdn.net/article/2015-08-07/2825412

http://blog.csdn.net/mindfloating/article/details/45740573

http://blog.csdn.net/sunhuiliang85/article/details/52976210

http://www.oschina.net/news/70121/microservice