由于一路一来看过很多的技术体系，也见证一些技术体系停止维护，想用自己觉得比较好的一套技术体系来做一个分布式微服务系统，包括开发层面，中间件层面和运维层面的技术，作为自己希望的一个技术团队里的技术栈。

这年SpringCloud开始把以前的技术给停止维护了，如eureka、feign、zuul，还有当当网的那个elastic-job，当当网都要挂了。所以出于这些原因，想换一套好使的技术栈。

而且我看了其他的商城的项目，要么就是不使用微服务的，要么就是只写了后端或者前端的，或者是知识纯粹用技术把功能给写出来，搬砖实现玩功能，做完而已，所以还是想自己按照真实一点的样子来开发，试着解决和做如何可靠和稳定分布式服务方案。

本文目的

1. 给大家介绍一下整体的设计和某些设计时，所用那款技术栈的原因。
2. 介绍开发小程序所用工具，着手前端开发
3. 以后逐一介绍每个技术场景的要点、技术难点
4. 一些东西只是在开发中，也还没完成。
5. 本文也是为了自己写一下自己喜欢的技术，留个底。

技术架构

这次主要转站SpringCloudAlibaba

服务治理：

springCloud Dubbo，因为SpringCloud原来那套都停止维护了。
虽然这次用回dubbo了，但是有些人说问是否后悔从dubbo转springCloud，不会后悔呀，因为那时候dubbo只有服务调度治理功能，没啥周边配套的。
服务降级也是因为Hystrix不用了，所以用Sentinel

服务网关：

以前呆过的公司，是由一个java服务作为app的服务端，再聚合下游多个服务再提供给接口包一层返回给app的，还有那些鉴权功能，这次使用SpringCloud gateway转发和鉴权。鉴权部分换了方式，这个点比较关键，放到后面业务系统设计来说。

消息队列：

使用RocketMq，而不用rabbitMq（慢），也不用Kafka（没有tag分标签的功能，一个队列多个消费者会消费相同的东西）

分布式事务：

就是跨系统的事务，以前都是使用最终一致性，异步处理的方式，这次看有没有场景使用到分布式同步的事务，之前了解的是用LCN国人开发的框架，这次想用阿里的Seata。（目前开发中的还没有使用上）

规则引擎：

图上没写，这里说一下是使用drools，就是用于营销服务的，是做那个店铺里的各个优惠的规则，如：满100减去10，满3件减10块，满多少送1个物品的这些规则。其实都可以用规则引擎来做，以前呆过的网贷公司，那时是用于对接n第三方时不同规则。

定时任务调度：

SchedulerX，而不用elastic-job，因为当当要挂了。唯品会用elastic-job封装了一下搞两个叫saturn，而虎牙又把saturn封装，这次调研一下SchedulerX，看看哪个好使。

自研自动生成RestFul接口：

这个是我自己做的一个框架，concise-mvc，简约mvc生成器，因为微服务现在都是用dubbo调用了，没有http协议的接口给springCloudgateway或者上层应用使用。所以搞了个根据某个特制的注解下的interface，都生成：/ #{interface名字}/#{方法名字}的uri。这样开发者就可以只开发dubbo接口，自动生成好http接口让gateway来调用。

前端：

前端目前只做小程序端，不做pc端，这次前端也是我自己写，使用uniapp，这个框架呢是可以用一份代码，实现微信、抖音、百度等小程序的编译，他编译会自动转换为他们需要的接口。为什么不用他来实现pc端的前端代码，是因为pc比较大，样式布局就不一样了。

后台管理系统

是使用vueadmin的框架，也是跟uniapp那样给你做好了导航栏那些，跳转那些。在里面写实现就好了。

运维设施方面技术栈是我在贷款公司里觉得比较好使的一些组件，后面去的公司也很多都用那些，其中最好的是以前贷款公司基于k8s开发的系统，因为其他的公司搞的k8s部署就只能一个test环境和prod环境。

其实那框里面很多都是本项目中我不会去做的，因为没有时间做太多，可能会找别人帮忙部署。

微服务划分

UDB系统

我看很多个系统里都有个叫security的服务，但是他们只是做鉴权功能。而这里为什么叫udb，是因为我在一个互联网公司的时候这个系统不只是仅仅的鉴权，而是做了统一帐号的功能，就是让微信、手机登陆、QQ的授权登录，都统一一个地方，让相同的人的微信号、qq号都绑定为一个号码。并且生成出一个id，作为userId，让业务其他系统都通过此id统一来交互。

微信授权其实也是oauth2的。

这样统一个鉴权的地方，生成的token就可以包含userId，这个使得开发springCloudgateway，可以使用GatewayFilter统一拦截数据的接口，filter里先做鉴权，让udb系统返回userid，然后把userid，塞到Http的body里面，让gateway下游系统使用这个userId，这样就能保证用户自己才能修改自己的数据，不会修改了别人id的数据，除非你把token都给别人了。

通过这样的结合Udb系统和springCloudgateway，就可以统一userId交互，统一鉴权，别各个项目，如一时电商一时点餐，当相同的人的时候就一个userId不同appId区分就好了，不然一个人来相同的企业有不同的身份证号，你看工商银行app和e融app里面也是相同的自然人号，不同的业务id。

营销服务

这里包括优惠券，促销活动，商家活动的优惠方式，其中上文说到的店铺优惠，一时满100减去10，一时满3件减10块，如果你用传统方式，都存到表里叫商店优惠规则，一个商店就有多个规则，那你优惠条件有很多种，每种又有不同结果，在代码里if else很麻烦的，所以先建议使用drools，后再讲怎么用。

其他的服务我觉得很常规，就看扣钱扣商品的时候是最终一致性还是要做分布式事务那些不详细讲了。

结语

总有一天大家也会独立完成自己喜欢的系统，搭建自己的玩具。