博客 / 列表

京東雲開發者 - 給 Web 前端工程師看的用 Rust 開發 wasm 組件實戰 | 京東雲技術團隊

什麼是wasm組件？ wasm 全稱 WebAssembly，是通過虛擬機的方式，可以在服務端、客户端如瀏覽器等環境執行的二進制程序。他有速度快、效率高、可移植的特點。 對我們 Web 前端工程最大的好處就是可以在瀏覽器端使用二進制程序處理一些計算量大的處理，使用他比 javascript 快的特點優化性能。 目前瀏覽器對wasm的兼容性如下： 在移動端除了 android 4.4 和 ios

rust , webassembly , HTML , 前端 , Javascript

京東雲開發者 - DDD學習與感悟——總是覺得自己在CRUD怎麼辦？ | 京東雲技術團隊

一、DDD是什麼？ DDD全名叫做Domins drives Design；領域驅動設計。再説的通俗一點就是：通過領域建模的方式來實現軟件設計。 問題來了：什麼是軟件設計？為什麼要進行軟件設計？ 軟件開發最主要的目的就是：解決一個問題（業務）而產生的一個交付物（系統）。而軟件設計旨在高效的實現複雜項目軟件。也就是説軟件設計是從業務到系統之間的橋樑。 而DDD則是在複雜業務場景下一種更高效更合理的軟

架構 , curd , ddd , 後端

京東雲開發者 - ThreadPoolExecutor線程池內部處理淺析 | 京東物流技術團隊

我們知道如果程序中併發的線程數量很多，並且每個線程都是執行一個時間很短的任務就結束時，會因為頻繁創建線程而大大降低系統的效率，因此出現了線程池的使用方式，它可以提前創建好線程來執行任務。本文主要通過java的ThreadPoolExecutor來查看線程池的內部處理過程。 1 ThreadPoolExecutor java.uitl.concurrent.ThreadPoolExecutor類是線

線程池 , threadpoolexecutor , JAVA , 後端

京東雲開發者 - Taro：高性能小程序的最佳實踐 | 京東雲技術團隊

前言 作為一個開放式的跨端跨框架解決方案，Taro 在大量的小程序和 H5 應用中得到了廣泛應用。我們經常收到開發者的反饋，例如“渲染速度較慢”、“滑動不夠流暢”、“性能與原生應用相比有差距” 等。這表明性能問題一直是困擾開發者的一個重要問題。 熟悉 Taro 的開發者應該知道，相比於 Taro 1/2，Taro 3 是一個更加註重運行時而輕量化編譯時的框架。它的優勢在於提供了更高效的代碼編寫方式

小程序 , taro , 前端

京東雲開發者 - 如何做好架構設計，架構設計有章可循嗎？ | 京東雲技術團隊

設計一個系統的過程，就是建造一座大廈的過程，架構設計的質量直接決定了大廈的質量。 在我們進行系統的架構設計時，總是會遇到一系列的問題，比如一個大型系統的架構應該如何起步，從哪裏開始設計？系統是否應該劃分成多個模塊，應該怎麼劃分模塊才更加的合理？亦或是覺得產品提出的需求非常不合理，完全影響我們正常的架構設計！對於非功能性的需求，我們是否可以得過且過，不去重視？ 這些問題，讓我們在剛開始架構設計時手足

架構設計 , 架構 , 架構師

京東雲開發者 - 記一次線上問題引發的對 Mysql 鎖機制分析 | 京東物流技術團隊

背景 最近雙十一開門紅期間組內出現了一次因 Mysql 死鎖導致的線上問題，當時從監控可以看到數據庫活躍連接數飆升，導致應用層數據庫連接池被打滿，後續所有請求都因獲取不到連接而失敗 整體業務代碼精簡邏輯如下： @Transaction public void service(Integer id) { delete(id); insert(id); } 數據庫實例監控： 當時

死鎖 , MySQL , 鎖 , 數據庫

