如何基于Spring Cloud Alibaba構(gòu)建微服務(wù)體系

這期內(nèi)容當(dāng)中小編將會(huì)給大家?guī)?lái)有關(guān)如何基于Spring Cloud Alibaba構(gòu)建微服務(wù)體系，文章內(nèi)容豐富且以專業(yè)的角度為大家分析和敘述，閱讀完這篇文章希望大家可以有所收獲。

為什么選擇 Spring Cloud Alibaba&Nacos

經(jīng)過(guò)對(duì) Alibaba Nacos 、HashiCorp Consul 等開(kāi)源注冊(cè)中心做了深入的調(diào)研和比較，以下是各個(gè)注冊(cè)中心的特性對(duì)比：

• Nacos

• 支持 AP+CP 一致性共識(shí)協(xié)議

• 支持 Agent DNS-F 服務(wù)注冊(cè)發(fā)現(xiàn)方式，跨語(yǔ)言

• 支持負(fù)載均衡，雪崩保護(hù)機(jī)制

• 支持多數(shù)據(jù)中心，跨注冊(cè)中心遷移

• Consul

• 只支持 CP 協(xié)議

• 支持 HTTP/DNS 協(xié)議

• K8s CoreDns

• 支持 DNS 協(xié)議

結(jié)論：Nacos 滿足目前掌門(mén)的服務(wù)治理技術(shù)棧，能實(shí)現(xiàn)注冊(cè)中心的平滑遷移，社區(qū)發(fā)展非?；钴S，所提供的特性，使得圍繞 Spring Cloud Alibaba&Nacos 能夠非常方便的構(gòu)建云原生應(yīng)用的動(dòng)態(tài)服務(wù)注冊(cè)發(fā)現(xiàn)。

一.Nacos server 落地

1. Nacos Server 部署

（Nacos Server 部署概覽圖）

• Nacos Server 環(huán)境和域名

掌門(mén)的應(yīng)用環(huán)境分為 4 套，DEV、FAT、UAT、PROD 分別對(duì)應(yīng)開(kāi)發(fā)、測(cè)試、準(zhǔn)生產(chǎn)環(huán)境、生產(chǎn)環(huán)境，因此 Nacos Server 也分為 4 套獨(dú)立環(huán)境。除了 DEV 環(huán)境是單機(jī)部署外，其他是集群方式部署。對(duì)外均以域名方式訪問(wèn)，SLB 做負(fù)載均衡，包括 SDK 方式連接 Nacos Server 和訪問(wèn) Nacos Server Dashboard 控制臺(tái)頁(yè)面。

• Nacos Server 環(huán)境隔離和調(diào)用隔離

Nacos 數(shù)據(jù)模型由 namespace / group / service 構(gòu)成。 可以通過(guò)創(chuàng)建不同的命名空間，做到同一個(gè)應(yīng)用環(huán)境的基礎(chǔ)上更細(xì)粒度的劃分，隔離服務(wù)注冊(cè)和發(fā)現(xiàn)。在某些場(chǎng)景下，開(kāi)發(fā)本地有需要連接測(cè)試環(huán)境的 Nacos Server ，但其他測(cè)試服務(wù)不能調(diào)用到開(kāi)發(fā)本地，這時(shí)候可以將 NacosDiscoveryProperties 的 enabled 屬性設(shè)置為 false 。 

• Nacos Server 集成 Ldap

Nacos Server Dashboard 集成公司的 Ldap 服務(wù)，并在用戶首次登錄時(shí)記錄用戶信息。 

2. Nacos Server 界面

• Nacos 界面權(quán)限

Nacos Server Dashboard 用戶首次登陸時(shí)，默認(rèn)分配普通用戶（即非 ROLE_ADMIN ）角色，對(duì)查詢以外的按鈕均無(wú)操作權(quán)限，以免出現(xiàn)誤操作導(dǎo)致服務(wù)非正常上下線。 

• Nacos 界面顯示服務(wù)概覽

Nacos Server Dashboard 頁(yè)面增加服務(wù)總數(shù)及實(shí)例總數(shù)的統(tǒng)計(jì)，該信息每 5 秒刷新一次。

3. Nacos 監(jiān)控

• 標(biāo)準(zhǔn)監(jiān)控

基于公司現(xiàn)有的 Prometheus 、 Grafana 、 AlertManager 從系統(tǒng)層監(jiān)控 Nacos。

• 高級(jí)監(jiān)控

