领导你好，接下来我介绍一下我之前做的一个项目---江苏南京国税局
它是基于Springcloud框架的一个税务咨询和缴纳的项目，我们项目组负责了大概20多个模块，这个项目期间我自己独立承担的大概八个模块。像权限模块，通用模块，管理模块，申报纳税模块、信息查询模块等等。在做这个项目期间我也学到了很多知识。
接触了很多技术，比如说Vue、LayUi、微信小程序、税控盘这些第三方技术，另外呢我还接触到了缓存技术Redis,全文索引技术Elasticseach,还接触了一些环境，也可以去搭建一些环境，比如说Elasticsearch+Logstash+kibana+Kafka实现分布式系统日志收集系统的搭建和使用，此外还可以搭建一个docker环境，实际上我们的项目考虑到成本和性能的原因，所以我们将我们的整个系统搭建在docker之上，是而本人对维护有着较为浓厚的兴趣，所以我当时也参与了服务部署事项，我可以通过dockerfile脚本文件完成整个项目的部署。
另外，我还参与了很多功能上的设计和环境上的实现，其实谈设计数据库可以采用的是分库分表的方式，我们采用的是Mycat,这是一个基于Mysql的数据库中间件来进行分库分表，分片的规则是Partition by mode,用分库分表的原因主要是我们南京的个体户和有限公司数量极具增长，所以根据这一业务需求，我们去做了这一个扩容。当时在使用了Mycat之后确实数据库压力有所减轻。
我们还用redis+token令牌机制实现登录，它能够解决传统session登录的问题。像集群服务器当中这个Session共享的问题，众所周知这个session的效率不高，还耗费资源。谈到这个令牌机制，谈到Redis,不得不谈消息队列，实际上就是消息中间件，之前用过很多消息中间件，像构建分布式系统日志收集系统时用的Kafka，多线程高并发多用户申报纳税的问题时用到了ActiveMq，每月1-15号定期的会有大量的用户登录纳税当中使用ActiveMq，这个主要是利用redis分布式锁setnx原理，引入分布式锁的原因是为了解决用户登录和缴纳税款的安全问题，主要是支付失败和重复支付的问题。
所谓的分布式锁其实就是上锁和去锁，当我们每次调用申报方法的时候每次要去上锁，申报缴费完成之后要去锁，后面的用户才能重新获得锁，再去申报，同样用户申报的时候也需要上锁。上锁的时候需要给锁设置一个有效时间，如果锁一直存在达到一定时间会直接让锁失效，这样让系统不会因为一个用户一直卡住。在我们引入分布式锁之后，发现分布式锁有一个致命问题，当时我们使用的是Apache提供的高并发压力测试工具Jmeter，这个工具可以模拟多线程情况下多个用户登录申报的情况，测试出来分布式锁的效率比较低。于是我们引入ActiveMq来解决效率低下的问题，实现流量削峰。当我们用户发送一个申报纳税请求的时候，用户会直接得到一个排队成功的返回信息，实际上处理这个申报请求的还是我们的consumer，然后处理完成之后将是否抢购成功发给ActiveMq,然后配置一个监听器，后端做一个轮询接口，前端利用quatz实时调用这个轮询接口，这样前端就可以不用等待，是一个异步请求，并且接近实时的获取是否抢购成功。这是一个完整的抢购业务和解决方案，能完成这个部分，这是我比较自豪的。当然了这些部分也是和项目组的人一起做的。
另外，在项目中也有其他的一些技术，比如说百度地图Api,短信验证接口，报表等等。