面試官：遇到這樣的簡歷，我會(huì)多問幾個(gè)問題

作者：小傅哥，博客：https://bugstack.cn

哈嘍，大家好，我是技術(shù)UP主小傅哥。

作為求職者參與了那么多場面試，那你知道站在面試官的角度，拿到一份簡歷后，如何下手面試的嗎？今天小傅哥就接著一份簡歷，給大家分享下，一個(gè)項(xiàng)目都會(huì)問哪些問題（有粗有細(xì)）！

小傅哥本身也是一個(gè)面試官，面試過實(shí)習(xí)、校招、社招、架構(gòu)師，不同的面試訴求會(huì)有不同的考察范圍。通過這些考察范圍的問題讓求職者通過案例舉證，來闡述自己的能力項(xiàng)。而這些能力項(xiàng)的匹配，則是招聘的要求。這里不得不提到，有些小卡拉米的簡歷，只言片語的項(xiàng)目描述，浮皮潦草的個(gè)人職責(zé)。是真的沒進(jìn)入面試就沒了！

接下來小傅哥會(huì)通過求職者、面試官，兩個(gè)角色進(jìn)行分享。你可以在這個(gè)過程中，閱讀簡歷和提問。

本次項(xiàng)目摘選小傅哥星球「碼農(nóng)會(huì)鎖」第8個(gè)實(shí)戰(zhàn)項(xiàng)目，簡歷編寫和面試提問。項(xiàng)目地址：http://gaga.plus

一、求職者

面試官您好，大營銷平臺(tái)的 Raffle 抽獎(jiǎng)模塊，是我獨(dú)立負(fù)責(zé)實(shí)現(xiàn)的一個(gè)（學(xué)習(xí)/工作）項(xiàng)目，此項(xiàng)目模塊在架構(gòu)設(shè)計(jì)上運(yùn)用了 DDD 分層架構(gòu)和模板模式、責(zé)任鏈模式、組合模式、工廠模式等，這樣的設(shè)計(jì)模式對(duì)業(yè)務(wù)流程進(jìn)行解耦和實(shí)現(xiàn)。Raffle 抽獎(jiǎng)模塊的完整開發(fā)，讓我對(duì) SpringBoot 框架技術(shù)，分布式技術(shù)棧的運(yùn)用更加熟練，也把設(shè)計(jì)模式在實(shí)際場景的使用了起來，積累了豐富的設(shè)計(jì)實(shí)現(xiàn)經(jīng)驗(yàn)。這寫技術(shù)學(xué)習(xí)的內(nèi)容，也可以更好的應(yīng)對(duì)以后的開發(fā)工作。非常感謝您給我這次面試機(jī)會(huì)。

項(xiàng)目名稱：大營銷平臺(tái) - Raffle 抽獎(jiǎng)服務(wù)

項(xiàng)目架構(gòu)：微服務(wù)架構(gòu)、DDD 領(lǐng)域驅(qū)動(dòng)模型、前后端分離設(shè)計(jì)

核心技術(shù)：SpringBoot、MyBatis、MySQL、Redis、SpringCloud/Dubbo【按需添加，只是對(duì)外的接口形式】、React、TypeScript

項(xiàng)目描述：Raffle 抽獎(jiǎng)模塊是整個(gè)大營銷平臺(tái)系統(tǒng)中非常重要的一個(gè)模塊，也是本次項(xiàng)目中我來負(fù)責(zé)的設(shè)計(jì)和實(shí)現(xiàn)的模塊。此模塊主要以支撐各類差異化抽獎(jiǎng)流程，如；通用抽獎(jiǎng)、黑名單、人群、N消耗積分指定抽獎(jiǎng)范圍、抽獎(jiǎng)N次解鎖獎(jiǎng)品等各類玩法的支持。在此系統(tǒng)模塊的設(shè)計(jì)中運(yùn)用到了模板模式、責(zé)任鏈模式、組合模式、工廠模式，解決代碼的可擴(kuò)展性，并對(duì)抽獎(jiǎng)的計(jì)算和秒殺做了設(shè)計(jì)的優(yōu)化，可以支撐單機(jī) 2c4g 服務(wù)器 1500 ~ 2000 TPS 的吞吐量?！覆煌?wù)器，帶寬，以及是否還配置有環(huán)境相關(guān)，會(huì)有不同的數(shù)據(jù)效果」

