架构师三大难-领域划分问题
作者：互联网
引子
在《架构师之路-redis集群解析》提到：提出有水平的问题、做出有水平的总结和建议、做出有水平的回答 是架构师面临的三大难。
天天开会，最怕开会。开会十分钟，准备半天功。
下面是围绕这三大难展开的故事。
情景-领域划分问题
几年前的一天，在一个会上，完全不相关的团队人员在进行我们系统的架构评审。由于他们对我的系统不了解，提的问题多是针对架构师个人能力上的。
我在介绍的时候提到：“根据系统的特点，按照角色划分领域的同时结合现有人员情况划分了下面几个应用……”，然后我被打断了，有人提问说：“应用是按领域划分还是按照人员划分？”
针对这种埋坑的问题，选项有A和B，那更合理的答案一般是C。
翻译提问者的问题其实是在问：“不是都是用领域划分领域吗？按照人员划分的方法不对吧？”
先来分析一下，我顺着提问者的话说会怎样：“模块需要按照领域划分，模块是分层级的。人员划分决定的是独立部署单位的粒度，在实际项目中应该综合考虑。”
这样虽然回答了提问者的问题，但是提问者很显然有知识上的盲区，需要我给他解惑的地方：“究竟要怎样划分应用？”而我的回答没有给出他完整的答案，他会继续找一些回答的漏洞来细化问题，比如：“资源预算不算做考虑粒度的因素吗？” 假定我每次顺着他的思路来，整个回答过程就没有清晰的结构了。
所以我需要直接针对他本质的问题展开回答，以下是回答内容：
在这次介绍的系统中，最主要的依据是按照领域来划分模块，同时根据资源和人员等情况来决定独立部署的应用模块的粒度。
但是在其他的系统中，根据不同的系统特点，模块或者应用的划分上，考虑侧重点会有所不同。我举几个例子。
示例一(管道过滤器模式)
比如工作流类的系统，从总体架构上采用的是管道过滤器模式
如上图，在这种系统中主要有两种角色，一种是管理者角色，负责把其他模块组织串联起来，整体对外提供服务。记得之前做个这样的项目，管理者角色的模块系统名叫captain（当时大家都以漫威英雄人物命名，captain对应美国队长）。其他模块都是一个个过滤器。是否要将每个过滤器独立应用部署，还是主要根据人力和资源来定。只要设计清晰，将来人力和资源有调整，或者随着业务的发展，对稳定性有个更好的要求，可能会需要根据可用性做一个隔离。高SLA和低SLA的单独部署，高SLA的多地区多机房部署。
示例二(三平面分离模式)
比如三平面分离架构系统，详情可参考我之前的文章《三平面分离架构》。简单来说分成最核心的流程控制平面、次核心的组件支撑平面和SLA只要求两个9的管理运维平面。如下图：
所以领域划分时这三个平面要边界分明，三个平面可用性级别不同，资源分配也不同。比如最核心的流程控制平台日志存储要90天，其他可能需要30天；流程控制平面可能需每笔请求开始和结束打日志，而其他服务只需要异常时打日志；流程控制平面和组件支撑平面需要四地八中心高可用部署，而管理运维平台只需要两机房容灾。所以核心是要将三个平面分开以分配不同的资源。
示例三(异步处理模式)
有些应用整体是实现一个大职责，但是被中间件分成了两个部分。比如有个服务是异步处理模式。所谓异步处理模式是将一个执行耗时长的流程分成两个阶段。比如退款操作。用户提交一个退款请求，先会收到一个实时通知：“您的退款请求已经收到，退款会于1~2个工作日内到账。”之后系统会将这个退款请求扔到MQ中，慢慢来消费处理。
这种模式的服务，根据实际资源等情况可以分成两个独立部署的系统，或者合在一个应用里既作为MQ的生产者又作为MQ的消费者。
总结
如果观察到别人总是就细节进行追问，这时候可以先把思路跳出来弄清楚他的本质问题是什么。
推荐阅读
标签：退款,大难,系统,划分,模块,平面,架构师,提问者 来源： https://www.cnblogs.com/xiexj/p/15581555.html