作者 | 殷銘??顏鋪科技架構(gòu)師

本文整理自架構(gòu)師成長系列 3 月 19 日直播課程。
關(guān)注“阿里巴巴云原生”公眾號(hào)，回復(fù)?“319”，即可獲取對(duì)應(yīng)直播回放鏈接及 PPT 下載鏈接。

**導(dǎo)讀：**顏鋪科技因美業(yè)??，“顏鋪專家”是一款專為美業(yè)商家打造的 SaaS 平臺(tái)，為了能夠給商戶提供更加安全、穩(wěn)定、高效的平臺(tái)，我們在技術(shù)方面做了很多嘗試，經(jīng)過幾次演進(jìn)，使系統(tǒng)變得更加穩(wěn)定可靠。今天主要和大家分享一下顏鋪科技的架構(gòu)演進(jìn)，以及 Nacos 在顏鋪的應(yīng)用實(shí)踐。

單體應(yīng)用時(shí)代

上圖是我們單體服務(wù)時(shí)的架構(gòu)圖，分為會(huì)員、訂單、門店等很多模塊，看架構(gòu)圖似乎還算清晰，但是真正看到包結(jié)構(gòu)的時(shí)候，真的令人頭禿!改起代碼特別頭痛。單體服務(wù)帶來的幾個(gè)挑戰(zhàn)：

• **發(fā)布周期慢：**雖然當(dāng)時(shí)業(yè)務(wù)量不算大，但是代碼量很大，業(yè)務(wù)迭代牽一發(fā)而動(dòng)全身，每次發(fā)布需要對(duì)整個(gè)服務(wù)進(jìn)行重新編譯打包部署。特別是最開始在沒有構(gòu)建工具的時(shí)候，發(fā)布過程需要一堆的命令，總有一種 **“一頓操作猛如虎，定睛一看原地杵”?**的感覺。

• **協(xié)同效率低：**合并沖突多，有時(shí)你在前面開心地寫代碼，而別人在解決沖突時(shí)，可能也在開心地刪著你的代碼，增加了很多的溝通成本。

• **穩(wěn)定性差：**當(dāng)服務(wù)出現(xiàn)故障時(shí)，可能會(huì)導(dǎo)致整個(gè)系統(tǒng)不可用，并且系統(tǒng)不易擴(kuò)容，當(dāng)商戶搞促銷時(shí)，可能活動(dòng)結(jié)束了，服務(wù)器還沒有擴(kuò)容完成。

• **性能差：**因?yàn)樵趩误w服務(wù)內(nèi)，有些開發(fā)人員為了滿足自己的業(yè)務(wù)，很多無關(guān)業(yè)務(wù)間 SQL 聯(lián)表查詢，并且不關(guān)注性能問題，導(dǎo)致線上時(shí)常出現(xiàn)負(fù)載警告。

另外，我們在業(yè)務(wù)上也遇到了一些挑戰(zhàn)：

• **業(yè)務(wù)轉(zhuǎn)型：?**2018 年 6 月，我們公司決定從泛行業(yè)轉(zhuǎn)向美業(yè)，需要打造一個(gè)專為美業(yè)商戶提供技術(shù)支持的麗人 SaaS 平臺(tái)。

• **快速占領(lǐng)市場：**業(yè)務(wù)的轉(zhuǎn)型帶來了更多商戶的新需求，如果不能快速迭代，則意味著被市場淘汰。因此，提升開發(fā)效率，快速占領(lǐng)市場成為我們急需解決的問題。

• **商戶體驗(yàn)差：**隨著越來越多的商戶入住，性能和可靠性的問題逐漸顯現(xiàn)，出現(xiàn)問題，不能及時(shí)修正，商戶體驗(yàn)變得很差，違背我們客戶第一的原則。

綜上所述，我們認(rèn)為進(jìn)行服務(wù)化改造刻不容緩。

微服務(wù)改造

經(jīng)過公司開發(fā)同學(xué)們的討論，我們最終決定分兩步進(jìn)行改造：
服務(wù)化改造 1.0 的目標(biāo)：

• 用最小的改造成本先將新、舊商戶平臺(tái)進(jìn)行打通，做到功能上的快速遷移；
• 業(yè)務(wù)抽象，將新舊商戶中心的公用部分進(jìn)行抽象，并優(yōu)化舊商戶中心的代碼邏輯，為后續(xù)的業(yè)務(wù)中臺(tái)建設(shè)做好鋪墊。