京東雲開發者 - MYSQL 事務的底層原理 | 京東物流技術團隊

事務的底層原理 在事務的實現機制上，MySQL 採用的是 WAL：Write-ahead logging，預寫式日誌，機制來實現的。 在使用 WAL 的系統中，所有的修改都先被寫入到日誌中，然後再被應用到系統中。通常包含 redo 和 undo 兩部分信息。 為什麼需要使用 WAL，然後包含 redo 和 undo 信息呢？舉個例子，如果一個系統直接將變更應用到系統狀態中，那麼在機器掉電重啓之後系

MySQL , 事務管理 , 數據庫 , 原理 , 事務

京東雲開發者 - 從混亂到優雅：基於DDD的六邊形架構的代碼翻新指南 | 京東物流技術團隊

前言 趁着雙十一備戰封板，終於又有一些時間可以梳理一下最近的心得。 最近這半年跟同事討論比較多的是分層架構，然後就會遇到兩個觸及靈魂的問題，一個是如何做好分層架構，二是DDD在架構層面該如何落地。 為了説好分層，我們需要了解架構的意義。 良好的架構是為了保證一下兩點： 治理應用複雜度，降低系統熵值； 從隨心所欲的混亂狀態，走向井井有條的有序狀態。 比如，你去圖書館借閲書籍，對於紛繁雜亂的各

分層架構圖 , 架構設計 , 架構 , ddd

京東雲開發者 - 線上SQL超時場景分析-MySQL超時之間隙鎖 | 京東物流技術團隊

前言 之前遇到過一個由MySQL間隙鎖引發線上sql執行超時的場景，記錄一下。 背景説明 分佈式事務消息表：業務上使用消息表的方式，依賴本地事務，實現了一套分佈式事務方案 消息表名：mq_messages 數據量：3000多萬 索引：create_time 和 status status：有兩個值，1 和 2， 其中99%以上的狀態都是2，表示分佈式事務全部已經執行完成，可以刪除。 消息表處理邏輯

MySQL , 鎖 , 數據庫 , SQL

京東雲開發者 - 完蛋！我被 Out of Memory 包圍了！ | 京東雲技術團隊

是極致魅惑、灑脱自由的Java heap space？ 是知性柔情、温婉大氣的GC overhead limit exceeded？ 是純真無邪、活潑可愛的Metaspace？ 如果以上不是你的菜，那還有…… 刁蠻任性，無跡可尋的CodeCache！ 性感火辣、心思細膩的Direct Memory 高貴冷豔，獨愛你一人的OOM Killer！ 總有一款，能讓你鍾情！BUG 選擇權

gc , 內存泄漏 , Linux , JAVA , 後端

京東雲開發者 - 微前端無界機制淺析 | 京東物流技術團隊

簡介 隨着項目的發展，前端SPA應用的規模不斷加大、業務代碼耦合、編譯慢，導致日常的維護難度日益增加。同時前端技術的發展迅猛，導致功能擴展吃力，重構成本高，穩定性低。 為了能夠將前端模塊解耦，通過相關技術調研，最終選擇了無界微前端框架作為物流客服系統解耦支持。為了更好的使用無界微前端框架，我們對其運行機制進行了相關了解，以下是對無界運行機制的一些認識。 基本用法 主應用配置 import Wuji

微前端 , 前端 , Javascript

京東雲開發者 - 線上JAVA應用平穩運行一段時間後出現JVM崩潰問題 | 京東雲技術團隊

一、問題是怎麼發現的 系統是一個定時任務系統，需要定時執行業務代碼，業務代碼主要是訪問MYSQL數據庫和緩存進行操作，該開始啓動，系統日誌一切正常，但是運行一段時間到凌晨後，系統就自動崩潰了，java進程沒有了，只留下了程序崩潰日誌如下： cat: /proc/1/environ: Permission denied [admin@host-11-40-38-52 ~]$ more hs_err_

