聊聊架构【笔记】

一、生命周期

一个事物一旦出生，就必然会长大，变异，一旦长大，就面临着衰老，接下来就是消亡了，这个过程就称为一个事件的生命周期，实际上就是指的生灭

每一个活动都是一个生命周期，生命周期中包含生命周期，一个生命周期消亡会产生另一个生命周期

生命周期里包含有各种活动，这些活动是推进这个生命周期的必要因素，并且这些活动之间有时间上的推进关系

生命周期总是有一个主体，因此更多的是明确指出某某的生命周期，所以识别出生命周期的主体是至关重要的事情

一个生命周期里面的活动可以进行拆分，拆分的原则就是形成若干个新的生命周期，每个新的生命周期都有自己的主体，拆分之后主体不变的子生命周期，称为核心生命周期，主体改变的称为非核心生命周期，寻找核心生命周期的过程实际上也就是一个发现内聚的过程

拆分出来的生命周期各自都有自己的边界，不会影响到其他的生命周期，因为各自的变化都在自己的生命周期内确定。每个主体的生命周期活动的变化都累积在该主体本身，这就是内聚。要做到内聚，必然要先确定生命周期的主体和生命周期本身

空间上连续的限制可以通过生命周期拆分来打破，形成空间上并行和时间上串行执行的状况

非核心生命周期的管理和执行、核心生命周期的管理和执行可以在时间和空间上并行，但执行仍然还是要依照拆分之前的大生命周期的顺序

从生命周期内部来看，生命周期的每个阶段是随着时间的推进而发生变化的，因此呈现出来的是一个按时间顺序发展的状况，当启动一个核心子生命周期的时候，必须把树上该节点的所有父生命周期启动才可以，也就是所谓的业务流程，因为大生命周期本身内部活动还是按照时间顺序连续发生的

非核心子生命周期处于一种服务的状态，要按需给出结果，执行时间足够短的可以在请求的时候实时执行，太长的则需要预先执行好，需要时直接给出结果。非核心子生命周期拆分出来成为服务后，这个服务不再仅仅给一个人用，而变成了所有人都能够共享，不在局限于原有的大生命周期，而大核心生命周期则变得更加精简，可以专注于自己的核心生命周期活动

二、时间

生命周期的变化体现的就是时间，而时间只不过是人们对事物变化的一个度量

在同样的时间内创造出更多的产出，相当于把自己的生命延长了，尽量做自己擅长的事情 ，以期获得最大的产出

三、为什么会产生架构

除了那些别人无法替代必须要由自己来完成的核心生命周期活动外，把其他的生命周期活动并行起来，在同样多的时间内做更多的事情，也相当于延长了自己的生命

原来需要一个人完成所有事情，生命周期被细分为很多小的非核心生命周期，这些小的非核心生命周期，就可以由另外一个人来负责，在空间上和时间上都得以并行，原来那个人只需要获得另一个人的结果就可以了

四、什么是架构

架构产生的动力：必须由人执行的工作、每个人的时间有限、对目标系统有更高的要求、目标系统的复杂性使得单个人完成这个系统时会受限于时间

架构的思考来源于对生命周期的识别，以及对生命周期的拆分，如果没有生命周期拆分的思考，就不能算架构

建筑架构按照人类生命周期的需求，对地球上的空间进行切分，并通过门窗、地基等技术，保持和地球以及空间的有机的沟通

什么是架构：

根据要解决的人类的问题，对目标系统的边界进行界定

围绕目标系统核心生命周期进行切分，切分的原则是要让非核心生命周期独立出来，便于不同的角色并行地开展工作

对这些切分出来的部分，确立各自的生命周期及其主体，以及负责的角色

在这些拆分出来的非核心生命周期和核心生命周期之间设立沟通机制，使得这些非核心生命周期能够围绕核心生命周期，通过树状架构组装起来成为一个整体，共同为核心生命周期做出贡献

人类架构实际上就是指人们根据自己对世界的认识，为解决某个问题，主动地、有目的地去识别问题，并根据核心生命周期进行分解、合并，以解决这个问题的实践活动

人类的架构总是在人类的业务遇到瓶颈的过程中产生，在瓶颈的解决中应用，在业务消亡时，也跟着消亡

架构的生命周期被拆分为两个子生命周期：

架构设计生命周期，研究业务本身的生命周期，根据问题发现瓶颈，进行架构拆分，把非核心生命周期拆分出来

架构实施生命周期（核心），为了把架构的拆分落实到组织架构上，让每一个人能够按照架构的职责拆分，并行工作，执行各自的生命周期

五、架构和树

主干就相当于核心生命周期，决定树的生死。枝叶是非核心生命周期

树状结构特别适合于增长，围绕着核心生命周期，把非核心生命周期剥离，也可以使得核心生命周期更加精简、轻量化，更容易应对周围环境的变化，树干也更容易长得壮实

分层实际上就是架构树拆分的结果，跨层访问就形成了图

不是树状结构，严格来说不算架构，因为并不能保证权责对等，业务会受其阻碍不能顺利长大，甚至导致业务的失败

架构是顺应业务生命周期规律的一种拆分，这个拆分始终是围绕着业务的核心生命周期的，结果也只有一种，就是一颗树，只有权责对待才能够保证参与人能从其自身的工作中获利，才能够保障参与人能够持续不断地推进业务的生命周期

六、概念

人类架构实际上解决的是人的问题，而概念是人互相沟通并认识这个世界的基础，对概念的认识因而变得非常的重要

名相：名字指代的看到的东西就是相，就是事物的相状。相实际上代表的是影像，以及这个影像背后所产生的作用，是人对这个作用的认识，并不是具体的某个东西。而名是用来标识这个影像和作用，用来沟通交流的

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

要做好架构首先必须具备的能力就是要能够正确地认识概念，能够发现概念背后所代表的问题，找出核心生命周期，进而才能够认识目标领域所需要解决的问题

做架构的时候，很多时候都是在一个新的领域解决问题，必须要快速进入并掌握这个领域，才能够真正的解决问题

七、什么是抽象

抽象是“abstract”，是“抽取、摘要”的意思

每个事物本身都有其独特的地方，我们称为事物的个性，要定义一个事物只能用这个事物独特的地方，也就是它的个性，而不是共性，但抽象恰恰主要关注在共性上，要找出事物的个性，就必须要深入分析和理解 这个事物的核心生命周期，核心生物周期明确了，事物的个性也就明确了

不能用抽象来定义一个事物，抽象实际上是一个分类的过程，抽取出事物中抽取人所关心的一些特征，并且不同的人抽取的侧重点是不一样的，甚至完全不同

做架构需要具备识别个性的能力，也就是要有发现独特问题的能力，必须亲自体验业务，感受业务，才可能真正认识业务的个性，真正认识业务所面临的问题，在理解业务个性的基础上，才能够谈共性，否则这个抽象就像是无根之木，局限于个人的主观认识，是很难长大的

八、识别问题

识别问题的能力基本上就决定了架构师的水平

当我们去解决一个问题的时候，一定要克服对时间的焦虑，耐心地先把问题搞清楚，只有真正敢投入思考“是谁的问题”，关心“真正的问题是什么”的工程师，才有可能成为真正的架构师

识别问题的一个最重要的前提就是要搞清楚：是谁的问题，也就是要先明确问题的主体是谁。主体搞清楚了，问题的边界也跟着确定了，再去讨论问题才有意义。

当我们处理问题的时候，如果发现自己正在致力于把自己的工作完成，就要马上警惕起来，因为这样下去会演变成没有主人翁精神（Ownership）的工作态度。在面对概念的时候，也会不求甚解，最终会导致无法真正的正解概念

架构师要解决的基本问题，都是别人的问题，别人的问题解决了，自己的问题才能解决掉：任何找上架构师的问题，绝对都不是真正的问题，发现问题永远比解决问题更加重要

明白了问题的主体，人们才可能真正地认识问题是什么。因为问题的主体是问题的隐含边界，边界不确定下来，问题就是不确定的。常用的方式就是直接面对主体进行访谈，深入到主体的工作生活当中，体验并感受这些问题，识别关键生命周期，进而识别出非关键生命周期

从问题暴露的点，一点点地去溯源查找，一定会找出来究竟是谁的问题，以及是谁的问题

要正正确的认识问题，需要问两个问题：这是谁的问题、有什么问题

九、切分的原则

