什么是架构？
软件总体的结构,软件的设计图。
为什么要出现架构？
一个软件太大了，一个人的心力很难完全构建出来，以至于需要很长时间或者多人合作开发。一个人的话，一开始自己对自己要做出来的东西可能会有一个清楚的认识，但时间长了就会忘记，就需要一个设计图来进行对照。但一群人的话，需要都遵循这个整体的结构，彼此之间通过约定好的接口来进行通讯，就像分布式开发。
架构解决谁的问题？
架构解决用户的问题。不同的架构有不同的侧重点，比如需要的同时支持几万个用户在线的就可能需要redis数据库，单纯的mysql是不现实的。用户心里面有一个模型，说出来的可能和他心里想的模型不一致，这就需要架构师设身处地地站在用户的层面思考，针对用户的真正需求设计架构。
必备各种流行技术
知道所有的主流框架，技术的原理和用途；
比如：
负载均衡是什么？热备又是什么？穿透DB是什么意思？怎么我取数据库里取一个值，数据库里没有，这种空数据的请求会把DB打跨？为什么还要把这些为Null的请求单独缓存起来？本地缓存做为一级缓存，Memcache做二级缓存？“对缓存来说，最关键的设计就在于失效策略是什么。”不同的应用场景，对于缓存的要求不一样，对实时性的要求也不一样。榜单这种一天更新一次的，每天晚上定时生成一次就好了。后台更新，但是要注意，一定要直接生成，直接切换，不能让前端用户访问的时候，再去生成。对于名字这种东西，用户改完之后，必须立刻更新缓存，包括本地缓存和远程缓存。
而且，原来不应该把所有的代码放到一个WEB里，原来分布式是这么回事儿，原来一个系统，是由多个子系统构成的，原来还要分层，原来封装和抽象是这么个意思。WEB层是一层，通常可以通过LVS部署两台到三台，或者是更多的，Service一层用来处理业务逻辑，缓存层用来扛并发，一定要藏在Service里面，Controller调用Service的时候，并不需要知道，数据倒底从哪来的，每一个Service使用什么样的缓存策略，完全不需要Controller层知道，持久化，对，对于大型应用来讲，Mysql只能用做是持久化，Mysql的单条访问速度并不查，只是在并发能力太差，扛不住。但是，有可能数据量过亿啊？过亿怎么办？是用分库，还是分表？读写分离要不要做？一台服务挂一台数据库，哪些数据库应该放在一个实例里，哪些应该单独拆出去？每台服务器的配置是什么？
架构师需要从前到后都要懂，他需要制定关键的技术细节，他需要给出最佳实践，他需要了解业界所有流行的解决方案，他需要去猜测Facebook怎么解决问题的，Twitter怎么解决问题的，Google怎么解决问题的，这些解决方案可不可以拿过来，也同样适用于我们自己的场景。他需要精通分布式，Nginx或者是F5，微服务，缓存，持久化，消息队列，他需要熟悉所有这些技术细节里的最常用的解决方案，不能有遗漏，也不可以过度设计，他决定的不是他一个人喜欢的风格，他决定的就是整个团队，在项目死亡之前都必须遵循的规范，现在的团队成员，和未来的团队成员，都必须遵循的体系，而且，如果在未来，这些架构体系有不合理的地方，那就麻烦大了。
然后架构师根据各种需求，把这些大的骨架定好，然后其他人去填充里面的内容。
架构师当他拿到需求时，并不单纯是考虑这个需求怎么实现，还会考虑，自己设计的架构体系，扩展性在哪里，在他的眼里，看到的需求会被分解，折分，然后自己的技术方案，会挨个分解，分配。在完成设计之后，他会很清楚的知道 ，自己设计的系统里，哪些变化是支持的，随便你改，我只需要改动一个很简单的内容，哪些是你绝对不能改的，你要改，我就必须花很大的代价，特别是在已经有线上数据的时候。
总结：架构师要精通各种框架、安全、运维等技术。还要精通算法和设计模式，设计出来的软件高内聚低耦合。是开发岗和算法岗的顶尖。
做这活，恐怕我们凡人真得赌上自己的所有时间精力才能升任。