【细品架构11/100】架构由术至道的转变(2)

341 阅读13分钟

上一篇文章《架构由术至道的转变(1)》已经从“人”、“组织”、“社会”三个方面讲述了架构的起源,为什么会产生架构,产生架构的动力条件,并分析了如何可以更好的做好架构,比如:概念认知、问题识别、架构切分,这些都是做好架构最核心、最实用的思维手段,相信真正理解了这些道的含义,再到软件行业进行架构实践,会更加的游刃有余。

其实软件行业也是社会的一部分,社会是由人组成的,自然架构最终是解决人的问题。有人的地方,便有了江湖,林子大了啥鸟都有,江湖中也便起了纷争,其实归根结底还是人对自己利益最大化的诉求。不过在此强调下,人对利益最大化的诉求,不是产生架构的必要条件,产生架构必要条件可查看《架构由术至道的转变(1)》

好了,那就让我们来看下,在软件行业中,架构又是为何产生,又是解决人的什么问题,最后再讨论下,软件行业的架构是如何做的。


首先,我们要确认什么是软件

软件的历史,实际上可以说是用机器模拟人的历史。不管大家(包括在这个历史过程中的参与者)有没有意识到,我们都有意无意的在计算机上模仿人类的行为。

人们越来越愿意把原来只有人才能做的事情,交给计算机来做。结果就导致软件越来越丰富,能够做的事情也越来越多,成本也越来越低。可以这么说,成本是我们为什么采用软件的主要动力,可以节省大量的人员培训,减少雇员的数目。随着互联网的发展,人类社会也开始软件化了。

有了软件之后,实际上,我们是把我们日常生活中所做的事情,包括我们自己本人都一起虚拟化到了计算机中。而人则演化成了,通过计算机的输入输出设备,控制计算机中的自己,来完成日常的工作,以及与其他人的沟通。也就是说,软件一直以来的动力,始终都是来模拟人和这个社会的

不管如何发展,模拟人的所有行为都是一个大的趋势。也就是说,软件的主要目的,还是把人类的生活模拟化,提供更低成本,高效率的新的生活。从这个角度来看,软件主要依赖的还是人类的生活知识。软件更多的是扮演一个cost center,这也是为什么会出现很多的软件代工。

软件架构为何出现

软件工程师是实现这个模拟过程的关键人物,他必须先理解人是怎么在日常生活中完成工作的,才能够很好的把这些工作在计算机中模拟出来。可是软件工程师需要学习大量的计算机语言和计算机知识,还需要学习各行各业的专业知识。软件工程师本身的培养就比较难,同时行业知识也要靠时间的积累,这样就远远超出了软件工程师的能力了。所以软件开发就开始有分工了,行业知识和业务的识别,会交给BA,系统的设计会交给架构师,设计的实现交给架构师,实现的检验交给测试,还有很多其他角色的配合。为了组织这些角色的工作,还有项目经理。这就把原来一个人的连续工作,拆分成了不同角色的人的连续配合,演化成了不同的软件开发的模式。然后慢慢演变出专门为别人开发软件的软件公司。

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

以上通过简单的描述计算机和软件的发展历史,阐明软件的本质,其实就是通过把人类的日常工作生活虚拟化,减少成本,提升单个人员的生产力,提升人类自己的利益。软件工程师的职责在这个浪潮中,不堪重负,自然而然就分拆为不同的角色,形成了一个独特的架构体系。这一切的背后,仍然是为了提升人类自己的利益,解决人类自己的问题。


然后,确认软件架构解决的核心问题

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

  1. 业务问题

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

  2. 计算机问题

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

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

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

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


然后,明确上面两个核心问题主体

  1. 业务owner的问题,需要提升业务的效率,降低业务的成本,这是动机,所以一般软件开发的出发点就在这里。
  2. 软件工程师的问题,要解决业务owner把业务虚拟化的问题,并且要解决软件开发和运营的生命周期的问题。

然后,明确分解上面两个核心问题

  1. 业务问题的本质,是业务所服务的对象的利益问题,明白了这个,就很容易搞清业务的概念和组织方式。再次强调一下,有了软件,可以降低业务的成本,没有软件的情况下,业务是一样跑的。如果只是为了跟风要用软件,说不定反而提高了成本,这个是采用软件之前首先要先搞清楚的。我们经常说软件和技术是业务的enabler,实际就是把原来成本很高的降到到了很低的程度而已,并不是有了什么新的业务。另外软件也不是降低业务成本的唯一方式。

  2. 为了能够让软件很好的跑起来,软件工程师必须理解业务所服务的对象,他们的利益所在,即业务问题。业务面对这些问题是如何分拆解决的? 涉及到了哪些概念? 这些概念分别解决了哪些哪些问题?我们不能自己按照自己的理解,用自己的一套概念体系来表述。如果这么做的话,会导致两个问题:

    业务无法和我们交流,因为他们无法明白我们所自己创建的概念,所以他们无法确认我们的理解是否正确。

    我们所表述的东西,并没有在实际生活中实践过,我们也不知道这些概念是否能够解决业务的问题。

  3. 软件工程师还必须要考虑,用什么样的硬件把软件跑起来,怎样跑得好,跑得快,并且可以随着业务的流量逐渐的长大?


