谈谈架构师是何种生物

小团队一般 10 人左右，其中常常是技术最牛的人做架构师（或 TL）。所以，架构师在广大码农中的占比大概平均不到 10%。

图片来自 Pexels

而架构师也可以分为初级、中级、高级三档，江湖上真正高水平的软件架构师就更少了。

所以，大部分（超过九成的）码农干上许多年，还是做不了架构师，这是什么原因造成的呢/p>

什么是架构师/p>

写代码和做架构是两个不同的事情。什么是架构师，架构师要做什么事情，为什么 Java 的领域里，会更注重架构师/p>

很早很早之前，我对于架构的概念一点都不理解，依稀记得，架构（ architecture）这个词，来自于建筑领域。

这对于我这个没写过几行代码的人来说，瞬间就有了一种“不明觉厉”的崇拜感。

架构，感觉好厉害的样子，从名称上来说，好像是设计根骨，设计底层，设计最核心的东西的人。

架构师，一定很 NB，我什么时候能成为架构师呢/p>

后来懂了一点点代码，去写增删改查，更是体会不出来架构的概念，不就是 SQL 语句吗/p>

我看到这些头都要炸了好么以，到底什么是架构/p>

整个系统只有一个 Web，Spring MVC+Spring+Hibernate 搞定一切，开始做需求分析，实际上就是设计表结构而已，剩下的就是查查查，改改改，删删删。

直到某天，我知道一个词，缓存。

缓存这玩意儿，在很早之前学习各种基础课程的时候，了解过一些，一级缓存，二级缓存什么的，LRU 我好像也懂一点点，但是，在系统里，缓存算是什么/p>

在公司里，那个架构师，画了一张图，告诉我们，这台机器上，放了一个 Memcache，然而我们都不懂，他只解释了一句，这个 Memcache 是缓存。

我的第一个困惑就是，所有的请求都要再次转发到另一台机器上，把数据取出来，单个请求可能不算什么，每天有几十万次请求，这中间的损耗不大么，为什么不把 Memcache 放到本地机器上呢/p>

他没解释，只告诉我说，不大，Memcache 就是要放在另一台机器。

在当时，我不清楚内 和外 的差别，也不清楚访问 Memcache 的请求倒底是需要多少 MS，更不理解，把 Memcache 放在和业务层一台机器，或者是分开放的差别倒底是什么。

但这个问题一直困惑着我，简单来说，这其实算是一点点架构师要做的事情的萌芽，一个系统中，如果拆解出来了很多模块，倒底应该部署在哪些机器上构师会解决这些问题。

后来，到了搜狐之后，我突然间发现了我之前学到的东西，在搜狐的技术大神面前，直接被轰成渣。

负载均衡是什么备又是什么透 DB 是什么意思么我取数据库里取一个值，数据库里没有，这种空数据的请求会把 DB 打垮还要把这些为 Null 的请求单独缓存起来地缓存做为一级缓存，Memcache 做二级缓存/p>

“对缓存来说，最关键的设计就在于失效策略是什么。”大神镇定的看着我。我很惶恐，感觉能把失效策略设计出来，很不容易。

不同的应用场景，对于缓存的要求不一样，对实时性的要求也不一样。榜单这种一天更新一次的，每天晚上定时生成一次就好了。

后台更新，但是要注意，一定要直接生成，直接切换，不能让前端用户访问的时候，再去生成。

对于名字这种东西，用户改完之后，必须立刻更新缓存，包括本地缓存和远程缓存。

这算不算架构中的一部分，根据不同的应用需要，去设计不同的策略，同时把这些场景规范化，成为一整个团队都要去遵循的标准/p>

我不知道，我只知道，能 Hold 住团队里所有人的那个人，技术一定非常 NB，团队里的每一个人，都会质疑，如果你 Hold 不住全场，怎么能推行下去/p>

当时近 30 的技术团队里，每一个都是神一样的存在啊，谁能 Hold 住 30 多个神。

