如果不用什么很高大上的東西，就是有多個微服務就行這種技術架構會很難嗎？
我看了一些視頻，他們都用到了es、mq、redis的東西，我想不用這些東西，就簡單的有多個服務，這樣可行嗎？
01 使用微服務你考慮好了嗎？
首先商場的開發要根據你的實際需要來定奪架構，例如，只是在微信小程序中商品滾動圖片展示、產品分類、微信支付、訂單、地址、簡要配送信息，並且有一套后台管理系統，包括：用戶、角色、商品、定價、訂單等，基本上一個完整的商場系統就可以運行了。那么是不是要一定上微服務呢，還是單體服務就夠用了呢？
需要上微服務架構最主要的目的就是為了解決服務功能頻繁更新發布，導致總是影響業務大面積抖動，從而降低了新功能的敏捷迭代。因為對於單體服務，這個問題是無法避免的，一定會影響可靠性。
1. 分布式CAP：但是我接觸過的微服務項目，往往微服務發布機制都不成熟，實際上每次發布微服務和發布單體是一個效果，所有服務都得停下來重新部署。為什么呢？因為在線事務系統一定是優先考慮強一致性，無論什么開發團隊遇到微服務，嘴上說得再漂亮，到了部署的時候，身體都會很誠實。微服務在分布式環境下對CAP理論的付諸實施，你是否已經了然於心了呢？
只要是聯機事務，在微服務環境下依然要保證分布式強一致性。如下圖所示：
2. 分布式事務：微服務另外遇到的一個問題就是將單體應用對數據庫的SQL操作拆分成了PRC遠程協作，那么這個時候就可能涉及分布式事務。
如下圖所示：發起端向支付微服務發起一次支付提交，完成支付后，支付微服務需要用RPC調用來通知訂單服務更新訂單狀態，那么這時候系統就已經掉入到了分布式事務的漩渦。你是否為分布式事務做好准備了?
02 技術是隨着業務規模的發展而逐步引入
其次，這些都對你來說都沒有問題了，為什么還會有Redis，elasticsearch(es)，MQ呢? 那我們就一一分析一遍這些技術在商場中的作用，你自己去評估是否引入。
1. Redis：主要作用是查詢緩存，防止數據庫被擊穿，主要情境是商場出現了高並發的訪問狀態，不過也恭喜你，能用Redis證明你的業務很成功。
如下圖所示：一個比較標准的MySQL讀寫分離，Redis作為查詢緩沖區的聯機事務處理的分布式架構耦。這種情況也是出現在MySQL讀寫分離都無法解決高並發帶來的某個峰值時刻，對數據庫的擊穿，就需要通過增加一個二級緩存來解決。
請一定要注意，貫徹K.I.S.S原則，技術上能不加就不加的原則。因為總是要面對分布式的一致性問題，在加入Redis緩存這個問題，實際上這是目前工程師們非常流行的一種做法，但是在保證MySQL主從復制的一致性方面本身就存在不可控的復雜度，更何況，又引入緩存系統（Redis）和數據庫（MySQL）之間的數據同步的一致性問題，會使得整體架構的復雜性更高，會導致上線后遇到很多不可預知的麻煩，所以在沒有做好充分准備工作之前，增加架構復雜度的事情要慎之又慎。
2. Elasticsearch：對於大量的商品內容檢索，高級一點就不僅僅是分類關鍵字查詢了，更需要是專業搜索提供的商品內容的全文內容檢索，方便用戶通過組合關鍵字，更快查找到自己想要的商品，除非你對自己的編程功底認為不錯，可以直接用luence，否則es是個很不錯的選擇。
如下圖所示：為架構納入Elasticsearch專業搜索引擎，需要引入的技術操作流程，MySQL binlog->Canal->Kafka->Elasticsearch，這是一個binlog實時推送架構，效果最好，也最復雜。這就是表面說起來簡單，但真要做好，內部都要沁透工程師的辛勤與汗水。
3. MQ：當商場的微服務之間，以及商場與第三方服務之間形成犬牙交錯的狀況，一般微服務架構會形成事件驅動機制也就是EDA，例如訂單發起后通過消息推送給下游，下游可能就是訂單的配送系統接受處理。那么用到mq了，系統已經不再是一個小范圍的商業服務了，應該算是平台級的！如下圖所示：
當然mq的引入也不一定是發展到了規模化，也有可能一開始就面臨O2O的業務需要，早期就需要將線上業務事件推送給線下業務系統，這就需要mq了，建議考慮支持分布式事務的mq，例如：rocketmq。如下圖所示：傳統企業搞互聯網+，一開始就要考慮通過消息中心來解決線上線下的數據對接、信息安全、異步協作等問題。
03 總結
最后做個總結，對於上面聊的這些內容，我相信你心里至少應該有個底，可以明確一點——系統架構的技術體系都是不斷迭代加厚，都是根據業務的需要不斷地加持，逐步產生良好的業務支撐作用。
初期往往過度設計得越多，系統死掉的幾率越大，因此微服務是不是一開始就要納入設計? 系統性能優化，高級查詢，復雜系統優化等等這些操作，是否需要在前期設計中完成?，是否已經有了與之匹配的團隊組織形式? 這些都需要逐一斟酌，雖需長遠規划但仍要從簡入深。
可以閱讀另一篇關於微服務和分布式關系的詳細文章：
前往讀字節創作中心——了解”讀字節“更多創作內容
