微服務架構開發電商系統需要用Redis、ES和MQ嗎?

讀位元組發表於2021-05-13

如果不用什麼很高大上的東西,就是有多個微服務就行這種技術架構會很難嗎?

我看了一些視訊,他們都用到了es、mq、redis的東西,我想不用這些東西,就簡單的有多個服務,這樣可行嗎?

01 使用微服務你考慮好了嗎?

首先商場的開發要根據你的實際需要來定奪架構,例如,只是在微信小程式中商品滾動圖片展示、產品分類、微信支付、訂單、地址、簡要配送資訊,並且有一套後臺管理系統,包括:使用者、角色、商品、定價、訂單等,基本上一個完整的商場系統就可以執行了。那麼是不是要一定上微服務呢,還是單體服務就夠用了呢?

需要上微服務架構最主要的目的就是為了解決服務功能頻繁更新發布,導致總是影響業務大面積抖動,從而降低了新功能的敏捷迭代。因為對於單體服務,這個問題是無法避免的,一定會影響可靠性。

1. 分散式CAP:但是我接觸過的微服務專案,往往微服務釋出機制都不成熟,實際上每次釋出微服務和釋出單體是一個效果,所有服務都得停下來重新部署。為什麼呢?因為線上事務系統一定是優先考慮強一致性,無論什麼開發團隊遇到微服務,嘴上說得再漂亮,到了部署的時候,身體都會很誠實。微服務在分散式環境下對CAP理論的付諸實施,你是否已經瞭然於心了呢?

只要是聯機事務,在微服務環境下依然要保證分散式強一致性。如下圖所示:

微服務架構開發電商系統需要用Redis、ES和MQ嗎?

2. 分散式事務:微服務另外遇到的一個問題就是將單體應用對資料庫的SQL操作拆分成了PRC遠端協作,那麼這個時候就可能涉及分散式事務。

如下圖所示:發起端向支付微服務發起一次支付提交,完成支付後,支付微服務需要用RPC呼叫來通知訂單服務更新訂單狀態,那麼這時候系統就已經掉入到了分散式事務的漩渦。你是否為分散式事務做好準備了?

微服務架構開發電商系統需要用Redis、ES和MQ嗎?

02 技術是隨著業務規模的發展而逐步引入

其次,這些都對你來說都沒有問題了,為什麼還會有Redis,elasticsearch(es),MQ呢? 那我們就一一分析一遍這些技術在商場中的作用,你自己去評估是否引入。

1. Redis:主要作用是查詢快取,防止資料庫被擊穿,主要情境是商場出現了高併發的訪問狀態,不過也恭喜你,能用Redis證明你的業務很成功。

如下圖所示:一個比較標準的MySQL讀寫分離,Redis作為查詢緩衝區的聯機事務處理的分散式架構耦。這種情況也是出現在MySQL讀寫分離都無法解決高併發帶來的某個峰值時刻,對資料庫的擊穿,就需要通過增加一個二級快取來解決。

微服務架構開發電商系統需要用Redis、ES和MQ嗎?

請一定要注意,貫徹K.I.S.S原則,技術上能不加就不加的原則。因為總是要面對分散式的一致性問題,在加入Redis快取這個問題,實際上這是目前工程師們非常流行的一種做法,但是在保證MySQL主從複製的一致性方面本身就存在不可控的複雜度,更何況,又引入快取系統(Redis)和資料庫(MySQL)之間的資料同步的一致性問題,會使得整體架構的複雜性更高,會導致上線後遇到很多不可預知的麻煩,所以在沒有做好充分準備工作之前,增加架構複雜度的事情要慎之又慎。

2. Elasticsearch:對於大量的商品內容檢索,高階一點就不僅僅是分類關鍵字查詢了,更需要是專業搜尋提供的商品內容的全文內容檢索,方便使用者通過組合關鍵字,更快查詢到自己想要的商品,除非你對自己的程式設計功底認為不錯,可以直接用luence,否則es是個很不錯的選擇。

如下圖所示:為架構納入Elasticsearch專業搜尋引擎,需要引入的技術操作流程,MySQL binlog->Canal->Kafka->Elasticsearch,這是一個binlog實時推送架構,效果最好,也最複雜。這就是表面說起來簡單,但真要做好,內部都要沁透工程師的辛勤與汗水。

微服務架構開發電商系統需要用Redis、ES和MQ嗎?

3. MQ:當商場的微服務之間,以及商場與第三方服務之間形成犬牙交錯的狀況,一般微服務架構會形成事件驅動機制也就是EDA,例如訂單發起後通過訊息推送給下游,下游可能就是訂單的配送系統接受處理。那麼用到mq了,系統已經不再是一個小範圍的商業服務了,應該算是平臺級的!如下圖所示:

微服務架構開發電商系統需要用Redis、ES和MQ嗎?

當然mq的引入也不一定是發展到了規模化,也有可能一開始就面臨O2O的業務需要,早期就需要將線上業務事件推送給線下業務系統,這就需要mq了,建議考慮支援分散式事務的mq,例如:rocketmq。如下圖所示:傳統企業搞網際網路+,一開始就要考慮通過訊息中心來解決線上線下的資料對接、資訊保安、非同步協作等問題。

微服務架構開發電商系統需要用Redis、ES和MQ嗎?

03 總結

最後做個總結,對於上面聊的這些內容,我相信你心裡至少應該有個底,可以明確一點——系統架構的技術體系都是不斷迭代加厚,都是根據業務的需要不斷地加持,逐步產生良好的業務支撐作用。

初期往往過度設計得越多,系統死掉的機率越大,因此微服務是不是一開始就要納入設計? 系統效能優化,高階查詢,複雜系統優化等等這些操作,是否需要在前期設計中完成?,是否已經有了與之匹配的團隊組織形式? 這些都需要逐一斟酌,雖需長遠規劃但仍要從簡入深。

可以閱讀另一篇關於微服務和分散式關係的詳細文章:

微服務都想用,先把分散式和微服務之間的關係說清楚

通俗地理解SOA與微服務之間的關係

前往讀位元組創作中心——瞭解”讀位元組“更多創作內容

微服務架構開發電商系統需要用Redis、ES和MQ嗎?

相關文章