博客 / 列表

得物技術 - ZGC關鍵技術分析

一、引言 垃圾回收對於Javaer來説是一個繞不開的話題，工作中涉及到的調優工作也經常圍繞垃圾回收器展開。面對不同的業務場景沒有一個統一的垃圾回收器能保證可GC性能。因此對程序員來説不僅要會編寫業務代碼，同時也要卷一下JVM底層原理和調優知識。這種局面可能因為ZGC的出現而發生改變，新一代回收器ZGC幾乎不需要調優的情況下GC停頓時間可以降低到亞秒級。 Oracle從JDK11開始正式引入ZGC，

gc , 高性能 , JAVA

得物技術 - Enhancer-輕量化的字節碼增強組件包

一、問題描述 當我們的業務發展到一定階段的時候，系統的複雜度往往會非常高，不再是一個簡單的單體應用所能夠承載的，隨之而來的是系統架構的不斷升級與演變。一般對於大型的To C的互聯網企業來説，整個系統都是構建於微服務的架構之上，原因是To C的業務有着天生的微服務化的訴求：需求迭代快、業務系統多、領域劃分多、鏈路調用關係複雜、容忍延遲低、故障傳播快。微服務化之後帶來的問題也很明顯：服務的管理複雜、鏈

性能監控 , aop , 字節碼

得物技術 - 亞毫秒 GC 暫停到底有多香？JDK17+ZGC 初體驗｜得物技術

1 前言 垃圾回收器的暫停問題一直是Java工程師關注的重點，特別是對實時響應要求較高的服務來説，CMS和G1等主流垃圾回收器的數十毫秒乃至上百毫秒的暫停時間相當致命。此外，調優門檻也相對較高，需要對垃圾回收器的內部機制有一定的瞭解，才能夠進行有效的調優。 為了解決此類問題，JDK 11開始推出了一種低延遲垃圾回收器ZGC。ZGC使用了一些新技術和優化算法，可以將GC暫停時間控制在10毫秒以

jdk17 , gc

得物技術 - 系統穩定性與高可用保障

一、前言 高併發、高可用、高性能被稱為互聯網三高架構，這三者都是工程師和架構師在系統架構設計中必須考慮的因素之一。今天我們就來聊一聊三H中的高可用，也是我們常説的系統穩定性。 \ 本篇文章只聊思路，沒有太多的深入細節。閲讀全文大概需要5~10分鐘。 二、高可用的定義 業界常用 N 個 9 來量化一個系統可用性程度，可以直接映射到網站正常運行時間的百分比上。 可用性的計算公式： 大部分公司的要求

運維 , 負載均衡 , 高可用 , 安全

得物技術 - 深入淺出解析JVM中的Safepoint ｜ 得物技術

1.初識Safepoint-GC中的Safepoint 最早接觸JVM中的安全點概念是在讀《深入理解Java虛擬機》那本書垃圾回收器章節的內容時。相信大部分人也一樣，都是通過這樣的方式第一次對安全點有了初步認識。不妨，先複習一下《深入理解Java虛擬機》書中安全點那一章節的內容。 書中是在講解垃圾收集器-垃圾收集算法的章節引入安全點的介紹，為了快速準確地完成GC Roots枚舉，避免為每條指令都生

jvm , jvm調優

得物技術 - 新一代異步IO框架 io_uring ｜ 得物技術

1.Linux IO 模型分類 相比於kernel bypass 模式需要結合具體的硬件支撐來講，native IO是日常工作中接觸到比較多的一種，其中同步IO在較長一段時間內被廣泛使用，通常我們接觸到的IO操作主要分為網絡IO和存儲IO。在大流量高併發的今天，提到網絡IO，很容易想到大名鼎鼎的epoll 以及reactor架構。但是epoll並不屬於異步IO的範疇。本質上是一個同步非阻塞的架構

JAVA , io , 後端

得物技術 - 社區收藏緩存設計重構實戰

一、背景 社區收藏業務是一個典型的讀多寫少的場景，社區各種核心Feeds流都需要依賴用户是否收藏的數據判斷，早期緩存設計時由於流量不是很大，未體現出明顯的問題，近期通過監控平台等相關手段發現了相關的一些問題，因此我們針對這些問題對緩存做了重構設計，以保障收藏業務的性能和穩定性。 二、問題分析定位 2.1 接口RT偏大 通過監控平台查看「判斷是否收藏接口」的RT在最高在8ms左右，該接口的主要作用是

性能優化 , 緩存 , 重構

得物技術 - 社區點贊業務緩存設計優化探索

背景 內容點贊業務在得物社區中是一個非常高頻的業務場景，功能本身複雜度不高，但是業務場景多、QPS高、而且由於社區的用户體量，整體點讚的數據量非常大。其中最核心、對響應性能要求最高的主要是“用户是否點贊內容”和“內容點贊數”場景。 在得物社區中凡是有內容消費的場景，都會有上面兩個點贊場景的處理，所以整體點贊業務的QPS在社區都是非常高的。當我們在刷各種Feed流時，每一次下滑，都需要對數十篇內容進

緩存 , 重構 , 後端 , 方案