根據(jù) Nacos 監(jiān)控手冊(cè)，結(jié)合 Prometheus 和 Grafana 監(jiān)控 Nacos 指標(biāo)。

• 服務(wù)實(shí)例狀態(tài)監(jiān)控

• 監(jiān)聽(tīng)實(shí)例下線事件

• 監(jiān)聽(tīng)實(shí)例注銷事件

• 監(jiān)聽(tīng)實(shí)例注冊(cè)事件

• 監(jiān)聽(tīng)實(shí)例上線事件

• 監(jiān)聽(tīng)實(shí)例心跳超時(shí)事件

4. Nacos 日志

• 日志合并及 JSON 格式化

將 Nacos 多模塊的日志統(tǒng)一按 info 、 warn、error 級(jí)別合并，定義 schema 字段標(biāo)記不同模塊，按 JSON 格式滾動(dòng)輸出到文件，供 ELK 采集展示。

5. Nacos 告警

• 業(yè)務(wù)服務(wù)上下線的告警

• 服務(wù)名大寫(xiě)告警

6. Nacos 性能測(cè)試

• 核心腳本

def registry(ip):
    fo = open("service_name.txt", "r")
    str = fo.read()
    service_name_list = str.split(";")
    service_name = service_name_list[random.randint(0,len(service_name_list) - 1)]
    fo.close()
    client = nacos.NacosClient(nacos_host, namespace='')
    print(client.add_naming_instance(service_name,ip,333,"default",1.0,{'preserved.ip.delete.timeout':86400000},True,True))
    while True:
      print(client.send_heartbeat(service_name,ip,333,"default",1.0,"{}"))
      time.sleep(5)

• 壓測(cè)數(shù)據(jù)

• 壓測(cè)結(jié)果圖

總結(jié)：Nacos Server 是 3 臺(tái) 1C4G 集群，同時(shí)承受 1499 個(gè)服務(wù)和 12715 個(gè)實(shí)例注冊(cè)，而且 CPU 和內(nèi)存長(zhǎng)期保持在一個(gè)合適的范圍內(nèi)，果真 Nacos 性能是相當(dāng) OK 的。

二.Nacos Eureka Sync 落地

1. Nacos Eureka Sync 方案選型

① Sync 官方方案

經(jīng)過(guò)研究，我們采取了官方的 Nacos Eureka Sync 方案，在小范圍試用了一下，效果良好，但一部署到 FAT 環(huán)境后，發(fā)現(xiàn)根本不行，一臺(tái)同步服務(wù)器無(wú)法抗住將近 660 個(gè)服務(wù)（非實(shí)例數(shù)）的頻繁心跳，同時(shí)該方案不具備高可用特點(diǎn)。  

② Sync 高可用一致性 Hash + Zookeeper 方案

既然一臺(tái)不行，那么就多幾臺(tái)，但如何做高可用呢？

我們率先想到的是一致性 Hash 方式。當(dāng)一臺(tái)或者幾臺(tái)同步服務(wù)器掛掉后，采用 Zookeeper 臨時(shí)節(jié)點(diǎn)的 Watch 機(jī)制監(jiān)聽(tīng)同步服務(wù)器掛掉情況，通知剩余同步服務(wù)器執(zhí)行 reHash ，掛掉服務(wù)的工作由剩余的同步服務(wù)器來(lái)承擔(dān)。通過(guò)一致性 Hash 實(shí)現(xiàn)被同步的業(yè)務(wù)服務(wù)列表的平均分配，基于對(duì)業(yè)務(wù)服務(wù)名的二進(jìn)制轉(zhuǎn)換作為 Hash 的 Key 實(shí)現(xiàn)一致性 Hash 的算法。我們自研了這套算法，發(fā)現(xiàn)平均分配的很不理想，第一時(shí)間懷疑是否算法有問(wèn)題，于是找來(lái) Kafka 自帶的算法（見(jiàn) Utils.murmur2 ），發(fā)現(xiàn)效果依舊不理想，原因還是業(yè)務(wù)服務(wù)名的本身分布就是不平均的，于是又回到自研算法上進(jìn)行了優(yōu)化，基本達(dá)到預(yù)期，下文會(huì)具體講到。但說(shuō)實(shí)話，直到現(xiàn)在依舊無(wú)法做到非常良好的絕對(duì)平均。

③ Sync 高可用主備 + Zookeeper 方案

