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

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

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

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

1.  

首先，咱们要确认什么是软件

软件的历史，实际上能够说是用机器模拟人的历史。无论你们（包括在这个历史过程当中的参与者）有没有意识到，咱们都有意无心的在计算机上模仿人类的行为。

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

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

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

软件架构为什么出现

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

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

以上经过简单的描述计算机和软件的发展历史，阐明软件的本质，其实就是经过把人类的平常工做生活虚拟化，减小成本，提高单我的员的生产力，提高人类本身的利益。软件工程师的职责在这个浪潮中，不堪重负，天然而然就分拆为不一样的角色，造成了一个独特的架构体系。这一切的背后，仍然是为了提高人类本身的利益，解决人类本身的问题。

1.  

而后，确认软件架构解决的核心问题

如前所述，软件实际上就是把现实生活模拟到计算机中，而且软件是须要在计算机的硬件中运行起来的。在这个过程当中，要作到这一点须要解决两个问题：

1. 业务问题

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

2. 计算机问题

   （1）如何把现实生活用软件来模拟？

   （2）模拟出来的软件，须要哪些硬件设施才可以知足要求？ 而且当访问量愈来愈大的时候，软件可否支持硬件慢慢长大，性能线性扩展？

   （3）由于硬件是可能会失效的，软件如何在硬件失效的状况下，仍然可以保证可用性，让用户可以不中断的访问软件提供的服务？

   （4）怎么收集软件产生的数据，为下一阶段的工做提供依据？

1.  

而后，明确上面两个核心问题主体

1. 业务owner的问题，须要提高业务的效率，下降业务的成本，这是动机，因此通常软件开发的出发点就在这里。
2. 软件工程师的问题，要解决业务owner把业务虚拟化的问题，而且要解决软件开发和运营的生命周期的问题。

1.  

而后，明确分解上面两个核心问题

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

2. 为了可以让软件很好的跑起来，软件工程师必须理解业务所服务的对象，他们的利益所在，即业务问题。业务面对这些问题是如何分拆解决的？ 涉及到了哪些概念？ 这些概念分别解决了哪些哪些问题？咱们不能本身按照本身的理解，用本身的一套概念体系来表述。若是这么作的话，会致使两个问题：

   业务没法和咱们交流，由于他们没法明白咱们所本身建立的概念，因此他们没法确认咱们的理解是否正确。

   咱们所表述的东西，并无在实际生活中实践过，咱们也不知道这些概念是否可以解决业务的问题。

3. 软件工程师还必需要考虑，用什么样的硬件把软件跑起来，怎样跑得好，跑得快，而且能够随着业务的流量逐渐的长大？

1.  

分析解决分解后的问题

对于2，在有限的时间下，软件工程师毫无疑问没法一我的去完成这么多事情，那么咱们须要把所作的事情列出来，进行分析：

1. 虚拟化业务须要完成这些事情：

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

2. 代码如何运营，须要完成这些事情：

   1. 须要多少硬件设备来知足访问的需求？
   2. 代码要分红多少个组件部署到哪些硬件设备上？
   3. 这些代码如何经过硬件设备互相链接在一块儿？
   4. 当业务流量增大到超过一台机器的容量时，软件可否支持经过部署到新增机器上的方式，扩大对业务的支撑？
   5. 当某台或某些硬件设备失效时，软件是否仍然可以不影响用户的访问。
   6. 软件运行产生的数据，可否支持提取出来并加以分析，为下一轮的业务决策提供依据。

3. 若是分红不一样的角色来完成这些事情，就须要一个组织架构来组织代码的编写和运营，须要作哪些事情：

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

1.  

最终，生成哪些架构

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

一样就会须要愈来愈多的人来完成拆分出来的愈来愈多的部署单元，甚至同一个部署单元也须要分拆为多人合做完成。可是咱们须要注意到一点，整个的概念体系，或者说业务的建模不会有任何的变化，仍是完成一样的这些事情。惟一的区别就是量愈来愈大，超过了单我的和单个机器的容量，不断地增加。这样就会致使如下的架构：

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

1.  

再谈，何为软件架构

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

1. 软件由于流量增大而分拆成不一样的运行单元，在不一样的机器上部署所造成的架构，属于软件架构。【部署架构】
2. 每一个运行单元为了让不一样角色的人，好比前端，业务，数据存储等可以并行工做，所分红的代码架构，也属于软件架构。【代码架构】

因此当咱们说软件架构的时候，咱们必定要讲清楚，究竟说的是部署的架构，仍是代码的架构。软件架构的落地，须要软件的组织架构和流程来保障，离开了这个，软件架构是一句空话。

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

架构实际是为了在量不断的增大，超过了单台服务器的容量，逐渐的分拆，同时致使超过单我的员的能力，工做人员不断的增多，工做内容不断的分拆的状况下，仍然可以良好地支撑业务流程高效运转。这自己就是架构的意义所在。无论怎么分拆，所达到的目标没有任何变化，就是完成业务在计算机中的虚拟化。

做者：猿码道 连接：https://juejin.im/post/5b3710d5e51d455f7762cd28 来源：掘金 著做权归做者全部。商业转载请联系做者得到受权，非商业转载请注明出处。