在构建满足中小型企业需求的 LAN 时，如果采用分层设计模型，成功的可能性会更大些。与其它网络设计相比较，分层网络更容易管理和扩展，排除故障也更迅速。
 
分层网络设计需要将网络分成互相分离的层。每层提供特定的功能，这些功能界定了该层在整个网络中扮演的角色。通过对网路的各种功能进行分离，可以实现模块化的网络设计，这样有利于提高网络的可扩展性和性能。典型的分层设计模型可分为三层：接入层、分布层和核心层。
 
接入层
 
接入层负责连接终端设备（例如 PC、打印机和 IP 电话）以提供对网络中其它部分的访问。接入层中可能包含路由器、交换机、网桥、集线器和无线接入点。接入层的主要目的是提供一种将设备连接到网络并控制允许网络上的哪些设备进行通信的方法。
 

分布层
 
分布层先汇聚接入层交换机发送的数据，再将其传输到核心层，最后发送到最终目的地。分布层使用策略控制网络的通信流并通过在接入层定义的虚拟 LAN（VLAN）之间执行路由 (routing) 功能来划定广播域。利用 VLAN，您可将交换机上的流量分成不同的网段，置于互相独立的子网 (subnetwork) 内。例如，在大学中，您可以根据教职员、学生和访客分离流量。为确保可靠性，分布层交换机通常是高性能、高可用性和具有高级冗余功能的设备。本课后面，您还将学习有关 VLAN、广播域和 VLAN 间路由的知识。
 

核心层
 
分层设计的核心层是网际网络的高速主干。核心层是分布层设备之间互联的关键，因此核心层保持高可用性和高冗余性非常重要。核心层也可连接到 Internet 资源。核心层汇聚所有分布层设备发送的流量，因此它必须能够快速转发大量的数据。
 

分层网络的优点
 
分层网络设计有许多优点。
 
可扩展性
 
分层网络具有很好的可扩展性。设计的模块化允许跟随网络的扩展同步复制设计元素。由于模块的每个实例都是一致的，因此很容易计划和实施网络扩展。例如，如果您的设计模型由每 10 台接入层交换机配两台分布层交换机组成，则可不断添加接入层交换机，直到有 10 台接入层交换机交叉连接到两台分布层交换机上为止，然后才需要向该网络拓扑添加额外的分布层交换机。此外，在您添加更多的分布层交换机以容纳接入层交换机的通信负载时，您可以添加核心层交换机来处理核心层上增加的负载。
 
冗余性
 
随着网络的不断扩大，网络的可用性也变得越来越重要。利用分层网络可以方便地实现冗余，从而大幅提高可用性。每台接入层交换机都连接到两台不同的分布层交换机上，借以确保路径的冗余性。如果其中一台分布层交换机出现故障，接入层交换机可以切换到另一台分布层交换机上。此外，每台分布层交换机也都连接到两台或多台核心层交换机上，借以确保在核心层交换机出现故障时的路径可用性。唯一存在冗余问题的网络层是接入层。通常，终端节点设备（例如 PC、打印机和 IP 电话）无法通过连接到多台接入层交换机来实现冗余性。如果接入层交换机出现故障，则连接到该交换机上的所有设备都会受此故障的影响。网络的其它部分则不受影响，继续保持正常运行。
 
性能
 
改善通信性能的方法是避免数据通过低性能的中间设备传输。数据通过聚合交换机端口链路以接近线速的速度从接入层发送到分布层。随后，分布层利用其高性能的交换功能将此流量上传到核心层，再在核心层将此流量发送到最终目的地。由于核心层和分布层的运行速度很高，因此不存在竞争网络带宽的问题。所以，正确设计的分层网络可以在所有设备之间实现接近线速的速度。
 
安全性
 
