系统架构合理性的思考

系统,架构,合理性,思考 · 浏览次数 : 87

小编点评

**系统架构合理性定义:** 从研发的角度来看,架构合理性可以从以下三个方面来评估: 1. **系统上下文清晰:**系统上下文明确了目标系统和外部系统的关系,明确的知道和周围系统的调用关系,数据同步机制。 2. **应用架构设计简单:**架构分层合理,功能定位清晰,不会出现功能边界之外的事情。 3. **应用拆分合理:**系统内的应用粒度在一个合理的范围内,应用间调用链路不应过长。

正文

最近牵头在梳理部门的系统架构合理性,开始工作之前,我首先想到的是如何定义架构合理性?

从研发的角度来看如果系统上下文清晰、应用架构设计简单、应用拆分合理应该称之为架构合理。

基于以上的定义可以从以下三个方面来梳理评估:

1、系统的上下文清晰:明确的知道和周围系统的调用关系,数据同步机制;

2、应用架构设计简单:架构分层合理,功能定位清晰,不会出现功能边界之外事情;

3、应用拆分合理:系统内的应用粒度在一个合理的范围内;应用间调用链路不应过长。

系统的上下文清晰

系统上下文图一词最早是从Simon Brown的C4模型中借用而来的,该模型”通过在不同的抽象层次重新定义方框和虚线来抽象表达架构的含义“。

C4模型把系统分为四层,每层都代表着不同的视图架构,关注点不同。第一层,讲的系统上下文,系统高层次的抽象。

如下图显示个人银行账号在浏览账户过程中发生不同的系统之间交互。 如果把Internet Banking Sysytem 当成我们的目标系统,那么E-mail System、MarinFrame Banking Sytem 就是它的伴生系统,也可以称为外部系统,它给Internet Banking Sysytem 提供系统价值,属于系统外,是黑盒。

系统上下文明确了目标系统和外部系统的关系,它和外部系统一起给目标用户提供价值。绘制系统上下文的时候,需要注意目标系统和外部系统之间的依赖方向。北向依赖意味着外部系统调用目标系统的服务,需要考虑目标系统定义了什么样的服务契约;南向依赖意味着目标系统调用了外部系统的的服务,需要了解外部系统的接口、调用方式,通信机制,甚至当外部系统出现故障时,目标系统该如何处理。

除了参考以上的画法,也可以用业务序列图表示。它脱胎与UML的序列图。序列图可以从左侧的角色开始,体现消息传递的次序。这隐含这一种驱动力:我们从左侧的参与对象开始,寻找与之协作的执行步骤,然后层层传进地推导出整个完整的协作流程。

企业序列图,代表了企业级系统的抽象,目标系统和外部系统之间的协作关系,参与的系统是一个完整的整体,所以不需要也不应该参与系统的内部实现的细节,消息的方向更多的代表系统的责任。业务序列图如下所示:

应用架构设计简单

应用本身是有架构分层的,Martin Fowler 在《企业应用架构模式》 提出合理的系统分层应该包括表现层,领域逻辑层,数据源层。 表现层主要提供服务,处理用户请求。领域层是处理逻辑,是系统的核心。数据源层与数据层、消息系统,与其他软件包通信。

后续发展的领域驱动架构设计,演变成四层,在表现层下加入了应用层,同时把数据源层改为基础设施层,突破了数据库管理系统的限制。

基于以上的系统分层,无论你是采用的三层架构还是四层架构,应用代表着功能边界,提供那些核心的能力,能做那些事情,那些事情不能做。

一个好的实践经验是参考领域驱动设计的业务域的方法论,梳理好系统的一二三级域,最多不超过四级,做好各级域的定义。好的域的定义代表着系统能力的边界,让你明白那些事情能做,那些事情不能做。

基于以上梳理好的系统业务域的定义和能力边界,我们在梳理的时候通常会两类系统,第一类是现有存量的系统且需求迭代相对频繁的系统,这类系统关键是要梳理出有哪些核心的能力,是否在上述系统的域的定义范围内的,是否其他系统有类似的能力,如果有的话,需要考虑合并。另外还需要考虑核心能力公开化、文档化,至少让部门内知道,有地可查,避免系统的重复造轮子。

遇到第二类系统是存量系统且没有需求迭代,业务上基本没有调用量的。这类系统需要和业务沟通是否有下线计划,是否有类似的系统可以替代,给业务决策提供技术参考。

应用拆分合理

需求开发中,一个项目或者需求的实现可能需要多个目标系统协同来实现,这涉及到目标系统的拆分的粒度,系统拆分成应用的粒度没有统一标准,但是要在相对合理范围内,可以参考的因素包括业务规划,系统调用量级,基于业务规划的架构设计,部门内的人数及分工。过多过少都是不好的。

如果一个新业务短期内看不到大的发展,在初步规划应用的时候,可以先粗粒度拆分,部门内人数平均不能应该超过2-3个应用,再多必然面临着一个需求实现的时候不同系统的切换成本。如果后续业务发展起来,部门内人数增多,因为分工更精细,可以考虑更细粒度的拆分,系统拆分必然会带来另一个问题,系统之间该如何的协同以及系统的调用链路的长度。

基于以上讲的系统分层的概念,部门内系统可以分为两类,一类系统是业务网关,一类是通用的业务能力。业务网关面向用户,用来协同应用的活动,不包含业务逻辑,不保留业务对象的状态,相当于领域驱动设计应用层+表现层,有人称作它为业务SOA,或者BFF层。