核心職責(zé)：

以PRD文檔訴求和對(duì)功能的評(píng)審，設(shè)計(jì)出抽獎(jiǎng)的領(lǐng)域模型功能，以及在抽獎(jiǎng)的流程抽象上，分為；抽獎(jiǎng)前、抽獎(jiǎng)中、抽獎(jiǎng)后，的節(jié)點(diǎn)上擴(kuò)展各項(xiàng)行為動(dòng)作。如抽獎(jiǎng)前的人群判斷、抽獎(jiǎng)中庫存扣減、抽獎(jiǎng)后兜底獎(jiǎng)勵(lì)等。

依賴于領(lǐng)域模型的定義，設(shè)計(jì)出抽獎(jiǎng)庫表。抽象抽獎(jiǎng)過程為抽獎(jiǎng)策略表、策略明細(xì)表、規(guī)則配置表、規(guī)則樹動(dòng)作表，這樣會(huì)讓抽獎(jiǎng)更好擴(kuò)展。

設(shè)計(jì)模板模式定義抽獎(jiǎng)流程標(biāo)準(zhǔn)，再在模板模式中，調(diào)用責(zé)任鏈完成抽獎(jiǎng)，對(duì)于抽獎(jiǎng)中和后的動(dòng)作使用組合模式的規(guī)則樹進(jìn)行動(dòng)態(tài)處理【支持庫表配置】。

在項(xiàng)目架構(gòu)中定義統(tǒng)一標(biāo)準(zhǔn)的 api 由觸發(fā)器層實(shí)現(xiàn)，在觸發(fā)器層定義監(jiān)聽、任務(wù)、http、rpc模塊，所有的行為動(dòng)作，都理解為觸發(fā)行為。

抽獎(jiǎng)也是一種峰值流量高的業(yè)務(wù)場景，因此在設(shè)計(jì)獎(jiǎng)品庫存扣減上，采用了 Redis decr 分段消費(fèi)和加鎖兜底的設(shè)計(jì)，同時(shí)對(duì)于消費(fèi)成功的庫存，異步隊(duì)列方式 + 定時(shí)任務(wù)更新庫存。這樣可以不超賣的同時(shí)，又減少數(shù)據(jù)庫的壓力。

在項(xiàng)目開發(fā)中熟練運(yùn)用了 IntelliJ IDEA、WEbStorm、Docker、MySQL、云服務(wù)器、SSH工具，并已將項(xiàng)目完整部署到線上【在校伙伴可以提供線上案例版】。

二、面試官

謝飛機(jī)同學(xué)你好，你做的這個(gè)項(xiàng)目我非常感興趣，接下來我們可以來聊一下關(guān)于這個(gè)《大營銷平臺(tái)項(xiàng)目》你完成的抽獎(jiǎng)服務(wù)部分。

1. 你的項(xiàng)目工程是怎么搭建的？

項(xiàng)目的搭建類似于使用 start.spring.io 腳手架創(chuàng)建的，在我們的項(xiàng)目中，使用了統(tǒng)一 maven-archetype-plugin 插件，自定義了一套 DDD 工程骨架腳手架。同類項(xiàng)目都是使用這套腳手架創(chuàng)建項(xiàng)目，因?yàn)槟_手架定義了統(tǒng)一的版本標(biāo)準(zhǔn)和對(duì)應(yīng)配套的開發(fā)環(huán)境，所以使用起來更加容易。【如果延伸提問，你還了解哪種搭建腳手架的方式，可以回答 FreeMarker】

2. 在你的這個(gè)項(xiàng)目中，都用到了什么開發(fā)工具？項(xiàng)目是怎么部署的

使用到了 IntelliJ IDEA、WebStorm、Sequel Ace/Navicat、ApiPost、Docker、SwitchHosts、Termius（SSH）等，項(xiàng)目上線的時(shí)候使用了2個(gè)方式，一個(gè)是本地構(gòu)建前后端鏡像，PUSH 到 Docker Hub，再通過編寫 docker compose 腳本，在云服務(wù)器部署。另外一個(gè)是搭建 Jenkins 配置部署流水線的方式進(jìn)行部署。

