背景
因为一路一来看过很多的技术体系，也见证一些技术体系进行保护，想用本人感觉比拟好的一套技术体系来做一个散布式微服务零碎，包含开发层面，中间件层面和运维层面的技术，作为本人心愿的一个技术团队里的技术栈。
这年SpringCloud开始把以前的技术给进行保护了，如eureka、feign、zuul，还有当当网的那个elastic-job，当当网都要挂了。所以出于这些起因，想换一套好使的技术栈。
而且我看了其余的商城的我的项目，要么就是不应用微服务的，要么就是只写了后端或者前端的，或者是常识纯正用技术把性能给写进去，搬砖实现玩性能，做完而已，所以还是想本人依照实在一点的样子来开发，试着解决和做如何牢靠和稳固分布式服务计划。
本文目标
- 给大家介绍一下整体的设计和某些设计时，所用那款技术栈的起因。
- 介绍开发小程序所用工具，着手前端开发
- 当前逐个介绍每个技术场景的要点、技术难点
- 一些货色只是在开发中，也还没实现。
- 本文也是为了本人写一下本人喜爱的技术，留个底。
欢送关注公众号，文章更快一步
我的公众号 ：地藏思维
技术架构
这次次要转站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，后再讲怎么用。
其余的服务我感觉很惯例，就看扣钱扣商品的时候是最终一致性还是要做分布式事务那些不具体讲了。
已开发实现样例
结语
总有一天大家也会独立实现本人喜爱的零碎，搭建本人的玩具。
欢送关注公众号，文章更快一步
我的公众号 ：地藏思维
掘金：地藏Kelvin
简书：地藏Kelvin
我的Gitee： 地藏Kelvin https://gitee.com/kelvin-cai
本文由博客一文多发平台 OpenWrite 公布！