阿里P8级大神经验分享，怎样成为一个优秀的架构师？(一)

#指导原则
除了上述设计原则，还有一些重要的指导原则如下：

1、N+1设计：系统中的每个组件都应做到没有单点故障；

2、回滚设计：确保系统可以向前兼容，在系统升级时应能有办法回滚版本；

3、禁用设计：应该提供控制具体功能是否可用的配置，在系统出现故障时能够快速下线功能；

4、监控设计：在设计阶段就要考虑监控的手段，便于有效的排查问题，比如引入traceId、业务身份 Id 便于排查监控问题；

5、多活数据中心设计：若系统需要极高的高可用，应考虑在多地实施数据中心进行多活，至少在一个机房断电的情况下系统依然可用；

6、采用成熟的技术：刚开发的或开源的技术往往存在很多隐藏的 bug，出了问题没有很好的商业支持可能会是一个灾难；

7、资源隔离设计：应避免单一业务占用全部资源；

8、架构水平扩展设计：系统只有做到能水平扩展，才能有效避免瓶颈问题；

9、非核心则购买的原则：非核心功能若需要占用大量的研发资源才能解决，则考虑购买成熟的产品；

10、使用商用硬件：商用硬件能有效降低硬件故障的机率；

11、快速迭代：系统应该快速开发小功能模块，尽快上线进行验证，早日发现问题大大降低系统交付的风险；

12、无状态设计：服务接口应该做成无状态的，当前接口的访问不依赖于接口上次访问的状态。

架构师知道了职责，具备很好的架构思维，掌握了通用的架构框架和方法论，使用架构原则进行架构设计，不同的业务和系统要求不一样，那么有没有针对不同场景的系统架构设计？下文就针对分布式架构演进、单元化架构、面向服务 SOA 架构、微服务架构、Serverless 架构进行介绍，以便于我们在实际运用中进行参考使用。

具备架构师的思维

架构师职责明确了，那么有什么架构思维可以指导架构设计呢？请看下述的架构思维。

1、自顶向下构建架构

要点主要如下：

1）首先定义问题，而定义问题中最重要的是定义客户的问题。定义问题，特别是识别出关键问题，关键问题是对客户有体感，能够解决客户痛点，通过一定的数据化来衡量识别出来，关键问题要优先给出解决方案。

2）问题定义务必加入时间维度，把手段/方案和问题定义区分开来。

3）问题定义中，需要对问题进行升层思考后再进行升维思考，从而真正抓到问题的本质，理清和挖掘清楚需求；要善用第一性原理思维进行分析思考问题。

4）问题解决原则：先解决客户的问题（使命），然后才能解决自己的问题（愿景）；务必记住不是强调我们怎么样，而是我们能为客户具体解决什么问题，然后才是我们变成什么，从而怎么样去更好得服务客户。

5）善用多种方法对客户问题进行分析，转换成我们产品或者平台需要提供的能力，比如仓储系统 WMS 可以提供哪些商业能力。

6）对我们的现有的流程和能力模型进行梳理，找到需要提升的地方，升层思考和升维思考真正明确提升部分。

7）定义指标，并能够对指标进行拆解，然后进行数学建模。

8）将抽象出来的能力诉求转换成技术挑战，此步对于技术人员来说相当于找到了靶子，可以进行方案的设计了，需要结合自底向上的架构推导方式。

9）创新可以是业务创新，也可以是产品创新，也可以是技术创新，也可以是运营创新，升层思考、升维思考，使用第一性原理思维、生物学（进化论–进化=变异+选择+隔离、熵增定律、分形和涌现）思维等哲科思维可以帮助我们在业务，产品，技术上发现不同的创新可能。可以说哲科思维是架构师的灵魂思维。

2、自底向上推导应用架构

先根据业务流程，分解出系统时序图，根据时序图开始对模块进行归纳，从而得到粒度更大的模块，模块的组合／聚合构建整个系统架构。

基本上应用逻辑架构的推导有4个子路径，他们分别是：