這個(gè)方案是個(gè)小插曲，當(dāng)一臺(tái)同步服務(wù)器掛掉后，由它的“備”頂上，當(dāng)然主備切換也是基于 Zookeeper 臨時(shí)節(jié)點(diǎn)的 Watch 機(jī)制來(lái)實(shí)現(xiàn)的。后面討論下來(lái)，主備方案，機(jī)器的成本很高，實(shí)現(xiàn)也不如一致性 Hash 優(yōu)雅，最后沒(méi)采用。

④ Sync 高可用一致性 Hash + Etcd 方案

折騰了這么幾次后，發(fā)現(xiàn)同步業(yè)務(wù)服務(wù)列表是持久化在數(shù)據(jù)庫(kù)，同步服務(wù)器掛掉后 ReHash 通知機(jī)制是由 Zookeeper 來(lái)負(fù)責(zé)，兩者能否可以合并到一個(gè)中間件上以降低成本？于是我們想到了 Etcd 方案，即通過(guò)它實(shí)現(xiàn)同步業(yè)務(wù)服務(wù)列表持久化 + 業(yè)務(wù)服務(wù)列表增減的通知 + 同步服務(wù)器掛掉后 ReHash 通知。至此方案最終確定，即兩個(gè)注冊(cè)中心（ Eureka 和 Nacos ）的雙向同步方案，通過(guò) Etcd 來(lái)做橋梁。 

2. Nacos Eureka Sync 落地實(shí)踐

① Nacos Eureka Sync 目標(biāo)原則

注冊(cè)中心遷移目標(biāo)：

• 過(guò)程并非一蹴而就的，業(yè)務(wù)服務(wù)逐步遷移的過(guò)程要保證線上調(diào)用不受影響，例如， A 業(yè)務(wù)服務(wù)注冊(cè)到 Eureka 上， B 業(yè)務(wù)服務(wù)遷移到 Nacos ，A 業(yè)務(wù)服務(wù)和 B 業(yè)務(wù)服務(wù)的互相調(diào)用必須正常；

• 過(guò)程必須保證雙注冊(cè)中心都存在這兩個(gè)業(yè)務(wù)服務(wù)，并且目標(biāo)注冊(cè)中心的業(yè)務(wù)服務(wù)實(shí)例必須與源注冊(cè)中心的業(yè)務(wù)服務(wù)實(shí)例數(shù)目和狀態(tài)保持實(shí)時(shí)嚴(yán)格一致。

注冊(cè)中心遷移原則：

• 一個(gè)業(yè)務(wù)服務(wù)只能往一個(gè)注冊(cè)中心注冊(cè)，不能同時(shí)雙向注冊(cè)；

• 一個(gè)業(yè)務(wù)服務(wù)無(wú)論注冊(cè)到 Eureka 或者 Nacos，最終結(jié)果都是等效的；

• 一個(gè)業(yè)務(wù)服務(wù)在絕大多數(shù)情況下，一般只存在一個(gè)同步任務(wù)，如果是注冊(cè)到 Eureka 的業(yè)務(wù)服務(wù)需要同步到 Nacos，那就有一個(gè) Eureka -> Nacos 的同步任務(wù)，反之亦然；在平滑遷移中，一個(gè)業(yè)務(wù)服務(wù)一部分實(shí)例在 Eureka 上，另一部分實(shí)例在 Nacos 上，那么會(huì)產(chǎn)生兩個(gè)雙向同步的任務(wù)；

• 一個(gè)業(yè)務(wù)服務(wù)的同步方向，是根據(jù)業(yè)務(wù)服務(wù)實(shí)例元數(shù)據(jù)（ Metadata ）的標(biāo)記 syncSource 來(lái)決定。

② Nacos Eureka Sync 問(wèn)題痛點(diǎn)

• Nacos Eureka Sync 同步節(jié)點(diǎn)需要代理業(yè)務(wù)服務(wù)實(shí)例和 Nacos Server 間的心跳上報(bào)。Nacos Eureka Sync 將心跳上報(bào)請(qǐng)求放入隊(duì)列，以固定線程消費(fèi)，一個(gè)同步業(yè)務(wù)服務(wù)節(jié)點(diǎn)處理的服務(wù)實(shí)例數(shù)超過(guò)一定的閾值會(huì)造成業(yè)務(wù)服務(wù)實(shí)例的心跳發(fā)送不及時(shí)，從而造成業(yè)務(wù)服務(wù)實(shí)例的意外丟失；

