微信号:infoqchina

介绍:有内容的技术社区媒体

隆中对:指点迷津的架构之道

2016-03-09 08:00 聊聊架构

夫架构之道,始于足下。 方今正用英雄时,不可失一人之言而失成功路。今天就在这里,与老司机一同煮酒论架构。

本文转自InfoQ旗下垂直号聊聊架构「架构漫谈」专栏,阅读完整版请关注公众号:聊聊架构(ID:archtime),回复关键词「1」~「9」。

一、什么是架构?


一直以来,在软件行业,对于什么是架构,都有很多的争论,每个人都有自己的理解。甚至于很多架构师一说架构,就开始谈论什么应用架构、硬件架构、数据架构等等。我曾经也到处寻找过架构的定义,请教过很多人,结果发现,没有大家都认可的定义。套用一句关于big data流行的笑话,放在架构上也适用:

Architecture is like teenage sex,everybody talks about it,nobody really knows what is it。

什么是架构,就是:

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

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

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

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

套用三国演义的一句话,合久必分,分久必合。架构实际上就是指人们根据自己对世界的认识,为解决某个问题,主动地、有目的地去识别问题,并进行分解、合并,解决这个问题的实践活动。架构的产出物,自然就是对问题的分析,以及解决问题的方案:包括拆分的原则以及理由,沟通合并的原则以及理由,以及拆分,拆分出来的各个部分和合并所对应的角色和所需要的核心能力等。

二、认识概念是理解架构的基础

每个概念实际上所解决的,还是人遇到的某个特定的问题,我们把解决问题的解决方案,给定了一个名字,这个名字就是对应的某个特定的概念。对于概念这个词本身,为了统一指代这些名字,我们称起这类作用的名字称为“概念”,“架构”也是是同样的一个特定概念。

我注意到,在做架构师的群体中,不谈抽象好像就不是一个合格的架构师。抽象这个词代表的含义,实际上是把不同的概念的相似的部分合并在一起,形成一个新的概念。我们不能用抽象来定义一个事物,抽象实际上是一个分类的过程,完全是另一码事。

根据架构的定义,要做好架构所首先必须具备的能力,就是能够正确的认识概念,能够发现概念背后所代表的问题,进而才能够认识目标领域所需要解决的问题,这样才能够为做好架构打好基础。做架构的时候,很多时候都是在一个新的领域解决问题,必须要快速进入并掌握这个领域,然后才能够正确的解决问题。

三、如何做好架构之识别

作为软件工程师或者架构师,我们大部分时候是要去解决别人的问题,“别人”是谁,是值得好好思考的。 找出问题的主体,是做架构的首要问题。再进一步,我们一定要明白,任何找上架构师的问题,绝对都不是真正的问题。为什么呢? 因为如果是真正的问题的话,提问题过来的人肯定都能够自己解决了,不需要找架构师。架构师都要有这个自觉:发现问题永远都比解决问题来的更加重要。

要正确的认识问题,需要问两个问题:

  1. 这是谁的问题?

  2. 有什么问题?

以我的经验,问题1会花比较多的时间,也是支支吾吾最多的地方,因为架构要解决的问题都是人的问题。但是一旦确定了答案,问题2就会变得非常容易。可以这样说,架构师的能力大部分会体现在问题1的识别上。

四、如何做好架构之架构切分

架构切分的导火索是人的负载太重。架构的切分实际就是对stakeholder的利益进行切分或合并,使得每个stakeholder的权责是对等的,每个stakeholder可以为自己的利益负责。 

架构切分的最终结果都会体现在组织架构上,只有这样才能够让架构落地并推进。 架构切分的结果一定是一个树状,这也是为什么会产生分层。层数越多沟通越多,效率越低,分层要越少越好。尽可能变成一颗平衡树,才能让整个系统的效率最大化。

五、什么是软件

早期的程序员写程序,主要是为了帮助自己研究课题。这些程序员熟练了之后,提高了自己的生产力,并发现还可以帮助别人写程序,慢慢软件就变成了一个独立的行业。程序从早期由一个人完成,也逐渐变成了由很多不同角色的人共同合作来完成。

软件架构的出现也是同样的。一开始是懵懵懂懂的去写软件,后来慢慢的就有意识的去切分,演变成了不同的架构。这个背后的动力也是一样的,就是提升参与的人的利益,降低成本。导火索也是软件工程师的任务太重,我们需要把很多工作拆分出来。拆分的原则也是一样的,如何让权责一致。

