當前位置：首頁 > 科技 > 軟件

同城雙活：交易鏈路的穩(wěn)定性與可靠性探索

來源：責編：時間：2024-03-26 09:37:37 279觀看

導讀知易行難，雙活過程中遇到了非常多的問題，但是回過頭看很難完美的表述出來，之所以這么久才行文也是這個原因，總是希望可以盡可能的復現(xiàn)當時的思考、問題細節(jié)及解決方案，但是寫出來才發(fā)現(xiàn)能給出的都是多次打磨、摸索之后的我

知易行難，雙活過程中遇到了非常多的問題，但是回過頭看很難完美的表述出來，之所以這么久才行文也是這個原因，總是希望可以盡可能的復現(xiàn)當時的思考、問題細節(jié)及解決方案，但是寫出來才發(fā)現(xiàn)能給出的都是多次打磨、摸索之后的我們認為偏合理的方案；不過換個角度看，給大家展示出來一個正確答案，是否有更積極的參考價值呢？

以及，涉及到容器、發(fā)布平臺、底層網(wǎng)絡運維、監(jiān)控等組件的內(nèi)容，限于視野及技術能力并未包含在內(nèi)，僅聚焦在業(yè)務團隊及中間件組件的設計及改造上。

一、背景

2022年，基于對穩(wěn)定性的焦慮...和思考，交易平臺聯(lián)動中間件平臺啟動過異地多活項目的探索，雖然完成了核心應用及基礎組件的改造，但在疫情&降本增效的影響下并未真正投產(chǎn)，同時也缺乏充分的測試以及線上流量的大規(guī)模驗證；后續(xù)在不斷的業(yè)務迭代中，相關設計及代碼被沖擊的面目全非，相關的多活自動化測試case也并沒有沉淀下來。

隨著近期外部友商時有嚴重故障出現(xiàn)，比如

圖片

以上林林總總出現(xiàn)的故障都給我們敲響了警鐘，必須建設快速恢復的能力。出現(xiàn)問題幾乎不可避免，但如果能控制影響范圍、縮短影響時間，也就能把損失降到最低。

我經(jīng)歷過的公司，做交易的和做中間件的往往是最容易焦慮也最容易心態(tài)失衡的兩撥技術人；一方面所有問題都會暴露在C端用戶面前，影響范圍大且不像toB/toM的場景避開高峰期甚至有可能無人知曉；另一方面流量高，壓力大，容易面臨突發(fā)流量及突發(fā)事件，穩(wěn)定性這根弦需要始終繃緊；所以往往是面向穩(wěn)定性(的焦慮)設計，當然熬過去成長也最快。

回到我們的現(xiàn)狀，得物目前的交易應用及中間件基礎組件都是基于某云部署，且前期為了降低跨機房調(diào)用產(chǎn)生的網(wǎng)絡損耗，較多應用都綁定了存儲組件(db/redis/hbase)及核心依賴下游的所在可用區(qū)，對此，為了避免在極端情況下，得物的交易主鏈路出現(xiàn)長時間不可用的情況，團隊決定提前預防，啟動同城雙活項目。

為了避免在極端情況下，得物的交易主鏈路出現(xiàn)長時間不可用的情況，團隊決定啟動同城雙活項目，目標是快速建設流量動態(tài)切換能力及快速恢復能力，同時降低改造難度、減少改造工作量，不增加大量額外成本。團隊討論決策繞過之前最復雜也最容易出問題的數(shù)據(jù)同步(db雙向同步、redis雙向同步等)，同時也不需要在流量切換時做db禁寫，整體具有比較大的可操作可實施性。

多說一句，同城雙活也有做數(shù)據(jù)雙向同步的case，當然更徹底--每個機房都有全量的數(shù)據(jù)及應用，某個機房出問題可以完全自閉環(huán)承接流量，不過帶來的復雜度上升、成本上升也會比較明顯，所以這次并沒有選擇這條路。換句話說，個人更傾向于小成本低風險快速落地，實現(xiàn)從0到1的功能建設，而不是大而全的方案，萬一期間遇到問題只能徒呼奈何。當然在現(xiàn)階段，通過建設相對低風險低投入的同城雙活，積累更多基礎能力的同時鍛煉團隊，選擇最合適當下的方案，解決目前排在第一位的問題，怎么想都覺得還是一件挺劃算的事兒。

