每个程序员心中都有一个成为架构师的梦想，梦想是美好的，但道路是曲折的。
我大概在 2006 年开始参与架构设计，原本以为学习架构设计就像学习一门编程语言一样，先学习一下基本的语法，再研究一下细节和原理，然后实践一下就能够快速掌握。但真正实践后才发现，架构设计的难度和复杂度要高很多。从最早开始接触架构设计，到自我感觉初步完整掌握架构设计，至少花费了 6 年时间。等到自我感觉彻底掌握架构设计的精髓，至少花费了 8 年的时间（当然，这个过程中我不是一直在做架构设计）。
我曾经以为是自己天资愚笨才会这样，后来我带了团队，看到几乎每个程序员在尝试架构设计的时候，都面临着我曾经遇到过的各种困惑和瓶颈。特别是我作为职业等级晋升评委的时候，发现很多同学技术能力很强，业务也很不错，但却卡在了架构设计这部分。我意识到这应该不是个人天资的问题，而是架构设计本身的一些特性导致的。
我总结几个架构设计相关的特性：
1. 架构设计的思维和程序设计的思维差异很大。
架构设计的关键思维是判断和取舍，程序设计的关键思维是逻辑和实现。很多程序员在转换为架构师后，很难一开始就意识到这个差异，还是按照写代码的方式去思考架构，会导致很多困惑。
2. 架构设计没有体系化的培训和训练机制。
大学的课程几乎没有架构设计相关的课程，架构设计的书籍更多的也只是关注某个架构设计点，没有体系化的架构设计书籍，导致程序员在学习上没有明确指导，只能自己慢慢摸索，效率低，容易踩坑。
3. 程序员对架构设计的理解存在很多误区。
例如：要成为架构师必须要有很强的技术天分；架构师必须有很强的创造力；架构设计必须要高大上才能体现架构师能力；架构一定要具备高可用、高性能……这些似是而非的误区让很多技术人员望而生畏，还没尝试就已经放弃了。
得益于移动互联网技术的快速发展，我在加入 UC 后有很多的机会直接参与架构设计，这些架构背后的业务形形色色，包括社交、电商、游戏、中间件、内部运营系统；用到的技术栈差异也比较大，包括 PHP，Java、C++ 等。虽然每次架构设计对我来说都是一个新的挑战，但正好也提供了非常好的机会，让我亲身体验不同的架构设计。在这个过程中，我不断学习、思考、实践、总结、改进、交流，逐步形成了自己的一套架构设计方法论。
有了这套方法论后，首先，我自己在做架构设计的时候游刃有余，不管什么样的业务，不管什么样的技术，按照这套方法论都能够设计出优秀的架构。在职业等级面评的时候，就算我之前从来没有接触过对方的业务，也能快速理解对方描述的架构和发现其中做得好或者做得不好的地方；其次，在指导其他同事的时候效果明显。原来对架构设计比较迷茫的同学，通过几次结合案例进行的方法论培训，都能够很快地掌握这套方法论并在实践中应用。甚至有很多其他业务线的同学，遇到架构设计的困惑，也来找我交流和指导。
我是一个很喜欢分享的人，经常在 InfoQ 写文章、在知乎写回答，当看到别人在经过我的指导后恍然大悟甚至醍醐灌顶的那种神态，或者发自内心由衷感谢的时候，我自己也会很有成就感。我在极客时间的专栏《从 0 开始学架构》，将与你分享我的架构设计方法论，希望能够帮助更多怀揣架构师梦想的同学早日实现自己的梦想。
这个专栏涵盖了我的整套架构设计方法论和架构实践，主要包括以下内容。
架构基础：我会先介绍架构设计的本质、历史背景和目的，然后从复杂度来源以及架构设计的原则和流程来详细介绍架构基础。
高性能架构模式：我会从存储高性能、计算高性能方面，介绍几种设计方案的典型特征和应用场景。
高可用架构模式：我会介绍 CAP 原理、FMEA 分析方法，分析常见的高可用存储架构和高可用计算架构，并给出一些设计方法和技巧。
可扩展架构模式：我会介绍可扩展模式及其基本思想，分析一些常见架构模式。
架构实战：我会将理论和案例结合，帮助你落地前面提到的架构原则、架构流程和架构模式。
通过本专栏的学习，你会收获：
清楚地理解架构设计相关的概念、本质、目的，避免架构师在实践过程中把握不住重点、分不清主次，眉毛胡子一把抓，导致架构设计变形或者“四不像” 。
掌握通用的架构设计原则，无论是何种业务或技术，架构师在判断和选择的时候有一套方法论可以参考，避免架构设计举棋不定，或者拍脑袋式设计。
掌握标准的架构设计流程，即使是刚开始做架构设计的新手，也能够按照步骤一步一步设计出合适的架构，避免某些步骤缺失导致错误的架构设计。
深入理解已有的架构模式，做到能够根据架构特点快速挑选合适的模式完成架构设计，或者在已有的模式上进行创新，或者将已有的模式组合出新的架构。
掌握架构演进和开源系统使用的一些技巧。
好的开始是成功的一半，希望专栏的内容能够有效地帮助你更快地掌握架构设计的技巧，更好地设计出优秀的架构，实现自己心中的技术梦想！
毕竟，只要你努力，技术的梦想一定会实现！
网友评论