分层网络设计可以提高网络的安全性并且便于管理。接入层交换机有各种端口安全选项可供配置，通过这些选项可以控制允许哪些设备连接到网络。在分布层还可灵活地选用更高级的安全策略。您可以应用访问控制策略，借以定义在网络上部署哪些通信协议以及允许这些协议的流量传送到何方。例如，如果希望限定只有接入层连接的特定用户群才可使用 HTTP，则可在分布层应用一个阻止 HTTP 流量的策略。要根据高层协议（例如 IP 和 HTTP）限制流量，要求交换机能够处理该层的策略。某些接入层交换机支持第 3 层功能，但处理第 3 层数据通常是分布层交换机的任务，因为分布层交换机处理的效率要高得多。
 
易于管理性
 
相对而言，分层网络更容易管理。分层设计的每一层都执行特定的功能，并且整层执行的功能都相同。因此，如果需要更改接入层交换机的功能，则可在该网络中的所有接入层交换机上重复此更改，因为所有的接入层交换机在该层上执行的功能都相同。由于几乎无须修改即可在不同设备之间复制交换机配置，因此还可简化新交换机的部署。利用同一层各交换机之间的一致性，可以实现快速恢复并简化故障排除。在某些特殊情形下，两台设备之间的配置可能会不一致，此时请务必妥善记录这些配置以便在部署之前进行比较。
 
易于维护性
 
由于分层网络在本质上是模块化的，并且扩展非常方便，因此维护起来也很容易。而其它网络拓扑设计，随着网络的不断扩大，管理的复杂性也随之不断增加。此外，在某些网络设计模型中，对网络的成长规模有一定的限制，以免网络过于复杂导致维护成本过于高昂。在分层设计模型中，交换机功能在各层统一定义，这样可以更方便地选择适当的交换机。向某一层添加交换机未必能解决其它层的瓶颈问题或其它限制。对于为实现最佳性能而采用的全网状网络拓扑，所有的交换机都必须是高性能的交换机，这是因为每台交换机都必须能够执行网络的全部功能。 但在分层模型中，每层交换机的功能并不相同。因此，可以在接入层上使用较便宜的接入层交换机，而在分布层和核心层上使用较昂贵的交换机来实现高性能的网络，这样可以节省资金。



				
转载于:https://blog.51cto.com/07net01/586120

分层思想，是应用系统最常见的一种架构模式，我们会将系统横向切割，根据业务职责划分。MVC 三层架构就是非常典型架构模式，划分的目的是规划软件系统的逻辑结构便于开发维护。MVC：英文即 Model-View-Controller，分成模型层、视图层、控制层。将页面和业务逻辑分离，提高应用的可扩展性及可维护性。如图所示。