畫一幅簡圖來區(qū)分下我們這次同城雙活的方案和業(yè)界異地雙活方案的差異。

異地雙活

圖片

主要特點：

存儲相關有兩份，雙機房內(nèi)各自讀寫，雙向同步

數(shù)據(jù)的循環(huán)賦值需要重點考慮如何處理

數(shù)據(jù)間的同步延遲問題會比較明顯，不過各自機房內(nèi)基本上可自閉環(huán)調(diào)用

對于用戶、商家資產(chǎn)的處理比較復雜，比如用戶券、賣家?guī)齑娴龋话阈枰紤]在某個機房維護(gzone)，避免數(shù)據(jù)同步問題帶來的超賣、超用

切流時需要做目標機房的局部數(shù)據(jù)禁寫，避免臟數(shù)據(jù)產(chǎn)生

同城雙活

圖片

特點：

只有一份數(shù)據(jù)源，不需要考慮數(shù)據(jù)同步的延遲問題及切流時的禁寫邏輯，不過若數(shù)據(jù)所在機房出問題，另一個機房無法正常承接流量(只能承接部分兜底流量，如cdn、緩存等有兜底數(shù)據(jù)的場景)
不需要考慮具備中心節(jié)點性質(zhì)的數(shù)據(jù)問題，如用戶券、庫存等
跨機房訪問較多，尤其是數(shù)據(jù)層面的讀寫，可能會造成RT的大幅上漲

不管是同城還是異地、雙活還是多活(雙活只是多活里最簡單的場景，雙活到三活難度飆升范圍應該不亞于<羊了個羊>里第一關和第二關的難度)，都是為了以下目標：

提高可靠性：通過在不同的物理位置部署服務，減少單點故障的風險。即使一個機房發(fā)生故障，其他機房也可以接管服務，確保業(yè)務連續(xù)性。
負載均衡：可以靈活分配用戶請求流量，避免單個機房過載，尤其隨著業(yè)務規(guī)模的擴大單個云廠商的機房已經(jīng)無力提供更多資源的情況下。
災難恢復：通過流量的調(diào)度切換來快速恢復某個機房的故障問題，減少業(yè)務中斷時間。
云成本：在技術成熟度較高的前提下，做同云、跨云甚至云+自建IDC機房之間的多活，一方面可以降低對某個云廠商的依賴從而獲取一定的議價權；另一方面多活本身在提高資源利用率方面可以有更多可能性。
提高服務質(zhì)量：這點尤其表現(xiàn)在異地多活場景，通過在多個中心之間分配流量，可以減少網(wǎng)絡延遲，提供更快的響應時間和更高的服務質(zhì)量。

二、設計思路

一句話描述：在云機房的多個可用區(qū)(即多個物理機房)中構造應用層面的雙集群部署，配合目前已經(jīng)在交易鏈路大規(guī)模上線的藍綠發(fā)布，完成流量的動態(tài)切換(含HTTP、RPC、DMQ[rocketmq/kafka])。而存儲(redis/db)還是在單機房(但是可以跨機房部署)，降低方案及實現(xiàn)的復雜度。

三、雙活整體架構

圖片

可以看到，整體在架構層面分為四層：

接入層：DNS 域名解析+ SLB主備 + DLB+DAG多機房部署，保障接入層高可用。其中在DAG中實現(xiàn)了根據(jù)用戶ID、流量比例等控制藍綠流量的策略。
應用層：應用通過改造，劃分為邏輯藍綠集群，通過藍綠同調(diào)的粘性屏蔽跨區(qū)調(diào)用。
中間件層：多個中間件組件有各自不同的跨AZ部署策略、數(shù)據(jù)同步、主動切換策略，下面會詳述。
數(shù)據(jù)層：數(shù)據(jù)層保持一份數(shù)據(jù)，通過自動/手動主從切換，跨區(qū)部署等技術手段，保障機房級別故障下服務可用，包含DB、Redis、Hbase等。

