摘要：微服務(wù)簡介微服務(wù)架構(gòu)是一種架構(gòu)概念，旨在通過將功能分解到各個離散的服務(wù)中以實現(xiàn)對解決方案的解耦。每個微服務(wù)僅關(guān)注于完成一件任務(wù)并很好地完成該任務(wù)。服務(wù)異常自動隔離。微服務(wù)架構(gòu)挑戰(zhàn)服務(wù)規(guī)模大，部署運維管理難度大。

微服務(wù)架構(gòu)（Microservice Architecture）是一種架構(gòu)概念，旨在通過將功能分解到各個離散的服務(wù)中以實現(xiàn)對解決方案的解耦。

微服務(wù)是一種架構(gòu)風(fēng)格，一個大型復(fù)雜軟件應(yīng)用由一個或多個微服務(wù)組成。系統(tǒng)中的各個微服務(wù)可被獨立部署，各個微服務(wù)之間是松耦合的。每個微服務(wù)僅關(guān)注于完成一件任務(wù)并很好地完成該任務(wù)。在所有情況下，每個任務(wù)代表著一個小的業(yè)務(wù)能力。

單體應(yīng)用 就是將所有的業(yè)務(wù)場景的表示層、業(yè)務(wù)邏輯層和數(shù)據(jù)訪問層放在一個工程中。最終經(jīng)過編譯、打包，部署在一臺服務(wù)器上。典型例子是j2ee的war包或ear包。

在應(yīng)用的初始階段，單體架構(gòu)無論是在開發(fā)速度、運維難度上，還是服務(wù)器的成本上都有著顯著的優(yōu)勢。在一個產(chǎn)品的前景不明確的初始階段，用單體架構(gòu)是非常明智的選擇。隨著應(yīng)用業(yè)務(wù)的發(fā)展和業(yè)務(wù)復(fù)雜度的提高，這種架構(gòu)明顯存在很多的不足，主要體現(xiàn)在以下3個方面。

缺點：

隨著業(yè)務(wù)擴張，開發(fā)難度加大，動一發(fā)而遷全身，代碼的可讀性、可維護(hù)性和可擴展性下降，業(yè)務(wù)擴展帶來的代價越來越大，開發(fā)都在同一個項目改代碼，相互等待，沖突不斷。

部署啟動時間較長，期間服務(wù)會中斷，模塊間相互影響較多，測試難難度加大，一個微小的問題，都可能導(dǎo)致整個應(yīng)用掛掉。

性能容量有限，無法滿足高并發(fā)下的業(yè)務(wù)需求，受單機限制（縱向擴展），有性能瓶頸。

隨著業(yè)務(wù)的發(fā)展，大多數(shù)公司會將單體應(yīng)用進(jìn)行集群部署，并增加負(fù)載均衡服務(wù)器（例如Nginx、F5等），以應(yīng)對用戶量的增加而帶來的高并發(fā)訪問量。此時的系統(tǒng)架構(gòu)如圖1-3所示。

優(yōu)化策略：

負(fù)載均衡，通過分發(fā)服務(wù)器，將用戶的訪問分派到不同的應(yīng)用服務(wù)器，應(yīng)用服務(wù)器的負(fù)載不再成為瓶頸，用戶量增加時，添加應(yīng)用服務(wù)器即可。

添加緩存，使用緩存服務(wù)器來緩解數(shù)據(jù)庫的數(shù)據(jù)以及數(shù)據(jù)庫讀取數(shù)據(jù)的壓力。大多數(shù)的讀取操作是由緩存完成的，但是仍然有少數(shù)讀操作是從數(shù)據(jù)庫讀取。

讀寫分離，當(dāng)有大量的讀寫操作時，將數(shù)據(jù)庫進(jìn)行讀寫分離是一個不錯的選擇，例如MySQL的主從熱備份，通過相關(guān)配置可以將主數(shù)據(jù)庫服務(wù)器的數(shù)據(jù)同步到從數(shù)據(jù)庫服務(wù)器，實現(xiàn)數(shù)據(jù)庫的讀寫分離，讀寫分離能夠改善數(shù)據(jù)庫的負(fù)載能力。

分區(qū)分庫分表，將數(shù)據(jù)量較大的表水平或垂直切分，分散到不同的庫或主機上，分散數(shù)據(jù)庫的壓力，提高性能。