事实上，MVC 三层架构只是概念层面的指导思想，我们会将层次结构划分的更加细致。例如，传统后端的 MVC 模式对于前后端的划分界限比较模糊。一般情况下，前端开发人员负责编写项目的静态页面，包括 HTML 页面、CSS 样式与 JavaScript 交互部分，并提供给服务端开发人员编写视图层业务，甚至有的项目直接让前端开发人员完成视图层的业务开发任务。这样的开发模式造成的问题在于，前后端在开发过程中分工不明确，并且存在相互强依赖，前端开发人员需要关心服务端的业务，服务端开发人员也需要依赖前端的进度。并且随着 Android、 IOS、 PC 以及 U3D 等多个客户端加入，程序的开发成本与维护成本会指数级上升。为了提高开发效率，细化职责，前后端分离的需求越来越被重视。前后端分离在于服务端提供 API 接口，前端调用 AJAX 实现数据交互。如图所示。
此外，随着数据存储能力的不断扩展（MySQL、Oracle、Redis、MongoDB、ElasticSearch、PostgreSQL、HBase 等），以及随着微服务的流行与普及，我们经常通过 RPC（Dubbo、HSF、Thrift 等）依赖很多外部接口或 HTTP 调用第三方平台。因此，我们需要一套细致划分的代码结构。此外，很多时候，我们在开发过程中，也并没有把它们职责划分开。例如，在代码结构中，我们将非常多的逻辑业务放在了 Controller 层，而只把 Service 作为数据透传的途径了。事实上，这个是不对的。无独有偶，我们还会发现有的项目中在 Dao 层调用远程服务，也有的会在 Service 层或者 Controller 层进行这样的操作，由于不同研发同学的习惯不同，或者偷工取巧导致开发代码风格完全不同，代码层次结构混乱。
总结一下，MVC 三层架构只是概念层面的指导思想，我们会将层次结构划分的更加细致。现在，我们来深入探讨“如何合理的设计代码分层，论代码分层的设计之道”。在笔者看来，合理的代码分层应该是这样的。如图所示。
其中，数据持久层 承载了数据存储和访问的能力，它既与底层数据进行交换，包括 MySQL、Oracle、Redis、MongoDB、ElasticSearch、PostgreSQL、HBase 等，又通过 Pxoxy 的代理和包装与远程服务数据进行联动。因此，在业务逻辑层调用时，它对底层的数据实现方式是无感知的，无论是哪种数据存储方式，以及它是远程数据，还是本地数据，都可以非常容易的调用。换句话说，我们需要将数据的查询和更改操作限制在数据持久层，并只能被业务逻辑层访问。
那么，业务逻辑层 的职责是与数据持久层交互，对多个数据源的操作进行聚合，并且提供组合复用的能力。此外，它也是业务通用能力的处理层，其中还包括缓存方案、消息监听（MQ）、定时任务等等。此外，我们要将尽可能多的业务处理放在业务逻辑层，包括了参数校验、数据转换、异常处理等，而不是在 Controller 再去处理。
笔者认为：请求处理层具有三块能力，一个是通过模板引擎渲染，例如 FreeMarket、Velocity 的页面渲染，以及通过 Controller 层封装的 RESTful API 的 HTTP 接口。如果项目中用到了 Dubbo、HSF、Thrift 等 RPC 服务，我们还需要提供对于的服务给上游的业务方使用，它通过 Service 来实现并暴露成 RPC 接口。这里，Service 的命名是相对的，一般通过 Client 提供接口，通过 Service 实现具体的业务逻辑。
我们了解了逻辑结构，那么，笔者认为比较清晰的物理代码结构应该是这样的。
那么，我们可以跨层级调用吗？笔者认为：我们需要禁止跨层级调用，因为每个层级都自己的职责，并且对上层而言是透明的，就像 OSI 七层协议模型和 TCP/IP 四层协议模型一样，只有将职责限制在自己的边界内，整体层次结构才清晰明了。那么对于同级调用，笔者认为在业务逻辑层是允许的，但是，要特别注意循环调用的产生。
现在，我们再横向理解几个领域模型：VO、BO、DO、DTO。这个概念，是由阿里编码规约提到的，由于其业务非常复杂，因此为了更好地进行领域建模和模型隔离，提出了这几个概念。其中，DO（Data Object）与数据库表结构一一对应，通过 DAO 层向上传输数据源对象。 而 DTO（Data Transfer Object）是远程调用对象，它是 RPC 服务提供的领域模型。注意的是，对于 DTO 一定要保证其序列化，实现 Serializable 接口，并显示提供 serialVersionUID，否则在反序列化时，如果 serialVersionUID 被修改，那么反序列化会失败。事实上，DO 和 DTO 唯一的区别在于，一个是本地数据源的领域模型，一个是远程服务的序列化领域模型。对于 BO（Business Object），它是业务逻辑层封装业务逻辑的对象，一般情况下，它是聚合了多个数据源的复合对象。那么，VO（View Object） 通常是请求处理层传输的对象，它通过 Spring 框架的转换后，往往是一个 JSON 对象。例如，你需要解决 Long 类型的数据精度丢失的问题（如果直接传给 Web 端的话，在 Long 长度大于 17 位时会出现精度丢失），你就可以在 Controller 层通过 @ResponseBody 将返回数据自动转换成 JSON 时，统一封装成字符串。
总结一下，分层思想，将系统横向切割，根据业务职责划分。划分的目的是规划软件系统的逻辑结构便于开发维护。但是，随着微服务的演变和不同研发的编码习惯，往往导致了代码分层不彻底导致引入了“坏味道”。

（1）网络协议

               可以理解为规则，其中包含着数据传输和数据的解释。

              典型的协议：传输层：tcp/udp协议，应用层：http/ftp协议，网络层：ip协议，网路接口：arp协议

