動態

@alixitongruanjianjishu

基於 Spring AI Alibaba + Nacos 的分佈式 Multi-Agent 構建指南

作者:如漫、席翁 AI Agent 的構建模式正在從“單個智能體做所有事”走向“多個專精智能體協作”,以更好地拆解並解決複雜任務、更精準的選取和使用工具。A2A(Agent-to-Agent)協議作為統一的通信層,旨在為跨進程、跨語言的智能體互操作提供標準化語義與傳輸通道,從而解決智能體數量增加引起的運維、管理和部署成本過高等問題。 為了讓開發者能夠高效、便捷的構建分佈式多智能體系統,同時更專注於

alixitongruanjianjishu 頭像

@alixitongruanjianjishu

昵稱 阿里云云原生

@alixitongruanjianjishu

SOFA AI 網關基於 Higress 的落地實踐

作者:SOFA 社區 背景 網關作為重要的中間件,在傳統業務中扮演着流量治理、路由轉發、協議轉換、安全防護等功能。根據不同業務場景的定位,也會衍生出不同類型的網關,例如流量網關、ESB(企業服務總線)、API 網關、雲原生網關。從網關職責看,其本質所承擔的職責沒有太多變化,主要是針對不同業務場景下作更多的適配,更好地滿足業務使用。比如,API 網關則是針對微服務場景,將原有的管理粒度從粗粒度的流量

alixitongruanjianjishu 頭像

@alixitongruanjianjishu

昵稱 阿里云云原生

@baidujiagoushi

大規模微服務系統中的雪崩故障防治

導讀 在大規模微服務架構中,雪崩故障是極具破壞力卻又難以預防的系統性威脅。本文基於百度搜索架構與運維團隊的實戰經驗,深入解析雪崩從“非穩態”到“自強化崩潰”的微觀演化機制,揭示重試風暴、容量退化等正反饋迴路的形成過程。文章提出系統化的治理思路,並詳細介紹百度落地的多項核心實踐,包括重試預算、隊列限流、全局TTL控制等自愈機制,以及秒級流量調度與降級預案。通過真實案例與生產數據,為行業提供了一套可借

baidujiagoushi 頭像

@baidujiagoushi

昵稱 百度Geek説

@hnclou

華納雲:分佈式存儲提高數據安全性的原理分享

分佈式存儲通過多節點協同工作,將數據分散存放在多個物理位置,從而在架構設計上提升了數據的可靠性與安全性。它的核心思想是“分而治之,備而無患”。以下從原理角度詳細解析分佈式存儲如何提高數據安全性: 1. 數據冗餘機制:保障硬件故障下的數據可恢復 分佈式存儲系統普遍採用數據冗餘策略,例如: • 副本機制(Replication):同一份數據在多個節點上保存(常見為3副本),當某一個節

hnclou 頭像

@hnclou

昵稱 用户bPddcxP

@aijianshendexuegao

AI 時代, 需要什麼樣的數據底座?

作者:楊克特 ProtonBase 技術副總裁 畢業於浙江大學計算機系,獲碩士學位,具備 10 多年核心系統設計和研發經驗。曾任阿里巴巴資深技術專家,負責過搜索引擎、資源調度、實時監控等系統的設計和研發。具備豐富的開源經驗,是 Apache Flink 和 Apache Druid 的 PMC 成員,以及 Apache 軟件基金會成員。 概念科普:Data Warebase = Data Ware

aijianshendexuegao 頭像

@aijianshendexuegao

昵稱 Protonbase

@pingcap

PingCAP“一號員工”唐劉:回顧我與 TiDB 的十年成長之旅

導讀 作為 PingCAP 的“一號員工”,TiDB 研發副總裁唐劉親歷了 TiDB 從一個開源小項目到全球知名分佈式數據庫的蜕變。本文,唐劉從親歷者視角,回顧了 TiDB 的技術演進、產品迭代和全球化歷程,還分享了自己從程序員到技術管理者的成長與感悟。 這是一段關於技術理想、客户成功與團隊協作的旅程,也是一次對開源精神、創新勇氣和商業智慧的深度剖析。通過唐劉的視角,我們得以窺見 TiDB 背後的

