一、前言
為了實(shí)現(xiàn)基于微服務(wù)開發(fā)的產(chǎn)品，或者說為了將單體應(yīng)用重構(gòu)為微服務(wù)架構(gòu)時(shí)，將面臨著眾多技術(shù)框架的選擇。大公司往往會有專門的部門或團(tuán)隊(duì)來負(fù)責(zé)自主研發(fā)自己的框架，以滿足產(chǎn)品的需要，但是對于一般的中小型企業(yè)，選擇合適的開源框架就顯得更接地氣了。本章將簡單介紹微服務(wù)中，在技術(shù)選型時(shí)需要注意哪些原則，一些常用的開源技術(shù)框架，希望能夠?yàn)榇蠹以谶M(jìn)行技術(shù)選型、調(diào)研時(shí)提供一些思路方向。
筆者面試過很多程序員，一提及微服務(wù)，就會具體說道Spring Boot、Spring Cloud，然后就是“背誦”各種具體的用法和配置文件。并不是說這樣不對，但我們更希望知道的是這些技術(shù)框架的原理，為什么選擇它，它與其他類似框架又有何不同呢。
至于一個(gè)技術(shù)框架該怎么用，它適用于什么場景，筆者建議可以直接閱讀官方或?qū)?yīng)的github上的文檔，有需要時(shí)還可以閱讀下關(guān)注點(diǎn)的源碼，這樣對正確的理解它，是很有必要的，畢竟官方發(fā)布的東西是相對權(quán)威的，其他地方的資料或許存在片面性，對大家的使用、理解存在一定的誤導(dǎo)。(這只是筆者對大家在技術(shù)選型時(shí)，查閱資料的一些建議)
二、選型原則
在軟件開發(fā)領(lǐng)域，幾乎每天都有新的技術(shù)框架誕生、更新，一些新的概念更是層出不窮，技術(shù)選型時(shí)，難免讓人無從抉擇。 對于技術(shù)選型，我個(gè)人有以下幾點(diǎn)建議：
1.有需求，再引入
在微服務(wù)架構(gòu)中，各類組件/技術(shù)很多很多，但并不意味著所有的都應(yīng)該引入你的項(xiàng)目，倘若單純?yōu)榱烁采w全技術(shù)?；蚪M件而全部引入，這將是一種很不明智的選擇。后續(xù)將會成為你項(xiàng)目的累贅，讓你苦不堪言。
只要你記住這六個(gè)字：“有需求，再引入”，就OK了。伴隨著項(xiàng)目體系架構(gòu)的完善、功能的健全，當(dāng)有某方面的需求時(shí)，在逐步考慮是否引入某些技術(shù)組件。
2.選擇最熟悉、使用最多的技術(shù)
“一個(gè)新項(xiàng)目里最好不要使用超過30%的新技術(shù)”，我覺得這句話是有一定道理的。對于你完全不知道、不了解的技術(shù)，你是無法預(yù)估、掌控在使用過程中會出現(xiàn)的任何風(fēng)險(xiǎn)，一旦出現(xiàn)問題，短時(shí)間內(nèi)解決不了，你將會變得很難堪。
在這里不是說拒絕使用、接觸新技術(shù)，新技術(shù)是值得大家去追捧、了解、學(xué)習(xí)，一些新技術(shù)在很大程度上能給我們帶來前所未有的利處，解決其他技術(shù)框架解決不了的問題。這里所說的“新技術(shù)”，是指沒有經(jīng)過充分的考察、技術(shù)驗(yàn)證、存在種種疑惑的技術(shù)，而是一味的拿來主義，這樣的風(fēng)險(xiǎn)可想而知。
確保選擇的技術(shù)，是業(yè)界使用最多的、被大家認(rèn)可的技術(shù)，即使出現(xiàn)了問題，也能應(yīng)對自如。至少在團(tuán)隊(duì)內(nèi)部小范圍是非常認(rèn)可的。
3.強(qiáng)大社區(qū)支撐的技術(shù)
GitHub上star的數(shù)量是一個(gè)重要指標(biāo)，同時(shí)參考近年來代碼、文檔、issues等更新頻率，各大技術(shù)博客是否有相關(guān)技術(shù)分享記載，這些都是能夠說明該技術(shù)是否活躍、受歡迎程度、使用人群多少等。
語言 方法
3126 F4v5f3Ck8d
rp4Ba
mcn機(jī)構(gòu)是什么意思4171 2005-05-08 20:37:22
擁有強(qiáng)大社區(qū)支持的技術(shù)，在選型后，倘若使用出現(xiàn)疑問、問題、bug等，能夠有地方可提、可修復(fù)、可深究探討，畢竟現(xiàn)在的技術(shù)社區(qū)都是足夠開放的。
慎選個(gè)人開源的技術(shù)框架、組件等，里面到底有多少坑，沒幾個(gè)人能說清楚的，況且說不定哪天就不復(fù)存在了呢。
4.從業(yè)務(wù)、項(xiàng)目規(guī)模出發(fā)
任何技術(shù)的出發(fā)點(diǎn)都是為最終業(yè)務(wù)而服務(wù)的，不同業(yè)務(wù)、不同項(xiàng)目規(guī)模，對技術(shù)的要求指標(biāo)都是不同的。處于初創(chuàng)期的業(yè)務(wù)，選型的基準(zhǔn)是相對靈活，畢竟業(yè)務(wù)相對簡單，支撐業(yè)務(wù)不是很大，只要夠用、開發(fā)效率足夠高就好。處于復(fù)雜業(yè)務(wù)而重構(gòu)的項(xiàng)目，選型就需謹(jǐn)慎，往往伴隨著一些復(fù)雜需求誕生、規(guī)模大小的不確定性，不得不考慮選型技術(shù)可能伴隨著一些小修小補(bǔ)或者螺旋式上升的重構(gòu)，則需選型便于適配、切換、替換，耦合度低的技術(shù)。
正因?yàn)榧夹g(shù)選型和業(yè)務(wù)相關(guān)，我們能夠觀察到一些很明顯的現(xiàn)象：新技術(shù)往往被早期創(chuàng)業(yè)團(tuán)隊(duì)或大公司的新興業(yè)務(wù)使用；中大型公司的核心業(yè)務(wù)則更傾向于用一些穩(wěn)定了幾年的技術(shù)；一個(gè)公司如果長期使用一種技術(shù)，就會傾向于一直使用下去，甚至連版本都不更新的使用下去。
學(xué)會從業(yè)務(wù)端思考。首先我們需要充分地理解業(yè)務(wù)，理解用戶需求，理解當(dāng)下需要解決的首要問題，以及可能的風(fēng)險(xiǎn)有哪些，再將目標(biāo)進(jìn)行分解，進(jìn)行具體的技術(shù)選型、模型設(shè)計(jì)、架構(gòu)設(shè)計(jì)。
5.先驗(yàn)證后使用
對于未經(jīng)驗(yàn)證的新技術(shù)、新理念的引入一定要慎重，一定要在全方位的驗(yàn)證過后，再大規(guī)模的使用，最終確定選型。新技術(shù)、新理念的出現(xiàn)，自然有它的誘惑，慎重并不代表保守，技術(shù)總是在不斷前進(jìn)，擁抱變化本身沒有問題，但是引入不成熟的技術(shù)看似能帶來短期的收益，但是它的風(fēng)險(xiǎn)或者是后期的成本可能遠(yuǎn)遠(yuǎn)大于收益。
驗(yàn)證后，才有說服力，用著更放心。
三、技術(shù)選型
每種技術(shù)架構(gòu)都有其優(yōu)缺點(diǎn),存在即合理,不同的業(yè)務(wù)場景使用不同的應(yīng)用架構(gòu)，技術(shù)框架，不一定說最新的架構(gòu)、技術(shù)就是最適合你的。
微服務(wù)架構(gòu)中常提及到的主要技術(shù)框架選型如下表所示，本文后面將基于此展開說明對比。
類型 框架
服務(wù)治理 Dubbo、Spring Cloud
API網(wǎng)關(guān) Zuul、traefik、OpenResty、Kong
服務(wù)注冊與發(fā)現(xiàn) Zookeeper、Eureka、Consul、etcd
配置中心 Spring Cloud Config、Apollo、Nacos
鏈路追蹤、監(jiān)控 Zipkin、CAT
四、服務(wù)治理
1.Dubbo
Dubbo是一款高性能、輕量級的開源JAVA RPC框架，以及SOA服務(wù)治理方案。簡單的說，Dubbo就是個(gè)服務(wù)框架，說白了就是個(gè)遠(yuǎn)程服務(wù)調(diào)用的分布式框架。它提供了三大核心能力：面向接口的遠(yuǎn)程方法調(diào)用、智能容錯(cuò)和負(fù)載均衡、以及服務(wù)自動注冊和發(fā)現(xiàn)，很容易和Spring框架無縫集成。
Dubbo邏輯架構(gòu)如下圖所示：
Provider：暴露服務(wù)的提供方，可以通過jar或者容器的方式啟動服務(wù)。
Consumer：調(diào)用遠(yuǎn)程服務(wù)的服務(wù)消費(fèi)方。
Registry：服務(wù)注冊中心和發(fā)現(xiàn)中心。
Monitor：統(tǒng)計(jì)服務(wù)和調(diào)用次數(shù)，調(diào)用時(shí)間監(jiān)控中心。（dubbo的控制臺頁面中可以顯示，目前只有一個(gè)簡單版本）
Container：服務(wù)運(yùn)行的容器。
Dubbo特點(diǎn)：
遠(yuǎn)程通訊: 提供對多種基于長連接的NIO框架抽象封裝（非阻塞I/O的通信方式，Mina/Netty/Grizzly），包括多種線程模型，序列化（Hessian2/ProtoBuf），以及“請求-響應(yīng)”模式的信息交換方式。
集群容錯(cuò): 提供基于接口方法的透明遠(yuǎn)程過程調(diào)用（RPC），包括多協(xié)議支持（自定義RPC協(xié)議），以及軟負(fù)載均衡（Random/RoundRobin），失敗容錯(cuò)（Failover/Failback），地址路由，動態(tài)配置等集群支持。
自動發(fā)現(xiàn): 基于注冊中心目錄服務(wù)，使服務(wù)消費(fèi)方能動態(tài)的查找服務(wù)提供方，使地址透明，使服務(wù)提供方可以平滑增加或減少機(jī)器。
在現(xiàn)有的微服務(wù)架構(gòu)下，Dubbo只能說是一個(gè)服務(wù)治理框架，或者說是一個(gè)RPC框架，是以接口為粒度，一個(gè)接口類就就是一個(gè)服務(wù)。如果直接用Dubbo來實(shí)現(xiàn)微服務(wù)架構(gòu)，還缺少以下幾個(gè)功能：
分布式配置：可以使用Spring Cloud Config、Apollo等來實(shí)現(xiàn)。
鏈路追蹤：可以使用Zipkin、CAT等來實(shí)現(xiàn)。
批量任務(wù)：可以使用當(dāng)當(dāng)網(wǎng)開源的Elastic-Job來實(shí)現(xiàn)。
2.Spring Cloud
Spring Cloud是目前最主流的微服務(wù)架構(gòu)落地首選方案之一，是基于Spring Boot實(shí)現(xiàn)的開源框架，是一個(gè)全家桶，是微服務(wù)的整體技術(shù)棧。
Spring Boot是Spring 的一套快速配置腳手架，使用默認(rèn)大于配置的理念，用于快速開發(fā)單個(gè)微服務(wù)。
它為服務(wù)注冊發(fā)現(xiàn)、動態(tài)路由、負(fù)載均衡、配置管理、消息總線、熔斷器、分布式鏈路追蹤、大數(shù)據(jù)操作等提供了簡單的實(shí)現(xiàn)，讓我們可以更簡潔的使用它。
正如我們前面說過的，微服務(wù)是可以獨(dú)立部署、水平擴(kuò)展、獨(dú)立訪問的服務(wù)單元，而Spring Cloud就是這些微服務(wù)的“大管家”，采用了微服務(wù)這種架構(gòu)之后，項(xiàng)目的數(shù)量會非常多，調(diào)用鏈路復(fù)雜，從而管理成了很大的問題，而Spring Cloud框架恰恰提供了各種組件用于管理和治理微服務(wù)。理所應(yīng)當(dāng)?shù)?，就成了大家首選框架了。
Spring Cloud的整體架構(gòu)如下圖所示，提供一站式的微服務(wù)架構(gòu)解決方案。
使用Spring Cloud來構(gòu)建微服務(wù)架構(gòu)可以省去你整合各家技術(shù)的成本，Spring Cloud為我們構(gòu)建微服務(wù)架構(gòu)提供了一站式的解決方案，就好比當(dāng)初Spring誕生是為解決EJB企業(yè)應(yīng)用開發(fā)的眾多問題而提供的一站式輕量級企業(yè)應(yīng)用開發(fā)解決方案一樣，隨著使用Spring Cloud的產(chǎn)品數(shù)量增加，Spring Cloud在微服務(wù)架構(gòu)中已一統(tǒng)江湖。
下面是Spring Cloud的完整技術(shù)棧，看完你就知道它為啥會在微服務(wù)架構(gòu)中一統(tǒng)江湖了。
3.對比、總結(jié)
Dubbo Spring Cloud
功能/專注點(diǎn) 專注于RPC和服務(wù)治理 微服務(wù)架構(gòu)生態(tài)、技術(shù)棧
通信協(xié)議 RPC(遠(yuǎn)程方法調(diào)用)協(xié)議 REST/HTTP（已有組件支持gRPC協(xié)議）
服務(wù)注冊與發(fā)現(xiàn) Zookeeper(CP) Eureka(AP)
負(fù)載均衡 軟負(fù)載均衡（Random/RoundRobin） Ribbon
容錯(cuò)機(jī)制 有 有
熔斷機(jī)制 無 Hystrix
配置中心 依賴外部組件，如：Nacos Spring Cloud Config
網(wǎng)關(guān) 無 zuul,Gateway
服務(wù)監(jiān)控 Dubbo + Monitor Hystrix + Turbine、Spring Boot Admin（SBA）
鏈路監(jiān)控 無 Sleuth + Zipkin
多語言支持 只支持Java REST支持多語言
社區(qū)活躍 高(依靠阿里) 高(依靠Spring)
消息總線 無 Spring Cloud Bus
數(shù)據(jù)流 無 Spring Cloud Stream
批量任務(wù) 無 Spring Cloud Task
…… …… ……
通過上表對比，很容易發(fā)現(xiàn)Spring Cloud擁有很多的項(xiàng)目模塊，包含了微服務(wù)系統(tǒng)的方方面面。Dubbo是一個(gè)非常優(yōu)秀的服務(wù)治理和服務(wù)調(diào)用框架，但缺少很多功能模塊，例如網(wǎng)關(guān)、鏈路追蹤等。在項(xiàng)目模塊上，Spring Cloud占據(jù)著更大的優(yōu)勢。對比并不是否定誰，推崇誰，只是說明在不同場景下，有利優(yōu)劣，需客觀來看。
如果僅關(guān)注于服務(wù)治理的這個(gè)層面，Dubbo其實(shí)還優(yōu)于Spring Cloud很多：
支持多種序列化協(xié)議，如Hessian、HTTP、WebService。
Dobbo Admin后臺管理功能強(qiáng)大，提供了路由規(guī)則、動態(tài)配置、訪問控制、權(quán)重調(diào)節(jié)、均衡負(fù)載等功能。
在國內(nèi)影響力比較大，中文社區(qū)文檔較為全面。
阿里最近重啟維護(hù)，成為Apache孵化項(xiàng)目。
Dubbo使用RPC協(xié)議效率更高，在極端壓力測試下，Dubbo的效率會高于Spring Cloud效率一倍多。
如果對效率有極高的要求建議使用Dubbo，相對比RPC的效率會比Restful高很多，如果選擇微服務(wù)架構(gòu)去重構(gòu)整個(gè)技術(shù)體系，那么 Spring Cloud是當(dāng)仁不讓之選，它可以說是目前最好的微服務(wù)框架沒有之一，并且可以斷言，將來Dubbo可以很好的整合到Spring Cloud中。
五、API網(wǎng)關(guān)
API網(wǎng)關(guān)作為微服務(wù)中所有服務(wù)的唯一入口，免得業(yè)界各類成熟的技術(shù)框架組件，在進(jìn)行技術(shù)選型時(shí)，需要特別考慮是否擁有以下特性：
高可用：網(wǎng)關(guān)是對外的唯一關(guān)口，必須保證 7 * 24小時(shí)可用，持續(xù)提供穩(wěn)定可靠的服務(wù)。
高性能：所有的請求都會經(jīng)過網(wǎng)關(guān)，它承受的壓力是巨大的，所以必須保證它具備良好的性能，以應(yīng)對高并發(fā)請求。
安全性：網(wǎng)關(guān)必須能夠防止外部的惡意訪問，確保內(nèi)部各個(gè)微服務(wù)的安全。
擴(kuò)展性：網(wǎng)關(guān)是一個(gè)處理非業(yè)務(wù)功能的絕佳場所，必須能夠提供流量管控、協(xié)議轉(zhuǎn)發(fā)、日志監(jiān)控等服務(wù)，同時(shí)能夠?yàn)橐院髮Ψ菢I(yè)務(wù)功能的擴(kuò)展提供良好的兼容性。
1.Zuul
Zuul作為Spring Cloud中的核心組件之一，充當(dāng)API網(wǎng)關(guān)的重要角色，所有請求都可以通過Zuul達(dá)到后端的應(yīng)用程序、服務(wù)。Zuul提供了動態(tài)路由、監(jiān)控、彈性負(fù)載和安全等特性，其核心是一系列的Filter，其作用類似于Servlet框架中的Filter，或者AOP。
Zuul底層利用各種Filter實(shí)現(xiàn)了如下功能：
動態(tài)路由：根據(jù)需要將請求動態(tài)路由到后端集群。
身份認(rèn)證和安全性：識別每個(gè)需要認(rèn)證的資源，拒絕不符合要求的請求，如：鑒權(quán)。
統(tǒng)計(jì)監(jiān)測：在服務(wù)邊界追蹤并統(tǒng)計(jì)數(shù)據(jù)，提供精確的統(tǒng)計(jì)監(jiān)測視圖。
壓力測試：逐漸增加對集群的流量以了解其性能。
負(fù)載卸載：預(yù)先為每種類型的請求分配容量，當(dāng)請求超過容量時(shí)自動丟棄。
靜態(tài)資源處理：直接在邊界返回某些響應(yīng)。
基于上述這些功能特性，使得Zuul作為API網(wǎng)關(guān)的不二之選。
Zuul的邏輯架構(gòu)如下圖所示:
Zuul的過濾器之間是不直接通信的，而是通過一個(gè)RequestContext的類來進(jìn)行數(shù)據(jù)傳統(tǒng)，RequestContext繼承ConcurrentHashMap，使用ThreadLocal變量來記錄每個(gè)Request需要傳遞的數(shù)據(jù)。
Zuul的過濾器是由Groovy來實(shí)現(xiàn)的，這些過濾器文件被存放在Zuul Server的特定目錄下，Zuul會定期輪詢這些目錄，修改過的過濾器會動態(tài)加載到Zuul Server中，以便過濾請求使用。
Zuul的大部分功能都是通過過濾器來實(shí)現(xiàn)的，其中定義了4種標(biāo)準(zhǔn)的過濾器類型(pre、route、post、error)，以滿足應(yīng)用于請求的不同階段。
(如果想更清晰深入的了解Zuul，可以參考上圖的Zuul邏輯架構(gòu)圖，并結(jié)合Zuul源碼深入研究下。)
2.traefik
在了解traefik之前，不妨先看看它的整體架構(gòu)圖，如下所示：
從上圖不難看出，traefik充當(dāng)了HTTP反向代理的角色，使得發(fā)布的服務(wù)變得輕松有趣。在微服務(wù)中，實(shí)質(zhì)上是一個(gè)為了讓部署微服務(wù)變得更加便捷而誕生的HTTP反向代理、負(fù)載均衡工具。，它支持多種后臺 (Docker, Swarm, Kubernetes, Marathon, Mesos, Consul, Etcd, Zookeeper, BoltDB, Rest API, file…) 來自動化、動態(tài)的應(yīng)用它的配置文件設(shè)置。
除了眾多功能之外，traefik的與眾不同之處還在于它會自動發(fā)現(xiàn)適合您服務(wù)的配置。無需維護(hù)和同步單獨(dú)的配置文件,一切都會自動，實(shí)時(shí)地進(jìn)行（無需重新啟動，不會中斷連接）。使用traefik后，你可以將更多的精力、時(shí)間花費(fèi)在開發(fā)和部署上面，而不是在配置和維護(hù)其工作狀態(tài)上。
特性：
高性能
無需安裝其他依賴，通過Go語言編寫的單一可執(zhí)行文件
支持Restful API接口
多種后臺支持：Docker, Swarm, Kubernetes, Marathon, Mesos, Consul, Etcd
后臺監(jiān)控, 可以監(jiān)聽后臺變化進(jìn)而自動化應(yīng)用新的配置文件設(shè)置
配置文件熱更新。（無需重啟）
正常結(jié)束http連接
后端斷路器
輪詢，rebalancer 負(fù)載均衡
Rest Metrics
支持最小化官方docker鏡像
后臺支持SSL
前臺支持SSL（包括SNI）
清爽的AngularJS前端頁面
支持Websocket
支持HTTP/2
網(wǎng)絡(luò)錯(cuò)誤重試
支持Let’s Encrypt (自動更新HTTPS證書)
高可用集群模式
3.OpenResty
OpenResty是一個(gè)基于Nginx與Lua的高性能Web平臺，其內(nèi)部集成了大量精良的Lua庫、第三方模塊以及大多數(shù)的依賴項(xiàng)。用于方便地搭建能夠處理超高并發(fā)、擴(kuò)展性極高的動態(tài)Web應(yīng)用、Web服務(wù)和動態(tài)網(wǎng)關(guān)。
OpenResty通過匯聚各種設(shè)計(jì)精良的Nginx模塊（主要由OpenResty團(tuán)隊(duì)自主開發(fā)），從而將Nginx有效地變成一個(gè)強(qiáng)大的通用Web應(yīng)用平臺。這樣，Web 開發(fā)人員和系統(tǒng)工程師可以使用Lua腳本語言調(diào)動 Nginx支持的各種C以及Lua模塊，快速構(gòu)造出足以勝任10K乃至 1000K以上單機(jī)并發(fā)連接的高性能Web應(yīng)用系統(tǒng)。
OpenResty的目標(biāo)是讓你的Web服務(wù)直接跑在Nginx服務(wù)內(nèi)部，充分利用Nginx的非阻塞I/O模型，不僅僅對HTTP客戶端請求,甚至于對遠(yuǎn)程后端諸如MySQL、PostgreSQL、Memcached以及Redis等都進(jìn)行一致的高性能響應(yīng)。
4.Kong
Kong是一個(gè)在Nginx中運(yùn)行的Lua應(yīng)用程序，并且可以通過lua-nginx模塊實(shí)現(xiàn)，Kong不是用這個(gè)模塊編譯Nginx，而是與OpenResty一起發(fā)布，OpenResty已經(jīng)包含了lua-nginx-module，OpenResty不是 Nginx的分支，而是一組擴(kuò)展功能的模塊。
是一個(gè)Api Gateway，通過插件的形式提供負(fù)載均衡，日志記錄，身份驗(yàn)證，速率限制，轉(zhuǎn)換等功能。可以很輕松擴(kuò)展功能，模塊化，可以運(yùn)行在任何基礎(chǔ)設(shè)施上。
它的核心是實(shí)現(xiàn)數(shù)據(jù)庫抽象，路由和插件管理，插件可以存在于單獨(dú)的代碼庫中，并且可以在幾行代碼中注入到請求生命周期的任何位置。很方便地為路由和服務(wù)提供各種插件，網(wǎng)關(guān)所需要的基本特性，Kong都如數(shù)支持：
云原生：與平臺無關(guān)，Kong可以從裸機(jī)運(yùn)行到Kubernetes。
動態(tài)路由：Kong的背后是OpenResty+Lua，所以從OpenResty繼承了動態(tài)路由的特性。
熔斷
健康檢查
日志：可以記錄通過Kong的HTTP，TCP，UDP請求和響應(yīng)。
鑒權(quán)：權(quán)限控制，IP黑白名單，同樣是OpenResty的特性。
SSL: 可以為基礎(chǔ)服務(wù)或API設(shè)置特定的SSL證書。
監(jiān)控：Kong提供了實(shí)時(shí)監(jiān)控插件。
認(rèn)證：如數(shù)支持HMAC, JWT, Basic, OAuth2.0等常用協(xié)議。
限流
REST API：通過Rest API進(jìn)行配置管理，從繁瑣的配置文件中解放。
可用性: 天然支持分布式。
高性能: 背靠非阻塞通信的nginx，性能自不用說。
插件機(jī)制: 提供眾多開箱即用的插件，且有易于擴(kuò)展的自定義插件接口，用戶可以使用Lua自行開發(fā)插件。
上面這些特性中，反復(fù)提及了Kong背后的OpenResty，實(shí)際上，使用 Kong之后，Nginx可以完全摒棄，因?yàn)镵ong的功能是Nginx的父集。
5.對比、總結(jié)
Zuul traefik OpenResty Kong
功能/用途 Spring Cloud中的核心組件之一，充當(dāng)API網(wǎng)關(guān)的角色 支持動態(tài)配置的HTTP反向代理和負(fù)載均衡器 基于Nginx與Lua的高性能Web平臺，服務(wù)代理/網(wǎng)關(guān) 企業(yè)級API管理
學(xué)習(xí)成本 簡單 簡單 適中 適中
社區(qū) 開源、活躍 開源 開源 開源/企業(yè)版
擴(kuò)展性 可擴(kuò)展，自己實(shí)現(xiàn)Filter 可擴(kuò)展，自己實(shí)現(xiàn) 可擴(kuò)展，插件 可擴(kuò)展， 插件
服務(wù)發(fā)現(xiàn) 動態(tài) 動態(tài) 動態(tài) 動態(tài)
通信協(xié)議 Restful http,https,grpc,websocket http,https,websocket http,https,websocket
限流 支持 不支持 支持 支持
熔斷 支持 支持 - -
健康檢查 支持 不支持 支持 支持
綜上對比，從開源社區(qū)活躍度和學(xué)習(xí)成本來看，無疑是Zuul和Traefik較好；從成熟度來看，較好的是Kong、Traefik；從性能角度來看，Kong要比其他幾個(gè)領(lǐng)先一些，從架構(gòu)優(yōu)勢的擴(kuò)展性來看，Kong豐富的插件，而Zuul是完全需要自研各類Filter，但Zuul由于與Spring Cloud深度集成，使用度也很高。
六、服務(wù)注冊與發(fā)現(xiàn)
服務(wù)注冊與發(fā)現(xiàn)，是一個(gè)古老的話題，當(dāng)應(yīng)用開始脫離單機(jī)運(yùn)行和訪問時(shí)，服務(wù)注冊與發(fā)現(xiàn)就誕生了。目前的網(wǎng)絡(luò)架構(gòu)是每個(gè)主機(jī)都有一個(gè)獨(dú)立的IP地址，那么服務(wù)發(fā)現(xiàn)基本上都是通過某種方式獲取到服務(wù)所部署的IP地址。DNS協(xié)議是最早將一個(gè)網(wǎng)絡(luò)名稱翻譯為網(wǎng)絡(luò)IP的協(xié)議，在最初的架構(gòu)選型中，DNS+LVS+Nginx基本可以滿足所有的RESTful服務(wù)的發(fā)現(xiàn)，此時(shí)服務(wù)的IP列表通常配置在Nginx或者LVS。后來出現(xiàn)了RPC服務(wù)，服務(wù)的上下線更加頻繁，人們開始尋求一種能夠支持動態(tài)上下線并且推送IP列表變化的注冊中心框架或組件。
現(xiàn)如今，各類服務(wù)注冊與發(fā)現(xiàn)的框架、組件很多(Zookeeper、Eureka、Consul、etcd等)，在選擇上更是眼花繚亂。在服務(wù)注冊與發(fā)現(xiàn)的技術(shù)選型上，我覺得我們應(yīng)該還是有一定遵循原則和關(guān)注要點(diǎn)的。通?？蓮囊韵聨讉€(gè)方面出發(fā)，進(jìn)行重點(diǎn)關(guān)注、抉擇。
數(shù)據(jù)一致性
負(fù)載均衡
健康檢查
性能與容量
易用性
集群擴(kuò)展性
用戶擴(kuò)展性
七、配置中心
在微服務(wù)架構(gòu)中，服務(wù)的數(shù)量以及配置信息的日益增多，比如各種服務(wù)器參數(shù)配置、各種數(shù)據(jù)庫訪問參數(shù)配置、各種環(huán)境下配置信息的不同、配置信息修改之后實(shí)時(shí)生效等等，傳統(tǒng)的配置文件方式或者將配置信息存放于數(shù)據(jù)庫中的方式已無法滿足開發(fā)人員對配置管理的要求，如：
安全性：配置跟隨源代碼保存在代碼庫中，容易造成配置泄漏。
時(shí)效性：修改配置，需要重啟服務(wù)才能生效。
局限性：無法支持動態(tài)調(diào)整：例如日志開關(guān)、功能開關(guān)。
在微服務(wù)架構(gòu)中，使用配置中心之前，上述的問題或麻煩，你肯定也會遇到過，所以，是否引入配置中心，取決于你是否有下面的需求：
配置集中化統(tǒng)一管理
配置實(shí)時(shí)生效
一般完善的配置中心，都會從以下兩個(gè)方面設(shè)計(jì)出發(fā)，以發(fā)揮配置中心的作用。
1）配置實(shí)時(shí)生效
傳統(tǒng)的靜態(tài)配置方式要想修改某個(gè)配置只能修改之后重新發(fā)布應(yīng)用，要實(shí)現(xiàn)動態(tài)性，可以選擇使用數(shù)據(jù)庫，通過定時(shí)輪詢訪問數(shù)據(jù)庫來感知配置的變化。輪詢頻率低感知配置變化的延時(shí)就長，輪詢頻率高，感知配置變化的延時(shí)就短，但比較損耗性能，需要在實(shí)時(shí)性和性能之間做折中。配置中心專門針對這個(gè)業(yè)務(wù)場景，兼顧實(shí)時(shí)性和一致性來管理動態(tài)配置。
2）配置管理流程
配置的權(quán)限管控、灰度發(fā)布、版本管理、格式檢驗(yàn)和安全配置等一系列的配置管理相關(guān)的特性也是配置中心不可獲取的一部分。(這也算是配置中心的高級特性作用)
1.Spring Cloud Config
Spring Cloud Config作為Spring Cloud中的一個(gè)組件，其功能開放，可開發(fā)性強(qiáng)，常是各類配置中心自我研發(fā)的基石。
從Spring Cloud Config的源碼(spring-cloud-config-server)中，可以看出目前支持本地存儲、Git倉庫存儲、SVN倉庫存儲、數(shù)據(jù)庫存儲方式，其他存儲方式可參考源碼自行實(shí)現(xiàn)即可。
以Git存儲方式為例說明，Spring Cloud Config包含config-server、Git和Spring Cloud Bus三大組件：
config-server提供給客戶端獲取配置。
Git用于存儲和修改配置。
Spring Cloud Bus通知客戶端配置變更。
本地測試模式下，Spring Cloud Bus和config-server需要部署一個(gè)節(jié)點(diǎn)，Git使用GitHub就可以。在生產(chǎn)環(huán)境中，Spring Cloud Config，config-server需要部署至少兩個(gè)節(jié)點(diǎn)。Spring Cloud Bus如果使用RabbitMQ，普通集群模式至少需要兩個(gè)節(jié)點(diǎn)。
Git服務(wù)如果使用GitHub就不用考慮高可用問題，如果考慮到安全性要自建Git私有倉庫，整體的成本比較高。Web服務(wù)可以部署多節(jié)點(diǎn)支持高可用，由于Git有數(shù)據(jù)的一致性問題，可以通過以下的方式來支持高可用：
Git+Keepalived冷備模式，當(dāng)主Git掛了可以馬上切到備Git。
Git多節(jié)點(diǎn)部署，存儲使用網(wǎng)絡(luò)文件系統(tǒng)或者通過DRBD實(shí)現(xiàn)多個(gè)Git節(jié)點(diǎn)的數(shù)據(jù)同步。
2.Apollo
Apollo（阿波羅）是攜程框架部門研發(fā)的分布式配置中心，能夠集中化管理應(yīng)用不同環(huán)境、不同集群的配置，配置修改后能夠?qū)崟r(shí)推送到應(yīng)用端，并且具備規(guī)范的權(quán)限、流程治理等特性，適用于微服務(wù)配置管理場景。
Apollo分為MySQL，Config Service，Admin Service，Portal四個(gè)模塊：
MySQL：存儲Apollo元數(shù)據(jù)和用戶配置數(shù)據(jù)。
Config Service：提供配置的讀取、推送等功能，客戶端請求都是落到Config Service上。
Admin Service：提供配置的修改、發(fā)布等功能，Portal操作的服務(wù)就是Admin Service。
Portal：提供給用戶配置管理界面。
本地測試Config Service，Admin Service，Portal三個(gè)模塊可以合并一起部署，MySQL單獨(dú)安裝并創(chuàng)建需要的表結(jié)構(gòu)。在生產(chǎn)環(huán)境使用Apollo，Portal可以兩個(gè)節(jié)點(diǎn)單獨(dú)部署，穩(wěn)定性要求沒那么高的話，Config Service和Admin Service可以部署在一起，數(shù)據(jù)庫支持主備容災(zāi)。
3.Nacos
Nacos是一個(gè)更易于構(gòu)建云原生應(yīng)用的動態(tài)服務(wù)發(fā)現(xiàn)、配置管理和服務(wù)管理平臺。這正是Nacos官方給出的定義：
an easy-to-use dynamic service discovery, configuration and service management platform for building cloud native applications.
核心功能：
動態(tài)配置服務(wù)：
動態(tài)配置服務(wù)讓您能夠以中心化、外部化和動態(tài)化的方式管理所有環(huán)境的配置。動態(tài)配置消除了配置變更時(shí)重新部署應(yīng)用和服務(wù)的需要。配置中心化管理讓實(shí)現(xiàn)無狀態(tài)服務(wù)更簡單，也讓按需彈性擴(kuò)展服務(wù)更容易。
服務(wù)發(fā)現(xiàn)及管理：
動態(tài)服務(wù)發(fā)現(xiàn)對以服務(wù)為中心的（例如微服務(wù)和云原生）應(yīng)用架構(gòu)方式非常關(guān)鍵。Nacos支持DNS-Based和RPC-Based（Dubbo、gRPC）模式的服務(wù)發(fā)現(xiàn)。Nacos也提供實(shí)時(shí)健康檢查，以防止將請求發(fā)往不健康的主機(jī)或服務(wù)實(shí)例。借助Nacos，您可以更容易地為您的服務(wù)實(shí)現(xiàn)斷路器。
動態(tài)DNS服務(wù)：
通過支持權(quán)重路由，動態(tài)DNS服務(wù)能讓您輕松實(shí)現(xiàn)中間層負(fù)載均衡、更靈活的路由策略、流量控制以及簡單數(shù)據(jù)中心內(nèi)網(wǎng)的簡單DNS解析服務(wù)。動態(tài)DNS服務(wù)還能讓您更容易地實(shí)現(xiàn)以DNS協(xié)議為基礎(chǔ)的服務(wù)發(fā)現(xiàn)，以消除耦合到廠商私有服務(wù)發(fā)現(xiàn)API上的風(fēng)險(xiǎn)。
Nacos部署需要Nacos Service和MySQL：
Nacos Service：對外提供服務(wù)，支持配置管理和服務(wù)發(fā)現(xiàn)。
MySQL：提供Nacos的數(shù)據(jù)持久化存儲。
單機(jī)模式下，Nacos可以使用嵌入式數(shù)據(jù)庫部署一個(gè)節(jié)點(diǎn)，就能啟動。如果對MySQL比較熟悉，想要了解整體數(shù)據(jù)流向，可以安裝MySQL提供給Nacos數(shù)據(jù)持久化服務(wù)。生產(chǎn)環(huán)境使用Nacos，Nacos服務(wù)需要至少部署三個(gè)節(jié)點(diǎn)，再加上MySQL主備。
4.對比、總結(jié)
整體來看，Nacos的部署結(jié)構(gòu)比較簡單，運(yùn)維成本較低。Apollo部署組件較多，運(yùn)維成本比Nacos高。Spring Cloud Config易于定制化二次開發(fā)，生產(chǎn)高可用的成本最高。
Spring Cloud Config Apollo Nacos
開源時(shí)間 2014.9 2016.5 2018.6
實(shí)時(shí)生效(推送) 基于Spring Cloud Bus完成 基于HTTP輪詢(1s內(nèi)) 基于HTTP輪詢(1s內(nèi))
版本管理 支持(Git、SVN) 支持 支持
配置回滾 支持(Git、SVN) 支持 支持
灰度發(fā)布 支持 支持 待支持
權(quán)限管理 支持 支持 待支持
集群 支持 支持 支持
多環(huán)境 支持 支持 支持
監(jiān)聽查詢 支持 支持 支持
多語言 只支持Java Java、Go、C++、Python、PHP Java、Python、Nodejs
單機(jī)部署 Config-Server + Git + Spring Cloud Bus(實(shí)時(shí)更新推送) Apollo-quickstart + MySQL Nacos單節(jié)點(diǎn)
分布式部署 Config-Server(2) + Git + MQ (部署復(fù)雜) Config(2) + Admin(2) + Portal(2) + MySQL (部署復(fù)雜) Nacos(3) + MySQL(部署簡單)
配置格式校驗(yàn) 不支持 支持 支持
通信協(xié)議 HTTP、AMQP HTTP HTTP
數(shù)據(jù)一致性 Git保證數(shù)據(jù)一致性 數(shù)據(jù)庫模擬消息隊(duì)列，Apollo定時(shí)讀取 HTTP異步通知
總的來說，Apollo和Nacos相對于Spring Cloud Config的生態(tài)支持更廣，在配置管理流程上做的更好。Apollo相對于Nacos在配置管理做的更加全面，不過使用起來也要麻煩一些。Nacos使用起來相對比較簡潔，在對性能要求比較高的大規(guī)模場景更適合。