分析解决分解后的问题

对于2,在有限的时间下,软件工程师毫无疑问无法一个人去完成这么多事情,那么我们需要把所做的事情列出来,进行分析:

  1. 虚拟化业务需要完成这些事情:

    1. 学习业务知识,认识业务所涉及的stakeholders的核心利益诉求,以及业务是如何分拆满足这些利益诉求,并通过怎样的组织架构完成整个组织的核心利益的,以及业务运作的流程,涉及到哪些概念,有哪些权利和责任等。
    2. 通过对业务知识的学习,针对这些概念所对应的权利和责任以及组织架构,对业务进行建模,把并把建模的结果用编程语言实现。这是业务的模型,通常是现实生活中利益斗争的结果,是非常稳定的。
    3. 学习业务所参与的stakeholder是如何和业务打交道,并完成每个人的权利和义务的,并通过编程语言,结合业务模型实现这些打交道的沟通通道。这部分是变化最频繁的,属于组合关系。明白了这一点,对后续的实现非常有帮助。
    4. 如何把业务运行的结果,持久化,并通过合适的手段把持久化后的数据,在合适的时间合适的地点加载出来。这部分和基础设施有关,变化可能也会比较频繁。
  2. 代码如何运营,需要完成这些事情:

    1. 需要多少硬件设备来满足访问的需求?
    2. 代码要分成多少个组件部署到哪些硬件设备上?
    3. 这些代码如何通过硬件设备互相连接在一起?
    4. 当业务流量增大到超过一台机器的容量时,软件能否支持通过部署到新增机器上的方式,扩大对业务的支撑
    5. 当某台或某些硬件设备失效时,软件是否仍然能够不影响用户的访问。
    6. 软件运行产生的数据,能否支持提取出来并加以分析,为下一轮的业务决策提供依据。
  3. 如果分成不同的角色来完成这些事情,就需要一个组织架构来组织代码的编写和运营,需要做哪些事情:

    1. 完成一和二所列的这些事情,需要哪些角色参与
    2. 这些事情基本都需要顺序的发生,如何保证信息在不同角色的传递过程中不会有损失? 或者说即使有损失,也能快速纠正?
    3. 这些角色之间是如何协调,才能共同完成虚拟化业务的需求?

最终,生成哪些架构

如果业务足够简单,用户流量够小,时间要求也不急迫,那么一个人,一台机器就够了,这个时候一般不会去讨论架构的问题。当访问的流量越来越大,机器就会越来越多,代码的部署单元就会拆分的越来越多。

同样就会需要越来越多的人来完成拆分出来的越来越多的部署单元,甚至同一个部署单元也需要分拆为多人合作完成。但是我们需要注意到一点,整个的概念体系,或者说业务的建模不会有任何的变化,还是完成同样的这些事情。唯一的区别就是量越来越大,超过了单个人和单个机器的容量,不断地增长。这样就会导致以下的架构:

  1. 当流量越来越大,我们就会发现,软件所部署的机器就会开始按照树状的结构开始分拆,就会形成硬件的部署架构。这就是为什么会形成部署的分层。
  2. 为了把业务在软件中实现并落地,需要前端人员、业务代码人员、存储层等不同技巧的人同时工作,需要切分成代码的架构。这就是为什么会形成代码的分层,形成代码的架构。当然,当这些角色由一个人来完成的时候,不一定会有代码架构,往往会比较乱。
  3. 当参与的人员越来越多,就会形成开发体系的组织架构。因为代码开发的过程是一个连续的过程,会用流程来把不同的角色串联起来,这就是软件工程。
  4. 为了完成业务的工作,需要识别出来业务架构和支撑业务的组织架构,以及业务运作的流程。这是被虚拟化的业务架构和组织架构,也需要体现在代码中,保持和现实生活中一致。

再谈,何为软件架构

这就是软件比较复杂的地方,涉及到软件本身的业务体系,和所虚拟的业务体系。根据以上的分析,所生成的架构,究竟那些算是软件架构呢?

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

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

另外很多人讲,架构是进化出来的,但其实架构是设计出来的,架构的好坏体现于在进化过程中支撑业务高效运转的生命周期

架构实际是为了在量不断的增大,超过了单台服务器的容量,逐渐的分拆,同时导致超过单个人员的能力,工作人员不断的增多,工作内容不断的分拆的情况下,仍然能够良好地支撑业务流程高效运转。这本身就是架构的意义所在。不管怎么分拆,所达到的目标没有任何变化,就是完成业务在计算机中的虚拟化。