四、具體改造方案

本次雙活涉及到三個主要部分，分別是：交易應用側(cè)雙活改造、交易依賴方應用雙活改造、中間件&基礎組件改造。下面分別介紹：

交易應用側(cè)雙活改造

1. 項目范圍

交易側(cè)默認所有服務均參與同城雙活改造，一方面內(nèi)部應用之間的調(diào)用關系復雜，區(qū)分處理梳理工作量極高；另一方面快速的業(yè)務迭代也會改變互相之間的依賴關系，維護這套邏輯成本太高；以及，內(nèi)部強弱依賴本身也在動態(tài)變化，讓團隊的同學不斷的識別哪些應該雙活、哪些應該單點，溝通和執(zhí)行成本反而更高。

2.業(yè)務改造思路及方案

實際業(yè)務場景中復雜的鏈路拓撲最終可以抽象為如下典型的、原子的鏈路拓撲(A-B-C)的疊加、組合。

圖片

A、C服務參與雙活，需要跨可用區(qū)部署。B服務不參與雙活，不需要跨可用區(qū)部署。

A、B、C服務都需要識別流量染色、服從流量調(diào)度。

相關服務Owner各自將服務中集成的統(tǒng)一基礎框架升級到指定版本，接入無侵入、零配置、開箱即用的藍綠發(fā)布能力組件全家桶。保證基于藍綠發(fā)布的運行時流量調(diào)度能力被完整集成。上述簡圖中A、B、C服務需要進行該步驟。
相關服務Owner各自在發(fā)布平臺界面白屏化遷移發(fā)布模式。發(fā)布模式遷移到藍綠發(fā)布時，發(fā)布平臺自動將服務Pod進行跨可用區(qū)部署，并在Pod中注入支撐流量調(diào)度的進程級元信息。藍綠發(fā)布能力組件在上游調(diào)用方LoadBalance時介入進行流量染色、流量調(diào)度。上述簡圖中A、C服務需要進行該步驟。

完成上述改造后，雙活鏈路上的流量呈現(xiàn)就近調(diào)用、可用區(qū)封閉的特點，即：流量染色后，后續(xù)鏈路上的每一跳調(diào)用都會優(yōu)先向下游服務集群中與流量同色(同可用區(qū))的實例發(fā)起調(diào)用。

交易依賴方應用雙活改造

僅僅依靠交易側(cè)應用，無法完成所有的P0鏈路，如下單時依賴供應鏈側(cè)時效。強依賴的外域服務同樣納入了同城雙活改造范圍。其改造點基本一致，不再贅述。

中間件&基礎組件

識別機器資源可用區(qū)

項目初期，我們發(fā)現(xiàn)容器POD和ECS缺少可用區(qū)標識，導致無法區(qū)分對應的資源歸屬。于是我們配合運維組和監(jiān)控組的同事制定了一份規(guī)范。在環(huán)境變量里給機器都打上對應的標記，同時這也是監(jiān)控和日志能透出機房標記的基石。

中間件RTO

同城雙活要求中間件在單個可用區(qū)出問題的時候，仍能對外提供服務。其設計目標的RTO為以下：

主要組件雙活改造方案

01.DLB - 自研流量網(wǎng)關

圖片

DLB是無狀態(tài)組件，在兩個可用區(qū)對等部署。

當其中一個可用區(qū)故障時，在SLB的endpoints上故障節(jié)點會被剔除，流量會打到正常的節(jié)點，實現(xiàn)故障快速恢復的目標。預計秒級完成。

02.彩虹橋 - 自研分布式關系數(shù)據(jù)庫代理

圖片

彩虹橋目前不具備自動流量切換能力，一方面自動切換過于復雜，另一方面也容易帶來更多的風險，以及也依賴DB層面的主備切換，所以走手動切換，預計分鐘級完成。

