1.认识架构

1.1生命周期：

• 万物皆有生命周期

• 生命周期包含各种活动，活动的推进是生命周期的必要因素（对象的行为）

• 生命周期里面的活动拆分后，形成若干新的生命周期

• 拆分后主体不变的是核心生命周期，变化了的是非核心生命周期

• 每个主体的生命周期变化都累积在自身，这个就是所谓的内聚（面向对象分析新思路）

• 生命周期拆分以后，因为非核心生命周期的主体已经发生变化。主体便可以将这些非核心生命周期分配给其他主体代为执行。这样，生命周期从时间连续的执行变成了空间上并行，时间上串行的连续活动。

• 新的技术诞生也会导致某些核心生命周期变为非核心生命周期，例如照相机的发明导致了人看到物体的生命周期发生了主体转变。 
  核心生命周期在拆分后，变成了通用服务，最后演变成了一个个职业。而大生命周期变得更加精简，可以更加专注自己核心生命周期

1.2时间：

• 时间是人们对事物变化的一种度量

• 万物遵循生命周期规律，随时间流逝生生灭灭，不因个人意志所转移。 
  生命无常，虽然每个人个体的生命周期无法按自我意愿进行延长。但是，通过提高自身的能力以获得更多成就，产生对社会更多的贡献，这是另一种层面的生命的延伸

1.3为什么产生架构：

• 推动人类社会架构的产生，本质上是人类对于时间无法控制的恐惧。

• 按特点进行分工以后，生产力得到了提升。相对的人的生命得到了一定的延长。

• 实际上按特长进行分工便形成了人类社会的架构。

• 良好的社会架构和分工使独立的人类节约了为了生存付出的时间。有了更多的精力来干自己有意愿去做的事，或更加擅长的工作。 
  让擅长的人去做他擅长的事，每个人可以专注于自身擅长的事和喜爱的事。

1.4什么是架构：

• 架构的思考来源于对生命周期的识别，以及对生命周期的拆分。

• 如何定义架构： 
  a) 根据要解决的问题，确定问题的主题，界定目标的边界。 
  b) 切分目标的生命周期，区别核心与非核心生命周期。将非核心生命周期独立起来，使之并行起来，缩短整个生命周期的执行时间。 
  c) 对切分后的部分，确定各自的生命周期和主体，以及负责的角色。 
  d）在拆分后的生命周期之间建立沟通机制。让非核心生命周期可以围绕核心生命周期形成树状结构，提供其需要的服务。

• 架构总是在业务遇到瓶颈过程中产生，在瓶颈的解决中应用，在业务消亡时一起消亡

• 自然业务的生命周期就是架构的生命周期

• 每种业务架构拆分是确定的，区别的只是规模不同 
  架构是为了业务而服务，让业务更加高效，让业务更健壮，让业务更服务于更多的人

1.5架构和树

• 树状结构的增长成本低，沟通路径增长少，沟通和能量传递行好。架构的产生恰恰是为了应对增长，自然而然架构都是树状架构的。

• 树状结构主次分离，非核心生命周期发生问题不会造成系统性问题。

• 非树状的分离不算架构，因为非树状结构无法保证架构的权责分离，业务会阻碍增长。

• 架构的目的是让树按自己的规律成长，而不是反过来在业务中加入架构自己的材料，干扰核心业务。

• 树状结构的权责对等保证了参与人能从自身工作中获利，从而保证参与人能够持续的推进业务的生命周期。 
  树状结构是架构的必要结构，脱离树状结构架构的设计不能应对业务的持续增长

1.6概念

• 概念是人互相沟通并认识这个世界的基础

• 不同的概念是为了解决不同的问题而产生的。客观环境决定了概念解决的具体问题。（同一个概念名词在不同的客观环境下解决的很有可能不是同一个问题）

• 设计架构时，先去探索概念所解决的问题，才能更加准确的区分核心、非核心生命周期，为架构打好基础（需求分析的方法论） 
  人与人之间沟通的基础是概念，但是每个人在不同的客观环境中所成长，所以在对架构的分析和设计中需要先统一概念，才能真正的设计出符合业务的架构

1.7什么是抽象

• 抽象实际上是把很多不同概念的相似部分合并在一起，形成一个新的概念。

• 抽象是一个分类的过程，根据不同的人或业务抽取出所关心的特征。

• 架构设计者必须要置身业务中，感受业务的个性，认识到业务所面临的问题。在充分了解个性的基础上才能谈到共性，否则这个抽象只是个人臆想的假共性。 
  共性和个性因不同人和业务方向而不同，在抽象共性的时候充分理解个性才能更好的抽象共性，从而设计出更加适合的架构

