11.8 Springcloud項目簡介

各位領導好，我從畢業後作了兩年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，直接調用便可。

最後呢，我想說的是我其實也不是什麼大咖，項目都是以團隊的形式作的，你們分工合做。我也有許多技術須要去學習，但願貴公司能夠給我一個機會，爲公司創造價值，提高本身。