时光退回到七八年以前，那个时候“架构师“还是一个很“高大上“的title。可是在今天的互联网圈，随便一个工作了三、五年的开发人员，都可以称之为架构师。
随便多翻几个招聘网站，你可以看到：前端架构师、后端架构师、Android架构师、iOS架构师、php架构师、运维架构师、DB架构师、搜索架构师、中间件架构师、大数据架构师。。。五花八门，不一而足。
从这些岗位需求可以看出，“架构师“这个词其实是一个很“虚“的词，不同技术领域、不同行业，所要求的技能点、所侧重的能力模型是差别很大的，不是一个简单的“架构师“就可以概括的。
而本文也将谈谈我个人对“架构师“这个职位的理解：虽然不同领域要求的能力模型不一样，但个人认为，作为一个“架构师“，还是有一些共同的东西需要掌握的。
格局
“格局“这个词听起来比较虚，但我举个通俗的例子：你去一个陌生的城市旅游，我想你首先需要的就是一张“地图“。这张地图定义了这个城市的“边界“，也定义了这个城市的所有地方，通过这张地图，你会对这个城市有一个“全局的了解“。
而这种“全局的视野“，不是说架构师才需要，换做其他职位、其他行业，同样的道理。做产品经理，需要对产品有“全局视野“；做运营，做市场，需要运营、市场相对应的全局视野；做技术，需要技术相关的全局视野。
说了这么多，可能还是比较“虚“，我就举个例子来说明到底什么叫“全局视野“，比如你现在负责开发一个新系统，你可能需要去理解下面这些关系到“大局的问题“：
这个系统的定位是什么？它能创造什么核心价值？
做这个系统的背景是什么？－－ 为什么以前不做，现在要上？是因为业务发展到了一定规模？还是开发资源现在有多余，没事可干？
这个系统在整个组织架构中，处于什么位置？跟这个系统关联的其它系统目前什么状况？
产品经理如何看待这个系统？技术老大如何看？
这个系统的需求，是处于比较确定、比较清晰状态？还是有很大灰度空间？很多核心点，大家还没想清楚？
这个系统所用的技术体系，是比较老？还是最新的？
业界类似的系统，人家是如何做的？
。。。
关键点：上面随便举的这个例子，并没有标准答案，我想表达的是，一个有“大局观“，一个有“格局“的人，在做一件事情之前，要对所做的事情有一个“全局把握“，风险在哪？挑战在哪？提前要有心理准备！
最后再多说一句：“格局“是有层次的，国家总理在“国家“这个层次思考，CEO在行业、“公司“这个层次思考，业务线负责人在他所负责的那个“业务“层面思考，技术老大可能主要在“技术层面“思考，产品老大在“产品层面“，到了最下面，写代码的，在“代码“这个层面思考。
不同层次的人，聚焦的范围大小不一样。可如果你能把你的“范围“往外扩一圈，这对你做自己的“本职工作“会很有好处。
而这，在我看来就是“格局“。
历史观-技术血脉
如果说“格局“是从空间的角度去看待问题，那么“历史观“就是从时间的角度去看。
任何一种技术，都不是谁吃饱了没事干凭空想象出来的，它一定是要解决某个特定问题。而这个特定问题，一定有它的历史背景：是因为之前的技术，在解决这个特定问题上，解决的不够好、或者有其它副作用，所以才发明了这个新技术。
所以，看待一个技术，一个方法论，需要把它放到“历史长河“中，去看它在历史中，处于什么位置。
推而广之，何止是技术，任何其他学问，何尝不需要“历史观“？说个更专业点的哲学名词，就这是所谓的“历史唯物主义“吧！
抽象能力
同“格局“一样，“抽象能力“又是一个很“虚“的词。可作为架构师，就是需要这种“务虚思维“。
抽象也是一个“层次“结构，从最底层到最上层，不同工作阶段，你需要在不同抽象层级进行思考。
很多写代码的人，都比较习惯“自底向上“的思维方式。当你跟他讨论需求的时候，他首先想的是这个需求如何实现，而不是这个需求本身是否合理？这个需求跟其它需求有什么关联关系？
这种过早考虑“实现细节“的思考方式，会让你“只见树木，不见森林“，最终淹没在茫茫的各种细节之中，层次混乱，把握不住重点。
同样拿上面的例子举例，假如让你做一个新的系统，那么从“抽象“到“细节“，你可能需要考虑：
每个需求的合理性？
这个系统的领域模型是什么样的？
这个系统是应该在旧的上面改造？还是应该另起炉灶？
这个系统可以分成几期，分期实施？
这个系统要拆分成几个子系统？
每个子系统又拆分出多少个模块？
系统的表设计？api接口设计？job的设计？系统之间的消息传输？
。。。
从上到下，是一个逐级细化的过程，并且进入到下1级之后，上1级可能又会退回去修改。
深入思考的能力
深入思考能力，这里主要指“技术“的深度。关于“广度“，在上面的“格局“这个层面已经包含。
“深度“不是说，你要在所有领域都很深。人一生的精力是有限的，你不可能对所有技术领域都很深，但你需要1个比较深的领域。
这种深度，并不代表你当前的工作就需要这个技术领域，而是说这种“深入思考的方式“，会让你在思考其他问题时，也会带着这个“习惯“。
这个东西很重要，因为技术一直在更新换代，当你面对一个新技术的时候，如果你有深入思考的能力和习惯，那你对新技术的理解往往也就很透彻。
同时，“深度“会让你对“技术风险“有更加清醒的认知，你做一个项目的时候，这里面潜在的“坑“，你可能会提前发现，而不是等做到那了，发现问题了，被迫思考。
架构的落地
任何的架构必须可以落地，可以实现。不能落地，只能停留在ppt上面的架构，那只能忽悠人。这种架构，对实际不仅没有指导作用，还会有反作用，对实际开发产生误导。
而一个架构师，应该跟踪从架构设计到架构落地到完整过程，“理论“到“实际“必然是有间隙的，跟踪这个过程，实时修正，才可能真的做到“理论“与“实际“的统一。
业务架构 vs. 技术架构 vs. 基础架构
基础架构：这个很容易理解，IDC、云平台、网络、分布式存储、数据库、消息中间件、SOA中间件、缓存、监控系统、大数据计算平台。。。
技术架构：为了支撑某类业务， 强调系统的“高性能“，“高并发“，“高可靠“、强一致性等。
业务架构：同样是为了支撑某类业务，但和技术架构的侧重点不同。 业务架构强调的是对“领域“的深刻理解，这通常和“领域专家“密切相关，这里可能会强调系统的“可扩展性“，“可复用性“，对需求的弹性应对。
自底往上，基础架构、技术架构、业务架构并不是相互独立的，一般都是“业务驱动技术“，2者在互相促进中，同时往深度、广度上发展。
组织架构与领导力
再复杂的系统，都是“人“开发出来的。而人多了之后，“人“相关的问题都会自然产生：沟通不充分、组织混乱、职责不清。。。
作为一个架构师，一般很难“独善其身“，说我只管“技术“，不管“人“。因为你的工作，是一个“团队“完成的，而不是一个“千里走单骑“的英雄。
所以熟悉整个组织架构，沥青职责，把各种混乱的流程、协作理顺，也是应该考虑在内的。
另一方面，组织架构和技术架构有着非常强的关联：
合理的团队，组织架构应该是根据业务的架构来拆分的，业务一直在发展，业务的架构也会一直迭代，组织架构也跟着迭代；
但现实中，往往遇到的情况是组织架构僵化，因为这涉及到利益分配，结果是组织架构约束了业务架构，也约束了技术架构的发展。而这就是看公司高层的领导力了。
作为JAVA架构师需要掌握的技术
总结
说到现在，你会发现，我可能说的并不是一个“纯粹的架构师“。的确如此，上面这些是我认为作为一个“技术人“，应该去不断修炼的东西，而不是光“架构师“需要。
