架构-分层模式案例

架构模式是什么

软件架构模式，诞生于软件开发的最大难题——需求变更。由于需求变更，导致了大量项目因为超出预算的人力、时间而归于失败。软件开发成本有限的，但需求变更似乎是无限的，这成为了一个非常难解决的问题。

软件需求变更的结果，基本上就是对于软件代码的修改。而软件代码的修改却是程序员们最头疼的事情。因为一些大型系统，其代码根本就无法完全看懂，即便能了解部分细节，在着手修改的时候，也会碰到“触一发而动全身”的问题：因为有些功能的修改，需要修改整个系统的很多部分，导致了无穷的BUG。

另外一个致命的问题，就是在紧迫的时间内，对于代码的修改往往只能依赖有限的一个或几个程序员，只有他们对系统是最熟悉的。但是面临巨大的工作量，几乎无法让更多的程序员参与进来，其他人只能干瞪眼。一旦熟悉系统的程序员离职，有可能就代表了整个系统无法维护。即便是系统能分割给几个人负责，在“集成”几个部分的代码的时候，其调试和除错的工作，又常常是旷日持久的，因为那些从来没协作过的代码，隐藏着大量的误解和不兼容问题。——这一切的根源，其实只是一个最简单的事实，就是系统中对于“代码耦合”的结构问题。糟糕的代码耦合让整个系统变得难以理解、难以修改、难以分工、难以集成。

针对代码耦合的问题，软件界进行了大量的理论研究和实践，最后发现：系统的架构设计，是改善耦合的最好方式。架构设计的本质，就是：

1. 划分耦合的单位——也就是划分模块。系统应该划分成什么样的模块，代表了设计者对于系统应对的需求的基本理解。一旦能清晰的划分出模块了，其代码耦合就有了最基本的范围。而模块本身也是提示程序员理解系统的基本单位。

   
   

2. 规范耦合的形式——代码耦合的形式有很多种，如直接调用、事件响应、消息队列等等，这些形式提供了代码耦合的不同特征。直接调用的代码在静态阅读的时候非常容易理解，而事件响应则提供了运行时耦合的好处。耦合的形式还有另外一层含义，就是代码耦合的规范：那些模块之间应该直接耦合，哪些不能耦合，是否应该加入中间层次等等。

这两个关于耦合的设计，就形成了各种架构设计。

在软件界多年的架构设计工作之后，人们总结出一些经验，这些经验被成为“架构模式”。架构模式包含了“名称”“适应场景”“模块定义”“模块关系”这几个部分。没有任何一种架构模式是万能的，所以每个模式都必须有“适应场景”。而模式本身的内容，就是通过“模式定义”和“模块关系”两个层面的规定来表现出来。除了模式的本身内容，为了理解某种特定的架构模式，人们还会附带上一些应用案例，好让学习者能通过实例来理解这种设计的真谛。

最后，还会有些关于某种设计模式的实现手段——在面向对象的设计思想下，往往会使用一种或者多种“设计模式”来作为实现。当然只要是符合架构模式的耦合规定的，都可以成为某种架构模式的实践，但是使用软件业常见的“设计模式”，还是能比较轻松的去用代码来实现这些架构。

分层模式

下面我们开始第一个架构模式的介绍，先看一个案例：

【此案例并非完全真实情况，有一定提炼修改成分】

这是一个有着复杂功能的多人在线社区，其服务器端是我们需要讨论的重点。这个产品的服务器端必须满足多样的功能：玩家移动到不同的场景中，玩家可以换上不同的服装，可以互相加好友并且聊天，同时还有广播频道的聊天，每个玩家还有自己的资料库和背包，另外还有各种运营活动。

在最初的开发过程中，我们针对每个需要开发的功能，建立了一个模块。这些模块通过单独和客户端、数据库的操作，完成所需功能。如果要开发新功能，就重新写一个这样的模块。这种架构设计在一开始是非常有效的，产品功能被不断的开发出来，模块的数量也在增多，但是也潜藏了一个问题。

这个问题的爆发是随着一个叫做“任务系统”的功能而出现的。因为任务系统本质上是需要很多其他模块的功能提供支持。如需要玩家去某个场景（场景模块），获得某个东西（背包模块），然后添加一个好友（好友模块），或者换上某个服装，说一句话等等……这样的任务功能的实现，被迫要修改很多个模块的代码，因为每个模块都只有最基本的“自由使用”功能的代码，编程接口都仅仅是面向客户端的，而数据结果都是直接SQL到数据库的。这种需要组合的功能请求，以及获得功能的结果状况，都是其接口上没有的。这导致了非常复杂的，持续的代码修改。因为任务的内容可是时常会变化的哦！

在分析了问题之后，我们决定重构整个架构，我们把架构从一字排开的设计，修改成为可以多个层次互相调用的模块。这些模块直接的接口，有面向客户端的，也有面向其他模块的，这样我们就能直接调用那些现成的功能，组合开发出更复杂强大的功能。不管任务系统如何变化，我们都可以不用重写那些已经实现的功能，这让整个系统成为可以应对这种需求变化的关键。

实际上，这样的架构正是一个著名的架构模式——分层模式。

分层模式的规定非常简单而有效：

1. 每个模块都必须属于某个层次，提供给“第N+1层”（上层）服务；同时委派任务给“第N-1层”的模块。

2. 任何一个模块，都不得逆层次调用：属于第N层的模块，不得调用（耦合）第N+1层或以上层次的模块。

3. 任何一个模块，都不得跨层调用：属于第N层的模块，不应该调用第N-2层或更下层的模块。

分层模式是架构中最基本的模式，但是也是我们开发中最被忽视的模式。我们开发中往往没有去定义代码的“层次”，仅仅以“功能”纵向划分模块，没有按实现层次横向切分。

门面模式、策略模式都常常用来实现分层架构。

上文所说的例子，后来改造成了分层模型：

1）重复代码减少了，功能开发更快了——一顶层开发只需要学习下层类库，就可以开始开发；近似功能模块被统一，修BUG覆盖面更好。

2）性能提升代码能更好的覆盖了——集中了通用实现代码，也集中了优化部分

3）可以并行开发，资深人员负责底层，一般人员负责上层

总结一下分层模式：

“模式的模式”——强大同时灵活

★ 适应：集成不同类型功能 ——当我们需要把很多不同功能的代码集成起来的时候，这种模式提供了最合理的结构。能让我们的代码有足够的灵活性去应对需求变更。

★ 不适应：简单业务模型——如果系统本身不复杂（或者叫做可预期的修改很少），建立各种层次，然后为了符合层次间调用的规定，会增加很多不必要的代码，陷入过度设计的泥坑。

★ 方法论：以业务逻辑特征建模 ——使用分层模式，往往需要我们在大脑里对问题领域进行层次抽象，这种抽象最可信赖的原则，就是按照业务逻辑去做。比如现实业务中有一个角色，我们就建立一个角色的模块；如果我们有一个场景，就以此为名建立一个这样的模块……。以业务逻辑建立的模块，本身也会让系统更容易被理解，因为在代码里能找到和现实中一一对应的概念。

★ 设计模式实现：

★ 门面模式 ——我们对于每个模块或者每个层次都会设计一个“门面”来降低耦合的复杂程度。

★ 策略模式——抽象层次会隐藏底层的实现细节，这就是策略模式最基本的设计，我们往往会把上层作为功能接口，下层作为可选的策略来实现。