跳转至

开篇

整个文档是我对极客时间-从零开始学架构专栏的一个学习笔记。每一个章节包含如下几个部分:

  • 原文(为了方便和清晰,开头都会放上课程的原文)
  • 读者观点(学习这门课程的人的一些评论)
  • 我的观点(我学习的一些感想和笔记)

买书如山倒,读书如抽丝,终来最难还是觉知此事要躬行

如果感觉原文挺好,可以去极客时间-从零开始学架构购买支持一下。


原文

每个程序员心中都有一个成为架构师的梦想,梦想是美好的,但道路是曲折的。

我大概在 2006 年开始参与架构设计,原本以为学习架构设计就像学习一门编程语言一样,先学习一下基本的语法,再研究一下细节和原理,然后实践一下就能够快速掌握。但真正实践后才发现,架构设计的难度和复杂度要高很多。从最早开始接触架构设计,到自我感觉初步完整掌握架构设计,至少花费了 6 年时间。等到自我感觉彻底掌握架构设计的精髓,至少花费了 8 年的时间(当然,这个过程中我不是一直在做架构设计)。

我曾经以为是自己天资愚笨才会这样,后来我带了团队,看到几乎每个程序员在尝试架构设计的时候,都面临着我曾经遇到过的各种困惑和瓶颈。特别是我作为职业等级晋升评委的时候,发现很多同学技术能力很强,业务也很不错,但却卡在了架构设计这部分。我意识到这应该不是个人天资的问题,而是架构设计本身的一些特性导致的。

我总结几个架构设计相关的特性:

  1. 架构设计的思维和程序设计的思维差异很大。

架构设计的关键思维是判断和取舍,程序设计的关键思维是逻辑和实现。很多程序员在转换为架构师后,很难一开始就意识到这个差异,还是按照写代码的方式去思考架构,会导致很多困惑。

  1. 架构设计没有体系化的培训和训练机制。大学的课程几乎没有架构设计相关的课程,架构设计的书籍更多的也只是关注某个架构设计点,没有体系化的架构设计书籍,导致程序员在学习上没有明确指导,只能自己慢慢摸索,效率低,容易踩坑。

  2. 程序员对架构设计的理解存在很多误区。

例如:要成为架构师必须要有很强的技术天分;架构师必须有很强的创造力;架构设计必须要高大上才能体现架构师能力;架构一定要具备高可用、高性能……这些似是而非的误区让很多技术人员望而生畏,还没尝试就已经放弃了。

得益于移动互联网技术的快速发展,我在加入 UC 后有很多的机会直接参与架构设计,这些架构背后的业务形形色色,包括社交、电商、游戏、中间件、内部运营系统;用到的技术栈差异也比较大,包括 PHP,Java、C++ 等。虽然每次架构设计对我来说都是一个新的挑战,但正好也提供了非常好的机会,让我亲身体验不同的架构设计。在这个过程中,我不断学习、思考、实践、总结、改进、交流,逐步形成了自己的一套架构设计方法论

有了这套方法论后,首先,我自己在做架构设计的时候游刃有余,不管什么样的业务,不管什么样的技术,按照这套方法论都能够设计出优秀的架构。在职业等级面评的时候,就算我之前从来没有接触过对方的业务,也能快速理解对方描述的架构和发现其中做得好或者做得不好的地方;其次,在指导其他同事的时候效果明显。原来对架构设计比较迷茫的同学,通过几次结合案例进行的方法论培训,都能够很快地掌握这套方法论并在实践中应用。甚至有很多其他业务线的同学,遇到架构设计的困惑,也来找我交流和指导。

我是一个很喜欢分享的人,经常在 InfoQ 写文章、在知乎写回答,当看到别人在经过我的指导后恍然大悟甚至醍醐灌顶的那种神态,或者发自内心由衷感谢的时候,我自己也会很有成就感。我在极客时间的专栏《从 0 开始学架构》,将与你分享我的架构设计方法论,希望能够帮助更多怀揣架构师梦想的同学早日实现自己的梦想。

