引子
在《架构师之路-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
本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享； 2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关； 3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关； 4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除； 5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。