如何才能真正的提高自己，成为一名出色的架构师？

人邮异步社区

已于 2022-07-30 19:48:09 修改

阅读量806

点赞数

文章标签：架构师软件开发设计模式

于 2022-07-30 19:47:35 首次发布

本文链接：https://blog.csdn.net/epubit17/article/details/126076810

版权

架构师成长之路

对于架构师来说，他的工作是最终确认和评估系统需求，给出开发规范，然后搭建系统实现的核心构架，并澄清技术细节，扫清主要难点。在项目开发中，架构师是一个非常核心且非常重要的角色。

如何从单纯的编码人员成长为一位合格的架构师，这是一个比较大的话题。对于架构师而言，需要考虑的因素很多。他除了要具备深厚的编码功底外，系统设计能力是一个很重要的因素。

对于编码人员来说，系统设计能力也是在其初级阶段相对容易培养的能力。例如，怎么解决复杂的问题，怎么应对复杂的需求，这些问题和需求在代码实现上是怎么体现的。这些都属于系统设计能力的一部分。

对于处于技能成长初级阶段的开发人员（比如应届毕业生、只有两三年工作经验的开发人员）来说，技术的广度才是他们在这个阶段该追求的。当年我在读书的时候就梦想成为一名架构师，并为此阅读了一些与架构师相关的图书。遗憾的是，在不同的成长阶段，对架构师的理解是不一样的。当时我被各种类似“换位思考、同事配合、组织事件风暴、组织站会、周会”等理念狂轰乱炸，但我觉得这些东西太虚了，一点用处也没有。

在那个阶段，我觉得只有技术层面的提升才能给我带来满足感。比如，JVM、垃圾回收算法、操作系统、框架源码等，我掌握得越多，满足感也就越大。尽管当时我对自己的技术特别自信，但是经常也会有这样的感受：自己设计的代码接口比较混乱、代码耦合较为严重、一个类中的代码过多，等等。而且，自己开发的代码除了能够炫技之外，并不能很好地应对工作中的要求。

如今，我经常会遇到这样一些比较优秀的应届毕业生或只有两三年经验的开发人员，他们的技术很扎实，自己也写了不少代码，做了不少项目，但是他们写的代码质量真的不敢恭维，毫无设计可言。究其根本，他们并不具备设计能力。

说到设计能力，很多人都会将设计能力和设计模式的掌握联系在一起。但是从我过去的面试经验来看，无论是应届生还是资深开发人员，大部分面试者都对设计模式了如指掌，因为在面试时这些内容有很大的概率会被问到，所以他们都会精心准备。然而从开发实践来看, “对设计模式了如指掌”和“写出一手好代码”这两者之间似乎没什么必然的联系。

在经过思索之后，我觉得大致是下面的原因所致。

设计模式一般是对特定场景的抽象，但是真正的生产过程中遇到的问题往往比较多样化，需要将多个设计模式混在一起才能实现最佳的设计方式。如果刻意、生硬地去套某种设计模式，往往会使代码显得格格不入。
现实中存在浮躁、过度设计倾向等因素，因此设计出来的编码逻辑可能过于复杂或者达不到预期的效果。
现实中的系统设计往往比设计模式中的场景更复杂、更庞大。

所以，你需要有一本《读源码学架构：系统架构师思维训练之道》这样以架构师的能力培养为切入点的书，作者将过去10多年在工作中遇到的问题进行抽象，并作为示例呈现给读者。希望读者在阅读本书时，能遵循下面这一系列步骤，通过抛出问题、分析问题、解决问题的闭环方式，做到知其然知其所以然，从而快速成长为一名合格甚至优秀的架构师。

读源码学架构：系统架构师思维训练之道

全书各章内容的分布如下图所示（注：该图是按照作用于系统中的位置来绘制的。比如, SDK以及防火墙用于系统外围的设计，内部属性暴露等用于系统内核的设计）。

本书共分为4篇：基础篇、主流程设计篇、组件篇、对外篇。这4篇基本上覆盖了大部分生产环境下的系统设计。

基础篇

第1章，基本设计原则：介绍了六大设计原则——单一职责原则、开闭原则、依赖倒置原则、里氏替换原则、迪米特法则、接口隔离原则，并通过不同的场景来列举六大设计原则的背后原理、相应的思考以及使用场景。

主流程设计篇

