?

WHAT - 什么是微服務

微服務簡介

這次參加JavaOne2015最大的困難就是聽Microservice相關的session，無論內容多么水，只要題目帶microservice，必定報不上名，可見Microservice有多火。最喜歡其中一頁。關于這個典故，可以參考this，此圖適用于一切高大上的名字——技術有SOA，Agile，CLOUD，DevOps等等，古代有道，氣，八卦等等。此類名詞的最大特點就是?一解釋就懂，一問就不知，一討論就打架。?

微服務的流行，Martin功不可沒，這老頭也是個奇人，特別擅長抽象歸納和制造概念，我覺的這就是最牛逼的markting啊，感覺這也是目前國人欠缺的能力。

Martin Fowler是國際著名的OO專家，敏捷開發方法的創始人之一，現為ThoughtWorks公司的首席科學家.福勒（Martin Fowler），在面向對象分析設計、UML、模式、軟件開發方法學、XP、重構等方面，都是世界頂級的專家，現為Thought Works公司的首席科學家。Thought Works是一家從事企業應用開發和集成的公司。早在20世紀80年代，Fowler就是使用對象技術構建多層企業應用的倡導者，他著有幾本經典書籍： 《企業應用架構模式》、《UML精粹》和《重構》等。—— 百度百科

先來看看傳統的web開發方式，通過對比比較容易理解什么是Microservice Architecture。和Microservice相對應的，這種方式一般被稱為Monolithic（比較難傳神的翻譯）。所有的功能打包在一個 WAR包里，基本沒有外部依賴（除了容器），部署在一個JEE容器（Tomcat，JBoss，WebLogic）里，包含了 DO/DAO，Service，UI等所有邏輯。

Monolithic比較適合小項目，優點是：

• 開發簡單直接，集中式管理

• 基本不會重復開發

• 功能都在本地，沒有分布式的管理開銷和調用開銷

它的缺點也非常明顯，特別對于互聯網公司來說（不一一列舉了）：

• 開發效率低：所有的開發在一個項目改代碼，遞交代碼相互等待，代碼沖突不斷

• 代碼維護難：代碼功能耦合在一起，新人不知道何從下手

• 部署不靈活：構建時間長，任何小修改必須重新構建整個項目，這個過程往往很長

• 穩定性不高：一個微不足道的小問題，可以導致整個應用掛掉

• 擴展性不夠：無法滿足高并發情況下的業務需求

所以，現在主流的設計一般會采用Microservice Architecture，就是基于微服務的架構。簡單來說，?微服務的目的是有效的拆分應用，實現敏捷開發和部署?。

用《The art of scalability》一書里提到的scale cube比較容易理解如何拆分。你看，我們叫分庫分表，別人總結成了scale cube，這就是抽象的能力啊，把復雜的東西用最簡單的概念解釋和總結。X軸代表運行多個負載均衡器之后運行的實例，Y軸代表將應用進一步分解為微服務 （分庫），數據量大時，還可以用Z軸將服務按數據分區（分表）

微服務的具體特征

先看看最官方的定義吧

The microservice architectural style 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.
-- James Lewis and Martin Fowler

把Martin老頭的定義大概的翻譯一下就是下面幾條，這個定義還是太抽象是不是，那就對了，就是要務虛，都說明白了誰還找他付費咨詢啊，這么貴。
1. 一些列的獨立的服務共同組成系統
2. 單獨部署，跑在自己的進程里
3. 每個服務為獨立的業務開發
4. 分布式的管理

Martin自己也說了，每個人對微服務都可以有自己的理解，不過大概的標準還是有一些的。

• 分布式服務組成的系統

• 按照業務而不是技術來劃分組織

• 做有生命的產品而不是項目

• Smart endpoints and dumb pipes（我的理解是強服務個體和弱通信）

• 自動化運維（DevOps）

• 容錯

• 快速演化

SOA vs Microservice

除了Smart endpoints and dumb pipes都很容易理解對嗎？相信很多人都會問一個問題，這是不是就是SOA換了個概念，掛羊頭賣狗肉啊，有說法把Microservice叫成 Lightway SOA。也有很多傳統磚家跳出來說Microservice就是SOA。其實Martin也沒否認SOA和Microservice的關系。

我個人理解，Microservice是SOA的傳承，但一個最本質的區別就在于Smart endpoints and dumb pipes，或者說是真正的分布式的、去中心化的。Smart endpoints and dumb pipes本質就是去ESB，把所有的“思考”邏輯包括路由、消息解析等放在服務內部（Smart endpoints），去掉一個大一統的ESB，服務間輕（dumb pipes）通信，是比SOA更徹底的拆分。

HOW - 怎么具體實踐微服務

