微服務概念

目錄

• 爲何須要微服務架構
• 什麼是微服務
• 微服務架構和單體架構的比較
• 微服務架構和SOA的比較
• 微服務要點
• 第一代微服務框架
• 服務網格
• 參考

爲何須要微服務架構

傳統IT架構面臨的一些問題：
對於企業：

• 使用傳統的單體應用架構開發系統，如CRM、ERP等大型應用，且須要不斷演變。隨着新需求的不斷增長，更新和維護會變得愈來愈困難。
• 隨着移動互聯網的發展，企業被迫將其應用遷移至現代化UI界面架構以便能兼容移動設備，這要求企業能實現應用功能的快速上線。
• 隨着應用雲化的日益普及，生於雲端的應用具備與傳統IT不一樣的技術基因和開發運維模式。
• 許多企業在SOA投資中獲得的回報有限，SOA能夠經過標準化服務接口實現能力的重用，但對於快速變化的需求，受到總體式應用的限制，有時候顯得力不從心；

對於產品：

• 不少時候，客戶須要的不是一個大而全的平臺，他們但願按他們的意願採購須要的模塊。
• 其它研發團隊或以前項目有一些比較好的組件能知足平臺產品的需求，卻不能直接拿來用。

此外，從技術方面看，雲計算及互聯網公司大量開源輕量級技術不停涌現並日漸成熟：

• 互聯網/內聯網/網絡更加成熟；
• 輕量級運行時技術的出現(node.js, WAS Liberty等)；
• 新的方法與工具(Agile, DevOps, TDD, CI, XP, Puppet, Chef…)；
• 新的輕量級協議(RESTful API接口, 輕量級消息機制)；
• 簡化的基礎設施：操做系統虛擬化(hypervisors), 容器化(e.g. Docker), 基礎設施即服務 (IaaS), - 工做負載虛擬化(Kubernetes,Spark…)等；
• 服務平臺化(PaaS)： 雲服務平臺上具備自動縮放、工做負載管理、SLA 管理、消息機制、緩存、構建管理等各類按需使用的服務；
• 新的可替代數據持久化模型：如NoSQL, MapReduce, BASE, CQRS等；
• 標準化代碼管理：如Github等。

這一切都催生了新的架構設計風格 – 微服務架構的出現。

什麼是微服務

參考2014年3月Martin Fowler關於微服務架構的文章。微服務架構是一種架構模式，它提倡將單一應用程序劃分紅一組小的服務，服務之間互相協調、互相配合，爲用戶提供最終價值。每一個服務運行在其獨立的進程中，服務與服務間採用輕量級的通訊機制互相協做（一般是基於HTTP協議的Restful API）。每一個服務都圍繞着具體業務進行構建，並使用自動化佈署工具進行獨立的發佈。能夠有一個很是輕量級的集中式管理來協調這些服務，可使用不一樣的語言來編寫服務，也可使用不一樣的數據存儲。

In short, the microservice architectural style [1] is an approach to developing a single application as a suite of small services, each running in its own process and communicating with lightweight mechanisms, often an HTTP resource API. These services are built around business capabilities and independently deployable by fully automated deployment machinery. There is a bare minimum of centralized management of these services, which may be written in different programming languages and use different data storage technologies.

微服務架構 ≈ 模塊化開發 + 分佈式計算

通用特性:

• 經過服務實現應用的組件化
• 圍繞業務能力組織服務 每一個微服務僅關注於完成一件任務並很好地完成該任務。每一個任務表明着一個小的業務能力。 因相同緣由而變化的功能聚合到一塊兒，而把因不一樣緣由而變化的功能分離開
• 智能端點與管道扁平化
• 去中心化 使用合適的工具完成各自的任務
• 基礎設施自動化

微服務架構和單體架構的比較

架構	優勢	缺點	適用場景
單體應用	1. 開發簡單直接，集中式管理 2. 功能都在本地，沒有分佈式的管理開銷和調用開銷	1. 隨着項目增大，會帶來開發效率低，代碼維護難，部署不靈活的問題 2. 擴展性不足（橫向的硬件資源擴展和縱向的功能擴展）	小項目，臨時項目
微服務	1. 下降系統複雜度。單體應用分解爲一組服務，每一個服務都比較簡單，只關注於一個業務功能 2. 鬆耦合，服務可獨立開發 3. 跨語言，選擇合適的語言和技術，而且易於重構和升級 4. 服務可獨立部署，使得持續集成和部署成爲可能也是必須 5. 服務可獨立擴展，根據服務特性選擇硬件資源 6. 和 Docker 容器結合的更好	1. 分佈式使服務間的調用，通訊，跟蹤變的複雜 2. 分區的數據庫體系和分佈式事務 3. 服務數量多，系統碎片化。必須考慮到部署，管理問題 4. 跨多個服務的更改須要仔細規劃和協調	大且業務複雜度高的項目， 須要長期演進的項目