第2章，轻松应对后续的变化：在设计主流程时，如果能拆分出主流程与分支流程，那么优先使用Postprocessor机制，先固化主流程。因为在通常情况下，主流程的变化是低频、稳定的。同时，通过预留的扩展点与主流程配合，通过对上下文参数的扩展传递以及返回结果对主流程走向的影响，不断地对主流程所能提供的功能进行完善，扩大功能覆盖面，可以灵活应对各种场景。

第3章，优雅地暴露内部属性：在考虑开闭原则时，程序要尽量做到高可扩展，因此很多时候就不得不考虑分布在函数内部以及类上的属性暴露问题。Aware机制提供了优雅的属性暴露方式。通过Aware方式进行属性暴露，可以解耦对属性生产类的依赖，使得开发人员更专注属性本身，且让属性的使用更简单，扩展性更强。

第4章，复杂逻辑的拆解与协同：在很多情况下没有办法区分主流程以及分支流程。比如，没有办法一次性确定主流程，或者说逻辑过于复杂，需要不同的模块协同处理。此时，基于PipeLine的管道模式设计或许是个不错的办法。

组件篇

第5章，复用的人性化设计：抽象是开发人员不得不考虑的问题。在持续的业务支持过程中，经常会产生大量的公共类以及公共代码，甚至代码中不得不冗余大量的胶水代码。通常，应对这种情况最简单的办法是将这些公共类以及公共代码抽象成工具类或者回调函数来解决。但是，如果大量的回调函数出现得比较频繁，也会影响到代码的可读性。这时，可以考虑将冗余代码封装并通过注解方式暴露，从而提高代码的可读性，降低使用的复杂度。

对外篇

第6章，屏蔽外部依赖的防火墙设计：软件开发行业发展到现阶段，尤其是最近微服务的流行，系统在很多情况下不得不依赖于外部系统。但是，由于外部系统对当前系统来说是一个黑盒，它的稳定性完全通过其提供方来保障，因此存在巨大的不确定因素，而且一旦处理不好就会引起服务的雪崩效应。所以，有必要构建一层防火墙。本章在设计防火墙时进行了不同层次的过滤，并在防火墙的实现上进行了职责拆分（每一层都有特定的职责）以保证逻辑上的不耦合。

第7章，事件的分散性与协议化封装：在对系统进行扩展时，不可盲目地全部通过 Postprocessor机制来实现，我们要在适合的场景进行适合的封装。例如，在使用PostProcessor 机制后再通过Aware机制传递出属性或者消息，这样可以在扩展功能层面实现二次业务的类型聚合，而不是将所有逻辑都并排在Postprocessor中。如果将所有的业务类型都基于 PostProcessor方式罗列扩展，会使得业务极为散乱，难以维护。

系统扩展有很多方式，当系统扩展能与主流程形成相互独立的两条线的时候，大部分情况下都会釆用发布订阅的事件监听机制。然而，如果业务的处理在大多数情况下都会覆盖主流程不同阶段的事件，则一般将主流程不同阶段的事件进行封装，从而让用户更为聚焦于关注点本身，以免在很多事件中挑选关注点，从而简化操作（这或许是Aware机制的延伸或者升级）。

第8章，基于Reactor模式的系统优化：在系统开发的过程中，难免会遇到系统阻塞的情况，这些阻塞可能来自于系统文件读取、远程调用等。如果我们不关注性能，则可能釆用的办法就是直接调用，或者釆用异步任务队列，逐渐处理队列中的任务，直到结束。然而，在很多情况下我们需要更高的吞吐量来应对服务请求，此时就要将同步的请求进行拆解，以免在同步处理请求期间因阻塞而带来的线程资源的浪费。

Reactor模式提供了不错的解决方案，它通过引入事件循环器EventLoop,将同步流程打散为离散事件，并通过EventLoop与AppWorker的配合隔离了阻塞调用，从而保证了计算类型任务的效率。本章提供了不同场景的解决方式，包括原生阻塞场景的处理、远程系统调用场景的处理，以及无法异步协同的阻塞场景的处理。

第9章，代码边界的延伸——善用SDK：系统在对外提供服务时有API和SDK这两种方式，尽管可以通过各种方式、各种手段来优化服务器，但是也不能忽略SDK带来的益处。合理利用SDK来分摊服务器的压力，可以帮助将服务器的性能发挥到极致，极大地增加系统的吞吐量。

所以，在设计中需要仔细评估SDK带来的优势与影响，要尽可能利用SDK的优势，尽量屏蔽SDK的劣势，从而给出最佳设计方案。