當(dāng)前位置:首頁(yè) > 公眾號(hào)精選 > 架構(gòu)師社區(qū)
[導(dǎo)讀]大多數(shù)時(shí)候我都是寫一些業(yè)務(wù)代碼,可能一堆 CRUD 就能解決問題,但這樣的工作對(duì)技術(shù)人的提升并不多,如何讓自己從業(yè)務(wù)中解脫出來找到寫代碼的樂趣呢,我做過一些嘗試,使用設(shè)計(jì)模式改善自己的業(yè)務(wù)代碼就是其中的一種。

大多數(shù)時(shí)候我都是寫一些業(yè)務(wù)代碼,可能一堆 CRUD 就能解決問題,但是這樣的工作對(duì)技術(shù)人的提升并不多,如何讓自己從業(yè)務(wù)中解脫出來找到寫代碼的樂趣呢,我做過一些嘗試,使用設(shè)計(jì)模式改善自己的業(yè)務(wù)代碼就是其中的一種。


我寫的代碼,又被CTO罵了......

“你這代碼寫的像坨屎,今天我的代碼又被當(dāng)作典型被 CTO 罵了......于是他給我的建議如下:


責(zé)任鏈設(shè)計(jì)模式


模式定義


請(qǐng)求在一個(gè)鏈條上處理,鏈條上的受理者處理完畢之后決定是繼續(xù)往后傳遞還是中斷當(dāng)前處理流程。


適用場(chǎng)景


適用于多節(jié)點(diǎn)的流程處理,每個(gè)節(jié)點(diǎn)完成各自負(fù)責(zé)的部分,節(jié)點(diǎn)之間不知道彼此的存在,比如 OA 的審批流,Java Web 開發(fā)中的 Filter 機(jī)制。


舉一個(gè)生活中的例子,筆者之前租房的時(shí)候遇到了所謂的黑中介,租的時(shí)候感覺自己是上帝,但是壞了東西找他修的時(shí)候就像個(gè)孫子一樣。


中介讓我找門店客服,門店客服又讓我找房東,房東又讓我找她家老公,最終好說歹說才把這事了了(租房一定要找正規(guī)中介)。


實(shí)踐經(jīng)驗(yàn)


筆者目前所做的業(yè)務(wù)是校園團(tuán)餐的聚合支付,業(yè)務(wù)流程很簡(jiǎn)單:

  • 學(xué)生打開手機(jī)付款碼支付。

  • 食堂大媽使用機(jī)具掃付款碼收款。


大學(xué)食堂有個(gè)背景是這樣的,食堂有補(bǔ)貼,菜品比較便宜,所以學(xué)校是不愿意讓社會(huì)人士去學(xué)校食堂消費(fèi)的,鑒于此,我們?cè)谥Ц吨凹恿艘惶资欠裨试S支付的檢驗(yàn)邏輯。


大體如下:

  • 某檔口只允許某類用戶用戶消費(fèi),比如教師檔口只允許教師消費(fèi),學(xué)生檔口不允許校外用戶消費(fèi)。

  • 某個(gè)檔口一天只允許某類用戶消費(fèi)幾次,比如教師食堂一天只允許學(xué)生消費(fèi)一次。

  • 是否允許非清真學(xué)生消費(fèi),比如某些清真餐廳,是不允許非清真學(xué)生消費(fèi)的。


針對(duì)這幾類情況我建立了三類過濾器,分別是:

  • SpecificCardUserConsumeLimitFilter:按用戶類型判斷是否允許消費(fèi)。

  • DayConsumeTimesConsumeLimitFilter:按日消費(fèi)次數(shù)判斷是否允許消費(fèi)。

  • MuslimConsumeLimitFilter:非清真用戶是否允許消費(fèi)。


判斷邏輯是先通過 SpecificCardUserConsumeLimitFilter 判斷當(dāng)前用戶是否可以在此檔口消費(fèi)。


如果允許繼續(xù)由 DayConsumeTimesConsumeLimitFilter 判斷當(dāng)天消費(fèi)次數(shù)是否已用完;如果未用完繼續(xù)由 MuslimConsumeLimitFilter 判斷當(dāng)前用戶是否滿足清真餐廳的就餐條件,前面三條判斷,只要有一個(gè)不滿足就提前返回。


