作者 | 殷銘  顏鋪科技架構師

本文整理自架構師成長系列 3 月 19 日直播課程。 關注“阿里巴巴雲原生”公眾號，回覆 “319”，即可獲取對應直播回放連結及 PPT 下載連結。

**導讀：**顏鋪科技因美業⽽⽣，“顏鋪專家”是一款專為美業商家打造的 SaaS 平臺，為了能夠給商戶提供更加安全、穩定、高效的平臺，我們在技術方面做了很多嘗試，經過幾次演進，使系統變得更加穩定可靠。今天主要和大家分享一下顏鋪科技的架構演進，以及 Nacos 在顏鋪的應用實踐。

單體應用時代

上圖是我們單體服務時的架構圖，分為會員、訂單、門店等很多模組，看架構圖似乎還算清晰，但是真正看到包結構的時候，真的令人頭禿!改起程式碼特別頭痛。單體服務帶來的幾個挑戰：

• **釋出週期慢：**雖然當時業務量不算大，但是程式碼量很大，業務迭代牽一髮而動全身，每次釋出需要對整個服務進行重新編譯打包部署。特別是最開始在沒有構建工具的時候，釋出過程需要一堆的命令，總有一種 **“一頓操作猛如虎，定睛一看原地杵” **的感覺。

• **協同效率低：**合併衝突多，有時你在前面開心地寫程式碼，而別人在解決衝突時，可能也在開心地刪著你的程式碼，增加了很多的溝通成本。

• **穩定性差：**當服務出現故障時，可能會導致整個系統不可用，並且系統不易擴容，當商戶搞促銷時，可能活動結束了，伺服器還沒有擴容完成。

• **效能差：**因為在單體服務內，有些開發人員為了滿足自己的業務，很多無關業務間 SQL 聯表查詢，並且不關注效能問題，導致線上時常出現負載警告。

另外，我們在業務上也遇到了一些挑戰：

• **業務轉型： **2018 年 6 月，我們公司決定從泛行業轉向美業，需要打造一個專為美業商戶提供技術支援的麗人 SaaS 平臺。

• **快速佔領市場：**業務的轉型帶來了更多商戶的新需求，如果不能快速迭代，則意味著被市場淘汰。因此，提升開發效率，快速佔領市場成為我們急需解決的問題。

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

綜上所述，我們認為進行服務化改造刻不容緩。

微服務改造

經過公司開發同學們的討論，我們最終決定分兩步進行改造： 服務化改造 1.0 的目標：

• 用最小的改造成本先將新、舊商戶平臺進行打通，做到功能上的快速遷移；
• 業務抽象，將新舊商戶中心的公用部分進行抽象，並優化舊商戶中心的程式碼邏輯，為後續的業務中臺建設做好鋪墊。

服務化改造 2.0 的目標：初步建設業務中臺，讓平臺的各種能力能夠快速複用、快速組合，支援業務更快捷地探索與發展。 服務化改造 1.0 預期效果：

• 我們希望老商戶中心在對外提供服務的同時，還能夠作為提供者，對新商戶中心提供服務支援；
• 新商戶中心僅對外提供服務，不直連資料庫，業務層只對美業的特殊邏輯進行處理。

因此，我們的想法是：新商戶中心直接呼叫舊商戶中心通過 Controller 暴露出的介面，進行遠端呼叫，於是我們決定嘗試使用 Spring Cloud 。

服務發現選型：

• Consul 支援服務發現的同時，支援 kv 儲存服務，因為我們想做一個配置中心的 KV 儲存，所以想利用 Consul 做一個嘗試；
• 服務健康檢查相對更為詳細；
• 在我們選型的期間，突然出現了 Eureka 2.x 開源工作宣告停止的訊息，雖然後來發現，這個對我們並沒有什麼太大的影響，但在當時的決策讓我們最終選擇了 Consul 。

服務化改造 1.0 架構圖：

服務化 1.0 我們的技術改造方案是：將舊的商戶中心註冊到 Consul 上面，新商戶中心到 Consul 上獲取伺服器列表，通過 Feign 進行遠端呼叫，打通了新老商戶中心的功能。

經過服務化 1.0 的改造，我們解決了如下幾個問題：

• **功能快速完善：**舊商戶中心的功能快速遷移到了新的商戶中心，並完成對美業的適配；
• **迭代速度加快：**新商戶中心大部分功能，能夠通過舊商戶中心進行修改相容，為後續的業務中臺的抽象打好基礎；
• **效能優化：**業務開發的同時，我們對舊商戶中心的老程式碼進行優化，效能和穩定性均有所提高。

但服務化 1.0 改造後，還是有一些挑戰沒有解決：

