讀完全文需要10min

通常跟微服務相對的是單體應用（即將所有功能都打包成在一個獨立單元的應用程序）。從單體應用到微服務并不是一蹴而就的，這是一個逐漸演變的過程。本文將以一個網(wǎng)上超市應用為例來說明這一過程。

最初的需求

?

隨著業(yè)務發(fā)展。。。

增加客戶端類型和數(shù)據(jù)分析、商品促銷等服務

上述架構的弊端：

• 重復造輪子：Web端和移動端有很多業(yè)務重復的代碼。
• 數(shù)據(jù)共享問題：數(shù)據(jù)有時候通過數(shù)據(jù)庫共享，有時候通過接口調用傳輸。接口調用關系雜亂。
• 后臺性能問題：管理后臺在一開始的設計中保障級別較低。加入數(shù)據(jù)分析和促銷管理相關功能后出現(xiàn)性能瓶頸，影響了其他應用。
• 數(shù)據(jù)庫性能問題：所有應用都在一個數(shù)據(jù)庫上操作，數(shù)據(jù)庫出現(xiàn)性能瓶頸。特別是數(shù)據(jù)分析跑起來的時候，數(shù)據(jù)庫性能急劇下降。

是時候做出改變了

這個階段只是將服務分開了，數(shù)據(jù)庫依然是共用的，所以一些煙囪式系統(tǒng)的缺點仍然存在：

數(shù)據(jù)庫成為性能瓶頸，并且有單點故障的風險。

數(shù)據(jù)管理趨向混亂。即使一開始有良好的模塊化設計，隨著時間推移，總會有一個服務直接從數(shù)據(jù)庫取另一個服務的數(shù)據(jù)的現(xiàn)象。

數(shù)據(jù)庫表結構可能被多個服務依賴，牽一發(fā)而動全身，很難調整。

如果一直保持共用數(shù)據(jù)庫的模式，則整個架構會越來越僵化，失去了微服務架構的意義。因此小明和小紅一鼓作氣，把數(shù)據(jù)庫也拆分了。所有持久化層相互隔離，由各個服務自己負責。另外，為了提高系統(tǒng)的實時性，加入了消息隊列機制。架構如下：

微服務架構容易出現(xiàn)的問題：

監(jiān)控 - 發(fā)現(xiàn)故障的征兆

定位問題 - 鏈路跟蹤

Istio文檔里的鏈路跟蹤

分析問題 - 日志分析

網(wǎng)關 - 權限控制，服務治理

參考文章：
為什么像王者榮耀這樣的游戲 Server 不愿意使用微服務？

什么是微服務架構？

總結

以上是生活随笔為你收集整理的微服务架构是什么？的全部內容，希望文章能夠幫你解決所遇到的問題。

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