微信号:infoqchina

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

关于架构,都有什么可以聊的?

2017-05-12 08:00 王概凯
作者|王概凯
编辑|小智  
在软件行业,架构师和工程师就类似于上帝,创建出形形色色的软件产品来服务于人类。要想当好这个角色,架构师自然也需要具备某种上帝的视角,来观察并表达这个世界。什么是架构、怎样做好架构、软件架构如何落地、如何写好程序、技术、业务和架构之间的关系如何?你还想了解什么?
什么是架构?

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

架构实际上解决的是人的问题,架构的产出物就是对问题的分析,以及解决问题的方案。它包括:拆分的原则以及理由,沟通合并的原则以及理由,以及拆分,拆分出来的各个部分和合并所对应的角色和所需要的核心能力等。

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

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

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

这就是架构。

为了让你更好地从本源上理解「架构」这个概念,我们耗时接近两年,打磨一本名为《聊聊架构》的技术书籍。花上五分钟,读完本文,再决定是否要入手这本可能无法成为畅销书的技术书。

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

架构实际上解决的是人的问题,而概念是人认识这个世界的基础,自然概念的认识就非常的重要。

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

要做好架构首先必须具备的能力是能 够正确的认识概念,能够发现概念背后所代表的问题,进而才能够认识目标领域所需要解决的问题

事实上,这一能力,在任何一个领域都是适用的,比如我们如果想要学习一项新的技术,如 Hibernate、Spring、PhotoShop、WWW、Internet 等等,如果知道这些概念所要解决的问题,学习这些新的技术或者概念就会如虎添翼,快速的入手;学习一个新的领域,也会非常的快速有效;使用这些概念来解释问题,甚至发明新的概念都是很容易的事。

为什么强调这个?因为做架构的时候,很多时候都是在一个新的领域解决问题,必须要快速进入并掌握这个领域,然后才能够正确的解决问题。

如何做好架构?
第一、识别问题,找到问题的主体

如果把真正的问题找到,那么问题就已经解决了 80% 了。这个能力基本上就决定了架构师的水平。找出问题的主体,是做架构的首要问题。这也是前面强调的,我们要解决的问题,一定都是人的问题。

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

一般来说,从问题暴露的点,一点点去溯源查找,一定会找出来谁的问题,以及是什么问题。最坏情况就是当我们时间或者能力有限,实在是无法定位出是谁的问题的时候,比如系统出故障,也就意味着我们无法根本解决问题。这时最好的办法就是去降低问题发生所带来的成本,尽量去隔离问题影响的范围。给我留出时间和空间去识别真正的问题。

总结一下,要正确的认识问题,需要问两个问题:

  • 这是谁的问题?

  • 有什么问题?

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

第二、架构切分,本质上是利益的调整

在识别出是谁的问题之后,会发现,在大部分情况下,问题都迎刃而解,不需要做额外的动作。但总还有一部分确实是有问题的,需要做调整,那么就必须要有所动作,做相应的调整。这个调整就是架构的切分。简单来说:

1、架构的切分的导火索是人的负载太重。

2、架构的切分实际就是对 stakeholder 的利益进行切分或合并,使得每个 stakeholder 的权责是对等的,每个 stakeholder 可以为自己的利益负责。

3、架构切分的最终结果都会体现在组织架构上,只有这样才能够让架构落地并推进。

4、架构切分的结果一定是一个树状,这也是为什么会产生分层。层数越多沟通越多,效率越低,分层要越少越好。尽可能变成一颗平衡树,才能让整个系统的效率最大化。

如何做架构切分?
切分就是利益的调整

我们要非常的清楚,所有的切分调整,都是对相关人的利益的调整。为什么这么说呢,因为维护自己的利益,是每个人的本性,是在骨子里面的,我们不能逃避这一点。我们以第一篇文章里面的例子为例来做解释。

为什么需要切分?

当人们认识到要主动的去切分一个系统的时候,毫无疑问,我们不能忘掉利益这个原动力。所有的切分决策都不能够违背这一点,这是大方向。结合前一篇“识别问题”,一旦确定了问题的主体,那么系统的利益相关人(用现代管理学语言叫:stockholder)就确定了下来。所发现的问题,会有几种情况:

  1. 某个或者某些利益相关人负载太重。

    时间上的负载太重。

    空间上的负载太重,本质上还是时间上的负载太重。

  2. 某个或者某些利益相关人的权利和义务不对等。

总结:

架构的切分的导火索是人的负载太重。

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

架构切分的最终结果都会体现在组织架构上,只有这样才能够让架构落地并推进。

架构切分的结果一定是一个树状,这也是为什么会产生分层。层数越多沟通越多,效率越低,分层要越少越好。尽可能变成一颗平衡树,才能让整个系统的效率最大化。

什么是软件?

软件的历史,实际上可以说是用机器模拟人的历史。不管大家(包括在这个历史过程中的参与者)有没有意识到,我们都有意无意的在计算机上模仿人类的行为。从冯诺依曼结构开始,程序逻辑开始脱离硬件,采用二进制编码。加上存储,配合输入输出,一个简化的大脑就出现了。