（2）网络应用设计模式

             1）C/S模型：客户端和服务器模型，需要在客户两段各自部署客户端和服务器来完成数据通信。

                     优点：性能好（由于数据缓存到客户端本地，从而提高了传输效率和观感）

                                 协议灵活（协议可以采用自定义的）

                     缺点：同时开发服务器和客户端，使得工作量增加，开发周期长。

                                 安装客户端在用户主机容易对用户主机安全造成威胁。

            2）B/S模型：浏览器和服务器模型

                      优点：使用标准服务器作为客户端，开发工作量小，只需要开发服务器即可

                                  采用浏览器来显示数据，移植性好，不受平台限制

                      缺点：使用第三方浏览器，网路应用支持受限。

                                  缓存数据不足，传输数据受到限制，应用观感大打折扣。

                                  必须和浏览器一样，使用http协议进行通信，协议选择不够灵活。

（3）分层模型

          1)OSI七层模型:物数网传会表应

                1>物理层：定义物理设备标准，传输比特流（0/1信号），数模转换层，这一层的数据称为比特。

                2>数据链路层：定义如何将格式化数据以帧为单位进行传输。这一层的数据称为帧。

                3>网络层：将位于不同地址位置的网络中的两个主机系统之间提供连接和路径选择（ip识别和MAC地址连接），主要通过路由器进行连接。

                4>传输层：定义传输数据的协议（tcp/udp）和端口号（进程）。这一层的数据称为段。

                5>会话层：通过传输层建立数据传输通路，主要用于系统之间发起会话和接收会话请求。

                6>表示层：用于数据格式之间进程转换。

                7>应用层：用户应用程序提供网路服务。

           2）TCP/IP模型

                1>2>合并称为链路层（网络接口层）：设备驱动程序及接口卡

                 3>网络层：IP

                 4>传输层：TCP/UDP

                 5>6>7>应用层：FTP

                