• **釋出週期依舊不夠快：**大部分程式碼還是在就商戶中心，業務迭代依然牽一髮而動全身；
• **協同效率沒有提高：**在程式碼衝突多，溝通成本高的同時，又出現了令開發同學頭痛的新老業務的相容問題；
• **維護成本：**Consul 是 Go 語言開發的，不易維護；Spring Cloud 在開發過程中體驗不佳，在寫業務的同時，還要摸索 Spring Cloud 的最佳實踐，花費了一些時間去做 Spring Cloud 的基礎建設。

於是我們決定開啟，服務化 2.0 的改造。 服務化改造 2.0 的預期效果：

• 完成業務中臺的初步建設，將模組重新劃分，抽象為獨立服務；
• 新、舊商戶中心服務僅做自己的業務相容，並對外暴露介面；
• 新增專門支援 H5、小程式 的 C 端 WEB 服務。 因 Spring Cloud 體驗不佳，我們決定服務化改造 2.0 嘗試使用 Dubbo 作為基礎服務的 RPC 遠端呼叫框架，因此我們要對註冊中心進行選型。

首先，註冊中心我認為應該具備的基本功能 ：

• 服務註冊及時被發現，異常時的及時下線；
• 服務管理，能夠手動恢復/剔除服務；
• 健康檢查，檢測服務是否可用；
• 後設資料管理；
• 註冊中心保證自身的高可用。

Zookeeper :

• 不能保證每次服務請求都是可達的，當 zk 叢集 master 掛掉時，需要進行選舉，在選舉期間中，服務是不可用的；
• 不支援跨機房的路由，比如 eureka 的 zone，當前機房不可用時，可以路由到其他機房；
• “驚群效應”， zk 的節點過多的時候，當 service 的節點發生變更，會同時通知到客戶端，瞬時流量有可能將網路卡瞬間打滿，並且會有重複通知的問題。

Nacos :

• 註冊中心部分更側重於可用性
• 服務發現與服務管理
• 服務後設資料的管理
• 動態配置管理

在此期間，我們也關注到了 Spring Cloud Alibaba。阿里巴巴技術經受多年“雙十一”的考驗，其效能和穩定性是值得信任的。Spring Cloud Alibaba 的元件開源社群活躍度很高，並且比起國外開源專案更容易交流。其元件由 Java 語言開發，對我們來說更易維護，在出現問題時能夠更快地定位問題進行修復。而且與阿里配合，更加容易上雲，比如 Nacos 可以與阿里的 MSE 和 ACM 配合，將註冊中心及配置管理全部上雲。 

因此，我們決定擁抱阿里技術棧。

服務化改造2.0架構圖：

我們將之前的模組直接抽到基礎服務之中，新增了 會員、訂單、門店 等服務作為Provider，暴露自己的Service，並註冊到 Nacos 上。新商戶中心服務做美業業務邏輯的處理，舊商戶中心服務做泛行業的業務處理，C端服務同理對外提供服務。通過 Dubbo 進行遠端呼叫。

通過服務化 2.0 的改造，效果如下：

• 伺服器成本降低30%：20+臺伺服器，由4核16G 降配到2核8G；
• 系統可靠性提升80%：load 告警明顯減少，線上的問題修正能夠快速修復，完成部署；
• 程式碼衝突減少75%：因為邊界有了基本各自維護，衝突顯著減少；
• 釋出迭代效率提升50%：之前5個人每個迭代開發評估可完成30個點，現在可完成45個點左右。

Nacos 落地實踐與問題分析

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

首先是使用情況：

• 部署方式：開發/測試環境單機部署，生產環境 3 臺叢集部署；
• 版本：生產環境從 0.9.0 開始使用，目前生產環境使用的版本為 1.1.4 ；
• 使用時間：2019 年 3 月份開始在生產環境下使用；
• 服務數量：線上 20+ 臺伺服器，提供了 600+ 個服務；
• 穩定性：一年的時間裡沒有出現大的問題，並且平滑升級；
• 相容性：新老服務，在我們公司無論是 Spring 4.3+ 的工程，還是 Spring Boot 的工程均相容良好。

Nacos 註冊中心：

• 服務註冊：將後端服務註冊到 Nacos，通過 Dubbo 進行呼叫。目前開發環境中我們正在測試Seata，並且也將 Seata 服務註冊到 Nacos 上；
• Namespace：服務統一註冊到 public 中。

Nacos 配置管理：

每個服務設定獨立的 Namespace 。

• 服務的配置檔案資訊：application.properties 全部配置到 Nacos，工程的配置檔案僅保留 Nacos 相關配置；
• 業務層的 KV 配置：比如業務開關，屬性預設值，定時任務配置等；
• MQ Topic 的動態配置：Binlog 服務採集動態傳送到在 Nacos 配置的 topic 及其需要的表資訊；
• Sentinel 的規則配置：Sentinel 限流規則持久化到 Nacos 。

問題描述：