而且，原来不应该把所有的代码放到一个 Web 里，原来分布式是这么回事儿，原来一个系统，是由多个子系统构成的，原来还要分层，原来封装和抽象是这么个意思。

Web 层是一层，通常可以通过 LVS 部署两台到三台，或者是更多的，Service 一层用来处理业务逻辑，缓存层用来扛并发，一定要藏在 Service 里面。

Controller 调用 Service 的时候，并不需要知道数据到底从哪来的，每一个 Service 使用什么样的缓存策略，完全不需要 Controller 层知道。

对于大型应用来讲，MySQL 只能用做是持久化，MySQL 的单条访问速度并不查，只是在并发能力太差，扛不住。但是，有可能数据量过亿啊/p>

过亿怎么办用分库，还是分表写分离要不要做台服务挂一台数据库，哪些数据库应该放在一个实例里，哪些应该单独拆出去台服务器的配置是什么/p>

我大概知道一点点，架构师要做哪些事情，他就是要把这些大的骨架定好，然后我们去填充里面的内容。如果骨架定歪了，其余团队必然跟着歪。

这时候有了一系列的问题，第一个，Controller 和 Service 之间，Service 和 Service 之间，应该通过什么调用/p>

RMI，这是惟一的选择。用 Thrift，或者是 ProtocolBuffer，或者是 Rest 实现的 RPC/p>

这是架构师要考虑的事情，如果是用 RMI，我们是要自己实现，还是要找找是否有好用的开源的框架，在其他的系统里被证明了是有用的/p>

大神们花了两周的时间，对当时流行的开源框架过了一遍，最终选定了 Tuscany，到现在我都觉得设计精美，完暴 Dubbo 的东西，真的是一点都不想切到 Dubbo 上去，毕竟“曾经沧海难为水，除却巫山不是云”。

直到最近几年微服务兴起的时候，我还是同样的目瞪口呆，这跟 2009 年搜狐当时做白 会的架构比起来，优势倒底在哪里/p>

差别好像没有那么大啊，而且 Tuscany 实现的更完美，只是使用的时候要有更强的约束，因为 Tuscany 太强大了，强大到有一点点重，必须要做简化。

而且，Tuscany 的开发团队不怎么维护了，白 会当时做的东西，还是大神花了两周的业余时间写了一个 Scallop，增加了 Tuscany 的负载均衡的功能。

但是，到底用什么，不用什么呢了 Tuscany，还讨论过要不要用 Hadoop，要不要用 ActiveMQ，要不要用 Erlang。

每一个技术框架的选择，都经过讨论，验证，测试，最终在全团队里推行。

这是否也是架构师的职责个架构师太厉害了，他需要从前到后都要懂，他需要制定关键的技术细节，他需要给出最佳实践，他需要了解业界所有流行的解决方案。

他需要去猜测 Facebook 怎么解决问题的，Twitter 怎么解决问题的，Google 怎么解决问题的，这些解决方案可不可以拿过来，也同样适用于我们自己的场景。

他需要精通分布式，Nginx 或者是 F5，微服务，缓存，持久化，消息队列，他需要熟悉所有这些技术细节里的最常用的解决方案，不能有遗漏，也不可以过度设计。

他决定的不是他一个人喜欢的风格，他决定的就是整个团队，在项目死亡之前都必须遵循的规范，现在的团队成员，和未来的团队成员，都必须遵循的体系，而且，如果在未来，这些架构体系有不合理的地方，那就麻烦大了。

这样的架构师，还要肩负着一个重大的使命，修复开源软件的 Bug。

在很早之前，我一直误以为开源软件是很厉害的很 NB 的东西，我一直以为这是完美的，很久很久之后，才明白，所谓的完美，都是用血和泪塑造而来的。

不经过各种各样的验证，环境，使用的测试，很难达到一个上线标准的稳定，即便是上线了，也有可能会出现之前完全预料不到的问题。

可是，如果你选择了这个框架，出了问题，谁去解决/p>