很多时候问题的产生都是因为沟通的误解，或者主观上有过多不必要的利益诉求导致的

架构师要非常清楚，所有的切分调整，都对相关人的利益进行调整，分工背后的动力来自于每个人寻求自己的利益最大化的冲动

所谓利益，其实就是保障自身的生命周期活动推进的质量。人们需要放弃一些自己不擅长的事情 ，分工的结果让大家都能够得到更多。人们对自己利益的渴望也是推动社会物质发展的原动力

如何提供更好更有质量的服务给这个社会，提供的服务更好更多，就能够换取更多更好的生活必需品，这也是人们在人类社会生存、立足、做人的基本道理和原则：先要付出才能够有收获

当人们认识到要主动地去切分一个系统的时候，就不能忘掉利益这个原动力，所有的切分决策都不能够违背这一点

利益相关人负载太重是导致切分的原因，权责不对等是切分不合理而导致的新问题，对于负载太重的问题，本质都是时间上的负载过重，有限的时间内无法得到期望的产出。只有把该利益相关人在时间上连续的动作，切分成时间或空间上可以并行的动作，在时间或空间上横向扩展，让更多的人并行工作来提升产出

架构切分的原则：

被切分的生命周期，如果必须要生命周期的主体在连续时间内持续执行，而且不能够被打断并更换生命周期主体的话，就不能切分出去

每个生命周期的负责人，对所有负责生命周期的权力和义务必须是对等的，权责不对等最终会导致架构无法落地，甚至导致业务失败

切分出来的生命周期，不应该超出一个自然人的负载

切分是内部活动，内部无论怎么切，对整个系统的外部都应该是透明的，如果因为切分导致整个系统解决的问题发生了变化 ，那么这个变化就不属于架构 的活动

所有的架构拆分都应该形成树状的结果，不应该变成有向衅，更不应该是无向图

权责不对等的情况一旦出现 ，架构师必须马上意识到，这个问题持续时间越长，企业的动作效率就会受到越大的影响，对利益相关人的利益是非常不利的，同样对于企业的利益也是不利的

树的层次越深，沟通损失就越大，效率也就越低，平衡树的深度可以做到比较均衡

架构的切分过程就是建模的过程，核心生命周期模型把所有的模型通过树组织起来，形成一个新的模型

架构的输出实际上就是一个系统的模型，一棵以业务生命周期为树干的树，要识别出有多少个相关方，每个相关方需要承担哪些权力和义务，不同的相关方是以什么方式组合起来完成整个系统

在进行架构切分的时候，往往也是组织在长大的时候

总结：

架构的拆分的导火索是人的负载太重，也就是时间不够

架构的切分实际就是对利益相关人的利益进行切分或合并，使得每个利益相关人的权责对待，每个利益相关人可以为自己的利益负责

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

架构切分的结果一定是一个树状，这也是为什么会产生分层 ，尽可能变成一棵平衡树，才能让整个系统的效率最大化

十、架构与流程

流程就是多个角色为了把一件事情做好，按时间顺序协作并完成的整个过程，包含了很多的活动，很多的判断，很多的分支，本质上也是一个生命周期

流程关注的是多个人如何把同一个目标完成，是描述整个事物发展各种可能性的树

对业务流程梳理是非常重要的事，往往就代表了业务的核心。不要被树枝、树叶迷惑，树干树根才是真正的核心

流程的推动都是和人相关的，流程实际上串联出来的是不同角色协作的过程

生命周期拆分之后，就意味着权力的下放，因此往往会产生审批的流程

核心是业务生命周期，业务为了长大，发生了架构拆分，形成了一颗树，而流程则把拆分之后的业务进行组合，通过遍历树，重新形成了业务生命周期整体

十一、什么是架构师

架构的目的就是为了增长

架构师会把需要增长的业务了解清楚，挖掘出核心生命周期，并确定核心生命周期的主体，就是要发现问题的主体，并确定核心问题，还需要对业务核心生命周期进行分析，剥离出非核心生命周期，并根据当前人员的状况，合理地分配非核心生命周期的权责

还需要更进一步，那就是根据对不同的生命周期的运营情况，对未来的增长做一定的预判，提前做好规划，做相应人员、技术的储备——这就是战略架构

任何一个人，只要他在思考如何做得更好，如何做得更多，必然会导致他去思考核心生命周期，那么他已经在做架构的思考了

做架构师，必须要具备调动资源的能力，只能具备权力落地的人才能叫架构师，架构师本质上就是权力的代名词。

架构师要把增长放在自己的第一考虑要素，把识别核心生命周期及其主体作为第一思考，这样才能确保权力的合理分配，保证增长的效率。必须深入到业务的核心领域，亲身体会业务的痛点，业务的个性，这样才能够挖掘出业务的核心生命周期，才能够做好拆分

十二、什么是软件

软件实际上是人类有意无意地在计算机上模仿自己这种原始动机的体现，让人们能够节省大量的工作时间，有更充足的时间去关注并推进自身的核心生命周期

邱奇—图灵论题：一切直觉上能靠可计算的函数都可用图灵机计算，反之亦然

成本是我们为什么采用计算机和软件的主要动力，它可以帮助人们节省大量的人员培训，减少雇员的数目，使得人们脱离重复的劳动

我们常说软件或技术（软件当然也是一种技术）是业务的使能者（Enabler），实际就是把业务的成本从原来很高降到了很低的程度而已，并不是有了什么新的业务。另外，软件也不是降低业务成本的唯一方式

软件的出现让机器的生命周期产生了分工，形成了硬件生产生命周期和软件生产生命周期两种形式

软件的出现，让只有“身体”的机器具备了“大脑”。机器通过更新“大脑”中软件的方式不断地学习，变成了一个“活着”的虚拟“人”。虚拟人的出现，导致人类社会也开始软件化、互联网化

软件模拟出了一个虚拟世界，打破了物理时空的限制，极大地提高了生产力，从而完成更多的生命周期

十三、软件的生命周期

一个软件，因为某个业务虚拟化的需要而产生；后续不断地更新、修改，推动软件逐渐变异、长大；当该软件不再被需要（因业务的变化），或有更多好的软件来替代时，该软件就会被废弃，完成使命而消亡

软件的整个生命周期也会发生切分，从而形成两个子生命周期：软件开发生命周期和软件运行生命周期

软件运行生命周期是核心生命周期，因为软件运行生命周期的主体和大的生命周期一致。从另一个角度来说，人们真正需要的是软件启动后为我们带来的服务，也就是说软件运行生命周期才是人们真正需要软件的地方

非核心生命周期：

软件的开发生命周期：产生可运行的软件，内部还会发生切分，如需求生命周期、代码开发生命周期、测试生命周期等

软件的运行生命周期：核心生命周期，又包含软件的访问生命周期、软件的功能生命周期、软件的监控生命周期

ROI（Return On Investment）在软件开发组织的时候，是否需要创建一个软件，要由大家一起来讨论，认证其必要性，确定代价和所获得价值的对比

从软件运行生命周期角度来说，一个可运行的独立部署单元才算是一个软件

从决定开始生产一个软件，到软件真正地运行起来，会经历一段时间的代码积累，这个过程就是软件开发的生命周期

软件开发过程中所有活动都是为了帮助软件工程师能够把代码写对，把业务虚拟出来，工程师必须要理解日常生活中是怎么完成业务工作的，然后才能在计算机中用代码模拟出来

要想对软件和计算机之外 的行业业务实现模拟，软件工程师还要对该业务所在行业的专业知识进行一定的积累，并要超越听懂和能执行两个阶段，才能够用另外一种语言，也就是计算机语言表达出来，这是一个相当高的要求

因为迭代的存在，软件会产生不同的版本，每个版本的软件都是一个完事的开发生命流程，版本叠加的过程也就是软件不断长大的过程

线上版本的运行是软件生命周期的核心，不管有多少个开发生命周期并行，线上版本都只有一个，必须确保版本上线的顺序发生

十四、什么是软件架构

软件要解决的问题：

业务的问题：需要明确业务的主体，并深入到业务的生命周期变化中，找到业务独特的个性

计算机的问题：在软件开发生命周期中，如何用计算机语言来表达业务的生命周期，明确软件的拆分及软件的内部组织；在软件运行生命周期中，硬件、扩展、保证可用性、收集数据

业务问题的本质是业务所服务对象的利益问题；软件工程师的问题本质就是要用代码将业务模拟出来，形成软件，交给计算机运行

