系统架构正交分解法

[Architecture] 系统架构正交分解法

[Architecture] 系统架构正交分解法

前言

随着企业成长,支持企业业务的软件,也会越来越庞大与复杂。当系统复杂到一定程度,开发人员会发现很多系统架构的设计细节,很难有条理、有组织的用一张大蓝图去做分析设计。先前在InfoQ上看到一篇文章:「亿级用户下的新浪微博平台架构 - 卫向军」,在这篇文章里使用正交分解法,来分析设计新浪微博平台的系统架构。

透过正交分解法这样表格式的条列与分解,可以让开发人员清楚理解每个象限的关注点,进而去理解与组织整个系统架构所使用到的框架技术。本篇文章介绍如何使用正交分解法来分析设计系统架构,主要为自己留个纪录,也希望能帮助到有需要的开发人员。

水平分层

使用正交分解法来分析设计系统架构,要先拆解出水平分层。水平分层的拆解方式,开发人员可以依照N-Tier的切割方式来拆解水平分层。在本篇文章的后续范例里,使用经典的三层式架构来拆解水平分层:

  • 表示层(Presentation):表示层用来分类与组织,系统所提供的功能接口。这边所定义的功能接口,会有两种概念,一种是给人使用的功能接口,一种是给计算机看的功能接口。例如一个对帐系统,可能提供HTML页面给用户使用、也可能提供RESTful API给其他系统调用。这些功能接口的分析、设计、实作,会被归类到表示层的象限范围。
  • 领域层(Domain):领域层用来分类与组织,系统所提供的领域逻辑。软件是用来处理特定领域的问题,每个软件透过程序代码将问题的解决方案,封装成为函式库或是一组对象来提供系统使用,这些也就是所谓的领域逻辑。这些领域逻辑的分析、设计、实作,会被归类到领域层的象限范围。
  • 存取层(Accesses):存取层用来分类与组织,系统所使用的存取媒介。系统运作的过程中,需要将一些参数、纪录、数据...等等讯息,持久化的保存到数据库以利后续使;或是需要从其他系统中取得这些相关讯息来进行处理。这些存取媒介的分析、设计、实作,会被归类到存取层的象限范围。

垂直分层

传统上,将系统依照特性与范围来拆解出N-Tier的架构之后,就可以开始着手进行每个Tier里面功能模块的分析设计。但使用正交分解法来分析设计系统架构,拆解出水平分层之后,还要接着拆解出垂直分层。垂直分层的拆解方式,开发人员可以依照不同的需求面向来拆解垂直分层。在本篇文章的后续范例里,使用「亿级用户下的新浪微博平台架构 - 卫向军」里的几个需求面向来拆解垂直分层:

  • 技术架构:技术架构用来分类与组织,面向平台需求的功能模块。系统里不牵扯领域逻辑、平台级重用的功能模块,会被分类到技术架构这个垂直分层。例如:一个自定义的WebAPI框架,包含了Token登入、数据加密、Route分派等等功能,这些功能属于不牵扯领域逻辑、并且可以做为平台反复提供其他功能模块使用。这些功能模块、框架、策略,会被归类到技术架构的象限范围。
  • 应用架构:应用架构用来分类与组织,面向领域需求的功能模块。系统里封装领域逻辑、互相交互的功能模块,会被分类到应用架构这个垂直分层。例如:一个商城系统里会包含了,订单追踪、客户数据、商家评价等等功能模块,这些功能模块封装系统的领域逻辑,并且互相交互。这些功能模块、框架、策略,会被归类到应用架构的象限范围。
  • 监控架构:监控架构用来分类与组织,面向维运需求的功能模块。系统里不牵扯领域逻辑、封装监控逻辑的功能模块,会被分类到监控架构这个垂直分层。例如:一个RPC监控模块,包含了RPC响应时间、RPC每秒负载等等功能,这些功能属于不牵扯领域逻辑、并且封装了监控逻辑。这些功能模块、框架、策略,会被归类到监控架构的象限范围。

01.技术架构x表示层