这个专栏涵盖了我的整套架构设计方法论和架构实践,主要包括以下内容。

  • 架构基础:我会先介绍架构设计的本质、历史背景和目的,然后从复杂度来源以及架构设计的原则和流程来详细介绍架构基础。
  • 高性能架构模式:我会从存储高性能、计算高性能方面,介绍几种设计方案的典型特征和应用场景。
  • 高可用架构模式:我会介绍 CAP 原理、FMEA 分析方法,分析常见的高可用存储架构和高可用计算架构,并给出一些设计方法和技巧。
  • 可扩展架构模式:我会介绍可扩展模式及其基本思想,分析一些常见架构模式。架构实战:我会将理论和案例结合,帮助你落地前面提到的架构原则、架构流程和架构模式。

通过本专栏的学习,你会收获:

  • 清楚地理解架构设计相关的概念、本质、目的,避免架构师在实践过程中把握不住重点、分不清主次,眉毛胡子一把抓,导致架构设计变形或者“四不像” 。
  • 掌握通用的架构设计原则,无论是何种业务或技术,架构师在判断和选择的时候有一套方法论可以参考,避免架构设计举棋不定,或者拍脑袋式设计。
  • 掌握标准的架构设计流程,即使是刚开始做架构设计的新手,也能够按照步骤一步一步设计出合适的架构,避免某些步骤缺失导致错误的架构设计。
  • 深入理解已有的架构模式,做到能够根据架构特点快速挑选合适的模式完成架构设计,或者在已有的模式上进行创新,或者将已有的模式组合出新的架构。
  • 掌握架构演进和开源系统使用的一些技巧。

好的开始是成功的一半,希望专栏的内容能够有效地帮助你更快地掌握架构设计的技巧,更好地设计出优秀的架构,实现自己心中的技术梦想!

毕竟,只要你努力,技术的梦想一定会实现!

各家观点

rommel: 就像李老师所说,市面上系统性讲解架构设计资料很少,这点还是很有感触的。李老师从“道”的方面为大家分享方法论和案例,我也分享一下我从“术”的角度整理的一些架构设计的知识点,https://github.com/xingshaocheng/architect-awesome

DevelDog 从我个人的工作经历来看,架构能力的获得是非常依赖于工作环境的,而大部分研发人员并没有这样的环境,所以很多经验和心得很容易沦为纸上谈兵,想问问老师怎么看待这个问题? 作者回复: 任何能力的提升都离不开知行合一,架构设计也不例外。架构设计的行可以有多重方式:亲自负责一个系统的架构设计,这种机会最锻炼人,但不可能一个工程师从来没做过架构设计然后某天突然被委以重任,必须要先有一定的积累才会有这样的机会;第二种是参与某个系统的架构设计,在总架构师的指导下,负责其中一部分的设计;第三种就是在设计好的架构下进行开发,虽然没有亲自参与架构设计,但如果能理解和看懂架构设计,对开发本身也很有帮助,如果能看出和分析出架构存在的问题,那就是一个展现自己的机会。 因此,在没有进行架构设计的时候要做好“知”的储备,并尝试运用这些知识技能去分析和研究已有系统的架构,通过这种方式逐步积累和提升,等到真正有机会的时候,能够做到快速开始,快速把握机会,然后在实践中逐步提升自己的能力。

闫飞 早期的架构师有着崇高的地位和内外影响力,而勃勃兴起的敏捷开发运动和极限编程方法论似乎又将架构师逼入了死角,乃至潘爱民老师都自嘲地解释说架构师不是已经死亡,而是他们仅仅在做俯卧撑。马丁福勒也写了设计已死的文章来分析这个论点,讲究更快地交付产品的互联网公司是如何平衡快速迭代的压力和维护产品长期可扩展可伸缩中间的矛盾是我个人心中长期思考和观察的一个问题。 安全和合规以及隐私泄露问题则是业界最近几年新暴露出来的痛点,架构师如何在这些方面去思考和取舍也是一个比较开放的问题。 期望能听到作者这方面的实践和观点。

我的观点

架构是关于取舍的学问