架构师三大难-领域划分问题

引子

在《架构师之路-redis集群解析》提到:提出有水平的问题、做出有水平的总结和建议、做出有水平的回答 是架构师面临的三大难。

天天开会,最怕开会。开会十分钟,准备半天功。

架构师三大难-领域划分问题_第1张图片

 

 

下面是围绕这三大难展开的故事。

 

情景-领域划分问题

几年前的一天,在一个会上,完全不相关的团队人员在进行我们系统的架构评审。由于他们对我的系统不了解,提的问题多是针对架构师个人能力上的。

我在介绍的时候提到:“根据系统的特点,按照角色划分领域的同时结合现有人员情况划分了下面几个应用……”,然后我被打断了,有人提问说:“应用是按领域划分还是按照人员划分?”

针对这种埋坑的问题,选项有A和B,那更合理的答案一般是C。图片

架构师三大难-领域划分问题_第2张图片

翻译提问者的问题其实是在问:“不是都是用领域划分领域吗?按照人员划分的方法不对吧?”

先来分析一下,我顺着提问者的话说会怎样:“模块需要按照领域划分,模块是分层级的。人员划分决定的是独立部署单位的粒度,在实际项目中应该综合考虑。”

这样虽然回答了提问者的问题,但是提问者很显然有知识上的盲区,需要我给他解惑的地方:“究竟要怎样划分应用?”而我的回答没有给出他完整的答案,他会继续找一些回答的漏洞来细化问题,比如:“资源预算不算做考虑粒度的因素吗?” 假定我每次顺着他的思路来,整个回答过程就没有清晰的结构了。

架构师三大难-领域划分问题_第3张图片

所以我需要直接针对他本质的问题展开回答,以下是回答内容:

在这次介绍的系统中,最主要的依据是按照领域来划分模块,同时根据资源和人员等情况来决定独立部署的应用模块的粒度。

但是在其他的系统中,根据不同的系统特点,模块或者应用的划分上,考虑侧重点会有所不同。我举几个例子。

示例一(管道过滤器模式)

比如工作流类的系统,从总体架构上采用的是管道过滤器模式

架构师三大难-领域划分问题_第4张图片

如上图,在这种系统中主要有两种角色,一种是管理者角色,负责把其他模块组织串联起来,整体对外提供服务。记得之前做个这样的项目,管理者角色的模块系统名叫captain(当时大家都以漫威英雄人物命名,captain对应美国队长)。其他模块都是一个个过滤器。是否要将每个过滤器独立应用部署,还是主要根据人力和资源来定。只要设计清晰,将来人力和资源有调整,或者随着业务的发展,对稳定性有个更好的要求,可能会需要根据可用性做一个隔离。高SLA和低SLA的单独部署,高SLA的多地区多机房部署。

示例二(三平面分离模式)

比如三平面分离架构系统,详情可参考我之前的文章《三平面分离架构》。简单来说分成最核心的流程控制平面、次核心的组件支撑平面和SLA只要求两个9的管理运维平面。如下图:

架构师三大难-领域划分问题_第5张图片

所以领域划分时这三个平面要边界分明,三个平面可用性级别不同,资源分配也不同。比如最核心的流程控制平台日志存储要90天,其他可能需要30天;流程控制平面可能需每笔请求开始和结束打日志,而其他服务只需要异常时打日志;流程控制平面和组件支撑平面需要四地八中心高可用部署,而管理运维平台只需要两机房容灾。所以核心是要将三个平面分开以分配不同的资源。

示例三(异步处理模式)

有些应用整体是实现一个大职责,但是被中间件分成了两个部分。比如有个服务是异步处理模式。所谓异步处理模式是将一个执行耗时长的流程分成两个阶段。比如退款操作。用户提交一个退款请求,先会收到一个实时通知:“您的退款请求已经收到,退款会于1~2个工作日内到账。”之后系统会将这个退款请求扔到MQ中,慢慢来消费处理。

这种模式的服务,根据实际资源等情况可以分成两个独立部署的系统,或者合在一个应用里既作为MQ的生产者又作为MQ的消费者。

 架构师三大难-领域划分问题_第6张图片

 

总结

如果观察到别人总是就细节进行追问,这时候可以先把思路跳出来弄清楚他的本质问题是什么。

 

推荐阅读

服务设计要解决的问题

分布式存储系统的一致性-可见性差异

代码荣辱观-以运用风格为荣,以随意编码为耻

程序员如何破局前行

你可能感兴趣的