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