本文將介紹微服務架構和相關的元件，介紹他們是什麼以及為什麼要使用微服務架構和這些元件。本文側重於簡明地表達微服務架構的全域性圖景，因此不會涉及具體如何使用元件等細節。

要理解微服務，首先要先理解不是微服務的那些。通常跟微服務相對的是單體應用，即將所有功能都打包成在一個獨立單元的應用程式。從單體應用到微服務並不是一蹴而就的，這是一個逐漸演變的過程。本文將以一個網上超市應用為例來說明這一過程。

最初的需求

幾年前，小明和小皮一起創業做網上超市。小明負責程式開發，小皮負責其他事宜。當時網際網路還不發達，網上超市還是藍海。只要功能實現了就能隨便賺錢。所以他們的需求很簡單，只需要一個網站掛在公網，使用者能夠在這個網站上瀏覽商品、購買商品；另外還需一個管理後臺，可以管理商品、使用者、以及訂單資料。

我們整理一下功能清單：

網站使用者註冊、登入功能商品展示下單管理後臺使用者管理商品管理訂單管理

由於需求簡單，小明左手右手一個慢動作，網站就做好了。管理後臺出於安全考慮，不和網站做在一起，小明右手左手慢動作重播，管理網站也做好了。總體架構圖如下：

小明揮一揮手，找了家雲服務部署上去，網站就上線了。上線後好評如潮，深受各類肥宅喜愛。小明小皮美滋滋地開始躺著收錢。

隨著業務發展……

好景不長，沒過幾天，各類網上超市緊跟著拔地而起，對小明小皮造成了強烈的衝擊。

在競爭的壓力下，小明小皮決定開展一些營銷手段：

開展促銷活動。比如元旦全場打折，春節買二送一，情人節狗糧優惠券等等。拓展渠道，新增移動端營銷。除了網站外，還需要開發移動端APP，微信小程式等。精準營銷。利用歷史資料對使用者進行分析，提供個性化服務。……

這些活動都需要程式開發的支援。小明拉了同學小紅加入團隊。小紅負責資料分析以及移動端相關開發。小明負責促銷活動相關功能的開發。

因為開發任務比較緊迫，小明小紅沒有好好規劃整個系統的架構，隨便拍了拍腦袋，決定把促銷管理和資料分析放在管理後臺裡，微信和移動端APP另外搭建。通宵了幾天後，新功能和新應用基本完工。這時架構圖如下：

這一階段存在很多不合理的地方：

網站和移動端應用有很多相同業務邏輯的重複程式碼。資料有時候通過資料庫共享，有時候通過介面呼叫傳輸。介面呼叫關係雜亂。單個應用為了給其他應用提供介面，漸漸地越改越大，包含了很多本來就不屬於它的邏輯。應用邊界模糊，功能歸屬混亂。管理後臺在一開始的設計中保障級別較低。加入資料分析和促銷管理相關功能後出現效能瓶頸，影響了其他應用。資料庫表結構被多個應用依賴，無法重構和優化。所有應用都在一個數據庫上操作，資料庫出現效能瓶頸。特別是資料分析跑起來的時候，資料庫效能急劇下降。開發、測試、部署、維護愈發困難。即使只改動一個小功能，也需要整個應用一起釋出。有時候釋出會不小心帶上了一些未經測試的程式碼，或者修改了一個功能後，另一個意想不到的地方出錯了。為了減輕釋出可能產生的問題的影響和線上業務停頓的影響，所有應用都要在凌晨三四點執行釋出。釋出後為了驗證應用正常執行，還得盯到第二天白天的使用者高峰期……團隊出現推諉扯皮現象。關於一些公用的功能應該建設在哪個應用上的問題常常要爭論很久，最後要麼乾脆各做各的，或者隨便放個地方但是都不維護。

儘管有著諸多問題，但也不能否認這一階段的成果：快速地根據業務變化建設了系統。不過緊迫且繁重的任務容易使人陷入區域性、短淺的思維方式，從而做出妥協式的決策。在這種架構中，每個人都只關注在自己的一畝三分地，缺乏全域性的、長遠的設計。長此以往，系統建設將會越來越困難，甚至陷入不斷推翻、重建的迴圈。