- 综合排序
- 最热优先
- 最新优先
- 来自专栏架构之家
大型复杂系统的架构设计思考
1、 大型系统和简单系统设计有什么区别？ 2、 大型系统设计不就是分布式设计吗？ 3、 如何进行大型系统设计？ 二、大型系统与简单系统设计的区别 从系统的简易程度可以将系统分为复杂系统或简单系统。 我们这里成复杂系统为大型系统，大型系统是复杂系统，一般是指规模大、复杂度高的系统。而简单系统是指规模小，复杂度也不高的系统，一般是单体，也可能是分布式架构的简单系统。 简单的对比如下： 对比项/对比类型 大型系统 简单系统 系统类型 分布式系统 一般是单体系统 业务复杂度 复杂 简单 规模复杂度 复杂 简单 技术复杂度 复杂 简单 资源投入 多 少 跨部门系统 是 否 四、如何进行大型系统设计 面对复杂问题，一般采用“分而治之”的思想，将大问题分解为小问题，解决掉小问题，大问题自然迎刃而解。对于系统设计来说，就是将系统拆分到适当的粒度，再组合的过程。 4.1 大型系统的设计步骤 大型复杂系统的设计不是一开始就进行架构设计，核心也不完全是分布式技术架构。而是要从业务开始，进行逐步设计的过程。
1.2K20编辑于 2022-07-12 多智能体系统设计：5种编排模式解决复杂AI任务
编排本质上是设计智能体间的通信协议、工作流程和决策机制，使整个系统能够处理故障、协同工作，完成单一智能体无法胜任的复杂任务。我们这里分析5种主流的智能体编排模式，每种都有其适用场景和技术特点。 这种模式在处理大数据量、计算密集型任务时表现出色，但需要精心设计任务分解策略，确保子任务的独立性和结果的可合并性。 迭代次数和退出条件的设计直接影响系统效率和最终质量的平衡。总结大模型能力的快速提升正在改变编排架构的必要性。 GPT-5等新一代模型展现出强大的上下文理解和多任务处理能力，单一模型通过精心设计的提示就能完成以前需要多智能体协作的任务。但在处理逻辑复杂、需要专业化分工的场景中，智能体编排仍然具有不可替代的价值。 关键是要根据具体应用场景选择合适的编排模式，在系统复杂度和实际效果之间找到最优平衡点
74200编辑于 2025-09-01- 来自专栏肉眼品世界
系统设计之降低复杂性
三、复杂性的原因 复杂性是由两件事引起的：依赖性和模糊性。 1、依赖关系 依赖关系是软件的基本组成部分，不能完全消除。实际上，我们在软件设计过程中有意引入了依赖性。 战略设计的主要目标必须是制作出出色的设计，考虑后续的可维护性及扩展性。 战略性编程需要一种投资心态。尽管前提投入会比战术编程花费更多的时间，但随着系统的迭代，战略编程的优势就开始逐渐显现。 当然既然是投资，就要考虑投入产出比，不应该吹毛求疵，只要发现一点不合理的地方就整体大重构。推荐的方式小步快跑的方式，在日常开发中留出5%-10%的时间来做战略设计。 2、模块的设计 开发一个新模块，如果有不可避免的复杂性。两种设计思路哪个更好：1、应该让模块用户处理复杂性，2、应该在模块内部处理复杂性？ 模块是设计应该是深的，最好的模块是那些其接口比其实现简单得多的模块。这样的模块具有两个优点。1、一个简单的接口可以将模块强加于系统其余部分的复杂性降至最低。
1K40发布于 2021-01-06 - 来自专栏Tom弹架构
使用桥接模式设计复杂的消息系统
本文节选自《设计模式就该这样学》 举个例子，我们在平时办公的时候经常通过邮件消息、短信消息或者系统内消息与同事进行沟通。尤其在走一些审批流程的时候，我们需要记录这些过程以备查。 根据类型来划分，消息可以分为邮件消息、短信消息和系统内消息。但是，根据紧急程度来划分，消息可以分为普通消息、加急消息和特急消息。显然，整个消息系统可以划分为两个维度，如下图所示。 [file] 如果我们用继承，则情况就复杂了，而且也不利于扩展。邮件消息可以是普通的，也可以是加急的；短信消息可以是普通的，也可以是加急的。下面我们用桥接模式来解决这个问题。 /** * 实现消息发送的统一接口 */ public interface IMessage { //要发送的消息的内容和接收人 void send(String message, 关注微信公众号『 Tom弹架构 』回复“设计模式”可获取完整源码。 【推荐】Tom弹架构：30个设计模式真实案例（附源码），挑战年薪60W不是梦 本文为“Tom弹架构”原创，转载请注明出处。
90530发布于 2021-11-08 - 来自专栏Tom弹架构
使用桥接模式设计复杂的消息系统
本文节选自《设计模式就该这样学》 举个例子，我们在平时办公的时候经常通过邮件消息、短信消息或者系统内消息与同事进行沟通。尤其在走一些审批流程的时候，我们需要记录这些过程以备查。 根据类型来划分，消息可以分为邮件消息、短信消息和系统内消息。但是，根据紧急程度来划分，消息可以分为普通消息、加急消息和特急消息。显然，整个消息系统可以划分为两个维度，如下图所示。 如果我们用继承，则情况就复杂了，而且也不利于扩展。邮件消息可以是普通的，也可以是加急的；短信消息可以是普通的，也可以是加急的。下面我们用桥接模式来解决这个问题。 /** * 实现消息发送的统一接口 */ public interface IMessage { //要发送的消息的内容和接收人 void send(String message, public Object watch(String messageId) { //根据给出的消息编码（messageId）查询消息的处理状态 //组织成监控的处理状态
73420编辑于 2021-12-21 - 来自专栏物流IT圈
通用设计：指挥调度系统——复杂行动的大脑与神经
应用场景 该系统的应用场景多出现在：需要多维时空信息用于决策；多人参与；人员动作需及时根据态势进行调整。如火灾、地震、海啸救援，危爆品事件处理，海上营救，群体事件处理等复杂场景。 设计目的 主要用于重大事件行动、复杂情况处置等情景的推演及调度，包括训练情境及实际指挥情境。运用信息化手段辅助组织实施和控制演练，为行动方法研究、行动方案预案推演提供手段。 （4）采用实时通信架构建立系统的通信支撑平台，可扩展接入其他的外部系统。 （5）具备指挥调度功能，包括指令的下发、任务进程及状态监控、任务执行情况反馈上报等功能。 5. （5） 参训指挥机构通过显示系统获取当前行动态势，结合辅助指挥系统进行行动指挥。 （6） 行动指挥作业系统将行动操作命令转换为规范化的指挥文书或指令。
1.4K30发布于 2020-07-16 软件设计的哲学-软件系统的复杂性问题
今天继续和大家推荐和导读《软件设计哲学》这本经典书籍。 这本书深入探讨了如何通过高内聚低耦合、分层抽象等设计方法有效降低软件系统的复杂性，适合所有软件开发人员阅读。 核心要点 软件系统的复杂性主要由依赖性和模糊性引起，其中依赖性问题更难解决。 模块设计应追求深度，即隐藏内部复杂性，对外暴露简单接口，尤其是通用模块。 在导读之前，我想先说明这本书的受众群体。根据我的阅读体验，这本书适合所有从事软件开发的人员阅读，无论是编码工程师还是系统设计师，都能从中获得启发。 本书的核心主题是探讨软件系统的复杂性问题。 若拆分过于粗略，则难以应对系统的复杂性；若拆分过于细致，模块间的集成和依赖又会加剧这种复杂性。因此，这成为一个两难的问题，解决起来颇具挑战性。 在概述复杂性之后，本书正式进入软件设计哲学的内容。 软件复杂性=业务*技术*治理 基于这两本经典书籍对软件系统复杂性的分析和阐述，我个人的理解是，我们应该从三个重要维度去理解软件系统的复杂性：业务复杂性、技术复杂性、上线以后的管控治理复杂性。
22210编辑于 2025-11-17- 来自专栏野生AI架构师
复杂场景下的用户与权限系统的设计思考与实践
最近参与一个项目的架构设计，及提供技术指导，发现其用户体系相当复杂，之前自己的设计显然想简单了。其大概的要点如下： 1. 图片来自文章 之前的设计及实施的偏差 之前的设计其实是一个比较通用的方案，设计要点： 所有用户的公共基础信息都在一个用户表里，由一个uid进行标识，不同用户类型的信息存储到扩展表上； 由统一的部门树来组织用户 低估的复杂性 之前设计的时候，有些问题考虑是不够的： 开始时漏考虑了一个角色：普通微信用户。 复杂性在于后续该用户可以和学生进行绑定，这时他的角色就可能会转换成学生或者家长等，可能需要对账号进行合并，因为原来学生的账号本来就是预先生成在系统中的，如果是家长则需要对账号类似进行转换。 问题产生的原因与教训 开发与架构设计沟通不够：这个可能是主要原因，架构在前面很难把所有细节都考虑到，特别是系统比较复杂的时候，这时舒畅的沟通机制就很重要，特别是跨团队的时候，有周例会对齐认知很重要；
57410编辑于 2023-08-26 - 来自专栏后端技术
系统设计与分析 作业5
数据库建模(E-R 模型) 按 Task 3 要求，给出系统的 E-R 模型（数据逻辑模型） 建模工具 PowerDesigner（简称PD） 或开源工具 OpenSystemArchitect 不负责的链接 http://www.cnblogs.com/mcgrady/archive/2013/05/25/3098588.html 导出 Mysql 物理数据库的脚本 简单叙说 数据库逻辑模型 与 领域模型 Location` () ON DELETE NO ACTION ON UPDATE NO ACTION) ENGINE = InnoDB DEFAULT CHARACTER SET = big5; 数据库逻辑模型 与 领域模型 的异同 相同点：两者都是抽象概念，都将业务的各概念，关系等抽象化，并用图表示出来，将需求抽象为可视化的概念关系。 不同点：领域模型不需要考虑太多的实现细节，更注重的是表达实体以及其之间的关系，还引进了中介实体的概念而数据库逻辑模型则是对领域模型的进一步细化，需要给出每个字段的具体细节，并用于生成代码。
51320发布于 2019-05-25 - 来自专栏magicodes
EXT.NET复杂布局（四）——系统首页设计（下）
首页JS函数介绍 使然使用了Ext.NET，但是JavaScript的地位还是举足轻重的。 值得注意的是Center面板：
<ext:TabPanel runat 在这里，我在工作台也添加了一个弹出窗口的JS函数，这么做的原因是，从这里打开窗口处理完事项，我可以刷新工作台的数据，甚至是指定的面板的数据，也就是在beforedestroy事件中，reload相应的store 至于其他的代码，我就不多介绍了，篇幅有限，精力有限。 工作台的代码，其他篇幅有部分介绍，可以参考EXT.NET复杂布局（一）——工作台。 ; 关于表单的一些介绍，请看EXT.NET复杂布局（三）——复杂表单布局。 尾声 从使用EXT.NET到现在，也差不多一年了，真正使用的时间也只有几个月而已。现在回想起来，还是感慨良多。 2.3K20发布于 2018-12-27 - 来自专栏magicodes
EXT.NET复杂布局（四）——系统首页设计（上）
很久没有发帖了，很是惭愧，因此给各位使用EXT.NET的朋友献上一份礼物。 本篇主要讲述页面设计与效果，下篇将讲述编码并提供源码下载。 系统首页设计往往是个难点，因为往往要考虑以下因素： 重要通知 系统功能菜单 快捷操作 日常维护工作（比如待办事项、已办事项等等） 用户信息（比如公司、部门、组织机构） 系统信息（意见反馈、帮助等） 联系沟通 等等 又要兼顾美观得体（丑了客户不愿意用，更别说钱了），方便实用，怎么从有限的空间里显示更多的功能（阵地战），往往弄得抓耳搔头，大费脑细胞。 下面就给出我的方案。 页面效果 我申明下，我不是专业的前端工程师，我就是一打杂的（啥都搞下），所以不要期望过高，如果还过得去，请点推荐。不多说了，上图： ? ? 顶部面包和右侧面板没啥好说的。接下来就说说功能吧。 左侧面板 左侧面板其实是相当重要的一块，在平常系统设计中，往往把功能菜单放在左侧。这里类似。不仅支持分组折叠，还支持无限极子菜单，美观而灵活。 ?
1.2K30发布于 2018-12-27 Go 的语言设计天然不适合复杂业务系统抽象
复杂业务系统（高变更频率、跨团队协作、强治理约束、复杂业务逻辑）里，Go 往往会把一部分“架构表达”的成本转移到工程约定与组织治理上。 Go 在基础设施领域是一门非常有竞争力的语言。 当你需要 Clean Architecture、DDD、Hexagonal、AOP、IoC 这类方法论来治理复杂系统时，Go 的克制设计通常会让这些方法论更依赖约定与工具链，从而把成本更多推到团队与流程上 一个“系统抽象能力强的语言”能让这些概念落在代码里，而不是停留在文档里。 Go 的设计目标与架构表达的取舍 Go 的核心设计原则是简单、清晰、显式与快速编译。 结构信息密度很高，但代价是更陡峭的学习曲线与更复杂的类型设计，需要强工程能力来驾驭。 例如一个日志采集系统与一个复杂的反欺诈系统面对的工程难题完全不同。 前者关注性能与可维护性，后者关注规则可演进与架构可治理。
16910编辑于 2026-01-29- 来自专栏ThoughtWorks
为复杂混沌的微服务生产环境设计韧性系统
面对复杂混沌的生产环境，应该本着“不信有好事”的原则来进行“明哲保身”式的软件设计，并在生产环境中利用混沌猴以及在办公区进行僵尸来袭模拟的混沌工程实践，来持续地主动揭示系统弱点，并加以改进，以提高系统韧性 5个月前的一个下午，正在客户现场的我，从微信群里得知了这一消息。 阿里云在那天，至少挂半小时。 对于阿里云这样复杂的系统，挂了的风险不可避免。 对于任何复杂的系统，失误必然会发生，只是敬畏还不够。因为—— 复杂和混沌的系统无法预测 科幻作家刘慈欣所创作的《三体》，受到了下面三体问题的启发。 英国咨询师斯诺登用他所创造的“栖息地”框架，把世间的问题分为5种： 明显的问题 繁杂的问题 复杂的问题 混沌的问题 紊乱的问题 明显的问题，其中的约束少而线性，就如同两人玩“石头、剪子、布”那样。 针对复杂和混沌的微服务生产环境，我们可以使用下面的方法来设计系统韧性。 识别问题种类。使用“栖息地”框架来确定生产环境属于哪种问题。
94320发布于 2019-09-16 - 来自专栏图南科技
复杂系统的产品设计与开发
有一天我在逛知识星球的时候，看有人推荐《系统架构 复杂系统的设计与开发》，于是买了实体书，读完后感觉很有价值。 抽象，复杂，难以理解的同时，呈现出来的是一套高屋建瓴的方法论。 在产品设想，原型设计，系统架构的时候，首先我们想到的是产品要满足什么样的功能需求。 其次以什么样形式展现给用户，再者就是这样的形式存在什么样的关系和结构。 像小程序，网站，H5 界面这些都是系统形式，在线和购物，居家团购就是系统功能。 形式强调存在性 每个系统都可以作为形式来出售，形式通过表现出来的功能而体现价值。 系统的功能需要对外展示，也就是说，系统的一条重要原则：功能与价值总是体现在系统边界处。 翻译过来，只有在跨界输出时，才能体现出最大价值。像 设计团队，只有在交付设计方案时，才能体现出价值。 ，它们是我们分析系统的重要角度； 这篇文章分享的关键词是 系统，功能，形式，涌现和复杂度信息歧义。
76830编辑于 2022-04-15 - 来自专栏架构精进之路
解构复杂业务系统：架构设计的核心逻辑与实践
一、什么是复杂系统 我们经常提到复杂系统，那么到底什么是复杂系统。我们看下维基的定义：复杂系统（英语：complex system），又称复合系统，是指由许多可能相互作用的组成成分所组成的系统。 八、复杂系统的架构特点 1.重视功能拆解，模块化设计，原子化设计 复杂系统一定要进行细致功能、模块、领域的划分。每个模块的都应该有明确，单一的职责。 我们知道复杂系统必然存在的纷繁复杂的依赖，依赖不可能存在于视图部分，肯定会表现为接口的依赖。对于复杂系统，我们要强迫我们转换思维，强迫我们面向接口进行设计。 5.大数据架构 当今的是一个数字化的时代，各行各业都在忙于进行数字化的转型。对于复杂的业务系统，数据的价值尤显突出，那么自然对于海量数据的处理、价值的挖掘诉求是必然存在的。 复杂系统的架构设计不是一蹴而就的，合适的才是正确的。希望本文能够对您在进行复杂系统设计时有一定的参考意义。
41120编辑于 2025-11-12 - 来自专栏运维开发王义杰
UML vs SysML：哪个更适合复杂系统架构设计？
引言 在面对一个由多个软件和中间件组成的复杂系统时，传统的UML（统一建模语言）可能显得有些局限。这时，我们可能会想，是否有更适合的建模工具或方法？SysML（系统建模语言）是一个可能的选项。 在这篇文章中，我们将探讨UML和SysML在处理这种复杂系统时的优缺点。 UML：软件建模的标准 UML是业界广泛接受的用于软件建模的标准。 SysML：系统建模的解决方案 SysML是一种扩展自UML的建模语言，专为复杂的系统（包括软件、硬件、人员、设备等）设计。它提供了一些额外的图示元素和建模范例，专门用于处理系统级的问题。 因此，在做出选择时，以下几点值得考虑： 需求复杂性：如果你的系统涉及多个软件、硬件和其他资源的复杂交互，SysML可能更合适。 总结 当我们面对一个由多个软件和中间件组成的复杂系统时，传统的UML可能不再足够。SysML提供了一种更全面的建模方法，特别是在需要系统级视角和全面需求分析的场景下。
2.1K20编辑于 2023-09-19 - 来自专栏EdisonTalk
5分钟了解系统架构设计（5）
最近梳理了之前学习的架构设计相关的一些课程学习总结，将其整理成了一个大纲脑图，以每篇5分钟系列展现出来，希望对你有所帮助。 如何设计一个高性能的系统架构，这是面试中一般常见的问题，明白回答该类问题的套路可以帮助我们理清思路。 本篇会聚焦high-level的思路，实际场景中还需要根据实际条件约束综合考虑。 综述，对于系统设计者而言，要清楚系统有所能，也有所不能。 此外，在压测阶段，可以通过绘制吞吐量和延迟的曲线，找到最佳性能点，进而在超过最佳性能点时做限流。 具体保护系统的措施包括：系统限流，即通过流量控制来保证系统的稳定性，当实际并发压力超过系统性能设计指标时，就拒绝新的请求连接，让用户进行排队。 通过上述的思路，我们大概可以了解在回答高性能系统的设计思路时，应该有的基本套路。 5、事后排查 当然，即使我们事前考虑的再多，也仍然会存在延迟和吞吐量的问题。
48320编辑于 2023-03-06 - 来自专栏明明如月的技术专栏
理解复杂系统的关键：耐心
理解复杂系统的关键：耐心 复杂系统本质上是多面的、复杂的。它们通常并非被设计成一瞬间就能理解的。这对于自然发生的系统，如生态系统，和人类设计的系统，如高级软件或机械，都是适用的。 这些系统是由多个组件混合而成，每个组件都有其独特的属性和角色。要理解整个系统，理解每个组件及其相互作用是至关重要的。这个过程需要时间，因此，需要相当程度的耐心。 理解复杂系统的关键就是耐心。 其次，复杂性常常伴随着不可预测性。在复杂系统中，微小的调整或变化可能会由于组件的相互连接性而导致无法预见的后果。这种特性，通常被称为"涌现行为"（系统的复杂性超过其各部分的总和），需要耐心和观察力。 草率的结论或行动很容易导致对系统真实行为的误解或误读。 耐心的路线图 那么，如何培养这个关键的技能呢？培养耐心需要改变思维方式，并有意识地接受学习的旅程。 接受复杂性：第一步是接受系统的固有复杂性。 总的来说，耐心在理解复杂系统的过程中，不仅是一种美德，更是一种基本的技能。它需要有意识的培养和实践，但会带来深度理解和掌握的丰富回报。
30820编辑于 2023-08-02 - 来自专栏全栈前端精选
组件库设计实战 - 复杂组件设计
这里我们提出一个组件复杂度的概念，一个组件复杂度的主要来源就是其自身的状态，即组件自身需要维护多少个不依赖于外部输入的状态。 最简单的轮播组件 抛去所有复杂的功能，轮播组件的实质，实际上就是在一个固定区域实现不同元素之间的切换。 至此，组件库设计实战系列文章也将告一段落。 在全部四篇文章中，我们分别讨论了组件库架构，组件分类，文档组织，国际化以及复杂组件设计这几个核心的话题，因笔者能力所限，其中自然有许多不足之处，烦请各位谅解。 组件库作为提升前端团队工作效率的重中之重，花再多时间去研究它都不为过。再加上与设计团队对接，形成设计语言，与后端团队对接，统一数据结构，组件库也可以说是前端工程师在拓展自身工作领域上的必经之路。
1.2K10发布于 2019-09-29 - 来自专栏图南科技
读完《系统架构，复杂系统的产品设计与研发》记住这三个词
这篇文章是《系统架构，复杂系统的产品设计与研发》第二部分。 本文主要围绕 概念，需求与目标三个词展开。 之前第一部分主要围绕涌现，形式和功能三个词阐述。原文参照这里 如何理解形式和功能？ 复杂系统的产品设计与开发 我认为这六个词是这本书的核心之处，值得关注。 概念 什么是概念 概念是我们对产品或系统所形成的图景，理念，想法或意象。 概念把功能映射到形式。 使用功能性框架时，我们希望它操作简单，部署复杂系统时，我们希望它架构清晰，其实都是降低一项任务所需的成本。 盲目的追求高端技术，设计复杂系统，增加学习与理解成本都属于本末倒置的一种。 「复杂性」贯穿整个产品设计与开发周期，降低复杂性是架构师的重要职责之一。 书中有专门一章提到了架构师的角色，减少歧义，制定解决方案，交付结果。 团队管理者的任务可以理解为，减少歧义，更新目标，管理复杂度。 需求与目标 说出你的需求，我们通常说，技术服务于业务。 利益相关者 在我看来设计系统之前，有两项需要知道。
2.3K20编辑于 2022-04-15
腾讯云开发者
Copyright © 2013 - 2026 Tencent Cloud. All Rights Reserved. 腾讯云 版权所有
深圳市腾讯计算机系统有限公司 ICP备案/许可证号：粤B2-20090059 
粤公网安备44030502008569号
腾讯云计算（北京）有限责任公司 京ICP证150476号 | 京ICP备11018762号