读漫谈架构博文有感

     什么是架构,经常听到有人谈论架构,数据架构,应用架构,硬件架构,但我自己对这个概念很模糊。在维基百科上是这么定义架构的: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)。然后就会有提高效率的需求出现,要求改进这个技术。这个技术的低效率部分就会被其他人(或者技术发明人自己)加以改进,这部分就会形成新的技术。

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

 

 

 

 

      

 

 

原文地址:https://www.cnblogs.com/dk1203573488/p/8529551.html