微服務架構和SOA的比較

架構	相同點	差別點
SOA	以服務爲核心	SOA更關注企業規模範圍，強調的是異構系統之間的通訊和解耦合。 重ESB 以Web Service/BMP/ESB等技術爲主
微服務	以服務爲核心	微服務架構則更關注應用規模範圍，強調的是系統按業務邊界作細粒度的拆分和部署。 微服務甚至是去ESB、去中心化、分佈式 採用許多新的開源技術和經驗

微服務要點

• 配置管理：將本地化的配置信息（properties, xml, yaml 等）註冊到配置中心，實現程序包在開發、測試、生產環境的無差異性，方便程序包的遷移。
• 服務註冊發現：服務提供方將本身調用地址註冊到服務註冊中心，讓服務調用方可以方便地找到本身。服務調用方從服務註冊中心找到本身須要調用的服務的地址。
• 負載均衡：服務提供方通常以多實例的形式提供服務，負載均衡功能可以讓服務調用方鏈接到合適的服務節點。
• API 網關：服務網關是服務調用的惟一入口，能夠在這個組件是實現用戶鑑權、動態路由、灰度發佈、A/B 測試、負載限流等功能。
• 服務安全
• 集中日誌
• 集中監控
• 分佈式跟蹤
• 服務容錯
• 服務擴展和健康檢查
• 服務發佈部署

第一代微服務框架

• Spring Cloud
  Spring Cloud爲開發者提供了快速構建分佈式系統的通用模型的工具
• Dubbo
  Dubbo是一個阿里巴巴開源出來的一個分佈式服務框架，致力於提供高性能和透明化的RPC遠程服務調用方案，以及SOA服務治理方案。

可是顯而易見，不管是Dubbo仍是Spring Cloud都只適用於特定的應用場景和開發環境，它們的設計目的並非爲了支持通用性和多語言性。而且它們只是Dev層的框架，缺乏DevOps的總體解決方案（這正是微服務架構須要關注的）。

服務網格

2017 年末，非侵入式的 Service Mesh 技術從萌芽到走向了成熟。譯做「服務網格」，做爲服務間通訊的基礎設施層。能夠將它比做是應用程序或者說微服務間的 TCP/IP，負責服務之間的網絡調用、限流、熔斷和監控。

Service Mesh有以下幾個特色：

• 應用程序間通信的中間層
• 輕量級網絡代理
• 應用程序無感知
• 解耦應用程序的重試/超時、監控、追蹤和服務發現

目前流行的Service Mesh開源軟件有Linkerd，Envoy，Istio，Conduit等。

• Linkerd：第一代 Service Mesh，2016 年 1 月 15 日首發布，業界第一個 Service Mesh 項目，由 Buoyant 創業小公司開發（前 Twitter 工程師），2017 年 7 月 11 日，宣佈和 Istio 集成，成爲 Istio 的數據面板。
• Envoy：第一代 Service Mesh，2016 年 9 月 13 日首發布，由 Matt Klein 我的開發（Lyft 工程師），以後默默發展，版本較穩定。
• Istio：第二代 Service Mesh，2017 年 5 月 24 日首發布，由 Google、IBM 和 Lyft 聯合開發，只支持 Kubernetes 平臺，2017 年 11 月 30 日發佈 0.3 版本，開始支持非 Kubernetes 平臺，以後穩定的開發和發佈。
• Conduit：第二代 Service Mesh，2017 年 12 月 5 日首發布，由 Buoyant 公司開發（借鑑 Istio 總體架構，部分進行了優化），對抗 Istio 壓力山大，也期待 Buoyant 公司的毅力。

Linkerd和Envoy比較類似，都是一種面向服務通訊的網絡代理，都可實現諸如服務發現、請求路由、負載均衡等功能。它們的設計目標就是爲了解決服務之間的通訊問題，使得應用對服務通訊無感知，這也是Service Mesh的核心理念。Linkerd和Envoy像是分佈式的Sidebar，多個相似Linkerd和Envoy的proxy互相鏈接，就組成了service mesh。

而Istio則是站在了一個更高的角度，它將Service Mesh分爲了Data Plane和Control Plane。Data Plane負責微服務間的全部網絡通訊，而Control Plane負責管理Data Plane Proxy。Conduit定位和功能與Istio相似。

參考

• 解析微服務架構
• 理解微服務架構的核心
• Spring Cloud vs. Kubernetes
• 從0開始的微服務架構
• 微服務和服務網格概念整理