软硬件两者一结合,一个可编程的大脑出现了,这也是现在为什么我们把计算机叫做电脑。在硬件上编写出的程序,就是软件,是用来控制硬件的行为的。

人们越来越愿意把原来只有人才能做的事情,交给计算机来做。结果就导致软件越来越丰富,能够做的事情也越来越多,成本也越来越低。

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

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

所以,软件的本质,其实就是通过把人类的日常工作生活虚拟化,减少成本,提升单个人员的生产力,提升人类自己的利益

软件架构要解决什么问题?

如前所述,软件实际上就是把现实生活模拟到计算机中,并且软件是需要在计算机的硬件中运行起来的。要做到这一点需要解决两个问题:

一、业务问题

具体的现实生活状态下,没有软件的时候,所解决的问题的主体是谁,解决的是什么问题,是如何解决,如何运作的?

二、计算机问题

  1. 如何把现实生活用软件来模拟?

  2. 模拟出来的软件,需要哪些硬件设施才能够满足要求? 并且当访问量越来越大的时候,软件能否支持硬件慢慢长大,性能线性扩展?

  3. 因为硬件是可能会失效的,软件如何在硬件失效的情况下,仍然能够保证可用性,让用户能够不中断的访问软件提供的服务?

  4. 怎么收集软件产生的数据,为下一阶段的工作提供依据?

究竟哪些算是软件架构呢?

软件因为流量增大而分拆成不同的运行单元,在不同的机器上部署所形成的架构,属于软件架构。每个运行单元为了让不同角色的人,比如前端,业务,数据存储等能够并行工作,所分成的代码架构,也属于软件架构。

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

另外很多人讲,架构是进化出来的。架构实际上是在量不断的增大,超过了单台服务器的容量,逐渐的分拆,同时导致超过单个人员的能力,工作人员不断的增多,工作内容不断的分拆形成的。这本身就是架构的意义所在。不管怎么分拆,所达到的目标没有任何变化,就是完成业务在计算机中的虚拟化。

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

架构师是要去平衡别人的利益,甚至会调整别人的利益的。一旦架构师是全心全意的为别人的利益服务,自然而然的架构师就拥有了强有力的影响力,肯定会是一个 leader。但是只是民意上的 leader 是没有用的,不能完全发挥架构师的能量。

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

架构师只能够通过建立某些流程来行使架构师的权利,比如强制架构 review,反而会造成很多内部不必要的冲突,最终都会导致这些流程流于形式,得不偿失。相信很多人都已经经历过这些,但似乎很少有人会去探讨这是为什么。

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

这样这个组织就会具备更好的抗压能力,能够更好的为这个组织的客户服务,这个组织的成员内心一定都是比较平衡的,每个人的能力都能够得到比较好的发展。当然读者可能又会说,这不是管理学的东西吗? 是的,但也是架构的问题。

所有架构的核心就是组织架构。或者也可以这样说,一个合格的组织领导人,一定必须是一个合格的架构师。

架构师和技术?

很多人会问,特别是做软件行业的,架构师是不是需要学习技术,甚至是学习语言? 如果一个架构师还有这个困扰—就如问这个问题的人,说明目前还不具备做架构师的能力,或者说还不具备对自己领域 -- 哪怕是技术领域 -- 的自信,更别谈业务领域了。

因为技术和语言,都是用来识别和解决所服务的主体的权责,保护并提升所服务的主体的权利的。特别对于软件领域来说,必须明白软件本身是怎么回事,解决什么问题,还要解决软件所服务的对象的领域本身是怎么回事,解决什么问题,这就要求更高了。

语言和技术应该是随手拈来才对,对于架构师这些都是工具。学习技术和语言,如果明白了这些技术和语言要解决的是谁的问题,什么问题,学起来是非常快,非常容易的。

同样,采用哪个技术或者语言,只要某个技术或语言所解决的问题的主体,以及所解决的问题,和自己所面对的问题的主体和这个主体要解决的问题,这两者是匹配的,那么这个方案是成本是最低的,所采用的技术或者语言就是靠谱的。

没有趁手的工具或语言的情况下,自己设计一个也不难,因为很清楚自己要什么。要不要自己做,无非是一个成本问题,也就是利益问题。并且从这个思路下去,选择的工具和语言肯定都是最简单的,成本是最低的。因为架构毕竟解决的还是人的利益问题,成本越低越好,这个成本当然是长期总体成本,不是眼前的短期成本。

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

我们经常会听说,重写代码,推翻原有架构,重新设计等等说法,来说明架构的进化。这实际上就是当初为了完成任务,没有充分思考所带来的后果。这也并不是架构进化的事情,而是个人对问题领域的逐渐深入理解的过程。所以有必要再讨论一下,代码的架构应该是怎样的。