• Nacos Eureka Sync 節(jié)點(diǎn)宕機(jī)，上面處理的心跳任務(wù)會(huì)全部丟失，會(huì)造成線上調(diào)用大面積失敗，后果不堪設(shè)想；

• Nacos Eureka Sync 已經(jīng)開(kāi)始工作的時(shí)候，從 Eureka 或者 Nacos 上，新上線或者下線一個(gè)業(yè)務(wù)服務(wù)（非實(shí)例），都需要讓 Nacos Eureka Sync 實(shí)時(shí)感知。

③ Nacos Eureka Sync 架構(gòu)思想

• 從各個(gè)注冊(cè)中心獲取業(yè)務(wù)服務(wù)列表，初始化業(yè)務(wù)服務(wù)同步任務(wù)列表，并持久化到 Etcd 集群中；

• 后續(xù)遷移過(guò)程增量業(yè)務(wù)服務(wù)通過(guò) API 接口持久化到 Etcd 集群中，業(yè)務(wù)服務(wù)遷移過(guò)程整合 DevOps 發(fā)布平臺(tái)。整個(gè)遷移過(guò)程全自動(dòng)化，規(guī)避人為操作造成的遺漏；

• 同步服務(wù)訂閱 Etcd 集群獲取任務(wù)列表，并監(jiān)聽(tīng)同步集群的節(jié)點(diǎn)狀態(tài)；

• 同步服務(wù)根據(jù)存活節(jié)點(diǎn)的一致性 Hash 算法，找到處理任務(wù)節(jié)點(diǎn)，后端接口通過(guò) SLB 負(fù)載均衡，刪除任務(wù)指令輪詢到的節(jié)點(diǎn)。如果是自己處理任務(wù)則移除心跳，否則找到處理節(jié)點(diǎn)，代理出去；

• 同步服務(wù)監(jiān)聽(tīng)源注冊(cè)中心每個(gè)業(yè)務(wù)服務(wù)實(shí)例狀態(tài)，將正常的業(yè)務(wù)服務(wù)實(shí)例同步到目標(biāo)注冊(cè)中心，保證雙方注冊(cè)中心的業(yè)務(wù)服務(wù)實(shí)例狀態(tài)實(shí)時(shí)同步；

• 業(yè)務(wù)服務(wù)所有實(shí)例從 Eureka 到 Nacos 后，需要業(yè)務(wù)部門(mén)通知基礎(chǔ)架構(gòu)部手動(dòng)從 Nacos Eureka Sync 同步界面摘除該同步任務(wù)。

④ Nacos Eureka Sync 集群分片及高可用方案

服務(wù)一致性 Hash 分片路由：

• 根據(jù)如上圖 1 多集群部署，為每個(gè)節(jié)點(diǎn)設(shè)置可配置的虛擬節(jié)點(diǎn)數(shù)，使其在 Hash 環(huán)上能均勻分布；

• 根據(jù)業(yè)務(wù)服務(wù)名的 FNV1_32_HASH 算法計(jì)算每個(gè)業(yè)務(wù)服務(wù)的哈希值，計(jì)算該 Hash 值順時(shí)針最近的節(jié)點(diǎn)，將任務(wù)代理到該節(jié)點(diǎn)。

同步節(jié)點(diǎn)宕機(jī)故障轉(zhuǎn)移：

• 節(jié)點(diǎn)監(jiān)聽(tīng)：監(jiān)聽(tīng)其它節(jié)點(diǎn)存活狀態(tài)，配置 Etcd 集群租約 TTL ， TTL 內(nèi)至少發(fā)送 5 個(gè)續(xù)約心跳以保證一旦出現(xiàn)網(wǎng)絡(luò)波動(dòng)避免造成節(jié)點(diǎn)丟失；

• 節(jié)點(diǎn)宕機(jī)：其中某個(gè)節(jié)點(diǎn)宕機(jī)，其任務(wù)轉(zhuǎn)移到其它節(jié)點(diǎn)，因?yàn)橛刑摂M節(jié)點(diǎn)的緣已經(jīng)故，所以此節(jié)點(diǎn)的任務(wù)會(huì)均衡 ReSharding 到其它節(jié)點(diǎn)，那么，集群在任何時(shí)候，任務(wù)處理都是分片均衡的，如上圖 2 中， B 節(jié)點(diǎn)宕機(jī)， ##1 、 ##2 虛擬節(jié)點(diǎn)的任務(wù)會(huì)分別轉(zhuǎn)移到 C 和 A 節(jié)點(diǎn)，這樣避免一個(gè)節(jié)點(diǎn)承擔(dān)宕機(jī)節(jié)點(diǎn)的所有任務(wù)造成剩余節(jié)點(diǎn)連續(xù)雪崩；