部分代碼如下:
public?boolean?canConsume(String?uid,String?shopId,String?supplierId){
????//獲取用戶信息,用戶信息包含類型(student:學(xué)生,teacher:老師,unknown:未知用戶)、名族(han:漢族,mg:蒙古族)
????UserInfo?userInfo?=?getUserInfo(uid);
????//獲取消費(fèi)限制信息,限制信息包含是否允許非清真消費(fèi)、每種類型的用戶是否允許消費(fèi)以及允許消費(fèi)的次數(shù)
???ConsumeConfigInfo?consumeConfigInfo?=?getConsumeConfigInfo(shopId,supplierId)?


????//?構(gòu)造消費(fèi)限制過濾器鏈條
????ConsumeLimitFilterChain?filterChain?=?new?ConsumeLimitFilterChain();
????filterChain.addFilter(new?SpecificCardUserConsumeLimitFilter());
????filterChain.addFilter(new?DayConsumeTimesConsumeLimitFilter());
????filterChain.addFilter(new?MuslimConsumeLimitFilter());
????boolean?checkResult?=?filterChain.doFilter(filterChain,?schoolMemberInfo,?consumeConfigInfo);

????//filterChain.doFilter方法
???public?boolean?doFilter(ConsumeLimitFilterChain?filterChain,UserInfo?userInfo,
?????????????ConsumeConfigInfo?consumeConfigInfo?)
{
????????//迭代調(diào)用過濾器
????????if(index????????????return?filters.get(index++).doFilter(filterChain,?userInfo,?consumeConfigInfo);
????????}
????}

????//SpecificCardUserConsumeLimitFilter.doFilter方法
?????public?boolean?doFilter(ConsumeLimitFilterChain?filterChain,UserInfo?userInfo,
?????????????ConsumeConfigInfo?consumeConfigInfo?)
{
????????????????//獲取某一類型的消費(fèi)限制,比如student允許消費(fèi),unknown不允許消費(fèi)
????????CardConsumeConfig?cardConsumeConfig?=?findSuitCardConfig(userInfo,?consumeConfigInfo);

????????//?判斷當(dāng)前卡用戶是否允許消費(fèi)
????????if?(consumeCardConfig?!=?null)?{
????????????if?((!CAN_PAY.equals(cardConsumeConfig?.getEnabledPay())))?{
????????????????return?false;
????????????}
????????}

????????????????//其余情況,繼續(xù)往后傳遞
????????????return?filterChain.doFilter(filterChain,?memberInfo,?consumeConfig);
????????}

????//DayConsumeTimesConsumeLimitFilter.doFilter方法
?????public?boolean?doFilter(ConsumeLimitFilterChain?filterChain,UserInfo?userInfo,
?????????????ConsumeConfigInfo?consumeConfigInfo?)
{
????????????????//獲取某一類型的消費(fèi)限制,比如student可以消費(fèi)2次
????????CardConsumeConfig?cardConsumeConfig?=?findSuitCardConfig(userInfo,?consumeConfigInfo);

????????????????//獲取當(dāng)前用戶今天的消費(fèi)次數(shù)
????????????????int?consumeCnt?=?getConsumeCnt(userInfo)????????
????????if(consumeCnt?>=?cardConsumeConfig.getDayConsumeTimesLimit()){
????????????????????return?false;
????????????????}

????????????????//其余情況,繼續(xù)往后傳遞
????????????????return?filterChain.doFilter(filterChain,?memberInfo,?consumeConfig);
????????}

總結(jié):將每種限制條件的判斷邏輯封裝到了具體的 Filter 中,如果某種限制條件的邏輯有修改不會(huì)影響其他條件,如果需要新加限制條件只需要重新構(gòu)造一個(gè) Filter 織入到 FilterChain 上即可。


策略設(shè)計(jì)模式


模式定義


定義一系列的算法,把每一個(gè)算法封裝起來,并且使它們可相互替換。


適用場(chǎng)景


主要是為了消除大量的 if else 代碼,將每種判斷背后的算法邏輯提取到具體的策略對(duì)象中,當(dāng)算法邏輯修改時(shí)對(duì)使用者無(wú)感知,只需要修改策略對(duì)象內(nèi)部邏輯即可。


這類策略對(duì)象一般都實(shí)現(xiàn)了某個(gè)共同的接口,可以達(dá)到互換的目的。


實(shí)踐經(jīng)驗(yàn)


筆者之前有個(gè)需求是用戶掃碼支付以后向檔口的收銀設(shè)備推送一條支付消息,收銀設(shè)備收到消息以后會(huì)進(jìn)行語(yǔ)音播報(bào),邏輯很簡(jiǎn)單,就是調(diào)用推送平臺(tái)推送一條消息給設(shè)備即可。


但是由于歷史原因,某些設(shè)備對(duì)接的推送平臺(tái)是不一樣的,A 類設(shè)備優(yōu)先使用信鴿推送,如果失敗了需要降級(jí)到長(zhǎng)輪詢機(jī)制,B 類設(shè)備直接使用自研的推送平臺(tái)即可。


還有個(gè)現(xiàn)狀是 A 類和 B 類的消息格式是不一樣的(不同的團(tuán)隊(duì)開發(fā),后期被整合到一起)。


鑒于此,我抽象出 PushStrategy 接口,其具體的實(shí)現(xiàn)有 IotPushStrategy 和 XingePushStrategy,分別對(duì)應(yīng)自研推送平臺(tái)的推送策略和信鴿平臺(tái)的推送策略,使用者時(shí)針對(duì)不同的設(shè)備類型使用不同的推送策略即可。


部分代碼如下:
/**
?*?推送策略
?*?/
public?interface?PushStrategy?{
????/**
?????????@param?deviceVO設(shè)備對(duì)象,包扣設(shè)備sn,信鴿pushid
?????????@param?content,推送內(nèi)容,一般為json
????????*/

????public?CallResult?push(AppDeviceVO?deviceVO,?Object?content);
}