简单地增加软件工程师并不能有效地提高产出，因为业务的生命周期只有一个，对业务的理解并不是简单增加人手就可以解决的。只有老老实实地分析业务的生命周期，通过拆分才能提升并行度。因此需要把软件生命周期中的活动列出来，逐个进行分析

对于软件开发生命周期，也就是软件工程师的核心生命周期，虚拟化业务需要完成：

学习业务知识，认识生命周期，以及生命周期中所涉及的利益相关人的核心利益诉求

通过对业务知识的学习，确定核心生命周期和非核心生命周期，以及这些生命周期的组织方式。对业务进行建模，并把建模结果交给编程语言实现，这就是业务的动作模型，也是虚拟人的组织架构

理解参与业务的利益相关人是如何和业务打交道，并为每个角色的权力和义务进行代码描述并落地实现的

考虑如何把业务运行的结果持久化，并通过合适的手段把持久化后的数据在合适的时间合适的地点加载出来

对于软件运行生命周期，即如何让软件运行起来，需要完成：

需要多少硬件设备来满足访问？

软件要如何拆分部署到哪些硬件设备上？

这些软件如何通过硬件设备连接到一起？

软件能否支持通过部署到新增机器上的方式扩大对业务的支撑？

当硬件失效时，软件是否能够不影响用户的访问？

软件产生的数据，能否支持提取出来并分析

按照软件开发核心生命周期的流程，把不同的非核心生命周期串联起来，使得这些非核心生命周期能够并行开展工作，这就是软件工程。所形成的就是软件开发团队的组织架构

软件架构就是通过对软件生命周期的拆分，在符合业务架构的前提下，以达到软件本身访问增长目的的方式。这个增长需要软件开发的增长，也需要软件运行的增长，由此达到所支撑业务的增长

离开了组织架构，任何软件架构都是纸上谈兵，因为架构的核心生命周期就是架构的执行

业务相当于基因，而架构树状拆分则相当于细胞的分裂

十五、什么是软件架构师

具备架构师头衔的人并不一定是架构师

如果一个人在工作中，只是致力于完成自己的工作，以做好自己的工作为主要目标，那么用自己行业的知识去理解另一个行业，就很容易出现沟通的困境，造成很多理解上的困难

要想成为架构师，则必须超越对时间的恐惧，看清楚要解决问题的主体是业务人员，而不是自己，即需要解决的问题是另一个行业的问题，自己是在帮助业务人员解决问题。工作是否完成由业务人员决定，而不是软件工程师自己。

软件工程时对时间有恐惧和压力，是因为他们把按时完成自己的工作当成了自己的最大利益，人对时间的压力是与生俱来的，并且对业务的不了解也会导致他们没有太大的把握

软件行业通常是以业务的问题是否解决为判断标准，是在解决另一个行业的问题，要求架构师把完成业务的工作当成自己的最大利益，对业务领域理解得越深入，就越知道如何去发现问题，慢慢就成为业务专家了，只有做到这一点才能在业务领域建立自信，成为一个合格的软件架构师

软件架构师需要去拆分生命周期，并要形成组织架构去落实架构执行，而且要平衡别人的利益，甚至去调整别人的利益，必须要具备权力去调整软件的开发生命周期和软件的运行生命周期

架构师的核心在于架构的执行，软件架构师必须是一个组织的领导人，有权力调动这个组织的架构，才能够更好地发挥架构师的作用

软件开发团队的组织领导人其实都是架构师，只是没有这个头衔而已，真正的架构师不一定具备架构师的头衔

人类架构的核心就是组织架构，正确的组织架构才能保证架构的执行

架构师面对技术很冷静，很平等地对待所有的技术，只要场景适合就会采纳，是技术的使用者，将技术当作解决增长问题的手段和工具，而不是被技术束缚住

架构师必须深入地了解不同的技术，知道这些技术的强项和弱点，懂得合适的取舍，不一定是所有技术的专家，没有永远最好的技术，也没有永远最差的技术，而问题总是在不断发生变化 的，对于这一点，架构师要有清醒的认识

架构师拆分生命周期，技术人员实现生命周期

架构师思考技术时更多地考虑技术对生命周期拆分的支撑，以及不同技术实现拆分时落地的成本和收益，以最少的成本达到更高的增长

技术是架构师手中的工具，当没有合适的技术时，架构师会去创造技术，或者催生出新的技术

技术包括软件技术和业务技术

技术人员如果想成为架构师，就必须跳出技术的视角，换一个角度去看技术。要把时间花在研究生命周期规律和业务的增长上，花在选择合适的技术上，而不只是追求新潮的或自己喜欢的技术

十六、业务、架构和技术三者的关系

软件工程师的误区：

架构和技术实际上是等同的，学的技术越多，架构水平越高

看不上业务，觉得业务太平凡、太低调，并且业务人员总是来挖坑

通过人为创造条件，让指定的规律按照人类的意愿发生，这就是技术

所谓业务，就是要解决人类的问题，目的是为了支撑人类自身的生命周期，使人类获得利益

技术总是在人类对业务目标要求不断提高的情况下产生的，其目的是为了获取更大的利益：

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

有了更好的技术后，效率较差的技术，就会慢慢地被淘汰，从而消失，一切都遵从人类的利益诉求

不同技术之间有两种关系：

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

通常刚开始解决核心业务问题的核心技术的效率是比较低的，只是把不可能变成了可能，慢慢就会有提高效率的需求出现，改进技术的要求就会变得很迫切

业务是核心，技术是解决业务问题的工具，而架构是让业务长大的组织方法。架构需要用技术来实现拆分，而技术需要架构来合理组织，以提升效率

产生冲突往往都是因为业务团队和技术团队的组织架构不匹配导致的，只有从组织架构上沟通才能解决，所以说，业务人员和技术人员的组织架构相互匹配、对应十分重要，可以减少大部分的沟通问题

很多架构师、技术人员主要专注于计算机相关的技术，看不上业务，背后的主要原因是对业务恐惧，更愿意专心于自己擅长的软件技术，因而忽略了业务，这也是为什么技术总是和业务相冲突的部分原因

架构师应该承担起解决业务问题的角色，专注于业务和软件本身的架构，通过对软件开发生命周期和软件运行生命周期的拆分，让技术人员合理地分工

是否重新发明轮子？

当技术所要解决的问题和拆分出来要解决的问题完全匹配时，这是最完美的

当技术所提供的能力远远超过需要解决的问题时，往往掌握技术和维护技术就会成为负担

当技术所提供的能力和我们所要解决的问题部分匹配时，要判断是否要采用，最终还是要看成本

开源的仅仅是代码，而代码并非是软件生命周期的核心，软件生命周期的核心是代码的运行生命周期和用户访问生命周期，而不是代码建立生命周期。很少企业会把自己的软件运营体系拿出来说事儿。

要想采用开源技术，就要理解这些开源技术往往都有其特定的使用场景，一般先从理解作者面对的问题入手，也就是从业务入手，分析作者是如何拆分业务生命周期的

十七、软件研发

软件最初的编写人员本身就是业务专家，业务非常精通，然后才学习用软件来提升业务的

编写软件从科学计算中拆分出来，变成了一个能用的服务，成为了一个独立的职业，具有独立的生命周期

软件工程师先学习计算机和软件知识，再学习行业知识，并且软件工程师对行业知识的掌握往往不像研究人员对科学领域所掌握的那样精通

在业务领域，大多是如何把现有的业务在软件中模拟出来的问题，并没有太多高深的数学问题。如何能够高效地把业务用软件表达出来，并能够随着业务的增长，让软件也快速地长大，则变成了一个更重要的问题

软件和业务最终还是要合体的

传统行业的软件虚拟化是对传统行业的颠覆，但是业务本身的规律是不变的。用户访问企业的生命周期从现实空间转到了虚拟空间，长大的方式从以人和空间为主变成了以计算机和软件为主，而计算机和软件长大的成本要远远你玩人的增长，虚拟空间的增长要远远低于真实空间的成本

把企业的业务自动化，把员工从粗糙、重复的工作中解放出来，释放更大的生产力，成为一件必须要做的事情。而软件在业务自动化中扮演了至关重要的角色

软件的开发生命周期基本上都包含：确定业务需求、编码、测试、上线

软件开发生命周期本身就要求前一个阶段完成才能够产生下一个阶段，因而瀑布式的时间推进过程是无法避免的，也不应该避免