服務(wù)化改造 2.0 的目標(biāo)：初步建設(shè)業(yè)務(wù)中臺(tái)，讓平臺(tái)的各種能力能夠快速復(fù)用、快速組合，支持業(yè)務(wù)更快捷地探索與發(fā)展。
服務(wù)化改造 1.0 預(yù)期效果：

• 我們希望老商戶中心在對(duì)外提供服務(wù)的同時(shí)，還能夠作為提供者，對(duì)新商戶中心提供服務(wù)支持；
• 新商戶中心僅對(duì)外提供服務(wù)，不直連數(shù)據(jù)庫，業(yè)務(wù)層只對(duì)美業(yè)的特殊邏輯進(jìn)行處理。

因此，我們的想法是：新商戶中心直接調(diào)用舊商戶中心通過 Controller 暴露出的接口，進(jìn)行遠(yuǎn)程調(diào)用，于是我們決定嘗試使用 Spring Cloud 。

服務(wù)發(fā)現(xiàn)選型：

• Consul 支持服務(wù)發(fā)現(xiàn)的同時(shí)，支持 kv 存儲(chǔ)服務(wù)，因?yàn)槲覀兿胱鲆粋€(gè)配置中心的 KV 存儲(chǔ)，所以想利用 Consul 做一個(gè)嘗試；
• 服務(wù)健康檢查相對(duì)更為詳細(xì)；
• 在我們選型的期間，突然出現(xiàn)了 Eureka 2.x 開源工作宣告停止的消息，雖然后來發(fā)現(xiàn)，這個(gè)對(duì)我們并沒有什么太大的影響，但在當(dāng)時(shí)的決策讓我們最終選擇了 Consul 。

服務(wù)化改造 1.0 架構(gòu)圖：

服務(wù)化 1.0 我們的技術(shù)改造方案是：將舊的商戶中心注冊到 Consul 上面，新商戶中心到 Consul 上獲取服務(wù)器列表，通過 Feign 進(jìn)行遠(yuǎn)程調(diào)用，打通了新老商戶中心的功能。

經(jīng)過服務(wù)化 1.0 的改造，我們解決了如下幾個(gè)問題：

• **功能快速完善：**舊商戶中心的功能快速遷移到了新的商戶中心，并完成對(duì)美業(yè)的適配；
• **迭代速度加快：**新商戶中心大部分功能，能夠通過舊商戶中心進(jìn)行修改兼容，為后續(xù)的業(yè)務(wù)中臺(tái)的抽象打好基礎(chǔ)；
• **性能優(yōu)化：**業(yè)務(wù)開發(fā)的同時(shí)，我們對(duì)舊商戶中心的老代碼進(jìn)行優(yōu)化，性能和穩(wěn)定性均有所提高。

但服務(wù)化 1.0 改造后，還是有一些挑戰(zhàn)沒有解決：

• **發(fā)布周期依舊不夠快：**大部分代碼還是在就商戶中心，業(yè)務(wù)迭代依然牽一發(fā)而動(dòng)全身；
• **協(xié)同效率沒有提高：**在代碼沖突多，溝通成本高的同時(shí)，又出現(xiàn)了令開發(fā)同學(xué)頭痛的新老業(yè)務(wù)的兼容問題；
• **維護(hù)成本：**Consul 是 Go 語言開發(fā)的，不易維護(hù)；Spring Cloud 在開發(fā)過程中體驗(yàn)不佳，在寫業(yè)務(wù)的同時(shí)，還要摸索 Spring Cloud 的最佳實(shí)踐，花費(fèi)了一些時(shí)間去做 Spring Cloud 的基礎(chǔ)建設(shè)。

于是我們決定開啟，服務(wù)化 2.0 的改造。
服務(wù)化改造 2.0 的預(yù)期效果：

• 完成業(yè)務(wù)中臺(tái)的初步建設(shè)，將模塊重新劃分，抽象為獨(dú)立服務(wù)；
• 新、舊商戶中心服務(wù)僅做自己的業(yè)務(wù)兼容，并對(duì)外暴露接口；
• 新增專門支持 H5、小程序 的 C 端 WEB 服務(wù)。?因 Spring Cloud 體驗(yàn)不佳，我們決定服務(wù)化改造 2.0 嘗試使用 Dubbo 作為基礎(chǔ)服務(wù)的 RPC 遠(yuǎn)程調(diào)用框架，因此我們要對(duì)注冊中心進(jìn)行選型。