3. 整個(gè)項(xiàng)目開發(fā)過程中，你熟練的掌握了哪些技術(shù)棧

在整個(gè)項(xiàng)目開發(fā)中熟練的使用了 SpringBoot、MyBatis、Redisson 等技術(shù)框架，在編程功能實(shí)現(xiàn)，熟練的結(jié)合與 Spring 容器，通過 Map 自動(dòng)裝配 Java 語言實(shí)現(xiàn)的策略模式。以及在項(xiàng)目中較多的使用了 Redisson 框架，向 Redis 寫入 key-value、queue、map、lock 等數(shù)據(jù)類型，實(shí)現(xiàn)業(yè)務(wù)功能。

4. 在項(xiàng)目開發(fā)過程中，你有遇到過哪些運(yùn)行時(shí)異常，怎么排查解決的

如剛開始項(xiàng)目開發(fā)引入腳手架以外的組件，進(jìn)行調(diào)試的時(shí)候，因?yàn)镴ar版本不同。出現(xiàn)過編譯通過，調(diào)用的時(shí)候方法不存在。通過 Maven Helper 插件，檢查到有其他組件多引入了相同Jar包。另外還有一些如開發(fā)調(diào)試中發(fā)現(xiàn)的空指針問題，如查后需要增加空對(duì)象判斷。此外其他一些更多是功能流程實(shí)現(xiàn)細(xì)節(jié)上，如項(xiàng)目中的規(guī)則樹節(jié)點(diǎn)判斷流程問題，拋出一些自定義的異常。這些通過在方法上斷點(diǎn)調(diào)試逐步的解決。

5. 因?yàn)槟愕捻?xiàng)目是前后端分離的，接口跨域怎么做的？

首先我們知道，Web跨域（Cross-Origin Resource Sharing，CORS）是一種安全機(jī)制，用于限制一個(gè)域下的文檔或腳本如何與另一個(gè)源的資源進(jìn)行交互。這是一個(gè)由瀏覽器強(qiáng)制執(zhí)行的安全特性，旨在防止惡意網(wǎng)站讀取或修改另一個(gè)網(wǎng)站的數(shù)據(jù)，這種攻擊通常被稱為“跨站點(diǎn)腳本”（Cross-Site Scripting，XSS）。

所以在我的前后端分離項(xiàng)目中，通過配置 @CrossOrigin 注解來解決跨越問題。開發(fā)階段 Access-Control-Allow-Origin: *、上線階段 Access-Control-Allow-Origin: https://gaga.plus

6. 看到你的項(xiàng)目用到了 DDD，這也是我們很感興趣的技術(shù)點(diǎn)，你可以介紹下你在使用 DDD 做這個(gè)項(xiàng)目時(shí)，都運(yùn)用了 DDD 哪些知識(shí)。

DDD 是一種軟件設(shè)計(jì)方法，軟件設(shè)計(jì)方法涵蓋了范式、模型、框架、方法論等內(nèi)容，而 DDD 的很多規(guī)范約定，都是為了提高工程交付質(zhì)量。如幾個(gè)很重要的知識(shí)點(diǎn)；框架分層結(jié)構(gòu)、領(lǐng)域、實(shí)體、聚合、值對(duì)象、依賴倒置等。它所有的手段，都希望以一個(gè)功能邏輯的實(shí)現(xiàn)為聚合，將功能所需的對(duì)象、接口、邏輯，按照領(lǐng)域劃分到自己的領(lǐng)域內(nèi)。

就像在這個(gè)項(xiàng)目中，我負(fù)責(zé)實(shí)現(xiàn)的抽獎(jiǎng)中的策略，就是一個(gè)獨(dú)立的領(lǐng)域模型。在這個(gè)領(lǐng)域中我需要提供策略的裝載、隨機(jī)數(shù)算法計(jì)算、抽獎(jiǎng)模板調(diào)用（含責(zé)任鏈和規(guī)則樹）功能，這樣一個(gè)領(lǐng)域就像劃分好的一個(gè)獨(dú)立個(gè)體，它擁有屬于它的對(duì)象信息（實(shí)體、值對(duì)象、聚合），當(dāng)需要使用數(shù)據(jù)庫資源、緩存資源，以及外部接口資源的時(shí)候，都通過依賴倒置進(jìn)行調(diào)用。也就是說，我的領(lǐng)域不做其他模塊的引入，而是領(lǐng)域只負(fù)責(zé)業(yè)務(wù)功能實(shí)現(xiàn)，所需的所有數(shù)據(jù)，則有外部接口通過依賴倒置提供。更多理論知識(shí)

