聊聊架构

（最近我会写一些我对架构的理解和思考，本篇是第一篇，欢迎交流）

什么是系统架构？

从字面上理解，系统架构是系统的框架结构，是系统进行抽象之后的一个草图。它包含了系统中各个抽象组件的协作方式。

为什么需要架构？

好的架构能够降低系统的创造和维护成本，特别是维护成本。一个系统的创造成本低，而维护的成本大，特别是互联网应用，一般情况下把一个系统搞上线只需要一个月，但是有的系统搞下线缺需要几个月，而维护则需要数年。好的设计师不会在系统上线后对系统进行大的修改，从而减少系统的维护成本。

如果区分创造和维护两个阶段的话，架构师分为系统架构师和维护架构师，架构新的系统的是系统架构师，而维护老系统的则是维护架构师，程序员大多数愿意做新系统不愿意维护老系统，因为感觉没什么技术含量，但是维护老的系统反而更难，因为老系统的重构和改进更加复杂，维护架构师不仅需要读懂老系统架构设计，还要在不影响老系统功能的情况下，进行功能新增和重构。我的一位同事在对一个旧的系统进行重构之前，读了几个星期的代码，然后才开始设计改进方案。

架构设计的目标

设计的目标围绕着降低成本这个需求进行。设计的目标非常多，不同的系统架构目标也不一致，但是我觉得比较重要的架构目标有以下几个，可扩展性，灵活性和可插入性。

• 可扩展性，新的功能容易加入到系统里，降低创造成本。
• 灵活性，一处修改不会波及其他的地方，降低维护成本。
• 可插入性，同样的功能可方便的替换，降低创造和维护成本。

那么如何实现这三个目标

• 提高可扩展性：把不易变的抽象出来。抽象层要比实现层要更稳定，抽象层的变化要少。把变化的集中起来，比如把容易变化的功能放在单独一个系统或者一个模块里。
• 灵活性：模块化，每个模块相互独立，减少模块之间的藕合度，修改不会互相传递。
• 提高可插入性：模块化，服务化。

如何开始架构

当一块新业务放在你面前时，如何进行系统架构？我觉得需要进行以下几个步骤的思考：

• 业务分析：输出业务架构图，这个系统里有多少个业务模块，从前台用户到底层一共有多少层。
• 系统划分：根据业务架构图输出系统架构图，需要思考的是这块业务划分成多少个系统，可能一个系统能支持多个业务。基于什么原则将一个系统拆分成多个系统？又基于什么原则将两个系统合并成一个系统？
• 系统分层：系统是几层架构，基于什么原则将一个系统进行分层，分成多少层？
• 模块化：系统里有多少个模块，哪些需要模块化？基于什么原则将一类代码变成一个模块。