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