前言
FOREWORD
随着社会节奏的日益加快,碎片化学习逐渐成为人们获取知识的主要方式,虽然能学到很多知识,但这些知识往往零散琐碎、不系统。
刚学习Spring时,每当看到Spring的示例代码,我先是恍然大悟:“哦,原来Spring还有这个功能!”然后赶紧把这段代码复制到自己的代码库里。
琢磨一番后发现:“不行,我还是得完整掌握Spring。”于是又在网络上寻找完整的Spring学习文档。但利用碎片化时间看完一半后,还是决定放弃了。
碎片化学习知识时,人们往往追求实用,对用得上的知识学得很快,而那些暂时用不到或没有融合使用场景的知识却不容易记住,每次看完就忘,一直这样循环往复。相信大部分人也都跟我一样,往往是真正遇到问题时才会去想对应的解决方案。
我是什么时候开始能完整看完Spring官方文档的?是在明白了Spring大部分功能的使用场景后。
同样的经历也发生在我的Spark学习之路上,我有过多次Spark从入门到放弃的经历,直到有一天碰到了一个实际业务问题——需要定期分析大量数据并生成分析结果,在解决这个问题的过程中,我才真正理解了Spark的用途。
这就和有些人一直不明白架构师到底是做什么的一样,直到有一天,他们遇到了一个具体的问题,摸索出了一个可行的方案,才明白:原来架构师是这样解决问题的。
因此,如果想要学好软件架构,基于场景的学习方式最有效。因为一旦理解了业务场景,就能很容易地看懂某个解决方案,并理解解决方案背后的实现原理。
那么,有没有这样一本书:
它没有教条,没有理论,就像讲故事一样,将个人架构实战经历娓娓道来。
它先讲清楚需要解决的问题,然后诉说个人架构的心路历程,并将实现思路结合起来,阐述整体方案,最后引申出解决方案的不足及更多思考。
在做了大量市场调研后我并没有找到此类书籍,于是就产生了一个想法,可不可以自己写一本这样的书,来填补这块空白?
本书讲的是架构,可是,什么是架构?
什么是架构?
关于架构,我以前一直以为,只有真正从0到1,经历各种技术选型后搭建出来的一个系统框架,才算是真正的架构。
但现实是,随意在Github上搜索一个框架,比如Spring Cloud脚手架,就有很多相关的教程。而且,对于从0开始的业务来说,技术选型有那么重要吗?实际工作中不都是技术创始人熟悉哪个技术栈就用哪个技术栈吗?
如果脚手架不是架构,那什么是?
来看看软件架构的定义。
软件架构是一系列相关的抽象模式,用于指导大型软件系统各个方面的设计。软件架构是一个系统的草图,描述的对象是直接构成系统的抽象组件,各个组件之间的连接明确和相对细致地描述组件之间的通信。在实现阶段,这些抽象组件被细化为实际的组件,比如具体的某个类或者对象。在面向对象领域中,组件之间的连接通常用接口来实现。软件架构是构建计算机软件的基础。与建筑师制订建筑项目的设计原则和目标来作为绘图员画图的基础一样,一个软件架构师或者系统架构师设计软件架构以作为满足不同客户需求的实际系统设计方案的基础。
是不是很难理解?
我以前有个领导,原来是Oracle的VP,那时候公司在推行Scrum,我就问他,学Scrum最重要的是什么?
他说,是“体验”,先别去刻意记忆那些规则,而是跟着前辈做项目,在里面认真体验一段时间,自然就懂了。
我觉得这一方法在学习上也可以参考:先不去纠结什么是架构,而是去探索架构要解决什么问题、要处理什么样的场景。这就是本书的立足点。
从实际场景中学架构
我职场深耕15余载,经历过数十次互联网架构业务。在这几十次的架构经历中,有些因与业务紧密结合无法单独拿出来,但有些可以从特定业务需求中剥离出来变成技术思路上通用的解决方案。其中可以抽取归纳的架构经历共16次,本书将这16次真实的架构经历整理成一套知识体系,方便读者更加系统地理解它们,最终内化为自己的知识。
根据架构设计的立足点,本书划分为5个部分。
• 第1部分:数据持久化层场景实战。主要讲解存储的数据量太大影响读写性能时,如何在存储层采取措施来解决性能问题。学完这部分内容后,当遇到数据量大的问题时,就可以直接从中找到参考答案。
• 第2部分:缓存层场景实战。主要讲解大流量时,如何避免流量直接压垮数据库层。学完这后,当遇到缓存层场景问题,就知道如何进行架构设计了。
• 第3部分:基于常见组件的微服务场景实战。主要讲解业务逻辑分布在不同的服务时,如何使用一些常见的组件去解决其中的各种问题。通过这部分内容的学习,能快速掌握一些微服务的基本原理,并灵活地组合一些常见微服务组件,或结合自研的一些框架来解决微服务场景问题。
• 第4部分:微服务进阶场景实战。在学完基于常见组件的微服务场景实战内容后,这个模块将先用各种真实经历让你提前体会在大公司使用微服务时会面临的一些问题,然后通过真实的架构经历来讲解使用无常见组件可用的微服务时所面临的一些问题及其解决方案。
• 第5部分:开发运维场景实战。主要讲解如何通过一些架构上的设计来提高开发效率和测试微服务的效率。
书中会穿插一些内容,用来专门讲解在解决方案中使用相应技术时会碰到的问题,比如使用Elasticsearch时,分页、延时等问题如何解决。还会有一些知识延伸,比如为什么大家都在说康威定律。这些问题在面试中经常会被问到,因此这部分内容对架构面试的帮助非常大。
16次架构实战经验
在程序员的现实世界里,不想当架构师的程序员不是个好程序员,即使你未曾主动想去当架构师,现实有时也会把你推到那个位置,而提前设计好自己的职业发展路径,远好过被动等待。
如果你想晋升为一名软件架构师,则需要同时具备架构思维和架构经历。那这两个要素如何快速积累?前者可以通过学习,而后者需要机会。
不同的程序员,其提交代码的质量及功能交付的速度各有不同,他们之间的差距在于看问题的视角不同,即所谓的“全局思维”。比如,有些程序员只熟悉自己设计的一些功能,或者自己负责的几个类,而那些优秀的程序员则更清楚整个架构如何运作,以及个人负责的代码会在架构全局中起到什么关键作用。
一个人的全局思维一旦形成,就会对其系统架构设计能力产生重大影响,也直接决定着一个架构师解决问题域的复杂性和规模大小。
前面提及架构经历必须靠机会,那机会如何而来?
举个例子,某天CTO遇到一个架构问题需要找人突破,而团队中碰巧有一个人研究过类似场景,懂得如何使用一些组合技术来解决这个问题,那么这位CTO自然会让他试一下。
再比如,在架构师面试过程中,面试官往往会让你聊聊实际开发经历,旨在考察你对业务场景的理解、解决问题的思路、考虑问题的全面性及对解决方案的熟悉度。如果在此之前,你已将相关架构经历做了归纳总结,那回答时肯定胸有成竹,侃侃而谈,面试成功的概率也会更大。
所以,机会并不会凭空而降,因为机会都是留给有准备的人。
本书将结合16次真实架构经历,完整、具体地将架构设计过程呈现出来,在通过各种场景帮你巩固架构实现原理和设计知识的同时,也是一种架构经历的丰富。看完本书后,你不仅可以更加自信地去争取更多解决架构问题的机会,面试架构师的成功率也会高一些,离架构师这个目标职位也就越来越近。
成为架构师
只有先懂场景才能学好架构,相信看完本书之后,无论是在全局的架构思维上,还是面试时的思路展现上,抑或工作难点的突破上,你都会得到全面的提升。
一起学好软件架构,尽快成为一个优秀的架构师!
编者