• 節(jié)點(diǎn)恢復(fù)：如圖 3，節(jié)點(diǎn)的虛擬節(jié)點(diǎn)重新添加到 Hash 環(huán)中， Sharding 規(guī)則變更，恢復(fù)的節(jié)點(diǎn)會(huì)根據(jù)新的 Hash 環(huán)規(guī)則承擔(dān)其它節(jié)點(diǎn)的一部分任務(wù)，心跳任務(wù)一旦在節(jié)點(diǎn)產(chǎn)生都不會(huì)自動(dòng)消失，這時(shí)需要清理其它節(jié)點(diǎn)的多余任務(wù)（即重新分配給復(fù)蘇節(jié)點(diǎn)的任務(wù)），給其它節(jié)點(diǎn)減負(fù)（這一步非常關(guān)鍵，不然也可能會(huì)引發(fā)集群的連續(xù)雪崩），保障集群恢復(fù)到最初正常任務(wù)同步狀態(tài)；

• 節(jié)點(diǎn)容災(zāi)：如果 Etcd 集群連接不上，則存活節(jié)點(diǎn)從配置文件中獲取，集群正常運(yùn)作，但是會(huì)失去容災(zāi)能力。

3. Nacos Eureka Sync 保障手段

① Nacos Eureka Sync 同步界面

從如下界面可以保證，從 Eureka 或者 Nacos 上，新上線或者下線一個(gè)業(yè)務(wù)服務(wù)（非實(shí)例），都能讓 Nacos Eureka Sync 實(shí)時(shí)感知。但我們做了更進(jìn)一層的智能化和自動(dòng)化： 

• 新增同步：結(jié)合 DevOps 發(fā)布平臺(tái)，當(dāng)一個(gè)業(yè)務(wù)服務(wù)（非實(shí)例）新上線的時(shí)候，智能判斷它是從哪個(gè)注冊(cè)中心上線的，然后回調(diào) Nacos Eureka Sync 接口，自動(dòng)添加同步接口，例如，A 業(yè)務(wù)服務(wù)注冊(cè)到 Eureka 上，DevOps 發(fā)布平臺(tái)會(huì)自動(dòng)添加它的 Eureka -> Nacos 的同步任務(wù)，反之亦然。當(dāng)然從如下界面的操作也可實(shí)現(xiàn)該功能；

• 刪除同步：由于 DevOps 發(fā)布平臺(tái)無(wú)法判斷一個(gè)業(yè)務(wù)服務(wù)（非實(shí)例）下線，或者已經(jīng)遷移到另一個(gè)注冊(cè)中心，已經(jīng)全部完畢（有同學(xué)會(huì)反問(wèn)，可以判斷的，即查看那個(gè)業(yè)務(wù)服務(wù)的實(shí)例數(shù)是否是零為標(biāo)準(zhǔn)，但我們應(yīng)該考慮，實(shí)例數(shù)為零在網(wǎng)絡(luò)故障的時(shí)候也會(huì)發(fā)生，即心跳全部丟失，所以這個(gè)判斷依據(jù)是不嚴(yán)謹(jǐn)?shù)模挥蓸I(yè)務(wù)人員來(lái)判斷，同時(shí)配合釘釘機(jī)器人告警提醒，由基礎(chǔ)架構(gòu)部同學(xué)從如下界面的操作實(shí)現(xiàn)該功能。

② Nacos Eureka Sync Etcd 監(jiān)控

從如下界面可以監(jiān)控到，業(yè)務(wù)服務(wù)列表是否在同步服務(wù)的集群上呈現(xiàn)一致性 Hash 均衡分布。

③ Nacos Eureka Sync 告警

• Nacos Eureka Sync 告警

• 業(yè)務(wù)服務(wù)同步完畢的告警

4.Nacos Eureka Sync 升級(jí)演練

• 7 月某天晚上 10 點(diǎn)開(kāi)始， FAT 環(huán)境進(jìn)行演練，通過(guò)自動(dòng)化運(yùn)維工具 Ansible 兩次執(zhí)行一鍵升級(jí)和回滾均沒(méi)問(wèn)題；