「技术架构x表示层」这个象限里,开发人员可以把关注点放在:不牵扯领域逻辑、平台级重用、用于表示层。以上述关注点去发想,可以发想出不管是选择ASP.NET MVC或是Spring MVC来开发系统的表示层,都免不了会依照系统或企业的需求与特性,去精炼出自己的表示层框架,用来提高系统的产量与产值。类似像这些功能模块、框架、策略,会被归类到「技术架构x表示层」的象限范围。在本节的后续说明里,介绍一些常见的功能模块、框架与策略:

  • WebSite框架:WebSite框架封装了Route分派、Passwod验证、Cookie验证、OAuth验证、Model串行化\反串行化、HTML渲染...等等功能。这个WebSite框架,支撑「应用架构x表示层」里的功能模块开发HTML Page给外部用户使用。并且该框架开放接口让「监控架构x表示层」,能够监控WebSite的响应时间、在线人数、热门页面等等信息。
  • WebAPI框架:WebAPI框架封装了Route分派、Passwod验证、Token验证、Model串行化\反串行化...等等功能。这个WebAPI框架,支撑「应用架构x表示层」里的功能模块开发REST API给外部系统使用。并且该框架开放接口让「监控架构x表示层」,能够监控WebAPI的响应时间、每秒负载、错误纪录等等信息。

02.技术架构x领域层

「技术架构x领域层」这个象限里,开发人员可以把关注点放在:不牵扯领域逻辑、平台级重用、用于领域层。以上述关注点去发想,可以发想出在领域层里的每个功能模块之间的互相交互,需要建立平台级的分布式框架来提供:服务注册与发现、远程调用、定时执行等等功能,用来提高系统的产量与产值。类似像这些功能模块、框架、策略,会被归类到「技术架构x领域层」的象限范围。在本节的后续说明里,介绍一些常见的功能模块、框架与策略:

  • 服务协调框架:服务协调框架封装了服务注册、服务查询、服务心跳...等等功能。这个服务协调框架,支撑「应用架构x领域层、表示层」里的功能模块,获取相依功能模块的联机信息与存活状态。并且该框架开放接口让「监控架构x领域层」,能够监控功能模块的服务数量、存活状态等等信息。
  • 远程调用框架:远程调用框架封装了供应端建立、消费端建立、同步调用、异步调用、错误处理...等等功能。这个远程调用框架,支撑「应用架构x领域层」里的功能模块,建立供应端来提供远程调用服务。支撑「应用架构x领域层、表示层」里的功能模块,建立消费端来使用远程调用服务。并且该框架开放接口让「监控架构x领域层」,能够监控功能模块的响应时间、每秒负载、错误纪录等等信息。
  • 消息队列框架:消息队列框架封装了建立队列、发送消息、取得消息、分发策略...等等功能。这个消息队列框架,支撑「应用架构x领域层」里的功能模块,建立消息队列来循序处理消息。支撑「应用架构x领域层、表示层」里的功能模块,建立发送端来发送消息到消息队列。并且该框架开放接口让「监控架构x领域层」,能够监控消息队列的处理时间、每秒负载、队列堆积数量等等信息。
  • 排程作业框架:排程作业框架封装了建立作业、定时执行作业、定期执行作业、错误处理...等等功能。这个排程作业框架,支撑「应用架构x领域层、表示层」里的功能模块,建立排程执行的作业来调用服务或是发送消息。并且该框架开放接口让「监控架构x领域层」,能够监控排程作业的处理时间、执行纪录、错误纪录等等信息。

03.技术架构x存取层

「技术架构x存取层」这个象限里,开发人员可以把关注点放在:不牵扯领域逻辑、平台级重用、用于存取层。以上述关注点去发想,可以发想出在存取层里为了因应大量用户的问题,需要提供平台级的大并发策略与框架,用来增加存取效能、回避存取效能瓶颈。类似像这些功能模块、框架、策略,会被归类到「技术架构x存取层」的象限范围。在本节的后续说明里,介绍一些常见的功能模块、框架与策略:

  • 资料快取框架:数据快取框架封装了数据快取策略方针、快取建立、快取使用、快取清除...等等功能。这个数据快取框架,指引「应用架构x存取层」里的储存媒介,如何进行数据快取的相关设计。支撑「应用架构x领域层」里的功能模块,透过框架功能来建立与使用L1\L2快取数据。并且该框架开放接口让「监控架构x存取层」,能够监控数据快取框架的快取命中率、快取负载等等信息。
  • 读写分离框架:读写分离框架封装了读写分离策略方针、读写分离新增、读写分离查询...等等功能。这个读写分离框架,指引「应用架构x存取层」里的储存媒介,如何进行分表分库的相关设计。支撑「应用架构x领域层」里的功能模块,透过框架功能来新删修查被分割的储存媒介。并且该框架开放接口让「监控架构x存取层」,能够监控读写分离框架的查询效能、数据负载等等信息。
  • 分库分表框架:分库分表框架封装了分库分表策略方针、分库分表新增、分库分表查询...等等功能。这个分库分表框架,指引「应用架构x存取层」里的储存媒介,如何进行分表分库的相关设计。支撑「应用架构x领域层」里的功能模块,透过框架功能来新删修查被分割的储存媒介。并且该框架开放接口让「监控架构x存取层」,能够监控分库分表框架的查询效能、数据负载等等信息。

