作者 | EF中國項目組 2021 EdgeX中國挑戰賽自7月12日開幕以來，得到各方積極響應，初賽作品提交通道已於8月10日順利關閉。 本次大賽共收到 80 支隊伍報名，55 份提交作品，相比 2020 年有近 50% 的提升。本次大賽的參賽隊背景多樣性很強，既包括像研華、新華三、網易、中興通訊、京東、中科創達、正泰電器等物聯網頭部企業，也包括江行智能、南京未來物聯 等初創公司，以及來自南洋理工大學、中國科技大學、南方科技大學、常州工學院 等高校的老師和學生。隨著 EdgeX Foundry 影響力的擴大，今年 EdgeX 挑戰賽的覆蓋範圍也大為拓寬，已由中國大陸延伸到了中國臺灣、新加坡。EdgeX 中國挑戰賽已成為輻射華語區的全球 EdgeX 黑客鬆賽事。 與去年相比，今年參賽作品涵蓋更為廣泛的行業，包括零售、工業、物流、商業和醫療，為 EdgeX 的應用部署拓廣了新的空間。在已提交的參賽作品中，有 27 份作品使用了人工智能工具套件 […]
作者 | 顧榮 Fluid開源社區主席 南京大學PASALab Fluid 是 CNCF 基金會旗下雲原生環境中數據密集型應用的高效支撐平臺，由南京大學、阿里云云原生團隊以及 Alluxio 開源社區聯合發起。項目自開源發佈以來吸引了眾多相關方向領域專家和工程師的關注，在大家的積極反饋下社區不斷演進。近期 Fluid 0.6 版本正式發佈，在該版本中，Fluid 主要新增改善以下三個方面內容： 數據感知的Pod調度，支持數據與應用協同調度，加強生態融合, 適配更多開源調度器。 豐富數據集操作功能，支持數據集自動彈性擴縮容、掛載點動態更新。 緩存引擎新增與增強，支持緩存引擎高可用並新增公有云緩存引擎。 Fluid
調度隊列和優化 Golang 實現無重複元素的隊列 Golang 實現固定Size的循環隊列 模擬貨運運輸和優化 假設： 有N個貨物，每個貨物有三個屬性： 貨物ID、貨物裝上車耗費的時間、貨物裝車後價值。 假設N個貨物同時到達站點等待裝車,裝車操作有序執行作答要求：(1)模擬N個貨物的單個貨物的耗費時間、貨物價值(2)輸出：計算N個貨物總排隊時間總排隊執行時間：定義第n個貨物排隊+執行耗時 time(n),n=0,time(0)=0定義第n個貨物裝車時間 load(n)= 隨機值第n個貨物排隊執行時間：time(n)= time(n-1)+load(n)(3)編程語言：java、golang、c、c++ 任意一種 基於上面試題3，假設貨物之間裝載沒有依賴關係，誰先誰後都是可以的假設貨車體積有限，如何優化，使得使得等待時間最小、貨物價值最大？編程語言：java、golang、c、c++ 任意一種 模擬公平調度算法實現 例如：Linux Completely
sync/atomic 介紹 當我們想要對某個變量併發安全的修改，除了使用官方提供的 mutex，還可以使用 sync/atomic 包的原子操作，它能夠保證對變量的讀取或修改期間不被其他的協程所影響。 atomic 包的原子操作是通過 CPU 指令，也就是在硬件層次去實現的，性能較好，不需要像 mutex 那樣記錄很多狀態。 當然，mutex 不止是對變量的併發控制，更多的是對代碼塊的併發控制，2 者側重點不一樣。 sync/atomic 操作 atomic 包有幾種原子操作，主要是 Add、CompareAndSwap、Load、Store、Swap。
本文介紹了 SmartNews 利用 Flink 加速 Hive 日表的生產，將 Flink 無縫地集成到以 Airflow 和 Hive 為主的批處理系統的實踐。詳細介紹過程中遇到的技術挑戰和應對方案，以供社區分享。主要內容為： 項目背景 問題的定義 項目的目標 技術選型 技術挑戰 整體方案及挑戰應對 項目成果和展望
一 方案介紹 為了解決Native模塊上線後的問題，mPaas 提供了熱修復功能，實現不發佈客戶端apk場景下的熱修復。目前Android端熱修復主要包括andfix和dexpatch，考慮到andfix的版本兼容性，目前主要推薦使用DexPatch。 DexPatch修復原理比較簡單，就是在啟動後通過RPC拉取當前需要下發的jar包地址，然後通過獨立進程去下載jar包文件，下載完成後保存。在二次啟動的時候hook系統的classLoader，修改DexPathList, 在其數組的最前面加入一個有修改過的class的dex文件，使其攔截住數組後面的dex文件中同名的class的加載。如下圖所示，classloader就會優先加載Patch.dex中的Ding.class，而忽略Classes.dex中的Ding.class, 達到了替換的效果。 基於這樣的原理，DexPatch具有以下特徵： 支持範圍上：是基於類級別的替換，所以只支持Java模塊的patch，不支持非Java模塊的patch，比如so模塊 兼容性上：由於是代理了系統的ClassLoader，使用的黑科技較少，所以整體方案兼容性較好 生效時效性上：只能在下載patch後重啟後才能生效，不支持實時生效 成功率上：由於下載是使用的獨立進程，減少了啟動階段主進程閃退對patch下載的影響，提升了下載的成功比例 二 使用介紹 以下介紹下在mPaas下使用DexPatch模塊的主要步驟以及問題排查思路，方便開發者日常開發。 1. 觸發patch拉取 啟動階段調用MPHotpatch.init(), 主要觸發Patch信息的RPC請求，如果命中發佈Patch發佈規則，RPC會返回Patch的jar包下載地址，客戶端去觸發下載，下載後保存在客戶端私有目錄/data/user/0/包名/dexpatch/patch/ 下。
1.系統選擇與環境搭建： (1)在系統選擇方面由於我對linux系統只學過一點皮毛所以不敢貿然使用，於是windows系統就成了我的不二之選(至少在系統操作方面的問題能減少)。 當我想連接我的雲服務器時第一個問題出現了：我該如何連接到服務器？在查詢資料後我發現了一個最適合我的辦法：使用windows系統自帶的遠程桌面連接。2)在第一次連接後我欣喜若狂，彷彿解決了世紀難題但其實更大的難題在拐角處等待著我。之後我按查詢的資料打算親自配置java+tomcat+mysql環境 但這個天真的想法毀了我剛剛得到的好心情。在配置java與tomcat時沒出現太大的問題但在mysql上便問題重重，在我查詢資料和認真思考後認為是缺少必要 的插件，因為我目前使用的是裸機一切都需要自己搭建這對我這個服務器小白來說是滅頂之災，但好在我發現了鏡像這一功能。鏡像的使用能使你免受環境搭 建的痛苦，我們可以在鏡像市場中挑選適合自己所需運行環境這樣我們就無需自己搭建。如我的需求是向服務器上傳web項目，我選擇的鏡像就包含了java， tomcat，mysql這三大類。當我第二次連接後服務器已經搭建好了環境，同時桌面上出現了一個TXT文檔裡面是一串字符。經過查詢和分析認定這是數據庫的密碼 但賬號還不得而知，於是我回到我選擇的鏡像的使用說明中查看詳細信息；很遺憾他沒能給我任何有用信息。我便大膽的嘗試了“root”這一祖傳通用用戶名，沒想到 連接成功了！至此關於環境搭建的問題得以解決。 2.對數據庫的操作 (1)環境搭建好後我就想著把項目所需數據庫內容也導入到雲服務器上，但對於DOS界面的操作實在過於繁瑣我便開始尋找能讓雲服務器數據庫可視化的工具， 經過一番查詢發現阿里雲已經為我們製作好了一款軟件DMS，我們可以在阿里雲官網上找到它，下載後通過網上的使用教程我們能簡易的將雲服務器上的數據庫添加
一 背景 目前 mPaas Android是使用的是Crash SDK對閃退進行的處理，CrashSDK 是 Android 平臺上一款功能強大的崩潰日誌收集 SDK，有著極高的崩潰收集率和完整、全面的崩潰日誌信息，生成的日誌內容非常利於問題的跟進和解決。在我們的日常運維中，經常遇到一些閃退，無法直接從閃退堆棧看到原因，尤其是一些非Java的Native的閃退，這裡分享下在mPaas框架下怎麼使用Crash SDK對閃退進行分析。 二 閃退報文分析工具介紹 對於mPaas的用戶，從MAS上閃退分析平臺導出的一般是原始的閃退信息，閃退信息比較多，如果直接閱讀會比較困難，使用者可以通過下載Chrome的插件LogAnalyzer，LogAnalyzer會將Crash SDK生成的日誌文本內容轉化成可視效果較強的 HTML 頁面展現，功能還是很強大的，主要包含： 1. 高亮顯示日誌中重點信息，並使用不同顏色區分； 2.
一 背景 在金融性質的App裡，選擇本地相冊圖片或者拍照，然後預覽並且上傳是一個典型的使用場景，比如常見的身份證信息上傳。在最近接觸的幾家銀行客戶裡，都反饋有類似的場景，並且在使用上都或多或少的遇到一些問題，最後找到我們，希望我們提供一些最佳實踐。在這裡分享下對應場景的一些優化解決方案。 二 方案介紹 我們先介紹下各個銀行的傳統方案都是怎麼做的，以及存在的問題。 1. 選圖方案 1.1 方案1：使用Android原生Webview 方案介紹：前端通過input標籤，指定type=file，通過原生webview的支持實現選擇文件。 Android原生webView並不支持選擇文件上傳，需要外殼自己擴展WebChromeClient裡的openFileChooser或者onShowFileChooser，然後去喚起系統選擇文件彈框，選擇文件會使用系統提供的組件或者其他支持的app，返回的uri有的直接是文件的url，有的是contentprovider的uri，需要統一處理一下返回uri格式。這種方案存在以下問題 外殼定製實現的邏輯較多，還需要對系統不同文件選擇器返回的地址做兼容，容易有兼容性問題 選擇文件實現依賴系統的文件選擇器，不同手機實現不一致，無法做到統一 1.2 方案2：使用mPaas的H5容器 如果業務使用了mPaas的H5容器後，雖然容器內已經內置了喚起文件選擇器的一系列操作，但是還是一樣存在系統文件選擇器不可控的風險。比如如果業務希望選擇的是一張圖片，但是喚起後的效果可能是下面這個樣子，很多客戶也是無法接受的。 1.3 方案3：實現jsapi喚起Native自定義的選圖頁面 這種方案就是利用H5容器提供的自定義jsapi的能力，自定義一個選圖的jsapi，然後前端去調用，去喚起Native自己實現的選圖頁面，最後結果通過base64的形式返回給前端做顯示。這樣就解決了前面提到系統選擇文件不可控的問題。