微服務架構被提出很短的時間内，就被越來越多的開發人員推崇，簡單來說其主要的目的是有效的拆分應用，實作靈活開發和部署。本分享即嘗試介紹微服務架構的一些實施細節和要求，探尋微服務架構的由來，并最終提供我們團隊内部的一些實踐總結，希望對大家有幫助。最後聲明下，不是所有的項目或公司都适合微服務。歡迎閱讀~
一、WHAT - 什麼是微服務
1.1 微服務簡介
這次參加JavaOne2015最大的困難就是聽Microservice相關的session，無論内容多麼水，隻要題目帶microservice，必定報不上名，可見Microservice有多火。最喜歡其中一頁。關于這個典故，可以參考[this](
http://knowyourmeme.com/memes/you-keep-using-that-word-i-do-not-think-it-means-what-you-think-it-means)，此圖适用于一切高大上的名字——技術有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軸将服務按資料分區（分表）
1.2 微服務的具體特征
先看看最官方的定義吧
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老頭的定義大概的翻譯一下就是下面幾條，這個定義還是太抽象是不是，那就對了，就是要務虛，都說明白了誰還找他付費咨詢啊，這麼貴。
- 一些列的獨立的服務共同組成系統
- 單獨部署，跑在自己的程序裡
- 每個服務為獨立的業務開發
- 分布式的管理
Martin自己也說了，每個人對微服務都可以有自己的了解，不過大概的标準還是有一些的。
- 分布式服務組成的系統
- 按照業務而不是技術來劃分組織
- 做有生命的産品而不是項目
- Smart endpoints and dumb pipes（我的了解是強服務個體和弱通信）
- 自動化運維（DevOps）
- 容錯
- 快速演化
關于微服務的更多理論基礎，可以參考康威定律。
1.3 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 - 怎麼具體實踐微服務
聽上去好像都不錯，具體怎麼落地啊？這需要回答下面幾個問題：
- 用戶端如何通路這些服務？
- 服務之間如何通信？
- 這麼多服務，怎麼找?
- 服務挂了怎麼辦？
2.1 用戶端如何通路這些服務？
原來的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。
2.2 服務之間如何通信？
因為所有的微服務都是獨立的Java程序跑在獨立的虛拟機上，是以服務間的通行就是IPC（inter process communication），已經有很多成熟的方案。現在基本最通用的有兩種方式。這幾種方式，展開來講都可以寫本書，而且大家一般都比較熟悉細節了，就不展開講了。
- 同步調用
- REST（JAX-RS）
- RPC（Dubbo）
- 異步消息調用(Kafka, Notify, MetaQ)
一般同步調用比較簡單，一緻性強，但是容易出調用問題，性能體驗上也會差些，特别是調用層次多的時候。RESTful和RPC的比較也是一個很有意思的話題。一般REST基于HTTP，更容易實作，更容易被接受，服務端實作技術也更靈活些，各個語言都能支援，同時能跨用戶端，對用戶端沒有特殊的要求，隻要封裝了HTTP的SDK就能調用，是以相對使用的廣一些。RPC也有自己的優點，傳輸協定更高效，安全更可控，特别在一個公司内部，如果有統一個的開發規範和統一的服務架構時，他的開發效率優勢更明顯些。就看各自的技術積累實際條件，自己的選擇了。
而異步消息的方式在分布式系統中有特别廣泛的應用，他既能減低調用服務之間的耦合，又能成為調用之間的緩沖，確定消息積壓不會沖垮被調用方，同時能保證調用方的服務體驗，繼續幹自己該幹的活，不至于被背景性能拖慢。不過需要付出的代價是一緻性的減弱，需要接受資料最終一緻性；還有就是背景服務一般要實作幂等性，因為消息發送出于性能的考慮一般會有重複（保證消息的被收到且僅收到一次對性能是很大的考驗）；最後就是必須引入一個獨立的broker，如果公司内部沒有技術積累，對broker分布式管理也是一個很大的挑戰。
2.3 這麼多服務，怎麼找?
在微服務架構中，一般每一個服務都是有多個拷貝，來做負載均衡。一個服務随時可能下線，也可能應對臨時通路壓力增加新的服務節點。服務之間如何互相感覺？服務如何管理？這就是服務發現的問題了。一般有兩類做法，也各有優缺點。基本都是通過zookeeper等類似技術做服務注冊資訊的分布式管理。當服務上線時，服務提供者将自己的服務資訊注冊到ZK（或類似架構），并通過心跳維持長連結，實時更新連結資訊。服務調用者通過ZK尋址，根據可定制算法，找到一個服務，還可以将服務資訊緩存在本地以提高性能。當服務下線時，ZK會發通知給服務用戶端。
- 用戶端做：優點是架構簡單，擴充靈活，隻對服務注冊器依賴。缺點是用戶端要維護所有調用服務的位址，有技術難度，一般大公司都有成熟的内部架構支援，比如Dubbo。
- 服務端做：優點是簡單，所有服務對于前台調用方透明，一般在小公司在雲服務上部署的應用采用的比較多。
2.4 這麼多服務，服務挂了怎麼辦？
前面提到，Monolithic方式開發一個很大的風險是，把所有雞蛋放在一個籃子裡，一榮俱榮，一損俱損。而分布式最大的特性就是網絡是不可靠的。通過微服務拆分能降低這個風險，不過如果沒有特别的保障，結局肯定是噩夢。我們剛遇到一個線上故障就是一個很不起眼的SQL計數功能，在通路量上升時，導緻資料庫load彪高，影響了所在應用的性能，進而影響所有調用這個應用服務的前台應用。是以當我們的系統是由一系列的服務調用鍊組成的時候，我們必須確定任一環節出問題都不至于影響整體鍊路。相應的手段有很多：
- 重試機制
- 限流
- 熔斷機制
- 負載均衡
- 降級（本地緩存）
這些方法基本上都很明确通用，就不詳細說明了。比如Netflix的Hystrix：https://github.com/Netflix/Hystrix
2.5 WHY - 微服務的應用
這裡有一個圖非常好的總結微服務架構需要考慮的問題，包括
- API Gateway
- 服務間調用
- 服務發現
- 服務容錯
- 服務部署
- 資料調用
微服務的優點和缺點（或者說挑戰）一樣明顯。
- 優點
- 開發簡單
- 技術棧靈活
- 服務獨立無依賴
- 獨立按需擴充
- 可用性高
- 缺點（挑戰）
- 多服務運維難度
- 系統部署依賴
- 服務間通信成本
- 資料一緻性
- 系統內建測試
- 重複工作
- 性能監控
沒有最好的，隻有适合自己的。
- 對于大的網際網路公司，微服務架構是血液，是習慣，每家公司都有自己的套路和架構，細節有不同，但是核心理念是通的。
- 對于一般的公司而言，實踐微服務有非常大的技術挑戰，于是乎才有了這麼多IT供應商考慮這裡的商機。微服務比較适合未來有一定的擴充複雜度，且有很大使用者增量預期的應用，說人話就是新興的網際網路公司。創業初期，不可能買大量的機器或者很貴的機器，但是又必須考慮應對成功後的巨量的使用者，微服務架構成了最好的選擇。
三、So What - 思考
看到上面的圖，不是不覺得特别的熟悉？其實我們N年前就用的滾瓜爛熟了好不好？褲子都拖了，你就給我看這個？
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是工具，是手段。。
文章來源：https://developer.aliyun.com/article/2764