各位面試官好，我之前在公司里做了一個基於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,
短信驗證接口，報表等等。