目前流量99%走A區(qū)集群、1%的流量走B區(qū)集群，當A區(qū)發(fā)生可用區(qū)故障時，可手動把流量全部調(diào)度至B區(qū)集群，同時需要DB層完成主備切換(a->b)。

03.DMQ

圖片

通過Broker分片級別打散到不同的可用區(qū)形成一套完整的集群。

當可用區(qū)故障時，集群可用分片會減少一半，集群整體可用。

DMQ的改造經(jīng)過了多次試錯，最開始通過在消費端創(chuàng)建多個consumer group的方式實現(xiàn)，但需要業(yè)務側(cè)配合多次升級處理，且會導致消費端存在雙倍的consumer group，后面才決定將主要改造工作放在rocketmq broker內(nèi)部。簡要介紹如下：

藍綠屬性

BROKER中的隊列設定成偶數(shù)，并且>=2。我們把前一半隊列視為邏輯上的藍色隊列，后一半隊列視為綠色隊列(這里也可以看到，雙活里的很多處理邏輯都是非此即彼，但是如果到多活，復雜度就會更高)。

圖片

生產(chǎn)者

在進行隊列選擇時，根據(jù)集群環(huán)境藍綠顏色進行分組選擇：

藍集群的消息會被投遞的broker的前一半隊列中
綠集群的消息會被投遞到broker的后一半隊列中

在每種選擇邏輯內(nèi)部是按照輪循的方式進行選擇，不破壞生產(chǎn)者本身支持的容錯邏輯。

消費者

消費者也是類似。藍色消費者消費藍色隊列的消息。綠色消費者消費綠色隊列的消息。

04.Kafka

由于ZK的ZAB協(xié)議要求保證 Math.floor(n/2)+1 奇數(shù)個節(jié)點存活才能選出主節(jié)點，所以 ZK 需要進行3個可用區(qū)部署，上面的nameserver類似。分散在3個可用區(qū)中，A:B:C 節(jié)點數(shù) = 2N:2N:1，確保始終是奇數(shù)個集群節(jié)點。

Broker 在兩個可用區(qū)對等部署，分區(qū)的主從跨區(qū)部署。當單個可用區(qū)故障時，分區(qū)leader切換。

05.ES

ES多可用區(qū)部署，需要區(qū)分數(shù)據(jù)節(jié)點和master節(jié)點。

數(shù)據(jù)節(jié)點：需要保持各個可用區(qū)之間節(jié)點對等，以保證數(shù)據(jù)的平衡；使用分區(qū)感應把主副分片隔開，保持在不同可用區(qū)內(nèi)。

圖片

master節(jié)點：部署在至少三個可用區(qū)，以保證任何一個可用區(qū)掛了，都不影響master的選舉。

圖片

06.注冊中心

PS：自研分布式注冊中心，基于raft協(xié)議實現(xiàn)系統(tǒng)可用性、數(shù)據(jù)一致性。承擔得物全站RPC服務發(fā)布/訂閱職責。

圖片

代理節(jié)點多分區(qū)部署，保障多可用區(qū)雙活
Sylas集群Raft節(jié)點3個分區(qū)部署，保障多可用區(qū)雙活

流量分配策略

01.RPC流量

雙活的RPC的入口流量在DAG上進行調(diào)整，DAG會盡量根據(jù)用戶ID進行流量分配。

每個應用會在請求上下文中附上當前的藍綠標識；
如果某個應用沒有納入雙活范疇，這里的藍綠標識會丟失，此時有兩種策略：

a. 隨機分配，不過會破壞鏈路的純潔性；

b. 根據(jù)userID再算一次，不過需要增加一次對ark配置的處理。

圖片

02.MQ流量比例

因為藍綠集群的生產(chǎn)者和消費者對隊列進行了綁定。所以只要調(diào)整藍綠生產(chǎn)者的消息比例就可以調(diào)整整個MQ的消費流量比例。而藍綠生產(chǎn)者的消息比例一般由RPC流量決定。所以調(diào)整RPC的流量比例，MQ的流量比例也會得到相應的調(diào)整。不過會有一定的滯后(5-10s)。

