在诸多项目模块中，我接触了很多技术Vue，layui等，微信小程序，微信公众号，支付宝等第三方的一些技术，我前期参与了当中的ssm项目，微服其实我只是做了半年，但是有很多共性。我还接触到了一些缓存技术redis，并且我还接触了一些环境，还搭建了一些环境，例如：Elasticsearch+logstash+Kibana+Kafka环境，作为一个日志的收集的功能。我还会独立搭建一个docker环境，所有的服务都是搭建在docker环境上，但是考虑到运营成本不够，减少陈本，第二，为了提高性能。在此之前也招了运维人员，但很快就离职了，所以我但是也参与了部署整个环境的一个任务，我参与了大概有半年的时间。实际上我还参与了一些功能上的设计以及环境上的实现。例如，原生权限，用户角色及用户权限，不同的用户有不同的角色，不同的角色有不同的权限，在整个功能模块中，我还使用Mycat数据库中间键，掌握分片规则:PartitionByMod，并对系统中部分业务库进行水平切割和分库分表操作，当时用分库分表的原因，主要是我们的订单业务的数据量太大了，所有为了符合客户方的需求，所以我们进行了一些扩展。当时我们的设计思路是用数据库中间件Mycat，在使用了Mycat数据库中间件，确实数据量的压力减少了许多。
谈到了消息中间件，在消息中间件之前还有redis+token，redis+token利用的是令牌的机制，实现的登录。之前，利用session实现session共享，后来发现session不能在app端使用，于是项目组组长又让我们实现了一套token机制去实现跨平台。谈到token令牌机制和redis不得不谈一个很厉害的技术:消息队列（消息中间件），在项目中用了ActiveMq，RabbitMq，kafka。印象比较深的是ActiveMq在抢购、多线程、高并发的情况下用到的，我在事务当中用到了RabbitMq，日志中使用到kafka。在我的认识中ActiveMq是做事务的，kafka是做日志收集的。在做多线程，高并发，多用户场景时，利用到了ActiveMq，目的是为了实现抢购这一功能。此功能主要是利用了分布式锁setnx基于redis的一个setnx的技术。当时引用分布式锁解决安全性问题。当时在高并发的时候出现了重复抢和抢超的两种问题。所有我们引用了分布式锁机制。在整个项目组引入分布式锁后，我们发现其性能太低，于是测试团队用压力测试工具JMeter ，测试出性能确实降低了很多。后来就引用了ActiveMq消息中间件去解决这一问题。在引用了ActiveMq时候处理了流量削峰这一问题，但实际上当用户发出请求，用户可以直接得到一个排队成功的一个异步处理的结果。这一抢购功能是谁来处理呢？不是消息中间件，是consumer端（消费端）。消费端处理后，用户端怎么知道有没有抢购成功了呢？当时的处理方式就是引用了ActiveMq，并且配置了监听器。在后端做一个轮询接口，前端会实时的调用轮询接口，这样用户端不用等待异步处理，可以实时知道处于什么情况。
我希望可以为贵公司创造更大的利益。
谢谢！