小張本科畢業(yè)后就入職了一家電商公司，目前已經(jīng)在這工作了兩年。

最近公司想要發(fā)展跨境電商業(yè)務(wù)，于是技術(shù)總監(jiān)讓小張、老陳和另一個(gè)小同事從國內(nèi)的電商項(xiàng)目組中抽出來，再重新搭建一個(gè)跨境電商平臺(tái)。

老陳沉思了一下，說：“咱們要不這樣，海外電商就別用微服務(wù)架構(gòu)進(jìn)行開發(fā)了吧，改為使用單體架構(gòu)進(jìn)行開發(fā)。”

圖片

小張有些疑惑地問：“為什么不跟現(xiàn)在的國內(nèi)電商平臺(tái)保持一致，也使用微服務(wù)架構(gòu)進(jìn)行開發(fā)呢，微服務(wù)架構(gòu)才是主流趨勢啊，單體架構(gòu)據(jù)說全是缺點(diǎn)。”

老陳神秘地笑了笑，說：“咱們國內(nèi)電商平臺(tái)以前也是單體架構(gòu)，微服務(wù)架構(gòu)是一個(gè)大廠架構(gòu)師來了之后搞的，說是為了公司業(yè)務(wù)發(fā)展和系統(tǒng)演進(jìn)。

至于這個(gè)跨境電商平臺(tái)，咱們就重新搞回單體架構(gòu)吧，慢慢你就明白有多爽了。”

小張將信將疑地點(diǎn)了點(diǎn)頭。

CQRS ——> 多表關(guān)聯(lián)

沒過多久，小張就感受到了第一個(gè)爽點(diǎn)。

公司的客服團(tuán)隊(duì)提了需求，希望實(shí)現(xiàn)對訂單的多維復(fù)雜查詢功能，查詢項(xiàng)但不限于：下單時(shí)間、支付時(shí)間、訂單狀態(tài)、訂單的商品品類、下單用戶手機(jī)號(hào)等，并且需要支持分頁和排序。

如果換做以前的微服務(wù)架構(gòu)，需要通過CQRS模式進(jìn)行實(shí)現(xiàn)才行。

也就是將用戶服務(wù)、訂單服務(wù)和商品服務(wù)的業(yè)務(wù)數(shù)據(jù)，通過Canal同步到ElasticSearch中形成大寬表，來支持對訂單的多維復(fù)雜查詢功能。

如下圖所示：

圖片

而現(xiàn)在的單體架構(gòu)就簡單多了，小張直接在MyBatis中將訂單表、商品表和用戶表進(jìn)行多表關(guān)聯(lián)，where條件中列出查詢項(xiàng)，再通過limit和order by支持分頁和排序即可，一條SQL語句搞定一切。

分布式事務(wù)——>本地事務(wù)

馬上小張又感受到了第二個(gè)爽點(diǎn)。

那就是在實(shí)現(xiàn)下單扣減庫存邏輯的時(shí)候，他再也不用引入Seata來實(shí)現(xiàn)分布式事務(wù)了。

況且如果選擇場景適合且性能最高的TCC模式的話，他還得自己手寫代碼來實(shí)現(xiàn)Try 階段和Confirm / Cancel 階段的業(yè)務(wù)邏輯， 那真是麻煩到家了。

1、Try 階段

image.png

如上圖描述，Try 階段所做的事情是，對各個(gè)業(yè)務(wù)服務(wù)進(jìn)行業(yè)務(wù)檢查和資源預(yù)留，并返回結(jié)果。

2、Confirm / Cancel 階段

圖片

如上圖描述，Confirm / Cancel 階段則是根據(jù) Try 階段執(zhí)行的結(jié)果，進(jìn)行業(yè)務(wù)提交或業(yè)務(wù)回滾操作。

嗯，單體架構(gòu)是不需要對數(shù)據(jù)庫進(jìn)行拆分的，小張這個(gè)在createOrder()方法中加上Spring的@Transaction注解，一行代碼解決戰(zhàn)斗。

服務(wù)化調(diào)用——>本地調(diào)用

小張感受到的第三個(gè)爽點(diǎn)在于，終于從服務(wù)化調(diào)用變成本地調(diào)用了，這里面省了太多的工作。

在微服務(wù)架構(gòu)中，如果選擇OpenFeign進(jìn)行RPC調(diào)用，還的需要一個(gè)注冊中心進(jìn)行服務(wù)注冊發(fā)現(xiàn)，并在服務(wù)調(diào)用者段引入各個(gè)依賴jar包。

對了，還得設(shè)置各種超時(shí)時(shí)間、重試次數(shù)之類的參數(shù)。

寫好了一段代碼邏輯之后，如果需要做聯(lián)調(diào)和單元測試的話，各個(gè)同事還得將上下游的各個(gè)服務(wù)全部啟動(dòng)起來，看看能不能互相調(diào)通之類的。

圖片

嗯，使用單體架構(gòu)就容易得多了，直接在代碼里進(jìn)行本地方法調(diào)用，一行代碼、不到一分鐘輕松搞定。

DevOps流程

系統(tǒng)上線后，小張終于感受到了他的最大爽點(diǎn)，那就是在整體的DevOps上，那真的是輕松得一批。

1、在微服務(wù)架構(gòu)中，業(yè)務(wù)代碼開發(fā)完成后進(jìn)行提測，需要合并本次修改的好幾個(gè)工程的代碼，并將其部署到測試環(huán)境中，錯(cuò)一個(gè)差一個(gè)都會(huì)有問題。

2、在微服務(wù)架構(gòu)中，一坨微服務(wù)的測試環(huán)境維護(hù)起來真的麻煩，不知道哪個(gè)服務(wù)的代碼沒有更新到最新版本，測試起來都會(huì)遇到問題。

3、在微服務(wù)架構(gòu)中，測試完成進(jìn)行發(fā)布上線的時(shí)候，需要發(fā)布好幾個(gè)服務(wù)才行，還要梳理清楚這些服務(wù)的上下游依賴，不然在發(fā)布上線期間會(huì)出現(xiàn)故障。

對了，上線發(fā)布失敗進(jìn)行回滾的時(shí)候也同樣麻煩。

4、在微服務(wù)架構(gòu)中，問題排查也著實(shí)讓人頭疼，想查清楚一筆下單為什么耗時(shí)這么久，還得引入鏈路追蹤工具SkyWalking或者Spring Cloud Sleuth + Zipkin。

圖片

同樣，想查清楚一筆下單為什么報(bào)錯(cuò)，還得引入EFK日志收集、排查工具，麻煩得要死。

而單機(jī)架構(gòu)統(tǒng)統(tǒng)沒有這些問題，提交代碼只需要Merge一個(gè)工程的代碼，發(fā)布上線也只需要發(fā)布一個(gè)工程，SkyWalking、Spring Cloud Sleuth + Zipkin、EFK都不需要，只要有一個(gè)Prometheus + Grafana監(jiān)控工具即可。

至于只有一個(gè)服務(wù)的測試環(huán)境，那維護(hù)起來更不是事兒了。

結(jié)語

當(dāng)然，我們在這里絕不是要抹黑或全盤否定微服務(wù)架構(gòu)，畢竟存在即合理。

只是三五個(gè)人的小研發(fā)團(tuán)隊(duì)真沒必要引入，更沒必要過度微服務(wù)化，在服務(wù)粒度上拆分得過細(xì)，僅此而已。