• 晚上 11 點(diǎn) 30 開(kāi)始，執(zhí)行災(zāi)難性操作，觀察智能恢復(fù)狀況， 9 臺(tái) Nacos Eureka Sync 掛掉 3 臺(tái)的操作，只丟失一個(gè)實(shí)例，但 5 分鐘后恢復(fù)（經(jīng)調(diào)查，問(wèn)題定位在 Eureka 上某個(gè)業(yè)務(wù)服務(wù)實(shí)例狀態(tài)異常）；

• 晚上 11 點(diǎn) 45 開(kāi)始，繼續(xù)掛掉 2 臺(tái)，只剩 4 臺(tái)，故障轉(zhuǎn)移，同步正常；

• 晚上 11 點(diǎn) 52 開(kāi)始，恢復(fù) 2 臺(tái)，Nacos Eureka Sync 集群重新均衡 ReHash ，同步正常；

• 晚上 11 點(diǎn) 55 開(kāi)始，全部恢復(fù)，Nacos Eureka Sync 集群重新均衡 ReHash ，同步正常；

• 12 點(diǎn) 14 分，極限災(zāi)難演練， 9 臺(tái)掛掉 8 臺(tái)，剩 1 臺(tái)也能抗住，故障轉(zhuǎn)移，同步正常；

• 凌晨 12 點(diǎn) 22 分，升級(jí) UAT 環(huán)境順利；

• 凌晨 1 點(diǎn) 22，升級(jí) PROD 環(huán)境順利；

• 容災(zāi)恢復(fù)中的 ReHash 時(shí)間小于 1 分鐘，即 Nacos Eureka Sync 服務(wù)大面積故障發(fā)生時(shí)，恢復(fù)時(shí)間小于 1 分鐘。

三.Solar 云原生微服務(wù)實(shí)踐

（Solar 云原生微服務(wù)體系）

Solar 微服務(wù)體系，囊括微服務(wù)治理組件，中間件以及基礎(chǔ)組件易用性封裝，告警監(jiān)控體系等，連接著掌門(mén)業(yè)務(wù)服務(wù)和底層基礎(chǔ)設(shè)施，每項(xiàng)服務(wù)都遵守強(qiáng)有力的合約，向著云原生微服務(wù)架構(gòu)方向演進(jìn)。 

1. 基于 Spring Cloud Alibaba、Nacos、Sentinel 等 SDK

① Alibaba Nacos

• Solar Nacos SDK 內(nèi)置 DEV | FAT | UAT | PROD 四個(gè)環(huán)境的域名，業(yè)務(wù)系統(tǒng)無(wú)感知 Solar Nacos SDK 基于 Spring Cloud Alibaba 整合攜程 VI Cornerstone 實(shí)現(xiàn)微服務(wù)點(diǎn)火熄火拉入拉出；

• Solar Nacos SDK 在 Nacos 和 Eureka 雙注冊(cè)中心過(guò)渡狀態(tài)下， 支持跨注冊(cè)中心調(diào)用的藍(lán)綠灰度發(fā)布和子環(huán)境功能；

• Solar Nacos SDK 集成灰度藍(lán)綠埋點(diǎn)到 SkyWalking；

• Solar Nacos SDK 通過(guò) @EnableSolarService  ， @EnableSolarGateway  封裝了標(biāo)準(zhǔn) Spring Boot / Spring Cloud / Apollo / Zuul 等大量注解，降低業(yè)務(wù)的使用成本；

• Solar Nacos SDK 和 Solar Eureka SDK 升級(jí)和回滾；

• Solar Nacos SDK 結(jié)合 Java Agent 方式，解決異步調(diào)用場(chǎng)景下的跨線程調(diào)用的上下文丟失。

②  Alibaba Sentinel

• Solar Sentinel SDK 內(nèi)置 DEV | FAT | UAT | PROD 四個(gè)環(huán)境的域名，業(yè)務(wù)系統(tǒng)無(wú)感知

• SDK通過(guò)獲取當(dāng)前機(jī)器所在的環(huán)境，適配當(dāng)前所要連接的Sentinel地址

• Solar Sentinel SDK 深度集成 Apollo SDK

• Sentinel配置，持久化到服務(wù)的apollo的namespace下面，下次重啟從apollo獲取配置加載到內(nèi)存

• 以appId的維度配置應(yīng)用熔斷限流規(guī)則

• Solar Sentinel SDK 整合 OpenTracing & SkyWalking，輸出 Sentinel 埋點(diǎn)到 SkyWalking