软件实际上是对现实生活的模拟,虚拟化。这是一个非常重要的前提,直接决定了我们的代码应该分为几部分。结合每个部署单元所承担的责任,可以明确的拆分为两个不同的责任:

  1. 表达业务逻辑的代码。很多人把这部分叫做 Domain Logic,或者叫 Domain Model。这部分实际是来源于生活的,必须保持和现实生活中的切分一致,并非人为的抽象而成。

  2. 对用户提供访问并保存业务逻辑运行结果的代码。计算机的状态保存有一个缺陷,本机保留业务运行结果有很大的问题,一般都在外存储设备上保存,也便于扩展。

我们真正想快速的完成代码工作,就要克服自己对时间的恐惧,真正的去研究业务的问题,相关 stakeholder 的利益,把这个变成我们的习惯。写代码的时候让该出现逻辑的地方出现逻辑,让不该出现的地方不能出现。一旦不该出现的地方出现了逻辑,那么要马上意识到,这个地方是一个坑,这个问题一定和业务的分析不透彻有关系。

更多相关内容,可参考本文:从架构的角度看如何写好代码?

理清技术、业务和架构的关系

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

学会的技术的多少,所带来的差别只是自己解决问题的手段多了罢了。但是手段多了就一定是好事吗? 很多时候,学习的技术越多,越不知道采用哪种技术好,所谓“乱花渐欲迷人眼"。

还有另一种很普遍的观点:技术人普遍看不起业务,认为技术更高端,而业务太低端,并且业务往往喜欢给技术挖坑。业务则觉得技术眼光高,但是实际解决不了问题,总是理解有偏差,但是又无可奈何,因为自己不会。

技术与架构,以及与业务之间的关系

技术总是在人类解决对业务的要求不断提高的情况下产生,目的也是为了获取更大更好的利益。所以:

  • 技术是为了解决业务的问题而产生的,没有了业务,技术就没有了存在的前提。

  • 有了更好的技术,效率更差的技术,就会慢慢的被淘汰,消失,一切都遵从人类的利益诉求——也就是业务。有人会问,不用钻木取火了,但是弓弦加速转动木棍还可以用啊? 没错,因为弓弦转动木棍这个技术,不是来生火的,是用来加速木棍转动的,所解决的问题不一样。但是两种不同的技术,合理结合起来,会更好更有效率的解决业务问题。

所以技术与技术之间,有两种关系:

  • 在解决同一个业务问题的前提下,更高效,更低成本的技术,会淘汰低效,高成本的技术。这是人类利益诉求所决定的。

  • 一般刚开始解决根本问题的技术(钻木取火)的效率是比较低的,只是把不可能变成了可能(从这一点上来说,技术才是业务的 enabler)。然后就会有提高效率的需求出现,要求改进这个技术。这个技术的低效率部分就会被其他人(或者技术发明人自己)加以改进,这部分就会形成新的技术。

技术人员和业务人员的关系

技术人员很多时候关心的技术,和业务的主要目标往往不是直接对应的,业务也是负责某一部分的业务,也不是和业务的主要目标直接对应的,都是树的分支节点(上文已经解释了为何会发生这种情况)。只有直接解决业务问题的那个技术(或业务)-- 树的根节点 -- 会和业务直接相关。所以一旦产生冲突,一般必须两个根节点(一般都是领导)碰面才能解决问题。

在软件行业,这个根节点技术就是软件。这也是为什么架构师要认识什么叫软件,软件解决谁的问题,什么问题,软件本身又是怎么分拆的,才能够更好的组合不同的技术,完成业务的目标。而软件里面和业务直接相关的,只有 Business Domain 这一部分。

用人来打比方,Business Domain 相当于人的大脑,而 Service,Repository,Glue Code 等部分所采用的技术,全部都是计算机自己领域的技术,都是为了能够让程序跑起来,相当于人的四肢。我们大部分开发人员的工作主要专注于四肢部分。

很多架构师、技术人员主要专注于计算机相关的技术,忽略了业务本身,甚至看不起业务,这也是为什么技术总是和业务冲突的原因。

架构师应该承担起解决业务问题的这个角色来,专注于 Business Domain 和软件本身的架构,让技术人员致力于为业务在计算机中跑起来而努力。只有把这两者很好的结合起来,才能更好地完成业务的目标,才会让软件更好地服务于大家。最终一定会得到一个很好的软件架构,令软件开发团队和业务部门都能够很好地开展工作并降低成本。

只有把这两者很好的结合起来,才能更好地完成业务的目标,才会让软件更好地服务于大家。最终一定会得到一个很好的软件架构,令软件开发团队和业务部门都能够很好地开展工作并降低成本。

《聊聊架构》修订版现货新鲜上架,

京东物流急速发货! 


 
InfoQ 更多文章 技术漫谈:为何KPI毁了索尼,而OKR却成就了谷歌? 覃超:从湘西到Facebook,硅谷只是技术人生的一小站 据说培养这些软技能,可以有效提升程序员的幸福感! 这二十个问题,可能是你技术人生中已经或即将遭遇的痛点,怎么解? 架构师不是你想的那样!
猜您喜欢 Java开发者易犯错误Top10 MongoDB 初见指南 近距离接触英伟达专业级显卡Quadro系列,都能干点啥? 5G网络2020年有望商用,最先体验到的或是亚洲国家 深入骨髓的极客精神