六、软件架构到底要解决什么问题?

  1. 软件因为流量增大而分拆成不同的运行单元,在不同的机器上部署所形成的架构,属于软件架构。

  2. 每个运行单元为了让不同角色的人,比如前端,业务,数据存储等能够并行工作,所分成的代码架构,也属于软件架构。

当我们说软件架构的时候,我们一定要讲清楚,究竟说的是部署的架构,还是代码的架构。软件架构的落地,需要软件的组织架构和流程来保障,离开了这个,软件架构是一句空话。

七、架构师没有话语权,还架什么构!

架构师是要去平衡别人的利益,甚至会调整别人的利益的。一旦架构师是全心全意的为别人的利益服务,自然而然的架构师就拥有了强有力的影响力,肯定会是一个leader。

架构师必须是一个组织的领导人,有权利调动这个组织的架构,才能够更好的发挥架构师的作用,更好的把利益的调整落到实处。所以很多公司设了很多架构师的职位,但是并不具备调动组织架构的权利,那么这个架构师的职位一定是形同虚设。

反过来,具备架构师能力的组织领导人,一定是一个很好的领导,这个组织一定是很健康向上的,因为每个人的权利和义务就是比较均等的。并且这类领导对于组织成员权利和义务的对等状况会非常的敏感,会及时的调整组织架构,在问题发生之前就解决了。

这样这个组织就会具备更好的抗压能力,能够更好的为这个组织的客户服务,这个组织的成员内心一定都是比较平衡的,每个人的能力都能够得到比较好的发展。

八、从架构的角度看如何写好代码

硬件部署架构是由代码的架构来决定。所以我们经常会听说,重写代码,推翻原有架构,重新设计等等说法,来说明架构的进化。这实际上就是当初为了完成任务,没有充分思考所带来的后果。软件实际上是对现实生活的模拟,虚拟化。

逻辑只允许存在于Business中,Service、Glue Code、Repository都不允许存在业务逻辑。在软件代码中,不需缩进和计算的顺序调用,包括缩进的代码目的是catch exception的,都不算逻辑,除此以外都是逻辑。

想要快速的完成代码工作,就要克服自己对时间的恐惧,真正去研究业务的问题,相关stakeholder的利益,把它变成习惯。

九、技术、业务和架构之间的关系?

在软件设计开发的过程中经常会看到,很多所谓的架构讨论实际上只是在讨论某种技术。 在很多人的概念里面,架构和技术实际上是等同的。学会了几种技术,就认为自己是架构师了,甚至是学习的技术越多,就觉得自己的水平越高。这样实际上是对自己很不负责任的。要知道任何技术都是为了解决某种问题而存在的,学会了技术,并不代表自己能够解决问题,这一点非常的重要。

而细粒度的技术往往不会和业务的主要目标发生直接的关系。不同的技术,通过树状结构,组合在一起,形成了一个完整的架构解决方案,共同完成业务的目标。这就是技术,业务和架构之间的关系。

架构师应该承担起解决业务问题的这个角色来,专注于Business Domain和软件本身的架构,让技术人员致力于为业务在计算机中跑起来而努力。只有把这两者很好的结合起来,才能更好地完成业务的目标,才会让软件更好地服务于大家。

当现有已经存在很多技术,而这些技术却和我们所要解决的问题并不是那么直接对应的时候,我们就需要有意识的组织和识别不同的技术,来实现业务的目标。 准确识别采用什么技术的能力,也是架构师所要具备的能力之一。考虑的主要因素也是长期的成本和收益。

作为架构师,我们是在扮演上帝的角色:我们不但要创建出一个个的程序,还要让这些程序能够脱离我们在硬件上独立运行,以便为这个程序所服务的群体提供服务。希望这篇文章可以作为切入点,以此来深入探究架构之迷津。

相约QCon,与大牛面对面:

余锋(花名褚霸 )阿里云研究员,有超过15年的网络和底层系统开发经验,专注于高性能分布式服务器的研究和实现,擅长构建大规模集群存储服务器。目前负责 AliCloudDB 数据库产品。点击阅读原文,了解更多大牛信息!



本文系InfoQ原创首发,未经授权谢绝转载。

 
InfoQ 更多文章 年前挖的坑都填了吗?技术债务偿还计划 程序员VS武林高手:技术为外功,思维乃内力 腾讯游戏大数据服务场景与应用(附PPT) 偷师饿了么:怎样用HTTP/2优化iOS APP网络层次架构? 作为高颜值的女程序员是一种怎样的体验?
猜您喜欢 趁年轻,学会花钱 这坚不可摧的加密可以拯救互联网 API 调用次数限制实现 技术不应成为业务的工具,一个资深架构师的思辩 Nginx与Lua的执行顺序和步骤说明