软件无法一次性地把所有的业务都模拟出来，必须要分步骤的一个一个阶段做出来，通过用户的反馈，一点点的长大，这就是所谓的迭代。每一个小的迭代都是瀑布式的推进。

迭代的前提是，必须要先确定优先级，而理清楚业务的核心生命周期是最高优先级

软件的开发生命周期要允许犯错，因为软件模拟的是人，人与人合作总是会因为沟通等问题犯错，只要犯的错误能够得到快速地反馈和纠正就不会造成问题。所谓“敏捷”（Agule）核心就在于快速迭代并得到反馈

为了组织好代码，架构师需要去理解业务的核心生命周期以及业务的架构拆分，形成代码的架构；为了组织好软件工程师，需要把软件拆分为组件，或者拆分软件，尽可能的让软件工程师之间并行工作，减少冲突；为了组织好软件工程师，就需要形成软件工程师的组织架构，与软件、组件进行对应，与业务的组织架构对应

把软件开发的核心生命周期精简，把非核心生命周期拆分，用软件来实现自动化，让软件工程师能专注于写代码，提升软件工程师的效率。软件开发业务本身也是软件的一个业务

两种开发模型：

以不信任软件开发工程师为基础，以避免软件开发工程师犯错为核心的开发模型

以信任软件开发工程师为基础，以软件开发工程师为核心的开发模型

软件开发的整个过程，参与其中的所有角色，都应该以软件工程师为核心，帮助软件工程师理解业务，让软件工程师成为业务专家。只有软件工程师成为业务专家，写出来的软件才是靠谱的

软件架构师要学习业务的架构，根据业务特点确定软件开发的核心生命周期，根据业务组织架构确定软件的拆分和架构：

组织软件工程师进行有效的分工，形成软件开发团队的组织架构

减轻软件工程师的负担，要把软件开发过程中的非核心生命周期拆分出来，形成软件开发本身的业务架构，并通过自动化来提升软件工程师的开发效率

软件所面对共有三大业务领域及其所对应的架构：

业务领域，由业务组织架构来推动业务的架构，即业务生命周期的拆分

软件开发业务领域，由软件开发的业务组织架构来推动软件的业务架构，形成的是软件开发模式，不同角色的分工模型

软件运行业务领域，由软件的开发工程师来负责编写代码，形成软件架构，并支撑软件的运行，对不同的软件开发工程师进行分工，形成不同的软件开发工程师组织架构，以支撑不同的软件，与软件的架构相匹配

软件业务组织架构和软件开发组织架构共同组成了软件研发团队，业务特性和软件开发业务的特性同时累积到软件中，形成了软件的架构

软件工程师负责建设，软件架构师负责组织

为了支持软件工程师的工作，软件架构师的主要职责包括：

理解业务组织架构，业务组织架构支撑并推进业务架构，背后的原因是地业务生命周期的拆分

根据业务生命周期的特点和软件开发生命周期的特点，形成了软件开发本身的业务体系，以及对软件开发生命周期的拆分，也就是软件开发的业务架构

根据对业务生命周期的以及软件开发生命周期的拆分，形成了和两者都相匹配的软件开发团队的组织架构

对软件进行架构拆分，匹配业务架构和软件开发的业务架构

十八、软件的架构拆分

软件拆分的原动力实际上是来源于业务本身的拆分所形成的组织架构

软件是为人服务的，是为业务服务的，先有人，有业务，才有软件，这个次序绝不可以颠倒。没有人，软件就推动了模拟的目标，软件也就没有价值了

每个业务部门形成一个软件开发团队，这个软件开发团队为这个部门生成相应的软件，提升该部门的价值和生产力，如果业务部门内部划分为多个子团队，则软件开发团队也应该一样划分相应的内部子团队

软件开发团队的利益来自于对业务部门需求的实现，也就是来源于业务部门对软件开发团队的访问，业务团队对软件开发团队的访问通道也不能够重用，避免不同业务部门的访问互相冲突

从软件团队到人，从人到组件，形成的还是一颗树。软件和组件，组件和组件之间，形成的也是一颗树

软件的利益通过用户的访问来实现，和业务人员的利益保持一致，因为软件模拟的就是业务人员，避免不同的用户访问通道相互影响，因此，软件在访问通道问题上也不能重用

重用访问通道的结果，既损伤用户的利益，也损伤软件的利益，还会损伤软件开发团队和企业的利益

软件架构把软件看成虚拟的人，实际上就是虚拟人的组织架构。架构拆分的原则首先来源于业务自身的组织架构，使得软件架构保持和业务组织架构的匹配关系；其次来源于软件开发团队的组织架构；最后来源于用户的流量对软件本身的冲击

十九、如何写好代码

代码主要由两部分组成：

表达业务生命周期的代码，也叫做业务逻辑（Domain Logic）或业务模型（Domain Model），要和现实生活中业务人员的职责拆分一致，并保持内聚

表达用户访问生命周期的代码，就是业务生命周期对外的访问通道，软件的核心价值通过这部分代码展现出来

内聚，是指某个生命周期的变化是累积在一个生命周期主体上的，而不是分散在不同的主体上，在代码中表示一个生命周期主体，就是指一个对象。要确保一个事物的生命周期是完整的，而不是分裂的。所谓完整，就是指一个生命周期的主体，从生到死之间的整个过程中，所发生的行为和状态是累积在一个主体上的

冯·诺伊曼体系架构，把存储和执行分开，同时把操作也数据化，实际上都是为了模拟人。业务的操作编程，就是属于行为的记忆

要模拟一个完整的人，就需要业务（Business）部分来实现业务的逻辑，完成对业务生命周期的模拟。业务的状态要靠存储（Repository）来存储持久化，相当于现实生活中的文件柜

服务（Service）的作用：

由于计算机和软件没有自己的意志，因此其内部生命周期的变化就要由外部的人来推动，这时需要提供一个访问通道给外部的用户。通道就是只负责调用业务逻辑，但不包含业务逻辑。也就是服务代码中是不包含业务逻辑的。

企业为了接待用户的访问，一定会设一个前台。这个前台就是一个服务

不同的用户访问，也要提供不同的服务，以避免不同的用户之间互相影响，因为服务的重用就是自找麻烦

用户要完成访问业务逻辑生命周期，需要做（三个子生命周期，Service->Glue Code->Business）：

服务首先要把业务的状态从存储中加载

服务调用并组合业务逻辑完成业务的访问（核心）

服务把业务逻辑执行后的状态保存到存储中

黏合代码：业务逻辑属于行为是没有记忆的，而存储属于记忆是没有逻辑的，要把行为和记忆黏合在一起，才能够模拟一个人

采用存储挂在黏合代码上的方式，就可以让黏合代码成为一个完整的虚拟人，虚拟人具备记忆和行为，可以均衡地处理上述两个问题，代码也就划分出了以下几个特性：

服务专注于用户（User）的需求，通过组织黏合代码，也就是虚拟人所提供的生命周期活动完成需求

黏合代码专注于管理业务中对象的生命周期，并且通过存储保存或加载业务中对象的状态，实现对业务虚拟人的模拟

业务专注于实现业务的生命周期活动

存储专注于数据的保存和加载，并让数据和存储设备的存储粒度一一对应

访问逻辑的特点是组合代码，即常见的顺序调用。这种代码里既不会有计算也不会有if else等判断，只有简单的组合代码，用于组合下一层的节点所提供的功能，方便上一层节点的调用

业务逻辑是以业务核心生命周期为主线，切分出的一个树状架构 ，树上的每个节点都有其独有的生命周期，每个节点都有一个独立的概念来表达这个生命周期的特质

业务逻辑不是内聚的就会散落到很多其他地方去，会造成的问题：

如果服务代码中混入了业务逻辑，则服务做了两件或者两件以上的事情：

典型的情况就是两个不同的访问生命周期合并在一个服务中来实现

如果是有计算的逻辑的话，比如受益计算、订单金额计算等，那么这部分应该是业务代码需要完成的，不能交给服务代码来实现

黏合代码里面如果包含业务逻辑的话，也会做两件或者两件以上的事情 ，会和服务代码一样，遇到同样的问题

存储代码里面如果混入了业务逻辑，则会导致业务逻辑进入到存储设备中

