- 综合排序
- 最热优先
- 最新优先
- 来自专栏架构之家
大型复杂系统的架构设计思考
1、 大型系统和简单系统设计有什么区别？ 2、 大型系统设计不就是分布式设计吗？ 3、 如何进行大型系统设计？ 二、大型系统与简单系统设计的区别 从系统的简易程度可以将系统分为复杂系统或简单系统。 我们这里成复杂系统为大型系统，大型系统是复杂系统，一般是指规模大、复杂度高的系统。而简单系统是指规模小，复杂度也不高的系统，一般是单体，也可能是分布式架构的简单系统。 4.1 大型系统的设计步骤 大型复杂系统的设计不是一开始就进行架构设计，核心也不完全是分布式技术架构。而是要从业务开始，进行逐步设计的过程。 在进行了以上设计的基础上，才会进入单系统的设计（以RUP 4+1视图为参考）。 五、业务架构 系统建设是为业务服务的，所有的系统建设都是为了解决业务问题。 （4）业务数据是支撑业务的简单数梳理，包括数据域，数据模型和数据规则。
1.2K20编辑于 2022-07-12 - 来自专栏肉眼品世界
系统设计之降低复杂性
三、复杂性的原因 复杂性是由两件事引起的：依赖性和模糊性。 1、依赖关系 依赖关系是软件的基本组成部分，不能完全消除。实际上，我们在软件设计过程中有意引入了依赖性。 战略设计的主要目标必须是制作出出色的设计，考虑后续的可维护性及扩展性。 战略性编程需要一种投资心态。尽管前提投入会比战术编程花费更多的时间，但随着系统的迭代，战略编程的优势就开始逐渐显现。 2、模块的设计 开发一个新模块，如果有不可避免的复杂性。两种设计思路哪个更好：1、应该让模块用户处理复杂性，2、应该在模块内部处理复杂性？ 模块是设计应该是深的，最好的模块是那些其接口比其实现简单得多的模块。这样的模块具有两个优点。1、一个简单的接口可以将模块强加于系统其余部分的复杂性降至最低。 4、重视命名 名称是一种抽象形式：名称提供了一种简化的方式来考虑更复杂的基础实体。良好的名字是一种文档形式：它们使代码更易于理解。它们减少了对其他文档的需求，并使检测错误更加容易。
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）具备指挥调度功能，包括指令的下发、任务进程及状态监控、任务执行情况反馈上报等功能。 显示系统涉及的关键技术包括显示系统与其他系统的接口设计，态势动态表现技术，通用地图接口和图元接口的设计，行动态势的多角度、多方式输出和表现技术。 10. （4） 系统调用模型库(包括态势符号库)、中央连接平台(负责各个子系统间的通信)，结合行动态势生成系统及推演引擎进行行动态势的生成，驱动整个推演调度系统按照推演剧情正常展开、进行。
1.4K30发布于 2020-07-16 软件设计的哲学-软件系统的复杂性问题
今天继续和大家推荐和导读《软件设计哲学》这本经典书籍。 这本书深入探讨了如何通过高内聚低耦合、分层抽象等设计方法有效降低软件系统的复杂性，适合所有软件开发人员阅读。 核心要点 软件系统的复杂性主要由依赖性和模糊性引起，其中依赖性问题更难解决。 模块设计应追求深度，即隐藏内部复杂性，对外暴露简单接口，尤其是通用模块。 在导读之前，我想先说明这本书的受众群体。根据我的阅读体验，这本书适合所有从事软件开发的人员阅读，无论是编码工程师还是系统设计师，都能从中获得启发。 本书的核心主题是探讨软件系统的复杂性问题。 若拆分过于粗略，则难以应对系统的复杂性；若拆分过于细致，模块间的集成和依赖又会加剧这种复杂性。因此，这成为一个两难的问题，解决起来颇具挑战性。 在概述复杂性之后，本书正式进入软件设计哲学的内容。 软件复杂性=业务*技术*治理 基于这两本经典书籍对软件系统复杂性的分析和阐述，我个人的理解是，我们应该从三个重要维度去理解软件系统的复杂性：业务复杂性、技术复杂性、上线以后的管控治理复杂性。
22210编辑于 2025-11-17- 来自专栏后端技术
系统设计与分析 作业4
去哪儿 c.对比两个时代、不同地区产品的用例图，总结在项目早期，发现创新的思路与方法。 两个用例图主要功能基本相同，但新时代的功能更多，服务更精细。 而且新的用例图中支付方式不仅限于信用卡，还有支付宝和微信。创新的思路主要在于在原有的思路上改进，同时考虑结合新科技，为顾客提供周到的服务。 d. a hotel reserve hotel 50 5 you can reserve a hotel by selecting a hotel and room. manage basket 30 4 简述利用流程图发现子用例的方法 b. 选择你身边的银行 ATM，用活动图描绘取款业务流程 c. 查找淘宝退货业务官方文档，使用多泳道图，表达客户、淘宝网、淘宝商家服务系统、商家等用户和系统协同完成退货业务的过程。分析客户要完成退货业务，在淘宝网上需要实现哪些系统用例 3.
50720发布于 2019-05-25 - 来自专栏野生AI架构师
复杂场景下的用户与权限系统的设计思考与实践
最近参与一个项目的架构设计，及提供技术指导，发现其用户体系相当复杂，之前自己的设计显然想简单了。其大概的要点如下： 1. 一个账号可能有多种角色，例如既可以是家长，也可能是校医校长、工作人员等；一个学生长大之后，也可能成为校医校长等； 4. 可以使用账号密码登录，还可以使用手机号登录，也可以使用绑定微信登录。 低估的复杂性 之前设计的时候，有些问题考虑是不够的： 开始时漏考虑了一个角色：普通微信用户。 复杂性在于后续该用户可以和学生进行绑定，这时他的角色就可能会转换成学生或者家长等，可能需要对账号进行合并，因为原来学生的账号本来就是预先生成在系统中的，如果是家长则需要对账号类似进行转换。 问题产生的原因与教训 开发与架构设计沟通不够：这个可能是主要原因，架构在前面很难把所有细节都考虑到，特别是系统比较复杂的时候，这时舒畅的沟通机制就很重要，特别是跨团队的时候，有周例会对齐认知很重要；
57410编辑于 2023-08-26 - 来自专栏magicodes
EXT.NET复杂布局（四）——系统首页设计（下）
title, content) { 2: Ext.net.Notification.show({ 3: hideFx: { 4: "&rand=")) + Math.round(Math.random() * 10000)); 3: var myWin = new Ext.Window({ 4: true, 16: maximizable: true, 17: maximized: arguments.length == 4 至于其他的代码，我就不多介绍了，篇幅有限，精力有限。 工作台的代码，其他篇幅有部分介绍，可以参考EXT.NET复杂布局（一）——工作台。 ; 关于表单的一些介绍，请看EXT.NET复杂布局（三）——复杂表单布局。 尾声 从使用EXT.NET到现在，也差不多一年了，真正使用的时间也只有几个月而已。现在回想起来，还是感慨良多。
2.3K20发布于 2018-12-27 - 来自专栏magicodes
EXT.NET复杂布局（四）——系统首页设计（上）
很久没有发帖了，很是惭愧，因此给各位使用EXT.NET的朋友献上一份礼物。 本篇主要讲述页面设计与效果，下篇将讲述编码并提供源码下载。 系统首页设计往往是个难点，因为往往要考虑以下因素： 重要通知 系统功能菜单 快捷操作 日常维护工作（比如待办事项、已办事项等等） 用户信息（比如公司、部门、组织机构） 系统信息（意见反馈、帮助等） 联系沟通 下面就给出我的方案。 页面效果 我申明下，我不是专业的前端工程师，我就是一打杂的（啥都搞下），所以不要期望过高，如果还过得去，请点推荐。不多说了，上图： ? ? 从图中可以看出，首页分4块区域（四大板块）： 顶部面板——LOGO、用户信息、帮助、反馈、通知等。 左侧面板——组织机构（通常放功能菜单）。 右侧面板——联系人或其他信息。 中央区域——工作台。 顶部面包和右侧面板没啥好说的。接下来就说说功能吧。 左侧面板 左侧面板其实是相当重要的一块，在平常系统设计中，往往把功能菜单放在左侧。这里类似。不仅支持分组折叠，还支持无限极子菜单，美观而灵活。 ?
1.2K30发布于 2018-12-27 Go 的语言设计天然不适合复杂业务系统抽象
复杂业务系统（高变更频率、跨团队协作、强治理约束、复杂业务逻辑）里，Go 往往会把一部分“架构表达”的成本转移到工程约定与组织治理上。 Go 在基础设施领域是一门非常有竞争力的语言。 当你需要 Clean Architecture、DDD、Hexagonal、AOP、IoC 这类方法论来治理复杂系统时，Go 的克制设计通常会让这些方法论更依赖约定与工具链，从而把成本更多推到团队与流程上 一个“系统抽象能力强的语言”能让这些概念落在代码里，而不是停留在文档里。 Go 的设计目标与架构表达的取舍 Go 的核心设计原则是简单、清晰、显式与快速编译。 结构信息密度很高，但代价是更陡峭的学习曲线与更复杂的类型设计，需要强工程能力来驾驭。 例如一个日志采集系统与一个复杂的反欺诈系统面对的工程难题完全不同。 前者关注性能与可维护性，后者关注规则可演进与架构可治理。
16910编辑于 2026-01-29- 来自专栏ThoughtWorks
为复杂混沌的微服务生产环境设计韧性系统
面对复杂混沌的生产环境，应该本着“不信有好事”的原则来进行“明哲保身”式的软件设计，并在生产环境中利用混沌猴以及在办公区进行僵尸来袭模拟的混沌工程实践，来持续地主动揭示系统弱点，并加以改进，以提高系统韧性 对于阿里云这样复杂的系统，挂了的风险不可避免。 对于任何复杂的系统，失误必然会发生，只是敬畏还不够。因为—— 复杂和混沌的系统无法预测 科幻作家刘慈欣所创作的《三体》，受到了下面三体问题的启发。 一年多前的一天，一位亚马逊S3服务团队成员正在根据运维剧本移除少量的服务器。一不小心，他输错了命令，导致多于预期的服务器被移除。此后的4个小时内，美国成千上万的网站无法正常运转。 ? 针对复杂和混沌的微服务生产环境，我们可以使用下面的方法来设计系统韧性。 识别问题种类。使用“栖息地”框架来确定生产环境属于哪种问题。 此时可以针对上面所识别出的约束，考虑使用超时、断路器、舱壁、快速失败、任其崩溃并替换等设计模式来增强系统韧性。
94320发布于 2019-09-16 - 来自专栏图南科技
复杂系统的产品设计与开发
有一天我在逛知识星球的时候，看有人推荐《系统架构 复杂系统的设计与开发》，于是买了实体书，读完后感觉很有价值。 抽象，复杂，难以理解的同时，呈现出来的是一套高屋建瓴的方法论。 在产品设想，原型设计，系统架构的时候，首先我们想到的是产品要满足什么样的功能需求。 其次以什么样形式展现给用户，再者就是这样的形式存在什么样的关系和结构。 系统的功能需要对外展示，也就是说，系统的一条重要原则：功能与价值总是体现在系统边界处。 翻译过来，只有在跨界输出时，才能体现出最大价值。像 设计团队，只有在交付设计方案时，才能体现出价值。 结合工作场景，其实我们每天工作交流的主要任务就是做这些事，避免信息分歧。 而团队管理者的任务可以理解为 减少歧义，更新目标，管理复杂度。 ，它们是我们分析系统的重要角度； 这篇文章分享的关键词是 系统，功能，形式，涌现和复杂度信息歧义。
76830编辑于 2022-04-15 - 来自专栏架构精进之路
解构复杂业务系统：架构设计的核心逻辑与实践
一、什么是复杂系统 我们经常提到复杂系统，那么到底什么是复杂系统。我们看下维基的定义：复杂系统（英语：complex system），又称复合系统，是指由许多可能相互作用的组成成分所组成的系统。 八、复杂系统的架构特点 1.重视功能拆解，模块化设计，原子化设计 复杂系统一定要进行细致功能、模块、领域的划分。每个模块的都应该有明确，单一的职责。 4.分而治之 对于复杂系统，拆分是必然的，大的问题化解成小的问题，根据领域、模块、功能的划分，我们把问题归属于不同的边界内，进行逐个攻破。 我们知道复杂系统必然存在的纷繁复杂的依赖，依赖不可能存在于视图部分，肯定会表现为接口的依赖。对于复杂系统，我们要强迫我们转换思维，强迫我们面向接口进行设计。 复杂系统的架构设计不是一蹴而就的，合适的才是正确的。希望本文能够对您在进行复杂系统设计时有一定的参考意义。
41120编辑于 2025-11-12 - 来自专栏运维开发王义杰
UML vs SysML：哪个更适合复杂系统架构设计？
引言 在面对一个由多个软件和中间件组成的复杂系统时，传统的UML（统一建模语言）可能显得有些局限。这时，我们可能会想，是否有更适合的建模工具或方法？SysML（系统建模语言）是一个可能的选项。 在这篇文章中，我们将探讨UML和SysML在处理这种复杂系统时的优缺点。 UML：软件建模的标准 UML是业界广泛接受的用于软件建模的标准。 SysML：系统建模的解决方案 SysML是一种扩展自UML的建模语言，专为复杂的系统（包括软件、硬件、人员、设备等）设计。它提供了一些额外的图示元素和建模范例，专门用于处理系统级的问题。 因此，在做出选择时，以下几点值得考虑： 需求复杂性：如果你的系统涉及多个软件、硬件和其他资源的复杂交互，SysML可能更合适。 总结 当我们面对一个由多个软件和中间件组成的复杂系统时，传统的UML可能不再足够。SysML提供了一种更全面的建模方法，特别是在需要系统级视角和全面需求分析的场景下。
2.1K20编辑于 2023-09-19 - 来自专栏明明如月的技术专栏
理解复杂系统的关键：耐心
理解复杂系统的关键：耐心 复杂系统本质上是多面的、复杂的。它们通常并非被设计成一瞬间就能理解的。这对于自然发生的系统，如生态系统，和人类设计的系统，如高级软件或机械，都是适用的。 这些系统是由多个组件混合而成，每个组件都有其独特的属性和角色。要理解整个系统，理解每个组件及其相互作用是至关重要的。这个过程需要时间，因此，需要相当程度的耐心。 理解复杂系统的关键就是耐心。 其次，复杂性常常伴随着不可预测性。在复杂系统中，微小的调整或变化可能会由于组件的相互连接性而导致无法预见的后果。这种特性，通常被称为"涌现行为"（系统的复杂性超过其各部分的总和），需要耐心和观察力。 草率的结论或行动很容易导致对系统真实行为的误解或误读。 耐心的路线图 那么，如何培养这个关键的技能呢？培养耐心需要改变思维方式，并有意识地接受学习的旅程。 接受复杂性：第一步是接受系统的固有复杂性。 总的来说，耐心在理解复杂系统的过程中，不仅是一种美德，更是一种基本的技能。它需要有意识的培养和实践，但会带来深度理解和掌握的丰富回报。
30820编辑于 2023-08-02 - 来自专栏全栈前端精选
组件库设计实战 - 复杂组件设计
这里我们提出一个组件复杂度的概念，一个组件复杂度的主要来源就是其自身的状态，即组件自身需要维护多少个不依赖于外部输入的状态。 最简单的轮播组件 抛去所有复杂的功能，轮播组件的实质，实际上就是在一个固定区域实现不同元素之间的切换。 至此，组件库设计实战系列文章也将告一段落。 在全部四篇文章中，我们分别讨论了组件库架构，组件分类，文档组织，国际化以及复杂组件设计这几个核心的话题，因笔者能力所限，其中自然有许多不足之处，烦请各位谅解。 组件库作为提升前端团队工作效率的重中之重，花再多时间去研究它都不为过。再加上与设计团队对接，形成设计语言，与后端团队对接，统一数据结构，组件库也可以说是前端工程师在拓展自身工作领域上的必经之路。
1.2K10发布于 2019-09-29 - 来自专栏后端精进之路
如何设计一个微博系统？- 4招教你搞定系统设计
经常在面试的时候，会被问到系统设计类的题目，比如如何设计微信朋友圈、如何设计12306系统、如何设计一个抢票系统等等。如果是没有准备过，一般都会不知所措，难以找到切入点。 百度、谷歌也不可能只是一个搜索框而已，底下的东西复杂去了。 所以首先要明确，系统问题的答案一定不可能是全面的，面试官也不会期望我们给出一个满分答案。 如何搞定系统设计 - 4步法 针对系统设计，这里给大家提供一个4步法解决方案，无论是任何系统设计的题目，都可以按照这几步去思考解决。 1. 这里面涉及到各种存储方案的选择、数据库的设计等等，后面会有专门的文章进行介绍。 4. 实战 - 4步法解决Weibo设计 这部分我以Weibo的设计为例，带大家过一遍如何用4步法解决实际的系统设计。
1.1K20编辑于 2023-10-19 - 来自专栏图南科技
读完《系统架构，复杂系统的产品设计与研发》记住这三个词
这篇文章是《系统架构，复杂系统的产品设计与研发》第二部分。 本文主要围绕 概念，需求与目标三个词展开。 之前第一部分主要围绕涌现，形式和功能三个词阐述。原文参照这里 如何理解形式和功能？ 复杂系统的产品设计与开发 我认为这六个词是这本书的核心之处，值得关注。 概念 什么是概念 概念是我们对产品或系统所形成的图景，理念，想法或意象。 概念把功能映射到形式。 使用功能性框架时，我们希望它操作简单，部署复杂系统时，我们希望它架构清晰，其实都是降低一项任务所需的成本。 盲目的追求高端技术，设计复杂系统，增加学习与理解成本都属于本末倒置的一种。 团队管理者的任务可以理解为，减少歧义，更新目标，管理复杂度。 需求与目标 说出你的需求，我们通常说，技术服务于业务。 利益相关者 在我看来设计系统之前，有两项需要知道。 充分了解了软件系统三个属性，形式，功能，目标之后， 一起看看书中提到的 四步通用产品的开发过程 通用产品的开发过程 产品开发过程分为 4 个活动。分别是 构思，设计，实现和运作。
2.3K20编辑于 2022-04-15 - 来自专栏ThoughtWorks
如何交接复杂的遗留系统？
业务复杂度高 业务上，这个支付网关光是在卡支付的场景下就同时支持8种技术，还有信用卡相关的安全功能，数不清的报表和各种增值服务。 鉴于项目的复杂度，在有限的交接期内达到这个目标基本是不可能的。但是如果将时间轴拉长，分阶段来实施，就比较容易做出一个切实可行的计划；同时，也能最大化交接期的价值，让团队从第一天起就朝着一个方向努力。 利用C4模型梳理系统架构 通常处理的问题都是业务问题，如果不能把一个个服务放在业务流程中去理解就没有意义。 因此，我们在交接完一个独立服务或者若干个有关联的服务后，都会试图用C4模型画出他们的C1(System Context Diagram)和 C2(Container Diagram)两个高级别的图，以可视化的方式展示出系统输入 从现在的结果来看，正是这种结对的形式，保证了整个团队的“高可用”。 4. 通过线上事故演练提升团队On Call的信心 7 × 24 小时 On Call 对团队来说，无疑会是一个非常大的挑战。
97510编辑于 2022-02-16
腾讯云开发者
Copyright © 2013 - 2026 Tencent Cloud. All Rights Reserved. 腾讯云 版权所有
深圳市腾讯计算机系统有限公司 ICP备案/许可证号：粤B2-20090059 
粤公网安备44030502008569号
腾讯云计算（北京）有限责任公司 京ICP证150476号 | 京ICP备11018762号