IotPushStrategy?implements?PushStrategy{
????????/**
?????????@param?deviceVO設(shè)備對(duì)象,包扣設(shè)備sn,信鴿pushid
?????????@param?content,推送內(nèi)容,一般為json
????????*/

????public?CallResult?push(AppDeviceVO?deviceVO,?Object?content){
????????????//創(chuàng)建自研推送平臺(tái)需要的推送報(bào)文
????????????Message?message?=?createPushMsg(deviceVO,content);

????????????//調(diào)用推送平臺(tái)推送接口
????????????IotMessageService.pushMsg(message);
????????}
}

XingePushStrategy?implements?PushStrategy{
????????/**
?????????@param?deviceVO設(shè)備對(duì)象,包扣設(shè)備sn,信鴿pushid
?????????@param?content,推送內(nèi)容,一般為json
????????*/

????public?CallResult?push(AppDeviceVO?deviceVO,?Object?content){
????????????//創(chuàng)建信鴿平臺(tái)需要的推送報(bào)文
????????????JSONObject?jsonObject?=?createPushMsg(content);

????????????//調(diào)用推送平臺(tái)推送接口
????????????if(!XinggePush.pushMsg(message)){
????????????????//降級(jí)到長(zhǎng)輪詢
????????????????...
????????????}
????????}
}

/**
消息推送Service
*/

MessagePushService{
????pushMsg(AppDeviceVO?deviceVO,?Object?content){
????????if(A設(shè)備){
????????????XingePushStrategy.push(deviceVO,content);
????????}?else?if(B設(shè)備){
????????????IotPushStrategy.push(deviceVO,content);
????????}
????}
}

總結(jié):將每種通道的推送邏輯封裝到了具體的策略中,某種策略的變更不會(huì)影響其他策略,由于實(shí)現(xiàn)了共同接口,所以策略可以互相替換,對(duì)使用者友好。


比如 Java ThreadPoolExecutor 中的任務(wù)拒絕策略,當(dāng)線程池已經(jīng)飽和的時(shí)候會(huì)執(zhí)行拒絕策略,具體的拒絕邏輯被封裝到了 RejectedExecutionHandler 的 rejectedExecution 中。


模板設(shè)計(jì)模式


模式定義


模板的價(jià)值就在于骨架的定義,骨架內(nèi)部將問題處理的流程已經(jīng)定義好,通用的處理邏輯一般由父類實(shí)現(xiàn),個(gè)性化的處理邏輯由子類實(shí)現(xiàn)。


比如炒土豆絲和炒麻婆豆腐,大體邏輯都是:

  • 切菜

  • 放油

  • 炒菜

  • 出鍋


1,2,4 都差不多,但是第 3 步是不一樣的,炒土豆絲得拿鏟子翻炒,但是炒麻婆豆腐得拿勺子輕推,否則豆腐會(huì)爛(疫情宅在家,學(xué)了不少菜)。


