簡(jiǎn)介本資源是一套基于Java技術(shù)棧開(kāi)發(fā)的跨境電商平臺(tái)ECO完整源碼面向Java后端開(kāi)發(fā)者、電商平臺(tái)學(xué)習(xí)者及微服務(wù)架構(gòu)實(shí)踐者旨在提供可運(yùn)行、可擴(kuò)展的企業(yè)級(jí)電商系統(tǒng)參考實(shí)現(xiàn)。壓縮包共444個(gè)文件總大小1.84MB涵蓋346個(gè)Java業(yè)務(wù)邏輯與控制器類(lèi)、57個(gè)XML配置與Mapper映射文件、14個(gè)YML環(huán)境配置、7個(gè)Dockerfile支持多環(huán)境容器化部署、以及SQL建表腳本、Maven構(gòu)建腳本和基礎(chǔ)前端靜態(tài)資源等體現(xiàn)典型Spring Boot MyBatis Docker的現(xiàn)代電商技術(shù)組合。已有208人學(xué)習(xí)下載讀者可直接導(dǎo)入IDE運(yùn)行調(diào)試深入理解用戶(hù)中心、商品管理、訂單流程、國(guó)際支付對(duì)接、多語(yǔ)言適配等核心模塊的設(shè)計(jì)與集成方式并借鑒其分層架構(gòu)、RESTful接口規(guī)范及CI/CD初步實(shí)踐。1. 項(xiàng)目緣起為什么選擇Java重寫(xiě)一個(gè)跨境電商平臺(tái)幾年前我接手了一個(gè)用PHP和Node.js混合技術(shù)棧搭建的跨境電商項(xiàng)目。項(xiàng)目初期為了快速上線技術(shù)選型比較隨意隨著業(yè)務(wù)量從日均幾百單增長(zhǎng)到幾萬(wàn)單各種問(wèn)題開(kāi)始集中爆發(fā)訂單處理延遲、庫(kù)存同步錯(cuò)亂、支付回調(diào)丟失、系統(tǒng)在高并發(fā)下頻繁宕機(jī)。更頭疼的是由于早期架構(gòu)設(shè)計(jì)缺乏規(guī)劃代碼耦合嚴(yán)重加一個(gè)促銷(xiāo)活動(dòng)功能可能得改五六個(gè)服務(wù)牽一發(fā)而動(dòng)全身。那段時(shí)間團(tuán)隊(duì)大部分精力都耗在了“救火”和“打補(bǔ)丁”上新業(yè)務(wù)需求根本排不上期。痛定思痛我們決定推倒重來(lái)啟動(dòng)一個(gè)代號(hào)為“ECO”的新平臺(tái)項(xiàng)目。這次我們選擇了Java作為核心開(kāi)發(fā)語(yǔ)言。很多人可能會(huì)問(wèn)現(xiàn)在Go、Python、Node.js不都很火嗎為什么還要用“老牌”的Java這背后是我們基于業(yè)務(wù)特性做的深度權(quán)衡。首先跨境電商的核心是“交易”而交易系統(tǒng)對(duì)一致性、穩(wěn)定性和事務(wù)處理能力的要求是極高的。Java生態(tài)中成熟的ORM框架如MyBatis、JPA和聲明式事務(wù)管理Spring的Transactional能讓我們以相對(duì)低的認(rèn)知成本構(gòu)建出強(qiáng)一致性的業(yè)務(wù)邏輯。其次跨境電商涉及復(fù)雜的供應(yīng)鏈、清關(guān)、多幣種支付、多語(yǔ)言客服等模塊系統(tǒng)本身就是由數(shù)十個(gè)微服務(wù)構(gòu)成的龐大體系。Spring Cloud Alibaba這一套成熟的微服務(wù)全家桶在服務(wù)治理、配置管理、流量控制等方面提供了開(kāi)箱即用的解決方案能極大降低分布式系統(tǒng)的復(fù)雜度。最后團(tuán)隊(duì)成員的技能棧也是重要考量我們有一批經(jīng)驗(yàn)豐富的Java工程師選擇Java能最大化利用現(xiàn)有的人力資源快速推進(jìn)項(xiàng)目。所以ECO項(xiàng)目不是一個(gè)簡(jiǎn)單的Demo它是一個(gè)基于真實(shí)業(yè)務(wù)痛點(diǎn)用Java技術(shù)棧重構(gòu)的、面向高并發(fā)與復(fù)雜業(yè)務(wù)的跨境電商平臺(tái)解決方案。今天我就把這個(gè)項(xiàng)目的核心架構(gòu)設(shè)計(jì)、關(guān)鍵技術(shù)選型以及我們踩過(guò)的那些“坑”分享出來(lái)希望能給正在規(guī)劃或重構(gòu)類(lèi)似系統(tǒng)的朋友一些參考。2. 核心架構(gòu)設(shè)計(jì)如何用微服務(wù)支撐全球電商業(yè)務(wù)一個(gè)健康的電商平臺(tái)架構(gòu)就像人的骨骼系統(tǒng)它決定了平臺(tái)的承載力、靈活性和未來(lái)的成長(zhǎng)空間。ECO平臺(tái)采用了經(jīng)典的前后端分離與微服務(wù)架構(gòu)整體上可以劃分為五層接入層、網(wǎng)關(guān)層、業(yè)務(wù)服務(wù)層、數(shù)據(jù)層和基礎(chǔ)設(shè)施層。2.1 微服務(wù)拆分與領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)DDD微服務(wù)不是拆得越細(xì)越好胡亂拆分只會(huì)帶來(lái)災(zāi)難性的分布式事務(wù)和運(yùn)維復(fù)雜度。我們借鑒了領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)DDD的思想來(lái)指導(dǎo)服務(wù)邊界劃分。DDD的核心是圍繞業(yè)務(wù)領(lǐng)域而非技術(shù)層面進(jìn)行建模。我們組織了多次“事件風(fēng)暴”工作坊邀請(qǐng)產(chǎn)品、運(yùn)營(yíng)、業(yè)務(wù)專(zhuān)家和開(kāi)發(fā)一起通過(guò)梳理“用戶(hù)下單”這個(gè)核心業(yè)務(wù)流程識(shí)別出了多個(gè)限界上下文。例如“訂單”是一個(gè)核心領(lǐng)域。用戶(hù)創(chuàng)建訂單時(shí)需要檢查庫(kù)存庫(kù)存上下文、計(jì)算優(yōu)惠促銷(xiāo)上下文、生成支付單支付上下文。如果把這些邏輯都塞進(jìn)一個(gè)“訂單服務(wù)”它很快就會(huì)變得臃腫不堪。因此我們拆分了用戶(hù)中心服務(wù)負(fù)責(zé)會(huì)員、收貨地址、安全認(rèn)證。商品服務(wù)負(fù)責(zé)商品、類(lèi)目、品牌、庫(kù)存的管理。這里特別注意庫(kù)存管理本身又分為可售庫(kù)存、實(shí)際庫(kù)存、在途庫(kù)存等是一個(gè)復(fù)雜的子域。訂單服務(wù)負(fù)責(zé)訂單生命周期的核心流轉(zhuǎn)如創(chuàng)建、狀態(tài)變更、履約。它不直接操作庫(kù)存而是通過(guò)發(fā)布“訂單已創(chuàng)建”領(lǐng)域事件由庫(kù)存服務(wù)來(lái)異步扣減。購(gòu)物車(chē)服務(wù)一個(gè)輕量的、有時(shí)效性的服務(wù)與訂單服務(wù)解耦。促銷(xiāo)服務(wù)管理優(yōu)惠券、滿(mǎn)減、折扣等活動(dòng)提供統(tǒng)一的優(yōu)惠計(jì)算引擎。支付服務(wù)對(duì)接多個(gè)第三方支付網(wǎng)關(guān)支付寶、微信、PayPal、Stripe處理支付、退款、對(duì)賬。清關(guān)服務(wù)這是跨境電商特有的負(fù)責(zé)組裝報(bào)關(guān)單、與海關(guān)系統(tǒng)對(duì)接。物流服務(wù)對(duì)接多家物流商API實(shí)現(xiàn)運(yùn)單追蹤。每個(gè)服務(wù)對(duì)應(yīng)一個(gè)獨(dú)立的Git倉(cāng)庫(kù)有自己獨(dú)立的數(shù)據(jù)庫(kù)遵循數(shù)據(jù)庫(kù)私有原則通過(guò)API或領(lǐng)域事件進(jìn)行通信。這樣當(dāng)促銷(xiāo)規(guī)則需要頻繁變動(dòng)時(shí)我們只需要修改和部署促銷(xiāo)服務(wù)不會(huì)影響到穩(wěn)定的訂單服務(wù)。2.2 技術(shù)棧選型與Spring Cloud生態(tài)確定了服務(wù)邊界接下來(lái)就是技術(shù)選型。我們以Spring Boot作為每個(gè)微服務(wù)的開(kāi)發(fā)框架它約定大于配置的理念能讓我們快速搭建一個(gè)可獨(dú)立運(yùn)行的服務(wù)。微服務(wù)治理方面我們選擇了Spring Cloud Alibaba原因在于它功能齊全、中文文檔豐富并且在國(guó)內(nèi)經(jīng)過(guò)大量實(shí)踐驗(yàn)證。服務(wù)注冊(cè)與發(fā)現(xiàn)Nacos。對(duì)比Eureka和ConsulNacos不僅提供了服務(wù)注冊(cè)發(fā)現(xiàn)還集成了配置中心功能一舉兩得。它的控制臺(tái)UI友好服務(wù)健康狀態(tài)一目了然。配置中心Nacos Config。將所有服務(wù)的配置數(shù)據(jù)庫(kù)連接、Redis地址、開(kāi)關(guān)配置等集中管理。在Nacos控制臺(tái)修改一個(gè)配置項(xiàng)相關(guān)服務(wù)能近乎實(shí)時(shí)地感知并刷新無(wú)需重啟。這對(duì)線上問(wèn)題排查和功能灰度發(fā)布至關(guān)重要。網(wǎng)關(guān)Spring Cloud Gateway。作為所有流量入口它負(fù)責(zé)路由轉(zhuǎn)發(fā)、權(quán)限校驗(yàn)、限流熔斷、日志記錄。我們編寫(xiě)了全局過(guò)濾器用來(lái)驗(yàn)證JWT令牌、將用戶(hù)信息放入請(qǐng)求頭傳遞給下游服務(wù)。熔斷與降級(jí)Sentinel。在“雙十一”大促期間如果支付服務(wù)響應(yīng)緩慢大量訂單請(qǐng)求堆積會(huì)拖垮整個(gè)系統(tǒng)。Sentinel可以實(shí)時(shí)監(jiān)控服務(wù)間的調(diào)用當(dāng)失敗率達(dá)到閾值或響應(yīng)時(shí)間過(guò)長(zhǎng)時(shí)自動(dòng)進(jìn)行熔斷快速失敗并返回一個(gè)友好的降級(jí)結(jié)果如“系統(tǒng)繁忙請(qǐng)稍后再試”保護(hù)系統(tǒng)不被雪崩。分布式事務(wù)Seata。這是微服務(wù)架構(gòu)下最棘手的問(wèn)題之一。比如“下單扣庫(kù)存”這個(gè)操作就涉及訂單服務(wù)和庫(kù)存服務(wù)。我們采用了Seata的AT模式。它的原理是攔截業(yè)務(wù)SQL生成前后鏡像保存到undo_log表中。在全局事務(wù)提交時(shí)各個(gè)分支事務(wù)正常提交如果需要回滾Seata會(huì)根據(jù)undo_log中的前后鏡像數(shù)據(jù)生成反向SQL進(jìn)行補(bǔ)償。對(duì)于大部分業(yè)務(wù)場(chǎng)景這已經(jīng)足夠。但對(duì)于極致性能要求的場(chǎng)景我們也會(huì)結(jié)合使用本地消息表、最終一致性方案。注意Seata的AT模式對(duì)數(shù)據(jù)庫(kù)支持有要求并且會(huì)帶來(lái)一定的性能損耗。在選型時(shí)一定要根據(jù)業(yè)務(wù)對(duì)一致性的要求級(jí)別強(qiáng)一致、最終一致來(lái)權(quán)衡。我們內(nèi)部有一條原則能用異步和最終一致性解決的就不用分布式事務(wù)。2.3 數(shù)據(jù)一致性設(shè)計(jì)從CAP理論到實(shí)踐在分布式系統(tǒng)中數(shù)據(jù)一致性是靈魂。我們根據(jù)業(yè)務(wù)場(chǎng)景采用了混合策略強(qiáng)一致性場(chǎng)景核心交易鏈路如創(chuàng)建訂單時(shí)扣減庫(kù)存。我們使用Seata的AT模式來(lái)保證。雖然性能有損耗但保證了資金的絕對(duì)正確這個(gè)代價(jià)是值得的。最終一致性場(chǎng)景大部分場(chǎng)景如訂單支付成功后發(fā)送短信通知、更新用戶(hù)積分、同步數(shù)據(jù)到數(shù)據(jù)分析平臺(tái)。我們使用RocketMQ作為消息中間件。訂單服務(wù)在本地事務(wù)提交后發(fā)送一條“訂單已支付”消息到RocketMQ。積分服務(wù)、短信服務(wù)作為消費(fèi)者訂閱該消息各自處理。即使某個(gè)消費(fèi)者暫時(shí)失敗消息也會(huì)在Broker中重試直到成功從而保證數(shù)據(jù)最終一致。讀寫(xiě)分離與數(shù)據(jù)同步對(duì)于商品詳情、用戶(hù)查詢(xún)這類(lèi)讀多寫(xiě)少的場(chǎng)景我們使用主從數(shù)據(jù)庫(kù)寫(xiě)操作走主庫(kù)讀操作走從庫(kù)用Canal監(jiān)聽(tīng)主庫(kù)的binlog近乎實(shí)時(shí)地同步數(shù)據(jù)到Elasticsearch提供復(fù)雜的商品搜索和篩選功能。這套混合架構(gòu)讓我們?cè)诒ＷC核心交易穩(wěn)定的前提下兼顧了系統(tǒng)的吞吐量和擴(kuò)展性。3. 核心業(yè)務(wù)模塊實(shí)現(xiàn)深度解析有了穩(wěn)固的架構(gòu)我們來(lái)深入幾個(gè)最具挑戰(zhàn)的業(yè)務(wù)模塊看看代碼是如何落地的。3.1 商品與庫(kù)存服務(wù)如何應(yīng)對(duì)高并發(fā)秒殺商品服務(wù)看似簡(jiǎn)單但庫(kù)存管理是電商的“命門(mén)”。我們?cè)O(shè)計(jì)了多層庫(kù)存模型可售庫(kù)存前臺(tái)用戶(hù)可見(jiàn)、可購(gòu)買(mǎi)的數(shù)量。鎖定庫(kù)存用戶(hù)下單后從可售庫(kù)存中扣除放入鎖定庫(kù)存防止超賣(mài)。實(shí)際庫(kù)存?zhèn)}庫(kù)中的物理庫(kù)存。當(dāng)用戶(hù)下單時(shí)扣減庫(kù)存的偽代碼邏輯如下Service public class InventoryServiceImpl implements InventoryService { Autowired private RedisTemplateString, String redisTemplate; Autowired private InventoryMapper inventoryMapper; Transactional(rollbackFor Exception.class) Override public boolean reduceStock(Long skuId, Integer quantity) { // 1. 校驗(yàn)參數(shù) if (skuId null || quantity 0) { throw new BizException(參數(shù)錯(cuò)誤); } // 2. Redis預(yù)減庫(kù)存應(yīng)對(duì)超高并發(fā) String key stock:cache: skuId; Long result redisTemplate.opsForValue().decrement(key, quantity); if (result ! null result 0) { // 庫(kù)存不足回滾Redis redisTemplate.opsForValue().increment(key, quantity); throw new BizException(庫(kù)存不足); } // 3. 數(shù)據(jù)庫(kù)扣減保證最終正確性 int updatedRows inventoryMapper.reduceActualStock(skuId, quantity); if (updatedRows 0) { // 數(shù)據(jù)庫(kù)扣減失敗回滾Redis redisTemplate.opsForValue().increment(key, quantity); throw new BizException(庫(kù)存扣減失敗請(qǐng)重試); } // 4. 異步更新其他庫(kù)存數(shù)據(jù)如鎖定庫(kù)存 // 發(fā)送MQ消息... return true; } }關(guān)鍵點(diǎn)解析Redis預(yù)減這是應(yīng)對(duì)秒殺的核心。所有請(qǐng)求先走Redis利用其單線程和內(nèi)存操作的特性快速判斷庫(kù)存是否充足將絕大部分無(wú)效請(qǐng)求攔截在數(shù)據(jù)庫(kù)之外。Redis中的庫(kù)存數(shù)可以略少于實(shí)際庫(kù)存作為緩沖。數(shù)據(jù)庫(kù)兜底R(shí)edis可能會(huì)因?yàn)榫W(wǎng)絡(luò)分區(qū)、重啟等原因丟失數(shù)據(jù)因此數(shù)據(jù)庫(kù)是庫(kù)存數(shù)據(jù)的最終權(quán)威存儲(chǔ)。任何Redis操作都要有對(duì)應(yīng)的數(shù)據(jù)庫(kù)操作和補(bǔ)償機(jī)制。異步化扣減實(shí)際庫(kù)存后更新鎖定庫(kù)存等操作可以通過(guò)消息隊(duì)列異步進(jìn)行避免長(zhǎng)事務(wù)提升響應(yīng)速度。我們?cè)谶@個(gè)環(huán)節(jié)踩過(guò)一個(gè)大坑早期我們只用了Redis做庫(kù)存扣減在一次Redis集群主從切換導(dǎo)致數(shù)據(jù)短暫不一致時(shí)發(fā)生了少量超賣(mài)。教訓(xùn)就是緩存只能用于加速和緩沖不能作為唯一可信數(shù)據(jù)源。3.2 訂單服務(wù)狀態(tài)機(jī)與分布式ID生成訂單的狀態(tài)流轉(zhuǎn)非常復(fù)雜從“待付款”、“已付款”、“待發(fā)貨”、“已發(fā)貨”到“已完成”或“已取消”中間還可能穿插“退款中”等狀態(tài)。如果用簡(jiǎn)單的if-else來(lái)控制狀態(tài)變更代碼會(huì)很快變成一團(tuán)亂麻。我們引入了狀態(tài)模式并配合使用Spring StateMachine框架。我們將訂單狀態(tài)和可能觸發(fā)狀態(tài)變更的事件如“用戶(hù)支付”、“商家發(fā)貨”定義出來(lái)在配置文件中清晰地描述狀態(tài)轉(zhuǎn)換規(guī)則Configuration EnableStateMachine(name orderStateMachine) public class OrderStateMachineConfig extends EnumStateMachineConfigurerAdapterOrderStatus, OrderEvent { Override public void configure(StateMachineStateConfigurerOrderStatus, OrderEvent states) throws Exception { states .withStates() .initial(OrderStatus.PENDING_PAYMENT) .states(EnumSet.allOf(OrderStatus.class)); } Override public void configure(StateMachineTransitionConfigurerOrderStatus, OrderEvent transitions) throws Exception { transitions .withExternal() .source(OrderStatus.PENDING_PAYMENT).target(OrderStatus.PAID) .event(OrderEvent.PAY_SUCCESS) .and() .withExternal() .source(OrderStatus.PAID).target(OrderStatus.TO_BE_SHIPPED) .event(OrderEvent.MERCHANT_CONFIRM) .and() // ... 更多轉(zhuǎn)換規(guī)則 } }這樣業(yè)務(wù)代碼里只需要stateMachine.sendEvent(OrderEvent.PAY_SUCCESS)狀態(tài)機(jī)就會(huì)自動(dòng)根據(jù)當(dāng)前狀態(tài)和事件判斷能否轉(zhuǎn)換并執(zhí)行相應(yīng)的動(dòng)作如支付成功后觸發(fā)發(fā)送短信的動(dòng)作監(jiān)聽(tīng)器。代碼清晰且不易出現(xiàn)非法狀態(tài)流轉(zhuǎn)。另一個(gè)關(guān)鍵點(diǎn)是訂單號(hào)生成。單調(diào)遞增的數(shù)據(jù)庫(kù)自增ID會(huì)暴露業(yè)務(wù)量也不適合分庫(kù)分表。我們采用了Snowflake雪花算法的變體來(lái)生成全局唯一的訂單號(hào)。算法生成的ID是64位的Long型數(shù)字包含時(shí)間戳、工作機(jī)器ID、序列號(hào)等信息趨勢(shì)遞增、高性能、無(wú)需中心化協(xié)調(diào)。我們對(duì)其做了小幅改造將一部分位用于表示業(yè)務(wù)類(lèi)型如普通訂單、秒殺訂單方便日后根據(jù)訂單號(hào)快速路由。3.3 支付與清關(guān)處理跨境業(yè)務(wù)復(fù)雜性支付是資金入口必須穩(wěn)如磐石。我們抽象了一個(gè)統(tǒng)一的支付網(wǎng)關(guān)服務(wù)內(nèi)部定義了PaymentStrategy策略接口針對(duì)支付寶、微信、PayPal等不同支付渠道實(shí)現(xiàn)不同的策略類(lèi)。這樣當(dāng)需要接入一個(gè)新的支付方式時(shí)只需要新增一個(gè)策略實(shí)現(xiàn)即可對(duì)主流程代碼無(wú)侵入。支付回調(diào)處理是重中之重必須做到冪等。第三方支付平臺(tái)可能會(huì)因?yàn)榫W(wǎng)絡(luò)問(wèn)題多次發(fā)送相同的回調(diào)通知。我們的處理邏輯是回調(diào)接口首先根據(jù)第三方支付單號(hào)查詢(xún)本地是否已處理過(guò)該筆回調(diào)。如果已處理并成功直接返回“success”。如果未處理則在一個(gè)分布式鎖的保護(hù)下進(jìn)行訂單狀態(tài)更新、記賬等操作。處理完成后將第三方支付單號(hào)和處理結(jié)果記錄到“支付回調(diào)日志表”。無(wú)論成功失敗都記錄日志并做好監(jiān)控告警。對(duì)于跨境電商清關(guān)是另一個(gè)復(fù)雜環(huán)節(jié)。不同國(guó)家、不同品類(lèi)的商品申報(bào)要求、稅率都不同。我們?cè)O(shè)計(jì)了一個(gè)可配置的“清關(guān)模板”系統(tǒng)。商品上架時(shí)運(yùn)營(yíng)人員需要填寫(xiě)HS編碼、原產(chǎn)地、申報(bào)要素等。當(dāng)訂單生成后清關(guān)服務(wù)會(huì)根據(jù)收貨地址國(guó)家、商品信息自動(dòng)匹配模板組裝成符合海關(guān)要求的報(bào)文格式通過(guò)第三方清關(guān)代理系統(tǒng)進(jìn)行申報(bào)。這個(gè)過(guò)程也是異步的通過(guò)消息隊(duì)列驅(qū)動(dòng)避免阻塞主訂單流程。4. 性能優(yōu)化與穩(wěn)定性保障實(shí)戰(zhàn)系統(tǒng)能跑起來(lái)只是第一步能在大流量下穩(wěn)定運(yùn)行才是真本事。我們?cè)谶@方面投入了巨大的精力。4.1 緩存策略與數(shù)據(jù)庫(kù)優(yōu)化緩存是提升性能的銀彈但用不好就是炸彈。我們制定了多級(jí)緩存策略一級(jí)緩存本地緩存使用Caffeine或Guava Cache緩存一些極少變更的數(shù)據(jù)如國(guó)家地區(qū)編碼、貨幣匯率短期。設(shè)置合理的過(guò)期時(shí)間如5分鐘和最大容量防止內(nèi)存溢出。二級(jí)緩存分布式緩存使用Redis集群緩存熱點(diǎn)數(shù)據(jù)如商品詳情頁(yè)信息、用戶(hù)會(huì)話、購(gòu)物車(chē)數(shù)據(jù)。這里的關(guān)鍵是緩存鍵的設(shè)計(jì)和過(guò)期策略。例如商品詳情緩存的Key可以設(shè)計(jì)為product:detail:{skuId}:{lang}包含語(yǔ)言維度。我們大量使用Hash結(jié)構(gòu)來(lái)存儲(chǔ)對(duì)象減少網(wǎng)絡(luò)傳輸?shù)男ey數(shù)量。緩存穿透、擊穿、雪崩應(yīng)對(duì)穿透對(duì)于不存在的商品ID查詢(xún)將空值null也緩存一小段時(shí)間如30秒避免惡意請(qǐng)求直接打到數(shù)據(jù)庫(kù)。擊穿對(duì)于熱點(diǎn)Key如爆款商品使用Redis的setnx命令實(shí)現(xiàn)分布式互斥鎖。當(dāng)緩存失效時(shí)只有一個(gè)線程能去數(shù)據(jù)庫(kù)加載數(shù)據(jù)其他線程等待或返回舊數(shù)據(jù)。雪崩給緩存Key設(shè)置隨機(jī)的過(guò)期時(shí)間避免大量Key在同一時(shí)刻失效。數(shù)據(jù)庫(kù)層面除了主從讀寫(xiě)分離我們對(duì)單表數(shù)據(jù)量過(guò)大的表如訂單表進(jìn)行了分庫(kù)分表。使用ShardingSphere-JDBC作為中間件按照用戶(hù)ID的哈希值進(jìn)行分片。這里要特別注意涉及分片鍵的查詢(xún)效率很高但非分片鍵的查詢(xún)?nèi)绨从唵螘r(shí)間范圍查詢(xún)就會(huì)很麻煩。我們的做法是建立訂單創(chuàng)建時(shí)間的月度歸檔表或者將這類(lèi)查詢(xún)導(dǎo)向Elasticsearch。4.2 全鏈路監(jiān)控與告警系統(tǒng)復(fù)雜了出問(wèn)題是難免的關(guān)鍵是要能快速發(fā)現(xiàn)、定位、解決。我們搭建了基于Prometheus Grafana Alertmanager的監(jiān)控告警體系。應(yīng)用指標(biāo)每個(gè)Spring Boot服務(wù)都通過(guò)micrometer暴露JVM內(nèi)存、GC、線程池、HTTP請(qǐng)求量、耗時(shí)、錯(cuò)誤率等指標(biāo)給Prometheus。業(yè)務(wù)指標(biāo)我們自定義了業(yè)務(wù)埋點(diǎn)如下單量、支付成功率、庫(kù)存扣減失敗次數(shù)等同樣上報(bào)到Prometheus。鏈路追蹤集成SkyWalking每個(gè)外部請(qǐng)求都會(huì)生成一個(gè)唯一的traceId貫穿經(jīng)過(guò)的所有微服務(wù)。在Grafana上可以清晰地看到一個(gè)請(qǐng)求的完整調(diào)用鏈每個(gè)環(huán)節(jié)的耗時(shí)一目了然。當(dāng)接口變慢時(shí)我們能迅速定位是哪個(gè)服務(wù)、甚至是哪個(gè)數(shù)據(jù)庫(kù)查詢(xún)拖了后腿。日志收集所有服務(wù)的日志統(tǒng)一輸出為JSON格式通過(guò)Filebeat收集發(fā)送到Elasticsearch用Kibana進(jìn)行查看和搜索。通過(guò)traceId可以把一次請(qǐng)求的所有相關(guān)日志串聯(lián)起來(lái)排查問(wèn)題效率倍增。告警規(guī)則我們?cè)O(shè)置得很細(xì)致比如某個(gè)服務(wù)的錯(cuò)誤率在5分鐘內(nèi)持續(xù)高于1%某個(gè)接口的P99響應(yīng)時(shí)間超過(guò)1秒數(shù)據(jù)庫(kù)連接池使用率超過(guò)80%等。告警會(huì)通過(guò)釘釘、短信第一時(shí)間通知到值班人員。4.3 容器化部署與CI/CD為了提升部署效率和資源利用率我們將所有服務(wù)都進(jìn)行了Docker容器化。每個(gè)服務(wù)對(duì)應(yīng)一個(gè)Dockerfile里面定義了運(yùn)行所需的基礎(chǔ)鏡像、JVM參數(shù)、時(shí)區(qū)等。我們利用Jenkins搭建了完整的CI/CD流水線。開(kāi)發(fā)人員提交代碼到Git分支后Jenkins自動(dòng)觸發(fā)代碼質(zhì)量檢查運(yùn)行SonarQube掃描檢查代碼規(guī)范、漏洞和壞味道。單元測(cè)試運(yùn)行項(xiàng)目的單元測(cè)試確保覆蓋率。構(gòu)建鏡像通過(guò)Maven打包然后執(zhí)行docker build生成鏡像并推送到私有的Harbor鏡像倉(cāng)庫(kù)。部署到測(cè)試環(huán)境通過(guò)調(diào)用Kubernetes的API更新測(cè)試環(huán)境的Deployment滾動(dòng)更新服務(wù)。集成測(cè)試自動(dòng)運(yùn)行一組接口測(cè)試用例。人工確認(rèn)后一鍵部署生產(chǎn)。生產(chǎn)環(huán)境我們使用Kubernetes進(jìn)行編排管理。Kubernetes的Deployment保證了服務(wù)的高可用多副本Service提供了內(nèi)部服務(wù)發(fā)現(xiàn)Ingress作為外部流量入口。配合HPA水平Pod自動(dòng)擴(kuò)縮容我們?cè)O(shè)置了基于CPU利用率的自動(dòng)伸縮規(guī)則在大流量來(lái)臨前系統(tǒng)就能自動(dòng)擴(kuò)容實(shí)例流量低谷時(shí)自動(dòng)縮容極大地節(jié)省了服務(wù)器成本。5. 開(kāi)發(fā)與運(yùn)維中的“血淚”經(jīng)驗(yàn)談最后這部分分享一些在ECO項(xiàng)目開(kāi)發(fā)和運(yùn)維過(guò)程中用“學(xué)費(fèi)”換來(lái)的經(jīng)驗(yàn)這些在官方文檔里通常找不到。經(jīng)驗(yàn)一接口設(shè)計(jì)要“笨”一點(diǎn)兼容性要強(qiáng)一點(diǎn)。早期我們?cè)O(shè)計(jì)接口時(shí)追求“優(yōu)雅”經(jīng)常使用枚舉類(lèi)型作為參數(shù)或返回值。后來(lái)發(fā)現(xiàn)當(dāng)需要新增一個(gè)枚舉值時(shí)所有調(diào)用方包括前端、其他服務(wù)都必須同步升級(jí)否則就會(huì)反序列化失敗。后來(lái)我們定下規(guī)矩核心對(duì)外的API盡量使用字符串或整型常量并在文檔中明確其含義。這樣服務(wù)端可以向后兼容地添加新?tīng)顟B(tài)舊的調(diào)用方雖然不認(rèn)識(shí)新值但不會(huì)崩潰。內(nèi)部服務(wù)間通信可以使用Protobuf等強(qiáng)類(lèi)型協(xié)議但也要有版本管理意識(shí)。經(jīng)驗(yàn)二數(shù)據(jù)庫(kù)字段寧寬勿緊。在設(shè)計(jì)商品表時(shí)有個(gè)字段是“商品特性標(biāo)簽”產(chǎn)品經(jīng)理說(shuō)最多就三五個(gè)標(biāo)簽。我們圖省事就定義了一個(gè)varchar(50)。結(jié)果業(yè)務(wù)發(fā)展起來(lái)運(yùn)營(yíng)希望給商品打上幾十個(gè)標(biāo)簽還要支持搜索。改字段類(lèi)型是痛苦的涉及數(shù)據(jù)遷移和停服?，F(xiàn)在的做法是對(duì)于可能擴(kuò)展的、非核心的文本字段直接使用varchar(255)甚至text類(lèi)型。存儲(chǔ)成本在今天已經(jīng)很低但線上修改數(shù)據(jù)結(jié)構(gòu)的風(fēng)險(xiǎn)極高。經(jīng)驗(yàn)三異步消息一定要有補(bǔ)償和監(jiān)控。我們?cè)驗(yàn)橐粋€(gè)促銷(xiāo)活動(dòng)向消息隊(duì)列里狂發(fā)消息導(dǎo)致消費(fèi)者處理不過(guò)來(lái)消息大量堆積。更糟的是有些消息格式錯(cuò)誤消費(fèi)者一直報(bào)錯(cuò)、重試形成死循環(huán)拖垮了整個(gè)隊(duì)列。教訓(xùn)是生產(chǎn)端必須做流量控制不能無(wú)節(jié)制地發(fā)。消費(fèi)端一定要做好冪等和異常處理對(duì)于格式錯(cuò)誤、處理失敗的消息不能無(wú)限重試應(yīng)該轉(zhuǎn)移到死信隊(duì)列并發(fā)出告警讓人工介入處理。必須監(jiān)控消息隊(duì)列的堆積情況設(shè)置堆積告警閾值。經(jīng)驗(yàn)四不要過(guò)度設(shè)計(jì)但要為擴(kuò)展留好“錨點(diǎn)”。微服務(wù)不是萬(wàn)能解藥。在項(xiàng)目初期如果業(yè)務(wù)邊界還不清晰盲目拆分微服務(wù)只會(huì)增加運(yùn)維和聯(lián)調(diào)成本。我們的策略是初期可以做成一個(gè)“單體”但要在代碼層面做好模塊化隔離比如清晰的包結(jié)構(gòu)領(lǐng)域?qū)?、?yīng)用層分離。同時(shí)在可能未來(lái)需要拆分的模塊之間優(yōu)先通過(guò)領(lǐng)域事件或API進(jìn)行通信而不是直接調(diào)用內(nèi)部方法。這樣當(dāng)這個(gè)模塊真的需要獨(dú)立成服務(wù)時(shí)遷移成本會(huì)低很多。這個(gè)通信接口就是預(yù)留的“錨點(diǎn)”。ECO項(xiàng)目從零到一再到穩(wěn)定支撐百萬(wàn)級(jí)用戶(hù)整個(gè)過(guò)程充滿(mǎn)了挑戰(zhàn)。技術(shù)選型沒(méi)有銀彈架構(gòu)設(shè)計(jì)也總是在做權(quán)衡。最重要的是團(tuán)隊(duì)要形成一套適合自己業(yè)務(wù)節(jié)奏和人員能力的方法論在追求技術(shù)先進(jìn)性的同時(shí)更要保證系統(tǒng)的穩(wěn)定和可維護(hù)性。這套源碼和其中蘊(yùn)含的設(shè)計(jì)思想是我們團(tuán)隊(duì)過(guò)去幾年經(jīng)驗(yàn)的結(jié)晶希望能為你帶來(lái)啟發(fā)。如果你在搭建類(lèi)似系統(tǒng)時(shí)遇到具體問(wèn)題歡迎交流探討。本文還有配套的精品資源點(diǎn)擊獲取