夫架构之道，始于足下。方今正用英雄时，不可失一人之言而失成功路。今天就在这里，与老司机一同煮酒论架构。本文转自InfoQ旗下垂直号聊聊架构「架构漫谈」专栏，阅读完整版请关注公众号：聊聊架构（ID：archtime），回复关键词「1」~「9」。
一直以来，在软件行业，对于什么是架构，都有很多的争论，每个人都有自己的理解。甚至于很多架构师一说架构，就开始谈论什么应用架构、硬件架构、数据架构等等。我曾经也到处寻找过架构的定义，请教过很多人，结果发现，没有大家都认可的定义。套用一句关于big data流行的笑话，放在架构上也适用：
Architecture is like teenage sex，everybody talks about it，nobody really knows what is it。
什么是架构，就是：
根据要解决的问题，对目标系统的边界进行界定。 并对目标系统按某个原则的进行切分。切分的原则，要便于不同的角色，对切分出来的部分，并行或串行开展工作，一般并行才能减少时间。 并对这些切分出来的部分，设立沟通机制。 根据3，使得这些部分之间能够进行有机的联系，合并组装成为一个整体，完成目标系统的所有工作。
套用三国演义的一句话，合久必分，分久必合。架构实际上就是指人们根据自己对世界的认识，为解决某个问题，主动地、有目的地去识别问题，并进行分解、合并，解决这个问题的实践活动。架构的产出物，自然就是对问题的分析，以及解决问题的方案：包括拆分的原则以及理由，沟通合并的原则以及理由，以及拆分，拆分出来的各个部分和合并所对应的角色和所需要的核心能力等。
每个概念实际上所解决的，还是人遇到的某个特定的问题，我们把解决问题的解决方案，给定了一个名字，这个名字就是对应的某个特定的概念。对于概念这个词本身，为了统一指代这些名字，我们称起这类作用的名字称为“概念”，“架构”也是是同样的一个特定概念。
我注意到，在做架构师的群体中，不谈抽象好像就不是一个合格的架构师。抽象这个词代表的含义，实际上是把不同的概念的相似的部分合并在一起，形成一个新的概念。我们不能用抽象来定义一个事物，抽象实际上是一个分类的过程，完全是另一码事。
根据架构的定义，要做好架构所首先必须具备的能力，就是能够正确的认识概念，能够发现概念背后所代表的问题，进而才能够认识目标领域所需要解决的问题，这样才能够为做好架构打好基础。做架构的时候，很多时候都是在一个新的领域解决问题，必须要快速进入并掌握这个领域，然后才能够正确的解决问题。
作为软件工程师或者架构师，我们大部分时候是要去解决别人的问题，“别人”是谁，是值得好好思考的。找出问题的主体，是做架构的首要问题。再进一步，我们一定要明白，任何找上架构师的问题，绝对都不是真正的问题。为什么呢? 因为如果是真正的问题的话，提问题过来的人肯定都能够自己解决了，不需要找架构师。架构师都要有这个自觉：发现问题永远都比解决问题来的更加重要。
要正确的认识问题，需要问两个问题：
这是谁的问题？ 有什么问题？
以我的经验，问题1会花比较多的时间，也是支支吾吾最多的地方，因为架构要解决的问题都是人的问题。但是一旦确定了答案，问题2就会变得非常容易。可以这样说，架构师的能力大部分会体现在问题1的识别上。
架构切分的导火索是人的负载太重。架构的切分实际就是对stakeholder的利益进行切分或合并，使得每个stakeholder的权责是对等的，每个stakeholder可以为自己的利益负责。
架构切分的最终结果都会体现在组织架构上，只有这样才能够让架构落地并推进。 架构切分的结果一定是一个树状，这也是为什么会产生分层。层数越多沟通越多，效率越低，分层要越少越好。尽可能变成一颗平衡树，才能让整个系统的效率最大化。
早期的程序员写程序，主要是为了帮助自己研究课题。这些程序员熟练了之后，提高了自己的生产力，并发现还可以帮助别人写程序，慢慢软件就变成了一个独立的行业。程序从早期由一个人完成，也逐渐变成了由很多不同角色的人共同合作来完成。
软件架构的出现也是同样的。一开始是懵懵懂懂的去写软件，后来慢慢的就有意识的去切分，演变成了不同的架构。这个背后的动力也是一样的，就是提升参与的人的利益，降低成本。导火索也是软件工程师的任务太重，我们需要把很多工作拆分出来。拆分的原则也是一样的，如何让权责一致。
软件因为流量增大而分拆成不同的运行单元，在不同的机器上部署所形成的架构，属于软件架构。 每个运行单元为了让不同角色的人，比如前端，业务，数据存储等能够并行工作，所分成的代码架构，也属于软件架构。
当我们说软件架构的时候，我们一定要讲清楚，究竟说的是部署的架构，还是代码的架构。软件架构的落地，需要软件的组织架构和流程来保障，离开了这个，软件架构是一句空话。
架构师是要去平衡别人的利益，甚至会调整别人的利益的。一旦架构师是全心全意的为别人的利益服务，自然而然的架构师就拥有了强有力的影响力，肯定会是一个leader。
架构师必须是一个组织的领导人，有权利调动这个组织的架构，才能够更好的发挥架构师的作用，更好的把利益的调整落到实处。所以很多公司设了很多架构师的职位，但是并不具备调动组织架构的权利，那么这个架构师的职位一定是形同虚设。
反过来，具备架构师能力的组织领导人，一定是一个很好的领导，这个组织一定是很健康向上的，因为每个人的权利和义务就是比较均等的。并且这类领导对于组织成员权利和义务的对等状况会非常的敏感，会及时的调整组织架构，在问题发生之前就解决了。
这样这个组织就会具备更好的抗压能力，能够更好的为这个组织的客户服务，这个组织的成员内心一定都是比较平衡的，每个人的能力都能够得到比较好的发展。
硬件部署架构是由代码的架构来决定。所以我们经常会听说，重写代码，推翻原有架构，重新设计等等说法，来说明架构的进化。这实际上就是当初为了完成任务，没有充分思考所带来的后果。软件实际上是对现实生活的模拟，虚拟化。
逻辑只允许存在于Business中，Service、Glue Code、Repository都不允许存在业务逻辑。在软件代码中，不需缩进和计算的顺序调用，包括缩进的代码目的是catch exception的，都不算逻辑，除此以外都是逻辑。
想要快速的完成代码工作，就要克服自己对时间的恐惧，真正去研究业务的问题，相关stakeholder的利益，把它变成习惯。
在软件设计开发的过程中经常会看到，很多所谓的架构讨论实际上只是在讨论某种技术。在很多人的概念里面，架构和技术实际上是等同的。学会了几种技术，就认为自己是架构师了，甚至是学习的技术越多，就觉得自己的水平越高。这样实际上是对自己很不负责任的。要知道任何技术都是为了解决某种问题而存在的，学会了技术，并不代表自己能够解决问题，这一点非常的重要。
而细粒度的技术往往不会和业务的主要目标发生直接的关系。不同的技术，通过树状结构，组合在一起，形成了一个完整的架构解决方案，共同完成业务的目标。这就是技术，业务和架构之间的关系。
架构师应该承担起解决业务问题的这个角色来，专注于Business Domain和软件本身的架构，让技术人员致力于为业务在计算机中跑起来而努力。只有把这两者很好的结合起来，才能更好地完成业务的目标，才会让软件更好地服务于大家。
当现有已经存在很多技术，而这些技术却和我们所要解决的问题并不是那么直接对应的时候，我们就需要有意识的组织和识别不同的技术，来实现业务的目标。准确识别采用什么技术的能力，也是架构师所要具备的能力之一。考虑的主要因素也是长期的成本和收益。
作为架构师，我们是在扮演上帝的角色：我们不但要创建出一个个的程序，还要让这些程序能够脱离我们在硬件上独立运行，以便为这个程序所服务的群体提供服务。希望这篇文章可以作为切入点，以此来深入探究架构之迷津。
相约QCon，与大牛面对面：
余锋（花名褚霸 ）阿里云研究员，有超过15年的网络和底层系统开发经验，专注于高性能分布式服务器的研究和实现，擅长构建大规模集群存储服务器。目前负责 AliCloudDB 数据库产品。点击阅读原文，了解更多大牛信息！
本文系InfoQ原创首发，未经授权谢绝转载。
本文转载自：微信公众账号 - InfoQ，版权归原作者所有！ | 
注册
登录