使用場(chǎng)景


不同場(chǎng)景的處理流程,部分邏輯是通用的,可以放到父類中作為通用實(shí)現(xiàn),部分邏輯是個(gè)性化的,需要子類去個(gè)性實(shí)現(xiàn)。


實(shí)踐經(jīng)驗(yàn)


還是接著之前語(yǔ)音播報(bào)的例子來說,后期我們新加了兩個(gè)需求:

  • 消息推送需要增加 trace。

  • 有些通道推送失敗需要重試。


所以現(xiàn)在的流程變成了這樣:

  • trace 開始。

  • 通道開始推送。

  • 是否允許重試,如果允許執(zhí)行重試邏輯。

  • trace 結(jié)束。


其中 1 和 4 是通用的,2 和 3 是個(gè)性化的,鑒于此我在具體的推送策略之前增加了一層父類的策略,將通用邏輯放到了父類中。


修改后的代碼如下:
abstract?class?AbstractPushStrategy?implements?PushStrategy{
????@Override
????public?CallResult?push(AppDeviceVO?deviceVO,?Object?content)?{
????????//1.構(gòu)造span
????????Span?span?=?buildSpan();
????????//2.具體通道推送邏輯由子類實(shí)現(xiàn)
????????CallResult?callResult?=?doPush(deviceVO,?content);

????????//3.是否允許重試邏輯由子類實(shí)現(xiàn),如果允許執(zhí)行重試邏輯
????????if(!callResult.isSuccess()?&&?canRetry()){
????????????doPush(deviceVO,?content);
????????}

????????//4.trace結(jié)束
????????span.finish()?
????}

????//具體推送邏輯由子類實(shí)現(xiàn)
????protected?abstract?CallResult?doPush(AppDeviceVO?deviceDO,?Object?content)?;

????//是否允許重試由子類實(shí)現(xiàn),有些通道之前沒有做消息排重,所有不能重試
????protected?abstract?boolean?canRetry(CallResult?callResult);

}

XingePushStrategy?extends?AbstractPushStrategy{
????@Override
????protected?CallResult?doPush(AppDeviceVO?deviceDO,?Object?content)?{
????????//執(zhí)行推送邏輯
????}

????@Override
????protected?boolean?canRetry(CallResult?callResult){
????????return?false
????}
}

總結(jié):通過模板定義了流程,將通用邏輯放在父類實(shí)現(xiàn),減少了重復(fù)代碼,個(gè)性化邏輯由子類自己實(shí)現(xiàn),子類間修改代碼互不干擾也不會(huì)破壞流程。


觀察者設(shè)計(jì)模式


模式定義


顧名思義,此模式需要有觀察者(Observer)和被觀察者(Observable)兩類角色。


當(dāng) Observable 狀態(tài)變化時(shí)會(huì)通知 Observer,Observer 一般會(huì)實(shí)現(xiàn)一類通用的接口。


比如 java.util.Observer,Observable 需要通知 Observer 時(shí),逐個(gè)調(diào)用 Observer 的 update 方法即可,Observer 的處理成功與否不應(yīng)該影響 Observable 的流程。


使用場(chǎng)景


一個(gè)對(duì)象(Observable)狀態(tài)改變需要通知其他對(duì)象,Observer 的存在不影響 Observable 的處理結(jié)果,Observer 的增刪對(duì) Observable 無(wú)感知。


比如 Kafka 的消息訂閱,Producer 發(fā)送一條消息到 Topic,至于是 1 個(gè)還是 10 個(gè) Consumer 訂閱這個(gè) Topic,Producer 是不需要關(guān)注的。


實(shí)踐經(jīng)驗(yàn)


在責(zé)任鏈設(shè)計(jì)模式那塊我通過三個(gè) Filter 解決了消費(fèi)限制檢驗(yàn)的問題,其中有一個(gè) Filter 是用來檢驗(yàn)消費(fèi)次數(shù)的,我這里只是讀取用戶的消費(fèi)次數(shù),那么消費(fèi)次數(shù)的累加是怎么完成的呢?


其實(shí)累加這塊就用到了觀察者模式,具體來講是這樣,當(dāng)交易系統(tǒng)收到支付成功回調(diào)時(shí)會(huì)通過 Spring 的事件機(jī)制發(fā)布“支付成功事件”。