通用业务能力相当于领域逻辑层+基础设施层,作为软件的核心所在,保留了业务对象的状态,对业务对象的持久化被委托给基础设施层,基础设施层作为其他层的支撑层,实现了和其他系统的通信,实现业务对象的持久化。

在以上两类系统中,业务网关是依赖通用业务能力层,业务网关是北向依赖,通用业务能力层是南向依赖。 在一个功能的实现不建议链路长度不超过2。同时也要注意到系统之间相互依赖的情况,要重视,此点是系统稳定性的风险点。

成本量化:

基于以上三方面分析,梳理出的交付物:1、系统的上下文依赖;2、 系统的业务域定义及能力规划地图。3、应用调用链路的长度及相互的依赖关系;4、应用拆分粒度合理性的评估;5、系统中能力的下沉或者合并;6、业务量少的系统列表。

其中1-4,可以看作系统的行动指南或者原则,5-6是下一步的行动,更简单的说是我们常做的系统的关停并转。在业务部门系统关停并转还需要考虑到成本问题,做好成本的量化。

首先需要评估关停并转的付出的成本,其次要评估系统日常维护1-3年的成本包括人力成本和机器资源的成本,前者和后者的三年累计值相减,如果大于零,系统建议暂时不动,如果少于零,可以考虑关停并转的计划。

以上是我从研发角度系统架构合理性的思考。

架构合理性如果从业务角度来评估,可能就变成以下三个方面:一是能解决当下业务需求和问题。2、高效完成业务需求: 能以优雅且可复用的方式解决当下所有业务问题。3、前瞻性设计: 能在未来一段时间都能以第2种方式满足业务,从而不会每次当业务进行演变时,导致架构翻天覆地的变化。

视角的不同必然代表着大家对同一件事情的看法不同。

作者:京东零售 高田林

来源:京东云开发社区 转载请注明来源

与系统架构合理性的思考相似的内容:

系统架构合理性的思考

从研发的角度来看如果系统上下文清晰、应用架构设计简单、应用拆分合理应该称之为架构合理。基于以上的定义可以从以下三个方面来梳理评估:

美团二面:SpringBoot读取配置优先级顺序是什么?

理解并合理运用Spring Boot配置加载的优先级,对于保障应用的安全性、可维护性以及降低部署复杂度至关重要。特别是在大规模微服务架构中,合理的配置管理和迁移对于整体系统的稳定性有着不可忽视的作用。

[转帖]架构修炼-10:高并发设计

一、如何衡量高并发的系统性能 1.吞吐量Throughput: 2.响应延迟Response Delay: 二、性能优化目标 1.缩短响应时间 2.提高系统并发数(提升吞吐量) 3.系统处理合理状态(机器利用率) 随着系统压力增加(X坐标:在线业务人数), Y坐标:绿色机器利用率,紫色并发数,蓝色:

[转帖]庐山真面目之十五微服务架构的动态分离的设计实现

https://www.cnblogs.com/PatrickLiu/p/16688731.html 一、开场白 我是一名程序员,是基于 NET 框架的跨平台开发的程序员。现在的业务系统,不论大小都开始实现了微服务,不管合不合适,最起码说起来挺牛气的。我做一位程序员,当然也不能落后了。微服务是为了满

[转帖]服务器体系(SMP, NUMA, MPP)与共享存储器架构(UMA和NUMA)

1 3种系统架构与2种存储器共享方式 1.1 架构概述 从系统架构来看,目前的商用服务器大体可以分为三类 对称多处理器结构(SMP:Symmetric Multi-Processor) 非一致存储访问结构(NUMA:Non-Uniform Memory Access) 海量并行处理结构(MPP:Ma

解密秒杀系统架构:不是所有的秒杀都是秒杀

摘要:究竟什么样的系统算是高并发系统?今天,我们就一起解密高并发业务场景下典型的秒杀系统的架构。 本文分享自华为云社区《【高并发】秒杀系统架构解密,不是所有的秒杀都是秒杀(升级版)!!》,作者: 冰 河。 究竟什么样的系统算是高并发系统?今天,我们就一起解密高并发业务场景下典型的秒杀系统的架构。 电

ArchKeeper (开篇):架构守护平台的问题与理念

在敏捷开发环境下,系统通过迭代增量的交付价值,系统架构也是如此。团队不可能在项目之初就建立完美的系统架构,系统架构应该随着系统迭代不断演进。架构演进和架构腐化是看待架构的不同视角:架构腐化着眼于现状,架构演进侧重于未来架构腐化不可避免,随着时间流转腐化现象必然发生。而我们需要做的是:通过某种方式及早发现和修正

下一代MES系统架构分析与选型参考

通用模型框架层由实力大厂主导、行业/工艺层由具有行业Know-How的应用开发商ISV来承担、企业用户层由系统集成商SI/企业IT人员来实施,发挥各自优势。

[转帖]构建安全可靠的系统:从SRE到SRS

https://www.jianshu.com/p/ba61020aeb1e 在看到《Google系统架构解密:构建安全可靠的系统》这本书之前,个人就有安全和可靠性不分家的观念。看到有同样想法的书籍,甚是欢喜。读完上一本书,终于可以读这一本了,接下来很长一段时间,看下Google是如何构建安全可靠系

[转帖]巧用 Docker Buildx 构建多种系统架构镜像

http://www.taodudu.cc/news/show-4511396.html?action=onClick Docker Buildx 是一个 Docker CLI 插件,其扩展了 Docker 命令,支持 Moby BuildKit 提供的功能。提供了与 Docker Build 相同