存储一旦变成了逻辑计算的主体，绑定数据的逻辑计算就成了一个巨大的限制 ，会导致存储设备无法通过增加机器 的方式横向扩展长大，只能换性能更好的机器纵向扩展（Scale up），而纵向扩展不仅程度有很而且成本也很高

业务逻辑内聚的好处：

由于服务、黏合代码和存储里面的代码都是严格的访问代码，而访问代码的特征就是简单的顺序调用，因此这些代码只要做连通性测试即可，不需要单元测试

由于业务不访问任何计算机设备相关的上下文，不访问任何具体的设备，如数据库、缓存、中间件等，因为其状态是靠黏合代码来填充的，因此这部分代码是非常容易写单元测试的，而且单元测试必须保证100%覆盖

存储如果没有逻辑，则很容易按照存储设备本身的最小访问粒度来完成工作，不需要Join

服务代码、黏合代码和存储代码只有变简单了，才可以让开发人员投入更多时间来研究业务

代码架构需要注意的地方：

不能把业务模型（Business Model）当作数据对象来处理：黏合代码需要把业务模型转换为存储设备的实体（Entity），实体和存储设备里面的存储粒度一一对应；同样业务模型不能拿来用作服务和用户之间的数据交互媒介，只能转换为DTO（Data Transfer Object）来使用

服务代码里不要考虑代码重用：针对不同的角色要提供不同的在服务来服务，确保他们之间的访问生命周期是隔离的，避免互相影响；尽量给不同角色不同的服务，既避免通道重用又降低沟通成本；服务多不是问题，服务的生命周期管理才是问题，服务治理（Service Governance）中心就是来解决这个问题的

业务模型是必须要重用的，因为这是所有用户访问的目标：所有服务代码需要的，就是组合业务模型所代表的业务生命周期，用来完成用户的访问

服务代码、黏合代码和存储代码不能有逻辑，要克服对业务，对时间的恐惧，真正的去研究业务核心生命周期，研究相关利益人的利益，把这个变成日常的习惯。写代码的时候让该出现逻辑的地方出现逻辑，让不该出现逻辑的地方不要出现

软件的拆分必须要和业务的拆分对应起来，此时就可看出业务生命周期分析的好处

二十、单元测试

“单元”（Unit）指的是代码调用的最小单位，实际上指的就是一个功能块（Function）或者方法（Method）

单元测试是一种白盒测试，就是必须要对单元的代码细节很清楚才能做的测试，所以，单元测试的编写和执行都是由软件工程师来做的。

集成测试是黑盒测试，主要是由测试人员根据软件的功能手册来进行测试，需要有专门的测试环境配合。集成测试又分功能测试、回归测试等

服务代码、管理者代码和存储代码都是不需要写单元测试的，单元测试是用来测软件工程师自己写的逻辑，如果代码里面没有逻辑就不需要写单元测试。单元测试代码自身也是简单的顺序执行，并没有逻辑，所以不需要测试。

只要出现了模拟，单元测试就开始失效了！

需要单元测试的代码实际上是开发人员自己写的逻辑，测试逻辑所依赖的环境是否正常不是单元测试的目的。看方法能否用一个main函数直接运行，如果可以的话就是可单元测试的代码，该方法单元的参数，开发人员可以自由模拟，并不需要依赖外部环境

如果代码有逻辑但不可以单元测试的话，就需要改造代码，就是要确保逻辑代码和外部环境相关代码隔离，把代码的执行顺序，也就是单元的执行生命周期做架构的拆分，让逻辑代码单元只依赖于参数，而不是依赖于环境（不用nginx、apache等，直接php就能运行），开发人员可以自由地模拟输入参数做单元测试。环境代码不再包含逻辑，恢复了简单的顺序执行。

只要确保输入参数不包含外部环境的上下文，同时内部代码对外部的调用也不包含对环境上下文的访问，这个方法就是可以单元测试的

写单元测试要先搞清楚两个问题：

要明确的是什么样的代码需要单元测试，要测的是什么——只有自己写的逻辑才需要测，外部环境和别人的代码不需要测

逻辑能否用单元测试来测，自己写的逻辑单元是否可测——如果不可测，说明逻辑和访问代码混合了，必须让自己写的逻辑单元只依赖于输入参数，就变成可测了，能够通过main函数提供输入参数就可以运行起来的逻辑单元都是可测的

测试基本都分为三个步骤：

构建输入参数，并预测该输入所产生的输出

调用要测试的目标方法，获取输出

检测目标方法的输出是否和预期的输入一致（Assert）

二十一、软件架构和面向对象

面向过程（Procedural Oriented），也叫过程式编程（Procedural Programming），会把过程式的代码封装成代码块，也叫功能（Function）或过程（Procedure），通过功能调用（Procedure Call）或者过程调用（Function Call）来组织调用的流程

越靠近硬件，越会使用面向过程的语言来编写，比如操作系统底层、硬件驱动等，因为硬件是天然的顺序执行，必须采用流程式的思维

事物生命周期推进的过程中，生命周期活动的主体是不变的，其生命周期活动的承受者就是该事物本身，这就是权责对等，也就是所谓的“自作自受”，有权力“作”，就要有相同的义务承受“作”的结果。所有的生命周期活动都作用并积累在该事物的本身，这就是面向对象，这一特性也被称为面向对象的“内聚”

面向对象让人们在代码世界中，用对象来描述人类在现实生活中的分工（即生命周期的拆分），并且能够用对象来描述自然界的分工

面向过程反映的是生命周期按时间推进的特质，而面向对象反映的则是事物生命周期活动内聚的特质

过程本身一定是某个主体生命周期中的一个过程，也就是某个对象的一个过程。面向对象的方式表述了事物的内聚，但是面向对象不能离开面向过程的基础，也就是顺序执行。对象的生命周期推进一定是通过一个个过程实现的。所以面向对象的编程语言，代码块还是顺序执行的

大部分时候，业务的变化都是流程的变化，并且都是和用户打交道的部分，也就是用户访问生命周期，所以这一部分的变动最频繁

业务对象是很稳定的，因为分工的变化并不是经常发生，其内存逻辑也是相对很稳定的，值得依赖

继承和多态，更多的是指事物的共性。只有封装和面向对象的内聚有关系。要想真正做到面向对象，就必须要去亲身体验事物的个性，也就是事物本身独特的生命周期，才能够真正地明白对象本身

事物有其共性，也有其自身的个性，或者说特性，最关键的就是其自身的特性

组合实际就是面向过程，组合其他拆分出去的对象来完成自己的生命周期。实际上已经包含了面向过程和面向对象的两个特质，因为组合要使用拆分的对象来完成过程的实现

对象的大小不是对象的分割因素，对象的设置要和现实的生命周期拆分，也就是分工相匹配

架构师要解决对象划分的问题，一定要先对现实生活中的业务有亲身的体验才行。不亲身体验业务生命周期，就无法理解分工，也就是业务的架构拆分，也就无法识别生命周期的主体

对象的创建不是对象本身，而是对象的管理者

二十二、软件架构与设计模式

模式就是在自然界或者人类设计中产生的一种可识别的规律，其重要的特征是重复性和周期性，能够产生模式的一般称为模板（Template）。要想得到模式，往往要结合抽象的思维，通过分析不同事物的共性，去掉差异，提取共同点，从而得到规律

设计模式是把模式的范围缩小限定在设计的范围，可以理解为一种有计划、有目的的活动，针对问题，通过对人或物进行合适的摆放，做出一个解决方案，并且还要考虑实现的成本

设计的共同点：

设计是用来解决人的问题的

设计往往要借助已有的东西为基础，对它们重新进行合适的定位和组合，来达到或满足人的目标

面向对象软件开发中的三类设计模式：

创建型（Creational）：如何生成对象，就是把产生对象的生命周期单独拆分出来

结构型（Structural）：专注于对象的不同组合方式

行为型（Behavioral）：针对对象之间的沟通

设计模式都是把原有对象的访问生命周期拉长，增加了环节，在不修改原有对象的基础之上，添加新的能力或者获得新的自由度

站在原有对象的角度来看，设计模式基本都是组合现有对象的能力，通过对原有对象访问生命周期进行架构拆分，形成一个新的解决方案来解决特定的问题。站在业务的角度，人们创造一个事物的过程总是先建设好事物本身，再考虑如何更好地把业务和用户连接起来

