从0开始学架构
李运华
资深技术专家
立即订阅
38968 人已学习
课程目录
已完结 59 讲
0/4登录后,你可以任选4讲全文学习。
开篇词 (1讲)
开篇词 | 照着做,你也能成为架构师!
免费
基础架构 (13讲)
01 | 架构到底是指什么?
02 | 架构设计的历史背景
03 | 架构设计的目的
04 | 复杂度来源:高性能
05 | 复杂度来源:高可用
06 | 复杂度来源:可扩展性
07 | 复杂度来源:低成本、安全、规模
08 | 架构设计三原则
09 | 架构设计原则案例
10 | 架构设计流程:识别复杂度
11 | 架构设计流程:设计备选方案
12 | 架构设计流程:评估和选择备选方案
13 | 架构设计流程:详细方案设计
高性能架构模式 (8讲)
14 | 高性能数据库集群:读写分离
15 | 高性能数据库集群:分库分表
16 | 高性能NoSQL
17 | 高性能缓存架构
18 | 单服务器高性能模式:PPC与TPC
19 | 单服务器高性能模式:Reactor与Proactor
20 | 高性能负载均衡:分类及架构
21 | 高性能负载均衡:算法
高可用架构模式 (10讲)
22 | 想成为架构师,你必须知道CAP理论
23 | 想成为架构师,你必须掌握的CAP细节
24 | FMEA方法,排除架构可用性隐患的利器
25 | 高可用存储架构:双机架构
26 | 高可用存储架构:集群和分区
27 | 如何设计计算高可用架构?
28 | 业务高可用的保障:异地多活架构
29 | 异地多活设计4大技巧
30 | 异地多活设计4步走
31 | 如何应对接口级的故障?
可扩展架构模式 (6讲)
32 | 可扩展架构的基本思想和模式
33 | 传统的可扩展架构模式:分层架构和SOA
34 | 深入理解微服务架构:银弹 or 焦油坑?
35 | 微服务架构最佳实践 - 方法篇
36 | 微服务架构最佳实践 - 基础设施篇
37 | 微内核架构详解
架构实战 (13讲)
38 | 架构师应该如何判断技术演进的方向?
39 | 互联网技术演进的模式
40 | 互联网架构模板:“存储层”技术
41 | 互联网架构模板:“开发层”和“服务层”技术
42 | 互联网架构模板:“网络层”技术
43 | 互联网架构模板:“用户层”和“业务层”技术
44 | 互联网架构模板:“平台”技术
45 | 架构重构内功心法第一式:有的放矢
46 | 架构重构内功心法第二式:合纵连横
47 | 架构重构内功心法第三式:运筹帷幄
48 | 再谈开源项目:如何选择、使用以及二次开发?
49 | 谈谈App架构的演进
50 | 架构实战:架构设计文档模板
特别放送 (7讲)
架构专栏特别放送 | “华仔,放学别走!”第1期
架构专栏特别放送 | “华仔,放学别走!” 第2期
如何高效地学习开源项目 | “华仔,放学别走!” 第3期
架构师成长之路 | “华仔,放学别走!” 第4期
架构师必读书单 | “华仔,放学别走!” 第5期
新书首发 | 《从零开始学架构》
致「从0开始学架构」专栏订阅用户
结束语 (1讲)
结束语 | 坚持,成就你的技术梦想
从0开始学架构
登录|注册

32 | 可扩展架构的基本思想和模式

李运华 2018-07-10
软件系统与硬件和建筑系统最大的差异在于软件是可扩展的,一个硬件生产出来后就不会再进行改变、一个建筑完工后也不会再改变其整体结构。例如,一颗 CPU 生产出来后装到一台 PC 机上,不会再返回工厂进行加工以增加新的功能;金字塔矗立千年历经风吹雨打,但其现在的结构和当时建成完工时的结构并无两样。相比之下,软件系统就完全相反,如果一个软件系统开发出来后,再也没有任何更新和调整,反而说明了这套软件系统没有发展、没有生命力。真正有生命力的软件系统,都是在不断迭代和发展的,典型的如 Windows 操作系统,从 Windows 3.0 到 Windows 95 到 Windows XP,直到现在的 Windows 10,一直在跟着技术的发展而不断地发展。
今天我们进入架构可扩展模式的学习,这部分内容包括分层架构、SOA 架构、微服务和微内核等,先来聊聊架构的可扩展模式
软件系统的这种天生和内在的可扩展的特性,既是魅力所在,又是难点所在。魅力体现在我们可以通过修改和扩展,不断地让软件系统具备更多的功能和特性,满足新的需求或者顺应技术发展的趋势。而难点体现在如何以最小的代价去扩展系统,因为很多情况下牵一发动全身,扩展时可能出现到处都要改,到处都要推倒重来的情况。这样做的风险不言而喻:改动的地方越多,投入也越大,出错的可能性也越大。因此,如何避免扩展时改动范围太大,是软件架构可扩展性设计的主要思考点。
取消
完成
0/1000字
划线
笔记
复制
© 版权归极客邦科技所有,未经许可不得传播售卖。 页面已增加防盗追踪,如有侵权极客邦将依法追究其法律责任。
该试读文章来自付费专栏《从0开始学架构》,如需阅读全部文章,
请订阅文章所属专栏。
立即订阅
登录 后留言

