03 | 可扩展架构：如何打造一个善变的柔性系统？
系统的构成：模块 + 关系
荧光笔
直线
曲线- 深入了解
- 翻译
- 解释
- 总结
本文深入探讨了如何打造一个可扩展的架构，从系统构成、模块和依赖关系三个方面详细阐述了可扩展架构的设计要点。首先，系统的模块需定位明确、概念完整、自成体系、粒度适中；依赖关系应简化为单向、层次结构。其次，通过MVC分层结构的例子，说明了模块的层次结构设计。文章以在线出行公司为例，阐述了模块拆分和整合的方法，包括水平和垂直拆分，以及通用化和平台化整合。通过这些手段，可以有效地控制系统复杂度，最小化业务变化引起的系统调整，从而实现系统的扩展性。文章深入浅出地解释了如何通过良好的模块设计和依赖关系管理来打造一个可扩展的系统，对于需要快速了解系统架构设计的读者具有很高的参考价值。
《架构实战案例解析》，新⼈⾸单¥59
全部留言(41)
- 最新
- 精选
航哥很帅看到目前，说说目前我对业务系统的理解： 架构的本质其实是如何通过一定的合理编排，让一个软件系统变得的有序，从而满足业务和技术的不断变化。说的高大上一些就是如何让系统变得更有序，而不是系统的熵变得越来越大。那如何让系统变得更有序呢？一般有两种方式：一种是分，一种是合。分就是能够对系统进行拆分，拆分成各个不同的业务模块，同时梳理清楚各个模块之间的关系；合就是能够将模块根据业务的种类，能够把相同的功能模块给合并起来，来统一对外提供服务。 对于业务架构的划分来说，有两个角色好像是在做相同的事情，一个是产品经理，一个是业务架构师。产品经理更多是面向用户侧的，目的是让用户能够对业务认识更清楚，而且产品经理一般不用从业务设计和实现的角度来考虑问题，所以产品经理和开发人员的对接就会比较困难。而业务架构师，则是在产品经理设计完产品功能以后，从面相对象设计的角度来划分模块，让软件的功能设计更加合理，更加适合开发。 一个非常简单的例子就是：产品经理设计的功能，一般都是流程化的，即整个业务流程图。而如果开发人员直接按照这个业务流程来进行开发，很有可能每个业务或功能都要照着流程来做，这样势必会造成大量功能的重复开发。而业务架构师往往就是做这个工作的，既然产品经理已经把哥哥业务流程梳理清楚了，那业务架构师就要把所有的业务流程进行融合和整理，从面相对象的角度来进行设计，画出各个对象之间的关系和依赖图，让开发人员能够更好的进行功能开发。 对于业务架构的可扩展性来说，系统如何能够做到柔性可扩展，是衡量一个系统架构设计好坏的金标准。什么是业务系统，说的简单一些业务系统就等于模块+关系。模块拆分好了，关系梳理好了，往往一个业务系统架构也就定义清楚了。但是一个业务系统好不好还有一个非常关键的指标，那就是：系统的可扩展性和功能的复用性是不是很好，因为这关系到了整个系统的生命周期。 系统的可扩展性好，本质上是系统中各个模块的依赖关系清楚，系统中的各个模块不是复杂和混乱的，而是模块和模块之间关系清楚，很少有相互调用，很少有双向调用。 系统的复用性好，本质上系统的逻辑划分清楚，功能模块能够做到粒度适中，通用功能能够合理整合，给各个业务功能提供调用。作者回复: 理解得很好
2020-11-16318
偏偏老师讲的很好，有几个问题请老师指点一下，1. 如果服务拆分的很细了，而且还有大中台提供服务，一般的做架构的话服务是不是可以不用分层和解耦了，如果按业务来看，影响分层和解藕都有哪些因素需要考量。 2. 关于系统重构，业务梳理并划分清楚后，在技术角度需要考量的因素还有那些。作者回复: 如果有大中台的话，主要的分层和解耦工作已经帮你做了，剩下的是偏应用上层的业务，不用太多考虑再深入拆分。拆分不是越细越好，在人容易理解的前提下，是越粗越好。 系统重构时，除了设计到位，保证系统能够平滑过渡也很重要。技术角度多考虑数据如何迁移，如何实现系统的灰度改造，分阶段上线，减少风险。出问题时，要有B计划兜底。
2020-02-2610
深山小书童老师您好，首先得感谢这个课程，案例丰富，干货满满，很有诚意，这十篇文章已经反复研读很多遍。关于可扩展架构的几篇文章老是串不起来，只记得可复用的几篇文章。能否请老师讲一下可扩展的几篇文章的安排思路，方便理解。作者回复: 赞一个，这么用心，这个问题，我都要翻一下前面几篇的内容，其实内容安排也没有那么有逻辑。 03篇到06篇讲的都是业务可扩展，大致关系如下： 1. 03篇是总纲，从系统=模块+关系出发，怎么去定义模块和关系。 2. 04篇介绍互联网架构，从单体到微服务，这些都是实际的架构，通过这些架构中，介绍模块和关系是怎么演变支持扩展的。 3. 05篇通过具体的网关案例，从单体到服务化，介绍模块和关系在一个实际项目中怎么变化的。 4. 06篇介绍中台，是04篇的继续。 其实都是围绕着模块和关系的定义，去解剖系统以及可扩展。
2020-03-147
乖，摸摸头老师，我们现在的一种业务场景，我们做的是一个信息对接平台，简化后的主要内容就是这样。 1.信息分为几大类，用户可以发布几种不同的信息，信息发布流程大不分逻辑是一样的，有一小部分差别，和你举例中的打车有点类似。 2.用户查看别人发布的信息需要消耗积分，查看几种分类的信息消耗的积分是不一样的。 3.用户可以置顶自己发布的信息，需要消耗积分，置顶不同分类信息的积分也是不同的。 4.积分是通过用户 拉新、充值等方式获得的。 5.用户的积分是储存在用户表的一个字段中。 6.用户查看信息、或者发布信息 之前会先判断用户的状态，如果用户被我们做了一些标记，就会先让用户做一些其他操作才能查看信息，比如先填手机号填个验证码. 7. 一条信息只扣一次积分，也就是说，在扣分之前会先查询是否已经扣分，扣过分就不再扣分了。 大致的场景就这样，我把系统划分为下面几个模块、和功能。 用户模块： 登录、注册、鉴权... 信息模块： 发布信息、修改信息... 积分模块： 设置各种信息的扣分单价（比如 A类信息需要1分查看，B类信息需要2分查看）。设置 充值单价(10元20积分，20元50积分等)。 记录 积分来源记、积分消耗等积分记录 问题1： 我这样划分模块合不合适？ 问题2： 用户查看信息消耗积分这个动作应该放在哪个模块，是放到用户模块、还是积分模块，还是再新增一个模块。 如果放到用户模块： 先去信息模块获取信息，获取用户信息(需要判断用户状态是否健康) 再扣掉用户积分，然后调用积分模块增加一条积分消耗的记录 如果放到积分模块： 先去信息模块获取信息，调用用户模块(需要判断用户状态是否健康) 再次调用用户模块扣掉积分，再增加一条积分消耗记录。作者回复: 信息量比较多，理解起来比较费时，这里我只提供思路。针对问题2，用户查看信息消耗积分如果不合适放用户模块或积分模块，可以放上这两个基础模块之上的聚合服务处理。就像电商的下单功能，在会员服务，商品服务，订单等基础服务之上。
2020-06-1123
Carlos老师，我在开发中遇到这种模块关系，怎么设计比较好？ 我们经常基于客户业务流程开发系统，按照流程节点划分模块，每个模块仅和上一个节点模块关联。模块间关系抽象标识为： 节点1 <- 节点2 <- 节点3 <- 节点4 正常情况下，每个模块仅需要了解相邻上个模块的信息即可。但有些情况下，客户需要在某个业务模块知道跨节点模块的信息，例如"节点4"需要能看到对应"节点1"的信息，这样“节点4”添加一个字段，就需要分别在“节点2”，“节点3”上添加一遍，然后“节点4”才能查到。 这种依赖关系有办法破吗？作者回复: 以下建议供参考： 1. 提供一个公共模块供这些跨节点信息读取，比如这个模块维护一张表，包含四个通用的列（节点名，记录id，属性名，属性内容） 2. 公共模块提供通用的属性存取逻辑，没有和具体节点相关的业务逻辑 3.每个节点自身维护额外属性时，发现某个属性可能被跨节点使用，同时写入公共模块 4.某个节点如果需要跨节点读取属性，从公共模块中获取 这里的关键是把公共模块变成纯技术性的基础设施，不包含业务逻辑，每个节点只和它交互，这样依赖关系相对简单。 由于不熟悉具体场景，不一定是最优方案，仅供参考。
2023-02-10归属地：山东2
小洛有几个问题请教下老师 1、模块业务逻辑要尽量围绕自身内部数据进行处理，但是有时候需要调用其他模块的数据才能正确处理自己内部的逻辑，就比如订单模块在算价的时候是需要调用优惠模块计算，然后拿到结果做保存，这时候失败了要怎么处理？ 2、如何做好模块结构层次化，有什么准则吗？怎么定义相似的模块放到同一层次？开始如果放错，后期调整，如果对业务造成很大影响，是否需要去调整呢？ 3、通用化整合，如果修改的是通用逻辑，依赖的多个业务线应该需要全部回归，在业务架构上如何去做权衡作者回复: 1. 上层应用调促销服务进行算价，然后把结果传给订单服务进行保存，订单服务不会直接调促销服务进行算价。 2. 业务实际上有分层的，比如基础业务和上层业务，订单，会员，商品这些业务都可以做类似的划分，比如下单属于订单的上层业务，订单的增删改查和生命周期管理就是基础业务。这些基础业务定位就一样，可以放到同一层。 3. 通用逻辑改了，自然需要回归，业务规则统一在一个地方啊比在多个地方改要好。为避免影响，服务内部要做好单元测试，服务接口要做好自动化测试。
2020-03-142
黄马为了业务流程之间的复用，系统分模块，为了关系模块之间的关系，模块分层； 这些所有的都是给予对业务的理解， 业务的理解公司的业务有关系，如果公司的业务不定，别说构建基础模块，连分模块都不可能。 如果有比较清楚领域知识的，能够识别业务领域的基础能力，直接构建基础能力平台，在此基础上构建各种的业务线 老师理解对吗？作者回复: 需要总体上理解业务，才能定义好哪些是基础业务，架构是逐步演进的，一开始自上而下直接搭建，怎么快怎么来，后面业务复杂了，就要考虑如何拆分组合，哪些属于稳定的基础业务，哪些属于快变的上层应用。不能指望一开始就构建基础平台，筑巢引凤，这不大可行。
2020-03-062
川杰有。领导觉得没有必要调整，或者，要你利用业余时间提出方案，甚至最好是能改好，还不能有什么BUG，最关键的是领导还是程序员出身；只能等他的短视自食其果了。作者回复: 能理解，这个要通过显式立项方式解决。
2020-02-2632
aszt王老师，早！重新温习此教程，又有新的收获，就模块划分和模块职责，我这有个小场景，希望你给些建议：标签平台管理标签及标签与商品之间的关系，现在A模块需要通过标签选商品，但标签平台中只有商品的id等少量信息，A模块需要更多的商品信息，应该由哪个模块来完善商品信息？作者回复: 几种选择： 1.可以在标签平台和商品服务之上提供一个聚合服务，调用标签选商品后，再获取商品更多信息。 2.也可以直接在商品服务里提供这个接口，不建议在标签平台提供，标签平台做专业的事情。 3. A模块调用完标签平台后，自己去聚合商品信息
2021-04-201
Presley老师，分布在同一层的基础模块，一个模块可以调用另一模块吗？如果有调用关系，被调用模块，放到更下一层次会不会合理些？作者回复: 基础模块不调用其他基础模块，比如会员服务不调用商品服务，它们相互之间应该是正交的。上层的聚合服务可以相互调用，组成更大的聚合服务。
2020-10-291