五、上線環(huán)節(jié)

前期準備階段

整體思路確定：

基于當前的藍綠發(fā)布做雙活，每次的藍綠發(fā)布過程就是一次雙活切流演練，避免長久不使用，需要用的時候手忙腳亂或者年久失修
服務層做雙活部署，數(shù)據(jù)層不做大的改造，DB和Redis通過自身的主從切換實現(xiàn)高可用，從節(jié)點分布在不同的可用區(qū)
交易域內(nèi)所有服務+核心鏈路相關外域服務做雙活改造

梳理所有業(yè)務場景、MQ情況、容器部署現(xiàn)狀、數(shù)據(jù)庫&緩存主從節(jié)點可用區(qū)現(xiàn)狀：

交易域所有服務&以及核心業(yè)務場景強依賴的外部服務、強依賴的具體業(yè)務場景、可否降級&有無兜底
MQ使用情況：DMQ還是Kafka還是其他、是否需要保證消息的順序性
所有服務當前機器所在可用區(qū)、是否綁定固定可用區(qū)
交易域所有數(shù)據(jù)庫、Redis對應的主節(jié)點和從節(jié)點分別所在可用區(qū)情況
依賴zookeeper的job情況

評估改動范圍：

上下游非交易域溝通確認（必須納入改造范圍的服務、可以不用雙活改造的服務必須要有兜底）
雙活涉及到的服務jar升級、未接入藍綠發(fā)布的接入藍綠發(fā)布
跨區(qū)調(diào)用情況下RT上漲明顯的接口針對性優(yōu)化

部分業(yè)務場景是否需要接入自建Redis的就近讀改造：

運維側(cè)提供自建Redis的就近讀方案，但是對于數(shù)據(jù)一致性方面有所犧牲，各方根據(jù)實際業(yè)務場景和接口RT情況綜合評估是否需要接入

開發(fā)&驗證階段

服務jar升級：支持雙活藍綠切流、支持MQ藍綠發(fā)送&消費

雙活藍綠染色測試環(huán)境搭建、測試流程改善

環(huán)境本身的搭建：服務藍綠集群拆分、綁定可用區(qū)、容器藍綠集群機器比例配置
雙活藍綠染色環(huán)境代碼版本校驗、代碼準入規(guī)則、分支自動合并規(guī)則、測試流程流轉(zhuǎn)等
將雙活藍綠染色環(huán)境定為測試二輪round2環(huán)境，在日常迭代中常態(tài)化回歸驗證雙活流程

雙活藍綠染色測試環(huán)境回歸

正常業(yè)務流程回歸
測試環(huán)境藍綠切流回歸
測試環(huán)境MQ生產(chǎn)&消費切流回歸
核心業(yè)務接口RT情況記錄對比、優(yōu)化意見

雙活染色環(huán)境全局通道打開情況下藍綠發(fā)布通道切流回歸

驗證通道優(yōu)先級：發(fā)布通道優(yōu)先級 > 全局通道

預發(fā)環(huán)境集群拆藍綠

此刻預發(fā)環(huán)境等于已經(jīng)實際上完成了雙活改造

預發(fā)環(huán)境驗證&RT問題重點關注

線上所有雙活改造服務單獨拆一臺機器到B區(qū)觀察&驗證RT上漲問題

交易平臺絕大部分服務之前都是綁定可用區(qū)A區(qū)，每個服務單獨部署一臺機器到B區(qū)，觀察接口RT情況

DMQ升級藍綠2.0支持按照藍綠標消費

線上準備&上線階段

日志平臺、監(jiān)控平臺、trace鏈路、容器升級支持藍綠標

生產(chǎn)環(huán)境DMQ切換為藍綠2.0支持按照雙活藍綠標消費

數(shù)據(jù)庫&Redis主節(jié)點切換，保證主從節(jié)點只在A區(qū)或者B區(qū)

