【session】Java電商平臺開發技能圖譜，探秘雙十一百萬PV

您將學習

Java電商平臺開發技能圖譜，探秘雙十一百萬PV

分享內容

企業級Java開發技能圖譜

從宏觀到微觀，Java到底怎么學

為了支撐雙十一，我們對Java程序做了什么

你將認識

熱愛分享的常樂君

開源組織javagrowing成員、CSDN博客專家、華為云專家

Thoughtworks咨詢師，華東區Tech Lead

5年Java開發經驗，1年培訓新人經驗

喜歡leetcode打野，偶爾出現在周賽前排

年少時兼職過主播和公益廣告模特，可以靠顏值吃飯卻非要拼技術

正文

Hi，小伙伴們，不知道大家是否經歷過學習了一門新的語言，了解了基本的語法，可以寫出能夠運行的程序之后，卻不知道下一步該做什么的窘境。

在工作生活中大多數同學還是有一定的Java開發基礎，當然我們的小伙伴中也不乏具有豐富開發經驗的同學，希望等下我在分享技能圖譜的時候大家都能從中有所收獲。

企業級Java開發技能圖譜：

接下來我們就直入主題，給大家分享一下技能圖譜。這里我推薦JGrowing技能圖譜，這是一份由諸多一線大廠開發人員和技術負責人共同整理的技能圖譜，也是我所在的JavaGrowing開源團體共同制作的。項目的地址在這里：https://github.com/javagrowing/JGrowing 因為臨近雙十一所以大部分貢獻者都暫時沒時間處理issue和pr，在雙十一之后項目會陸續被維護起來。

可以看到這個技術圖譜是以企業級Java開發人員為目標而不是單純的面試準備，涵蓋了Java基礎，計算機基礎，數據結構與算法，分布式，基礎開發工具，常用框架，分析設計，服務端開發和一些面經。其中也包括了一些書籍。我推薦大家這樣使用這個圖譜（也是我的使用方式）：首先選擇一個近期打算強化的類型，比如Java基礎中的Java并發編程工具，那么我們定位到需要掌握的技能是并發的核心工具，同時也應當掌握線程安全性分析基礎和線程池的相關概念。然后就可以通過尋找適當的方式：比如閱讀源碼（j.u.c），閱讀有關書籍（JCIP：Java并發編程實戰），購買一些在線課程（如果覺得看書枯燥無味的話）或者是詢問身邊更有經驗的人：）

宏觀與微觀，Java到底怎么學？

Java知識圖譜為我們建立了宏觀上的知識框架，這個框架是很有必要的，因為不知道大家是否經歷過這樣的場景：有一天聽到自己的同學/同事/朋友在談論一項技術，比如WebFlux。這時候機敏好學的你嗅到了新技術的味道，然后就隨手打開了搜索引擎輸入：“WebFlux是什么”，在琳瑯滿目的搜索結果中你對WebFlux有了一個初步的認識：“WebFlux是SpringFramework5.0中的新功能，是一個典型的非阻塞異步框架，它的核心是基于Reactor相關API實現的，可以運行在Netty，Undertow以及支持Servlet3.1的容器上…bla bla bla“。這時候你大概對WebFlux有了一個基本的認識，等下，你有沒有覺得，似乎只是有了一個認識，具體WebFlux可以在什么場景下使用？還不知道。WebFlux框架下程序如何編寫？還不知道。WebFlux的底層實現原理是什么？又不知道。自己進入了一種似懂非懂，聽過名字，知道簡介卻還是一問三不知的狀態。這時候就需要你的知識框架和思考體系出馬了！

我們先從宏觀上看，WebFlux是一個Web框架，我們在它的官網上找到了他和SpringMVC的對比：

那么到這里，我們大概知道WebFlux具有Controller的功能，同時又能提供響應式的client。這時候就可以在我們的知識框架中宏觀上將它放入Spring技術體系下的和SpringMVC一樣或類似的位置，然后就可以進入對他的微觀學習。

接下來我們再嘗試著從微觀的角度去分析一下WebFlux和它的周邊技術，我們可以深入某一個自己感興趣的點，比如如何利用WebFlux寫一個demo，WebFlux如何實現在有限的系統資源下提高伸縮性等。這里我們以圖片右下角的Netty為例，深入下去，Netty是對Java NIO的封裝，而Java NIO又涉及到計算機系統底層epoll相關的概念。這時候你就徹底的進入到了一個微觀的領域，再從下到上，理解為什么epoll相較于poll和selector具有更好的性能，Netty是通過怎樣的封裝解決了Java NIO的一些潛在問題。進而達到微觀宏觀的融會貫通。

為了支撐雙十一，我們做了什么？

