读漫谈架构博文有感

     什么是架构，经常听到有人谈论架构，数据架构，应用架构，硬件架构，但我自己对这个概念很模糊。在维基百科上是这么定义架构的：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。从这个定义上看，架构好像是一个过程，也不是很清晰。总结一下，架构是什么：

1.根据要解决的问题，对目标系统的边界进行界定。

2.并对目标系统按某个原则的进行切分。切分的原则，要便于不同的角色，对切分出来的部分，并行或串行开展工作，一般并行才能减少时间。

3.并对这些切分出来的部分，设立沟通机制。

4.根据3，使得这些部分之间能够进行有机的联系，合并组装成为一个整体，完成目标系统的所有工作。

   什么是桌子，这个问题看上去很简单，但要用语言描述却有点僵硬。有四个腿和一个平面？一般与椅子配对出现？桌子下面有空间容纳腿？所以说，每个概念实际上解决的是某个特定的问题，然后把该方案起了一个名字，这个名字就是对应的特定概念。

   作为软件工程师或者架构师，大部分的时候是要解决别人的问题的，“别人”是谁，问题的目标主体是什么，这样才能认清真正的问题而不是盲目去做，最后看似完成了任务却谁也不满意。所以要正确的认识问题需要问两个问题：1.这是谁的问题 2.有什么问题，而问题一最能显示架构师的能力。

   从某种意义来说，谈架构就是谈分层，从根节点下来，深度相同的是同一层，同样我们看一个组织架构也可以做一个粗略的判断。架构的切分的导火索是人的负载太重，架构的切分实际就是对stakeholder（利益相关者）的利益进行切分或合并，使得每个stakeholder的权责是对等的，每个stakeholder可以为自己的利益负责。架构切分的结果一定是一个树状，这也是为什么会产生分层。层数越多沟通越多，效率越低，分层要越少越好。尽可能变成一颗平衡树，才能让整个系统的效率最大化。架构切分的最终结果都会体现在组织架构上，只有这样才能够让架构落地并推进。

    一开始是懵懵懂懂的去写软件，后来就有意识地去切分，演变成了不同的架构，这个导火索是软件工程师的任务太重，需要把很多的工作拆分出来。什么是软件架构：软件因为流量增大而分拆成不同的运行单元，在不同的机器上部署所形成的架构，属于软件架构。每个运行单元为了让不同角色的人，比如前端，业务，数据存储等能够并行工作，所分成的代码架构，也属于软件架构。所以当我们说软件架构的时候，我们一定要讲清楚，究竟说的是部署的架构，还是代码的架构。软件架构的落地，需要软件的组织架构和流程来保障，离开了这个，软件架构是一句空话。架构是进化出来的。架构实际上是在量不断的增大，超过了单台服务器的容量，逐渐的分拆，同时导致超过单个人员的能力，工作人员不断的增多，工作内容不断的分拆形成的。这本身就是架构的意义所在。不管怎么分拆，所达到的目标没有任何变化，就是完成业务在计算机中的虚拟化。

    架构师是要去平衡别人的利益，甚至会调整别人的利益的。一旦架构师是全心全意的为别人的利益服务，自然而然的架构师就拥有了强有力的影响力，肯定会是一个leader。但是只是民意上的leader是没有用的，不能完全发挥架构师的能量。反过来，具备架构师能力的组织领导人，一定是一个很好的领导，这个组织一定是很健康向上的，因为每个人的权利和义务就是比较均等的。并且这类领导对于组织成员权利和义务的对等状况会非常的敏感，会及时的调整组织架构，在问题发生之前就解决了。这样这个组织就会具备更好的抗压能力，能够更好的为这个组织的客户服务。

技术与架构，以及与业务之间的关系：技术总是在人类解决对业务的要求不断提高的情况下产生，目的也是为了获取更大更好的利益。所以：技术是为了解决业务的问题而产生的，没有了业务，技术就没有了存在的前提。有了更好的技术，效率更差的技术，就会慢慢的被淘汰，消失，一切都遵从人类的利益诉求——也就是业务。有人会问，不用钻木取火了，但是弓弦加速转动木棍还可以用啊？ 没错，因为弓弦转动木棍这个技术，不是来生火的，是用来加速木棍转动的，所解决的问题不一样。但是两种不同的技术，合理结合起来，会更好更有效率的解决业务问题。

　所以技术与技术之间，有两种关系：在解决同一个业务问题的前提下，更高效，更低成本的技术，会淘汰低效，高成本的技术。这是人类利益诉求所决定的。一般刚开始解决根本问题的技术（钻木取火）的效率是比较低的，只是把不可能变成了可能（从这一点上来说，技术才是业务的enabler）。然后就会有提高效率的需求出现，要求改进这个技术。这个技术的低效率部分就会被其他人（或者技术发明人自己）加以改进，这部分就会形成新的技术。

   架构本身不是目标，而简单实用且支持灵活扩展的系统才是最终目标。好的建筑应该通过美观，坚固，实用三个方面衡量，而好的架构也正是这三方面的平衡和配合，没有哪一个方面比其他方面更加重要。