大部分在在a、b這兩個區(qū)，也有例外。核心是主節(jié)點一定要在這兩個區(qū)

線上服務拆分藍綠集群（手動），項目正式上線，回歸驗證&RT問題關注

綠集群（A區(qū)）擴容至100%機器，藍集群（B區(qū)）維持50%機器，灰度觀察5天

線上RT上漲接口技術專項優(yōu)化

發(fā)布平臺雙活保障迭代升級

支持新增服務一鍵加入雙活藍綠集群

圖片

雙活藍綠集群支持按區(qū)批量擴容能力（單機房故障情況下，快速拉起存活區(qū)的服務）

容器平臺支持容器管控多可用區(qū)部署

六、項目成果

2023年12月14日，籌備近100天的交易鏈路同城雙活完成上線，經(jīng)過5天(12.14-12.18)的觀察及圣誕前高流量(DLB流量達到雙十一的77.8%)的驗證，確認無明顯異常，之后線上集群完成縮容。部分場景的RT有一定比例的上漲(數(shù)據(jù)層面只做了跨可用區(qū)容災，但是并沒有實現(xiàn)就近訪問，所以藍集群的所有數(shù)據(jù)層面調(diào)用都需要跨可用區(qū))，已啟動技術小項目推動優(yōu)化中。

從實際效果上看，經(jīng)過12.22的大版本發(fā)布過程中的跨機房切流，交易鏈路已經(jīng)具備跨機房流量調(diào)度的能力，如下：

圖片

流量表現(xiàn)

（A區(qū) - 綠集群，B區(qū) - 藍集群)

兩個可用區(qū)的集群流量達到了50:50。不過rocketmq 由于存在少量上下游應用并未進行多活改造，還有較小流量未嚴格分布

圖片

核心指標 qps/rt/錯誤率

核心基礎組件訪問情況由于所有數(shù)據(jù)存儲(db、redis、hbase)均在A區(qū)，故B區(qū)的 rt 有一定上漲，整體看上浮大概 7-8ms( 存在一次請求查詢多次數(shù)據(jù)的場景)，還在持續(xù)推動優(yōu)化

成本情況

因A區(qū)原有云資源均為包年包月模式，停止使用依然會有費用產(chǎn)生；同時在B區(qū)部署服務穩(wěn)定性支撐50%流量之前，存在5天的并行期（A區(qū)100%資源、B區(qū)50%資源，共150%），期間共產(chǎn)少量成本。

灰度并行期結束后，A區(qū)資源釋放掉50%，整體成本回歸原有平均線，無額外成本產(chǎn)生。

七、帶來的新問題及后續(xù)

1. 藍綠發(fā)布中，如果下游接入了雙活但沒有進入發(fā)布通道，消費流量會傾斜，比如在上游切換流量過程中，RPC或MQ會優(yōu)先本可用區(qū)調(diào)用，也就是另一個可用區(qū)流量比例會受影響；需要關注每個可用區(qū)中冗余的容量評估是否可以支撐全量流量。

2. RT變化，對于下游未加入雙活、或者某些存儲/緩存中間件，如DB/Hbase/Redis未開啟就近讀取，B機房的RT會普遍高5-8ms。已在逐步投入優(yōu)化。

3. 容器管控作為基礎設施，在出現(xiàn)機房級故障的時候需要保證正常運行，能夠順利完成擴縮容操作，即容器管控面的多可用區(qū)部署，這塊目前還在建設中。

4. 機房級故障情況下，單機房批量擴容快速拉起，是否有足夠的可用資源（尤其是大促期間，云廠商本身資源就吃緊）。

5. 多個大域之間的雙活聯(lián)動問題，比如交易和搜推

兩個大域雙活切流是否需要聯(lián)動（聯(lián)動：影響范圍被放大，且搜推側(cè)擴容不易；不聯(lián)動：各域雙活流量非常割裂）
兩個大域之間的是否識別相同的藍綠標（各大域內(nèi)部自閉環(huán)保證同區(qū)訪問or大域之間也需要保證）