pingcap 頭像

@pingcap

昵稱 PingCAP

@hnclou

華納雲:分佈式存儲如何提高數據安全性?

華納雲分佈式存儲通過多種技術和機制顯著提高了數據安全性,以下是其主要方式: 1、數據冗餘與備份 分佈式存儲將數據分散存儲在多個節點上,並通過冗餘備份機制確保數據的可靠性。例如,數據可以被分割成多個片段,並在不同節點上存儲多個副本。即使某個節點發生故障或數據丟失,其他節點上的副本仍可保證數據的完整性和可用性。 2、數據加密 數據在存儲和傳輸過程中均會進行加密處理。分佈式存儲系統通常採用強加密算法(如

hnclou 頭像

@hnclou

昵稱 用户bPddcxP

@xuxueli

XXL-MQ v1.4.0 | 輕量級分佈式消息隊列

Release Notes: 1、【重構】XXL-MQ 核心代碼重構,基於“存算分離”與“分區機制”設計思想。在輕量級、分佈式的基礎上,強化高吞吐、海量消息及水平擴展能力。; 2、【新增】存算分離:消息中心(Broker)與消息存儲層(Store)解耦。消息中心 提供消息OpenApi以及消息控制枱管理能力;消息存儲層 提供消息存儲能力。得益於存算分離系統設計,消息中心支持水平擴展,支持線性

xuxueli 頭像

@xuxueli

昵稱 xuxueli

@zengshenaiguodehuoche_d2oimj

SpringBoot中@Scheduled和Quartz的區別是什麼?分佈式定時任務框架選型實戰

今天為大家帶來的是@Scheduled和Quartz對比分析: 新手常見困惑: 剛學SpringBoot時,我發現用@Scheduled寫定時任務特別簡單。但當我看到同事在項目裏用Quartz時,代碼突然變得複雜起來——為什麼要用這些複雜的配置?難道註解不香嗎? 今天,我們就用最直白的方式,手把手對比這兩種方案。 1. 定位與設計目標 1.1. @Scheduled註解 輕量級單機調度:Spr

zengshenaiguodehuoche_d2oimj 頭像

@zengshenaiguodehuoche_d2oimj

昵稱 曾深愛過的火車_d2oImJ

@baidujiagoushi

BaikalDB 架構演進實錄:打造融合向量化與 MPP 的 HTAP 查詢引擎

導讀 BaikalDB作為服務百度商業產品的分佈式存儲系統,支撐了整個廣告庫海量物料的存儲和OLTP事務處理。隨着數據不斷增長,離線計算時效性和資源需求壓力突顯,基於同一份數據進行OLAP處理也更為經濟便捷,BaikalDB如何在OLTP系統內實現適合大數據分析場景的查詢引擎以應對挑戰? 01 BaikalDB應對OLAP場景的挑戰 BaikalDB是面向百度商業產品系統的需求而設計的分佈式存儲系

baidujiagoushi 頭像

@baidujiagoushi

昵稱 百度Geek説

@zhaoqianglaoshi

【趙渝強老師】基於PostgreSQL的分佈式數據庫:Citus

由於PostgreSQL具有強大的功能和良好的可擴展性,因此基於PostgreSQL很容易就可以實現分佈式架構。Citus便是具體的一種實現方式。它以擴展的插件形式與PostgreSQL進行集成,且獨立於PostgreSQL內核,部署也比較簡單。Citus是現在非常流行的基於PostgreSQL的分佈式解決方案。 一、 Citus基礎 下面是百度百科中對分佈式數據庫的定義: 分佈式數據庫系統通

zhaoqianglaoshi 頭像

@zhaoqianglaoshi

昵稱 趙渝強老師

@mirrorship

什麼是 MPP 數據庫?解鎖海量數據分析的關鍵技術

為什麼需要 MPP 數據庫? 在數據爆炸的時代,傳統數據庫處理 TB 甚至 PB 級數據時往往力不從心,查詢緩慢,無法支撐實時分析需求。這種情況下,MPP 數據庫成為解決大規模數據分析性能瓶頸的關鍵技術。 想象一下:一個電商平台在大促期間,原本穩定的系統突然卡死;一個數據彙總應用在處理全年數據時崩潰。這些都是我們在高併發、高吞吐量場景下常見的問題。為什麼會這樣?因為系統設計時沒有考慮極限情況下的數

mirrorship 頭像

@mirrorship

昵稱 鏡舟科技

@danxiaodezixingche

單機分佈式一體化數據庫的架構設計與優化

作者:楊志豐,OceanBase產品總經理、首席架構師 首先為大家推薦這個 OceanBase 開源負責人老紀的公眾號 “老紀的技術嘮嗑局”,會持續更新和 #數據庫、#AI、#技術架構 相關的各種技術內容。歡迎感興趣的朋友們關注! 本文摘自《OceanBase社區版在泛互場景的應用案例研究》,歡迎點擊鏈接閲讀詳細內容。 綜述 在OceanBase 十餘年的技術演進中,共經歷了三次大的架構升級

danxiaodezixingche 頭像

@danxiaodezixingche

昵稱 老紀的技術嘮嗑局

@gvison

三步搞定 Go 分佈式任務!sasynq 庫讓異步任務變得如此簡單

Go 後台任務的“坑”,你踩過幾個? 在 Go 應用開發中,總有一些任務不適合現場完成,比如: 發郵件/發短信:用户點擊按鈕後,還要乾等?體驗太糟糕! 大計算量任務:生成報表、數據分析,CPU 一直被佔,其他請求全卡住? 定時任務:凌晨跑統計、每小時同步數據,難道要寫個死循環 time.Sleep? 所以,聰明的我們會把這些任務扔進異步任務隊列,讓後台“工人”(Worker)慢慢處理。

gvison 頭像

@gvison

昵稱 gvison

@fiveyoboy

分佈式理論 CAP + Base

簡介 在分佈式系統的設計中,分佈式系統有三個指標 CAP,但是沒有一種設計可以同時滿足 CAP (一致性,可用性,分區容錯性 )3個特性,只能滿足其中 2 個 CAP 簡介 CAP 描述 C 一致性 Consistency,一致性 強調的是 分佈式系統中各個節點之間的數據一致性;不管訪問哪個節點,返回的數據都是一致的,否則節點不可用(拒絕服務

fiveyoboy 頭像

@fiveyoboy

昵稱 五歲小孩

@fiveyoboy

分佈式和微服務和集羣的含義及區別

分佈式系統 多個人做同一件事件 分佈式系統是指由多個相互獨立的計算機節點組成的系統,這些節點通過網絡協議進行通信和協作,共同完成一個或多個應用程序的任務。分佈式系統的優點在於它們可以提供更高的可用性、可伸縮性和可靠性,但同時也需要更多的複雜性和管理工作。 微服務 ==微服務是一種基於分佈式系統的架構模式==,它將一個大型應用程序拆分成多個較小的、自治的服務。這些服務可以獨立開發、測試、部署和擴展

fiveyoboy 頭像

@fiveyoboy

昵稱 五歲小孩

@xuxueli

XXL-JOB v3.2.0 | 分佈式任務調度平台

Release Notes 1、【強化】AI任務(ollamaJobHandler)優化:針對 “model” 模型配置信息,從執行器側文件類配置調整至調度中心“任務參數”動態配置,支持集成多模型、並結合任務動態配置切換。 2、【安全】登錄認證重構:密碼加密算法從Md5改為Sha256;登錄態改為登錄後動態隨機生成;提升系統安全性;(需要針對用户表進行字段調整,同時需要重新初始化密碼信

xuxueli 頭像

@xuxueli

昵稱 xuxueli

@elhix0bg

ODPS 十五週年實錄 | Data + AI,MaxCompute 下一個15年的新增長引擎

ODPS十五週年實錄|Data+AI,MaxCompute下一個15年的新增長引擎 本文根據ODPS十五週年·年度升級發佈實錄整理而成,演講信息如下: 於得水(得水):阿里雲智能集團計算平台事業部資深技術專家 活動:【數據進化·AI啓航】ODPS年度升級發佈 此次演講內容共分為三個部分: 第一部分,介紹MaxCompute面向Python和AI生態計算的演進歷史。從最初的SDKLibrary到表示

elhix0bg 頭像

@elhix0bg

昵稱 阿里雲大數據AI

@baidujiagoushi

BaikalDB MCP Server :鏈接數據庫和AI的直通橋

導讀 BaikalDB作為服務百度商業產品的分佈式存儲系統,支撐了整個廣告庫海量物料的存儲。在大語言模型LLM蓬勃發展的現在,想在大模型裏使用BaikalDB裏的數據進行分析,都需要複雜的定製開發。看BaikalDB如何藉助模型上下文協議(MCP),讓數據庫對話像聊天一樣簡單——無需編寫代碼,大語言模型即可完成複雜數據分析。 01 引言 在2025年以前,大語言模型(Large Language

baidujiagoushi 頭像

@baidujiagoushi

昵稱 百度Geek説

@fannaodeliushu

《微服務冪等性踩坑實錄:從資損到全鏈路零故障的7個關鍵突破》

去年電商平台“618”大促結束後的第三天,財務部門在進行訂單與支付流水對賬時,發現了一組異常數據:用户張先生的一筆2999元家電訂單,支付記錄顯示“成功扣款兩次”,但訂單系統中對應的物流單號僅有一個,且商品已發貨。財務同事第一時間將問題反饋到技術部,我們隨即成立應急小組,從支付回調日誌、訂單狀態變更記錄、數據庫操作日誌三個維度展開溯源。順着第三方支付平台的回調日誌查看,發現該筆訂單在大促高峯期(當

fannaodeliushu 頭像

@fannaodeliushu

昵稱 程序員阿偉

@gvison

從單兵作戰到兵團壓測:PerfTest 分佈式集羣壓測實戰

前言 在前一篇文章中,我們詳細介紹了 perftest 的單機壓測能力,展示了它如何通過極簡的命令行實現對 HTTP/1.1、HTTP/2、HTTP/3 與 WebSocket 的高性能測試。然而,當業務系統龐大、服務部署分佈式、網絡鏈路複雜時,單機的壓測能力顯然無法滿足真實生產環境的模擬需求。 幸運的是,perftest 不止於單機。它同樣支持 分佈式集羣壓測,通過 Collector + Ag

gvison 頭像

@gvison

昵稱 gvison

@lpc63szb

Spring Security入門學習

認識Spring Security Spring Security 是為基於 Spring 的應用程序提供聲明式安全保護的安全性框架。Spring Security 提供了完整的安全性解決方案,它能夠在 Web 請求級別和方法調用級別處理身份認證和授權。因為基於 Spring 框架,所以 Spring Security 充分利用了依賴注入(dependency injection, DI)和

lpc63szb 頭像

@lpc63szb

昵稱 運維社

@lpc63szb

JVM頻繁GC內存溢出排查

前言 GC(Garbage collection)頻繁和堆內存溢出原因簡單來説是對象佔用堆空間難以回收,新對象無法分配觸發GC或者直接導致內存溢出,最終進程結束。 排查思路是先查看進程各種類型對象佔用空間大小和比例,鎖定佔用空間較多的對象後再分析相關的程序是否有使用不當的地方。下文的側重點是通過多種方式查看堆內存分佈。 例子程序 先編譯(javac FrequentFull

lpc63szb 頭像

@lpc63szb

昵稱 運維社