大型电商微服务分布式体系架构技术解析

项目架构体系解析

架构运行流程：
1.客户端通过PC和手机访问服务器的路由器，VIP是虚拟IP，Keepalived是虚拟路由器，Nginx是web服务器
2.路由器访问的是虚拟IP，虚拟IP被绑定到两个虚拟路由器的任意一个上，用户每次只会请求其中一个路由器，如果其中一个Nginx崩溃了，那么虚拟路由器上的虚拟IP会全部转移到另外一个虚拟路由器上去，Keepalived+Nginx主要是解决nginx单点故障，nginx还可以限流，可以根据IP限流，可以根据访问速率限流，比如说这个网站每秒只限制10个人访问，每秒一个IP只允许访问两次，而且nginx自带缓存，所有的用户访问，它都能够通过缓存来提高服务的一个抗压能力，对于后台缓存不会造成任何压力，后期还会整合OpenResty的Nginx变的更加强悍，能处理10k-1000k的并发量
3.进入到微服务网关Geteway集群，微服务网关主要实现的作用是，将用户请求路由到不同的微服务去，而且微服务也可以限流，微服务网关需要服务器发布起来，那么服务器的承受并发是有限的，这个时候微服务网关可以给每个微服务提供一个保护措施，防止大量流量涌入进来对服务造成压力，除了限流之外，还可以实现权限效验，可以在微服务网关直接判断用户是否拥有能力访问这个商品微服务
4.访问后台的微服务，分为四大块，分别是业务微服务、公共组件微服务、抽取、负载均衡，每个微服务都是一个独立的模块，微服务之间的调用使用Feign来相互调用，相互调用一定会涉及到JavaBean的操作，所有我们把JavaBean和Feign单独抽取出来，其实Feign就是实现了Ribbon的负载均衡的控制，Hystrix熔断/降级服务也提取出来，使用fescar把分布式事务单独抽取出来，谁要实现事务依赖就行了，谁不需要实现事务把依赖去掉就行了，所有分布式事务这一块做的比较灵活，让各个组件形成一种可插法的组件型的模式，oauth2.0也抽取出来，让他单独实现一个微服务限权，rabbitmq也单独抽取出来，canal微服务是实现数据的同步接听的，支付微服务也给单独抽出出来了，因为之后每个工程都有可能用到支付操作
5.各个微服务文件的监听使用SpringCloud Bus消息组件，监控中心使用Hystrix Dashboard，注册中心使用Eureka，配置统一管理我们使用ConfigServer，远程仓库使用github
6.数据支撑方面，数据的检索商品的搜索使用Es集群，完整的数据用MySql保存，缓存用Redis，文件管理使用FastDFS

技术选型：
Lua：编写软件插件，比如外挂，我们在项目里实现缓存的更新操作
Redis：redis集群
Eureka：搜索引擎集群
SpringBoot：开发框架
OAuth2.0：实现权限的操作
JWT：用来封装用户授权信息的
Spring AMQP：异步消息队列
MyBatis+通用Mapper：持久化技术，操作数据库的
SpringDataEs：持久化技术，操作Es索引库
SpringDataRedis：持久化技术，操作redis缓存
mySQL：mysql主从、复制、读写分离
RabbitMQ：消息队列
支付接口：微信支付

技术点的解决方案：
1.nginx单点故障使用：Nginx Master+Keepalived虚拟路由器，OpenResty实现Nginx高并发（10k—1000k并发）
2.微服务网关：Gatevay集群，限流作用
3.抽取：Feign服务调用
4.负载均衡：Ribbon负载均衡，Hystrix服务熔断/降级
5.消息组件：SpringCloud Bus
6.监控中心：Hystrix Dashboard
7.注册中心：Eureka
8.配置统一管理：ConfigServer
9.远程仓库：github
10.数据支持：数据的检索，商品的搜索用ES集群，完整的数据进行保存用Mysql集群，缓存用Redis集群，文件用FastDFS

数据库表设计：在大型应用里面推荐反三范式，比如以前表与表之间保持一种原则性，还有另一个表与表要保证数据的完整性，表与表就会有依赖，那么增删改速度会变慢
1.建议不要创建外键，增删改不用去检查依赖
2.数据冗余操作，增加冗余数据，不需要外键关联