1.8识别问题

• 核心生命周期才是最主要需要解决的问题

• 识别问题的能力决定着架构师的水平

• 解决问题要克服对时间的焦虑，要先耐心的把问题搞清楚

• 搞清问题先要了解问题是谁提出的，搞清真正的问题是什么样的。

• 不分析清楚问题就去解决问题，最后结果是问题没有被解决。反而，还产生了新的问题需要去解决。 
  强势插入：有时候产品或者需求方直接给出的是问题解决方案。但是，大部分情况下这个解决方案并不能真正的解决他们需要解决的问题。所以就导致了需求重复变更，开发人员不断抱怨，结果问题还没解决。开发人员应该尽可能的通过沟通和交流了解需求方的真正问题。

• 工程师在解决问题的时候应该好好思考，到底是在帮谁解决问题。搞清楚提出问题的主体才能找到真正的解决方案。（抱着完成自己工作任务的思想，去处理问题的方式是非常危险的。因为此时问题主体已经变成了“我”，而不是真正需要解决问题的主体）

• 任何找到架构师的问题，都不是真正的问题。

• 发现问题永远都比解决问题更重要。

• 警惕那些直接提出解决方案的问题，基本上这类解决方案都不能解决真正的问题。 * 
  a)这是谁的问题? 
  b)什么问题?

1.9切分的原则

• 所有的切分调整，都是对相关人的利益进行调整。（人个体对利益最大化的追求）

• 在社会上，提供的服务更多更好，就能换取到更多更好的生活必需品。

• 利益才是原动力（引申：相干人培训–王直）

• 切分不均衡导致的权责不均衡会导致生命周期无法顺利进行

• 切分出来的生命周期不能超过一个自然人的负载（自然人的负载也根据个体不同而不同）

• 切分是内部行为，应该对系统外是透明的（边界区分）

• 架构的前提是吧一个生命周期连续过程拆分成了一棵树，因为有了树才会有层的出现。

• 树的层次越低，沟通损失越小，效率越高。（管理扁平化）

• 节点能力提升或技术提升都可以帮助减少其子树的深度。

• 切分的结果最后会体现在组织架构上。 
  良好的切分会让整个业务架构树茁壮成长，子节点的权责不对等则会导致整个架构受影响

1.10架构与流程

• 流程就是多个角色为了把一件事做好，按时间顺序协作并完成的整个过程。

• 流程形式上与生命周期相似，但流程关注的并非生灭，而且多个人如何完成同一个目标。

• 流程是描述整个事物发展各种可能性的树 
  业务为了长大发生了架构拆分，形成了树。而流程把拆分之后的业务进行组合，通过遍历树，重新形成了业务生命周期整体

1.11什么是架构师

• 架构师要发现问题的主体，挖掘出核心生命周期。合理分配非核心生命周期的职责。根据核心生命周期将工作成功组合起来，达到1+1>2的效果

• 架构师的权责也要是对等的。

• 架构师的工作效果应该由解决问题的效果也就是增长的效果来决定

• 架构师应该是某个业务或领域的负责人，如果置身于业务子节点中，架构的分配方案将难以落地 
  人人都是架构师。在生活当中每个人或多或少的都在进行着业务的架构划分。比如，桌面的摆放，软件的顺序，到达某个点的路线。在阅读本书的过程后，从雾里看花，身在此山中的感觉中走了出来。发现架构无处不在，不管是夫妻之间，同事之间，朋友之间。根据不同的主体进行分析，了解他的主要问题所在，或者沟通的要点。将会给生活、工作带来莫大的帮助

第二部分、软件架构

2.12 什么是软件

1、软件的目的就是把人类生活的非核心生命周期软件化、虚拟化，以提供更低的成本和更高效的新生活,让核心生命周期运行的更加容易，让非核心生命周期2、的处理更少的占用人类的时间，变相的延长人类生命。

3、成本为王

4、天空才是极限

2.13 软件的生命周期

1、软件开发生命周期，软件运行生命周期

2、人们真正需要的是软件启动后为我们带来的服务，也就是说软件运行生命周期才是人们真正需要软件的地方

3、要成为某个领域的专家，需要一万小时的训练。按每天8小时计算，需要一个人在一个领域工作满5年

2.14 什么是软件架构

1、要解决什么问题：业主的问题、计算机的问题

2、分别是谁的问题：业主、软件工程师

3、分别有什么问题：利益问题、与业主的沟通问题

4、分析问题：

5、会产生哪些架构：组织架构、树状架构