首先，注冊中心我認(rèn)為應(yīng)該具備的基本功能 ：

• 服務(wù)注冊及時(shí)被發(fā)現(xiàn)，異常時(shí)的及時(shí)下線；
• 服務(wù)管理，能夠手動(dòng)恢復(fù)/剔除服務(wù)；
• 健康檢查，檢測服務(wù)是否可用；
• 元數(shù)據(jù)管理；
• 注冊中心保證自身的高可用。

Zookeeper :

• 不能保證每次服務(wù)請(qǐng)求都是可達(dá)的，當(dāng) zk 集群 master 掛掉時(shí)，需要進(jìn)行選舉，在選舉期間中，服務(wù)是不可用的；
• 不支持跨機(jī)房的路由，比如 eureka 的 zone，當(dāng)前機(jī)房不可用時(shí)，可以路由到其他機(jī)房；
• “驚群效應(yīng)”，?zk 的節(jié)點(diǎn)過多的時(shí)候，當(dāng) service 的節(jié)點(diǎn)發(fā)生變更，會(huì)同時(shí)通知到客戶端，瞬時(shí)流量有可能將網(wǎng)卡瞬間打滿，并且會(huì)有重復(fù)通知的問題。

Nacos :

• 注冊中心部分更側(cè)重于可用性
• 服務(wù)發(fā)現(xiàn)與服務(wù)管理
• 服務(wù)元數(shù)據(jù)的管理
• 動(dòng)態(tài)配置管理

在此期間，我們也關(guān)注到了 Spring Cloud Alibaba。阿里巴巴技術(shù)經(jīng)受多年“雙十一”的考驗(yàn)，其性能和穩(wěn)定性是值得信任的。Spring Cloud Alibaba 的組件開源社區(qū)活躍度很高，并且比起國外開源項(xiàng)目更容易交流。其組件由 Java 語言開發(fā)，對(duì)我們來說更易維護(hù)，在出現(xiàn)問題時(shí)能夠更快地定位問題進(jìn)行修復(fù)。而且與阿里云配合，更加容易上云，比如 Nacos 可以與阿里云的 MSE 和 ACM 配合，將注冊中心及配置管理全部上云。?

因此，我們決定擁抱阿里技術(shù)棧。

服務(wù)化改造2.0架構(gòu)圖：

我們將之前的模塊直接抽到基礎(chǔ)服務(wù)之中，新增了 會(huì)員、訂單、門店 等服務(wù)作為Provider，暴露自己的Service，并注冊到 Nacos 上。新商戶中心服務(wù)做美業(yè)業(yè)務(wù)邏輯的處理，舊商戶中心服務(wù)做泛行業(yè)的業(yè)務(wù)處理，C端服務(wù)同理對(duì)外提供服務(wù)。通過 Dubbo 進(jìn)行遠(yuǎn)程調(diào)用。

通過服務(wù)化 2.0?的改造，效果如下：

• 服務(wù)器成本降低30%：20+臺(tái)服務(wù)器，由4核16G 降配到2核8G；
• 系統(tǒng)可靠性提升80%：load 告警明顯減少，線上的問題修正能夠快速修復(fù)，完成部署；
• 代碼沖突減少75%：因?yàn)檫吔缬辛嘶靖髯跃S護(hù)，沖突顯著減少；
• 發(fā)布迭代效率提升50%：之前5個(gè)人每個(gè)迭代開發(fā)評(píng)估可完成30個(gè)點(diǎn)，現(xiàn)在可完成45個(gè)點(diǎn)左右。

Nacos 落地實(shí)踐與問題分析

Nacos 在我們公司處理做注冊中心之外，配置管理也對(duì)我們提供了很好的服務(wù)。下面說一下，Nacos 我們的使用情況，以及我們遇到的問題。

首先是使用情況：

• 部署方式：開發(fā)/測試環(huán)境單機(jī)部署，生產(chǎn)環(huán)境 3 臺(tái)集群部署；
• 版本：生產(chǎn)環(huán)境從?0.9.0?開始使用，目前生產(chǎn)環(huán)境使用的版本為 1.1.4 ；
• 使用時(shí)間：2019 年 3 月份開始在生產(chǎn)環(huán)境下使用；
• 服務(wù)數(shù)量：線上 20+?臺(tái)服務(wù)器，提供了 600+?個(gè)服務(wù)；
• 穩(wěn)定性：一年的時(shí)間里沒有出現(xiàn)大的問題，并且平滑升級(jí)；
• 兼容性：新老服務(wù)，在我們公司無論是 Spring 4.3+?的工程，還是 Spring Boot 的工程均兼容良好。