7. 你的抽獎(jiǎng)流程中，哪些被定義為值對(duì)象，哪些被定義為實(shí)體對(duì)象

在 DDD 的規(guī)范定義中，值對(duì)象通常用于描述對(duì)象屬性的值，不具備唯一ID，不影響數(shù)據(jù)變化。如；數(shù)據(jù)庫中字段的枚舉值、業(yè)務(wù)流程中屬性對(duì)象。如抽獎(jiǎng)流程中，RuleLimitTypeVO 規(guī)則限定方式的枚舉值對(duì)象、還有 RuleTreeVO 規(guī)則樹值對(duì)象。而那些實(shí)體對(duì)象，則具備唯一ID，會(huì)影響到最后的寫庫動(dòng)作。如；抽獎(jiǎng)發(fā)起實(shí)體、獎(jiǎng)品信息實(shí)體對(duì)象。并且我們可以把一些和實(shí)體對(duì)象相關(guān)的功能聚合到對(duì)象內(nèi)，這樣的通用性會(huì)更好，避免所有調(diào)用方都需要自己編寫邏輯。

8. 關(guān)于訪問數(shù)據(jù)層的依賴倒置，是怎么使用的，有什么好處，你可以描述下嗎

DDD 中的依賴倒置是一個(gè)非常好的設(shè)計(jì)，尤其是與 MVC 結(jié)構(gòu)對(duì)比的時(shí)候，MVC 的貧血模型結(jié)構(gòu)設(shè)計(jì)，數(shù)據(jù)庫持久化對(duì)象，很容易被當(dāng)做業(yè)務(wù)對(duì)象使用，這樣后期非常難維護(hù)。但在 DDD 的分層結(jié)構(gòu)用，是以 domain 領(lǐng)域?qū)崿F(xiàn)為核心，一個(gè) domain 領(lǐng)域下所需的外部服務(wù)，都由領(lǐng)域?qū)佣x接口，讓基礎(chǔ)層做具體實(shí)現(xiàn)。而數(shù)據(jù)庫持久化操作，定義的 PO 對(duì)象，就被這樣的方式被限定在基礎(chǔ)層了，外部是沒法引入使用的，也就天然的防止了數(shù)據(jù)庫持久化對(duì)象進(jìn)入業(yè)務(wù)中。

9. 我看你簡歷有提到，把抽獎(jiǎng)劃分為抽獎(jiǎng)前、中、后，三個(gè)動(dòng)作。請(qǐng)具體結(jié)合場景講解下，為什么這樣設(shè)計(jì)

這個(gè)的設(shè)計(jì)得益于在 Spring/MyBatis 框架源碼的學(xué)習(xí)，在源碼中經(jīng)常會(huì)出現(xiàn)對(duì)一個(gè)流程進(jìn)行拆分解耦，流程可擴(kuò)展的點(diǎn)，如 Spring 是 Bean 對(duì)象的拆解，MyBatis 是會(huì)話流程的拆解。所以在設(shè)計(jì)大營銷的抽獎(jiǎng)模塊時(shí)，對(duì)于需求中的各類功能點(diǎn)；黑名單抽獎(jiǎng)、權(quán)重抽獎(jiǎng)、默認(rèn)抽獎(jiǎng)、抽獎(jiǎng)N次解鎖、兜底抽獎(jiǎng)等等情況，是可以拆解為抽獎(jiǎng)前、中、后，3個(gè)行為動(dòng)作的，基于這樣的考慮后，就可以設(shè)計(jì)出非常容易擴(kuò)展的松耦合結(jié)構(gòu)。

10. 是什么場景下使用了責(zé)任鏈模式，什么場景使用了組合模式，為什么？