定時任務 , jvm , JAVA , 後端

京東雲開發者 - 你的停機真的優雅麼？第二彈來襲 | 京東雲技術團隊

1. 前言 之前總結了一篇基於現有業務線在停機重啓時會產生RPC和MQ調用強殺導致業務數據不一致文章，文中通過優雅停機改造對RPC服務進行反註冊和MQ進行暫停消費，進而可以解決在停機時強制kill掉RPC線程或者MQ線程導致數據不一致現象，具體的原文大家感興趣可以去看一下。Ok前情提要結束，最近在一些核心應用上線重啓的時候又出現了業務訂單數據不一致的情況，通過排查定位發現還是因為停機不夠優雅，罪魁

定時任務 , 數據一致性 , 程序員 , 後端

京東雲開發者 - 同城售後系統退款業務重構心得 | 京東雲技術團隊

一、重構背景 1.1、退款 到家、小時購、天選退款有2套結構，代碼邏輯混亂； 其中小時購、天選部分售後單是和平生pop交互退款，部分是和售後中台交互退款；並且兼容3套邏輯； 痛點：代碼繁重，缺乏合理性的設計，後續迭代開發以及維護成本高，同時增加了系統的風險和不穩定性 1.2、金額計算 到家、小時購兩套獨立的邏輯結構計算，在此基礎上針對退差和非退差又實現了2套邏輯； 針對商品件維度、商品行維度、售後

架構設計 , 重構和設計模式 , 架構 , 重構 , 後端

京東雲開發者 - 為什麼idea建議使用“+”拼接字符串 | 京東雲技術團隊

前言 各位小夥伴在字符串拼接時應該都見過下面這種提示： 內容翻譯：報告StringBuffer、StringBuilder或StringJoiner的任何用法，這些用法可以用單個java.lang.String串聯來替換。使用字符串串聯可以使代碼更短、更簡單。只有當得到的串聯至少與原始代碼一樣高效或更高效時，此檢查才會報告。 大家普遍認知中，字符串拼接要使用StringBuilder，那為什麼i

字符串 , stringbuilder , intellij-idea , 程序員 , 後端

京東雲開發者 - 淺析Redis大Key | 京東雲技術團隊

