構建安全可靠的微服務 | Nacos 在顏鋪 SaaS 平臺的應用實踐

1.jpeg

做者 | 殷銘  顏鋪科技架構師數據庫

本文整理自架構師成長系列 3 月 19 日直播課程。 關注「阿里巴巴雲原生」公衆號,回覆 「319」,便可獲取對應直播回放連接及 PPT 下載連接。小程序

**導讀:**顏鋪科技因美業⽽⽣,「顏鋪專家」是一款專爲美業商家打造的 SaaS 平臺,爲了可以給商戶提供更加安全、穩定、高效的平臺,咱們在技術方面作了不少嘗試,通過幾回演進,使系統變得更加穩定可靠。今天主要和你們分享一下顏鋪科技的架構演進,以及 Nacos 在顏鋪的應用實踐。後端

單體應用時代

2.png

上圖是咱們單體服務時的架構圖,分爲會員、訂單、門店等不少模塊,看架構圖彷佛還算清晰,可是真正看到包結構的時候,真的使人頭禿!改起代碼特別頭痛。單體服務帶來的幾個挑戰:安全

  • **發佈週期慢:**雖然當時業務量不算大,可是代碼量很大,業務迭代牽一髮而動全身,每次發佈須要對整個服務進行從新編譯打包部署。特別是最開始在沒有構建工具的時候,發佈過程須要一堆的命令,總有一種 **「一頓操做猛如虎,定睛一看原地杵」 **的感受。性能優化

  • **協同效率低:**合併衝突多,有時你在前面開心地寫代碼,而別人在解決衝突時,可能也在開心地刪着你的代碼,增長了不少的溝通成本。服務器

  • **穩定性差:**當服務出現故障時,可能會致使整個系統不可用,而且系統不易擴容,當商戶搞促銷時,可能活動結束了,服務器尚未擴容完成。網絡

  • **性能差:**由於在單體服務內,有些開發人員爲了知足本身的業務,不少無關業務間 SQL 聯表查詢,而且不關注性能問題,致使線上時常出現負載警告。 架構

另外,咱們在業務上也遇到了一些挑戰:app

  • **業務轉型: **2018 年 6 月,咱們公司決定從泛行業轉向美業,須要打造一個專爲美業商戶提供技術支持的麗人 SaaS 平臺。框架

  • **快速佔領市場:**業務的轉型帶來了更多商戶的新需求,若是不能快速迭代,則意味着被市場淘汰。所以,提高開發效率,快速佔領市場成爲咱們急需解決的問題。

  • **商戶體驗差:**隨着愈來愈多的商戶入住,性能和可靠性的問題逐漸顯現,出現問題,不能及時修正,商戶體驗變得不好,違背咱們客戶第一的原則。 

綜上所述,咱們認爲進行服務化改造刻不容緩。

微服務改造

通過公司開發同窗們的討論,咱們最終決定分兩步進行改造: 服務化改造 1.0 的目標:

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

服務化改造 2.0 的目標:初步建設業務中臺,讓平臺的各類能力可以快速複用、快速組合,支持業務更快捷地探索與發展。 服務化改造 1.0 預期效果: 3.png

  • 咱們但願老商戶中心在對外提供服務的同時,還可以做爲提供者,對新商戶中心提供服務支持;
  • 新商戶中心僅對外提供服務,不直連數據庫,業務層只對美業的特殊邏輯進行處理。 

所以,咱們的想法是:新商戶中心直接調用舊商戶中心經過 Controller 暴露出的接口,進行遠程調用,因而咱們決定嘗試使用 Spring Cloud 。

 服務發現選型: 4.png

  • Consul 支持服務發現的同時,支持 kv 存儲服務,由於咱們想作一個配置中心的 KV 存儲,因此想利用 Consul 作一個嘗試;
  • 服務健康檢查相對更爲詳細;
  • 在咱們選型的期間,忽然出現了 Eureka 2.x 開源工做宣告中止的消息,雖而後來發現,這個對咱們並無什麼太大的影響,但在當時的決策讓咱們最終選擇了 Consul 。 

服務化改造 1.0 架構圖: 5.png

服務化 1.0 咱們的技術改造方案是:將舊的商戶中心註冊到 Consul 上面,新商戶中心到 Consul 上獲取服務器列表,經過 Feign 進行遠程調用,打通了新老商戶中心的功能。 

通過服務化 1.0 的改造,咱們解決了以下幾個問題:

  • **功能快速完善:**舊商戶中心的功能快速遷移到了新的商戶中心,並完成對美業的適配;
  • **迭代速度加快:**新商戶中心大部分功能,可以經過舊商戶中心進行修改兼容,爲後續的業務中臺的抽象打好基礎;
  • **性能優化:**業務開發的同時,咱們對舊商戶中心的老代碼進行優化,性能和穩定性均有所提升。 

但服務化 1.0 改造後,仍是有一些挑戰沒有解決:

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

因而咱們決定開啓,服務化 2.0 的改造。 服務化改造 2.0 的預期效果: 6.png

  • 完成業務中臺的初步建設,將模塊從新劃分,抽象爲獨立服務;
  • 新、舊商戶中心服務僅作本身的業務兼容,並對外暴露接口;
  • 新增專門支持 H五、小程序 的 C 端 WEB 服務。 因 Spring Cloud 體驗不佳,咱們決定服務化改造 2.0 嘗試使用 Dubbo 做爲基礎服務的 RPC 遠程調用框架,所以咱們要對註冊中心進行選型。 