6、软件架构就是通过对软件生命周期的拆分，在符合业务架构的前提下，以达到软件本身访问增长目的的方式。

7、软件架构离不开软件开发团队的组织架构，这个组织架构是软件开发生命周期和软件运行生命周期的执行者

2.15 什么是软件架构师

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

2、软件架构师把完成业主的工作当成自己的最大利益，深入到业务中去。

3、软件的生命周期、业务的生命周期

4、软件架构师需要去拆分生命周期，并要形成组织架构去落实架构执行，而且要平衡别人的利益，甚至去调整别人的利益。

5、对于软件的开发生命周期和软件的运行生命周期，软件架构师必须要具备权力去调整。这一点要求软件架构师必须是一个软件团队组织领导者的身份。

6、要想做好架构师的工作，就要向大自然学习，这样才能够认识到事物本身的生命周期，并能够去顺应事物自身的生命周期的规律来进行拆分，以达到增长的目的。

7、架构师很冷静、很平等地对待所以的技术，只选用合适的技术。技术人员喜欢热衷于某种技术，对其他技术嗤之以鼻

8、架构师是技术的使用者。技术本身没有好坏，因时因地而已

9、架构师拆分生命周期，技术人员实现生命周期。这就是为什么架构师需要有组织架构的权力，因为要确保架构拆分的落地。

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

11、软件技术、业务技术。

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

1、什么是技术

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

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

2、先有业务问题，才会有技术来解决业务问题。而业务的长大要求，提高了对技术的要求，导致了对业务生命周期的拆分，以并行的方式提升效率，形成了架构，也形成了新的技术。

3、重复发明轮子

（1）当技术要解决的问题和拆分出来要解决的问题一致时，这是最完美的。

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

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

4、开源技术

（1）软件运行生命周期这部分才是软件真正的核心能力。代码的核心在于作者对其理念的实现，而不是代码本身。代码的内容反映的是作者对世界的认识，反映的是作者的世界观。

2.17 软件开发

1、软件迭代：优先级、敏捷，犯的错越多，纠正的越快，就越能减少线上的问题

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

3、软件开发模式：（1）以不信任软件开发工程师为基础，以避免软件开发工程师犯错为核心的开发模型。大量的文档，不要求工程师理解，按文档写，大量的测试；（2）以信任软件开发工程师为基础，以软件工程师为核心的开发模型。

4、软件工程师的支持者

（1）软件架构师要想做好架构工作，首先必须是业务的架构专家，同时还得是软件的架构专家，这样才能够支持好软件工程师的工作。

（2）架构师本身也是构架师的一个业务，也需要架构拆分，形成不同领域的架构师。

2.18 软件的架构拆分

1、软件开发团队的拆分

（1）多个业务团队对应一个软件开发团队：可能造成多种业务在一个软件中缠绕

（2）一个业主团队对应多个软件开发团队：产生很多沟通，扯皮，效率低下

（3）一个业主团队对应一个软件开发团队（最优选择）

2、软件的拆分

（1）多个软件团队开发同一个软件：代码容易冲突

（2）一个软件团队开发多个软件：软件之间的界限变模糊

（3）一个软件开发团队开发一个软件（最优选择，但似乎不太现实）

3、软件开发的基础技术：UED，日志、流量分流、基础架构、运维等

4、软件拆分的第二动力：流量的增长

5、架构不可能一步到位

2.19 如何写好代码

1、服务代码、黏合代码、储存代码，业务逻辑代码

2.20 单元测试

1、单元测试：单元测试用来测试工程师自己写的逻辑，比如排序算法这种

2、自测

3、集成测试

2.21 软件架构和面向对象

2.22 软件架构与设计模式

1、模式只用来解决共性问题，不要“过度设计”

2.23 软件架构与软件框架

1、mvc，orm（hibernate），crm（客户关系管理系统）

2.24 软件运维

1、隔离：办公环境与生产环境，   软件、硬件、网络、电力的变更

2、监控变更

3、预警变更

2.25 软件访问生命周期

1、用户--客户端--网络--目标软件--应用服务器--容器（虚拟化）--操作系统

2、集群

3、数据中心：灾备、负载均衡

2.26 软件架构和大数据

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

2.27 软件架构和建筑架构

第三部分、软件架构的应用

3.28 交易

3.29 产品

3.30 用户

3.31 订单

3.32 交易系统

3.33 事务

本文出自 “风之痕_雪虎” 博客，请务必保留此出处http://snowtiger.blog.51cto.com/12931578/1947384

聊聊架构--读书笔记