设计模式所以要解决的问题和原有对象所要解决的问题并不相同。站在组合的角度，设计模式是集合现有对象的能力，针对要解决的问题，通过某种方式的组合来形成问题的解决方案。“可重用”（Reusable），即尽可能利用现有对象的能力，通过某种形式的组合，形成新的对象和能力提供给外部

设计模式内部的分工其实是在模拟现实生活的分工。并且设计模式内部的分工往往更加的抽象，是更简化的方式，而现实生活往往更加复杂，只有去除了具体问题的独特性，才能让设计模式更普遍地重复使用

软件设计模式本身就是一个架构拆分的结果，只是这个拆分被标准化了，可以被重复使用而已。而设计模式在被使用的时候，则不需要再进行设计，直接使用即可。因此设计模式就变成了一个成熟的技巧或者技术了。

软件设计模式这部分的代码其实是有自己的业务领域的，这个领域就是软件的访问生命周期

只有从访问代码中剥离了所服务业务的逻辑，才有可能讨论软件访问生命周期自身的业务模型。后续软件访问生命周期部分，会展开对这个业务领域的进一步讨论

一个模式重复周期性的出现，是外在的表现，这些类似的现象是人们对共性抽象的结果。但是一些模式外在的表现一样，并不代表它们背后产生的原理也不一样，解决的问题也不一样；同样一个问题表现出来的模式可能并不一样；

毕竟模式只是关注到了共性，共性只会让解决问题变得更容易、更轻松，因为别人解决过了，有参考，但无法解决真正的问题。而真正要解决问题则是要发现问题的个性，发现了个性，共性才能发挥更大的作用。

要真正用好设计模式，就要和使用技术一样，不但要理解设计模式能解决的问题，还要深刻地理解自己要解决的问题

什么代码都考虑重用也是一个误区，业务对象应该被重用，但是对于服务、黏合代码和存储而言，它们都有自己独特的业务问题，即它们处理访问通道的，目的并不是给大家共享，也不是访问的目标，而处理好通道，则需要按照不同角色的用户来进行分析，提供不同的通道，让它们之间的访问互不影响。访问通道是不能重用的。

二十三、软件架构和软件框架

业务呈现给客户，并让用户能够独立访问，形成软件，会遇到两大问题：

如何把业务用软件表达出来

软件如何被放入计算机，提供给用户访问

计算机软件内部所模拟的生命周期变化 ，都是要由外部被模拟的人通过个人意志来推动。而在推动的过程中，通常会有下面这些问题：

提供给用户什么样的访问界面？

用户访问时，如何和用户进行交互？

用什么方式组织业务逻辑并对外提供访问？

业务逻辑的状态如何从存储（Repository）中存取？

软件以什么方式在计算机中运行起来？

针对用户的访问问题，设计模式的典型作用就是把用户的访问和最终的存储连接起来，形成访问通道，为用户访问业务逻辑提供便利

模式都有一些典型特点：对用户访问输入端会提供访问的方式，并且这些访问点可以横向扩张；对通道下一节点访问的输出端也会横向扩张，而其本身则是实现这个设计模式背后的业务。经常修改的部分，往往是输入输出部分的扩张，比如添加功能或者新的访问点

MVC框架，对控制器（Controller）进行了封装，作为其自身的核心业务，对用户不可见，即变成透明的。模型更多的是指对视图的数据支持，一般用DTO来表达。而业务模型关注的是业务生命周期及其行为，业务模型的内部数据只是这些行为的结果，两者不同，但可以通过数据转换结合来连接沟通使用，需要类似于适配器（Adapter）的模式来解决这个问题

所有通道型的框架，背后都有控制器的特质，以方便前后端接入点的扩展；也会有数据转换的要求，以方便前后端数据的传递

行业类框架，是为了给整个行业提供解决方案，既要考虑整个行业的业务模式，还需要适应行业内不同企业的区别，因而往往会形成一个行业的框架

框架基本上都是根据业务模型，或设计模式等，把模型中稳定的部分进行封装，形成一个大的边界，但是具体内容仍留有余地。往往是为了方便本地定制的，在本地进行改造，和自己的软件结合在一起。

框架和服务的一个区别是：软件引用是本地引用的方式，而服务是用来远程调用的

要想应用个框架，首先需要理解好这个框架所能解决的问题，然后才能理解这个框架本身的业务模型和架构的拆分方式，最终才能把其他人的工作变成自己软件的一部分

二十四、软件运维

软件的运行生命周期所要达到的主要目的，则是为了能够提供给用户持续不断的访问，因此软件运行生命周期的核心是软件访问生命周期。软件的访问生命周期，从软件接收到用户的访问请求开始，执行用户的请求到返回给用户请求的结果为止。

软件运维其实就是指软件的运行和维护。运维工程师本质上也是一个软件工程师，只不过专注的领域就是计算机软件本身的运营和维护，一旦运维软件变得很成熟，软件工程师就可以替代软件运维工程师的工作，这个角色也会逐渐地回归到业务的软件工程师，发生树的节点的合并。这就是所谓的自动化。

运维的业务目标是保证用户的访问生命周期不受影响。也就是保证软件稳定地被用户访问是运维的主要业务目标。保持软件的运行稳定，就要求运维能够感知软件的运行状态，能够探测软件的状态是否超出边界，并对之进行处理，使软件尽快恢复正常

“虚拟人”需要依赖电力、网络和硬件等，这些设施本身也会遇到问题，运维系统就相当于“虚拟人”身上的免疫系统，软件工程师就相当于“虚拟人”的医生

运维的生命周期是从软件部署开始的。任何对软件的改变，都是风险，都是需要运维关注的。每次变化的风险控制是最重要的任务。

隔离，避免软件出现在不安全的地方，可以控制所有对软件的改变，对软件所依赖的硬件、网络和电力也是同样的，只有设立隔离区才能保证软件的安全。要区分出办公环境和生产环境（Production）。

生产环境一旦建立，那么生产环境就有了自己的生命周期，其内部就会开始持续不断地发生生命周期变化，这些生命周期变化就是变更。无论是网络上还是物理上，对生产环境上的访问都是变更。分为：被动发生的变更、企业内部主动发起的变更

主动变更所导致的软件系统问题大约占所有线上问题的2/3以上。其中软件本身的变更所千万的问题大约占所有线上问题的一半以上，占主动变更中的绝大部分

线上问题无法完全避免，唯一的办法只能是减少问题产生后带来的损失。减少损失的办法，要么提前预防问题，要么缩短问题所影响的时间，两者都要求运维要具备快速发现并定位问题的能力。要具备这个能力就必须要时刻的感知系统的运行状态，这就是监控（Monitoring）。

监控的目的就是把系统内不同生命周期的当前运行状态，通过探测器传输出来，展示到可视或可感知的设备上，来供人查看。非常重要的指标就是实时度。

理解了软件和业务本身的含义，才能得到软件的数据和指标。理解了这些数据和指标，监控人员就可以对超出正常范围的数据进行报警，马上采取行动，尽可能在问题造成实际损害前就把问题解决掉。这就是运维的预警。

预警分为两部分：

软件本身业务的预警，包括软件、硬件、电力、网络等设备

软件所实现业务的预警，注册量、订单量等等

一旦理解了业务生命周期就会发现，业务的数据会成周期性的变化，而周期性的变化就意味着可以用历史生命周期的数据作为报警的基线

监控是生成预警的数据基础。对业务生命周期的理解则是是生成预警的规则基础。

预警软件本身也是需要监控和预警的，也是预警的业务。

在生产环境做变更，也需要一个正向反馈环，这个正向反馈环核心环节就是监控和预警

变更在生产环境的执行一般称为发布，对变更进行管理的系统叫做发布系统

主导变更的策略主要就是让变更逐步地发生，一般称作“灰度发布”，其核心思想就是尽可用减少变更所影响的范围。软件要支持灰度发布，还要要求软件本身能够支持两个不同版本的代码同时运行在线上，并且保证是对用户透明的，不会影响到用户的访问

把代码发布和功能启用进行架构拆分，先确保代码上线没有问题，再通过软件开关来打开关闭某个功能，功能的打开和关闭就形成了一个新的发布生命周期

生产故障时要优先恢复用户的正常访问，而不是在生产环境探查问题的根本原因。所有的发布都必须要做好回退的方案，一般没有回退计划的发布是不允许执行的

回归（Regression）测试环境，或称为Staging环境，重点就是测试新旧功能是否都能够正常地执行，一般用自动化来完成，因为大部分测试都是原有的功能。