首先,註冊中心我認爲應該具有的基本功能 :

  • 服務註冊及時被發現,異常時的及時下線;
  • 服務管理,可以手動恢復/剔除服務;
  • 健康檢查,檢測服務是否可用;
  • 元數據管理;
  • 註冊中心保證自身的高可用。

7.png

Zookeeper :

  • 不能保證每次服務請求都是可達的,當 zk 集羣 master 掛掉時,須要進行選舉,在選舉期間中,服務是不可用的;
  • 不支持跨機房的路由,好比 eureka 的 zone,當前機房不可用時,能夠路由到其餘機房;
  • 「驚羣效應」, zk 的節點過多的時候,當 service 的節點發生變動,會同時通知到客戶端,瞬時流量有可能將網卡瞬間打滿,而且會有重複通知的問題。

Nacos :

  • 註冊中心部分更側重於可用性
  • 服務發現與服務管理
  • 服務元數據的管理
  • 動態配置管理

8.png

在此期間,咱們也關注到了 Spring Cloud Alibaba。阿里巴巴技術經受多年「雙十一」的考驗,其性能和穩定性是值得信任的。Spring Cloud Alibaba 的組件開源社區活躍度很高,而且比起國外開源項目更容易交流。其組件由 Java 語言開發,對咱們來講更易維護,在出現問題時可以更快地定位問題進行修復。並且與阿里雲配合,更加容易上雲,好比 Nacos 能夠與阿里雲的 MSE 和 ACM 配合,將註冊中心及配置管理所有上雲。 9.png

所以,咱們決定擁抱阿里技術棧。 

服務化改造2.0架構圖:

10.png

咱們將以前的模塊直接抽到基礎服務之中,新增了 會員、訂單、門店 等服務做爲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 註冊中心:

11.png

  • 服務註冊:將後端服務註冊到 Nacos,經過 Dubbo 進行調用。目前開發環境中咱們正在測試Seata,而且也將 Seata 服務註冊到 Nacos 上;
  • Namespace:服務統一註冊到 public 中。 

Nacos 配置管理:

12.png

每一個服務設置獨立的 Namespace 。 

  • 服務的配置文件信息:application.properties 所有配置到 Nacos,工程的配置文件僅保留 Nacos 相關配置;
  • 業務層的 KV 配置:好比業務開關,屬性默認值,定時任務配置等;
  • MQ Topic 的動態配置:Binlog 服務採集動態發送到在 Nacos 配置的 topic 及其須要的表信息;
  • Sentinel 的規則配置:Sentinel 限流規則持久化到 Nacos 。

問題描述:

13.png

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

經過日誌發現,報錯緣由是門店服務沒法調用。而門店服務日誌,出現問題的時間段內,沒有任何的調用記錄。系統恢復正常時,出現了不少服務註冊的通知。

所以,咱們將問題瞄準了 Nacos。查看 Nacos 的日誌發現,在系統恢復過程當中,有大量的服務正在上線。

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

問題分析:

  • 兩次出現的問題均是門店服務,但出現問題期間 JVM 和數據庫的運行狀態均良好;
  • 報錯信息都是 Dubbo 調用超時,且出現問題期間,門店服務沒有任何流量進入;
  • 出現問題時,註冊在 Nacos 上的服務開始大量不健康。恢復正常時,這些服務又開始上線,說明出現問題時,服務被下線又從新上線。

 綜上,咱們開始懷疑是網絡緣由形成的。

 問題確認:

14.png

通過排查,發現咱們的服務大多部署在 阿里雲華東 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 的容災策略都是值得信賴的。 

回顧與展望:

15.png

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

將來規劃

提高系統高可用

  • **Seata :**目前咱們公司的分佈式事務主要依賴 MQ 的補償,今年準備引入 Seata 來完善分佈式事務,保證數據一致性,減小開發修數據的狀況;

  • **Sentinel :**目前 Sentinel 咱們只是在商戶作活動時啓用,所以咱們要配置出適用於咱們公司的最佳實踐,保證系統的高可用;

  • **全鏈路跟蹤:**咱們公司如今定位問題主要靠日誌和告警,作不到全鏈路的跟蹤,因此咱們要把這部分作好,作到故障快速定位,各調用環節性能分析,以及數據分析;

  • **異地容災:**隨着來自全國各省的商戶愈來愈多,咱們須要對商戶的數據保障,避免數據丟失,確保服務的可靠性。 

社區回饋

16.png

由於咱們的公司體量如今不大,咱們可以作到的是儘量地使用最新的版本,及時嘗試新特性,對發現的問題提 issues,但咱們也但願可以對 Nacos 開源社區盡一份咱們的力量。

**做者信息:**殷銘,顏鋪科技架構師,負責顏鋪 SAAS 平臺中間件的應用和實踐,主導了平臺架構在顏鋪向分佈式演進的全過程,目前也負責大數據在顏鋪平臺的實踐和落地。

17.png

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

相關文章
相關標籤/搜索