在設(shè)計(jì)完抽獎(jiǎng)前、中、后，搜耦合的結(jié)構(gòu)模型后，對(duì)于抽獎(jiǎng)前要執(zhí)行哪種抽獎(jiǎng)，但單向選擇問題。所以這里使用了責(zé)任鏈模式，進(jìn)行節(jié)點(diǎn)流程判斷，從黑名單、權(quán)重，最后到默認(rèn)，走一個(gè)單獨(dú)的具體抽獎(jiǎng)，所以使用責(zé)任鏈更為合適。

之后是進(jìn)入抽獎(jiǎng)的中和后，這兩部的流程是相對(duì)復(fù)雜的，需要判斷用戶抽獎(jiǎng)了幾次，對(duì)于不同次會(huì)限定是否能獲得某個(gè)獎(jiǎng)品，同時(shí)還有庫存的扣減，如果庫存不足或者不滿足n次抽獎(jiǎng)得到某個(gè)獎(jiǎng)品，則會(huì)進(jìn)行兜底。那么這就是一個(gè)樹規(guī)則的交叉流程，所以會(huì)使用了組合模式構(gòu)建一顆規(guī)則樹，并通過數(shù)據(jù)庫表的動(dòng)態(tài)配置決定在抽獎(jiǎng)前完成后，后續(xù)的流程要如何進(jìn)行。

11. 抽獎(jiǎng)也是一種瞬時(shí)峰值很高的業(yè)務(wù)場景，那么對(duì)于抽中獎(jiǎng)品后的庫存扣減是怎么做的？

關(guān)于庫存的扣減，是一個(gè)非常重要的流程。尤其是這種單獨(dú)資源競爭的場景，如果設(shè)計(jì)的不好，很容易把服務(wù)打掛。

所以在這套系統(tǒng)設(shè)計(jì)中，為了避免庫存扣減直接更新庫表的行級(jí)鎖，而導(dǎo)致大量的用戶進(jìn)行等待狀態(tài)。所以把數(shù)據(jù)庫表的庫存同步到 Redis 緩存中，在通過 incr 扣減的方式進(jìn)行消費(fèi)，同時(shí)為了確保在臨界狀態(tài)、庫存恢復(fù)、異常處理等情況下不超賣，而對(duì)每一條產(chǎn)生從 incr 值，與抽獎(jiǎng)的策略ID組合一個(gè)key，進(jìn)行 setnx 加鎖兜底，來保證不超賣?！?這樣的設(shè)計(jì)是顆粒度更小的鎖方案設(shè)計(jì)，性能接近于無鎖化。

12. 你講到庫存的扣減是通過 Redis 滑塊鎖實(shí)現(xiàn)的，那么最終同步庫是怎么做的，怎么降低對(duì)數(shù)據(jù)庫的壓力的？

關(guān)于 redis 緩存和數(shù)據(jù)庫表庫存數(shù)據(jù)的流程，設(shè)計(jì)了異步更新，保持最終一致性的設(shè)計(jì)。在執(zhí)行完庫存的扣減操作后（在抽獎(jiǎng)中規(guī)則樹庫存節(jié)點(diǎn)流程），發(fā)送一個(gè)扣減完成到 Redis 的異步隊(duì)列（可以使用MQ+延遲消費(fèi)），之后通過定時(shí) Schedule Job 來消費(fèi)隊(duì)列。這樣就可以控制效率速率，降低對(duì)數(shù)據(jù)庫的壓力。（因?yàn)槲覀儾荒?Redis 扣減的多快，就直接打到庫表上，那樣對(duì)數(shù)據(jù)庫的壓力依然很大，容易打掛）

13. 你提到了接口的單一職責(zé)設(shè)計(jì)，這部分具體講解下。

單一職責(zé)原則的核心思想是，一個(gè)類應(yīng)該只有一個(gè)引起它變化的原因。也就是說一個(gè)類應(yīng)該只負(fù)責(zé)一項(xiàng)任務(wù)或功能，如果一個(gè)類承擔(dān)了過多的職責(zé)，那么這個(gè)類就會(huì)變得復(fù)雜，難以維護(hù)和擴(kuò)展。

