微信号:infoqchina

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

《聊聊架构》结束前,要不要再听听它的故事?

2018-03-02 08:21 InfoQ
《聊聊架构》近期将从极客商城下架。自去年在极客商城独家销售以来,《聊聊架构》已经陪伴大家 10 个月之久。从第一周销量就突破 3000 本到后续收到无数读者的书评,用户的每一点反馈我们都倍感珍惜。 年后我们又加印了 1000 本,希望这本书最后能给您带来一些收获。

在软件行业,架构师和工程师就类似于上帝,创建出形形色色的软件产品来服务于人类。要想当好这个角色,架构师自然也需要具备某种上帝的视角,来观察并表达这个世界。

《聊聊架构》以作者的架构经验为基础,逐步讨论什么是架构、怎样做好架构、软件架构如何落地、如何写好程序等问题,帮你理清技术、业务和架构之间的关系,洞见架构之道,进阶为更优秀的架构师。

什么是架构?

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

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

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

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

这就是架构。

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

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

比如,什么是“杯子”?杯子这个概念并不是瓷器,回归作用:其实是为了解决“人需要一个可单手持握,但是希望避免直接接触所盛物体”这个问题。

每个概念实际上所解决的,还是人遇到的某个特定的问题,我们把解决问题的解决方案,给定了一个名字,这个名字就是对应的某个特定的概念。

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

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

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

如果把真正的问题找到,那么问题就已经解决了 80% 了。这个能力基本上就决定了架构师的水平。

找出问题的主体,是做架构的首要问题。这也是前面强调的,我们要解决的问题,一定都是人的问题。

更进一步,作为软件工程师或者架构师,我们大部分时候是要去解决别人的问题,“别人”是谁,是值得好好思考的。

再进一步,我们一定要明白,任何找上架构师的问题,绝对都不是真正的问题。为什么呢? 因为如果是真正的问题的话,提问题过来的人肯定都能够自己解决了,不需要找架构师。架构师都要有这个自觉:发现问题永远都比解决问题来的更加重要。

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

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

  1. 这是谁的问题?

  2. 有什么问题?

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

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

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

这个调整就是架构的切分。简单来说:

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

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

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

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

什么是软件?

软件的历史,实际上可以说是用机器模拟人的历史。不管大家有没有意识到,我们都有意无意的在计算机上模仿人类的行为。人们越来越愿意把原来只有人才能做的事情,交给计算机来做。结果就导致软件越来越丰富,能够做的事情也越来越多,成本也越来越低。

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

随着软件的规模的变大,程序从早期由一个人完成,也逐渐变成了由很多不同角色的人共同合作来完成。软件工程师的职责在这个浪潮中,不堪重负,自然而然就分拆为不同的角色,形成了一个独特的架构体系。这一切的背后,仍然是为了提升人类自己的利益,解决人类自己的问题。

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

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

业务问题

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

计算机问题

如何把现实生活用软件来模拟?模拟出来的软件,需要哪些硬件设施才能够满足要求? 并且当访问量越来越大的时候,软件能否支持硬件慢慢长大,性能线性扩展?因为硬件是可能会失效的,软件如何在硬件失效的情况下,仍然能够保证可用性,让用户能够不中断的访问软件提供的服务?怎么收集软件产生的数据,为下一阶段的工作提供依据?

总之,软件架构包括了:代码架构,以及承载代码运行的硬件部署架构。实际上,硬件部署架构最终还是由代码的架构来决定。

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

架构师必须是一个组织的领导人,有权利调动这个组织的架构,才能够更好的发挥架构师的作用,更好的把利益的调整落到实处。

如果架构师只能够通过建立某些流程来行使架构师的权利,比如强制架构 review,反而会造成很多内部不必要的冲突,最终都会导致这些流程流于形式,得不偿失。

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

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

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

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

我们经常会听说,重写代码,推翻原有架构,重新设计等等说法,来说明架构的进化。这实际上就是当初为了完成任务,没有充分思考所带来的后果。

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

这里还有作者分析的案例和图示,请看书细细品味吧。

所以,你理清技术、业务和架构之间的关系了吗?

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

为什么会发生这种冲突呢?

这是因为技术人员很多时候关心的技术,和业务的主要目标往往不是直接对应的;业务也是负责某一部分的业务,也不是和业务的主要目标直接对应的,都是树的分支节点。只有直接解决业务问题的那个技术(或业务)–树的根节点–会和业务直接相关。所以一旦产生冲突,一般必须两个根节点(一般都是领导)碰面才能解决问题,就是这个原因–他们都知道业务主要目标。

这也是为什么下层无法理解上层,而上层都喜欢下军令状,要求下层执行。人只有尽量去理解上层的问题才能做下层的分拆。

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

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

我们大部分开发人员的工作主要专注于四肢部分。我们真正应该投入的是大脑部分。因为大脑能够决定四肢长什么样,而不是反过来。很多架构师、技术人员主要专注于计算机相关的技术,忽略了业务本身,甚至看不起业务,这也是为什么技术总是和业务冲突的原因。

架构师应该承担起解决业务问题的这个角色,专注于 Business Domain 和软件本身的架构,让技术人员致力于为业务在计算机中跑起来而努力。

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


 
InfoQ 更多文章 新的开始,走在技术之路上的你,现在迷茫么? Spring Boot 2.0正式发布,新特性解读 360开源技术大盘点 批处理ETL已死,Kafka才是数据处理的未来? 零基础如何快速搭建一个推荐系统?
猜您喜欢 给新手的最佳类Windows界面的Linux发行版 【补发】十五天精通WCF——第二天 告别烦恼的config配置 Scala:为简单而生长 30本《自己动手设计物联网》签名版接受预定 智能新能源汽车不一样在哪里