6. 如何在線上無損情況下進行一次貼近實際的演練。

以上問題都是在雙活之后帶來的新挑戰(zhàn)，也都在不斷的思考及投入解決。

不管做什么，不管怎么做，人生總會有新的問題出現(xiàn)，不是么？Keep a long-term view lol...

本文鏈接：http://m.www897cc.com/showinfo-26-79309-0.html同城雙活：交易鏈路的穩(wěn)定性與可靠性探索

聲明：本網(wǎng)頁內(nèi)容旨在傳播知識，若有侵權等問題請及時與本網(wǎng)聯(lián)系，我們將在第一時間刪除處理。郵件：2376512515@qq.com

上一篇：十個必備的VS Code插件，解鎖你的編程潛力

下一篇：深入探討Maven打包：打造精致的Zip包

標簽：

熱門焦點

5月安卓手機好評榜：魅族20 Pro奪冠

性能榜和性價比榜之后，我們來看最后的安卓手機好評榜，數(shù)據(jù)來源安兔兔評測，收集時間2023年5月1日至5月31日，僅限國內(nèi)市場。第一名：魅族20 Pro好評率：97.50%不得不感慨魅族老品牌還
六大權益！華為8月服務日開啟：手機免費貼膜、維修免人工費

8月5日消息，一年一度的華為開發(fā)者大會2023（Together）日前在松山湖拉開帷幕，與此同時，華為8月服務日也式開啟，到店可享六大專屬權益。華為用戶可在華為商城Ap
8月總票房已突破10億！《封神》第一：口碑已經(jīng)成了

8月5日消息，據(jù)燈塔專業(yè)版數(shù)據(jù)，截至8月5日9時35分，8月總票房（含預售）已突破10億。其中，《封神》以大比分的優(yōu)勢領先。根據(jù)官方消息，目前該片總票房已經(jīng)超過14.
一文看懂為蘋果Vision Pro開發(fā)應用程序

譯者 | 布加迪審校 | 重樓蘋果的Vision Pro是一款混合現(xiàn)實（MR）頭戴設備。Vision Pro結合了虛擬現(xiàn)實（VR）和增強現(xiàn)實（AR）的沉浸感。其高分辨率顯示屏、先進的傳感器和強大的處理能力
學習JavaScript的10個理由...

作者 | Simplilearn編譯 | 王瑞平當你決心學習一門語言的時候，很難選擇到底應該學習哪一門，常用的語言有Python、Java、JavaScript、C/CPP、PHP、Swift、C#、Ruby、Objective-
JVM優(yōu)化：實戰(zhàn)OutOfMemoryError異常

一、Java堆溢出堆內(nèi)存中主要存放對象、數(shù)組等，只要不斷地創(chuàng)建這些對象，并且保證 GC Roots 到對象之間有可達路徑來避免垃圾收集回收機制清除這些對象，當這些對象所占空間超過
得物寵物生意「狂飆」，發(fā)力“它經(jīng)濟”

作者｜花花小萌主近日，得物宣布正式上線寵物鑒別，通過得物App內(nèi)的“在線鑒別”，可找到鑒別寵物的選項。通過上傳自家寵物的部位細節(jié)，就能收獲擁有專業(yè)資質(zhì)認證的得物鑒
東方甄選單飛：有些鳥注定是關不住的

作者：彭寬鴻來源：華爾街科技眼&zwj;&zwj;&zwj;&zwj;&zwj;&zwj;&zwj;&zwj;&zwj;&zwj;東方甄選創(chuàng)始人俞敏洪帶隊的“7天甘肅行”直播活動已在近日順利收官。成立后一
攜眾多高端產(chǎn)品亮相ChinaJoy，小米帶來一場科技與人文的視聽盛宴

7月28日，全球數(shù)字娛樂領域最具知名度與影響力的年度盛會中國國際數(shù)碼互動娛樂展覽會（簡稱ChinaJoy）在上海新國際博覽中心盛大開幕。作為全球領先的科