聽上去好像都不錯，具體怎么落地啊？這需要回答下面幾個問題：

• 客戶端如何訪問這些服務？

• 服務之間如何通信？

• 這么多服務，怎么找?

• 服務掛了怎么辦？

客戶端如何訪問這些服務？

原來的Monolithic方式開發，所有的服務都是本地的，UI可以直接調用，現在按功能拆分成獨立的服務，跑在獨立的一般都在獨立的虛擬機上的?Java進程了。客戶端UI如何訪問他的？后臺有N個服務，前臺就需要記住管理N個服務，一個服務下線/更新/升級，前臺就要重新部署，這明顯不服務我們 拆分的理念，特別當前臺是移動應用的時候，通常業務變化的節奏更快。另外，N個小服務的調用也是一個不小的網絡開銷。還有一般微服務在系統內部，通常是無 狀態的，用戶登錄信息和權限管理最好有一個統一的地方維護管理（OAuth）。

所以，一般在后臺N個服務和UI之間一般會一個代理或者叫API Gateway，他的作用包括

• 提供統一服務入口，讓微服務對前臺透明

• 聚合后臺的服務，節省流量，提升性能

• 提供安全，過濾，流控等API管理功能

我的理解其實這個API Gateway可以有很多廣義的實現辦法，可以是一個軟硬一體的盒子，也可以是一個簡單的MVC框架，甚至是一個Node.js的服務端。他們最重要的作 用是為前臺（通常是移動應用）提供后臺服務的聚合，提供一個統一的服務出口，解除他們之間的耦合，不過API Gateway也有可能成為單點故障點或者性能的瓶頸。

一般用過Taobao Open Platform的就能很容易的體會，TAO就是這個API Gateway。

服務之間如何通信？

因為所有的微服務都是獨立的Java進程跑在獨立的虛擬機上，所以服務間的通行就是IPC（inter process communication），已經有很多成熟的方案。現在基本最通用的有兩種方式。這幾種方式，展開來講都可以寫本書，而且大家一般都比較熟悉細節了， 就不展開講了。

• 同步調用

  • REST（JAX-RS，spring?Boot）

  • RPC（Thrift, Dubbo）

• 異步消息調用(Kafka, Notify, MetaQ)

一般同步調用比較簡單，一致性強，但是容易出調用問題，性能體驗上也會差些，特別是調用層次多的時候。RESTful和RPC的比較也是一個很有意 思的話題。一般REST基于HTTP，更容易實現，更容易被接受，服務端實現技術也更靈活些，各個語言都能支持，同時能跨客戶端，對客戶端沒有特殊的要 求，只要封裝了HTTP的SDK就能調用，所以相對使用的廣一些。RPC也有自己的優點，傳輸協議更高效，安全更可控，特別在一個公司內部，如果有統一個 的開發規范和統一的服務框架時，他的開發效率優勢更明顯些。就看各自的技術積累實際條件，自己的選擇了。

而異步消息的方式在分布式系統中有特別廣泛的應用，他既能減低調用服務之間的耦合，又能成為調用之間的緩沖，確保消息積壓不會沖垮被調用方，同時能 保證調用方的服務體驗，繼續干自己該干的活，不至于被后臺性能拖慢。不過需要付出的代價是一致性的減弱，需要接受數據最終一致性；還有就是后臺服務一般要 實現冪等性，因為消息發送出于性能的考慮一般會有重復（保證消息的被收到且僅收到一次對性能是很大的考驗）；最后就是必須引入一個獨立的broker，如 果公司內部沒有技術積累，對broker分布式管理也是一個很大的挑戰。

這么多服務，怎么找?

在微服務架構中，一般每一個服務都是有多個拷貝，來做負載均衡。一個服務隨時可能下線，也可能應對臨時訪問壓力增加新的服務節點。服務之間如何相互 感知？服務如何管理？這就是服務發現的問題了。一般有兩類做法，也各有優缺點。基本都是通過zookeeper等類似技術做服務注冊信息的分布式管理。當 服務上線時，服務提供者將自己的服務信息注冊到ZK（或類似框架），并通過心跳維持長鏈接，實時更新鏈接信息。服務調用者通過ZK尋址，根據可定制算法， 找到一個服務，還可以將服務信息緩存在本地以提高性能。當服務下線時，ZK會發通知給服務客戶端。

• 客戶端做：優點是架構簡單，擴展靈活，只對服務注冊器依賴。缺點是客戶端要維護所有調用服務的地址，有技術難度，一般大公司都有成熟的內部框架支持，比如Dubbo。

• 服務端做：優點是簡單，所有服務對于前臺調用方透明，一般在小公司在云服務上部署的應用采用的比較多。

這么多服務，服務掛了怎么辦？