Nacos 注冊中心：

• 服務(wù)注冊：將后端服務(wù)注冊到 Nacos，通過 Dubbo 進(jìn)行調(diào)用。目前開發(fā)環(huán)境中我們正在測試Seata，并且也將 Seata 服務(wù)注冊到 Nacos 上；
• Namespace：服務(wù)統(tǒng)一注冊到 public 中。

Nacos 配置管理：

每個(gè)服務(wù)設(shè)置獨(dú)立的 Namespace 。

• 服務(wù)的配置文件信息：application.properties 全部配置到 Nacos，工程的配置文件僅保留 Nacos 相關(guān)配置；
• 業(yè)務(wù)層的 KV 配置：比如業(yè)務(wù)開關(guān)，屬性默認(rèn)值，定時(shí)任務(wù)配置等；
• MQ Topic 的動(dòng)態(tài)配置：Binlog 服務(wù)采集動(dòng)態(tài)發(fā)送到在 Nacos 配置的 topic 及其需要的表信息；
• Sentinel 的規(guī)則配置：Sentinel 限流規(guī)則持久化到 Nacos 。

問題描述：

2019 年 12 月 31 日，下午 3 點(diǎn) 15 分左右，線上突然出現(xiàn)大量服務(wù)告警，Dubbo 服務(wù)出現(xiàn)報(bào)錯(cuò)，整個(gè)過程持續(xù)約 3 多分鐘。各個(gè)業(yè)務(wù)組當(dāng)天均沒有任何發(fā)布，數(shù)據(jù)庫狀態(tài)也良好。

通過日志發(fā)現(xiàn)，報(bào)錯(cuò)原因是門店服務(wù)無法調(diào)用。而門店服務(wù)日志，出現(xiàn)問題的時(shí)間段內(nèi)，沒有任何的調(diào)用記錄。系統(tǒng)恢復(fù)正常時(shí)，出現(xiàn)了很多服務(wù)注冊的通知。

因此，我們將問題瞄準(zhǔn)了 Nacos。查看 Nacos 的日志發(fā)現(xiàn)，在系統(tǒng)恢復(fù)過程中，有大量的服務(wù)正在上線。

就在排查的過程中，線上突然又出現(xiàn)了之前相同的告警，Nacos 上的服務(wù)列表開始大量變成不健康的狀態(tài)，于是我們緊急重啟了線上的 Nacos ，在這期間又經(jīng)歷了一個(gè) 3 分多鐘的驚魂后，再次恢復(fù)了平靜。

問題分析：

• 兩次出現(xiàn)的問題均是門店服務(wù)，但出現(xiàn)問題期間 JVM 和數(shù)據(jù)庫的運(yùn)行狀態(tài)均良好；
• 報(bào)錯(cuò)信息都是 Dubbo 調(diào)用超時(shí)，且出現(xiàn)問題期間，門店服務(wù)沒有任何流量進(jìn)入；
• 出現(xiàn)問題時(shí)，注冊在 Nacos 上的服務(wù)開始大量不健康。恢復(fù)正常時(shí)，這些服務(wù)又開始上線，說明出現(xiàn)問題時(shí)，服務(wù)被下線又重新上線。

綜上，我們開始懷疑是網(wǎng)絡(luò)原因造成的。

問題確認(rèn)：

經(jīng)過排查，發(fā)現(xiàn)我們的服務(wù)大多部署在 阿里云華東 1 可用區(qū) B ，只有門店服務(wù)和 Nacos 集群沒有部署在可用區(qū) B ，說明這段時(shí)間可用區(qū) B 與其他區(qū)之間的發(fā)生了網(wǎng)絡(luò)隔離。

于是，我們在可用區(qū) B 緊急部署了門店服務(wù)，之后沒有再出現(xiàn)問題。

經(jīng)過與阿里云的溝通確認(rèn)于北京時(shí)間 2019 年 12 月 31 日 14:05 分左右開始，部分用戶反饋阿里云華東 1 地域可用區(qū) B 部分網(wǎng)絡(luò)出現(xiàn)異常，影響部分云資源訪問。

問題復(fù)盤：