• 通過(guò)SkyWalking提供的OpenTracing 工具包，手動(dòng)埋點(diǎn)，獲取span信息，推送到SkyWalking持久化到ES

• Solar Sentinel SDK Dashboard 持久化改造，集成 InfluxDB & Grafana

• 將Sentinel Metrics數(shù)據(jù)持久化到時(shí)序數(shù)據(jù)庫(kù)InfluxDB中，然后通過(guò)Grafana 展示

• Solar Sentinel SDK Limit-App 熔斷擴(kuò)展 （特色功能：灰度藍(lán)綠發(fā)布指標(biāo)的熔斷）

• 灰度藍(lán)綠調(diào)用時(shí)，如果探測(cè)到版本匹配失敗時(shí)，則拋BlockException

• Solar Sentinel SDK 網(wǎng)關(guān)流控 ，微服務(wù)單機(jī)限流

• 全鏈路壓測(cè)幫助了解服務(wù)能承載流量峰值

• 信號(hào)量隔離/QPS, 并發(fā)線程數(shù)限流/平均響應(yīng)時(shí)間、秒級(jí)異常比率、分鐘級(jí)異常數(shù)熔斷

• 基于 TCP BBR 的系統(tǒng)保護(hù)算法，自動(dòng)探測(cè)系統(tǒng)瓶頸，保護(hù)系統(tǒng)穩(wěn)定性

• Solar Sentinel SDK 集群限流

• 通過(guò)集群限流來(lái)解決集群各個(gè)機(jī)器的流量不均導(dǎo)致整體限流效果不精確的問(wèn)題

2. 灰度藍(lán)綠和環(huán)境隔離

• 基于 Spring Cloud Alibaba 、Nacos SDK、Nepxion Discovery 開(kāi)源框架（https://github.com/Nepxion/Discovery）

• 藍(lán)綠灰度發(fā)布 ：版本匹配灰度發(fā)布、版本權(quán)重灰度發(fā)布

• 多區(qū)域路由：區(qū)域匹配灰度路由、區(qū)域權(quán)重灰度路由

• 環(huán)境隔離：環(huán)境隔離、環(huán)境路由

3. 基于 DevOps 發(fā)布平臺(tái)的智能化和半自動(dòng)化灰度藍(lán)綠

• **智能化發(fā)布入口界面 **

• 藍(lán)綠條件驅(qū)動(dòng)模式界面

• 藍(lán)綠權(quán)重放量模式界面

• 全量發(fā)布和回滾界面

4. 基于 DevOps 發(fā)布平臺(tái)的滾動(dòng)無(wú)損發(fā)布

1. 運(yùn)維 CD 發(fā)布平臺(tái)，先將實(shí)例狀態(tài)設(shè)置 disabled ，實(shí)例從注冊(cè)中心拉出；

2. 消費(fèi)者訂閱注冊(cè)中心，通知消費(fèi)者實(shí)例處于不可用狀態(tài)；

3. 消費(fèi)者停止路由轉(zhuǎn)發(fā)到不可用實(shí)例；

4. 服務(wù)上面流量繼續(xù)處理，30S 后才會(huì)啟動(dòng)實(shí)例發(fā)布腳本；

5. 實(shí)例重啟成功后，CD 平臺(tái)通過(guò)請(qǐng)求寄宿在業(yè)務(wù) Web 容器里的 VI 接口檢測(cè)實(shí)例健康狀態(tài)；

6. 狀態(tài)檢測(cè)健康后，注冊(cè)到 Nacos 注冊(cè)中心；

7. 消費(fèi)者訂閱到新的實(shí)例，請(qǐng)求正常負(fù)載。

5. 分布式追蹤和 APM 系統(tǒng) SkyWalking

• 所有服務(wù)異常監(jiān)控大盤(pán)

• 接口性能指標(biāo)

• 服務(wù)維度的異常監(jiān)控看板，聚合鏈路中異常數(shù)量，幫助業(yè)務(wù)快速定位問(wèn)題

• 集成 Solar 全鏈路灰度藍(lán)綠埋點(diǎn)

• 集成 Sentinel 限流降級(jí)熔斷埋點(diǎn)

• 整合服務(wù)、實(shí)例、接口維度性能指標(biāo)

• 快速定位異常、慢 SQL、熔斷鏈路

• 整合鏈路與日志

• 服務(wù)、實(shí)例、接口、鏈路維度拓?fù)鋱D

• 整合應(yīng)用診斷系統(tǒng)（Arthas & Bistoury)