架构师，他要开源码，理解这些开源框架的思路，然后去找有可能产生问题的地方，再去修复他。

我一直都觉得，能看懂别人写的代码的人，都是神。某段时间我去看一个 Heritrix，看的我神清气爽，各种层出不穷的继承，各种抽象类，连着三天我欲仙欲死，更加坚定了我死也不要，也不允许其他人在项目里使用继承的决心。

但是 Heritrix 从外表看起来特别牛，他的抓取策略也很 NB，用的分布式抓取的解决方案非常轻巧。可是我我实在是不想再去读一次了，在当时不读不行，资料太少。

那么，一个架构师，要对这些源码都了解么或者是，他必须具备，需要他去读源码，他就必须读源码，而且去优化的能力大概比提前懂源码，更神奇。

因为是有时间要求的啊，简单来讲，他需要在一个有效的时间内，去弄懂所有的底层的东西，说句实在话，当有同事嘲笑我都没有完整的看过 TCP/IP 协议详解的时候，我真的是无话可说的。

对于特别底层的东西，我确实了解的不够多，可是架构师们不一样。

架构师需要懂业务么/p>

有了这些，就可以称之为架构师了么构师需要懂业务么/p>

是不是就可以每天看技术，写底层框架（比如我们原来在搜狐用到的 DAL，数据访问层，用起来简直是神器的东西）。

没有不懂业务的架构师，所有的架构，都依赖于业务。所有的架构师，也必须要去写业务代码，不把自己设计的东西，用在真正的项目里，恐怕他们自己都不会知道，这种架构设计的合理性在哪里。

在某团购公司上市之前，他们的 CTO 拿出来了他们的架构图给我看，在给我看之前，所有的技术术语都一样，但是当我认真看了架构图之后，我的困惑……

为什么 Memcache 要放在 Controller 层被调用应该是放到 Service 层吗/p>

怎么会出现你说的，一个 Serivce 负责维护的数据，也有可能被另外的 Service 去更改的情况/p>

每一个 Service 对数据的操作，必须是独立的啊，除了这个 Service，其他的任何服务都决不允许直接更改 DB 啊。

而且，怎么 Service 拆分了，DB 不拆分呢样的话，压力大的 DB 会把全站拖跨的啊。

那张架构图我看到之后，感觉自己的认知被突破了，原来可以这么做，原来同样的，类似的技术选型，可以做出来如此艰难的东西/p>

就在我以为这其实就差不多是架构师的全部的时候。在最近一段时间，我突然间发现了一个问题。

为什么有的人代码写的这么烂，很多写死的代码，一点儿灵活性都没有，更没有规范，完全就是堆压。

为什么有的人根本不知道怎么去抽象，并不清楚怎么样积累成公共组件，为什么他们改一个问题，通常会引出更多的问题/p>

为什么他们的代码里的实现方案，让人看完之后恨的牙痒痒，想改又完全不能改，毕竟，正常工作的代码才是好代码/p>

很大程度上是因为，很多程序员，不懂的代码的扩展性，不会面向未来编程。

怎么叫做面向未来编程/p>

一个好的工程师，在听到需求的时候，可以根据自己的业务能力，判断出来这些需求中，哪些是有可能变化的，哪些是不太可能变化的。

针对这些变化的内容，在编写的过程中，不会写死，而反复确认不可能会变化的需求，会写的简单一些，防止过度设计引起的复杂度。

简单说，当他拿到需求时，并不单纯是考虑这个需求怎么实现，还会考虑，自己设计的架构体系，扩展性在哪里，在他的眼里，看到的需求会被分解，折分，然后自己的技术方案，会挨个分解，分配。

在完成设计之后，他会很清楚的知道 ，自己设计的系统里，哪些变化是支持的，随便你改，我只需要改动一个很简单的内容，哪些是你绝对不能改的，你要改，我就必须花很大的代价，特别是在已经有线上数据的时候。