這樣負(fù)責(zé)累加消費(fèi)次數(shù)和負(fù)責(zé)語(yǔ)音播報(bào)的訂閱者就會(huì)收到“支付成功事件”,進(jìn)而做各自的業(yè)務(wù)邏輯。


畫個(gè)簡(jiǎn)單的圖描述一下:
我寫的代碼,又被CTO罵了......
代碼結(jié)構(gòu)大體如下:
/**
支付回調(diào)處理者
*/

PayCallBackController?implements?ApplicationContextAware?{
?????private?ApplicationContext?applicationContext;

????//如果想獲取applicationContext需要實(shí)現(xiàn)ApplicationContextAware接口,Spring容器會(huì)回調(diào)setApplicationContext方法將applicationContext注入進(jìn)來
????@Override
????public?void?setApplicationContext(ApplicationContext?applicationContext)
????????????throws?BeansException?
{
????????this.applicationContext?=?applicationContext;
????}
?????@RequestMapping(value?=?"/pay/callback.do")
?????public?View?callback(HttpServletRequest?request){
????????if(paySuccess(request){
????????????//構(gòu)造支付成功事件
????????????PaySuccessEvent?event?=?buildPaySuccessEvent(...);
????????????//通過applicationContext發(fā)布事件,從而達(dá)到通知觀察者的目的
????????????this.applicationContext.publishEvent(event);
????????}?
????}
}
/**
?*?語(yǔ)音播報(bào)處理者
?*
?*/

public?class?VoiceBroadcastHandler?implements?ApplicationListener<PaySuccessEvent>{
????@Override
????public?void?onApplicationEvent(PaySuccessEvent?event)?{
????????//語(yǔ)音播報(bào)邏輯
????}
}

//其他處理者的邏輯類似

總結(jié):觀察者模式將被觀察者和觀察者之間做了解耦,觀察者存在與否不會(huì)影響被觀察者的現(xiàn)有邏輯。


裝飾器設(shè)計(jì)模式


模式定義


裝飾器用來包裝原有的類,在對(duì)使用者透明的情況下做功能的增強(qiáng),比如 Java 中的 BufferedInputStream 可以對(duì)其包裝的 InputStream 做增強(qiáng),從而提供緩沖功能。


使用場(chǎng)景


希望對(duì)原有類的功能做增強(qiáng),但又不希望增加過多子類時(shí),可以使用裝飾器模式來達(dá)到同樣的效果。


實(shí)踐經(jīng)驗(yàn)


筆者之前在推動(dòng)整個(gè)公司接入 trace 體系,因此也提供了一些工具來解決 trace 的自動(dòng)織入和上下文的自動(dòng)傳遞。


為了支持線程間的上下文傳遞,我增加了 TraceRunnableWrapper 這個(gè)裝飾類,從而起到將父線程的上下文透?jìng)鞯阶泳€程中,對(duì)使用者完全透明。


代碼如下:
/**
可以自動(dòng)攜帶trace上下文的Runnable裝飾器
*/

public?class?TraceRunnableWrapper?implements?Runnable{
????//被包裝的目標(biāo)對(duì)象
????private?Runnable?task;
????private?Span?parentSpan?=?null;

????public?TraceRunnableWrapper(Runnable?task)?{
????????//1.獲取當(dāng)前線程的上下文(因?yàn)閚ew的時(shí)候還沒有發(fā)生線程切換,所以需要在這里將上下文獲?。?/span>
????????//對(duì)這塊代碼感興趣的可以查看opentracing?API
????????io.opentracing.Scope?currentScope?=?GlobalTracer.get().scopeManager().active();
????????//2.保存父上下文
????????parentSpan?=?currentScope.span();
????????this.task?=?task;
????}

????@Override
????public?void?run()?
{
????????//run的時(shí)候?qū)⒏妇€程的上下文綁定到當(dāng)前線程
????????io.opentracing.Scope?scope?=?GlobalTracer.get().scopeManager().activate(parentSpan,false);
????????task.run();
????}
}

//使用者
new?Thread(new?Runnable(){run(...)}).start()替換為new?TraceRunnableWrapper(new?Runnable(){run(...)}).start()

總結(jié):使用裝飾器模式做了功能的增強(qiáng),對(duì)使用者來說只需要做簡(jiǎn)單的組合就能繼續(xù)使用原功能。


外觀設(shè)計(jì)模式


模式定義