(4)通信过程

            

        分层思想，是应用系统最常见的一种架构模式，我们会将系统横向切割，根据业务职责划分。MVC 三层架构就是非常典型架构模式，划分的目的是规划软件系统的逻辑结构便于开发维护。MVC：英文即 Model-View-Controller，分成模型层、视图层、控制层。将页面和业务逻辑分离，提高应用的可扩展性及可维护性。如图所示：



        事实上，MVC 三层架构只是概念层面的指导思想，我们会将层次结构划分的更加细致。例如，传统后端的 MVC 模式对于前后端的划分界限比较模糊。一般情况下，前端开发人员负责编写项目的静态页面，包括 HTML 页面、CSS 样式与 JavaScript 交互部分，并提供给服务端开发人员编写视图层业务，甚至有的项目直接让前端开发人员完成视图层的业务开发任务。这样的开发模式造成的问题在于，前后端在开发过程中分工不明确，并且存在相互强依赖，前端开发人员需要关心服务端的业务，服务端开发人员也需要依赖前端的进度。并且随着 Android、 IOS、 PC 以及 U3D 等多个客户端加入，程序的开发成本与维护成本会指数级上升。为了提高开发效率，细化职责，前后端分离的需求越来越被重视。前后端分离在于服务端提供 API 接口，前端调用 AJAX 实现数据交互。如图所示。



        此外，随着数据存储能力的不断扩展（MySQL、Oracle、Redis、MongoDB、ElasticSearch、PostgreSQL、HBase 等），以及随着微服务的流行与普及，我们经常通过 RPC（Dubbo、HSF、Thrift 等）依赖很多外部接口或 HTTP 调用第三方平台。因此，我们需要一套细致划分的代码结构。此外，很多时候，我们在开发过程中，也并没有把它们职责划分开。例如，在代码结构中，我们将非常多的逻辑业务放在了 Controller 层，而只把 Service 作为数据透传的途径了。事实上，这个是不对的。无独有偶，我们还会发现有的项目中在 Dao 层调用远程服务，也有的会在 Service 层或者 Controller 层进行这样的操作，由于不同研发同学的习惯不同，或者偷工取巧导致开发代码风格完全不同，代码层次结构混乱。

        总结一下，MVC 三层架构只是概念层面的指导思想，我们会将层次结构划分的更加细致。现在，我们来深入探讨“如何合理的设计代码分层，论代码分层的设计之道”。在笔者看来，合理的代码分层应该是这样的。如图所示。



        其中，数据持久层 承载了数据存储和访问的能力，它既与底层数据进行交换，包括 MySQL、Oracle、Redis、MongoDB、ElasticSearch、PostgreSQL、HBase 等，又通过 Pxoxy 的代理和包装与远程服务数据进行联动。因此，在业务逻辑层调用时，它对底层的数据实现方式是无感知的，无论是哪种数据存储方式，以及它是远程数据，还是本地数据，都可以非常容易的调用。换句话说，我们需要将数据的查询和更改操作限制在数据持久层，并只能被业务逻辑层访问。

        那么，业务逻辑层 的职责是与__数据持久层__交互，对多个数据源的操作进行聚合，并且提供组合复用的能力。此外，它也是业务通用能力的处理层，其中还包括缓存方案、消息监听（MQ）、定时任务等等。此外，我们要将尽可能多的业务处理放在__业务逻辑层__，包括了参数校验、数据转换、异常处理等，而不是在 Controller 再去处理。

        笔者认为：请求处理层具有三块能力，一个是通过模板引擎渲染，例如 FreeMarket、Velocity 的页面渲染，以及通过 Controller 层封装的 RESTful API 的 HTTP 接口。如果项目中用到了 Dubbo、HSF、Thrift 等 RPC 服务，我们还需要提供对于的服务给上游的业务方使用，它通过 Service 来实现并暴露成 RPC 接口。这里，Service 的命名是相对的，一般通过 Client 提供接口，通过 Service 实现具体的业务逻辑。

        我们了解了逻辑结构，那么，笔者认为比较清晰的物理代码结构应该是这样的。



        那么，我们可以跨层级调用吗？笔者认为：我们需要禁止跨层级调用，因为每个层级都自己的职责，并且对上层而言是透明的，就像 OSI 七层协议模型和 TCP/IP 四层协议模型一样，只有将职责限制在自己的边界内，整体层次结构才清晰明了。那么对于同级调用，笔者认为在业务逻辑层是允许的，但是，要特别注意循环调用的产生。

        现在，我们再横向理解几个领域模型：VO、BO、DO、DTO。这个概念，是由阿里编码规约提到的，由于其业务非常复杂，因此为了更好地进行领域建模和模型隔离，提出了这几个概念。其中，DO（Data Object）与数据库表结构一一对应，通过 DAO 层向上传输数据源对象。 而 DTO（Data Transfer Object）是远程调用对象，它是 RPC 服务提供的领域模型。注意的是，对于 DTO 一定要保证其序列化，实现 Serializable 接口，并显示提供 serialVersionUID，否则在反序列化时，如果 serialVersionUID 被修改，那么反序列化会失败。事实上，DO 和 DTO 唯一的区别在于，一个是本地数据源的领域模型，一个是远程服务的序列化领域模型。对于 BO（Business Object），它是业务逻辑层封装业务逻辑的对象，一般情况下，它是聚合了多个数据源的复合对象。那么，VO（View Object） 通常是请求处理层传输的对象，它通过 Spring 框架的转换后，往往是一个 JSON 对象。例如，你需要解决 Long 类型的数据精度丢失的问题（如果直接传给 Web 端的话，在 Long 长度大于 17 位时会出现精度丢失），你就可以在 Controller 层通过 @ResponseBody 将返回数据自动转换成 JSON 时，统一封装成字符串。

        总结一下，分层思想，将系统横向切割，根据业务职责划分。划分的目的是规划软件系统的逻辑结构便于开发维护。但是，随着微服务的演变和不同研发的编码习惯，往往导致了代码分层不彻底导致引入了“坏味道”。笔者试图提出一个新的代码分层思路来规避和规范这种分层结构。


如果你有不同的想法和兴趣，欢迎加我微信一起探讨与交流哟~

原文地址：梁桂钊的博客

博客地址：blog.720ui.com

欢迎转载，转载请注明作者及出处，谢谢！