在今天的技术圈，可能随便遇到一个人递给你一张名片，title 就是某某架构师。架构师多如过江之鲫，也正是眼下业内一个有趣的现象。对于架构师，你有什么看法？
什么是架构师？
随便打开某招聘网站：系统架构师、搜索架构师、前端架构师、iOS/Android 架构师、平台架构师、（大）数据架构师、JAVA/PHP/.NET 架构师、高级架构师、资深架构师、BI 架构师，这些是大家常见的，君不见还有后台架构师、MIS/ERP/OA 系统架构师、金融系统架构师、搜索架构师、总线架构师、运维架构师，安全架构师...... 林林总总，不一而足。
仅仅是上面这些岗位名称，就能看到架构师岗位的差异之大，方向不同、技术栈不同、行业不同，即便同一个岗位，水平差距也是天壤之别，如果仅以架构师一个称谓来描述，显然是不合适的，所以我觉得今天在行业内这个称谓还有点”虚”。
李维先生曾经有过一次演讲，讲到了一个架构师应该具备的特性：
1. 核心软件技术。要攻克数据库设计问题，必须深入了解数据库的工作原理，而不是会写复杂的SQL会管理个备份会设计个表结构就算精通数据库。有人甚至把会用hibernate\structs\spring当作自己会核心软件技术。
2. 产品特性。你学了那么多核心技术，到底要干吗？我一直在商业软件公司工作，没有在研究所工作过。我各种技术要做到的就是帮助企业软件生产，如何更快更省力气质量更好市场竞争力更强。
3. 软件趋势。在企业管理软件开发领域，往往会见到这样的现象：不少开发人员精通客户业务需求，深入第一线做客户实施。他们学习技术也是为了解决现有手头的问题。尤其企业管理软件开发领域，技术要求并不高，而如果不了解客户需求，开发的软件实用性就不强，即使你的功能开发的又性能好又安全性好也没实用意义。
架构切分，本质上是利益的调整
在识别出是谁的问题之后，大部分情况下问题都迎刃而解。但总还有一部分确实是有问题的，需要做调整。
这个调整就是架构的切分。简单来说：
架构的切分的导火索是人的负载太重。
架构的切分实际就是对 stakeholder 的利益进行切分或合并，使得每个 stakeholder 的权责是对等的，每个 stakeholder 可以为自己的利益负责。
架构切分的最终结果都会体现在组织架构上，只有这样才能够让架构落地并推进。
架构切分的结果一定是一个树状，这也是为什么会产生分层。层数越多沟通越多，效率越低，分层要越少越好。尽可能变成一颗平衡树，才能让整个系统的效率最大化。
如何才能把握好这两个问题？怎样才能快速的层层剖析，找到问题的主题？又如何才能合理有效的进行切分？这些问题，是制约是否成为出色架构师的关键。
什么是好的软件架构
这个问题，可能大家一直都在问，包括一些IT企业也在问，对于这个问题的回答，可能不仅仅是一个简单的语句或者是定义就可以回答的出的，我们来看下面的几个形象的例子：
这个是什么东东呢？乐高玩具，乐高玩具大家肯定都玩过吧？
它即可以以一个完整的模型卖给你，你也可以把它全部打碎了重新从一个模型自由的再去组装成另一个模型，因为每一个乐高的模块在横向、坚向里都有标准的接口，这就是我们常说的高内聚、低耦合。
良好的沟通
架构师需要知道，有效沟通是建立信任和影响团队以外成员的关键技能。他们知道不同群体使用不同的词汇，而使用技术术语和描述与业务人员沟通将会变得比较困难。与其谈论模式、工具和编程概念，架构师需要使用听众熟悉的词汇与之交流，诸如风险回报、成本和收益等。这比单纯使用技术词汇进行沟通来得更好。架构师还需要认识到团队内部沟通与外部沟通同样重要，可以使用图表和小组讨论的方式来建立和完善技术愿景，并书面记录之（如架构决策日志或Wiki等），从而为将来留下可追溯的历史。
结语
架构之路任重而道远。程序设计和架构设计是互通的，每个人都可以从设计好一个程序往设计好一个系统架构前进。
想成为架构师不是懂了一大堆技术就可以了，这些是解决问题的基础、是工具，不懂这些怎么去提解决方案呢？这是成为架构师的必要条件。
架构师还要针对业务特点、系统的性能要求提出能解决问题成本最低的设计方案才合格，人家一个几百人用户的系统，访问量不大，数据量小，你给人家上集群、上分布式存储、上高端服务器，为了架构而架构，这是最扯淡的，架构师的作用就是第一满足业务需求，第二最低的硬件网络成本和技术维护成本。
另外还有一点可以通过自身的学习来获取一大进步。
分享给超过5万的程序员朋友下载，这次我把所有资料重新梳理精简，免费分享给大家 。
究竟有哪些干货呢？先给你们一个目录：
免费领取资料途径：公众平台 “程序员编程"