何為外觀,就是對(duì)外提供一個(gè)統(tǒng)一的入口:

  • 一是可以影藏系統(tǒng)內(nèi)部的細(xì)節(jié)。

  • 二是可以降低使用者的復(fù)雜度。


比如 SpringMVC 中的 DispaterServlet,所有的 Controller 都是通過 DispaterServlet 統(tǒng)一暴露。


使用場(chǎng)景


降低使用者的復(fù)雜度,簡(jiǎn)化客戶端的接入成本。


實(shí)踐經(jīng)驗(yàn)


筆者所在的公司對(duì)外提供了一些開放能力給第三方 ISV,比如設(shè)備管控、統(tǒng)一支付、對(duì)賬單下載等能力。


由于分屬于不同的團(tuán)隊(duì),所以對(duì)外提供的接口形式各異,初期還好,接口不多,ISV 也能接受,但是后期接口多了 ISV 就開始抱怨接入成本太高。


為了解決這一問題,我們?cè)陂_放接口前面加了一層前端控制器 GatewayController,其實(shí)就是我們后來開放平臺(tái)的雛形。


GatewayController 對(duì)外統(tǒng)一暴露一個(gè)接口 gateway.do,將對(duì)外接口的請(qǐng)求參數(shù)和響應(yīng)參數(shù)統(tǒng)一在 GatewayController 做收斂,GatewayController 往后端服務(wù)路由時(shí)也采用統(tǒng)一接口。


改造前后對(duì)比如下圖:
我寫的代碼,又被CTO罵了......
大概代碼如下:
使用者:
HttpClient.doPost("/gateway.do","{'method':'trade.create','sign':'wxxaaa','timestamp':'15311111111'},'bizContent':'業(yè)務(wù)參數(shù)'")

GatewayController:
@RequestMapping("/gateway.do")
JSON?gateway(HttpServletRequest?req){
???//1.組裝開放請(qǐng)求
???OpenRequest?openRequest?=?buildOpenRequest(req);

???OpenResponse?openResponse?=?null;
???//2.請(qǐng)求路由
???if("trade.create".equals(openRequest.getMethod()){
???????//proxy?to?trade?service?by?dubbo
???????openResponse?=?TradeFacade.execute(genericParam);
???}?else?if("iot.message.push".equals(openRequest.getMethod()){
???????//proxy?to?iot?service?by?httpclient
????????openResponse?=?HttpClient.doPost('http://iot.service/generic/execute'genericParam);
???}

???if(openResponse.isSuccess()){
????????return?{"code":"10000","bizContent":openResponse.getResult()};
???}else{
????????return?{"code":"20000","bizCode":openResponse.getCode()};
???}


}

總結(jié):采用外觀模式屏蔽了系統(tǒng)內(nèi)部的一些細(xì)節(jié),降低了使用者的接入成本。


就拿 GatewayController 來說,ISV 的鑒權(quán),接口的驗(yàn)簽等重復(fù)工作統(tǒng)一由它實(shí)現(xiàn)。


ISV 對(duì)接不同的接口只需要關(guān)心一套接口協(xié)議接口,由 GatewayController 這一層做了收斂。


作者:踩刀詩(shī)人

出處:https://urlify.cn/J3mAna


特別推薦一個(gè)分享架構(gòu)+算法的優(yōu)質(zhì)內(nèi)容,還沒關(guān)注的小伙伴,可以長(zhǎng)按關(guān)注一下:

我寫的代碼,又被CTO罵了......

我寫的代碼,又被CTO罵了......

我寫的代碼,又被CTO罵了......

長(zhǎng)按訂閱更多精彩▼

我寫的代碼,又被CTO罵了......

如有收獲,點(diǎn)個(gè)在看,誠(chéng)摯感謝

免責(zé)聲明:本文內(nèi)容由21ic獲得授權(quán)后發(fā)布,版權(quán)歸原作者所有,本平臺(tái)僅提供信息存儲(chǔ)服務(wù)。文章僅代表作者個(gè)人觀點(diǎn),不代表本平臺(tái)立場(chǎng),如有問題,請(qǐng)聯(lián)系我們,謝謝!

本站聲明: 本文章由作者或相關(guān)機(jī)構(gòu)授權(quán)發(fā)布,目的在于傳遞更多信息,并不代表本站贊同其觀點(diǎn),本站亦不保證或承諾內(nèi)容真實(shí)性等。需要轉(zhuǎn)載請(qǐng)聯(lián)系該專欄作者,如若文章內(nèi)容侵犯您的權(quán)益,請(qǐng)及時(shí)聯(lián)系本站刪除。
換一批
延伸閱讀

9月2日消息,不造車的華為或?qū)⒋呱龈蟮莫?dú)角獸公司,隨著阿維塔和賽力斯的入局,華為引望愈發(fā)顯得引人矚目。

