# 【IT老齐001】聊一聊被培训机构神话的架构师
现在时代在快速发展，原本技术驱动的行业也开始变的浮躁起来，如果你在网上搜索“架构”关键字，首先映入眼帘的不是某高分技术贴，而是XX架构培训、XXP7班的招生广告，这些培训班宣称学完他们课程就能对标阿里P7、P8甚至P9的水平，我也是觉得蛮无语的，原本需要多年潜心研究沉淀的技术岗位，反倒成了培训班贩卖焦虑，切割韭菜的利刃。在这我也不想对这种现象再多做评论，我只想说架构师没有大家想的那样高大上，架构这个行业也没有所谓的捷径，每一名年薪百万的架构师都是在多年磨砺、精益求精的基础上慢慢成长起来的。
我做这个"架构300讲"系列的初衷就是希望为各位小伙伴分享更有价值的架构知识与开发细节，把我多年的架构经验通过视频的形式能进行分享，希望更多的小伙伴可以少走弯路从中受益，仅此而已。
同时我也奉劝培训机构的“P8、P9级讲师”们，所谓的“架构课”不应是“面向面试编程”的套路，早些年线下培训是怎么做烂的？过度包装、学历造假、简历造假不仅害了学员，更毁了整个行业对技术人的信任，劝你们“耗子尾汁”别再来祸害行业了。
好了，不再吐槽了，咱们正式开始“IT老齐的架构300讲”，如果大家觉得还不错，麻烦点个赞，点赞超过10个，马上开始下一节的更新。
今天我跟大家聊一聊“架构”到底是什么，我们都知道盖楼要打地基，要做框架。
那放在软件中也是一样的，所谓架构就是软件系统的地基，任何软件脱离架构支撑，系统的稳定性、并发性、团队协作将无从谈起。在发展了这么多年后，其实架构设计也是有完整的“套路”的，我们管这种叫做“模式”，例如常说的单机架构、分布式架构、微服务架构都是架构模式，有完整的开发套路。
我举个例子，现在无数小公司在开发系统时，因为数据量小、并发量低、人员技能差等因素还在采用“单机架构”模式，所谓单机架构实质将Web容器Tomcat、文件管理甚至MySQL数据库都放在一台高性能服务器上。
你可能对这样的架构还在嗤之以鼻，觉得low爆了，但在我看来它这么有它的道理，最直接的体现就是从成本上得到的极大的简化。人员方面，找一个Java工程师，兼UI、前端、测试运维于一身，便可以把整套架构维护的妥妥的。在设备方面，花点钱买一台服务器往IDC一扔就完事了，更有甚者，连服务器都不采购直接租用阿里云服务，真可谓每一个钢镚都用在刀刃上。这是你可能会想，这种软件不具备可靠性与稳定性啊，系统崩了怎么办？那还能怎么办，重启一下不就完事儿，在紧张的资金面前一切都是可以妥协的。说了这个案例，我想你对架构应该有了一个基本的认识，架构不是越新越好，越高大上越好，架构师在设计架构时首要考虑的是在有限的资源前提下，如何保证系统的核心利益，例如对于这个小公司，只有几万块预算，你作为大厂架构师财大气粗惯了，上来就弄分布式、微服务架构，你看老板会不会提刀来砍你。请记住在架构圈子里的两句名言：
不谈场景的架构设计都是耍流氓
架构没有对不对，只有合不合适！
那一个老架构师和菜鸟架构师有什么差距呢？其实这就体现在内功上了，我再举个例子，像刚才的单体架构，随着业务的发展已经不堪重负，到了该架构升级的时候了，新人会想这好办啊，分析后目前架构的瓶颈发现是大量文件文件的读写影响到数据库存储的IO，导致数据库查询出现高延迟，这是新人可能会想到在服务器内额外部署Redis缓存，将数据库中的数据载入到Redis中，对于无事务处理直接在Redis中完成，阻止其缓存穿透到MySQL层面，问题就能得到解决。
这么做当然没问题，这种方案也在京东金融的内部实现，已经经过了超高并发的考验。但这必然会带来架构复杂度增加，同时Redis与MySQL的数据一致性也会成为系统架构的另一个新难题。
此时，老鸟站了出来，他说不用那么麻烦，现有架构就能解决，不是数据库磁盘IO的覆盖高么，可是咱们还有大把内存闲置啊，我们对现有系统进行调优，于是老鸟大刀阔斧的去分析源码和架构从以下几个方面介入：
Web容器层面增加拦截器阻挡垃圾重复无效的请求穿透到数据库
分析业务代码中SQL是否存在全表扫描以及索引选择性问题
增加InnoDB引擎的Buffer_Pool让查询拥有更多的缓存命中率
在操作系统层面，增加文件系统缓存，减少文件IO次数
.....
于是在经过细致缜密的优化后，系统架构没有增加任何新的组件，也解决了棘手的问题。通过这个案例相比你也能感觉出来，新人架构师往往局限于自己的知识体系，通常是选择外向型的增加架构复杂度来解决现有问题，而老架构师往往更喜欢挖掘问题的源头，利用多年积累的各种技术经验在尽可能不增加复杂度的前提下解决已有问题。
以上是我多年从业的一些简单看法，谨代表我一家之言。那么最后，我这里还有一点误区要跟小伙伴提个醒。在我面试的时候，进场会聊到“你们项目采用什么架构”这个话题，很多程序猿会直接回复：“我们使用了Spring、MyBatis、MySQL、Tomcat、Nginx”吧啦吧啦，其实这是错误的，以为开发用的框架与架构有着本质不同。
架构是实现软件目标的宏观设计，比如为了支持1000人同时使用流媒体服务器，我们的服务器该如何部署，模块如何切分，数据如何流转，，数据如何流转，带宽需要多少，人员如何组织，数据库使用的集群规格等等，这些都是宏观的设计。
而框架是开发的规则，是落地到具体实现层面代码如何写，应用标准如何定义，是微观上的处理，一个好的开发框架，哪怕就是来实习的小白也能写出开起来像回事的代码，不至于和老鸟们南辕北辙。所以以后再碰到此类问题，要分开说，我们的架构采用的是哪种模型，哪种部署方式、什么数据库形式等等，之后再说我们的框架采用了Spring 、MyBatis。。。
最后如果你正在或准备从事软件架构设计的工作，我也给你一个忠告，架构师宏观设计与微观实现都要有所掌握，如果只会宏观设计，那就是只会吹牛逼的PPT架构师，真到落地的时候恐怕会被做事的Java工程师喷死，而如果只会微观实现，这也是很多程序猿向架构师转型是遇到的瓶颈，过分关注细节容易在整体层面上失去控制，之前我在京东时的同事就是这样，事无巨细就连妹子们写错代码他都要去指导下，生怕别人说他技术菜，可是你作为架构师应该做出的整体设计呢？领导看了你的东西能满意吗。
好啦，林林总总说了些有的没的，作为开篇我想给兄弟们传达一个信号，架构师不是什么高大上的职业，它是你多年积累的技术结晶，只要你一直往这个方向走，架构师并不是什么遥不可及的职业。最后拜托兄弟们点个赞，超过10赞马上开始下一个视频的录制，为大家分享更多的~
