我认为AI Native它不是一个功能,而是一种全新的思想范式,一套完整的方法论,一套全新的架构。我觉得,一个真正的AI原生应用,必须具备以下五个环环相扣的核心支柱: 支柱一:架构原生 这是地基。 AI原生应用不是在传统的软件架构上“打补丁”,而是从第一行代码开始,就为AI而生。 传统架构:是“以应用为中心”的。一个庞大的、一体化的应用,通过API去调用一下AI的“能力”。AI是个“外援”。 原生架构:是“以AI(大模型)为中心”的。整个系统被设计成一个由多个微服务、工具、数据源组成的网络,而大模型是这个网络的“大脑”和“调度中心”。 架构不原生,AI的智慧就永远被禁锢在传统软件的牢笼里,无法发挥应有的潜能。 支柱二:交互原生 这是体验。AI原生应彻底改变人与机器的协作方式: 传统交互(GUI):图形用户界面。 总结:从“工具”到“生命体” 现在,我们再回看“AI原生”,它的画像就清晰了: 它拥有一个为AI而生的“原生架构”,通过“原生交互”理解我们的意图,由自主的“Agent”去执行任务。
那些整整齐齐的"单体→分布式→SOA→微服务→云原生→AI原生"或者"单体-C/S分层→SOA→微服务→云→云原生/Serverless"的分段框架,都是后人总结实践经验形成的叙事框架,只是为了便于人脑记忆和理解 拥抱不确定性,才是软件架构的第一性原理。AI大模型的到来,把不确定性往前推了更大的一步。 AI时代的新挑战 现在谈AI原生架构,需要保持谦逊。 大模型已经来了,AI Agent、工作流编排、Skills仓库、AI网关、模型路由层……各种新概念和新组件在快速涌现。已经有人开始喊"AI Native架构",也有人在聊"AI云原生架构"。 这话在以前是对的,在AI时代也是对的。至于AI原生的定义,等到新一代架构涌现之后自有人来评说。马克·吐温有句话——"历史不会重复,但总是押韵。" 从单体到分布式,从SOA到微服务,从云原生到AI原生,每个历史阶段的问题不同,但架构理念相同:解耦、隔离、容错、拥抱不确定性,权衡、取舍、折中、解决当下的问题。
在QCon AI纽约2025大会上,Tracy Bannon发表演讲,探讨了AI代理的快速采用如何重塑软件系统,以及如果组织将所有“AI”或“代理”视为可互换的,为何会面临重复熟悉架构失败的风险。 “每个人都在谈论AI‘生产力’,却很少有人提及随之而来的架构健忘症。” —— Tracy Bannon为了具体说明,Bannon概述了一组在软件开发生命周期中常见的自主性模式。 她认为,AI并没有引入全新的故障模式,而是通过加速变化和扩大错误的波及范围,加剧了现有的问题。她重点阐述了将既定的架构原则应用于代理系统。 演讲最后呼吁架构师和高级工程师在引入AI代理的方式上发挥积极作用。 她的结束语是:软件架构的核心实践仍然有效,挑战不在于学习全新的学科。希望了解更多信息的开发者可以探索更多QCon AI会议和InfoQ的报道,大会的录播视频预计将于2026年1月15日开始提供。
那些整整齐齐的"单体→分布式→SOA→微服务→云原生→AI原生"或者"单体-C/S分层→SOA→微服务→云→云原生/Serverless"的分段框架,都是后人总结实践经验形成的叙事框架,只是为了便于人脑记忆和理解 拥抱不确定性,才是软件架构的第一性原理。AI大模型的到来,把不确定性往前推了更大的一步。AI时代的新挑战现在谈AI原生架构,需要保持谦逊。 大模型已经来了,AIAgent、工作流编排、Skills仓库、AI网关、模型路由层……各种新概念和新组件在快速涌现。已经有人开始喊"AINative架构",也有人在聊"AI云原生架构"。 这话在以前是对的,在AI时代也是对的。至于AI原生的定义,等到新一代架构涌现之后自有人来评说。马克·吐温有句话——"历史不会重复,但总是押韵。" 从单体到分布式,从SOA到微服务,从云原生到AI原生,每个历史阶段的问题不同,但架构理念相同:解耦、隔离、容错、拥抱不确定性,权衡、取舍、折中、解决当下的问题。
部署全栈AI原生引擎与安全运行时沙箱 为解决大模型应用中的系统稳定性与开发效率问题,腾讯云升级智算能力,构建了更贴近Agent的AI原生云软硬协同架构: Agent Infra(运行层构建): 专为大规模 同时,腾讯自研TACO Kit推理引擎覆盖生文、生图、生视频等多模态,实现多种模态推理加速 4倍(其中TACO-LLM推理效率提升 100~130%,TACO-DiT提升 122%)。 支撑实体产业与泛互联网核心业务系统 该套AI原生云基础设施已在多行业、多场景中得到大规模实际业务验证。 确立亚太区智算基石的权威认证优势 腾讯云在AI云基础设施领域的架构优化与技术确定性,获得了全球权威机构的量化认可。 在评估系统稳定性、产品技术创新力及市场执行力等维度后,腾讯云荣获 Gartner 评级亚太第一,并在 2024年沙利文(Frost Radar)中国AI基础架构市场综合竞争表现中位列创新指数国内第一,印证了其在
量化安全运营效能:AI驱动的检出率提升与决策自动化 通过开放腾讯云自身安全实践,“4+N”体系在实际应用中展现出高投资回报率(ROI),核心体现在以下三个量化的业务指标: 敏捷接入效率(Ops Cost 大幅降低): 依托腾讯云原生架构实现免部署、轻配置。 例如,某奶茶小程序业务原生接入小程序网关后,拦截4000万次攻击,平均请求耗时降低22%。 AI驱动的运营降本指标: 接入基于腾讯混元的AI安全模型,通过“云安全助手”简化40%的产品操作;在AI值守模式下,系统可自动完成>50%的安全决策。 原生接入4道防线,实现数据全生命周期(分类分级、加密、脱敏、审计)的管理,满足个人敏感信息防护等核心合规性标准要求。 一汽解放集团(车联网安全检测): 与腾讯共建网络安全测试实验室。
Llama 4:原生多模态,混合专家架构,超长上下文支持。 此外,Llama4系列还整合了文本、图像和视频的统一框架,使其具备原生多模态能力。 它采用了混合专家(MoE)架构,提高了训练和回答用户查询时的效率。 接下来将带你详细了解本次llama4模型的新特性。 技术背景 Llama4 是 Meta 于 今日发布的新一代开源大语言模型系列,标志着其在多模态 AI 领域的重要突破。 核心技术架构 混合专家(MoE,Mixture of Experts)架构 Llama4系列AI模型是Meta公司推出的最新产品,它采用了混合专家(MoE,Mixture of Experts)架构,这是一种在训练和回答用户查询时效率更高的架构 原生多模态融合 Llama 4采用了原生多模态设计,能够处理和整合各种类型的数据,包括文本、视频、图像和音频,并且可以在这些格式之间转换内容。
流式 BFF(Streaming Backend for Frontend) 是一种适用于 AI 原生架构的胶水层,旨在解决 HTTP API 与智能体协同过程中的数据流处理和接口不一致等问题。 而那篇《语言接口:探索大模型优先架构的新一代 API 设计》中,我们介绍了 自然语言即 DSL、实时文本流 DSL、本地函数动态代理等模式。这些模式为我们开发 AI 原生应用带来了新的思路。 流式 BFF:AI 原生架构下的协同模式 传统的 BFF 模式关注为特定的前端应用定制后端服务,以满足前端的特定需求。 定义流式 BFF 模式:流式 BFF(Streaming Backend for Frontend) 是一种适用于 AI 原生架构的胶水层,旨在解决 HTTP API 与智能体协同过程中的数据流处理和接口不一致等问题 总结 生成式 AI 原生架构要求我们重新审视传统后端模式。流式 BFF 为智能体接口不一致、与传统 API 不同步等问题提供了有效的解决方案。
2009年4月,VMware推出业界首款云操作系统VMware vSphere。 2015年,云原生刚推广时,Matt Stine在《迁移到云原生架构》一书中定义了符合云原生架构的几个特征 符合12因素应用(12 Factors Application) 面向微服务架构(Microservices ,使能应用开发者简单、高效地使用其提供的功能 云原生应用架构思考: 单体架构的局限性 单体架构的问题不在于不可拆分上,在于无法隔离和自治。 微服务独立性和敏捷性更好,架构持续演进更容易,更适合云原生应用 云原生架构模式: Serverless架构 Serverless (无服务器架构) 指的是由开发者实现的服务端逻辑运行在无状态的计算容器中 华为云长期投入云原生技术与产业,是全球云原生领域领导者 华为云基于擎天架构 云原生基础设施:在云原生基础设施方面,华为云基于擎天架构实现了基于应用SLA来灵活调度算力,根据应用IO的不同,动态分配网络带宽
接下来这几篇我们就一起看一下关于iOS系统架构以及独立做一个APP的架构设计的相关问题。 iOS系统架构 iOS系统架构如下所示: 具体哪一层包含什么框架如下所示: 下面看一下详细的信息: 1. 4. 核心操作系统层(Core OS) 包含大多数低级别接近硬件的功能,它所包含的框架常常被其它框架所使用。Accelerate框架包含数字信号,线性代数,图像处理的接口。 参考文章 1. iOS系统架构和常用框架 2. iOS系统架构 后记 本篇主要讲述了iOS系统的架构,感兴趣的给个赞或者关注,谢谢~~~
架构定位与核心理念 1.1 系统本质 本架构描述的系统不是一个"加了 AI 功能的传统 CRUD 应用",而是一套以本体模型为核心驱动力、以 AI 大模型为生成引擎和运行时智能引擎的 AI 原生应用架构 五、SSE 流式输出架构 AI 对话必须支持流式输出,这是 AI 原生应用用户体验的基本要求。 这套架构既适合当前的合同管理场景,也适合作为后续更多业务域扩展的通用 AI 原生应用底座。当一个新的业务域需要接入时,只需提供对应的本体 YAML,整个技术栈可以直接复用。 后续为此增加了运行时知识注册表,把 M1/M2/M3/M4/ME 模型、原始需求文档、技术架构文档统一整理成知识条目;同时新增 ontology_knowledge_query 工具,让 AI 可以围绕流程 本文档版本 1.0 | 基于合同管理 AI 原生应用技术架构设计文档 | 2026 年 4 月
2025年,不会设计AI原生架构的程序员,就像2015年不懂微服务一样。 最近一个猎头朋友问我:"现在招聘架构师,JD里不写懂AI都不好意思发。你们搞技术的,AI到底改变了什么?" 那一刻我意识到:把AI当工具用,和为AI设计架构,是完全不同的两件事。 二、范式转移:从AI增强到AI原生 2024到2025年,业界正在经历一个关键转折点。 预测:到2026年,超过80%的企业将采用AI原生架构模式。 三、AI原生架构的5个核心设计原则 1. 延迟不是bug,是架构问题 大模型调用动辄几秒,传统同步架构直接崩溃。 执行反馈:结果评估和自我修正 4.
一、云原生架构内涵 云原生架构 基于云原生技术,指将 云应用中的非业务代码部分进行最大化的剥离,让 云设施接管项目中大量非功能特性(如弹性、韧性、安全、可观测性和灰度等)。 云原生包含:业务代码、三方软件 和 处理非功能特性的代码。把这些交给IaaS和PaaS完成。 二、主要架构模式 1、服务化架构模式:典型的 微服务和小服务。 4、存储计算分离模式:在云环境中,把各类暂态数据(如:session)给云服务保存。 5、分布式事务模式:访问多个微服务,必然带来分布式事务问题。 4)微服务分布式约束:故障发现时效性和精确开发维护人员核心述求。 无服务器技术(Server less)因为屏蔽了服务器的各种运维难度。有以下特点: 1、全托管的计算服务。 2、通用性。 4、按量计费。 函数计算(FasS)最具有代表性的产品。把应用逻辑拆分为多个函数,每个函数通过事件方式触发。 无服务器主要关注:计算资源弹性调度、负载均衡和流控、安全性。
推荐序一 云原生与传统云计算最大的区别在于,传统云计算关注的是如何提供性价比最高的计算、存储、网络资源,而云原生关注的是 如何让产品能够支持快速验证业务模式 如何简化复杂的开发流程、提升研发效率 如何保障产品的高可用性让业务无需承受成长之痛 互联网系统架构的挑战 1.1 云应用架构技术发展 简单的云主机创建也不太能满足业务的需求,后续还有大量的运维和运营工作,运维操作频率基本占比在90%以上,尤其在业务本身不断发展并且规模不断扩大的时候会更加明显 ,矛盾也会越来越突出 1.2 云平台下架构的不同点 云应用架构设计意味着更快的迭代速度、持续可用的服务、弹性扩容及一些非功能需求,包括追求产品创新时间的技术挑战、以用户体验为中心的挑战和移动互联网时代的突发性挑战 ,保证资源的占用自动缩容,以减轻业务部门的成本支出;对于非核心的业务,启用避开峰值的方式来实现在线或离线业务的计算,尽可能实现云计算最大利用率,也就是常说的用好“云”,发挥云计算的最大价值 1.3 云原生应用架构 采用基于云原生的技术和管理方法,可以更好地把业务生于“云”或迁移到云平台,从而享受“云”的高效和持续的服务能力 目前业界公认的云原生主要包括以下几个层面的内容 敏捷基础设施 开发人员可以随时拉取一套基础设施来服务于开发
3)如何决定微服务架构的拆分粒度 微服务架构中的“微”字,并不代表足够小,应该解释为合适。 4)单体架构 VS 微服务架构对比 ? 流行的微服务框架:spring-cloud/dubbo。 2. 无论是云原生开发人员还是传统开发人员,选择在本地服务器上运行代码的比例都相同。这表明,尽管云原生开发人员已经掌握了云的灵活性,但他们并未放弃本地服务器。 4. 4)趋势四:动态、混合、分布式的云环境将成为新常态 上云已是大势所趋,但对于企业而言,有些业务出于对数据主权、安全隐私的考量,会采用混合云架构。 由于 x86 处理器的性能越来越难以提升,而在 AI 等对算力要求极高的场景,GPU、FPGA、TPU(Tensor Processing Units)等架构处理器的计算效率更具优势。 4.
前言: 从技术的角度,云原生架构是基于云原生技术的一组架构原则和设计模式的集合,旨在将云应用中非业务代码的部分进行最大化的剥离,从而让云设施接管应用中原有的大量非功能特性(如弹性、韧性、安全、可观测性 云原生相比传统架构进了一大步,从业务代码中剥离了大量非功能性特性(不会是所有,比如易用性还不能进行剥离)到lassh和paas中,从而减少了业务代码开发人员的技术关注范围,通过云厂商的专业性提示了应用的非功能性能力 此外具备云原生架构的应用,可以最大化利用云服务和提升软件交付的能力,进一步的加快软件的开发。 1. 代码结构发生巨大大变化:云原生架构最有影响力的就是让开发人员的编程模型发生 巨大的变化。
核心定义云原生计算基金会(CNCF)对云原生的定义:云原生技术使组织能够在公有云、私有云和混合云等现代动态环境中构建和运行可扩展的应用程序。 ArgoCD、Spinnaker三、云原生设计原则1.微服务化展开代码语言:TXTAI代码解释传统架构:单体应用→微服务架构好处:独立部署、技术多样、快速迭代2.容器化部署展开代码语言:DockerfileAI :重建镜像,快速替换4.服务网格展开代码语言:TXTAI代码解释服务网格(如Istio)提供:-流量管理-安全通信-可观测性-策略控制四、12-Factor应用原则云原生应用应遵循12-Factor方法论 应用作为无状态进程运行端口绑定-通过端口绑定导出服务并发-通过进程模型扩展易处理-快速启动和优雅停止开发/生产平等-开发、预发布、生产环境尽量一致日志-把日志当作事件流管理进程-将管理任务当作一次性进程五、云原生架构模式 1.零信任架构展开代码语言:TXTAI代码解释传统:边界安全零信任:永不信任,始终验证2.容器安全展开代码语言:YAMLAI代码解释#Pod安全策略示例apiVersion:policy/v1beta1kind
大家好,我是人月聊IT,进行继续分享本体模型驱动的AI原生应用架构设计方面的内容。 本体驱动架构(Ontology-Driven Architecture)提出了一种基于本体+AI大模型驱动的AI原生应用构建解决方案。 4. 应用分层-职责解耦与语义对齐 为了保障系统的稳定性与可扩展性,应用架构采用了严格的分层模型。每一层都通过明确定义的接口与上下层通信,确保本体定义的语义在传递过程中不发生衰减。 大语言模型(LLM)的集成 本架构在设计之初就考虑到了 AI 技术栈的快速迭代。因此,系统通过抽象接口层实现了对不同规模、不同部署方式模型的高度兼容。 结论:语义一致的应用架构 本体驱动的 AI 原生架构不仅是对开发工具的改进,更是对软件生命周期管理的重新定义。
这个周末刚好看到武艳军老师微信公众号分享的一篇文章,谈企业架构4A架构中再增加一个AI架构是极其不合理的。 当然对于4A架构的集成和协同,我在前面专门写过文章。 企业架构规划设计-4A架构之间的关系和集成 我们常说的4A架构就是业务架构、数据架构、应用架构和技术架构,其实去理解4A架构的集成核心,你仍然要去参考企业架构这本书里面谈到的企业架构元模型。 而是想简单谈下在AI和大模型时代,对我们传统的企业架构和4A架构规划,究竟带来了哪些变化? 智能化-模型驱动 到了AI和大模型阶段,那么变成了模型驱动,但是并不是说在传统的4A架构上面增加了一个新的AI架构。AI架构的内容本身应该拆分到已有的4A架构里面。
一、技术架构设计原则基于行业验证的实践表明,高效科研教学基座需满足以下技术要求: 环境隔离性 • 采用Docker容器封装不同版本的Python包(如TensorFlow 1.x/2.x) 集群与公有云算力动态调配 • 调度算法:采用DRF(Dominant Resource Fairness)算法实现多维度资源调度,任务排队时间减少58% 工具可扩展性 • 通过Helm Chart规范AI 大模型服务化架构 基于Triton Inference Server的多模型部署方案: graph TD A[客户端请求] --> B{路由网关} B --> C[DeepSeek-7B 分布式训练加速 采用Horovod框架优化ResNet-50训练: horovodrun -np 8 -H gpu01:4,gpu02:4 \python train.py --batch-size 调度机制:基于优先级队列的抢占式调度算法,任务平均等待时间缩短70% • 能效管理:DVFS调频技术使TCO降低18%(年均节电34万kWh) • 服务可用性:达成99.98% SLA,MTTR<4分钟四