功能测试环境，建立多个，供测试人员做不同版本的新功能测试

开发测试环境，避免开发人员和测试人员工享，避免发生冲突

软件在几个环境中发布的推进管道（Pipeline）：开发测试环境-功能测试环境-回归测试环境-生产环境，所有的变更，包括软件与硬件的变更 ，都沿着这个管道依次的通过，最终到达生产环境

软件运维生命周期的核心是预警生命周期。也就是说，保证软件运行生命周期的稳定是运维的核心工作

二十五、软件访问生命周期

访问（Access）用更通俗的话来说就是使用（或操作）

访问路径：

最初：用户->目标软件->硬件

硬件统一管理：用户->目标软件->操作系统->硬件

网络兴起后：用户->客户端->网络->目标软件->操作系统->硬件

服务端拆分：用户->客户端->网络->目标软件->应用服务器->操作系统->硬件

云服务时期：用户->客户端->网络->目标软件->应用服务器->容器->操作系统->硬件

云服务时期：用户->客户端->网络->目标软件->应用服务器->操作系统->虚拟化->硬件

访问路径上的业务，都是计算机和软件自身的业务，是为降低软件的开发难度而沿着访问生命周期做架构拆分而形成的

计算机和软件自身的业务都可以归结为访问通道型的业务

两种增长模式：

以复制自己的方式增长的，叫做Scale-Out，或者叫做横向扩展

以增大个体能力的方式增长的，叫做Scale-Up，或者叫做纵向扩展

扩张没有最好的方式，选择横向扩张还是纵向扩张都要根据当时社会的技术能力水平来判断。判断标准是对比两种扩张方式的成本和收益，同时也要看业务拥有者本身的扩张意愿

集群就是装有相同软件，具备相同功能的一组计算机，组织在一起共同服务于客户的访问。集群的路由主要考虑的因素是集群内机器的负载均衡问题，路由必须定时检查集群内机器的健康和剩余访问容量

多数据中心（Data Center）可以看成是集群的集群，装有同一个软件的集群会同时部署在多个不同的数据中心，集群在不同的数据中心各复制了一份

数据中心前置路由策略是要把数据中心所覆盖地区的用户访问归属到相应的数据中心，要考虑的实际上是物理空间维度上用户的覆盖面，避免数据中心过小而用户过多，导致数据中心之间的负载不均衡

所谓的系统设计，目的就是为了处理好用户的访问生命周期，必须深刻理解用户的访问生命周期，也要理解访问生命周期是如何推动并形成硬件的拆分和部署以及网络的拆分和部署的

二十六、软件架构和大数据

大数据并非是某一种具体的数据，也并非指数据是否大，而是相对于以前的数据处理方式而言的，是对关系型数据库处理方式的颠覆。其实说的是新的针对大量数据的处理技术，并非“大数据”这个概念表面文字那样是说“数据”本身

要做好大数据，真正的焦点并不在“大”，而在“数据”本身。真正的理解数据，才能够处理好数据，让数据产生价值

有了大数据这个工具，分析业务数据就可以得到不同生命周期的变化过程，得到不同业务决策对用户行为的影响，可以帮助判断不同生命周期的运转是否良好以及整体业务运营是否和预想的一致等，这其实就是业务的监控和预警，或者叫做业务的运营

从另外一个角度看，只要对实时度和数据集大小的要求不高，关系型数据库还是可以很好地完成任务的，理解了业务，一样可以把业务的监控和预警做好，并不一定要采用大数据技术。真正的重点在于理解业务，而不是技术本身。有些场景下，关系型数据库还是有自己的优势的。

用户对软件的访问生命周期体现了业务的访问行为，也同时体现了软件本身的访问行为，因此访问日志（Access Log）可以被用于业务数据分析和软件本身的业务分析。所有的服务器都带有访问日志，不需要额外的开发成本。

当业务需要从大量的软件访问日志中抽取用户的业务行为时，也是典型的大数据应用场景

得到的数据只是一个表象，简单的收集数据并不能解决问题，哪怕采用大数技术也是一样。不理解这些架构的拆分，不理解这些拆分出来的生命周期的积累，是无法理解数据的。因此，架构对于大数据处理至关重要。

软件的大数据分为两部分：

一部分是业务的监控和预警，由业务方来执行

一部分是软件本身的监控和预警，由运维团队来执行

由于业务运营的数据往往来源于运维团队，所以业务的运营少不了运维的支持和参与，也就是说业务的运营会访问运维团队。针对不同的业务业务团队，运维团队内部还要对此进行分工，形成不同的访问通道，避免不同的业务方互相干扰，从而对自己产生不必要的沟通成本

二十七、软件架构和建筑架构

软件架构和建筑架构都是为人服务的，两者在这一点上是一致的，都是为了解决人类自身生命周期的问题，对世界做的一个拆分。并且拆分的结果，都是对人类形成了分工。拆分的目的，也都是为了延长人类的生命周期，提升人类生命周期活动的推进质量。

很多人认为架构就是一个框架或架子的原因就在于，要知道框架和架子的目的仅仅是为了实现架构对空间的切分，属于实施的技术，并非架构本身

软件的目标关注的是把人们所做的事情模拟出来，把人从重复的劳动中解脱出来。世界是周期变化 的，意味着软件一旦把这些周期模拟出来、管理起来，人们只需要按照自己的需要，推动这些生命周期为自己服务即可，不需要亲自去执行这个周期，软件所关心的是人类生命周期的切分，把人类自身执行生命周期活动以外的非核心生命周期用软件来模拟实现，让人可以有更多的时间来算下推进自己的生命周期，提升生命质量

建筑的设计建造往往是由建筑公司来做的，运营可以完全交给物业公司；而软件目前做不到，必须要自己运营；建筑可以出租给其他的用户来使用，软件的出租比较难，只有娱乐软件或标准化的软件相对容易些；

有了软件之后，人的一辈子能够作出更多的创造，达成更多的目标，也相当于延长了人的生命

建筑扩展主要是横向扩展，由一个一个的个体建筑，形成了社区、城市和国家，纵向扩展可以理解为重新装修，改善居住空间

像建筑一样的瀑布式开发并不理想：

一是由于人们对软件的认识还远远达不到对建筑的认识程度

二是建筑的访问增长是可以预测的，而软件则不可预测

软件的优势是建造非常简单的代码，不仅原有的设施可以直接使用，而且每次发布都可以重用以前写好的代码，只需要做增量的修改即可；建筑的模块化程度也远低于软件；

二十八、交易

交易就是人们各自拿自己多余的物品，从其他人手上换取自己必须的物品，从而双方都获得利益的过程

所谓市场，就是指集中发生交易的地方，每个人都可以在市场上卖自己的物品，也可以在市场上寻找自己想买的物品

用单位时间增加的产出去换取另一个人对应时间增加的产出，大家都用比较少的时间得到了更多的回报。因此，慢慢也出现了很多人直接用自己的时间与人交易，得到自己的生活必须品，这就形成了雇佣关系，从而变成了职业

企业通过对生产的生命周期分工，雇佣更多的人，组织他们并行工作，可以得到更大的产能，甚至1+1>2的效果，这就是企业的组织架构

促使用户访问软件的动力，就在于软件的虚拟化极大地减少了人们获得物品的难度，所有获取的信息量更大，因此，要评价一个软件的价值，它的访问量是一个至关重要的衡量标准，因为每一次用户的访问，就相当于该软件所产生的一个交易

交易的背后实际上是人们互相之间时间的交换，而不是货币。货币只是对时间的定价，方便交易的一个工具。对于不同的商业模式，交易都有自己的形态，需要人们识别出来

企业的生命长度可以远远超过一个人的生命长度，所以很多人会把企业当作自己生命的延长来付出。企业要具有比人长的寿命，就要超出个人的诉求，不再为某个个人服务，而是为了一个群体服务，形成了企业的核心诉求和目标，也就是人们常说的企业愿景（Vision）

企业在达成愿景的过程中，其生命周期由一个一个和用户的交易积累而成。交易又由一次一次的访问生命周期积累而成，这就是企业生命周期的动作过程，也是企业生命周期的架构拆分

组织架构的目的就是通过更多人的并行工作，来支撑更多用户的访问生命周期。无论哪种企业，交易的最终实现，都是通过用户的访问来达成的。访问是如何达成的，访问生命周期是如何切分的，则是不同企业的区别之处，也是不同企业愿景的入手点