自從2009年雙十一淘寶促銷以來，各大電商，企業乃至線下商超都投入到了這場一年一度的全民購物狂歡。雙十一期間紛紛出現的限量秒殺，限時支付，拼團拼購等玩法對線上服務系統提出了不小的挑戰。作為國內最大的進口家居廠商，我所服務的公司也提出了多種線上玩法旨在招攬用戶，提升銷量。那么為了應對可能突如其來的流量，我們都做了什么呢？

如果我們要進行一段代碼或一個架構的性能優化，我們如何知道自己性能優化的好壞呢？

首先需要測量。如果需要知道我們做了一件事的效果，我們首先就要能分清什么是好，什么是壞，也就是說要能夠使我們做的事情是可衡量的。只有知道了代碼修改之前的性能，對比代碼修改之后的性能，我們才能知道自己對于代碼的修改就是是否有影響，以及這個影響是正向的影響還是負向的影響。

這里就給大家帶來另一個互動小問題，請問有多少人知道TDD？以及有多少人在實際的開發過程中是遵從TDD原則來進行開發的呢？

正如TDD中所要求的任何對于代碼的改動都需要測試先行作為安全網的原則一樣，對于代碼邏輯或者架構的性能優化也需要保證可測試性。

這里我們團隊選用Gatling(https://gatling.io/)作為負載測試，作為一款支持Scala語言編寫測試定義的as code的開源測試工具，Gatling易于編寫維護，所有配置參數均通過代碼定義，從最大程度上減少了測試人員的手工操作成本，通過編寫良好的測試程序，只需要修改極少數參數信息就可以快速測試不同用戶負載下的機器性能數據，并生成詳細的性能分析報告和錯誤統計報告。這里我不打算詳細的向大家介紹Gatling的用法，感興趣的同學可以在官網自行查看文檔和demo。

利用Gatling我們對加購，結算，支付，退款，訂單生成以及限量秒殺，紅包卡券等功能進行了詳盡的性能測試，生成了服務SLA的同時利用Arthas對熱點代碼進行監控，結合業務邏輯提出了很多優化方案，這里簡要分享幾個：

架構

1.在架構上，我們分別在網關層（Nginx，API Gateway），容器層（Tomcat）和服務層進行了限流配置和流量監控，使用了諸如令牌桶，流速控制以及最大連接數控制等方案保證服務穩定性。

使用消息隊列服務實現對大流量的削峰填谷，使用Servless改寫部分邏輯使其能夠在高訪問場景下自行動態擴容。

代碼

2.代碼層面，我們結合業務邏輯減少了鎖粒度并適當對鎖進行了降級來減少鎖爭用情況。A.比如過去的結算流程用偽代碼大概是：

function checkout() { lock() { checkPrice() checkDelivery() checkItemAvailable() lockCoupon() sendToDownStreamSystem() reduceItemAmount() } }

經過修改之后的邏輯是

function checkout() { checkPrice() checkDelivery() checkItemAvailable() lockCoupon() lock() { checkoutItemAvailable() reduceItemAmount() } sendToDownStreamSystem() }

B.同樣是扣減場景，如果是不敏感的情況我們降低了鎖的方式，改使用樂觀鎖CAS的方式完成用戶唯一可領取一張的優惠券的校驗過程。

fucntion retrieveCoupon(user) { lock(user){ someThingBeforeAssign() ifNotExistTargetCoupon(user) { assignCoupon(user) someThingAfterAssign() }}

經過修改過后是：

fucntion retrieveCoupon(user) { someThingBeforeAssign() boolean flag = assignCoupon(user) if(flag) { someThingAfterAssign() } } @Transactional function assignCoupon(user) { ifNotExistTargetCoupon(user) { assignCoupon(user) } }

C.通過異步事件處理機制減少單一邏輯阻塞：比如發送通知郵件短信等，受限于第三方服務響應效率，可能第三方服務在高負載情況下響應速度較慢，對于時效性不長的場景，可以通過異步事件進行優化

function placeOrder() { redeemCoupon() sendToOrderHub() sendEmail() sendSMS() }

經過優化后

function placeOrder() { redeemCoupon() sendToOrderHub() sendEvent(SendEmailEvent) sendEvent(SendSMSEvent) } class EventHandler() { handleEmailSendEvent(SendEmailEvent) { sendEmail() } handleSMSSendEvent(SendSMSEvent) { sendSMS() } }

基礎設施

3.在基礎設施層面，我們配置了動態擴容規則，并且準備了備用機器以防單點故障。增加備用數據庫配置，對數據庫等服務進行了適當實例增強準備。同時進行了詳細的基礎設施故障演練，應對突發狀況制定響應規則和響應策略

Ruby 緩存 Java Spring Cloud 分布式

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。