架构漫谈读书笔记

　架构的本质

　　任何系统，自然情况下，都是从有序到无序，这是有科学依据的， 按照热力学第二定律，自然界的一切自发过程都有方向性，一个孤立系统会由有序变为无序，即它的熵会不断增加，最终寂灭。但生物可以通过和外界交互，主动进行新陈代谢，制造 “负熵” 来保证自身有序，继续生存。

　　同样，一个软件系统随着功能越来越多，调用量急剧增长，整个系统逐渐碎片化，越来越无序，最终无法维护和扩展，所以系统在一段时间的野蛮生长后，也需要及时干预，避免越来越无序。

　　架构的本质就是对系统进行有序化重构，不断减少系统的 “熵”，使系统不断进化。

　　那架构是如何实现无序到有序的呢？ 基本的手段就是分和合，先把系统打散，然后重新组合。

　分的过程是把系统拆分为各个子系统 / 模块 / 组件，拆的时候，首先要解决每个组件的定位问题，然后才能划分彼此的边界，实现合理的拆分。合就是根据最终要求，把各个分离的组件有机整合在一起，相对来说，第一步的拆分更难。

　　拆分的结果使开发人员能够做到业务聚焦、技能聚焦，实现开发敏捷，合的结果是系统变得柔性，可以因需而变，实现业务敏捷。

　　举个例子，在 Web 1.0 时代，一个 ASP 或 JSP 页面里，HTML 和脚本代码混在一起，此时脚本代码越多，系统越混乱（即熵增加），最终连开发者自己都无法理解。此时就需要对系统重新架构，办法是引入 view helper 模式，分离 HTML 和脚本，HTML 成为 view，脚本成为帮助类。然后再简单整合在一起。通过重新分和合，整个系统层次清晰，职责明确，系统的无序度降低，容易扩展。同时不同技能的开发人员，如 UED 和程序员，可以负责不同部分，有效提高开发效率。

　　好的架构就像一篇优美的散文，形散神不散，表面看无序，实则高度有序。

　　架构分类和服务对象

　　架构一般可分业务架构、应用架构、技术架构，那么它们分别解决什么问题，服务于谁呢？ 我们首先看一个系统落地过程：

　　对于负责开发的人来说，怕的是业务太复杂，代码逻辑太乱，超出他能理解的范畴，系统无法维护。因此开发的需求是系统整体概念清晰，容易理解，方便扩展。

　　对于负责运行的机器来说，怕的是业务并发量太大，系统核心资源不够用（如数据库连接）。它希望在业务量增加时，系统能够支持水平扩展，支持硬件容错（如避免单点故障）。

　　开发的痛点主要由业务架构和应用架构解决，业务架构从概念层面帮助开发理解系统（动态的包括业务流程 / 节点 / 输入输出，静态的包括业务域 / 业务模块 / 单据模型）。

　　应用架构从逻辑层面帮助开发落地系统（应用种类 / 应用形式 / 数据交互关系 / 交互方式等），整个系统逻辑上容易理解，最近大家谈的比较多的 SOA 即属于应用架构的范畴。

　　机器的痛点主要由技术架构解决，如技术平台选型（操作系统 / 中间件 / 设备等），部署上希望支持多机房，水平扩展，无单点等。

　　强调一下，系统是人的系统，架构首先是为人服务的，业务概念清晰、应用逻辑合理、人好理解是第一位的（即系统有序度高）。现在大家讨论更多的是技术架构，如高并发设计，分布式事务处理等，只是因为这个不需要业务上下文背景，比较好相互沟通。具体架构设计时，首先要关注业务架构和应用架构，这个架构新手要特别注意。