从程序员到架构师都需要经历什么？

一、内容简介

《从程序员到架构师：大数据量、缓存、高并发、微服务、多团队协同等核心场景实战》分为数据持久化层场景实战、缓存层场景实战、基于常见组件的微服务场景实战、微服务进阶场景实战和开发运维场景实战5个部分，基于对十余个架构搭建与改造项目的经验总结，介绍了大数据量、缓存、高并发、微服务、多团队协同等核心场景下的架构设计常见问题及其通用技术方案，包含冷热分离、查询分离、分表分库、秒杀架构、注册发现、熔断、限流、微服务等具体需求下的技术选型、技术原理、技术应用、技术要点等内容，将技术讲解与实际场景相结合，内容丰富，实战性强，易于阅读。《从程序员到架构师：大数据量、缓存、高并发、微服务、多团队协同等核心场景实战》适合计划转型架构师的程序员及希望提升架构设计能力的IT从业人员阅读。

二、程序员之间的能力差异在哪里？

如果是学技术，大家可以阅读同样的书籍和网络文章，为什么还会造成最终专业能力的差异？
我认为有三点：

1、经历的场景不同

同样大学毕业的程序员，学习能力的差别并不会很大，可是为什么行业头部公司的程序员更受欢迎？原因就是他们经历的场景不一样，头部公司就职的程序员会碰到更多在其他公司没有机会碰到的业务场景。

2、在同一个场景中思考问题的角度不同

同一个场景中，可以看到全局、从业务问题推导到最终技术细节的人，和基于别人的设计开始开发的人，其收货并不一样。

3、解决问题的方法不同

程序员是不可能掌握所有技术的，这就要求他们用20%的技术知识解决80%的问题。所以当碰到一个新的业务场景时，关于如何从0到1设计出方案并最终落地，每个人的方法论是有差异的。
我推荐你读一本书，因为本书抛开教条和理论，精心选取作者16次架构经历，从易到难，从单一技术到组合技术，层层深入，以实际的业务问题作为切入点，讲解方案设计过程，让你轻松看懂解决方案，理解背后的实现原理。本书行文逻辑完全源于现实当中的思考历程，通俗易懂，让你在酣畅淋漓的阅读体验上，习得场景、纵览全局，了解作者解决问题的方法论，从而提升自己的架构设计能力。
我认为，一个人要能够长期发展，就要不断探索和解决新的业务场景，全局思考，并且有一套发现问题、高效学习、解决问题、总结改进的方法论。只要具备这样的能力，那么，不只是35岁，任何年龄对你来说，都不是桎梏。

三、什么是架构？

如果想要学好软件架构，基于场景的学习方式最有效。因为一旦理解了业务场景，就会很容易地看懂某个解决方案，并理解解决方案背后的实现原理。
关于架构，我以前一直以为，只要真正从0到1，经历各种技术选型后搭建出来的一个系统框架，才算是真正的架构。
那么，先看看软件架构的定义吧。
软件架构师一系列相关的抽象模式，用于指导大型软件系统各个方面的设计。软件架构是一个系统的草图，描述的对象是直接构成系统的抽象组件，各个组件之间的连接明确和相对细致地描述组件之间的通信。在实现阶段，这些抽象组件被细化为实际的组件，比如具体的某个类和某个对象。在面向对象领域中，组件之间的连接通常用接口来实现。软件架构师构建计算机软件的基础。与建筑师指定建筑项目的设计原则和目标来作为绘图员画图的基础一样，一个软件架构师或者系统架构师设计软件架构作为满足不同客户需求的实际系统设计方案的基础。

四、从实际场景中学架构

《从程序员到架构师》中关于架构设计，分5个部分阐述：

1、数据持久化层场景实战

主要讲解存储的数据量太大影响读写性能时，如何在存储层采取措施来解决性能问题，学完这部分内容后，当遇到数据量大的问题时，就可以直接从中找到参考答案。

2、缓存层场景实战

主要讲解大流量时，如何避免流量直接压垮数据库层。学完这部分后，当遇到缓存层场景问题，就知道如何进行架构设计了。

3、基于常见组件的微服务场景实战

主要讲解业务逻辑分布在不同的服务时，如何使用一些常见的组件区解决其中的各种问题。通过这部分内容的学习，能快速掌握一些微服务的基本原理，并灵活的组合一些常见的微服务组件，或结合自研的一些框架来解决微服务场景问题。

4、微服务进阶场景实战

在学完基于常见组件的微服务场景实战内容后，这个模块将先用各种真实经历让你提前体会在大公司使用微服务时会面临的一些问题，然后通过真实的架构经历来讲解使用无常见组件可用的微服务时所面临的一些问题及其解决方案。

5、开发运维场景实战

主要讲解如何通过一些架构上的设计来提高开发效率和测试微服务的效率。
书中会穿插一些内容，用来专门讲解在解决方案中使用相应技术时会碰到的问题，比如使用Elasticsearch时，分页、延时等问题如何解决。还会有一些知识延伸，比如为什么大家都在说康威定律，这些问题在面试中经常会被问到，因此这部分内容对架构面试的帮助非常大。

五、16次架构实战经验

如果你想晋升为一名软件架构师，则需要同时具备架构思想和架构经历。
不同的程序员，其提交代码的质量及功能交付的速度各有不同，他们之间的差距在于看问题的视角不同，即所谓的全局思维。比如，有些程序员只熟悉自己设计的一些功能，或者自己负责的那几个类，而那些优秀的程序员则更清楚整个架构如何运作，以及个人负责的代码会在架构全局中起到什么关键作用。
一个人的全局思维一旦形成，就会对其系统架构设计能力产生重大影响，也直接决定着一个架构师解决问题域的复杂性和规模大小。
前面提及架构经历必须靠机会，那机会从何而来？
举个例子，某天CTO遇到一个架构问题需要找人突破，而团队中碰巧有一个人研究过类似的场景，懂得如何使用一些组合技术来解决这个问题，那么这位CTO自然会让他试一下。
再比如，在架构师面试过程中，面试官往往会让你聊聊实际开发经历，旨在考察你对业务场景的理解、解决问题的思路、考虑问题的全面性及对解决方案的熟悉度。如果在此之前，你已将相关架构经历做了归纳总结，那回答时肯定胸有成竹，侃侃而谈，面试成功的概率也会更大。
所以，机会并不会从天而降，因为机会都是留给有准备的人。