在這個(gè)萬(wàn)物互聯(lián)的時(shí)代,物聯(lián)網(wǎng)業(yè)務(wù)蓬勃發(fā)展,但也瞬息萬(wàn)變,對(duì)于開發(fā)人員來(lái)說(shuō),這是一種挑戰(zhàn),但也是一種“折磨”。
在業(yè)務(wù)發(fā)展初期,因?yàn)闀r(shí)間有限,我們一般會(huì)遵循“小步快跑,迭代試錯(cuò)”的原則進(jìn)行業(yè)務(wù)開發(fā),用通俗的話來(lái)說(shuō)就是“no bb,先上了再說(shuō)”,對(duì)于開發(fā)人員的具體實(shí)現(xiàn),就是“腳本式”的開發(fā)方式,或者說(shuō)是數(shù)據(jù)的 CURD,這樣的開發(fā)方式,在項(xiàng)目早期沒(méi)什么問(wèn)題,但隨著新業(yè)務(wù)的不斷加入,業(yè)務(wù)迭代的頻繁,我們會(huì)發(fā)現(xiàn),現(xiàn)在的業(yè)務(wù)系統(tǒng)變得越來(lái)越冗雜,新加一個(gè)需求或者改一個(gè)業(yè)務(wù),變得無(wú)比困難,因?yàn)闃I(yè)務(wù)實(shí)現(xiàn)彼此之間模糊不清,業(yè)務(wù)規(guī)則在代碼中無(wú)處不在,開發(fā)人員也就無(wú)從下手。
那怎么解決上面的問(wèn)題呢?可能很多人會(huì)說(shuō)“你這代碼不行,重構(gòu)呀”,是的,我們發(fā)現(xiàn)了項(xiàng)目中的“壞代碼”,比如一個(gè)類上千行,一個(gè)方法幾百行,于是我們把一些代碼抽離出來(lái),做一些內(nèi)聚的實(shí)現(xiàn),代碼規(guī)范做一些調(diào)整,但這樣只是解決現(xiàn)在項(xiàng)目代碼中的問(wèn)題,下次項(xiàng)目迭代的時(shí)候,你并不能保證寫的新代碼是符合規(guī)范的,而且最重要的是,重構(gòu)并不能在業(yè)務(wù)代碼上給一個(gè)定義,什么意思呢?比如你重構(gòu)一個(gè)方法,你只能從技術(shù)的角度去重構(gòu)它,并不能從業(yè)務(wù)的角度去重構(gòu),因?yàn)樵谡麄€(gè)業(yè)務(wù)系統(tǒng)“混亂”的情況下,你無(wú)法保證自己的“清白”。另外還有一點(diǎn),即使你重構(gòu)了它,但對(duì)于新加入的開發(fā)人員來(lái)說(shuō),他并不能理解你重構(gòu)的目的,換句話說(shuō),就是如果他要使用或改這個(gè)方法,他完全不知道能不能使用或者使用了會(huì)不會(huì)影響其他業(yè)務(wù),說(shuō)白了就是,業(yè)務(wù)的邊界不明確。
那如何定義業(yè)務(wù)的邊界呢?答案就是運(yùn)用 Eric Evans 提出的領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)(Domain Driven Design,簡(jiǎn)稱 DDD),關(guān)于 DDD 的相關(guān)概念,這邊就不敘述了,網(wǎng)上有很多資料,需要注意的是,DDD 關(guān)注的是業(yè)務(wù)設(shè)計(jì),并非技術(shù)實(shí)現(xiàn)。
物聯(lián)網(wǎng)業(yè)務(wù)如何應(yīng)用領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)?這其實(shí)是個(gè)大命題,該怎么實(shí)現(xiàn)?如何下手呢?我找了我之前做的一個(gè)業(yè)務(wù)需求,來(lái)做示例,看看“腳本式”的實(shí)現(xiàn),和 DDD 的實(shí)現(xiàn),前后有什么不太一樣的地方。
腳本式的開發(fā)
業(yè)務(wù)需求:針對(duì)物聯(lián)網(wǎng)卡的當(dāng)前套餐使用量,根據(jù)一定的規(guī)則,進(jìn)行特定的限速設(shè)置。
需求看起來(lái)很簡(jiǎn)單,下面要具體實(shí)現(xiàn)了,首先,我創(chuàng)建了三張表:
speed_limit:限速表,包含用戶 ID、套餐 ID 等。
speed_limit_config:限速配置表,包含限速檔位,也就是套餐使用量在什么區(qū)間,限速多少的配置。
speed_limit_level:限速級(jí)別表,包含限速的單位和具體值,主要界面選擇使用。
然后再創(chuàng)建對(duì)應(yīng)“貧血”的模型對(duì)象(沒(méi)有任何行為,并且屬性和數(shù)據(jù)庫(kù)字段一一對(duì)應(yīng)):
public class SpeedLimit {
private Long id;
private Integer orgId;
private Long priceOfferId;
//getter setter....
}
public class SpeedLimitConfig {
private Long id;
private Long speedLimitId;
private Double usageStart;
private Double usageEnd;
//getter setter....
}
public class SpeedLimitLevel {
private Long id;
private String unit;
private Double value;
//getter setter....
}
好,數(shù)據(jù)庫(kù)表和模型對(duì)象都創(chuàng)建好了,接下來(lái)做什么呢?CURD 啊,界面需要對(duì)這些數(shù)據(jù)進(jìn)行查看和維護(hù),所以,我創(chuàng)建了:
SpeedLimitMapper.xml:數(shù)據(jù)庫(kù)訪問(wèn) SQL。
SpeedLimitService.java:調(diào)用 Mapper,并返回?cái)?shù)據(jù)。
SpeedLimitController.java:接受前端傳遞參數(shù),并調(diào)用 Service,封裝返回?cái)?shù)據(jù)。
簡(jiǎn)單看下SpeedLimitService.java中的代碼:
public interface SpeedLimitService {
List<SpeedLimit> listAll();
SpeedLimitVO getById(Long id);
Boolean insert(Integer orgId, Long priceOfferId, List<SpeedLimitConfig> speedLimitConfigs);
//...
}
CURD 流程沒(méi)啥問(wèn)題吧,數(shù)據(jù)維護(hù)好了,接下來(lái)要進(jìn)行限速檢查了,我們目前的實(shí)現(xiàn)方式是:有一個(gè)定時(shí)任務(wù),每間隔一段時(shí)間批量執(zhí)行,查詢所有的限速配置(上面的speed_limit),然后根據(jù)用戶 ID 和套餐 ID,查詢出符合條件的物聯(lián)網(wǎng)卡,然后將卡號(hào)丟到 MQ 中異步處理,MQ 接受到卡號(hào),再查詢對(duì)應(yīng)的限速配置(speed_limit以及speed_limit_config),然后再查詢此卡的套餐使用量,最后根據(jù)規(guī)則匹配,進(jìn)行限速設(shè)置等操作。
MQ 中的處理代碼(阿里插件都已經(jīng)提醒我,這個(gè)方法代碼太長(zhǎng)了):
為什么代碼不貼出來(lái)?因?yàn)槔锩娴拇a慘不忍睹啊,if..else..的各種嵌套,所以,還是眼不看為凈。
好,到此為止,這個(gè)需求已經(jīng)“腳本式”的開發(fā)完了,我們來(lái)總結(jié)一把:
條理清晰,開發(fā)效率賊高,完全符合“先上了再說(shuō)”的開發(fā)原則。
數(shù)據(jù)的 CURD 和業(yè)務(wù)邏輯處理隔離開,用到的地方_x001D_“單獨(dú)處理”,似乎沒(méi)啥問(wèn)題。
沒(méi)啥問(wèn)題對(duì)吧?好,現(xiàn)在業(yè)務(wù)迭代來(lái)了,產(chǎn)品經(jīng)理發(fā)話了,說(shuō)除了批量限速檢查,還需要對(duì)單卡的限速同步處理(瞎掰的),因?yàn)槭峭教幚?,所以我沒(méi)辦法發(fā)消息到 MQ 處理,只能對(duì) MQ 中的那一坨代碼進(jìn)行重構(gòu),代碼抽離的過(guò)程中發(fā)現(xiàn),并不能兼容新的需求,怎么搞呢?只能又重載了一個(gè)方法,把里面能抽離的抽離出來(lái),改好之后,需求完美上線。
過(guò)了一天,產(chǎn)品經(jīng)理又發(fā)話了。
然后,我把產(chǎn)品經(jīng)理打死了。
領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)
為了避免我和產(chǎn)品經(jīng)理打架,我需要做一些改變,就事論事,畢竟問(wèn)題出在開發(fā)這邊,面對(duì)“一鍋亂粥”的代碼,我決定用 DDD 這把“武器”進(jìn)行改造它。
我們知道,DDD 分為戰(zhàn)略設(shè)計(jì)和戰(zhàn)術(shù)設(shè)計(jì),戰(zhàn)略設(shè)計(jì)就是把限界上下文和核心領(lǐng)域搞出來(lái),然后針對(duì)某個(gè)限界上下文,再利用戰(zhàn)術(shù)設(shè)計(jì)進(jìn)行具體的實(shí)現(xiàn),這個(gè)過(guò)程一般是針對(duì)一個(gè)完整復(fù)雜的業(yè)務(wù)系統(tǒng),涉及的東西很多,你可能需要和領(lǐng)域?qū)<疫M(jìn)行深入溝通,如有必要還需畫出業(yè)務(wù)領(lǐng)域圖、限界上下文圖、限界上下文映射圖等等,以便理解。
針對(duì)限速設(shè)置的業(yè)務(wù)需求,我簡(jiǎn)單畫了下所涉及的上下文映射圖:
可以看到,我們關(guān)注的只有一個(gè)限速上下文,物聯(lián)網(wǎng)卡上下文、套餐流量上下文和運(yùn)營(yíng)商 API 上下文,我們并不需要關(guān)心,ACL 的意思是防腐層(Anticorruption Layer),它的作用就是隔離各個(gè)上下文,以及協(xié)調(diào)上下文之間的通信。
限速上下文內(nèi)部的實(shí)現(xiàn)(如聚合根和實(shí)體等),其實(shí)就是戰(zhàn)術(shù)設(shè)計(jì)的具體實(shí)現(xiàn),關(guān)于概念這邊就不多說(shuō)了,這里說(shuō)下具體的設(shè)計(jì):
SpeedLimit聚合根:毫無(wú)疑問(wèn),限速上下文的聚合根是限速聚合根,也可以稱之為聚合根實(shí)體,這里的SpeedLimit并不是上面貧血的模型對(duì)象,而是包含限速業(yè)務(wù)邏輯的聚合對(duì)象。
SpeedLimitConfig實(shí)體:限速配置實(shí)體,在生命周期內(nèi)有唯一的標(biāo)識(shí),并且依附于限速聚合根。
SpeedLimitLevel實(shí)體:其實(shí)限速級(jí)別應(yīng)該設(shè)計(jì)成值對(duì)象,因?yàn)樗](méi)有生命周期和唯一標(biāo)識(shí)的概念,只是一個(gè)具體的值。
SpeedLimitContext值對(duì)象:限速上下文,只包含具體的值,作用就是從應(yīng)用層發(fā)起調(diào)用到領(lǐng)域?qū)?,可以看做是傳輸?duì)象。
SpeedLimitService領(lǐng)域服務(wù):因?yàn)樯婕暗蕉鄠€(gè)上下文的協(xié)調(diào)和交互,限速聚合根并不能獨(dú)立完成,所以這些聚合根完成不了的操作,可以放到領(lǐng)域服務(wù)中去處理。
SpeedLimitRepository倉(cāng)儲(chǔ):限速聚合對(duì)象的管理中心,可以數(shù)據(jù)庫(kù)存儲(chǔ),也可以其他方式存儲(chǔ),不要把Mapper接口定義為Repository接口。
以上因?yàn)椴缓迷诂F(xiàn)有項(xiàng)目中做改造,我就用 Spring Boot 做了一個(gè)項(xiàng)目示例(Spring Boot 用起來(lái)真的很爽,簡(jiǎn)潔高效,做微服務(wù)非常好),大致的項(xiàng)目結(jié)構(gòu):
├── src
│ ├── main
│ │ ├── java
│ │ │ └── com
│ │ │ └── qipeng
│ │ │ └── simboss
│ │ │ └── speedlimit
│ │ │ ├── SpeedLimitApplication.java
│ │ │ ├── application
│ │ │ │ ├── dto
│ │ │ │ └── service
│ │ │ │ ├── SpeedLimitApplicationService.java
│ │ │ │ └── impl
│ │ │ │ └── SpeedLimitApplicationServiceImpl.java
│ │ │ ├── domain
│ │ │ │ ├── aggregate
│ │ │ │ │ └── SpeedLimit.java
│ │ │ │ ├── entity
│ │ │ │ │ ├── SpeedLimitConfig.java
│ │ │ │ │ └── SpeedLimitLevel.java
│ │ │ │ ├── service
│ │ │ │ │ ├── SpeedLimitService.java
│ │ │ │ │ └── impl
│ │ │ │ │ └── SpeedLimitServiceImpl.java
│ │ │ │ └── valobj
│ │ │ │ └── SpeedLimitCheckContext.java
│ │ │ ├── facade
│ │ │ │ ├── CarrierApiFacade.java
│ │ │ │ ├── DeviceRatePlanFacade.java
│ │ │ │ ├── IotCardFacade.java
│ │ │ │ └── model
│ │ │ │ ├── CarrierConstants.java
│ │ │ │ ├── DeviceRatePlan.java
│ │ │ │ ├── EnumTemplate.java
│ │ │ │ ├── IotCard.java
│ │ │ │ └── SpeedLimitAction.java
│ │ │ └── repo
│ │ │ ├── dao
│ │ │ │ └── SpeedLimitDao.java
│ │ │ └── repository
│ │ │ └── SpeedLimitRepository.java
│ │ └── resources
│ │ ├── application.yml
│ │ ├── mybatis
│ │ │ ├── mapper
│ │ │ │ └── SpeedLimitMapper.xml
│ │ │ └── mybatis-config.xml
│ └── test
│ └── java
│ └── com
│ └── qipeng
│ └── simboss
│ └── speedlimit
│ ├── SpeedLimitApplicationTests.java
│ ├── application
│ │ └── SpeedLimitApplicationServiceTest.java
│ └── domain
│ └── SpeedLimitServiceTest.java
包路徑:
import com.qipeng.simboss.speedlimit.domain.a(chǎn)ggregate.SpeedLimit;//聚合根import com.qipeng.simboss.speedlimit.domain.entity.*;//實(shí)體import com.qipeng.simboss.speedlimit.domain.valobj.*;//值對(duì)象import com.qipeng.simboss.speedlimit.domain.service.*;//領(lǐng)域服務(wù)import com.qipeng.simboss.speedlimit.domain.repo.repository.*;//倉(cāng)儲(chǔ)import com.qipeng.simboss.speedlimit.repo.dao.*;//mapper接口import com.qipeng.simboss.speedlimit.a(chǎn)pplication.service.*;//應(yīng)用層服務(wù)
好,基本上這個(gè)項(xiàng)目設(shè)計(jì)的差不多了,需要注意的是,上面核心是com.qipeng.simboss.speedlimit.domain包,里面包含了最重要的業(yè)務(wù)邏輯處理,其他都是為此服務(wù)的,另外,在領(lǐng)域模型不斷完善的過(guò)程中,需要持續(xù)對(duì)領(lǐng)域模型進(jìn)行單元測(cè)試,以保證其健壯性,并且,設(shè)計(jì)SpeedLimit聚合根的時(shí)候,不要先考慮數(shù)據(jù)庫(kù)的實(shí)現(xiàn),如果需要數(shù)據(jù)進(jìn)行測(cè)試,可以在SpeedLimitRepository中 Mock 對(duì)應(yīng)的數(shù)據(jù)。
看下SpeedLimit聚合根中的代碼:
package com.qipeng.simboss.speedlimit.domain.a(chǎn)ggregate;
import com.qipeng.simboss.speedlimit.domain.entity.SpeedLimitConfig;import com.qipeng.simboss.speedlimit.facade.model.IotCard;import lombok.Data;import java.util.Date;import java.util.List;
/**
* 限速聚合根
*/@Datapublic class SpeedLimit {
/**
* 限速
*/
private Long id;
/**
* 組織ID
*/
private Integer orgId;
/**
* 套餐ID
*/
private Long priceOfferId;
/**
* 限速配置集合
*/
private List<SpeedLimitConfig> configs;
/**
* 是否刪除當(dāng)前限速,不持久化
*/
private Boolean isDel = false;
/**
* 卡的限速值,不持久化
*/
private Double cardSpeedLimit;
/**
* 獲取限速值
*/
public Double chooseSpeedLimit(Double usageDataVolume, Double totalDataVolume, Long cardPoolId,
Boolean isRealnamePassed, Double currentSpeedLimit) {
//todo this...
}
/**
* 設(shè)置是否刪除當(dāng)前限速
*/
private void setIsDelSpeedLimit(Double currentSpeedLimit) {
//判斷當(dāng)前限速是否存在,如果存在,則刪除現(xiàn)有的限速配置
//todo this...
}
}
上面注釋寫的比較多(方便理解),SpeedLimit聚合根和之前的SpeedLimit貧血對(duì)象相比,主要有以下改動(dòng):
SpeedLimit聚合根并不只是包含getter和setter,還包含了業(yè)務(wù)行為,并且也不和數(shù)據(jù)庫(kù)表一一對(duì)應(yīng)。
SpeedLimit聚合根中包含configs對(duì)象(限速配置集合),因?yàn)橄匏倥渲脤?shí)體依附于SpeedLimit聚合根。
SpeedLimit聚合根中的chooseSpeedLimit方法,意思是根據(jù)某種規(guī)則從限速配置中,選取當(dāng)前要限速的值,這是限速的核心業(yè)務(wù)邏輯。
那為什么不把整個(gè)限速設(shè)置的邏輯寫在SpeedLimit聚合根中?而只是實(shí)現(xiàn)選取要限速的值呢?為什么?為什么?為什么?
答案很簡(jiǎn)單,因?yàn)橄匏僭O(shè)置的整個(gè)邏輯需要涉及到多個(gè)上下文的協(xié)作,SpeedLimit聚合根完全 Hold 不住呀,所以要把這些邏輯寫到限速領(lǐng)域服務(wù)中,還有最重要的是,SpeedLimit聚合根只關(guān)注它邊界內(nèi)的業(yè)務(wù)邏輯,像限速設(shè)置的具體后續(xù)操作,它不需要關(guān)心,那是業(yè)務(wù)流程需要關(guān)心的,也就是限速_x001D_領(lǐng)域服務(wù)需要去協(xié)作的。
好,那我們就看下限速領(lǐng)域服務(wù)的具體實(shí)現(xiàn):
package com.qipeng.simboss.speedlimit.domain.service.impl;
/**
* 限速領(lǐng)域服務(wù)
*/@Servicepublic class SpeedLimitServiceImpl implements SpeedLimitService {
@Autowired
private SpeedLimitRepository speedLimitRepo;
@Autowired
private IotCardFacade iotCardFacade;
@Autowired
private DeviceRatePlanFacade deviceRatePlanFacade;
@Autowired
private CarrierApiFacade carrierApiFacade;
/**
* 批量限速檢查
*/
@Override
public void batchSpeedLimitCheck() {
List<SpeedLimit> speedLimits = speedLimitRepo.listAll();
for (SpeedLimit speedLimit : speedLimits) {
List<IotCard> iotCards = iotCardFacade.listByByOrgId(speedLimit.getOrgId(), speedLimit.getPriceOfferId());
for (IotCard iotCard : iotCards) {
doSpeedLimitCheck(iotCard, speedLimit);
}
}
}
/**
* 單個(gè)限速檢查
*/
@Override
public void doSpeedLimitCheck(SpeedLimitCheckContext context) {
String iccid = context.getIccid();
IotCard iotCard = iotCardFacade.get(iccid);
if (iotCard ?。?null) {
SpeedLimit speedLimit = speedLimitRepo.get(iotCard.getOrgId(), iotCard.getPriceOfferId());
if (speedLimit ?。?null) {
this.doSpeedLimitCheck(iotCard, speedLimit);
}
}
}
/**
* 執(zhí)行限速邏輯
*
* @param iotCard
* @param speedLimit
*/
private void doSpeedLimitCheck(IotCard iotCard, SpeedLimit speedLimit) {
//todo this...
notify(iccid, speedLimit.getCardSpeedLimit());
}
/**
* 修改卡的限速值,并通知用戶
*/
private void notify(String iccid, Double speedLimit) {
if (speedLimit ?。?null) {
//todo this...
System.out.println("update iotCard SpeedLimit to: " + speedLimit);
System.out.println("notify...");
}
}
}
上面的代碼看起來(lái)很多,其實(shí)干的事并不復(fù)雜,主要是業(yè)務(wù)流程:
通過(guò)SpeedLimitCheckContext上下文獲取iccid,然后獲取對(duì)應(yīng)的限速對(duì)象和套餐流量對(duì)象。
通過(guò)限速聚合根獲取需要設(shè)置的限速值(核心業(yè)務(wù))。
調(diào)用相關(guān)接口進(jìn)行添加/刪除限速。
修改卡的限速值,并通知用戶。
以上限速領(lǐng)域模型基本上比較豐富了,后面的業(yè)務(wù)迭代只需要改里面的代碼即可。
好,我們?cè)賮?lái)看下應(yīng)用服務(wù)中的代碼:
package com.qipeng.simboss.speedlimit.a(chǎn)pplication.service.impl;
@Servicepublic class SpeedLimitApplicationServiceImpl implements SpeedLimitApplicationService {
@Autowired
private SpeedLimitService speedLimitService;
@Override
public void batchSpeedLimitCheck() {
speedLimitService.batchSpeedLimitCheck();
}
@Override
public void doSpeedLimitCheck(String iccid) {
SpeedLimitCheckContext context = new SpeedLimitCheckContext();
context.setIccid(iccid);
speedLimitService.doSpeedLimitCheck(context);
}
}
應(yīng)用服務(wù)不應(yīng)包含任何的業(yè)務(wù)邏輯,只是工作流程的處理,比如接受參數(shù),然后調(diào)用相關(guān)服務(wù),封裝返回等,如果需要持久化聚合根對(duì)象,調(diào)用倉(cāng)儲(chǔ)服務(wù)即可(可能會(huì)涉及到 UnitOfWork),另外,像限速聚合根對(duì)象的維護(hù),也是實(shí)現(xiàn)在應(yīng)用服務(wù)(因?yàn)椴话魏螛I(yè)務(wù)邏輯),比如創(chuàng)建限速聚合根,過(guò)程大概是這樣:
應(yīng)用服務(wù)接受參數(shù),然后調(diào)用創(chuàng)建限速聚合根工廠(如SpeedLimitFactory),或者通過(guò)構(gòu)造函數(shù)創(chuàng)建(包含業(yè)務(wù)規(guī)則,不符合則拋出錯(cuò)誤),當(dāng)然創(chuàng)建還包含聚合根附屬的實(shí)體。
限速聚合根創(chuàng)建好了,調(diào)用倉(cāng)儲(chǔ)服務(wù)持久化對(duì)象。
返回操作結(jié)果。
那如何改善之前 MQ 中處理的一坨代碼呢?答案就是一行代碼:
@Testpublic void doSpeedLimitCheckTest() {
System.out.println("start....");
speedLimitApplicationService.doSpeedLimitCheck("1111");
System.out.println("end");
}
沒(méi)錯(cuò),調(diào)用下應(yīng)用層的doSpeedLimitCheck服務(wù)即可,調(diào)用方完全不需要關(guān)心里面的業(yè)務(wù)邏輯,業(yè)務(wù)隔離。
單元測(cè)試執(zhí)行結(jié)果:
結(jié)語(yǔ)
關(guān)于領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)的分層架構(gòu):
其實(shí),我個(gè)人覺得 DDD 的首要核心是確定業(yè)務(wù)的邊界(領(lǐng)域邊界),接著把各個(gè)邊界之間的關(guān)系整理清晰(上下文映射圖),然后再針對(duì)具體的邊界具體設(shè)計(jì)(戰(zhàn)術(shù)設(shè)計(jì)),最后就是工作流程的處理,就像上面圖中所表達(dá)一樣。
好,改造完了,又可以和產(chǎn)品經(jīng)理一起愉快的玩耍了。
作者:岳中新
-
物聯(lián)網(wǎng)
+關(guān)注
關(guān)注
2899文章
43807瀏覽量
369206 -
應(yīng)用軟件
+關(guān)注
關(guān)注
0文章
49瀏覽量
9067
發(fā)布評(píng)論請(qǐng)先 登錄
相關(guān)推薦
評(píng)論