二十九、产品

交易过程中，人们交换的物品被称为产品（Product），有时也被称为商品（Good）。产品配上主语就是：谁生产的一个东西

人类要访问产品，首先要有一个访问目标，即产品本身，其次还需要一个访问的途径，两者都具备才能够达成对产品的访问

制造类的产品要能够让人类访问，必须要到达人类的感觉范围内。因此必须要建立空间的渠道，经历时间传输到用户的感觉范围内，用户通过自己的感觉器官才能够接触访问到产品

为人类提供对制造类产品访问的空间通道，所形成的便是服务类的产品，也就是通道类的产品

产品更多的是表达生产属性，而商品则更多的是表达交易属性。产品本身不一定能够售卖，但是售卖的东西一定是某个产品，也就是说一定是某个主体所生产的产品

从用户角度看，在达成交易之前 ，用户寻找的是解决自己问题的产品。而在寻找到自己想要的产品之后交易时，用户考虑的则是数量和价格，交易时购买的是商品。在用户使用的时候仍然是产品，也就是产品属性

对于一个企业来说，如果这个企业的领导人对自己企业的愿景不够清晰的话，往往会带来一个严重的问题，就是这个企业的产品往往是模糊的。产品不清晰导致的结果就是：目标人群不清楚，产品体系混乱，进而导致组织架构混乱 ，交易很难增长，企业也会陷入困境

要让用户知道这个产品，就必须要把产品所解决的问题等信息传播出去，使得目标用户能够访问到这些令牌，通过这些令牌吸引用户来访问产品的入口，让用户产生交易的意愿，这就叫做市场营销（Marketing）

产品本身就是最好的营销。产品系统实际上是市场营销的起点，也是交易的起点，也是企业用来实现自己愿景的工具，是愿景的具体化

产品列表（产品目录）要展示的信息，就是把企业的愿景传递给用户，取得用户的认同并购买。把产品列表向目标人群分发，就是产品的营销

商品规则：

从商品本身为出发点的，一般是来提升商品本身的销量。比如优惠价格、评价优惠等

从客户本身为出发点的，一般是用来提升用户的数量，或者提升用户的活跃度。比如新用户优惠等

从支付推广为出发点的，一般是用来提升某个支付方式的使用率。比如啊啊服务号信用卡优惠等

三十、用户

用户，用的是某个主体生产的产品。当某人正在使用某个主体生产的产品时，一般会说此人就是这个产品的用户。用户表达的是产品运行生命周期中所服务的人或人群

客户（Customer），更多的是关注在交易层面，是产品销售的对象，也是交易的对象，目标是为了让产品的客户成为产品的用户

用户这个概念是针对产品生产者，也就是企业而言的，目的是为了把用户处的信息，通过某种方式搜集到企业这里，是企业对其产品使用方建档并跟踪的一个原始数据组织

任何产品都需要用户，因为产品的生产都是为人服务的。用户对于企业是至关重要的，任何企业都是由人推动往前发展的。企业只是人类需求的一个实现形式，因此企业时刻都要以人为本

要让人们成为企业产品的用户，企业必须要把产品卖给客户

用户的产品使用行为记录基本上靠用户主动反馈的产品使用信息，企业有责任帮助用户解决产品访问和使用上的任何问题，这就是产品的运营。用户的信息一直保留在企业处，这是企业非常宝贵的数据，也是下一轮销售生命周期的起点

企业应该投入资源从通道处获取自己产品的访问情况，用来提升自己的产品

三十一、订单

订单，就是指和客户的一次交易的生命周期过程，实际上是所售卖产品的订单，表述的是产品的售卖过程，售卖的东西是产品中的某个商品。订单所代表的就是一次交易的整个生命周期过程，从交易生成开始产生订单，到交易结束为止完成订单

其实复杂的事情一开始都是简单的，简单的东西逐渐地发生拆分就变得越来越复杂了

三十二、交易系统

一个交易是需要两方来形成的，一是卖方，还有一个愿意购买的买方。要两方同时达成一致才能够形成一个交易。

企业愿景的达成依靠企业所生产产品的售卖，通过交易建立起客户独占访问产品的通道，使企业和客户都获得更大的利益，形成双赢的结果

企业的交易生命周期是核心生命周期，企业的生产是为交易服务的

产品访问通道是交易系统能够运作的前提。为了把产品展示给客户，一般就会要求产品的负责人把所有产品整理好，用来供用户查询，这就是产品系统

为了跟踪客户使用产品的问题，还需要把客户的信息和购买行为记录下来，这就形成了客户系统

有了用户的购买行为和联系方式，客户的通道就建立了。利用这个通道就可以在适当的时机推荐合适的产品，或者在客户两次购买的时候，快速的帮助客户选择到更合适的产品，这就是营销推荐系统

一个企业的交易生命周期和订单生命周期是核心生命周期，而产品、用户等生命周期都可以不用自己亲自来做，但订单是非要自己来做不可的

对于架构师和软件工程师来说，如何快速识别模型需要对业务的生命周期进行深入了解，要对业务的特性有足够的认识和体会。对业务系统的建模来源于业务本身生命周期的拆分，即组织架构的拆分。建模实际上就是把人虚拟化，把各业务系统负责人的工作用模型表达出来。模型中的每一个对象，代表的就是现实生活中一个个活生生的人。这个对象的方法，代表的就是这个人所负责的业务生命周期行为

“阻抗不匹配（Impedance dismatch）”，两个东西完全不匹配，放在一起反而会互相干扰造成更大的问题

业务模型完全就是现实社会中已存在的分工，建模的人只需要识别出来就可以，不需要再绞尽脑汁用不同技术抽象出来另外建一个模型来表达业务

软件模拟业务的展现方式总是尽量模拟现实生活，让用户感到是“真实的人”人在服务于自己。软件的一切都是在模拟人的行为

访问通道的另一个非常重要的要求就是，不同类型的用户访问要提供单独的访问通道

很多架构师喜欢做访问通道的重用，往往会导致不相干的另一类用户访问受影响。不重用访问通道的目的是为了重用业务对象。一旦重用访问通道，业务对象中的业务逻辑一定会分散到访问通道中，业务逻辑反而得不到重用了

在计算机软件中，服务的本身是客户端访问服务端的访问通道，是不包含所服务的业务的。一旦软件发生了架构拆分，原来的本地调用就变成了服务调用

服务有自己独立的生命周期，会形成自己独立的业务，不再依赖于原核心生命周期，焕发出新的活力

架构拆分最终都会形成最小粒度的生命周期，粒度有多小取决于业务本身的规律，也取决于当前技术的发展水平

用户系统的核心是为了能够标识用户，让用户能够以独立的身份访问系统，从而软件可以识别并跟踪用户

做架构的拆分不会影响外部，而影响外访问行为的拆分都是业务的破坏，应该叫做结构变化或业务变化

三十三、事务

在英文中，Transaction的含义是交易的意思，指的是物物交换。

在软件中实现交易的时候，一般是通过订单来记录各方的当前状态。交易中过往行为的记录，则是通过操作日志来实现的。操作日志和订单记录结合起来模拟人类大脑的记忆。所谓回滚，也是通过已执行操作的日志记录，按发生顺序反向执行恢复反向操作来进行的。因此，交易日志在软件中是至关重要的。

软件把内部运行中的生命周期状态交换给数据库来保存，而数据库本身获得了生存，有了自己的生命周期，形成了新的存储技术。而为了确保把软件的状态可靠的存储，可靠的获取，就需要一定的机制来保障这个交易，这就是数据库的Transaction技术，也就是所谓的事务，应该就是要达到可靠数据交换的缘故

数据库应该完全和软件所模拟的业务脱离关系，应该恢复到其本身的作用上来，即持久化软件的状态，并且仅仅持久化软件的状态

数据库事务只应该存在于和数据库打交道的存储代码中

假设被调用的两个服务不是在同一个事务中：

第一个服务不成功，说明整个调用操作是失败的，没有影响

两个服务都调用成功，说明整个操作是成功的

一个成功一个失败

调用方收到错误提示后自行

重试每个服务的调用

将第一个服务做反向操作，恢复现场，需要操作日志的帮助，如果不能恢复，则需要人工介入解决，恢复数据

导图：

https://github.com/zhangyue0503/blogfile/tree/master/%E8%81%8A%E8%81%8A%E6%9E%B6%E6%9E%84