java開發(fā)分布式服務(wù)框架Dubbo調(diào)用過(guò)程
大致流程
客戶端根據(jù)遠(yuǎn)程服務(wù)的地址,客戶端發(fā)送請(qǐng)求至服務(wù)端,服務(wù)端解析信息并找到對(duì)應(yīng)的實(shí)現(xiàn)類,進(jìn)行方法調(diào)用,之后將調(diào)用結(jié)果原路返回,客戶端解析響應(yīng)之后再返回。

調(diào)用請(qǐng)求的具體信息
客戶端發(fā)送給服務(wù)端的請(qǐng)求中應(yīng)該包含哪些具體信息呢?
首先肯定要說(shuō)明調(diào)用的是服務(wù)端的哪個(gè)接口、方法名、方法參數(shù)類型、以及版本號(hào)等,將上述信息封裝進(jìn)請(qǐng)求,服務(wù)端就可以根據(jù)請(qǐng)求進(jìn)行方法調(diào)用,之后再組裝響應(yīng)返回即可。

以上就是一個(gè)實(shí)際調(diào)用請(qǐng)求所包含的信息。
協(xié)議
遠(yuǎn)程調(diào)用必不可少協(xié)議的約定,否則客戶端與服務(wù)端無(wú)法解析彼此傳來(lái)的信息,因此需要提前約定好協(xié)議,方便遠(yuǎn)程調(diào)用的信息解析。
Dubbo使用的協(xié)議屬于Header+Body,協(xié)議頭固定長(zhǎng)度,并且頭部中會(huì)填寫B(tài)ody的長(zhǎng)度,因此Body是不固定長(zhǎng)度的,方便拓展,伸縮性較好。
Dubbo協(xié)議

協(xié)議分為協(xié)議頭和協(xié)議體,16字節(jié)的協(xié)議頭主要攜帶了魔法數(shù)、一些請(qǐng)求的設(shè)置,消息體數(shù)據(jù)長(zhǎng)度。
16字節(jié)之后包含的就是協(xié)議體,包含版本信息,接口名稱,接口版本,以及方法名參數(shù)類型等。

序列化器
網(wǎng)絡(luò)是以字節(jié)流傳輸?shù)?,傳輸之前,我們需要將?shù)據(jù)序列化為字節(jié)流然后再傳輸至服務(wù)端,服務(wù)端再反序列化這些字節(jié)流得到原來(lái)的數(shù)據(jù)。
從上圖中可得知,Dubbo支持多種序列化,大致分為兩種,一種是字符型,一種是二進(jìn)制流。
字符型的代表就是JSON,優(yōu)點(diǎn)是易懂,方便調(diào)試,缺點(diǎn)也很明顯,傳輸效率低,對(duì)于計(jì)算機(jī)來(lái)說(shuō)有很多冗余的東西,例如JSON中的括號(hào)等等都會(huì)使得網(wǎng)絡(luò)傳輸時(shí)長(zhǎng)邊長(zhǎng),占用帶寬變大。
二進(jìn)制流類型的數(shù)據(jù)緊湊,占用字節(jié)數(shù)小,傳輸更快,但是調(diào)試?yán)щy。
Dubbo默認(rèn)使用的是Hessian2Serialization,即Hessian2序列化協(xié)議。
調(diào)用流程圖

這個(gè)流程圖比較簡(jiǎn)略,大致就是客戶端發(fā)起調(diào)用,實(shí)際調(diào)用的是代理類,代理類調(diào)用Client(默認(rèn)使用NettyClient),之后構(gòu)造好協(xié)議頭以及將Java對(duì)象序列化生成協(xié)議體,之后進(jìn)行網(wǎng)絡(luò)傳輸。
服務(wù)端的NettyServer接收到請(qǐng)求之后,會(huì)分發(fā)給業(yè)務(wù)線程池,由線程池來(lái)調(diào)用具體的方法。
但這遠(yuǎn)遠(yuǎn)不夠,實(shí)際場(chǎng)景比這復(fù)雜得多,并且Dubbo是生產(chǎn)級(jí)別的,通常會(huì)比上述流程更加安全穩(wěn)定。

