由于一路一來看過很多的技術(shù)體系，也見證一些技術(shù)體系停止維護，想用自己覺得比較好的一套技術(shù)體系來做一個分布式微服務(wù)系統(tǒng)，包括開發(fā)層面，中間件層面和運維層面的技術(shù)，作為自己希望的一個技術(shù)團隊里的技術(shù)棧。

這年SpringCloud開始把以前的技術(shù)給停止維護了，如eureka、feign、zuul，還有當當網(wǎng)的那個elastic-job，當當網(wǎng)都要掛了。所以出于這些原因，想換一套好使的技術(shù)棧。

而且我看了其他的商城的項目，要么就是不使用微服務(wù)的，要么就是只寫了后端或者前端的，或者是知識純粹用技術(shù)把功能給寫出來，搬磚實現(xiàn)玩功能，做完而已，所以還是想自己按照真實一點的樣子來開發(fā)，試著解決和做如何可靠和穩(wěn)定分布式服務(wù)方案。

本文目的

1. 給大家介紹一下整體的設(shè)計和某些設(shè)計時，所用那款技術(shù)棧的原因。
2. 介紹開發(fā)小程序所用工具，著手前端開發(fā)
3. 以后逐一介紹每個技術(shù)場景的要點、技術(shù)難點
4. 一些東西只是在開發(fā)中，也還沒完成。
5. 本文也是為了自己寫一下自己喜歡的技術(shù)，留個底。

技術(shù)架構(gòu)

這次主要轉(zhuǎn)站SpringCloudAlibaba

服務(wù)治理：

springCloud Dubbo，因為SpringCloud原來那套都停止維護了。
雖然這次用回dubbo了，但是有些人說問是否后悔從dubbo轉(zhuǎn)springCloud，不會后悔呀，因為那時候dubbo只有服務(wù)調(diào)度治理功能，沒啥周邊配套的。
服務(wù)降級也是因為Hystrix不用了，所以用Sentinel

服務(wù)網(wǎng)關(guān)：

以前呆過的公司，是由一個java服務(wù)作為app的服務(wù)端，再聚合下游多個服務(wù)再提供給接口包一層返回給app的，還有那些鑒權(quán)功能，這次使用SpringCloud gateway轉(zhuǎn)發(fā)和鑒權(quán)。鑒權(quán)部分換了方式，這個點比較關(guān)鍵，放到后面業(yè)務(wù)系統(tǒng)設(shè)計來說。

消息隊列：

使用RocketMq，而不用rabbitMq（慢），也不用Kafka（沒有tag分標簽的功能，一個隊列多個消費者會消費相同的東西）

分布式事務(wù)：

就是跨系統(tǒng)的事務(wù)，以前都是使用最終一致性，異步處理的方式，這次看有沒有場景使用到分布式同步的事務(wù)，之前了解的是用LCN國人開發(fā)的框架，這次想用阿里的Seata。（目前開發(fā)中的還沒有使用上）

規(guī)則引擎：

圖上沒寫，這里說一下是使用drools，就是用于營銷服務(wù)的，是做那個店鋪里的各個優(yōu)惠的規(guī)則，如：滿100減去10，滿3件減10塊，滿多少送1個物品的這些規(guī)則。其實都可以用規(guī)則引擎來做，以前呆過的網(wǎng)貸公司，那時是用于對接n第三方時不同規(guī)則。

定時任務(wù)調(diào)度：

SchedulerX，而不用elastic-job，因為當當要掛了。唯品會用elastic-job封裝了一下搞兩個叫saturn，而虎牙又把saturn封裝，這次調(diào)研一下SchedulerX，看看哪個好使。

自研自動生成RestFul接口：

這個是我自己做的一個框架，concise-mvc，簡約mvc生成器，因為微服務(wù)現(xiàn)在都是用dubbo調(diào)用了，沒有http協(xié)議的接口給springCloudgateway或者上層應(yīng)用使用。所以搞了個根據(jù)某個特制的注解下的interface，都生成：/ #{interface名字}/#{方法名字}的uri。這樣開發(fā)者就可以只開發(fā)dubbo接口，自動生成好http接口讓gateway來調(diào)用。

前端：

前端目前只做小程序端，不做pc端，這次前端也是我自己寫，使用uniapp，這個框架呢是可以用一份代碼，實現(xiàn)微信、抖音、百度等小程序的編譯，他編譯會自動轉(zhuǎn)換為他們需要的接口。為什么不用他來實現(xiàn)pc端的前端代碼，是因為pc比較大，樣式布局就不一樣了。

后臺管理系統(tǒng)

是使用vueadmin的框架，也是跟uniapp那樣給你做好了導(dǎo)航欄那些，跳轉(zhuǎn)那些。在里面寫實現(xiàn)就好了。

運維設(shè)施方面技術(shù)棧是我在貸款公司里覺得比較好使的一些組件，后面去的公司也很多都用那些，其中最好的是以前貸款公司基于k8s開發(fā)的系統(tǒng)，因為其他的公司搞的k8s部署就只能一個test環(huán)境和prod環(huán)境。

其實那框里面很多都是本項目中我不會去做的，因為沒有時間做太多，可能會找別人幫忙部署。

微服務(wù)劃分

UDB系統(tǒng)

我看很多個系統(tǒng)里都有個叫security的服務(wù)，但是他們只是做鑒權(quán)功能。而這里為什么叫udb，是因為我在一個互聯(lián)網(wǎng)公司的時候這個系統(tǒng)不只是僅僅的鑒權(quán)，而是做了統(tǒng)一帳號的功能，就是讓微信、手機登陸、QQ的授權(quán)登錄，都統(tǒng)一一個地方，讓相同的人的微信號、qq號都綁定為一個號碼。并且生成出一個id，作為userId，讓業(yè)務(wù)其他系統(tǒng)都通過此id統(tǒng)一來交互。

微信授權(quán)其實也是oauth2的。

這樣統(tǒng)一個鑒權(quán)的地方，生成的token就可以包含userId，這個使得開發(fā)springCloudgateway，可以使用GatewayFilter統(tǒng)一攔截數(shù)據(jù)的接口，filter里先做鑒權(quán)，讓udb系統(tǒng)返回userid，然后把userid，塞到Http的body里面，讓gateway下游系統(tǒng)使用這個userId，這樣就能保證用戶自己才能修改自己的數(shù)據(jù)，不會修改了別人id的數(shù)據(jù)，除非你把token都給別人了。

通過這樣的結(jié)合Udb系統(tǒng)和springCloudgateway，就可以統(tǒng)一userId交互，統(tǒng)一鑒權(quán)，別各個項目，如一時電商一時點餐，當相同的人的時候就一個userId不同appId區(qū)分就好了，不然一個人來相同的企業(yè)有不同的身份證號，你看工商銀行app和e融app里面也是相同的自然人號，不同的業(yè)務(wù)id。

營銷服務(wù)

這里包括優(yōu)惠券，促銷活動，商家活動的優(yōu)惠方式，其中上文說到的店鋪優(yōu)惠，一時滿100減去10，一時滿3件減10塊，如果你用傳統(tǒng)方式，都存到表里叫商店優(yōu)惠規(guī)則，一個商店就有多個規(guī)則，那你優(yōu)惠條件有很多種，每種又有不同結(jié)果，在代碼里if else很麻煩的，所以先建議使用drools，后再講怎么用。

其他的服務(wù)我覺得很常規(guī)，就看扣錢扣商品的時候是最終一致性還是要做分布式事務(wù)那些不詳細講了。

結(jié)語

總有一天大家也會獨立完成自己喜歡的系統(tǒng)，搭建自己的玩具。