得物技術 - “整潔架構”和商家前端的重構之路

1. 背景 團隊歸屬於後方業務支撐部門，組內的項目都以pc中後台應用為主。對比移動端應用，代碼庫比較龐大，業務邏輯也相對複雜。在持續的迭代過程中，我們發現當前的代碼倉庫仍然有不少可以優化的點： 可以減弱對ui框架的依賴 21年前端平台決定技術棧統一遷移到React生態，後續平台的基礎建設也都圍繞React展開，這就使得商家使用Vue生態做開發的系統面臨技術棧遷移的難題，將業務邏輯和UI框架節藕變得

重構 , 前端

得物技術 - 得物多活架構設計之路由服務設計

一 、背景 隨着公司的業務發展，每次穩定性故障帶來的影響越來越大，提供穩定的服務，保證系統的高可用已經變成了整個技術部面對的問題。基於這種背景，公司開展了多雲/多活的技術項目，本人有幸參與了 “次日達” 項目【1】的異地雙活改造方案的設計。想以此來淺談一下我對多活乃至全球化的一些技術方案的認知。 多活架構系列的文章我會按照總體技術方案、雙活/全球區域化部署技術、網絡調度技術、性能優化以及SRE五大

服務 , 架構設計 , 架構 , 架構模式 , 路由

得物技術 - 得物複雜 C 端項目的重構實踐

1. 背景 1.1 重構 Q：什麼是重構？ 重構是在不改變軟件可觀察行為的前提下，改善其內部結構。--《重構 - 改善既有代碼的設計》 Q：為什麼要重構？ 重構可以提高理解性和降低修改成本 。--《重構 - 改善既有代碼的設計》 Q：什麼時候重構？ （1）何時不應該重構？ 沒有價值，沒有意義或者投入產出比很低時。團隊資源是有限的，有限的資源應該儘可能投入到有意義的事情上去。從團隊的角度考慮投

項目 , 大前端 , 實踐 , 重構 , 前端

得物技術 - 看完這篇異地多活的改造，我決定和架構師battle一下｜得物技術

簡述 異地多活的概念以及為什麼要做異地多活這裏就不進行概述了。概念性的很多，像什麼同城雙活、兩地三中心、三地五中心等等概念。如果有對這些容災架構模式感興趣的可以閲讀下這篇文章進行了解：《淺談業務級災備的架構模式》。 閲讀本篇文章之前，我們先明確一下背景，這樣大家後續在看的時候就不會產生困惑。 1.1 機房劃分 得物多活改造一期目前有兩個機房，分別是機房A和機房B。文章中大部分圖中都會有標識，這就説

架構設計 , 客户端 , 架構 , 機房監控 , 架構模式

得物技術 - Module Federation在客服工單業務中的最佳實踐

Module Federation： 是模塊聯邦的意思，在webpack 5中流行起來的，也屬於一種微前端方案。 一、背景 1、客服高頻工作場景 一線客服： 基於一站式工作台中的在線工作台及電話工作台，根據用户進線反饋的問題，查看當前用户相關的工單詳情或訂單詳情，並根據實際情況決定是否創建新的工單。 二線客服： 根據各種渠道反饋的工單（其中一個主要來源是一線客服的反饋），根據工單內容，聯繫用户或

module , 業務 , 實踐 , 微前端 , 前端

得物技術 - 得物技術初探OpenResty

簡介 Nginx 的高性能是業界公認的，近年來在全球服務器市場上的佔比份額也在逐年增加，在國內知名互聯網公司也有廣泛的應用，阿里還基於Nginx進行擴展打造了著名的Tengine。而OpenResty是由國人章亦春基於Nginx和LuaJIT打造的動態web平台，LuaJIT是Lua編程語言的即時編譯器。Lua是一種強大、動態、輕量級的編程語言。該語言的設計目的是為了嵌入應用程序中，從而為應用程序

架構 , 性能 , openresty , Nginx , 後端

得物技術 - 得物技術在搭建會場下的頁面性能優化

得物App內h5的項目都是通過webview打開。對於webview的性能大家普遍的印象就是打開速度比native慢。 對於SPA應用，一個用户打開webveiw訪問h5需要經過如下過程： 點擊App入口（例如banner等） 到達新頁面，頁面白屏。 頁面基本框架出現（骨架屏），但是沒有數據，頁面處於loading狀態。 出現所有數據，頁面完全呈現。 從程序執行的角度，我們來看一個沒有

頁面佈局 , 性能 , 搭建 , 優化 , 前端

得物技術 - 得物技術談談App 需要什麼樣移動網關

目前大部分App後端還沒有統一的網關。其實不止是後端，移動端也是需要網關的。移動網關幫助我們解決穩定性、業務分級隔離、大促容量評估、異構系統支持等問題。移動網關本質是是，以可管控的方式暴露到外網去，這裏的關鍵是如何管控和暴露。從通訊協議上講移動網關是對外接收開放的通信協議，HTTP、gRPC等，一般還有協議轉換講HTTP轉換成內部的RPC協議。本文筆者將談談得物需要什麼樣的移動網關。 一、電商對網

移動端 , 電商 , 網絡 , 移動端適配 , 後端