關(guān)鍵字: 阿維塔 塞力斯 華為

倫敦2024年8月29日 /美通社/ -- 英國(guó)汽車技術(shù)公司SODA.Auto推出其旗艦產(chǎn)品SODA V,這是全球首款涵蓋汽車工程師從創(chuàng)意到認(rèn)證的所有需求的工具,可用于創(chuàng)建軟件定義汽車。 SODA V工具的開發(fā)耗時(shí)1.5...

關(guān)鍵字: 汽車 人工智能 智能驅(qū)動(dòng) BSP

北京2024年8月28日 /美通社/ -- 越來越多用戶希望企業(yè)業(yè)務(wù)能7×24不間斷運(yùn)行,同時(shí)企業(yè)卻面臨越來越多業(yè)務(wù)中斷的風(fēng)險(xiǎn),如企業(yè)系統(tǒng)復(fù)雜性的增加,頻繁的功能更新和發(fā)布等。如何確保業(yè)務(wù)連續(xù)性,提升韌性,成...

關(guān)鍵字: 亞馬遜 解密 控制平面 BSP

8月30日消息,據(jù)媒體報(bào)道,騰訊和網(wǎng)易近期正在縮減他們對(duì)日本游戲市場(chǎng)的投資。

關(guān)鍵字: 騰訊 編碼器 CPU

8月28日消息,今天上午,2024中國(guó)國(guó)際大數(shù)據(jù)產(chǎn)業(yè)博覽會(huì)開幕式在貴陽(yáng)舉行,華為董事、質(zhì)量流程IT總裁陶景文發(fā)表了演講。

關(guān)鍵字: 華為 12nm EDA 半導(dǎo)體

8月28日消息,在2024中國(guó)國(guó)際大數(shù)據(jù)產(chǎn)業(yè)博覽會(huì)上,華為常務(wù)董事、華為云CEO張平安發(fā)表演講稱,數(shù)字世界的話語(yǔ)權(quán)最終是由生態(tài)的繁榮決定的。

關(guān)鍵字: 華為 12nm 手機(jī) 衛(wèi)星通信

要點(diǎn): 有效應(yīng)對(duì)環(huán)境變化,經(jīng)營(yíng)業(yè)績(jī)穩(wěn)中有升 落實(shí)提質(zhì)增效舉措,毛利潤(rùn)率延續(xù)升勢(shì) 戰(zhàn)略布局成效顯著,戰(zhàn)新業(yè)務(wù)引領(lǐng)增長(zhǎng) 以科技創(chuàng)新為引領(lǐng),提升企業(yè)核心競(jìng)爭(zhēng)力 堅(jiān)持高質(zhì)量發(fā)展策略,塑強(qiáng)核心競(jìng)爭(zhēng)優(yōu)勢(shì)...

關(guān)鍵字: 通信 BSP 電信運(yùn)營(yíng)商 數(shù)字經(jīng)濟(jì)

北京2024年8月27日 /美通社/ -- 8月21日,由中央廣播電視總臺(tái)與中國(guó)電影電視技術(shù)學(xué)會(huì)聯(lián)合牽頭組建的NVI技術(shù)創(chuàng)新聯(lián)盟在BIRTV2024超高清全產(chǎn)業(yè)鏈發(fā)展研討會(huì)上宣布正式成立。 活動(dòng)現(xiàn)場(chǎng) NVI技術(shù)創(chuàng)新聯(lián)...

關(guān)鍵字: VI 傳輸協(xié)議 音頻 BSP

北京2024年8月27日 /美通社/ -- 在8月23日舉辦的2024年長(zhǎng)三角生態(tài)綠色一體化發(fā)展示范區(qū)聯(lián)合招商會(huì)上,軟通動(dòng)力信息技術(shù)(集團(tuán))股份有限公司(以下簡(jiǎn)稱"軟通動(dòng)力")與長(zhǎng)三角投資(上海)有限...

關(guān)鍵字: BSP 信息技術(shù)
關(guān)閉
關(guān)閉