前面提到，Monolithic方式開發一個很大的風險是，把所有雞蛋放在一個籃子里，一榮俱榮，一損俱損。而分布式最大的特性就是網絡是不可靠 的。通過微服務拆分能降低這個風險，不過如果沒有特別的保障，結局肯定是噩夢。我們剛遇到一個線上故障就是一個很不起眼的SQL計數功能，在訪問量上升 時，導致數據庫load彪高，影響了所在應用的性能，從而影響所有調用這個應用服務的前臺應用。所以當我們的系統是由一系列的服務調用鏈組成的時候，我們 必須確保任一環節出問題都不至于影響整體鏈路。相應的手段有很多：

• 重試機制

• 限流

• 熔斷機制

• 負載均衡

• 降級（本地緩存）

這些方法基本上都很明確通用，就不詳細說明了。比如Netflix的Hystrix：https://github.com/Netflix/Hystrix

WHY - 微服務的應用

這里有一個圖非常好的總結微服務架構需要考慮的問題，包括

• API Gateway

• 服務間調用

• 服務發現

• 服務容錯

• 服務部署

• 數據調用

微服務的優點和缺點（或者說挑戰）一樣明顯。

• 優點

  • 開發簡單

  • 技術棧靈活

  • 服務獨立無依賴

  • 獨立按需擴展

  • 可用性高

• 缺點（挑戰）

  • 多服務運維難度

  • 系統部署依賴

  • 服務間通信成本

  • 數據一致性

  • 系統集成測試

  • 重復工作

  • 性能監控

沒有最好的，只有適合自己的。

• 對于大的互聯網公司，微服務架構是血液，是習慣，每家公司都有自己的套路和架構，細節有不同，但是核心理念是通的。

• 對于一般的公司而言，實踐微服務有非常大的技術挑戰，于是乎才有了這么多IT供應商考慮這里的商機。微服務比較適合未來有一定的擴展復雜度，且有 很大用戶增量預期的應用，說人話就是新興的互聯網公司。創業初期，不可能買大量的機器或者很貴的機器，但是又必須考慮應對成功后的巨量的用戶，微服務架構 成了最好的選擇。?

So What - 思考

看到上面的圖，不是不覺得特別的熟悉？其實我們N年前就用的滾瓜爛熟了好不好？褲子都拖了，你就給我看這個？

from:?https://github.com/Netflix/recipes-rss/wiki/Architecture

其實本來所謂的微服務就是對互聯網在應用技術的一個總結歸納，IT廠商鼓吹所有概念無非是為了生意（business），SOA是，Cloud是，Microservice也是。下面玩笑很有意思的概括了這個情況（我加了第一條線，原圖見這里）

所以微服對我們的思考我覺得更多的是思維上的，對已微服務架構，?技術上不是問題，意識比工具重要。

• 按照業務 或者客戶需求組織資源（這是最難的）

• 做有生命的產品，而不是項目

• 頭狼戰隊，全棧化

• 后臺服務貫徹Single Responsibility Principle

• VM->Docker?（to PE）

• DevOps (to PE)

同時，對于開發同學，有這么多的中間件和強大的PE支持固然是好事，我們也需要深入去了解這些中間件背后的原理，知其然知其所以然，設想下，如果我們是一個小公司的CTO，離開的阿里的大環境，在有限的技術資源如何通過開源技術實施微服務？

最后，一般提到微服務都離不開DevOps和Docker，理解微服務架構是核心，devops和docker是工具，是手段。下次在抽時間再學習整理下。

參考資料和推薦閱讀

• http://www.infoq.com/articles/microservices-intro

• http://martinfowler.com/articles/microservices.html

• http://martinfowler.com/microservices/

• http://highscalability.com/blog/2014/4/8/microservices-not-a-free-lunch.html

• https://www.nginx.com/blog/introduction-to-microservices/

• http://microservices.io/patterns/microservices.html

• http://www.infoq.com/presentations/migration-cloud-native

• https://github.com/Netflix/recipes-rss

• http://www.mattstine.com/microservices

文章來自阿里巴巴技術協會（ATA）精選集，原文首發于阿里云棲社區：http://yq.aliyun.com/articles/2764?。云棲社區是由阿里云負責運營、阿里巴巴技術協會和阿里巴巴集團各技術團隊提供內容支持的開放式技術社區：http://yq.aliyun.com。

本站文章除注明轉載外，均為本站原創或編譯。歡迎任何形式的轉載，但請務必注明出處，尊重他人勞動共創開源社區。

轉載請注明：文章轉載自 開源中國社區?[http://www.oschina.net]

本文標題：微服務（Microservice）那點事

本文地址：https://www.oschina.net/news/70121/microservice

總結

以上是生活随笔為你收集整理的微服务（Microservice）那点事的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。