架构师应该具备哪些思维模型？

架构师一直是程序员「羡慕且追求」的高度，今天来说说我（奈学教育CEO：孙玄）眼里优秀的架构师该如何定义。毕竟我也曾经是一名架构师：

创新互联公司是专业的南陵网站建设公司，南陵接单;提供网站设计、成都网站建设,网页设计,网站设计,建网站,PHP网站建设等专业做网站服务;采用PHP框架,可快速的进行南陵网站开发网页制作和功能扩展;专业做搜索引擎喜爱的网站,专业的做网站团队,希望更多企业前来合作!

在开始今天的话题之前我说一个和我前公司P9现在已经是P10的对话。

问题是这样的他说公司中间件架构师不熟悉公司业务，很多事落地不了，非常的疑惑。他最近主要任务就是和这些架构师聊天解惑：）

接着他说了一个类比的故事大概是这样的，

我们（架构师）要建设一条高速公路，来分别看看公路建造者（架构师）和司机（业务研发）的视角。

1，建造者 他们选用最好的沙子 水泥 更好的设计图纸和操作流程保证质量和处理异常情况（比如出入口提示，超车，紧急停车带）

2，司机同志 他们关心什么？

司机关心路宽么，有堵车可以提前告知么。

司机关心路平整么？当然关心，关心。

引出一个的问题：司机（业务研发）关心用最好的水泥么 ？

想象你是司机（业务研发）你你关心吗？

A，关心

B，不关心

欢迎留言留下你的思考。

我觉得一名优秀的架构师，在设计系统时需要有以下这四项关键能力：「平衡取舍、预判未来、抽象思维、容错机制」。

1. 平衡取舍

一个架构本质上总会有优有劣，它不可能是完美的、普适的，也不存在一个架构在 A 场景能用，在 B 场景也最适用的情况，所以就需要我们准确判断，作出取舍。

我们可以根据具体的业务需求来调整架构，也就是以当前的业务需求，选出最匹配的架构。另外，架构师还需要根据现状衡量好需求和资源、效率和安全、时延和吞吐等等之间的关系，做出判断。

比如对于在线交易系统，可能更重要的是保证它的低时延，因此就可以牺牲一定的吞吐量，而对于离线系统，吞吐量则更重要一些。

2. 预判未来

架构师需要具备一定的未来的预判能力，因为架构的调整周期通常比较长。这也是程序员和架构师之间一个很大的区别所在。

程序员负责一个项目，在当前的互联网大背景下，项目的迭代周期非常快，基本以天或周为单位，最多一个月。如果发现不合适的代码，需要重构，程序员基本也能在几天或几周内就能完成重构。

而架构的调整是相对漫长的过程，可能需要数月，甚至要几年。因此，在设计架构时就需要架构师具备预判意识，对很多不确定的事情做出预判和选择，诸如未来访问量会增长到什么量级，会不会产生新的业务，这些会对系统产生什么样新的要求等等。

3. 抽象思维

除了懂得取舍和拥有预判意识，架构师在设计架构时还要掌握抽象的方法，不能胡子眉毛一把抓，要做好分层和区隔。

因为架构师面对的是一个很庞大的系统，为了避免过早陷入细节，不要去看各个组件的细节，而是把它们的角色定义下来之后，再分块来思考。而在看每个分块时，其他分块都可以视为一个抽象的概念，另外，也需要考虑复用的问题。

举个例子，我之前在某送餐平台做在线客服机器人，就运用了分层思想，并且高复用，一个对话机器人可以完成各种各样的业务需求。这其实是一个非常复杂的系统，里面有各种各样的对话机器人的模块，有的特别适合去做检索式的查询，还有的适合做任务导向的、产品推荐导向的对话等等。

我们把对话机器人抽象成一个通用的接口，再将它分为一个个小机器人。这样一来，每个小机器人只需要关注自己的业务模块就行了。然后，我们会在前端再引入一个路由机器人，由路由机器人根据当前对话管理的状态，来判断当前的对话应该交给哪个小机器人去完成。这就是典型的分层的思想。

4. 容错机制

相比程序员，架构师面对的环境要恶劣的多，因为系统更复杂了，出错的概率也增加了，每个节点、每个功能都有可能出错，所以这就需要架构师为错误而设计（Design For Failure），事先提前做好解决方案。

除了应用出错，还有可能产生数据丢失的情况，这个可以通过备份来预防。

另外，如果出现故障，该怎样做到快速恢复呢？我们现在普遍的做法是不修只换，因为如果要修复一个异常状态，可能修复后还会出现连带问题，而如果能通过技术手段，删除已出现的故障，换一个全新的系统，就能够保证它迅速恢复到正常状态。