各位面试官好，我之前在公司里做了一个基于SpringCloud框架的名为“智慧生鲜”的微服项目，我们项目组负责了大概
20多个模块，这个项目期间我自己独立承担了大概8个模块。像权限模块，通用模块，管理模块，抢购模块，搜索商品等等。
这个系统是采用基于SpringCloud的微服项目。另外也接触了许多技术，比如说Vue,支付宝这些第三方技术，另外我还
接触到缓存技术Redis，全文索引技术Elasticsearch,我还接触了一些环境，也可以搭建一些环境，比如说Elasticsearch+
Logstash+Kibana+Kafka实现分布式系统日志收集系统的搭建和使用，此外还可以搭建一个docker环境，实际上我们的项目
考虑到成本和性能的原因，所以我们将我们的系统搭建在docker之上，而且本人对维护有着较为浓厚的兴趣，所以我当时
也参与了服务部署，我可以通过dockerfile脚本文件完成整个项目的部署。
另外，谈设计数据库可以采用的是分库分表的方式，我们采用的是Mycat,这是一个基于Mysql的数据库中间件来进行分库分表，
分片的规则是Partition by mode,用分库分表的原因主要是我们的订单业务数据量实在太大，所以根据这一业务需求，我们
去做了这一个扩容。当时在使用了Mycat之后确实数据库压力有所减轻。
其实在数据库中间件之前呢，我们还有一个技术叫做redis+token令牌机制实现登录，它能够解决传统session登录的问题。
并且我们还使用了MD5对用户信息进行加密，来防止用户信息被篡改。像集群服务器当中这个Session共享的问题，众所周知
这个session的效率不高，还耗费资源。谈到这个令牌机制，谈到Redis,不得不谈消息队列，实际上就是消息中间件，之前
用过很多消息中间件，像构建分布式系统日志收集系统时用的Kafka，多线程高并发多用户抢购的问题时用到了ActiveMq，
还有用作事务的RabbitMq,我印象比较深的是当时的一个类似于双十一抢购的抢购服务使用ActiveMq，这个主要是利用
redis分布式锁setnx原理，引入分布式锁的原因是为了解决抢购过程中的安全问题，主要是抢超和重复抢的问题。
所谓的分布式锁其实就是上锁和去锁，当我们每次调用抢购方法的时候每次要去上锁，抢购完成之后要去锁，后面的用户才能重新
获得锁，再去抢购商品，同样的抢购的时候也需要上锁。上锁的时候需要给锁设置一个有效时间，如果锁一直存在达到一定时间会
直接让锁失效，这样让系统不会因为一个用户一直卡住。在我们引入分布式锁之后，发现分布式锁有一个致命问题，当时我们使用
的是Apache提供的高并发压力测试工具Jmeter，这个工具可以模拟多线程情况下多个用户抢购的情况，测试出来分布式锁的效率
比较低。于是我们引入ActiveMq来解决效率低下的问题，实现流量削峰。当我们用户发送一个抢购请求的时候，用户会直接得到
一个排队成功的返回信息，实际上处理这个抢购请求的还是我们的consumer，然后处理完成之后将是否抢购成功发给ActiveMq,
然后配置一个监听器，后端做一个轮询接口，前端利用cros实时调用这个轮询接口，这样前端就可以不用等待，是一个异步请求，
并且接近实时的获取是否抢购成功。
另外，在后台管理模块中我们需要对每天的利润和商品需求变化等业务进行统计分析，所以我们用了JasperReport将报表导出到
Execl中，并用Highcharts的图表技术来显示数据的变化。在项目中也有其他的一些技术，比如说支付宝字符接口，百度地图Api,
短信验证接口，报表等等。