• 业务概念架构：业务概念架构来自于业务概念模型和业务流程；
• 系统模型：来自于业务概念模型；
• 系统流程：来自业务流程；
• 非功能性的系统支撑：来自对性能、稳定性、成本的需要。
• 效率、稳定性、性能是最影响逻辑架构落地成物理架构的三大主要因素，所以从逻辑架构到物理架构，一定需要先对效率、稳定性和性能做出明确的量化要求。

自底向上重度依赖于演绎和归纳。

如果是产品方案已经明确，程序员需要理解这个业务需求，并根据产品方案推导出架构，此时一般使用自底向上的方法，而领域建模就是这种自底向上的分析方法。

对于自底向上的分析方法，如果提炼一下关键词，会得到如下两个关键词：

1）演绎：演绎就是逻辑推导，越是底层的，越需要演绎：

• 从用例到业务模型就属于演绎；
• 从业务模型到系统模型也属于演绎；
• 根据目前的问题，推导出要实施某种稳定性措施，这是也是演绎。

2）归纳：这里的归纳是根据事物的某个维度来进行归类，越是高层的，越需要归纳：

• 问题空间模块划分属于归纳；
• 逻辑架构中有部分也属于归纳；
• 根据一堆稳定性问题，归纳出，事前，事中，事后都需要做对应的操作，是就是根据时间维度来进行归纳。
  ##3、领域驱动设计架构
  大部分传统架构都是基于领域模型分析架构，典型的领域实现模型设计可以参考DDD（领域驱动设计），详细可以参考《实现领域驱动设计》这本书，另外《UML和模式应用》在领域建模实操方面比较好，前者偏理论了解，后者便于落地实践。

领域划分设计步骤：

• (1) 对用户需求场景分析，识别出业务全维度 Use Case。

(2) 分析模型鲁棒图，识别出业务场景中所有的实体对象。鲁棒图 —— 是需求设计过程中使用的一种方法（鲁棒性分析），通过鲁棒分析法可以让设计人员更清晰，更全面地了解需求。它通常使用在需求分析后及需求设计前做软件架构分析之用，它主要注重于功能需求的设计分析工作。需求规格说明书为其输入信息，设计模型为其输出信息。它是从功能需求向设计方案过渡的第一步，重点是识别组成软件系统的高级职责模块、规划模块之间的关系。鲁棒图包含三种图形：边界、控制、实体，三个图形如下：

(3) 领域划分，将所有识别出的实体对象进行分类。

(4) 评估域划分合理性，并进行优化。

##4、基于数据驱动设计架构
随着 IoT、大数据和人工智能的发展，以领域驱动的方式进行架构往往满足不了需求或者达不到预期的效果，在大数据时代，在大数据应用场景，我们需要转变思维，从领域分析升维到基于大数据统计分析结果来进行业务架构、应用架构、数据架构和技术架构。这里需要架构师具备数理统计分析的基础和 BI 的能力，以数据思维来架构系统，典型的系统像阿里的数据分析平台采云间和菜鸟的数据分析平台 FBI。

上述四种思维，往往在架构设计中是融合使用的，需要根据业务或者系统的需求来选择侧重思维方式。

如果我这篇文章反响不错，我将继续发表文章向大家介绍单元化架构，微服务架构以及Serveless架构。如果对你有帮助，可以点个赞支持一下小编哦。

一起来学习吧：

1.超赞：不愧是阿里内部“Spring boot学习笔记”从头到尾，全是精华

2.每一个程序员，都渴望成为一名分布式系统架构师

3.新手值得一看！初级Java工程师也能轻松进行JVM调优了

总结

大型分布式系统犹如一个生命，系统中各个服务犹如骨骼，其中的数据犹如血液，而Kafka犹如经络，串联整个系统。这份Kafka源码笔记通过大量的设计图展示、代码分析、示例分享，把Kafka的实现脉络展示在读者面前，帮助读者更好地研读Kafka代码。

麻烦帮忙转发一下这篇文章+关注我

过大量的设计图展示、代码分析、示例分享，把Kafka的实现脉络展示在读者面前，帮助读者更好地研读Kafka代码。

麻烦帮忙转发一下这篇文章+关注我

[外链图片转存中…(img-zwcPSxYI-1714820955266)]

本文已被CODING开源项目：【一线大厂Java面试题解析+核心总结学习笔记+最新讲解视频+实战项目源码】收录