分层架构特定场景：程序员
分层架构是一种很常见的架构模式，它也叫N层架构。分层架构适用于一个集成不一样功能的系统，当咱们须要把不少不一样的代码集起来的时候，这种模式提供了最合理的结构。能让咱们的代码有足够的灵活性去应对需求改变。当系统自己不负责或者可预期的修改不多时，则不适合用分层架构，由于这样能够增长不少没必要要的代码，陷入过分设计的泥坑。不过度层架构模式是一个稳定的通用模式，这使得它成为大部分应用程序的首选，特别是当你不肯定使用哪一个架构的时候。没有任何一种架构模式是万能的，因此每一个模式都必须有“适应场景”。而模式自己的内容，就是经过“模式定义”和“模块关系”两个层面的规定来表现出来。数据库
分层架构解决的问题：编程
当软件需求变动以后，基本上是对软件代码的修改。而软件代码的修改倒是程序员们最头疼的事情。由于一些大型系统，它的代码根本彻底看不懂，即使是了解了部分细节后，着手修改的时候，也会碰到牵一发而动全身的问题。由于有些功能的修改，须要修改整个系统的不少部分，致使了无穷的BUG。另外就是在紧迫时间内，对于代码的修改每每只能依赖有限的一个或几个程序员，只有他们对系统最熟悉。可是，会面临工做量巨大的问题，几乎没法让更多的程序玩参与进来。假如，熟悉的程序员离职，就有可能表明了整个系统的没法维持。即使是系统能分割给几我的负责，在“集成”几个部分代码的时候，其调试和排错工做，又经常是很持久的，由于那些历来没有协做过的代码，隐藏着大量的误解和不兼容性的问题。这一切的根源只是一个最简单的事实，就是系统对于“代码耦合”的结构问题。糟糕的代码耦合让整个系统变得难以理解，难以修改，难以分工，难以集成。而分层架构就是来解决这个耦合问题的。在这个模式中，请求流只是简单的穿过层次，不留一点云彩，或者说只留下一阵青烟。好比说界面层响应了一个得到数据的请求。响应层把这个请求传递给了业务层，业务层也只是传递了这个请求到持久层，持久层对数据库作简单的SQL查询得到用户的数据。这个数据按照原理返回，不会有任何的二次处理，返回到界面上。每一个分层架构或多或少均可能遇到这种场景。关键在于这样的请求有多少。80-20原则能够帮助你肯定架构是否处于反污水模式。大概有百分之二十的请求仅仅是作简单的穿越，百分之八十的请求会作一些业务逻辑操做。然而，若是这个比例反过来，大部分的请求都是仅仅穿过层，不作逻辑操做。那么开放一些架构层会比较好。不过因为缺乏了层次隔离，项目会变得难以控制。数组
分层架构的解决方案：服务器
分层架构里的组件被分红几个平行的层次，每一层都表明了应用的一个功能。通常状况下，结构大多分红四层：展现层，业务层，持久层，和数据层。有时候，业务层和持久层会合并成单独的一个业务层，尤为是持久层的逻辑绑定在业务层的组件当中。所以，有一些小的应用可能只有3层，一些有着更复杂的业务的大应用可能有5层或者更多的分层。例如：展现层负责处理全部的界面展现以及交互逻辑， 业务层负责处理请求对应的业务。架构里的层次是具体工做的高度抽象，它们都是为了实现某种特定的业务请求。例如：展现层并不须要关心怎样获得用户数据，它只需在屏幕上以特定的格式展现信息。 业务层并不关心要展现在屏幕上的用户数据格式，也不关心这些用户数据从哪里来。它只须要从持久层获得数据，执行与数据有关的相应业务逻辑，而后把这些信息传递给展现层。分层架构的一个突出特性是组件间关注点分离。数据结构
分层架构中的每一层都着特定的角色和职能。它们中的每一层都有着特定的角色和职能。架构里的层次是具体工做的高度抽象，它们都是为了实现某种特定的业务请求。分层的模式的规定很是简单有效：①每一个模块必须属于某个层次，提供给“第N+1层”（上层）服务；同时委派任务给“第N-1层”的模块。②任何一个模块。都不得逆层次调用：属于第N层模块的，不得调用，第N+1层或者以上层次的模块。③任何一个模块，都不得跨层调用：属于第N层的模块，不该该调用第N-2层或者更下层的模块。以业务逻辑特征建模，使用分层模式，每每须要咱们在大脑里对问题领域进行层次抽象，这种抽象是可信赖的原则，就是按照业务逻辑去作。好比现实业务中有一个角色，咱们就创建一个角色的模块，若是咱们有一个场景，就以此为名创建一个这样的模块。以业务逻辑创建的模块，自己也会让系统更容易被理解，由于在代码里能找到和现实中一一对应的概念。多亏了组件分离，让咱们更容易构造有效的角色和强力的模型。 这样应用变的更好开发，测试，管理和维护。架构
分层架构的实例：测试
实例1：spa
好比，存在一个复杂功能的多人在线社区系统，它的服务器端是咱们须要重点讨论的对象。这个产品的服务器端必须知足多样功能：如，玩家移动到不一样的场景中，玩家移动到不一样的场景中，玩家能够换上不一样的服装，能够互相加好友而且能够互相聊天，同时还有广播频道的聊天功能，每一个玩家还有终极的资料库和背包，另外还有各类运营活动。设计
在最初的开发过程当中，咱们须要针对每个须要开发的功能，创建一个模块。这些模块经过单独和客户端、数据库的操做，完成所需功能。若是要开发新的功能，就重写一个这样的模块。这种架构在一开始的时候就有效的，可是随着产品的功能被不断的开发出来，模块的数量也哎增多，可是就潜藏了一个问题。
这个问题的爆发，就是随着任务系统的功能的增多而出现的。由于任务系统本质上是不少其余模块功能的功能支持。如须要玩家去某个场景，得到了某个东西，而后添加了一个好友，或者换了某个时装，发一句消息等等。这样的任务功能实现，被迫要修改不少个模块的代码，由于每一个模块都只有最基本的“自由使用”功能的代码，编程接口都仅仅是面向客户端的，而数据结构都是直接SQL到数据库的。这种须要组合的功能需求，以及得到功能的结果情况，都是其接口上没有写的。这致使了很是复杂的，持续的代码修改。由于任务的内容是时常会变化的。因此这个时候，咱们就须要重构整个架构。把架构从一字排开的设计，修改为能够多个层次互相调用的模块。这些模块之间的接口，有面向客户端的也有面向其余模块的，这样咱们就能直接调用那些现成的功能，组合开发出更复杂强大的功能。无论任务系统如何变化，咱们均可以不用重写那些已经实现的功能，这让整个系统成为能够应对这种需求变化的关键。这就是一个分层架构的实例。
实例2：
想象一个场景，用户发出了一个请求要得到客户的信息。在这个例子中，用户信息由客户数据和订单数组组成(客户下的订单)。用户界面只管接受请求以及显示客户信息。它无论怎么获得数据的，或者说获得这些数据要用到哪些数据表。若是用户界面接到了一个查询客户信息的请求，它就会转发这个请求给用户委托(Customer Delegate)模块。这个模块能找到业务层里对应的模块处理对应数据(约束关系)。业务层里的customer object聚合了业务请求须要的全部信息(在这个例子里获取客户信息)。这个模块调用持久层中的 customer dao 来获得客户信息，调用order dao来获得订单信息。这些模块会执行SQL语句，而后返回相应的数据给业务层。当 customer object收到数据之后，它就会聚合这些数据而后传递给 customer delegate,而后传递这些数据到customer screen 展现在用户面前。
优势：
1.结构简单，容易理解和开发
2.不一样技能的程序员能够分工，负责不一样的层，适合大多数软件公司的组织架构
3.每一层均可以独立测试，其余层的接口能够模拟解决。
缺点：
1.一旦环境变化，须要代码调整或增长工能时，一般比较麻烦和费时
2.部署比较麻烦，即时只修改一个小地方，每每须要整个软件从新部署，不容易作持续发布。
3.软件升级时，可能须要整个服务中止。
4.扩展性差，用户请求大量增长时，必须一次扩展每一层，因为每一层内部是耦合的，扩展会很困难。