各位領導好，我從畢業后做了兩年Java開發工程師，剛開始都是一些SSM框架的項目，但是由於技術不斷更新，微服項目成為必然的趨勢，大約在做了1年的SSM框架，之后開始接觸微服項目，前后經理過Dubbo和SpringCloud兩種框架，接下來我就介紹一下簡歷上的第一個項目。
首先它是一個基於Springcloud框架的名為“永樂票務”的微服項目，我們項目組負責了大概20多個模塊，這個項目期間我自己獨立承擔的大概八個模塊。其實前期我還參加了SSM項目，大致的功能就是支撐永樂票務的系統的功能。所以說真正的微服我只大概做了半年。我們項目組負責了大概20多個模塊，這個項目期間我自己獨立承擔的大概八個模塊。像登錄模塊，支付模塊，通用模塊，管理模塊，權限模塊，運營模塊等等。在做這個項目期間我也學到了很多知識。
總體來說，系統采用的是基於Springcloud的微服項目，采用的是中台架構。另外也接觸了很多技術，比如說Vue、Angular.js、LayUi、ElementUi、Node.js、微信小程序，微信公眾號，支付寶這些第三方技術，另外呢我還接觸接觸到了緩存技術Redis,全文索引技術Elasticseach,還接觸了一些環境，也可以去搭建一些環境，比如說Elasticsearch+Logstash+kibana+Kafka實現分布式系統日志收集系統的搭建和使用，此外還可以搭建一個docker環境，實際上我們的項目考慮到成本和性能的原因，所以我們將我們的整個系統搭建在docker之上，實際上當時運維人員稀缺，之前一直在做的離職了，所以我當時也參與了服務部署事項，所以我可以通過dockerfile腳本文件完成整個項目的部署。
另外，我還參與了很多功能上的設計和環境上的實現，舉個例子說吧，我們設計了一個原生的權限框架，不同的用戶有不同的角色，不同的角色有不同的權限，系統之中有一個類似於審批流程的概念。其實談設計數據庫可以采用的是分庫分表的方式，我們采用的是Mycat,這是一個基於Mysql的數據庫中間件來進行分庫分表，分片的規則是Partition by mode,用分庫分表的原因主要是我們的訂單業務數據量實在太大，所以呢根據這一業務需求，我們去做了這一個擴容。當時在使用了Mycat之后確實數據庫壓力有所減輕。
其實在數據庫中間件之前呢，我們還有一個技術叫做redis+token令牌機制實現登錄，它能夠解決傳統session登錄的問題。像集群服務器當中這個Session共享的問題，眾所周知這個session的效率不高，還耗費資源。談到這個令牌機制，談到Redis,不得不談消息隊列，實際上就是消息中間件，之前用過很多消息中間件，像構建分布式系統日志收集系統時用的Kafka，多線程高並發多用戶搶購的問題時用到了ActiveMq，還有用作事務的RabbitMq,我印象比較深的是當時的一個類似於雙十一搶購的搶購服務當中使用ActiveMq，這個主要是利用redis分布式鎖setnx原理，引入分布式鎖的原因是為了解決搶購過程中的安全問題，主要是搶超和重復搶的問題。
所謂的分布式鎖其實就是上鎖和去鎖，當我們每次調用搶購方法的時候每次要去上鎖，搶購完成之后要去鎖，后面的用戶才能重新獲得鎖，再去搶購商品，同樣的搶購的時候也需要上鎖。上鎖的時候需要給鎖設置一個有效時間，如果鎖一直存在達到一定時間會直接讓鎖失效，這樣讓系統不會因為一個用戶一直卡住。在我們引入分布式鎖之后，發現分布式鎖有一個致命問題，當時我們使用的是Apache提供的高並發壓力測試工具Jmeter，這個工具可以模擬多線程情況下多個用戶搶購的情況，測試出來分布式鎖的效率比較低。於是我們引入ActiveMq來解決效率低下的問題，實現流量削峰。當我們用戶發送一個搶購請求的時候，用戶會直接得到一個排隊成功的返回信息，實際上處理這個搶購請求的還是我們的consumer，然后處理完成之后將是否搶購成功發給ActiveMq,然后配置一個監聽器，后端做一個輪詢接口，前端利用cros實時調用這個輪詢接口，這樣前端就可以不用等待，是一個異步請求，並且接近實時的獲取是否搶購成功。這是一個完整的搶購業務和解決方案，能完成這個部分，這是我比較自豪的。當然了這些部分也是和項目組的人一起做的。
另外，在項目中也有其他的一些技術，比如說支付寶字符接口，百度地圖Api,短信驗證接口，報表等等。報表就是將項目中的信息以excel的形式導出來，共客戶方財務或者我們的運維人員使用。當然報表模塊使用的也就死一個工具類Jcreporter，直接調用即可。
最后呢，我想說的是我其實也不是什么大咖，項目都是以團隊的形式做的，大家分工合作。我也有許多技術需要去學習，希望貴公司可以給我一個機會，為公司創造價值，提升自己。