這樣的原則在一些需要長期使用、迭代、維護(hù)的功能設(shè)計(jì)上，是非常重要的。我們要盡可能的讓大營銷的抽獎(jiǎng)?lì)I(lǐng)域領(lǐng)域模塊具備獨(dú)立性，所以要使用單一職責(zé)原則。在這個(gè)原則約束下，設(shè)計(jì)了3個(gè)接口類；抽獎(jiǎng)策略接口、獎(jiǎng)品信息接口、庫存處理接口（異步扣減等），這樣3個(gè)接口的設(shè)計(jì)，在將來需要擴(kuò)展的時(shí)候，會(huì)非常容易。（可能會(huì)問具體編碼，問的比較多樣性，這部分需要自己閱讀代碼來學(xué)習(xí)）

14. 在項(xiàng)目中你提到了可以支持不同場景的抽獎(jiǎng)訴求，比如；多少積分后可以抽獎(jiǎng)一個(gè)固定范圍的獎(jiǎng)品，或者抽獎(jiǎng)n次后，才可以中獎(jiǎng)某個(gè)獎(jiǎng)品。這部分你是怎么做的？庫表怎么設(shè)計(jì)的？

這塊的流程，就是前面關(guān)于大營銷抽獎(jiǎng)?lì)I(lǐng)域模型的設(shè)計(jì)，從而確定的庫表設(shè)計(jì)。也就是常說的領(lǐng)域->驅(qū)動(dòng)設(shè)計(jì)。

庫表包括；策略表、策略明細(xì)（庫存、概率、規(guī)則key）、獎(jiǎng)品表、規(guī)則表、規(guī)則樹（3個(gè)表）—— 這部分在學(xué)習(xí)項(xiàng)目后，需要具備能在紙上畫出庫表ER圖。

15. 你的抽獎(jiǎng)接口響應(yīng)時(shí)間是多少？

這樣的問題主要考察你是否做了項(xiàng)目的上線，以及了解過接口的響應(yīng)時(shí)間。如果做過就非常好回答，沒做過亂說是挺容易被繼續(xù)提問的。

參考數(shù)據(jù)；2c2g 云服務(wù)器，部署項(xiàng)目（含mysql、redis），占用63%內(nèi)存，抽獎(jiǎng)接口響應(yīng)時(shí)間為38~55毫秒（項(xiàng)目有完整的手把手部署教程，還有監(jiān)控部署教程，可以自己部署驗(yàn)證）。

16.（開放問題）你在做項(xiàng)目中，什么問題難住你的時(shí)間最長，為什么？

這是一個(gè)開放問題，重點(diǎn)考察你對(duì)項(xiàng)目的開發(fā)中個(gè)人的積累。你可以針對(duì)自己的學(xué)習(xí)過程中，有哪個(gè)流程的實(shí)現(xiàn)，讓你最為有感觸，即可回答。

如；可以對(duì)大營銷抽獎(jiǎng)模型流程的設(shè)計(jì)和庫表設(shè)計(jì)，最為耗時(shí)，因?yàn)槟悴粩嗟脑谒伎既绾尾鸾獬鲆粋€(gè)好擴(kuò)展的松耦合結(jié)構(gòu)，同時(shí)拆解后，還要保證搜耦合下的高內(nèi)聚。所以這部分是比較耗時(shí)的。同時(shí)也可以說在設(shè)定某個(gè)方法的，名稱、入?yún)?、出參時(shí)，做了大量的思考。因?yàn)槊值亩x非常影響以后的理解。好的代碼就是文檔，所以對(duì)于這樣的東西花費(fèi)不少時(shí)間。

三、干項(xiàng)目

這就是跟著小傅哥學(xué)習(xí)項(xiàng)目可以獲得的收獲；從需求設(shè)定、框架搭建、領(lǐng)域設(shè)計(jì)、庫表設(shè)計(jì)、功能開發(fā)、項(xiàng)目打包、發(fā)布部署、運(yùn)維監(jiān)控、簡歷編寫、面試解析，這樣一整條線的內(nèi)容，全部交給你！有了這樣一套的組合，那你學(xué)習(xí)完找份工作還不是嘎嘎滴容易！

這樣的項(xiàng)目學(xué)習(xí)在小傅哥星球「碼農(nóng)會(huì)鎖」有8個(gè)，每個(gè)都是從0到1開發(fā)并提供簡歷模板和面試題，并且還在繼續(xù)開發(fā)，后續(xù)還將有更多！價(jià)格嘎嘎實(shí)惠，早點(diǎn)加入，早點(diǎn)提升自己。項(xiàng)目地址：https://gaga.plus