一痴怨、前言
隨著IT技術(shù)發(fā)展和推進(jìn)忙干，傳統(tǒng)的單體應(yīng)用程序模式已不滿足大多數(shù)企業(yè)IT平臺(tái)構(gòu)建，尤其是大型互聯(lián)網(wǎng)網(wǎng)站或企業(yè)級(jí)應(yīng)用浪藻。單體應(yīng)用隨著項(xiàng)目持續(xù)集成捐迫，代碼庫(kù)越來(lái)越大，在系統(tǒng)復(fù)雜度爱葵、測(cè)試弓乙、代碼沖突解決末融、可擴(kuò)展性、多環(huán)境支持暇韧、需求變更容易造成系統(tǒng)整體影響等方面面臨各種嚴(yán)峻挑戰(zhàn)勾习。此時(shí)微服務(wù)架構(gòu)應(yīng)運(yùn)而生。
微服務(wù)從2014的1.0技術(shù)元年開(kāi)始懈玻，隨著微服務(wù)社區(qū)的推進(jìn)巧婶，微服務(wù)技術(shù)體系生態(tài)產(chǎn)生極大變化，微服務(wù)進(jìn)入2.0時(shí)代涂乌。微服務(wù)架構(gòu)體系經(jīng)過(guò)多年的大規(guī)模生產(chǎn)驗(yàn)證艺栈，已成為構(gòu)建互聯(lián)網(wǎng)網(wǎng)站、大型企業(yè)級(jí)應(yīng)用的首選分布式技術(shù)架構(gòu)湾盒。
2020年隨著容器化湿右、K8S技術(shù)的發(fā)展?fàn)顟B(tài)，將微服務(wù)架構(gòu)推向了更高的地位罚勾，甚至許多大廠都在喊著一些都是服務(wù)化的口號(hào)∫闳耍現(xiàn)在后端工程師除了搞算法、嵌入式的外尖殃，簡(jiǎn)歷上不寫著會(huì)微服務(wù)丈莺，大概也不好找工作了吧...
相對(duì)于單體應(yīng)用，微服務(wù)更具有優(yōu)勢(shì)：
- 易于理解：微服務(wù)將應(yīng)用按照功能分解為獨(dú)立開(kāi)發(fā)和部署的微型應(yīng)用送丰，每個(gè)服務(wù)與應(yīng)用程序的其他微服務(wù)之間有一個(gè)很小且有限的契約缔俄。微服務(wù)更加專注目標(biāo)，作為一個(gè)功能模塊的單元器躏，微服務(wù)更容易理解俐载。
- 微服務(wù)易于測(cè)試：每個(gè)微服務(wù)都是獨(dú)立開(kāi)發(fā)部署的微型應(yīng)用，易于測(cè)試登失。在集成測(cè)試和驗(yàn)收測(cè)試方面也更易于驗(yàn)證瞎疼。
- 較少遇到庫(kù)不兼容問(wèn)題：每個(gè)微服務(wù)都有自己獨(dú)立的項(xiàng)目構(gòu)建依賴項(xiàng)的集合，而這些集合不會(huì)與其他微服務(wù)共享壁畸。
- 微服務(wù)能夠獨(dú)立擴(kuò)展：微服務(wù)之間獨(dú)立部署贼急，因此指定微服務(wù)的內(nèi)存和實(shí)例擴(kuò)展不會(huì)影響整體應(yīng)用其他微服務(wù)的內(nèi)存和實(shí)例數(shù)量。
- 微服務(wù)可以獨(dú)立選擇不同的技術(shù)棧：微服務(wù)可以選擇不同的語(yǔ)言捏萍、平臺(tái)太抓、框架和庫(kù)。特別是如果微服務(wù)采用HTTP協(xié)議這樣的跨平臺(tái)協(xié)議令杈，實(shí)際上java微服務(wù)可以和C#走敌、Python等編寫的微服務(wù)協(xié)作是完全合理的。
- 微服務(wù)更易于發(fā)布：微服務(wù)是獨(dú)立部署的逗噩，因此不需要等待其他微服務(wù)部署就緒掉丽。同時(shí)隨著docker容器化跌榔、k8s服務(wù)編排、自動(dòng)化CI/CD工具的出現(xiàn)捶障，讓微服務(wù)的發(fā)布更加簡(jiǎn)單僧须。
當(dāng)然微服務(wù)架構(gòu)作為分布式架構(gòu)，同樣面臨網(wǎng)絡(luò)延遲项炼、多服務(wù)運(yùn)維担平、分布式復(fù)雜性等問(wèn)題的挑戰(zhàn)。因此合理合適的技術(shù)選型是微服務(wù)項(xiàng)目的構(gòu)建的重中之中锭部。
選型準(zhǔn)則
生產(chǎn)級(jí)
我們使用微服務(wù)架構(gòu)是要解決實(shí)際業(yè)務(wù)場(chǎng)景和生產(chǎn)抗流量的暂论，而不是做簡(jiǎn)單的demo，如果選擇不慎可能出現(xiàn)生產(chǎn)級(jí)事故拌禾。因此取胎，生產(chǎn)級(jí)（Production Ready）、可運(yùn)維（Ops Ready）湃窍、可治理闻蛀、技術(shù)成熟的微服務(wù)技術(shù)才是我們的首選。
使用已經(jīng)在多個(gè)一線互聯(lián)網(wǎng)或大型企業(yè)落地并經(jīng)過(guò)生產(chǎn)挑戰(zhàn)的
我們應(yīng)該盡量選擇使用已經(jīng)在多個(gè)一線互聯(lián)網(wǎng)或大型企業(yè)落地并經(jīng)過(guò)生產(chǎn)挑戰(zhàn)并且開(kāi)源的坝咐，且在社區(qū)有良好口碑的技術(shù)棧。
開(kāi)源社區(qū)活躍
社區(qū)活躍析恢、stars數(shù)量越多墨坚、代碼和文檔更新頻率高的技術(shù)棧是優(yōu)選選擇的，開(kāi)源社區(qū)活躍可以直接反應(yīng)技術(shù)的生命力映挂。同時(shí)閉源或者停止更新的技術(shù)框架應(yīng)該慎重選擇泽篮。
結(jié)合項(xiàng)目實(shí)際情況
不是所有項(xiàng)目都適用于微服務(wù)架構(gòu)體系，應(yīng)該結(jié)合項(xiàng)目實(shí)際情況選擇合適的技術(shù)架構(gòu)柑船。
二帽撑、微服務(wù)基礎(chǔ)架構(gòu)關(guān)鍵
微服務(wù)框架選型
微服務(wù)框架經(jīng)過(guò)多年發(fā)展是一個(gè)比較成熟的領(lǐng)域，有比較多選擇鞍时，以下為市場(chǎng)主流微服務(wù)架構(gòu)對(duì)比：
| 微服務(wù)框架 | Spring Boot/Cloud | Dubbo/DubboXg | gRpc | Thirft | Motan |
|---|---|---|---|---|---|
| 功能點(diǎn)位 | 完整微服務(wù)框架方案 | 服務(wù)框架 | RPC | RPC | RPC |
| 是否支持REST | 是亏拉，基于Ribbon支持多種可插拔的序列化選擇 | 否 | 否 | 否 | 否 |
| 是否支持RPC | 否 | 是 | 是 | 是 | 是 |
| 是否支持多語(yǔ)言 | 是 | 否 | 是 | 是 | 否 |
| 典型案例 | Netflix、阿里 | 阿里逆巍、當(dāng)當(dāng) | 谷歌 | Sina | |
| 社區(qū)活躍 | 高 | 高 | 高 | 一般 | 一般 |
| 文檔豐富度 | 高 | 高 | 一般 | 一般 | 一般 |
Spring Cloud由于其Spring社區(qū)影響和Netflix的背書及塘，以及其提供的完整一套微服務(wù)框架實(shí)現(xiàn)方案，目前可以認(rèn)為Spring Cloud是基于java構(gòu)建微服務(wù)的標(biāo)準(zhǔn)方案锐极。其對(duì)于新興團(tuán)隊(duì)或未形成自己微服務(wù)體系的團(tuán)隊(duì)有較大吸引力笙僚。Spring Cloud由于其社區(qū)活躍度、完善的生態(tài)灵再，目前國(guó)內(nèi)外眾多大廠都加入其生態(tài)家族（aws肋层、alibaba亿笤、huawei、Azure等）栋猖，甚至阿里將其微服務(wù)框架Dubbo也加入到Spring Cloud生態(tài)净薛，成為其畢業(yè)項(xiàng)目。
Spring Cloud框架本身基于HTTP協(xié)議掂铐，是一種典型的RESTfull框架而不是RPC框架罕拂，序列化協(xié)議主要基于文本的JSON。
RESTfull天然支持跨語(yǔ)言平臺(tái)全陨，任何支持HTTP協(xié)議的應(yīng)用都可以接入調(diào)用爆班，但是客戶端需要自己解析payload。TESTfull框架接口文檔管理隨著版本迭代辱姨，維護(hù)越發(fā)困難柿菩，如果沒(méi)有統(tǒng)一標(biāo)準(zhǔn)的接口文檔管理機(jī)制，更新不及時(shí)或缺乏注釋等接口文檔對(duì)于接口調(diào)用者和繼續(xù)集成開(kāi)發(fā)者來(lái)說(shuō)是一個(gè)災(zāi)難雨涛。目前Spring框架也支持Swagger 契約編程模型枢舶，可以基于Swagger 契約生成各語(yǔ)言的強(qiáng)類型客戶端，極大方便不同語(yǔ)言棧的接入替久。Dubbo是阿里多年構(gòu)建生產(chǎn)級(jí)分布式微服務(wù)的技術(shù)結(jié)晶凉泄，服務(wù)治理能力豐富，在國(guó)內(nèi)社區(qū)非瞅歉活躍后众。Dubbo其本質(zhì)是一套基于java的RPC框架。當(dāng)當(dāng)DubboX在Dubbo基礎(chǔ)上進(jìn)行了擴(kuò)展颅拦，支持了RESTfull接口暴露的能力蒂誉。
Dubbo主要面向Java技術(shù)棧，跨語(yǔ)言支持能力先天不足距帅，同時(shí)由于豐富的治理能力右锨，框架整體比較重，想要完整使用好Dubbo門檻比較高碌秸。但是如果企業(yè)基本都是基于java技術(shù)棧進(jìn)行項(xiàng)目構(gòu)建绍移，選擇Dubbo可以使項(xiàng)目站在比較高的起點(diǎn)上，Dubbo在企業(yè)級(jí)性能和服務(wù)治理能力都非常優(yōu)秀讥电。Sina的Motan和Dubbo功能類似登夫，可以認(rèn)為是Dubbo的輕量級(jí)剪裁版。前面已說(shuō)到Dubbo已加入Spring Cloud生態(tài)允趟，通過(guò)Apache Dubbo RPC擴(kuò)展Spring Cloud服務(wù)間調(diào)用的通信協(xié)議恼策，因此一定程度可以不用糾結(jié)Spring Cloud還是Dubbo了 O(∩_∩)O。
gRpc是谷歌推出的一套R(shí)PC框架，基于protobuf的強(qiáng)契約編程模型涣楷，能夠自動(dòng)生成各類語(yǔ)言的客戶端且保證互操作分唾。gRpc適用于內(nèi)部互相調(diào)用的場(chǎng)景，對(duì)外暴露RESTfull API實(shí)現(xiàn)比較麻煩狮斗，需要引入第二套R(shí)ESTfull 框架作為輔助绽乔。
運(yùn)行時(shí)服務(wù)支撐服務(wù)選型
服務(wù)注冊(cè)與發(fā)現(xiàn)
服務(wù)治理實(shí)現(xiàn)微服務(wù)架構(gòu)體系下各個(gè)微服務(wù)實(shí)例的自動(dòng)化注冊(cè)和發(fā)現(xiàn)。大部分分布式項(xiàng)目在構(gòu)建之初碳褒，由于微服務(wù)實(shí)例較少折砸，基本是采用傳統(tǒng)靜態(tài)配置的方式管理服務(wù)實(shí)例清單，在項(xiàng)目擴(kuò)展或變更時(shí)需要手工維護(hù)靜態(tài)配置沙峻。隨著業(yè)務(wù)發(fā)展睦授，系統(tǒng)功能越來(lái)越復(fù)雜、微服務(wù)實(shí)例數(shù)量也極具增加摔寨，手工方式維護(hù)靜態(tài)配置需要花費(fèi)大量人力去枷，同時(shí)還極易發(fā)生錯(cuò)誤。服務(wù)治理組件就是為了解決微服務(wù)架構(gòu)實(shí)例維護(hù)問(wèn)題是复。
CAP原則
談到服務(wù)注冊(cè)就必須先說(shuō)CAP原則删顶，指的是分布式系統(tǒng)中的一致性（Consistency）、可用性（Availability）淑廊、分區(qū)容錯(cuò)性（Patitiontolerence）逗余，三者不可全得。
- 一致性：指的是分布式所有節(jié)點(diǎn)在同一時(shí)間的數(shù)據(jù)完全一致季惩，對(duì)于一致性录粱，一致的程度可以分為強(qiáng)、弱蜀备、最終一致性：
- 強(qiáng)一致性：對(duì)于關(guān)系數(shù)據(jù)庫(kù)关摇，要求更新數(shù)據(jù)能夠被后續(xù)的訪問(wèn)都能看到荒叶。如A更新了V0到V1碾阁，其他線程后續(xù)讀取的時(shí)候必須是V1。
- 弱一致性：能夠容忍后續(xù)讀取部分或者全部訪問(wèn)不到些楣。如A更新V0到V1脂凶，可以容忍其他線程讀取的時(shí)候仍是V0；
- 最終一致性：弱一致性的特例愁茁，保證在沒(méi)有后續(xù)更新的前提下蚕钦，系統(tǒng)經(jīng)過(guò)一段時(shí)間要求返回最近一次更新后的數(shù)據(jù)。
- 可用性：分布式集群一部分節(jié)點(diǎn)故障后鹅很，集群整體是否還能響應(yīng)客戶請(qǐng)求嘶居。
- 分區(qū)容錯(cuò)：某節(jié)點(diǎn)故障或網(wǎng)絡(luò)分區(qū)延遲，集群整理仍能對(duì)外提供設(shè)計(jì)好的一致性和可用性的服務(wù)。
主流注冊(cè)中心對(duì)比
| 特點(diǎn)/注冊(cè)服務(wù)組件 | Eureka | Zookeeper | Nacos | Cousul |
|---|---|---|---|---|
| 服務(wù)健康檢查 | 可配支持 | （弱）長(zhǎng)連接邮屁，keepalive | 服務(wù)狀態(tài)整袁、內(nèi)存、硬盤等 | 連接心跳 |
| 多數(shù)據(jù)中心 | 支持 | - | 支持 | 支持 |
| kv存儲(chǔ)服務(wù) | - | 支持 | - | 支持 |
| 一致性算法 | - | paxos | Raft（CP）Distro(AP) | raft |
| 數(shù)據(jù)一致性 | AP | CP | AP佑吝、CP | CA |
| 多語(yǔ)言支持 | http(Sidecar模式) | 客戶端 | http(Sidecar模式) | 支持http和DNS |
| Watch支持 | 支持long polling/大部分增量 | 支持 | 支持long polling/大部分增量 | 全量/支持long polling |
| 自身監(jiān)控 | metrics | - | metrics | metrics |
| 安全 | - | acl | - | acl/https |
| Spring Cloud集成 | 已支持 | 已支持 | 已支持 | 已支持 |
| 數(shù)據(jù)模型 | 實(shí)例級(jí)別 | 無(wú) | 服務(wù)-集群-實(shí)例 | 實(shí)例級(jí)別 |
Eureka:是SpringCloud生態(tài)核心坐昙，通過(guò)對(duì)Netfiix Eureka的二次封裝提供服務(wù)注冊(cè)和發(fā)現(xiàn)功能。Eureka 與SpringCloud生態(tài)深度結(jié)合芋忿，獲得大量用戶炸客。Eureka集群數(shù)據(jù)是AP，集群每個(gè)節(jié)點(diǎn)具有相同地位戈钢，最大程度保證集群節(jié)點(diǎn)故障痹仙，注冊(cè)中心的可用性。
Zookeeper:是應(yīng)用于分布式應(yīng)用程序的高性能分布式協(xié)調(diào)服務(wù)逆趣，它暴露了一組簡(jiǎn)單的公共服務(wù)（提供java和C接口）蝶溶，如命名、配置管理宣渗、集群服務(wù)抖所、分布式鎖等，分布式應(yīng)用程序可以基于此實(shí)現(xiàn)更高級(jí)別的服務(wù)進(jìn)行同步痕囱、組合命名田轧。是RPC框架首選注冊(cè)中心。
Nacos:致力于幫助您發(fā)現(xiàn)鞍恢、配置和管理微服務(wù)傻粘。Nacos 提供了一組簡(jiǎn)單易用的特性集，幫助您快速實(shí)現(xiàn)動(dòng)態(tài)服務(wù)發(fā)現(xiàn)帮掉、服務(wù)配置弦悉、服務(wù)元數(shù)據(jù)及流量管理。
對(duì)于Spring Cloud微服務(wù)蟆炊，目前只要還是在Eureka和Nacos上進(jìn)行選擇：
- Eureka由于其閉源稽莉，基本生產(chǎn)級(jí)微服務(wù)搭建不要考慮Eureka。
- Nacos目前社區(qū)活躍涩搓，其在集群擴(kuò)展上表現(xiàn)優(yōu)秀污秆。同時(shí)其注冊(cè)中心、配置中心統(tǒng)一集成昧甘，以及其支持命名空間的隔離良拼，使得項(xiàng)目在微服務(wù)服務(wù)治理和配置集中化管理上大大減小投入，可以說(shuō)目前Nacos應(yīng)該是Spring Cloud首選注冊(cè)中心充边。Nacos集成
API網(wǎng)關(guān)
為什么需要使用API網(wǎng)關(guān)
傳統(tǒng)單體應(yīng)用庸推，客戶端訪問(wèn)服務(wù)器采用訪問(wèn)ip+端口+服務(wù)接口前綴，客戶端程序需要維護(hù)服務(wù)實(shí)例列表，如果后續(xù)系統(tǒng)擴(kuò)展贬媒，對(duì)于客戶端開(kāi)發(fā)來(lái)說(shuō)是一個(gè)災(zāi)難刮吧。又如目前有些分布式架構(gòu)采用F5+Nginx等設(shè)施的路由和負(fù)載，然后轉(zhuǎn)發(fā)到各個(gè)不同的服務(wù)實(shí)例掖蛤，此模式下需要專業(yè)運(yùn)維人員進(jìn)行服務(wù)實(shí)例列表清單和路由規(guī)則進(jìn)行維護(hù)杀捻，當(dāng)有服務(wù)實(shí)例增減和IP地址變更，運(yùn)維人員需要手工更新路由規(guī)則和實(shí)例清單信息以保證實(shí)例信息和中間配置的一致性蚓庭。如果系統(tǒng)規(guī)模不大的情況致讥，手工維護(hù)Nginx路由規(guī)則和實(shí)例清單不算復(fù)雜，如果系統(tǒng)規(guī)模達(dá)到一定程度器赞，有幾十垢袱、上百、上千的服務(wù)實(shí)例需要維護(hù)港柜，那么對(duì)于運(yùn)維人員來(lái)說(shuō)也是極大的挑戰(zhàn)请契，同時(shí)也容易提高配置錯(cuò)誤的概率。
服務(wù)網(wǎng)關(guān)是微服務(wù)系統(tǒng)唯一入口夏醉，采用類似外觀模式封裝了系統(tǒng)內(nèi)部架構(gòu)爽锥，為客戶端提供定制化API服務(wù)，同時(shí)提供登錄鑒權(quán)畔柔、監(jiān)控氯夷、負(fù)載均衡、請(qǐng)求分片與管理靶擦、靜態(tài)響應(yīng)處理腮考、多協(xié)議支持、限流玄捕、熔斷等高級(jí)功能踩蔚。服務(wù)網(wǎng)關(guān)能夠通過(guò)框架集成實(shí)現(xiàn)自動(dòng)發(fā)現(xiàn)和管理實(shí)例，并且提供如驗(yàn)簽枚粘、登錄校驗(yàn)叙量、監(jiān)控等通過(guò)功能励堡，使得微服務(wù)開(kāi)發(fā)更加專注業(yè)務(wù)邏輯的實(shí)現(xiàn)鼻弧。
目前Spring Cloud 生態(tài)霸饲，可供我們選擇的網(wǎng)關(guān)主要還是Spring Cloud Zuul和Spring Cloud Gateway翔悠。
- Spring Cloud Zuul 是集成Netflix Zuul組件添履，與Spring Cloud有很好的集成郁轻，缺點(diǎn)是1.x 異步性能不足泥兰。
- Spring Cloud Gateway 是Spring Cloud 生態(tài)全新項(xiàng)目庄涡，基于Spring 5量承、Spring Boot 2.X、Project Reactor實(shí)現(xiàn)的API網(wǎng)關(guān)，旨在為微服務(wù)提供簡(jiǎn)單高效的API路由管理方法撕捍。
Spring Cloud Gateway 作為Spring Cloud 生態(tài)中的網(wǎng)關(guān)拿穴，目標(biāo)是代替Zuul 1.X。Spring Cloud 2.X版本目前仍未對(duì)Zuul 2.X高性能版本進(jìn)行集成忧风，仍使用的是非Reactor的老版本Zuul網(wǎng)關(guān)默色。
- 目前Spring Cloud dependencies 最新版本Hoxton.SR8 仍使用的是Zuul 1.3.1
- Zuul 2.x 高性能Reactor版本本身與18年5月開(kāi)源，目前最新版本2.1.9
Spring Cloud Gateway集成