在實(shí)際生產(chǎn)環(huán)境中,服務(wù)端往往會(huì)集群分布,多個(gè)服務(wù)端的服務(wù)會(huì)有多個(gè)Invoker,最終需要通過(guò)路由Router過(guò)濾,以及負(fù)載均衡LoadBalance選出一個(gè)Invoker進(jìn)行調(diào)用。
請(qǐng)求會(huì)到達(dá)Netty的IO線程池進(jìn)行序列化,再將請(qǐng)求發(fā)送給服務(wù)端,反序列化后丟入線程池處理,找到對(duì)應(yīng)的Invoker進(jìn)行調(diào)用。
調(diào)用流程源碼分析——客戶端
客戶端調(diào)用方法并發(fā)送請(qǐng)求。
首先會(huì)調(diào)用生成的代理類,而代理類會(huì)生成一個(gè)RpcInvocation對(duì)象調(diào)用MockClusterInvoker.invoke()。
生成的RpcInvocation如下:

進(jìn)入MockClusterInvoker.invoke()看看:
public Result invoke(Invocation invocation) throws RpcException {
Result result = null;
//獲取mock參數(shù)配置
String value = this.directory.getUrl().getMethodParameter(invocation.getMethodName(), "mock", Boolean.FALSE.toString()).trim();
//如果配置了并且配置值為true
if (value.length() != 0 && !value.equalsIgnoreCase("false")) {
//強(qiáng)制走mock流程
if (value.startsWith("force")) {
result = this.doMockInvoke(invocation, (RpcException)null);
} else {
//不走mock流程
try {
result = this.invoker.invoke(invocation);
} catch (RpcException var5) {
....
}
....
result = this.doMockInvoke(invocation, var5);
}
}
} else {
result = this.invoker.invoke(invocation);
}
return result;
}
總的來(lái)說(shuō)就是檢查配置是否配置了mock,如果沒(méi)有就直接進(jìn)入this.invoker.invoke(invocation),實(shí)際上會(huì)調(diào)用到AbstractClusterInvoker.invoke():
public Result invoke(Invocation invocation) throws RpcException {
//檢查是否被銷毀
this.checkWhetherDestroyed();
LoadBalance loadbalance = null;
//從上下文中獲取attachments,如果獲取得到的話綁定到invocation中
Map<String, String> contextAttachments = RpcContext.getContext().getAttachments();
if (contextAttachments != null && contextAttachments.size() != 0) {
((RpcInvocation)invocation).addAttachments(contextAttachments);
}
//調(diào)用的是directory.list,其中會(huì)做路由過(guò)濾
List<Invoker<T>> invokers = this.list(invocation);
//如果過(guò)濾完之后還有Invoker,就通過(guò)SPI獲取對(duì)應(yīng)的LoadBalance實(shí)現(xiàn)類
if (invokers != null && !invokers.isEmpty()) {
loadbalance = (LoadBalance)ExtensionLoader.getExtensionLoader(LoadBalance.class).getExtension(((Invoker)invokers.get(0)).getUrl().getMethodParameter(RpcUtils.getMethodName(invocation), "loadbalance", "random"));
}
RpcUtils.attachInvocationIdIfAsync(this.getUrl(), invocation);
return this.doInvoke(invocation, invokers, loadbalance); //調(diào)用子類方法
}
protected List<Invoker<T>> list(Invocation invocation) throws RpcException {
//獲取invokers目錄,實(shí)際調(diào)用的是AbstractDirectory.list()
List<Invoker<T>> invokers = this.directory.list(invocation);
return invokers;
}
模板方法模式
這是很常見的設(shè)計(jì)模式之一,就是再抽象類中定好代碼的整體架構(gòu),然后將具體的實(shí)現(xiàn)留到子類中,由子類自定義實(shí)現(xiàn),由此可以再不改變整體執(zhí)行步驟的情況下,實(shí)現(xiàn)多樣化的實(shí)現(xiàn),減少代碼重復(fù),利于擴(kuò)展,符合開閉原則。
在上述代碼中this.doInvoke()是抽象方法,具體實(shí)現(xiàn)在FailoverClusterInvoker.doInvoke()中,上述所有步驟是每個(gè)子類都需要執(zhí)行的,所以抽取出來(lái)放在抽象類中。
路由和負(fù)載均衡
上述this.directory.list(invocation),其實(shí)就是通過(guò)方法名找到對(duì)應(yīng)的Invoker,然后由路由進(jìn)行過(guò)濾。
public List<Invoker<T>> list(Invocation invocation) throws RpcException {
if (this.destroyed) {
throw new RpcException("Directory already destroyed .url: " + this.getUrl());
} else {
//抽象方法doList,同樣由子類實(shí)現(xiàn)
List<Invoker<T>> invokers = this.doList(invocation);
List<Router> localRouters = this.routers;
if (localRouters != null && !localRouters.isEmpty()) {
Iterator i$ = localRouters.iterator();
while(i$.hasNext()) {
Router router = (Router)i$.next();
try { //遍歷router,并判斷是否進(jìn)行路由過(guò)濾
if (router.getUrl() == null || router.getUrl().getParameter("runtime", false)) {
invokers = router.route(invokers, this.getConsumerUrl(), invocation);
}
} catch (Throwable var7) {
logger.error("Failed to execute router: " + this.getUrl() + ", cause: " + var7.getMessage(), var7);
}
}
}
return invokers;
}
}
返回Invokers之后,還會(huì)在進(jìn)行負(fù)載均衡的篩選,得到最終調(diào)用的Invoke,Dubbo默認(rèn)使用的是FailoverClusterInvoker,即失敗調(diào)用后自動(dòng)切換的容錯(cuò)方式。
進(jìn)入FailoverClusterInvoker.doInvoke():
public Result doInvoke(Invocation invocation, List<Invoker<T>> invokers, LoadBalance loadbalance) throws RpcException {
//重試次數(shù)
int len = this.getUrl().getMethodParameter(invocation.getMethodName(), "retries", 2) + 1;
if (len <= 0) {
len = 1;
}
....
//重試
for(int i = 0; i < len; ++i) {
//負(fù)載均衡篩選出一個(gè)Invoker
Invoker<T> invoker = this.select(loadbalance, invocation, copyinvokers, invoked);
invoked.add(invoker);
//在上下文中保存調(diào)用過(guò)的invoker
RpcContext.getContext().setInvokers(invoked);
try {
Result result = invoker.invoke(invocation);
....
return result;
} catch (RpcException e) {
....
} finally {
providers.add(invoker.getUrl().getAddress());
}
}
throw new RpcException();
}
發(fā)起這次調(diào)用的invoker.invoke又是調(diào)用抽象類的中的invoke,然后再調(diào)用子類的doInvoke,我們直接進(jìn)入子類DubboInvoker.doInvoke看看:
protected Result doInvoke(Invocation invocation) throws Throwable {
RpcInvocation inv = (RpcInvocation)invocation;
String methodName = RpcUtils.getMethodName(invocation);
inv.setAttachment("path", this.getUrl().getPath()); //設(shè)置path到attachment中
inv.setAttachment("version", this.version); //設(shè)置版本號(hào)
ExchangeClient currentClient;
if (this.clients.length == 1) { //選擇client
currentClient = this.clients[0];
} else {
currentClient = this.clients[this.index.getAndIncrement() % this.clients.length];
}
try {
boolean isAsync = RpcUtils.isAsync(this.getUrl(), invocation); //是否異步調(diào)用
boolean isOneway = RpcUtils.isOneway(this.getUrl(), invocation); //是否oneway調(diào)用
int timeout = this.getUrl().getMethodParameter(methodName, "timeout", 1000); //獲取超時(shí)限制
if (isOneway) { //oneway
boolean isSent = this.getUrl().getMethodParameter(methodName, "sent", false);
currentClient.send(inv, isSent); //發(fā)送
RpcContext.getContext().setFuture((Future)null); //返回空的future
return new RpcResult(); //返回空結(jié)果
} else if (isAsync) { //異步調(diào)用
ResponseFuture future = currentClient.request(inv, timeout);
RpcContext.getContext().setFuture(new FutureAdapter(future)); //上下文中設(shè)置future
return new RpcResult(); //返回空結(jié)果
} else { //同步調(diào)用
RpcContext.getContext().setFuture((Future)null);
return (Result)currentClient.request(inv, timeout).get(); //直接調(diào)用future.get() 進(jìn)行等待,完成get操作之后再返回結(jié)果
}
} catch (TimeoutException var9) {
throw new RpcException();
}
}
調(diào)用的三種方式
從上述代碼中,可以看到調(diào)用一共分為三種,分別是oneway,異步,同步。
- oneway:不需要關(guān)心請(qǐng)求是否發(fā)送成功的情況下,直接使用oneway,無(wú)需關(guān)心是否能完成發(fā)送并返回結(jié)果。
- 異步調(diào)用:client發(fā)送請(qǐng)求之后會(huì)得到一個(gè)ResponseFuture,然后將這個(gè)future塞入上下文中,讓用戶從上下文拿到這個(gè)future,用戶可以繼續(xù)執(zhí)行操作在調(diào)用future.get()返回結(jié)果。
- 同步調(diào)用:從Dubbo源碼中,我們可以看到,先使用了future.get(),讓用戶進(jìn)行等待之后,再用client發(fā)送請(qǐng)求,給用戶的感覺就是調(diào)用接口后要進(jìn)行等待才能返回結(jié)果,這個(gè)過(guò)程是阻塞的。
currentClient.request()就是由如下所示,組裝request,然后構(gòu)造一個(gè)future調(diào)用NettyClient發(fā)送請(qǐng)求。
public ResponseFuture request(Object request, int timeout) throws RemotingException {
if (this.closed) {
throw new RemotingException(this.getLocalAddress(), (InetSocketAddress)null, "Failed to send request " + request + ", cause: The channel " + this + " is closed!");
} else {
Request req = new Request(); //構(gòu)建request
req.setVersion(Version.getProtocolVersion());
req.setTwoWay(true);
req.setData(request);
DefaultFuture future = new DefaultFuture(this.channel, req, timeout);
try {
this.channel.send(req); //調(diào)用NettyServer.sent()進(jìn)行發(fā)送請(qǐng)求
return future;
} catch (RemotingException var6) {
future.cancel();
throw var6;
}
}
}
Dubbo默認(rèn)的調(diào)用方式是異步調(diào)用,那么這個(gè)future保存至上下文之后,等響應(yīng)回來(lái)之后怎么找到對(duì)應(yīng)的future呢?
進(jìn)入DefaultFuture看看:
public class Request {
private final long mId;
public Request() {
this.mId = newId();
}
//靜態(tài)變量遞增,依次構(gòu)造唯一ID
private static long newId() {
return INVOKE_ID.getAndIncrement();
}
}
public class DefaultFuture implements ResponseFuture {
private static final Map<Long, DefaultFuture> FUTURES = new ConcurrentHashMap();
public DefaultFuture(Channel channel, Request request, int timeout) {
this.done = this.lock.newCondition();
this.start = System.currentTimeMillis();
this.channel = channel;
this.request = request;
this.id = request.getId(); //唯一ID
this.timeout = timeout > 0 ? timeout : channel.getUrl().getPositiveParameter("timeout", 1000);
FUTURES.put(this.id, this); //將唯一ID和future的關(guān)系保存到這個(gè)ConcurrentHashMap中
CHANNELS.put(this.id, channel);
}
}
Request構(gòu)造對(duì)象的時(shí)候會(huì)生成一個(gè)唯一ID,future內(nèi)部也會(huì)將自己與請(qǐng)求ID存儲(chǔ)到一個(gè)ConcurrentHashMap中,這個(gè)ID發(fā)送至服務(wù)端之后,服務(wù)端也會(huì)把這個(gè)ID返回,通過(guò)ID再去ConcurrentHashMap中找到對(duì)應(yīng)的future,由此完成一次完整的調(diào)用。
最終相應(yīng)返回之后會(huì)調(diào)用DefaultFuture.received():
public static void received(Channel channel, Response response) {
try {
//獲取響應(yīng)的ID去FUTURES中獲取對(duì)應(yīng)的future,獲取之后將future移除
DefaultFuture future = (DefaultFuture)FUTURES.remove(response.getId());
if (future != null) {
//確認(rèn)接收響應(yīng)
future.doReceived(response);
} else {
logger.warn("....");
}
} finally {
CHANNELS.remove(response.getId());
}
}
private void doReceived(Response res) {
this.lock.lock();
try {
this.response = res; //響應(yīng)賦值
if (this.done != null) {
this.done.signal(); //通知響應(yīng)返回
}
} finally {
this.lock.unlock();
}
if (this.callback != null) {
this.invokeCallback(this.callback);
}
}