• 問題出現(xiàn)：下午 3 點(diǎn)多，突然連續(xù)出現(xiàn)的服務(wù)告警， Dubbo 服務(wù)出現(xiàn)報(bào)錯(cuò)；
• Nacos：Nacos 服務(wù)列表里大量服務(wù)出現(xiàn)不健康的狀態(tài)；
• 網(wǎng)絡(luò)不通：可用區(qū) B 與其它區(qū)網(wǎng)絡(luò)不通，導(dǎo)致服務(wù)無法調(diào)用；
• 緊急部署：在 B 區(qū)部署缺失的 門店服務(wù)；
• 恢復(fù)正常。

問題思考：

• 服務(wù)部署：應(yīng)用服務(wù)和Nacos建議多機(jī)房部署，即使在云上可用區(qū)之間也需要考慮；
• 容災(zāi)：問題出現(xiàn)時(shí)，可用區(qū) B 并沒有部署 Nacos，但可用區(qū)B內(nèi)的服務(wù)之間依然能調(diào)通，且能夠讀到 Nacos 上的配置。因此，我們認(rèn)為 Nacos 以及 Dubbo 的容災(zāi)策略都是值得信賴的。

回顧與展望：

“顏鋪專家”經(jīng)過不斷地快速迭代，幫助美業(yè)商家?效快捷地管理門店，進(jìn)行經(jīng)營數(shù)據(jù)分析，數(shù)據(jù)化管理門店，建?完善的會(huì)員周期管理體系，為美業(yè)商家在經(jīng)營管理中，提供?體化的解決方案，將美業(yè)傳統(tǒng)的門店經(jīng)營模式進(jìn)?互聯(lián)網(wǎng)升級(jí)。截止到目前我們累計(jì)服務(wù) 3000 多個(gè)品牌，1.1W + 個(gè)?店。我們提供了店務(wù)管理系統(tǒng)、會(huì)員管理系統(tǒng)、營銷拓客系統(tǒng)、大數(shù)據(jù)決策系統(tǒng)、供應(yīng)鏈管理系統(tǒng)、員工績效管理系統(tǒng)6?系統(tǒng)能力，同時(shí)?持 PC 端、手機(jī) APP 、 pos 機(jī)、 iPad 操作，滿??店多端操作需求，覆蓋?店經(jīng)營管理中的所有場景需求。

未來規(guī)劃

提升系統(tǒng)高可用

• **Seata ：**目前我們公司的分布式事務(wù)主要依賴 MQ 的補(bǔ)償，今年準(zhǔn)備引入 Seata 來完善分布式事務(wù)，保證數(shù)據(jù)一致性，減少開發(fā)修數(shù)據(jù)的情況；

• **Sentinel ：**目前 Sentinel 我們只是在商戶做活動(dòng)時(shí)啟用，因此我們要配置出適用于我們公司的最佳實(shí)踐，保證系統(tǒng)的高可用；

• **全鏈路跟蹤：**我們公司現(xiàn)在定位問題主要靠日志和告警，做不到全鏈路的跟蹤，所以我們要把這部分做好，做到故障快速定位，各調(diào)用環(huán)節(jié)性能分析，以及數(shù)據(jù)分析；

• **異地容災(zāi)：**隨著來自全國各省的商戶越來越多，我們需要對(duì)商戶的數(shù)據(jù)保障，避免數(shù)據(jù)丟失，確保服務(wù)的可靠性。

社區(qū)回饋

因?yàn)槲覀兊墓倔w量現(xiàn)在不大，我們能夠做到的是盡可能地使用最新的版本，及時(shí)嘗試新特性，對(duì)發(fā)現(xiàn)的問題提 issues，但我們也希望能夠?qū)?Nacos 開源社區(qū)盡一份我們的力量。

**作者信息：**殷銘，顏鋪科技架構(gòu)師，負(fù)責(zé)顏鋪 SAAS 平臺(tái)中間件的應(yīng)用和實(shí)踐，主導(dǎo)了平臺(tái)架構(gòu)在顏鋪向分布式演進(jìn)的全過程，目前也負(fù)責(zé)大數(shù)據(jù)在顏鋪平臺(tái)的實(shí)踐和落地。

“阿里巴巴云原生關(guān)注微服務(wù)、Serverless、容器、Service Mesh 等技術(shù)領(lǐng)域、聚焦云原生流行技術(shù)趨勢、云原生大規(guī)模的落地實(shí)踐，做最懂云原生開發(fā)者的公眾號(hào)。”

總結(jié)

以上是生活随笔為你收集整理的构建安全可靠的微服务 | Nacos 在颜铺 SaaS 平台的应用实践的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。