而且会拿着自己的架构体系跟 PM 沟通，讲清楚。

什么样的变化是支持的信通道是有可能变化的，而调用短信通道的地方可能会有点多，所以我必须把短信通道抽象，并封装在一个公共接口，如果需要更换短信通道，我可能只需要更改一个配置文件就好了。

那么什么样的变化是不支持的不需要不停机就更换短信通道的功能，除非你在后台系统中提前配置好，或者是有明确的需要，我做出这么一个东西出来。往往在前期，不会用到，为什么/p>

在创业初期，短信通道往往用于用户注册，一旦出问题，就是生死问题，必须要有一个备份，运营商一怒封掉你的通道，很常见。

而重启一次服务，在创业前期，往往没有那么严重。所以，这些技能，是不是也应该归纳到架构师的职责里去/p>

架构师从开始就要考虑选型，从语言开始，从业务开始，要对这个领域里的开源框架熟悉，了解，要能解决疑难问题，要懂安全，要会备份，要学会面向未来编程，还需要什么/p>

还需要 DevOps，在持续集成的年代，在服务器规模越来越大，在云服务器的年代，在异地存储，冗灾，在全球化越来越快的年代。

运维的重要性已经到了一个很核心的程度了。弹性伸缩，自动扩容，灰度发布等等等概念，要求，都在冲击着架构师这个概念的定义。

如果说之前的架构师，更多的是在系统开发前，现在越来越偏于系统上线后。

还包括数据分析，日志分析，等等等等，对了，还没有提到 NoSQL DB，实时搜索，知识库，算法这一系列的东西。

每一个领域都在细分，每一个概念都在深化。简单说，架构师确实和语言无关，但是又绝对和语言有关系。

你可以说，架构师就是在做选型，但是只会做选型，肯定做不出架构师。

Java 更需要架构师，因为他本身就是各种开源框架，不对这些框架了解的清清楚楚，你很难做出一个好的选择，而一旦架构被固定，实际业务人员的开发，又会变的简单很多。

中级工程师的发展路线

说到了现在，我有没有讲清楚架构师是什么你，还想要做架构师吗/p>

反正，我说自己是架构师的时候，我的内心是羞耻的，我知道 ，我远远没达到架构师的能力。

然后，我曾整理过一个中级工程师的发展路线。

科班基础：

• 计算机组成原理（洗髓换骨营）

• 计算机操作系统（洗髓换骨营）

• 计算机 络（洗髓换骨营）

• 数据结构（洗髓换骨营）

• 数据库

• 算法

语言相关：

• JDK

• 线程

• Set

• Hash

• GC

• ClassLoader

• Lambda

Spring：

• IOC

• Spring

• Spring MVC

• Spring Boot

• Shrio

数据库：

• MySQL 基础

• DB 设计

• DB 调优

• MySQL 底层架构

• idcenter

• 常用工具

• 索引

架构：

• 设计模式

• 缓存

• 分布式

• Key-Value

• 消息队列

• 定时任务

• 微服务

• RPC

• 高并发

• 性能优化

项目规范：

• 接口定义

• 日志规范

• 编码规范

• 最佳实践

运维：

• Linux 常用命令

• JVM 常用工具

• Nginx

• Resin

• LVS

• Iptables

• Jenkins

• Ansible

• 容器 Docker

• 监控

• CICD

常用算法：

• 一致性哈希

• Gossip

• Paxos

• Spotsig

• HTTPS

• MD5

• Auth2

• Bloom Filte

• TrieTree

• Rete

源码解析：

• Spring

• Redis

• Memcache

• Mybatis

• Log4j

• Maven

• Git

开发流程：

• 敏捷开发

场景解决方案：

• 金融

• 支付

• 电商

• 直播

• 教育

• O2O

• 分销

• 会员

• 活动

• 秒杀

思维方式：

• 自顶而下

• 分层模式

• 抽象

• 落地

• 推测

• 验证

• 组件

• 定制

• 生成