調(diào)用流程源碼分析——服務(wù)端
服務(wù)端接受請(qǐng)求之后會(huì)解析請(qǐng)求得到消息,消息總共有五種派發(fā)策略:

Dubbo默認(rèn)使用的是all,所有消息都派發(fā)到業(yè)務(wù)線程池中,在AllChannelHandler中實(shí)現(xiàn):
public void received(Channel channel, Object message) throws RemotingException {
ExecutorService cexecutor = this.getExecutorService();
try {
cexecutor.execute(new ChannelEventRunnable(channel, this.handler, ChannelState.RECEIVED, message));
} catch (Throwable var8) {
if (message instanceof Request && var8 instanceof RejectedExecutionException) {
Request request = (Request)message;
if (request.isTwoWay()) { //如果需要返回響應(yīng),將錯(cuò)誤封裝起來(lái)之后返回
String msg = "Server side(" + this.url.getIp() + "," + this.url.getPort() + ") threadpool is exhausted ,detail msg:" + var8.getMessage();
Response response = new Response(request.getId(), request.getVersion());
response.setStatus((byte)100);
response.setErrorMessage(msg);
channel.send(response);
return;
}
}
throw new ExecutionException(message, channel, this.getClass() + " error when process received event .", var8);
}
}
上述代碼就是將消息封裝成一個(gè)ChannelEventRunnable然后放入業(yè)務(wù)線程池中執(zhí)行,ChannelEventRunnable會(huì)根據(jù)ChannelState參數(shù)調(diào)用對(duì)應(yīng)的處理方法,此處是ChannelState.RECEIVED,因此調(diào)用的是handler.received,最終調(diào)用的是HeaderExchangeHandler.handleRequest()方法:
Response handleRequest(ExchangeChannel channel, Request req) throws RemotingException {
Response res = new Response(req.getId(), req.getVersion()); //通過(guò)requestId構(gòu)造響應(yīng)
Object data;
if (req.isBroken()) {
data = req.getData();
String msg;
if (data == null) {
msg = null;
} else if (data instanceof Throwable) {
msg = StringUtils.toString((Throwable)data);
} else {
msg = data.toString();
}
res.setErrorMessage("Fail to decode request due to: " + msg);
res.setStatus((byte)40);
return res;
} else {
data = req.getData();
try {
Object result = this.handler.reply(channel, data); //最終調(diào)用DubboProtocol.reply()
res.setStatus((byte)20);
res.setResult(result);
} catch (Throwable var6) {
res.setStatus((byte)70);
res.setErrorMessage(StringUtils.toString(var6));
}
return res;
}
}
進(jìn)入DubboProtocol.reply()看看:
public Object reply(ExchangeChannel channel, Object message) throws RemotingException {
if (!(message instanceof Invocation)) {
throw new RemotingException();
} else {
Invocation inv = (Invocation)message;
Invoker<?> invoker = DubboProtocol.this.getInvoker(channel, inv); //根據(jù)inv得到對(duì)應(yīng)的Invoker
if (Boolean.TRUE.toString().equals(inv.getAttachments().get("_isCallBackServiceInvoke"))) {
//一些回調(diào)邏輯
} else {
hasMethod = inv.getMethodName().equals(methodsStr);
}
}
RpcContext.getContext().setRemoteAddress(channel.getRemoteAddress());
return invoker.invoke(inv); //調(diào)用選擇的Invoker.invoke()
}
}
最后的調(diào)用我們已經(jīng)了解過(guò),就是調(diào)用一個(gè)Javassist生成的代理類,其中包含了真正的實(shí)現(xiàn)類;再進(jìn)入this.getInvoker()看看是怎么根據(jù)請(qǐng)求信息獲取到Invoker的:
Invoker<?> getInvoker(Channel channel, Invocation inv) throws RemotingException {
//....
int port = channel.getLocalAddress().getPort();
String path = (String)inv.getAttachments().get("path");
//根據(jù)port、path以及其他信息獲取serviceKey
String serviceKey = serviceKey(port, path, (String)inv.getAttachments().get("version"), (String)inv.getAttachments().get("group"));
//根據(jù)serviceKey在之前提到的exportMap中獲取exporter
DubboExporter<?> exporter = (DubboExporter)this.exporterMap.get(serviceKey);
if (exporter == null) {
throw new RemotingException(....);
} else {
return exporter.getInvoker(); //返回Invoker
}
}
關(guān)鍵點(diǎn)在于serviceKey,在之前服務(wù)暴露提到的將Invoker封裝成exporter之后再構(gòu)建一個(gè)exporterMap,將serviceKey和對(duì)應(yīng)的exporter存入,在服務(wù)調(diào)用時(shí)這個(gè)map就起到作用了。
找到所需要的Invoker最終調(diào)用實(shí)現(xiàn)類具體方法再返回響應(yīng)整個(gè)服務(wù)調(diào)用流程就結(jié)束了,再對(duì)上述的流程圖進(jìn)行一下補(bǔ)充:

總結(jié)
首先客戶端調(diào)用接口中的某個(gè)方法,但實(shí)際調(diào)用的是代理類,代理類通過(guò)Cluster從獲取Invokers,之后通過(guò)Router進(jìn)行路由過(guò)濾,再通過(guò)所配置的負(fù)載均衡機(jī)制進(jìn)行篩選得到本次遠(yuǎn)程調(diào)用所需要的Invoker,此時(shí)根據(jù)具體的協(xié)議構(gòu)造請(qǐng)求頭,再將參數(shù)根據(jù)具體的序列化協(xié)議進(jìn)行序列化之后構(gòu)造好塞入?yún)f(xié)議體,最后通過(guò)NettyClient發(fā)起遠(yuǎn)程調(diào)用。
服務(wù)端NettyServer收到請(qǐng)求后,根據(jù)協(xié)議將得到的信息進(jìn)行反序列化得到對(duì)象,根據(jù)消息派發(fā)策略(默認(rèn)是All)將消息丟入線程池。
業(yè)務(wù)現(xiàn)場(chǎng)會(huì)根據(jù)消息類型得到serviceKey,用這個(gè)key從之前服務(wù)暴露生成的exportMap中得到對(duì)應(yīng)的Invoker,然后調(diào)用真正的實(shí)現(xiàn)類中的具體方法。
最終將結(jié)果返回,因?yàn)檎?qǐng)求和響應(yīng)的都有一個(gè)對(duì)應(yīng)且唯一的ID,客戶端會(huì)根據(jù)響應(yīng)的ID找到存儲(chǔ)起來(lái)的Future,塞入響應(yīng)中等待喚醒Future的線程,這就完成了一次完整的調(diào)用過(guò)程。
如有錯(cuò)誤或不足歡迎評(píng)論指正。
以上就是java開發(fā)分布式服務(wù)框架Dubbo調(diào)用過(guò)程的詳細(xì)內(nèi)容,更多關(guān)于Dubbo服務(wù)調(diào)用過(guò)程的資料請(qǐng)關(guān)注腳本之家其它相關(guān)文章!
相關(guān)文章
Java項(xiàng)目之java+springboot+ssm實(shí)現(xiàn)理財(cái)管理系統(tǒng)設(shè)計(jì)
這篇文章主要介紹了Java項(xiàng)目java+springboot+ssm實(shí)現(xiàn)理財(cái)管理系統(tǒng)設(shè)計(jì),使用了當(dāng)前較為流行的spring boot,spring,spring mvc,mybatis,shiro框架分頁(yè)處理使用了pagehelper進(jìn)行操作,需要的朋友可以參考一下2022-03-03
PageHelper引發(fā)的幽靈數(shù)據(jù)問(wèn)題解析
這篇文章主要為大家介紹了PageHelper引發(fā)的幽靈數(shù)據(jù)問(wèn)題解析,有需要的朋友可以借鑒參考下,希望能夠有所幫助,祝大家多多進(jìn)步,早日升職加薪2023-04-04
java自帶的工具Jstack截取進(jìn)程中的堆棧信息
本文給大家記錄的是java自帶的工具Jstack截取進(jìn)程中的堆棧信息的方法,非常的實(shí)用,有需要的小伙伴可以參考下。2016-01-01
Java多線程之scheduledThreadPool的方法解析
這篇文章主要介紹了Java多線程之scheduledThreadPool的方法解析,queue是DelayedWorkQueue,但通過(guò)后面的分析可以知道,最大線程數(shù)是不起作用的,最多會(huì)起核心線程數(shù)的數(shù)量,需要的朋友可以參考下2023-12-12
利用Netty+SpringBoot實(shí)現(xiàn)定時(shí)后端向前端推送數(shù)據(jù)
這篇文章主要介紹了BIO、NIO、AIO三種Java?IO模型,并探討了如何使用Spring?Boot集成Netty實(shí)現(xiàn)后臺(tái)向前端推送信息的功能,文中通過(guò)代碼介紹的非常詳細(xì),需要的朋友可以參考下2025-01-01
Spring Boot實(shí)現(xiàn)自動(dòng)發(fā)送郵件
這篇文章主要為大家詳細(xì)介紹了Spring Boot實(shí)現(xiàn)自動(dòng)發(fā)送郵件,文中示例代碼介紹的非常詳細(xì),具有一定的參考價(jià)值,感興趣的小伙伴們可以參考一下2020-02-02