應(yīng)用拆分，將較重要或訪問量較大的功能模塊拆分出來作為新應(yīng)用多帶帶開發(fā)、運維。新應(yīng)用與老應(yīng)用間的相關(guān)依賴通過接口調(diào)用或其它方式交互。

集群有一定的處理高并發(fā)的能力，也能應(yīng)對一定復(fù)雜的業(yè)務(wù)需求，改善了系統(tǒng)的性能，但是依然沒有改變系統(tǒng)為單體架構(gòu)的事實，此時存在的不足之處如下。

缺點：

并發(fā)容量雖有提高，但有限。雖做一定的應(yīng)用拆分后，一定程度上可以緩解單體應(yīng)用的問題。但隨著服務(wù)拆分越來越多，開發(fā)、部署、運維、管理難度也越來越大。

持續(xù)交付能力差，業(yè)務(wù)越復(fù)雜，代碼越多，修改代碼和添加代碼所需的時間越長。新人熟悉代碼的時間長、成本高。

子應(yīng)用間依賴耦合較緊，重復(fù)功能建設(shè)，重復(fù)代碼等，服務(wù)間通信沒有標(biāo)準(zhǔn)等。

“微服務(wù)”最初是由Martin Fowler 在2014年寫的一篇文章《MicroServices》中提出來的。關(guān)于Martin Fowler的介紹

Martin Fowler是國際著名的OO專家，敏捷開發(fā)方法的創(chuàng)始人之一，現(xiàn)為ThoughtWorks公司的首
席科學(xué)家。在面向?qū)ο蠓治鲈O(shè)計、UML、模式、軟件開發(fā)方法學(xué)、XP、重構(gòu)等方面，都是世界頂級的
專家，現(xiàn)為Thought Works公司的首席科學(xué)家。Thought Works是一家從事企業(yè)應(yīng)用開發(fā)和——集
成的公司。早在20世紀(jì)80年代，F(xiàn)owler就是使用對象技術(shù)構(gòu)建多層企業(yè)應(yīng)用的倡導(dǎo)者，他著有幾
本經(jīng)典書籍： 《企業(yè)應(yīng)用架構(gòu)模式》、《UML精粹》和《重構(gòu)》等。

相對于大規(guī)模的集群，微服務(wù)帶來了質(zhì)的飛越，不僅僅是服務(wù)拆分，微服務(wù)是一整套的服務(wù)治理的架構(gòu)，具備整套的設(shè)施。

特性：

每個服務(wù)為獨立的業(yè)務(wù)開發(fā)，多帶帶部署，跑在自己的進(jìn)程中。

自動化測試、部署、運維（ DevOps ）。

快速演化、快速迭代。

整個業(yè)務(wù)由一系列的獨立的服務(wù)共同組成系統(tǒng)。

高度容錯性、高可用、高并發(fā)。

具備能力：

注冊中心：應(yīng)用啟動自動注冊，調(diào)用方自動發(fā)現(xiàn)上線應(yīng)用。服務(wù)異常自動隔離。

配置中心：多環(huán)境配置管理，支持在線管理配置信息，客戶端實時生效。支持版本管理，快速回滾。

消息中心：服務(wù)間異步通信的總線。

負(fù)載均衡：服務(wù)調(diào)用服務(wù)會采用一定的分發(fā)策略，一般是客戶端分發(fā)策略。

服務(wù)間通信：使用http或RPC協(xié)議進(jìn)行服務(wù)調(diào)用，REST、gRPC、Thrift、hession等

服務(wù)降級、熔斷、重試：降級，服務(wù)或依賴服務(wù)異常時，返回保底數(shù)據(jù)。熔斷，若依賴服務(wù)多次失效，則斷開，不再嘗試調(diào)用，直接返回降級值。重試，熔斷后，定期探測依賴服務(wù)可用性，若恢復(fù)則恢復(fù)調(diào)用。

服務(wù)發(fā)布與回滾：紅綠部署、灰度、AB Test等發(fā)布策略，可快速回滾應(yīng)用。

服務(wù)動態(tài)伸縮、容器化：根據(jù)服務(wù)負(fù)載情況，可快速手動或自動進(jìn)行節(jié)點增加和減少。

服務(wù)監(jiān)控與告警：服務(wù)定期健康檢察、指標(biāo)統(tǒng)計、異常告警通知運維。

請求緩存與合并：服務(wù)間調(diào)用相同請求緩存，類似請求合并成批量請求，減少服務(wù)間通信，提高性能。