04.应用架构x表示层

「应用架构x表示层」这个象限里,开发人员可以把关注点放在:封装领域逻辑、应用表示层。系统里所封装的领域逻辑,需要透过这个象限的封装,才能开放给外部系统或是用户使用。开发人员可以依照领域逻辑的面向,来分类与组织表示层所封装的功能模块。这些功能模块会使用「技术架构x表示层」所提供的框架,来建立REST API或是Web Page给外部系统与用户使用。并且使用「技术架构x领域层」所提供的功能模块,来调用「应用架构x逻辑层」里所封装的领域逻辑。

05.应用架构x领域层

「应用架构x领域层」这个象限里,开发人员可以把关注点放在:封装领域逻辑、应用领域层。系统里提供的所有领域逻辑,都会被封装成为这个象限里一个一个的功能模块。开发人员可以依照领域逻辑的面向,来分类与组织领域层所封装的功能模块。这些功能模块会使用「技术架构x领域层」所提供的框架,来提供与使用领域逻辑。并透过「技术架构x存取层」所提供的功能模块,来存取「应用架构x存取层」里所的持久化资料。

06.应用架构x存取层

「应用架构x存取层」这个象限里,开发人员可以把关注点放在:封装领域逻辑、应用存取层。系统里所有领域逻辑执行过程所产生的持久化数据,都会被储存在这些象限里。开发人员可以依照系统的需求,来选择储存媒介的类型。这些储存媒介,透过「技术架构x存取层」所提供的策略方针来设计规划。并且透过「技术架构x存取层」所提供的功能模块,让「应用架构x领域层」能够存取位于存取媒介内的持久化数据。

07.监控架构x表示层、逻辑层、存取层

「监控架构x表示层、逻辑层、存取层」这个象限里的功能模块,依照「技术架构x表示层、逻辑层、存取层」对应层级所开放的接口,来监控对应功能模块的各项参数。例如:监控「技术架构x表示层」里WebSite框架的响应时间、在线人数、热门页面等等信息。以监控平台的设计来说,从技术架构的层面切入,尽量减少对于应用架构的侵入,可以有效降低应用架构的复杂度,进而增加系统的产值与产能,并且也不会减少系统监控的相关能力。

结语

正交分解法将系统架构切割为水平的N-Tier、与垂直的需求面向,再去交互切割组合每个象限的不同关注点。并且依照项目需求,还可以做更复杂的条件扩充。例如:水平分层可以加入提供Mobile、HTML5 SPA的Tier;垂直分割可以加入面向测试、面向布署的需求面向。

透过正交分解法这样的切割方式,可以减少开发人员每个象限所需要思考的关注点;并且表格象限式的分析设计,也减少开发人员遗漏某个关注点的可能性。不管是开发新系统、或是审视旧系统,都非常推荐开发人员尝试看看。

参考数据

时间: 2024-10-08 20:41:58

系统架构正交分解法的相关文章

[Architecture] 系统架构正交分解法

[Architecture] 系统架构正交分解法 前言 随着企业成长,支持企业业务的软件,也会越来越庞大与复杂.当系统复杂到一定程度,开发人员会发现很多系统架构的设计细节,很难有条理.有组织的用一张大蓝图去做分析设计.先前在InfoQ上看到一篇文章:「亿级用户下的新浪微博平台架构 - 卫向军」,在这篇文章里,使用正交分解法,来分析设计新浪微博平台的系统架构. 透过正交分解法这样表格式的条列与分解,可以让开发人员清楚理解每个象限的关注点,进而去理解与组织整个系统架构所使用到的框架技术.本篇文章介绍

架构思维—软件架构—系统架构—系统—大局观、系统观(结构与秩序)、还原论(分与合)

架构思维—软件架构—系统架构—系统—大局观.系统观(结构与秩序).还原论(分与合) 最高层次的规划,难以改变的决定 分解仅仅是加速开发和降低问题复杂度,如果分解后的内容无法集成在一起,那么分解就没有任何意义.分解+集成可以理解为架构最核心的思考方式和方法. https://zhuanlan.zhihu.com/p/30679273 架构的本质 一个软件系统随着功能越来越多,调用量急剧增长,整个系统逐渐碎片化,越来越无序,最终无法维护和扩展,所以系统在一段时间的野蛮生长后,也需要及时干预,避免越来