2019 年 12 月 31 日，下午 3 點 15 分左右，線上突然出現大量服務告警，Dubbo 服務出現報錯，整個過程持續約 3 多分鐘。各個業務組當天均沒有任何釋出，資料庫狀態也良好。

通過日誌發現，報錯原因是門店服務無法呼叫。而門店服務日誌，出現問題的時間段內，沒有任何的呼叫記錄。系統恢復正常時，出現了很多服務註冊的通知。

因此，我們將問題瞄準了 Nacos。檢視 Nacos 的日誌發現，在系統恢復過程中，有大量的服務正在上線。

就在排查的過程中，線上突然又出現了之前相同的告警，Nacos 上的服務列表開始大量變成不健康的狀態，於是我們緊急重啟了線上的 Nacos ，在這期間又經歷了一個 3 分多鐘的驚魂後，再次恢復了平靜。

問題分析：

• 兩次出現的問題均是門店服務，但出現問題期間 JVM 和資料庫的執行狀態均良好；
• 報錯資訊都是 Dubbo 呼叫超時，且出現問題期間，門店服務沒有任何流量進入；
• 出現問題時，註冊在 Nacos 上的服務開始大量不健康。恢復正常時，這些服務又開始上線，說明出現問題時，服務被下線又重新上線。

綜上，我們開始懷疑是網路原因造成的。

問題確認：

經過排查，發現我們的服務大多部署在 阿里華東 1 可用區 B ，只有門店服務和 Nacos 叢集沒有部署在可用區 B ，說明這段時間可用區 B 與其他區之間的發生了網路隔離。

於是，我們在可用區 B 緊急部署了門店服務，之後沒有再出現問題。

經過與阿里的溝通確認於北京時間 2019 年 12 月 31 日 14:05 分左右開始，部分使用者反饋阿里華東 1 地域可用區 B 部分網路出現異常，影響部分雲資源訪問。

問題覆盤：

• 問題出現：下午 3 點多，突然連續出現的服務告警， Dubbo 服務出現報錯；
• Nacos：Nacos 服務列表裡大量服務出現不健康的狀態；
• 網路不通：可用區 B 與其它區網路不通，導致服務無法呼叫；
• 緊急部署：在 B 區部署缺失的 門店服務；
• 恢復正常。

問題思考：

• 服務部署：應用服務和Nacos建議多機房部署，即使在雲上可用區之間也需要考慮；
• 容災：問題出現時，可用區 B 並沒有部署 Nacos，但可用區B內的服務之間依然能調通，且能夠讀到 Nacos 上的配置。因此，我們認為 Nacos 以及 Dubbo 的容災策略都是值得信賴的。

回顧與展望：

“顏鋪專家”經過不斷地快速迭代，幫助美業商家⾼效快捷地管理門店，進行經營資料分析，資料化管理門店，建⽴完善的會員週期管理體系，為美業商家在經營管理中，提供⼀體化的解決方案，將美業傳統的門店經營模式進⾏網際網路升級。截止到目前我們累計服務 3000 多個品牌，1.1W + 個⻔店。我們提供了店務管理系統、會員管理系統、營銷拓客系統、大資料決策系統、供應鏈管理系統、員工績效管理系統6⼤系統能力，同時⽀持 PC 端、手機 APP 、 pos 機、 iPad 操作，滿⾜⻔店多端操作需求，覆蓋⻔店經營管理中的所有場景需求。

未來規劃

提升系統高可用

• **Seata ：**目前我們公司的分散式事務主要依賴 MQ 的補償，今年準備引入 Seata 來完善分散式事務，保證資料一致性，減少開發修資料的情況；

• **Sentinel ：**目前 Sentinel 我們只是在商戶做活動時啟用，因此我們要配置出適用於我們公司的最佳實踐，保證系統的高可用；

• **全鏈路跟蹤：**我們公司現在定位問題主要靠日誌和告警，做不到全鏈路的跟蹤，所以我們要把這部分做好，做到故障快速定位，各呼叫環節效能分析，以及資料分析；

• **異地容災：**隨著來自全國各省的商戶越來越多，我們需要對商戶的資料保障，避免資料丟失，確保服務的可靠性。

社群回饋

因為我們的公司體量現在不大，我們能夠做到的是儘可能地使用最新的版本，及時嘗試新特性，對發現的問題提 issues，但我們也希望能夠對 Nacos 開源社群盡一份我們的力量。

**作者資訊：**殷銘，顏鋪科技架構師，負責顏鋪 SAAS 平臺中介軟體的應用和實踐，主導了平臺架構在顏鋪向分散式演進的全過程，目前也負責大資料在顏鋪平臺的實踐和落地。

“阿里巴巴雲原生關注微服務、Serverless、容器、Service Mesh 等技術領域、聚焦雲原生流行技術趨勢、雲原生大規模的落地實踐，做最懂雲原生開發者的公眾號。”