开篇词 | 学好软件架构，先从场景入手
你好，我是韦木，曾是硅谷上市公司的一名技术总监，拥有 15 年互联网技术研发经验。
随着社会节奏的日益加快，碎片化学习逐渐成了我们获取知识的主要方式。在技术学习上，我也是一个碎片化学习的人，也因此我发现学习到的东西往往零散琐碎、不系统，只是让我感觉好像学到了很多东西。
犹记得刚学习 Spring 时，每当看到 Spring 的代码示例，我先是恍然大悟：“哦，原来 Spring 还有这个功能啊”，然后赶紧把这段代码示例拷贝放入自己的代码库里。
琢磨一番后：“哎呀，不行，我还是得完整掌握 Spring”。于是乎，我又在网络上大肆寻找完整的 Spring 学习文档，不过利用碎片化时间看完一半后，我还是决定放弃了。
主要碎片化学习知识时，我往往追求实用，用得上的知识我记得快，而那些用不到或不理解使用场景的知识我完全记不住，每次看完就忘光，一直这样循环往复。我相信大部分人也都跟我一样，往往是真正遇到问题时才会去想对应的解决方案。
来看看我自身的学习经历。我是什么时候开始能完整看完 Spring 的官方文档的呢？是在明白了 Spring 大部分功能的使用场景后。
同样的事情也发生在我的 Spark 学习之路上，我曾有过多次 Spark 从入门到放弃的经历，直到有一天碰到了一个实际业务问题——需要定期分析大量数据并生成分析结果，在解决这个问题的过程中，我才真正深入地了解了 Spark。
这就跟有些人一直不明白架构师到底是做什么的一样，直到有一天，他们遇到了一个具体的问题，摸索出了一个可行的方案，才明白：原来架构师是这样解决问题的。
因此，如果想要学好软件架构，基于场景的学习方式最有效。一旦理解了业务场景，我们就能轻易看懂某个解决方案，并理解解决方案背后的实现原理。
于是乎，我就想，市面上有没有这样一门课程：
-
它没有教条，没有理论，就像讲故事一样，将个人实战架构经历娓娓道来；
-
它先讲清楚需要解决的问题，然后诉说个人架构心路历程，再将实现思路串起来阐述整体方案是什么样的，最终引申出解决方案的不足及其他延伸思路。
然而，做了大量市场调研后，我就在想，我可不可以做一门这样的课程，来填补这块空缺呢？
我的软件架构专栏是什么样的？
我深耕职场 15 余载，大厂、小厂、大型民企、外企都待过，其间涉猎过不少互联网项目，大大小小的项目至少 30 个，10 余次从 0~1 搭建完整的技术架构方案，架构升级改造 20 多次。
几十次的架构经历中，有些因与业务紧密结合无法单独拿出来，有些可以从业务特殊需求中剥离出来变成技术思路上通用的解决方案，其中可以抽取归纳的架构经历共 16 次，我在这里已将这 16 次真实的架构经历整理成一套知识体系，方便你更加系统化地理解内容，最终内化为自己的知识。
根据架构设计的立足点，我将本专栏划分为了 6 大模块。
-
模块一：数据持久化层场景实战。 这部分主要讲解存储的数据量太大影响读写性能时，如何在存储层做文章解决性能问题，学完这个模块后，一旦你遇到数据量大的问题，可以直接从我的 16 次架构经历中找到参考答案。
-
模块二：缓冲层场景实现。 这部分主要讲解大流量时，如何避免流量直接压垮数据库层，学完这个模块后，当你遇到缓存层场景问题，你就知道如何进行架构设计了。
-
模块三：基于常用组件的微服务场景实战。 这部分主要讲解业务逻辑分布在不同的服务时，如何使用市面上一些常见的组件解决碰到的各种问题。学完这个模块，你能快速掌握一些微服务的基本原理，并灵活地组合市面上一些常见组件，或结合自研的一些框架解决微服务场景问题。
-
模块四：实际场景解说微服务的痛。 在你学完基于常用组件的微服务场景实战内容后，这个模块将用各种真实经历，让你提前体会在大公司使用微服务时会面临的一些问题。
-
模块五：无常用组件可用的微服务场景实战。 这部分内容主要讲解当一些场景没有常用组件可用时，该如何解决？这个模块将通过真实的架构经历帮助你解决在大公司使用无常用组件可用的微服务所面临的一些问题。
-
模块六：开发运维场景实战。 这部分主要讲解如何通过一些解决方案加快开发效率和测试微服务的效率。
其中，我还会穿插一些课时，专门讲解在解决方案中使用相应技术会碰到的问题。比如使用 ES 时，分页、延时等问题如何解决？再比如使用微服务时，整个团队会面临什么样的问题？为什么大家都在说康威定律？这些问题在面试中时常会被问到，因此这部分内容对架构面试的帮助非常大，你有必要好好体会。
你可以获得什么？
工作至今，我带领团队已 10 余年，10 人以下或者 100 多人的团队我都带过。
不开玩笑，程序员的现实世界里，不想当架构师的程序员不是好程序员，况且就算你未曾主动想去当架构师，现实有时也会把你推到那个位置，而提前设计好自己的职业发展路径，远好过被动等待。
而如果你想晋升为一名软件架构师，需要同时具备架构思维和架构经历。 那这两个要素如何快速积累？前者可以通过学习，而后者需要机会。
在带团队的过程中，我发现不同的程序员，其提交的代码质量及功能交付速度各有不同，后来我发现他们之间的差距在于看问题的视角不同，即所谓的“架构思维”。比如有些程序员只知道自己设计的一些功能，或者只知道自己负责的那几个类，而那些优秀的程序员清楚整个架构的全局如何运作，以及个人负责的代码在架构全局中起到什么关键作用。
一个人的架构设计思维一旦形成，会对其系统架构设计能力产生重大影响，也直接决定着一个架构师解决问题域的复杂性和规模大小。
前面我们提及架构经历必须靠机会，那机会如何而来呢？
我来举个小例子，比如：某天，CTO 碰巧遇到一个架构问题需要找人突破，而团队中碰巧有一个人研究过类似场景，懂得如何使用一些组合技术解决这个问题，你猜这位 CTO 会选谁来试一下？
再比如：在架构师面试过程中，面试官往往会让你聊聊实际开发经历，旨在考察你对业务场景的理解、解决问题的思路、考虑问题的全面性及解决方案的熟悉度。如果在此之前，你已将相关架构经历做了归纳总结，那回答时肯定得心应手，侃侃而谈，Offer 也是手到擒来。
所以，机会就是这样来的，并不会凭空而降，因为机会都是留给有准备的人。
本专栏，我将结合自身 16 次真实架构经历，完完整整地将架构设计实现过程呈现出来，变相地为你增加 16 次架构经历，并且通过各种场景帮你巩固架构的一些实现原理和设计知识。使你学完本专栏后，不仅可以获得更多解决架构问题的机会，面试架构师的成功率也会高一些，离架构师这个目标也就越来越近。
寄语
我们只有先懂场景才能学好架构，相信你学完这个专栏之后，无论是全局的架构思维上，还是面试思路展现上，抑或工作难点突破上都会得到全面的提升。
让我们一起学好软件架构，尽早地升职加薪吧。