系统架构师上午考试总结

系统架构师上午考试总结 Table of Contents 1 2009年有上午考试 1.1 试题7,8 1.2 试题15 1.3 试题19 1.4 试题20 1 2009年有上午考试 1.1 试题7,8 设关系模式R{U,F},其中R上的属性集U={A,B,C,D,E},R上的函数依赖集 F={A->B,DE->B,CB->E,E->A,B->D}.___为关系R的候选关键字.分解___是无损连接,并是 持函数依赖的. (7) A. AB B. DE C. CE D. DB

互联网DSP广告系统架构及关键技术解析

互联网DSP广告系统架构及关键技术解析 宿逆 关注 1.9 2017.10.09 17:05* 字数 8206 阅读 10271评论 2喜欢 60 广告和网络游戏是互联网企业主要的盈利模式 广告是广告主通过媒体以尽可能低成本的方式与用户达成接触的商业行为.也就是说按照某种市场意图接触相应人群,影响其中潜在用户,使其选择广告主产品的几率增加,或对广告主品牌产生认同,通过长期的影响逐步形成用户对品牌的转化. 一个好的DSP系统需要满足: 拥有强大的RTB(Real-Time Bidding)的基础设

秒杀系统架构分析与实战

0 系列目录 秒杀系统架构 秒杀系统架构分析与实战 1 秒杀业务分析 正常电子商务流程 (1)查询商品:(2)创建订单:(3)扣减库存:(4)更新订单:(5)付款:(6)卖家发货 秒杀业务的特性 (1)低廉价格:(2)大幅推广:(3)瞬时售空:(4)一般是定时上架:(5)时间短.瞬时并发量高: 2 秒杀技术挑战 假设某网站秒杀活动只推出一件商品,预计会吸引1万人参加活动,也就说最大并发请求数是10000,秒杀系统需要面对的技术挑战有: 对现有网站业务造成冲击 秒杀活动只是网站营销的一个附加活动,

大型网站系统架构的演化(转)

前言 一个成熟的大型网站(如淘宝.京东等)的系统架构并不是开始设计就具备完整的高性能.高可用.安全等特性,它总是随着用户量的增加,业务功能的扩展逐渐演变完善的,在这个过程中,开发模式.技术架构.设计思想也发生了很大的变化,就连技术人员也从几个人发展到一个部门甚至一条产品线.所以成熟的系统架构是随业务扩展而完善出来的,并不是一蹴而就:不同业务特征的系统,会有各自的侧重点,例如淘宝,要解决海量的商品信息的搜索.下单.支付,例如腾讯,要解决数亿的用户实时消息传输,百度它要处理海量的搜索请求,他们都有各

dubbo框架----探索-大型系统架构设计(图解)

对于高并发系统的架构要求: 1. 负载均衡 2.高并发 3.高可用 4.面向服务架构 (Dubbo框架使用) 5.分布式缓存 (redis分布式缓存) 6.分布式全文检索 (solr分分布式全文检索) 7.分布式数据库集群 (mycat 集群mysql数据库) dubbo  简介 系统架构 redis 集群 solr 集群 mysql 集群

大型网站系统架构的演化

前言 一个成熟的大型网站(如淘宝.京东等)的系统架构并不是开始设计就具备完整的高性能.高可用.安全等特性,它总是随着用户量的增加,业务功能的扩展逐渐演变完善的,在这个过程中,开发模式.技术架构.设计思想也发生了很大的变化,就连技术人员也从几个人发展到一个部门甚至一条产品线.所以成熟的系统架构是随业务扩展而完善出来的,并不是一蹴而就:不同业务特征的系统,会有各自的侧重点,例如淘宝,要解决海量的商品信息的搜索.下单.支付,例如腾讯,要解决数亿的用户实时消息传输,百度它要处理海量的搜索请求,他们都有各

秒杀系统架构分析与实战(参考、转载)

目录[-] 0 系列目录 1 秒杀业务分析 2 秒杀技术挑战 3 秒杀架构原则 4 秒杀架构设计 4.1 前端层设计 4.2 站点层设计 4.3 服务层设计 4.4 数据库设计 4.4.1 基本概念 4.4.2 设计思路 5 大并发带来的挑战 5.1 请求接口的合理设计 5.2 高并发的挑战:一定要“快” 5.3 重启与过载保护 6 作弊的手段:进攻与防守 6.1 同一个账号,一次性发出多个请求 6.2 多个账号,一次性发送多个请求 6.3 多个账号,不同IP发送不同请求 7 高并发下的数据安全