32 | 可扩展架构的基本思想和模式
李运华
该思维导图由 AI 生成，仅供参考
软件系统与硬件和建筑系统最大的差异在于软件是可扩展的，一个硬件生产出来后就不会再进行改变、一个建筑完工后也不会再改变其整体结构。例如，一颗 CPU 生产出来后装到一台 PC 机上，不会再返回工厂进行加工以增加新的功能；金字塔矗立千年历经风吹雨打，但其现在的结构和当时建成完工时的结构并无两样。相比之下，软件系统就完全相反，如果一个软件系统开发出来后，再也没有任何更新和调整，反而说明了这套软件系统没有发展、没有生命力。真正有生命力的软件系统，都是在不断迭代和发展的，典型的如 Windows 操作系统，从 Windows 3.0 到 Windows 95 到 Windows XP，直到现在的 Windows 10，一直在跟着技术的发展而不断地发展。
今天我们进入架构可扩展模式的学习，这部分内容包括分层架构、SOA 架构、微服务和微内核等，先来聊聊架构的可扩展模式。
软件系统的这种天生和内在的可扩展的特性，既是魅力所在，又是难点所在。魅力体现在我们可以通过修改和扩展，不断地让软件系统具备更多的功能和特性，满足新的需求或者顺应技术发展的趋势。而难点体现在如何以最小的代价去扩展系统，因为很多情况下牵一发动全身，扩展时可能出现到处都要改，到处都要推倒重来的情况。这样做的风险不言而喻：改动的地方越多，投入也越大，出错的可能性也越大。因此，如何避免扩展时改动范围太大，是软件架构可扩展性设计的主要思考点。
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线笔记
复制
AI
- 深入了解
- 翻译
- 解释
- 总结
本文介绍了软件系统可扩展性的基本思想和模式，强调了拆分是实现可扩展性的关键。拆分方式包括面向流程、面向服务和面向功能，每种方式都会导致不同的架构设计。通过TCP/IP协议栈和学生信息管理系统的案例，阐述了流程、服务和功能的区别和联系。不同的拆分方式决定了系统的扩展方式，并且可以在系统架构设计中进行组合使用。文章最终强调了合理的拆分能够强制保证即使程序员出错，出错的范围也不会太广，影响也不会太大。总的来说，本文为软件架构设计提供了重要的指导，帮助开发人员理解如何设计可扩展的软件系统。
仅可试看部分内容，如需阅读全部内容，请付费购买文章所属专栏
《从 0 开始学架构》，新⼈⾸单¥68
《从 0 开始学架构》，新⼈⾸单¥68
立即购买
© 版权归极客邦科技所有，未经许可不得传播售卖。 页面已增加防盗追踪，如有侵权极客邦将依法追究其法律责任。
登录 后留言
全部留言(56)
- 最新
- 精选
鹅米豆发面向流程、面向服务、面向功能，这三个的命名，面向服务和面向功能还可以，面向流程这个容易让人误解。 面向流程，大概指的是数据移动的流程，而不是业务流程。分层架构的本质，就是固定的内核，移动的数据。 规则引擎的扩展方式，可以用下排除法。 首先，肯定不是分层架构，即不是面向流程的，因为规则引擎主要作用在业务层。 其次，也不应该是面向服务的，因为规则引擎都是跨越多个服务的。 规则引擎和插件式架构，解决的都是功能扩展的问题。微内核架构就是一种插件式架构。 所以，规则引擎应该是面向功能的扩展方式。作者回复: 思路很清晰，赞，面向流程这个说法确实不那么容易理解，但你对照TCP/IP那个图就很清晰了
2018-07-103104
feifei规则引擎由推理引擎发展而来，是一种嵌入在应用程序中的组件，实现了将业务决策从应用程序代码中分离出来，并使用预定义的语义模块编写业务决策。接受数据输入，解释业务规则，并根据业务规则做出业务决策。 规则引擎是将业务决策与业务分离，它提供的还是决策功能，我觉得是面向功能，我没使用规则引擎的经验！不知道这样理解是否存在问题？作者回复: 理解正确
2018-07-1034
东面向服务和面向功能，这两个概念感觉十分难以区分，某个功能也可以做成一个微服务，某个微服务也可以认为是一个功能，求教二者的差别。谢谢华仔作者回复: 可以理解服务是一组相似功能的集合，例如用户登录是服务，这个服务支持手机号登录，微信登录，QQ登录3个登录功能，当然，如果你真的需要把手机号登录做成一个独立的服务也是可以的，不存在绝对的界限
2018-07-11326
钱课后思考及问题 1：拆——不仅仅是许多房二代产生原因，还是所有可扩展性系统架构的精髓。 在看正文之前我稍微想了一下，发现能做到水平扩展的，比如：web服务、微服务、数据存储服务等，加上一些机器就能一起扛量，都是流量的路由和中转，对应的服务够纯粹，可以独立提供对于的服务。 2：系统拆分的模式？ 2-1：面向流程——分层架构，数据流程非业务流程 2-2：面向服务——微服务，倾向于站在外部视角而言 2-3：面向功能——微内核，倾向于站在内部视角而言 3：规则引擎是常用的一种支持可扩展的方式，按照今天的分析，它属于哪一类？ 规则引擎没具体弄过，不过我感觉类似状态转换，是一个功能型的东东。也可通过排除法比较清晰的，看出它应该属于面向功能的类型。作者回复: 回答正确
2019-09-0113
正是那朵玫瑰规则引擎是嵌入应用程序的一种组件，我们也一直想引入来解决复杂多变的规则变化，而规则应属某项功能，比如我们在p2p行业，想筛选出种子用户，可能会有很多的条件限制，如投资额达到多少，投资的频率等等，而这些条件又会经常变化，于是用规则引擎抽离出来，从这个角度看规则引擎应该是面向功能拆分（筛选种子用户是属于一项功能）。不过我觉得规则引擎还可以编排流程，比如有A，B，C，D四个流程， 1、当满足条件1时走A-->B-->C-->D 2、满足条件2时走A-->B-->D 3、满足条件2时走A-->B-->C 从这个角度来说是不是也可以认为是面向流程拆分，不知道理解是否正确？作者回复: 文章中的流程概念范围要大很多，可以认为流程和条件无关
2018-07-1013
天外来客规则引擎是嵌入的一种功能组件，就像计算引擎一样，属于功能级的概念，应该属于面向功能的拆分。 另一方面，即使把规则相关的部分做成服务，仅就规则引擎来讲，它也是功能级的概念，而非流程或者服务。作者回复: 理解到位👍
2018-07-2612
慎独明强总结下今天所学到的内容。可拓展架构的基本思想就是拆，拆又分为流程拆分，服务拆分，功能拆分，三个粒度是越来越小。在工作中首先是按照业务流程拆分为不同的服务，小服务为了支持可拓展按流程拆分为合单、过滤拦截、冻结、查询库存、预售、寻仓等，再每个小流程按功能去拆分为不同的接口，再通过配置化实现这些接口的组装或者说调用链，来实现可配置化的支持业务。有新增业务，只需增加配置项和接口，不会影响到其他业务功能。作者回复: 点赞👍
2020-08-078
沧海一粟面向服务的拆分成独立的子系统，如文中所讲的学生管理系统，拆分为注册服务，登录服务，管理系统等子系统，请问老师，这些子系统是自己链接数据库的吗？实际项目都是怎么做的？作者回复: 每个服务是独立的子系统，有各自独立的数据库，缓存，服务器
2018-07-105
11月的萧邦提高架构的扩展性靠拆，那么拆是也可以提高代码层面的扩展性？比如：两个功能耦合在一个方法里了，通过拆分成两个方法，一个方法里面各完成一个功能，也达到解耦的效果来提供扩展性作者回复: 是的，大道相通
2022-04-083
Will面向流程是否可以这样理解，比如电商网站下单的流程。登陆、浏览商品、加入购物车、结算、下单、支付、收货、评价等。拆完就是用户服务、商品服务、订单服务、评价服务等。谢谢华仔这么赞的所有章节！作者回复: 是的，这就是面向流程拆分，同样是这个电商案例，如果按照男装，女装，电器拆分，就是面向服务拆分
2018-07-1733
收起评论
