当我们在讨论架构时，该用什么姿势？

ddatsh

dev #dev

架构的本质

任何系统，自然情况下，都是从有序到无序

热力学第二定律，自然界一切自发过程都有方向性，孤立系统由有序变为无序，即它的熵不断增加，最终寂灭

但生物可以通过和外界交互，主动进行新陈代谢，制造 “负熵” 来保证自身有序，继续生存

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

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

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

分：合理定位；合：有机整体

分，把系统拆分为各子系统 / 模块 / 组件

拆时，先要解决每个组件的定位问题，然后才能划分彼此的边界，实现合理拆分

合，根据最终要求，把各分离组件有机整合在一起，相对来说，第一步的拆分更难

拆使开发人员业务聚焦、技能聚焦，实现开发敏捷

合是系统变得柔性，可以因需而变，实现业务敏捷

Web 1.0 时代，ASP 或 JSP 里，HTML 和脚本代码混在一起，系统越混乱（熵增加），最终连开发者自己都无法理解

此时对系统重新架构，分离 HTML 和脚本，HTML 成为 view，脚本成为帮助类。然后再简单整合在一起

重新分和合，整个系统层次清晰，职责明确，系统无序度降低，容易扩展

不同技能的开发人员，负责不同部分，有效提高开发效率

架构分类和服务对象

业务、应用、技术架构，分别解决什么问题，服务于谁？

系统落地过程

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

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

开发的痛点主要由业务和应用架构解决

从概念层面帮助开发理解系统（动态的包括业务流程 / 节点 / 输入输出，静态的包括业务域 / 业务模块 / 单据模型）

从逻辑层面帮助开发落地系统（应用种类 / 应用形式 / 数据交互关系 / 交互方式等）

整个系统逻辑上容易理解，SOA 即属于应用架构范畴

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

强调架构首先为人服务，业务概念清晰、应用逻辑合理、人好理解是第一位的（即系统有序度高）

现在大家讨论更多的是技术架构，如高并发设计，分布式事务处理等，只是因为这个不需要业务上下文背景，比较好相互沟通

具体架构设计时，首先要关注业务架构和应用架构，这个架构新手要特别注意

架构师能力要求

架构师只做分和合的事情，但综合能力要求很高，要求内外兼修，下得厨房，上得厅堂

要有技术的广度（多领域知识），又有深度（技术前瞻），对主流公司的系统设计非常了解，知道优劣长短，碰到实际问题，很快有多种方案可供评估

抽象思维是架构师最重要的能力，要善于把实物概念化并归类

比如面对一个大型的 B2C 网站，能够迅速抽象为采购->运营->前台搜索->下单->履单这几大块，对系统分而治之，庖丁解牛，早已目无全牛

抽象思维是往高层次的总结升华，由实到虚

而透过问题看本质则是由虚到实，往深层次地挖掘

比如看到一段 java 代码，知道它在 JVM 如何执行；一个跨网络调用，知道数据是如何通过各种介质到达目标 (操作系统内核 / 网卡端口 / 电磁介质等）

透过问题看本质使架构师能够敏锐地发现底层之真实，系统性端到端地思考问题，识别木桶的短板并解决之

能落地的架构才是好架构，良好的沟通能力确保各方对架构达成共识，愿意采取行动

良好的平衡取舍能力确保架构在现有资源约束下是最合理的，理想最终照进现实

总结