缘起
一直以来，在软件行业，对于什么是架构，都有很多的争论，每个人都有自己的理解。甚至于很多架构师一说架构，就开始谈论什么应用架构、硬件架构、数据架构等等。我曾经也到处寻找过架构的定义，请教过很多人，结果发现，没有大家都认可的定义。套用一句关于 big data 流行的笑话，放在架构上也适用：
Architecture is like teenage sex，everybody talks about it，nobody really knows what is it。
事实上，架构在软件发明时的 N 多年以前，就已经存在了，这个词最早是跟随着建筑出现的。所以，有必要从源头开始，把架构这个概念先讨论清楚，只有这样，软件行业架构的讨论才有意义。
什么是架构？
架构的英文是 Architecture，在Wikipedia 上，架构是这样定义的：
Architecture (Latin architectura, from the Greek ἀρχιτέκτων arkhitekton"architect", from ἀρχι- "chief" and τέκτων "builder") is both the process and the product of planning, designing, and constructing buildings and other physical structures。
从这个定义上看，架构好像是一个过程，也不是很清晰。为了讲清楚这个问题，我们先来看看为什么会产生架构。
为什么会产生架构？
想象一下，在最早期，每个人都完全独立生活，衣、食、住、行等等全部都自己搞定，整个人类都是独立的个体，不相往来。为了解决人类的延续的问题，自然而然就有男女群居出现，这个时候就出现了分工了，男性和女性所做的事情就会有一定的分工，可是人每天生活的基本需求没有发生变化，还是衣食住行等生活必须品。
但是一旦多人分工配合作为生存的整体，力量就显得强大多了，所以也自然的形成了族群：有些人种田厉害，有些人制作工具厉害，有些地方适合产出粮食，有些地方适合产出棉花等，就自然形成了人的分群，地域的分群。当分工发生后，实际上每个人的生产力都得到了提高，因为做的都是每个人擅长的事情。
整个人群的生产力和抵抗环境的能力都得到了增强。为什么呢？因为每个人的能力和时间都是有限的，并且因为人的结构的限制，人同时只能专心做好一件事情，这样不得已就导致了分工的产生。既然分工发生了，原来由一个人干生存所必需的所有的事情，就变成了很多不同分工的角色合作完成这些事情，这些人必须要通过某些机制合在一起，让每个人完成生存所必需的事情，这实际上也导致了交易的发生（交易这部分就不在这里展开了，有机会再讨论）。
在每个人都必须自己完成所有生活必须品的生产的时候，是没有架构的（当然在个人来讲，同一时刻只能做有限的事情，在时间上还是可能会产生架构的）。一旦产生的分工，就把所有的事情，切分成由不同角色的人来完成，最后再通过交易，使得每个个体都拥有生活必须品，而不需要每个个体做所有的事情，只需要每个个体做好自己擅长的事情，并具备一定的交易能力即可。
这实际上就形成了社会的架构。那么怎么定义架构呢？以上面这个例子为例，把一个整体（完成人类生存的所有工作）切分成不同的部分（分工），由不同角色来完成这些分工，并通过建立不同部分相互沟通的机制，使得这些部分能够有机的结合为一个整体，并完成这个整体所需要的所有活动，这就是架构。由以上的例子，也可以归纳出架构产生的动力：
- 必须由人执行的工作（不需要人介入，就意味着不需要改造，也就不需要架构了）
- 每个人的能力有限（每个人都有自己的强项，个人的产出受限于最短板，并且由于人的结构限制，同时只能专注于做好一件事情，比如虽然有两只眼睛，但是只能同时专注于一件事物，有两只手，无法同时做不同的事情。ps. 虽然有少部分人可以左手画圆右手画框，但是不是普遍现象）
- 每个人的时间有限（为了减少时间的投入，必然会导致把工作分解出去，给擅长于这些工作的角色来完成，见 2，从而缩短时间）
- 人对目标系统有更高的要求（如果满足于现状，也就不需要进行架构了）
- 目标系统的复杂性使得单个人完成这个系统，满足条件 2，3（如果个人就可以完成系统的提高，也不需要别的人参与，也就不需要架构的涉及，只是工匠，并且一般这个工作对时间的要求也不迫切。当足够熟练之后，也会有一定的架构思考，但考虑更多的是如何提高质量，提高个人的时间效率）
有人可能会挑战说，如果一个人对目标系统进行分解，比如某人建一栋房子，自己采购材料，自己搭建，难道也不算架构嘛？如果对于时间不敏感的话，是会出现这个情况的，但是在这种情况下，并不必然导致架构的发生。如果有足够的自觉，以及足够的熟练的话，也会产生架构的思考，因为这样对于提高生产力是有帮助的，可以缩短建造的时间，并会提高房子的质量。事实上建筑的架构就是在长期进行这些活动后，积累下来的实践。
当这 5 个条件同时成立，一定会产生架构。从这个层面上来说，架构是人类发展过程中，由懵懵懂懂的，被动的去认识这个世界，变成主动的去认识，并以更高的效率去改造这个世界的方法。以下我们再拿建筑来举例加强一下理解。
最开始人类是住在山洞里，住在树上的，主要是为了躲避其他猛兽的攻击，以及减少自然环境的变化，对人类生存的挑战。为了完成这些目标，人类开始学会在平地上用树木和树叶来建立隔离空间的设施，这就是建筑的开始。但是完全隔离也有很多坏处，慢慢就产生了门窗等设施。
建筑的本质就是从自然环境中，划出一块独占的空间，但是仍然能够通过门窗等和自然环境保持沟通。这个时候架构就已经开始了。对地球上的空间进行切分，并通过门窗，地基等，保持和地球以及空间的有机的沟通。当人类开始学会用火之后，茅棚里面自然而然慢慢就会被切分为两部分，一部分用来烧饭，一部分用来生活。当人的排泄慢慢移入到室内后，洗手间也就慢慢的出现了。这就是建筑内部的空间切分。
这个时候人们对建筑的需求也就慢慢的越来越多，空间的切分也会变成很多种，组合的方式也会有很多种，比如每个人住的房子，群居所产生的宗教性质的房子，集体活动的房子等等。这个时候人们就开始有意识的去设计房子，架构师就慢慢的出现了。一切都是为了满足人的越来越高的需求，提升质量，减少时间，更有效率的切分空间，并且让空间之间更加有机的进行沟通。这就是建筑的架构以及建筑的架构的演变
总结一下，什么是架构，就是：
- 根据要解决的问题，对目标系统的边界进行界定。
- 并对目标系统按某个原则的进行切分。切分的原则，要便于不同的角色，对切分出来的部分，并行或串行开展工作，一般并行才能减少时间。
- 并对这些切分出来的部分，设立沟通机制。
- 根据 3，使得这些部分之间能够进行有机的联系，合并组装成为一个整体，完成目标系统的所有工作。
同样这个思考可以展开到其他的行业，比如企业的架构，国家的架构，组织架构，音乐架构，色彩架构，软件架构等等。套用三国演义的一句话，合久必分，分久必合。架构实际上就是指人们根据自己对世界的认识，为解决某个问题，主动地、有目的地去识别问题，并进行分解、合并，解决这个问题的实践活动。架构的产出物，自然就是对问题的分析，以及解决问题的方案：包括拆分的原则以及理由，沟通合并的原则以及理由，以及拆分，拆分出来的各个部分和合并所对应的角色和所需要的核心能力等。
架构师职责
1 确认需求
架构师要懂得用户需求，理解用户真正想要什么，这使得架构师必须要和分析人员不断沟通，反复确认需求规格说明书，以此来保证他精准清楚用户需求。
项目经理刘先生在受访时说：「架构师会与很多人沟通，例如开发人员，例如我们项目经理，有时甚至是用户本身。架构设计的目的很明确，目的是什么呢？挖掘用户需求。」
2 系统分解
在架构师认可需求规格说明书后，架构师已明确用户需求是是什么，这时候便看架构师的分解能力了。
通过100offer入职的全栈技术架构师周先生从「纵向分解」和「横向分解」和我们说明了系统分解是什么——
「一般分为纵向分解和横向分解，纵向分解是将整个系统分层，从而将整体系统分解成下一级的子系统与组件。横向分解是在系统分解成不同的逻辑层或服务后，对逻辑层进行分块，确定层与层之间的关系。」
3 技术选型
在系统分解后，架构师会最终形成软件整体架构，接下来，架构师的职责是技术选型。
「前端到底用瘦客户端还是富客户端呢？数据库是用MySQL还是MSSQL又或是Oracle呢？」架构师张先生在接受采访时说，「在了解用户需求后，分解完系统后，技术选型是非常重要的环节，提出各个方向，我再进行评估。不过，很多人都以为架构师是有决定权的，其实不是，架构师没有拍版的权力，决定由项目经理来做。 」
架构师在技术选型阶段会提供参考信息给项目经理，项目经理再从预算、进度、人力、资源等各方面情况来权衡，最终确认。
4 制定技术规格说明
如前文调查显示，架构师在项目开发过程中是「灵魂人物」，并且要具备协调组织能力和懂得人员分工。
在制定技术规格说明阶段，架构师要协调起所有的开发人员，架构师通常会用技术规格说明书与开发人员保持沟通，让开发人员能从各个视角去观测、理解他们负责的模块或者子系统，确保开发人员能够按照架构意图实现各项功能。
架构师应该具备怎样的能力呢
从广义上应具备以下能力：
一、广度
广度指的是架构师应该对所在领域的主流技术体系有一个全面清晰的认识，每一种技术不需要很深入的了解，但必须知道每种技术的3W：
1，Why：每种技术的由来，为什么会出现这种技术，这个技术是用来解决什么问题的？
2，What：每种技术是什么？技术的基本组成部分是什么？
3，Which：解决同一问题的相同技术各自的优缺点是什么，更适合哪种场景？比如，ORM框架（Hibernate，IBatis与EFCore），MVC框架（Struts,SpringMVC与Asp.Netcore MVC），大数据技术（Hadoop与Spark）它们各自的优缺点是什么，只有清晰认识同一类型技术的优缺点，才能在技术选型时能够使用更加合理的技术。
广度的学习方法：对各主流技术一一通过搜索引擎了解其3W的内容。
二、高度
高度指的是架构师应具备对客观事物的“拔高”能力，能够从纷繁杂乱的信息中建立秩序，也就是我们一般所说的抽象能力。抽象能力包括：
1，业务抽象：能够软件和产品的复杂的需求中抽象核心业务实体，并给各业务实体建立合理的关系；
2，技术抽象：能够对复杂的技术架构进行分层抽象、服务抽象（微服务抽象）、组件抽象，并为各层和各服务之间的调用建立合理的“关系”；
高度的学习方法：深入理解和学习面向对象、设计模式，琢磨优秀开源框架的设计原理和设计思想。
三、深度
深度指的是架构师能对主流技术有较为深入的理解，主要包括：
1，可以不了解源代码，但对主流技术的原理，运作机理有一个基本的理解；
2，至少对一种技术有深入的认识，是这种技术的专家，熟悉其源代码
以上2点，1为必须，2为非必须
四、宽度
宽度指的是架构师能够熟知当前的技术前沿和热点，能够使用新的技术解决问题。比如，微服务、大数据、云计算、人工智能等。
宽度的学习方法：可以使用手机订阅相关的技术资讯了解，定期了解即可，对于跟所负责工作相关的技术进行进一步的了解。
广度决定了系统架构技术选型的合理性；
高度决定了系统架构设计的合理性；
深度决定了系统架构的优化能力；
宽度决定了系统架构的领先性，不至于三五年被淘汰
从侠义上也应具备以下能力：
37%的受访人认为架构师的设计能力最重要，技术实力重要度排在第二占了24%，沟通能力则排在第三，占比14%，管理能力在大多数架构师眼中并不是最重要的，仅占了7%。此次，我们详细分析排在前三的能力。
1 设计能力－擅长整合分析
架构是过程，并非结果。
架构是架构师洞察内在结构、原则、规律与逻辑的过程，架构师要做到清晰理解系统，以及简洁描述，这是分析整合的能力。
一个架构师必须具备极强的分析能力，要做到根据产品宗旨和目标，分析清楚产品定位以及产品业务，再整合利用现有的技术领域，找出最佳方案，实现产品概念。
2 技术实力－实现产品规划
架构师首先要将代码写的清晰易懂，要能够实现功能，做到没有Bug，这要求架构师必须具备至少熟练掌握一门语言。
这是最重要的，每一名出色的架构师，必定是一位优秀程序员。架构师并不是纯粹的管理岗位，对那些爱写各式文档、画流程图、脱离代码、只说不做、高高在上的架构师，程序员们通常会称他们为——
PPT 架构师。
不懂编程的架构师的职业生涯必定是短暂的，无论如何都不可本末倒置，要想实现自己的职业规划，不能荒废自己本身的技能，技术是架构师赖以生存的最基本能力。
所以，不推荐不热爱编程的人去做架构师，对于团队工作和个人发展来说，都会带来糟糕的后果。
3 沟通能力－能够横向沟通
架构师必须参与项目开发全过程，包括确认需求、系统分解、架构设计、技术选型、制定技术规格说明、系统实现、集成测试和部署各阶段，在这一系列过程中，架构师会与各部门沟通交流。
一个产品会有多部门合作，架构师在其中的沟通极为重要，直接影响产品进度与质量。架构师不仅要与开发人员沟通，也要和项目经理、分析人员甚至用户沟通，来实现产品的各种可能性。
所以，对于架构师来讲，不仅有技术方面的要求，还有能够横向沟通的要求。
架构漫谈（一）：什么是架构？ https://www.infoq.cn/article/an-informal-discussion-on-architecture-part01/
如何成为一个架构师？ https://www.zhihu.com/question/19627054