服務(wù)網(wǎng)關(guān)：用戶請求過載時進(jìn)行限流、排隊，過載保護(hù)，黑白名單、異常用戶過濾攔截等。

服務(wù)依賴、文檔、Mock Server、版本管理：自動生成接口文檔，接口版本化管理，Mock接口等。

日志收集、追蹤、分析：集中收集各服務(wù)日志匯總，方便排障、問題調(diào)查、應(yīng)用日志分析等。

性能監(jiān)測APM：對各服務(wù)性能進(jìn)行監(jiān)測與分析，為服務(wù)優(yōu)化提供數(shù)據(jù)支持。

以上我整理的微服務(wù)相關(guān)應(yīng)具備的能力，內(nèi)容相當(dāng)?shù)亩啵罱ㄟ@樣一套完善的微服務(wù)平臺，花費的財力和時間都是巨大的。幸好開源界已經(jīng)在各方面有眾多的可選方案。

服務(wù)規(guī)模大，部署、運維、管理難度大。

服務(wù)間調(diào)用關(guān)系復(fù)雜，調(diào)用鏈路長，排障難度大。

服務(wù)間通信成本變大，性能和容錯帶來的挑戰(zhàn)。

服務(wù)間依賴較多，系統(tǒng)集成、測試難度變大。

開發(fā)人員技術(shù)能力挑戰(zhàn)，各服務(wù)間重復(fù)代碼，重復(fù)建設(shè)等。

集群規(guī)模大，功能性能監(jiān)控、告警帶來的挑戰(zhàn)。

大規(guī)模分布式，數(shù)據(jù)一致性帶來的挑戰(zhàn)。

需求和版本協(xié)調(diào)復(fù)雜度大大增加，測試難度也增加。

對基礎(chǔ)架構(gòu)要求大大提高，規(guī)模大幅增加。

SpringCloud是在SpringBoot基礎(chǔ)之上構(gòu)建的快速開發(fā)分布式系統(tǒng)（微服務(wù)）的工具集。
為開發(fā)人員提供了一個開箱即用，快速構(gòu)建微服務(wù)的一些通用組件（例如配置管理，服務(wù)發(fā)現(xiàn)，斷路器，智能路由，消息總線等）。

官網(wǎng)

Dubbo是阿里巴巴公司開源的一個高性能優(yōu)秀的服務(wù)框架，使得應(yīng)用可通過高性能的RPC實現(xiàn)服務(wù)的輸出和輸入功能，可以和Spring框架無縫集成。

官網(wǎng)

Service Mesh 架構(gòu)圖：

Service Mesh 開源項目簡介：

Linkerd（https://github.com/linkerd/li...）：

第一代 Service Mesh，2016 年 1 月 15 日首發(fā)布，業(yè)界第一個 Service Mesh 項目，由 Buoyant 創(chuàng)業(yè)小公司開發(fā)（前 Twitter 工程師），2017 年 7 月 11 日，宣布和 Istio 集成，成為 Istio 的數(shù)據(jù)面板。

Envoy（https://github.com/envoyproxy...）：

第一代 Service Mesh，2016 年 9 月 13 日首發(fā)布，由 Matt Klein 個人開發(fā)（Lyft 工程師），之后默默發(fā)展，版本較穩(wěn)定。

Istio（https://github.com/istio/istio）：

第二代 Service Mesh，2017 年 5 月 24 日首發(fā)布，由 Google、IBM 和 Lyft 聯(lián)合開發(fā)，只支持 Kubernetes 平臺，2017 年 11 月 30 日發(fā)布 0.3 版本，開始支持非 Kubernetes 平臺，之后穩(wěn)定的開發(fā)和發(fā)布。

Conduit（https://github.com/runconduit...）：

第二代 Service Mesh，2017 年 12 月 5 日首發(fā)布，由 Buoyant 公司開發(fā)（借鑒 Istio 整體架構(gòu)，部分進(jìn)行了優(yōu)化），對抗 Istio 壓力山大，也期待 Buoyant 公司的毅力。

nginMesh（https://github.com/nginmesh/n...）：

2017 年 9 月首發(fā)布，由 Nginx 開發(fā)，定位是作為 Istio 的服務(wù)代理，也就是替代 Envoy，思路跟 Linkerd 之前和 Istio 集成很相似，極度低調(diào)，GitHub 上的 star 也只有不到 100。