一、背景 在京東到家購物車系統中，用户基於門店能夠對商品進行加車操作。用户與門店商品使用Redis的Hash類型存儲，如下代碼塊所示。不知細心的你有沒有發現，如果單門店加車商品過多，或者門店過多時，此Key就會越來越大，從而影響線上業務。 userPin:{ storeId:{門店下加車的所有商品基本信息}, storeId:{門店下加車的所有商品基本信息},

redis , key , redis集羣 , 後端

京東雲開發者 - 記一次老商家端應用內存突然飈高原因分析 | 京東物流技術團隊

一、排查過程 問題發現是因為當時接到了內存UMP報警信息，如下： 通過查看PFinder發現內存一直在增長，沒有停止跡象，觸發fullGC也並沒有下降趨勢： 當機立斷，先立即去NP上摘除了此台機器流量，然後繼續觀察，發現內存依然在不斷增長。 隨即查看故障分析，並沒有得到有效信息： 因為流量已經摘除，那麼繼續觀察到底哪裏的問題，約半小時後然後接到了機器的宕機告警如下： 由於在應用啓動參數裏

內存 , JAVA , 內存溢出 , 後端

京東雲開發者 - 實用的命令行終端增強軟件：Tabby | 京東雲技術團隊

還是那句話：出眾的軟件有很多，適合自己的才是最好的。 一、軟件介紹 Tabby是一個開源免費軟件，支持Windows、macOS和Linux系統。它提供了一個高度可定製的終端界面，可以通過多種方式添加、切換和關閉終端標籤頁。能與 Linux 服務器輕鬆傳輸文件，支持多種主題，界面炫酷，插件豐富。它還支持通過插件擴展其功能，例如增強的滾動條、批量複製和粘貼等功能。 github地址： htt

windows , 服務器 , 終端 , Linux , ios

京東雲開發者 - 頁面查詢多項數據組合的線程池設計 | 京東雲技術團隊

背景 我們應對併發場景時一般會採用下面方式去預估線程池的線程數量，比如QPS需求是1000，平均每個任務需要執行的時間是t秒，那麼我們需要的線程數是t * 1000。 但是在一些情況下，這個t是不好估算的，即便是估算出來了，在實際的線程環境上也需要進行驗證和微調。比如在本文所闡述分頁查詢的數據項組合場景中。 1、數據組合依賴不同的上游接接口， 它們的響應時間參差不齊，甚至差距還非常大。有些接口支持

線程池 , 數據 , JAVA

京東雲開發者 - 【京東開源項目】微前端框架MicroApp 1.0正式發佈

介紹 MicroApp是由京東前端團隊推出的一款微前端框架，它從組件化的思維，基於類WebComponent進行微前端的渲染，旨在降低上手難度、提升工作效率。MicroApp無關技術棧，也不和業務綁定，可以用於任何前端框架。 源碼地址： https://github.com/micro-zoe/micro-app 官網地址： https://micro-zoe.github.io/micro

react , 微前端 , 開源項目介紹 , 前端 , Javascript

京東雲開發者 - 深入理解線段樹 | 京東物流技術團隊

線段樹（Segment Tree）是常用的維護區間信息的數據結構，它可以在 O(logn) 的時間複雜度下實現單點修改、區間修改、區間查詢（區間求和、區間最大值或區間最小值）等操作，常用來解決 RMQ 問題。 RMQ(Range Minimum/Maximum Query) 問題是指：對於長度為 n 的數列 A，回答若干詢問 RMQ(A, i, j) 其中 i, j = n，返回數列 A 中下

數據結構 , 線段樹 , 數據結構與算法

京東雲開發者 - 交易履約之結算平台實踐 | 京東雲技術團隊

導讀 京東科技業務在快速發展的同時，產生了眾多線上化資金結算的需求。傳統的線下資金結算模式有着人力成本高、耗時長、多方溝通協調成本高、結算準確率低等固有缺點，且無法滿足“風法財審”對於資金流程的管控要求，在此背景下金道結算平台孕育而生。本文從系統建設的背景、設計細節、已支撐案例及適用業務場景多個層面進行詳細闡述。讀者可以關注文中所講的系統實踐過程，進而對結算領域系統設計能力提升，具有一定的參考價值

系統設計 , 架構設計 , 平台數字化 , 交易所

京東雲開發者 - Java21上手體驗-分代ZGC和虛擬線程 | 京東雲技術團隊

一、導語 幾天前Oracle剛剛發佈了Java21， 由於這是最新的LTS版本，引起了大家的關注。 我也第一時間在個人項目中進行了升級體驗。 一探究竟，和大家分享。 二、Java21更新內容介紹 官方release公告： https://jdk.java.net/21/release-notes 開源中國介紹： https://my.oschina.net/waylau/blog/10

java21 , gc , 線程 , JAVA , 後端

京東雲開發者 - 全場景流量驗證系統 | 京東物流技術團隊

本文介紹了一種基於線上流量實現對重構系統進行功能和性能驗證的實踐方案。針對線上流量如何攔截、如何錄製、如何存儲、如何回放以及如何發壓均作了詳細説明，為具有類似需求的讀者提供了一種可供參考的思路。 1 業務背景 隨着百川項目的啓動，中台需要對訂單流量收口，將ECLP、各BP的接單入口全部切換至百川統一接單系統。且各個接單入口調用方式各異，有JOS請求（外部商家）、JSF請求（如TC），也有MQ異步消

系統設計 , 測試 , 驗證規則 , 程序員 , 流量分析