共计 2597 个字符，预计需要花费 7 分钟才能阅读完成。
背景
因为一路一来看过很多的技术体系，也见证一些技术体系进行保护，想用本人感觉比拟好的一套技术体系来做一个散布式微服务零碎，包含开发层面，中间件层面和运维层面的技术，作为本人心愿的一个技术团队里的技术栈。
这年 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 公布！