精选留言(30)

  • 鹅米豆发
    面向流程、面向服务、面向功能,这三个的命名,面向服务和面向功能还可以,面向流程这个容易让人误解。

           面向流程,大概指的是数据移动的流程,而不是业务流程。分层架构的本质,就是固定的内核,移动的数据。

           规则引擎的扩展方式,可以用下排除法。

           首先,肯定不是分层架构,即不是面向流程的,因为规则引擎主要作用在业务层。

           其次,也不应该是面向服务的,因为规则引擎都是跨越多个服务的。

           规则引擎和插件式架构,解决的都是功能扩展的问题。微内核架构就是一种插件式架构。

           所以,规则引擎应该是面向功能的扩展方式。

    作者回复: 思路很清晰,赞,面向流程这个说法确实不那么容易理解,但你对照TCP/IP那个图就很清晰了

    2018-07-10
    46
  • 正是那朵玫瑰
    规则引擎是嵌入应用程序的一种组件,我们也一直想引入来解决复杂多变的规则变化,而规则应属某项功能,比如我们在p2p行业,想筛选出种子用户,可能会有很多的条件限制,如投资额达到多少,投资的频率等等,而这些条件又会经常变化,于是用规则引擎抽离出来,从这个角度看规则引擎应该是面向功能拆分(筛选种子用户是属于一项功能)。不过我觉得规则引擎还可以编排流程,比如有A,B,C,D四个流程,
    1、当满足条件1时走A-->B-->C-->D
    2、满足条件2时走A-->B-->D
    3、满足条件2时走A-->B-->C
    从这个角度来说是不是也可以认为是面向流程拆分,不知道理解是否正确?

    作者回复: 文章中的流程概念范围要大很多,可以认为流程和条件无关

    2018-07-10
    9
  • feifei
    规则引擎由推理引擎发展而来,是一种嵌入在应用程序中的组件,实现了将业务决策从应用程序代码中分离出来,并使用预定义的语义模块编写业务决策。接受数据输入,解释业务规则,并根据业务规则做出业务决策。

    规则引擎是将业务决策与业务分离,它提供的还是决策功能,我觉得是面向功能,我没使用规则引擎的经验!不知道这样理解是否存在问题?

    作者回复: 理解正确

    2018-07-10
    9
  • 面向服务和面向功能,这两个概念感觉十分难以区分,某个功能也可以做成一个微服务,某个微服务也可以认为是一个功能,求教二者的差别。谢谢华仔

    作者回复: 可以理解服务是一组相似功能的集合,例如用户登录是服务,这个服务支持手机号登录,微信登录,QQ登录3个登录功能,当然,如果你真的需要把手机号登录做成一个独立的服务也是可以的,不存在绝对的界限

    2018-07-11
    4
  • 天外来客
    规则引擎是嵌入的一种功能组件,就像计算引擎一样,属于功能级的概念,应该属于面向功能的拆分。
    另一方面,即使把规则相关的部分做成服务,仅就规则引擎来讲,它也是功能级的概念,而非流程或者服务。

    作者回复: 理解到位👍

    2018-07-26
    2
  • 沧海一粟
    面向服务的拆分成独立的子系统,如文中所讲的学生管理系统,拆分为注册服务,登录服务,管理系统等子系统,请问老师,这些子系统是自己链接数据库的吗?实际项目都是怎么做的?

    作者回复: 每个服务是独立的子系统,有各自独立的数据库,缓存,服务器

    2018-07-10
    2
  • godtrue
    课后思考及问题
    1:拆——不仅仅是许多房二代产生原因,还是所有可扩展性系统架构的精髓。
    在看正文之前我稍微想了一下,发现能做到水平扩展的,比如:web服务、微服务、数据存储服务等,加上一些机器就能一起扛量,都是流量的路由和中转,对应的服务够纯粹,可以独立提供对于的服务。
    2:系统拆分的模式?
    2-1:面向流程——分层架构,数据流程非业务流程
    2-2:面向服务——微服务,倾向于站在外部视角而言
    2-3:面向功能——微内核,倾向于站在内部视角而言
    3:规则引擎是常用的一种支持可扩展的方式,按照今天的分析,它属于哪一类?
    规则引擎没具体弄过,不过我感觉类似状态转换,是一个功能型的东东。也可通过排除法比较清晰的,看出它应该属于面向功能的类型。

    作者回复: 回答正确

    2019-09-01
    1
  • 微风
    李老师能说说OSGI吗

    作者回复: 下一章会简单介绍一下

    2018-09-28
    1
  • 孙振超
    规则引擎更多的是对变化比较频繁、参数比较多、条件组合比较多场景下的一种相对优雅的解决方法,可以归属为服务或功能层面,具体是功能还是服务要看切分的粒度。比如判断当前操作者是否为用户本人,可以采用规则引擎来实现,但这是一个服务还是功能就需要看具体的切分粒度和实现方式。

    作者回复: 通常规则引擎还是按功能拆分更方便实施

    2018-09-09
    1
  • Will
    面向流程是否可以这样理解,比如电商网站下单的流程。登陆、浏览商品、加入购物车、结算、下单、支付、收货、评价等。拆完就是用户服务、商品服务、订单服务、评价服务等。谢谢华仔这么赞的所有章节!

    作者回复: 是的,这就是面向流程拆分,同样是这个电商案例,如果按照男装,女装,电器拆分,就是面向服务拆分

    2018-07-17
    1
  • Tom
    面向服务拆分的具体表现形式是每个服务部署为一个子系统,面向功能拆分的具体表现形式是怎样的呢,新功能一个dll?

    作者回复: 微内核,规则引擎

    2018-07-16
    1
  • 空档滑行
    感觉像是按功能拆分,一个模块可能之前只支持一两个规则,在有新的功能要加进来时可以只添加具体功能的实现,嵌入到原来的流程中。比如我们之前做的积分系统,各种活动获取积分时翻倍,新的活动规则都是用插件的方式添加的,不知道这个算不算。

    作者回复: 是的,功能拆分

    2018-07-10
    1
  • 但莫
    规则引擎可能是面向流程和面向功能两种拆分方式相结合。
    流程规划每一层的职责,并规划好处理流程,在每一层可按功能模块进行拆分和管理,更容易添加新的规则。

    如果系统做的更大一些可能还会引入soa。把没一层或每一层中的模块拆分成单独的服务。
    2018-07-10
    1
  • narry
    感觉规则引擎是面向流程的拆分,将规则的生命周期拆分成了:设计和执行两步

    作者回复: 规则引擎最终还是要完成功能的呀,不是把规则拆分为设计和执行

    2018-07-10
    1
  • 业余爱好者
    服务是个逻辑概念,功能实现了服务。每个服务(功能)的执行都有一定的流程。如:

    public interface LoginService{
        void login();
    }

    public class PhoneLoginService implements LoginService{
        @Override
        public void login(){
            //1. 流程1
            doA();
            //2. 流程2
            doB();
            //......

        }
    }

    2019-09-24
  • Geek_88604f
    规则引擎由推理引擎发展而来,是一种嵌入在应用程序中的组件,实现了将业务决策从应用程序代码中分离出来,并使用预定义的语义模块编写业务决策。接受数据输入,解释业务规则,并根据业务规则做出业务决策。它最大的价值是实现了业务决策和应用的分离,也就是说最开始应用和规则是耦合在一起的,随着业务的发展规则越来越多,代码越来越难维护,迫切需要将规则分离出去,规则引擎应运而生,变成了应用的决策支持层。从这一点上来讲它属于流程的扩展性。
            由于大数据和人工智能的发展,决策层的
    功能也变得越来越强大和丰富,往往又引入了基于大数据和人工智能的决策方式,规则引擎是其中之一。从这一点上来讲它属于功能的扩展。
            规则引擎是通用的能力,离开了具体的应用就不会产生价值,通常要应用传递参数才能给出决策。从这一点上看它不属于服务的扩展。

    作者回复: 属于功能扩展

    2019-09-19
  • gkb111
    可扩展性三种架构
    分层架构,固定的内核,移动的数据如,展示层,业务层,数据层,存储层
    面向服务架构,微服务,osa
    面向功能
    2019-04-19
  • 日光倾城
    规则引擎我觉得是基于功能的

    作者回复: 是的

    2019-03-24
  • 乘风
    规则引擎:规则引擎由推理引擎发展而来,是一种嵌入在应用程序中的组件,实现了将业务决策从应用程序代码中分离出来,并使用预定义的
    语义模块编写业务决策。接受数据输入,解释业务规则,并根据业务规则做出业务决策。
    规则引擎将输入的数据根据业务规则做决策,根据不同功能拆分成不同的业务规则,是面向功能拆分,微内核,如注册功能可以根据不同的注册方式
    拆分成的不同的注册功能,手机号、第三方快登等。
    2018-12-06
  • 文竹
    规则引擎是微内核架构,面向具体功能,因为引擎是由中端用户来定的,架构师设计时考虑由功能指导。
    2018-08-25
收起评论
30
返回
顶部