6. 應(yīng)用診斷系統(tǒng) Arthas & Bistoury

• 無(wú)需登錄機(jī)器

• 整合 Arthas，Web 化控制臺(tái)  從 CPU 、線程、內(nèi)存、JVM 等方面對(duì)應(yīng)用進(jìn)行診斷

• 熱點(diǎn)方法分析

• 在線 Debug 

四. Solar 云原生容器化實(shí)踐

1. CI/CD 持續(xù)發(fā)布

• CD Platform 通過(guò) jinkens 編譯打包生成 Jar 包和 Docker img，通過(guò) Harbor 上傳鏡像到 OSS 平臺(tái)，Harbor 通過(guò) SLB 做高可用；

• 自研 Hyperion 中間服務(wù)，作為連接 Harbor 和阿里云 K8s 的 API 調(diào)用中間層；

• CD Platform 通過(guò) Hyperion 調(diào)用阿里云 K8s API 發(fā)布鏡像，K8s 從 Harbor 拉取鏡像，deploy 到物理節(jié)點(diǎn)；

• 阿里云 K8s 推送狀態(tài)事件給 Hyperion，Hyperion 將數(shù)據(jù)推送給 .CD Platform 實(shí)時(shí)展示發(fā)布狀態(tài)信息。

2. 日志收集

1. Pod 將日志寫(xiě)到容器內(nèi)的路徑 /opt/logs/{appid}/xxx；

2. 建立軟連接指向 Node 路徑 /var/log/{appid}/{podid}/xxx；

3. 一個(gè)物理節(jié)點(diǎn)啟動(dòng)一個(gè) FileBeat 進(jìn)程收集此物理節(jié)點(diǎn)上所有 Pod 日志信息；

PS：經(jīng)過(guò)全面的壓測(cè)，一個(gè)物理節(jié)點(diǎn)上啟動(dòng)一個(gè) FileBeat 進(jìn)程收集所有 Pod 日志，性能沒(méi)有問(wèn)題 如果存在日志收集不及時(shí)問(wèn)題，則可以一個(gè) Pod 掛載一個(gè) FileBeat 進(jìn)程來(lái)解決，這樣的缺點(diǎn)是會(huì)占用更多系統(tǒng)資源。

4. FileBeat 將日志信息推送到 Kafka；

5. GoHangout 并發(fā)消費(fèi) Kafka 中數(shù)據(jù)，持久化到 ES 集群中；

GoHangout 并發(fā)消費(fèi) Kafka 消息性能比較好。

6. Kibana 顯示 ES 中所有日志索引數(shù)據(jù)。

3. 微服務(wù)彈性擴(kuò)容和自愈

• CPU 負(fù)載

• Memory

• Metrics：根據(jù)熔斷、限流、監(jiān)控等組件提供的 Metric 指標(biāo)做彈性伸縮和自愈；

• 根據(jù)課堂排課信息的容量規(guī)劃：如下圖掌門(mén)上課情況非常規(guī)律，流量峰值也規(guī)律分布，根據(jù)排課信息等數(shù)據(jù)來(lái)規(guī)劃未來(lái)幾小時(shí)內(nèi)微服務(wù)需要承載容量，并按照計(jì)劃，分配 Pod 數(shù)量

4. 平滑遷移網(wǎng)絡(luò)解決方案

•  Terway Kubernetes 集群提供 CNI Plugin 實(shí)現(xiàn) Pod IP、Node IP 處于同一平面；

• Pod 每次發(fā)布 IP 都會(huì)發(fā)生變化，內(nèi)網(wǎng)沿用虛擬機(jī)時(shí)代的訪問(wèn)和治理方案；

• 外網(wǎng)訪問(wèn)通過(guò)阿里云 SLB，SLB 能自動(dòng)探測(cè) IP 變化；

• 基礎(chǔ)架構(gòu)在微服務(wù)構(gòu)建上面已經(jīng)有很深的積累，充分利用 Spring Cloud Alibaba 以及 Nacos 等一系列服務(wù)治理方案 ，使我們?cè)圃萜骰^(guò)程能夠平滑遷移到阿里云 K8s。

上述就是小編為大家分享的如何基于Spring Cloud Alibaba構(gòu)建微服務(wù)體系了，如果剛好有類似的疑惑，不妨參照上述分析進(jìn)行理解。如果想知道更多相關(guān)知識(shí)，歡迎關(guān)注億速云行業(yè)資訊頻道。