ToB企服应用市场:ToB评测及商务社交产业平台

标题: 高并发体系设计之架构分层 [打印本页]

作者: 汕尾海湾 时间: 2025-1-10 23:48
标题: 高并发体系设计之架构分层
什么是分层架构

软件架构分层在软件工程中是一种常见的设计方式，它是将整体体系拆分成 N 个层次，每个层次有独立的职责，多个层次协同提供完整的功能。
“MVC”（Model-View-Controller）架构。它将整体的体系分成了 Model（模型），View（视图）和 Controller（控制器）三个层次，也就是将用户视图和业务处置惩罚隔离开，并且通过控制器连接起来，很好地实现了表现和逻辑的解耦，是一种标准的软件分层架构。
别的一种常见的分层方式是将整体架构分为表现层、逻辑层和数据访问层：
- 表现层，顾名思义嘛，就是展示数据效果和接受用户指令的，是最靠近用户的一层；
- 逻辑层内里有复杂业务的详细实现；
- 数据访问层则是主要处置惩罚和存储之间的交互。
这是在架构上最简单的一种分层方式。其实，我们在不经意间已经按照三层架构来做体系分层设计了，比如在构建项目的时间，我们通常会建立三个目次：Web、Service 和 Dao，它们分别对应了表现层、逻辑层还有数据访问层。
Linux 文件体系也是分层设计的，可以清晰地看出文件体系的层次。在文件体系的最上层是捏造文件体系（VFS），用来屏蔽不同的文件体系之间的差异，提供同一的体系调用接口。捏造文件体系的下层是 Ext3、Ext4 等各种文件体系，再向下是为了屏蔽不同硬件装备的实现细节，我们抽象出来的单独的一层——通用块装备层，然后就是不同类型的磁盘了。可以看到，某些层次负责的是对下层不同实现的抽象，从而对上层屏蔽实现细节。比方说 VFS 对上层（体系调用层）来说提供了同一的调用接口，同时对下层中不同的文件体系规约了实现模型，当新增一种文件体系实现的时间，只需要按照这种模型来设计，就可以无缝插入到 Linux 文件体系中。

分层有什么好处

分层的设计可以简化体系设计，让不同的人专注做某一层次的事变。
想象一下，假如你要设计一款网络步调却没有分层，该是一件多么痛苦的事变。
- 因为你必须是一个通晓网络的全才，要知道各种网络装备的接口是什么样的，以便可以将数据包发送给它。你还要关注数据传输的细节，并且需要处置惩罚类似网络拥塞，数据超时重传这样的复杂问题。固然了，你更需要关注数据如安在网络上安全传输，不会被别人窥探和篡改。
- 而有了分层的设计，你只需要专注设计应用层的步调就可以了，其他的，都可以交给下面几层来完成。
- 再有，分层之后可以做到很高的复用。比如，我们在设计体系 A 的时间，发现某一层具有一定的通用性，那么我们可以把它抽取独立出来，在设计体系 B 的时间使用起来，这样可以减少研发周期，提升研发的效率。
- 最后一点，分层架构可以让我们更容易做横向扩展。假如体系没有分层，当流量增长时我们需要针对整体体系来做扩展。但是，假如我们按照上面提到的三层架构将体系分层后，那么我们就可以针对详细的问题来做过细的扩展。

如何来做体系分层

最主要的一点就是你需要理清晰每个层次的边界是什么。你大概会问：“假如按照三层架构来分层的话，每一层的边界不是很容易就界定吗？”没错，当业务逻辑简单时，层次之间的边界简直清晰，开发新的功能时也知道哪些代码要往哪儿写。但是当业务逻辑变得越来越复杂时，边界就会变得越来越模糊。我们可以将原先的三层架构细化成下面的样子：
分层架构中的每一层的作用：
- 终端显示层：各端模板渲染并实验显示的层。当前主要是 Velocity 渲染，JS 渲染， JSP 渲染，移动端展示等。
- 开放接口层：将 Service 层方法封装成开放接口，同时举行网关安全控制和流量控制等。
- Web 层：主要是对访问控制举行转发，各类基本参数校验，或者不复用的业务简单处置惩罚等。
- Service 层：业务逻辑层。
- Manager 层：通用业务处置惩罚层。这一层主要有两个作用，其一，你可以将原先 Service 层的一些通用本领下沉到这一层，比如与缓存和存储交互策略，中心件的接入；其二，你也可以在这一层封装对第三方接口的调用，比如调用支付服务，调用审核服务等。
- DAO 层：数据访问层，与底层 MySQL、Oracle、Hbase 等举行数据交互。
- 外部接口或第三方平台：包罗其它部分 RPC 开放接口，基础平台，其它公司的 HTTP 接口。
在这个分层架构中主要增长了 Manager 层，它与 Service 层的关系是：Manager 层提供原子的服务接口，Service 层负责依据业务逻辑来编排原子接口。

分层架构的不足

任何事物都不可能是尽善尽美的，分层架构虽有上风也会有缺陷，它最主要的一个缺陷就是增长了代码的复杂度。
这是显而易见的嘛，明显可以在接收到请求后就可以直接查询数据库获得效果，却偏偏要在中心插入多个层次，并且有可能每个层次只是简单地做数据的传递。有时增长一个小小的需求也需要更改全部层次上的代码，看起来增长了开发的本钱，并且从调试上来看也增长了复杂度，本来假如直接访问数据库我只需要调试一个方法，现在我却要调试多个层次的多个方法。
别的一个可能的缺陷是，假如我们把每个层次独立摆设，层次间通过网络来交互，那么多层的架构在性能上会有损耗。这也是为什么服务化架构性能要比单体架构略差的原因，也就是所谓的“多一跳”问题。
那我们是否要选择分层的架构呢？答案固然是肯定的。你要知道，任何的方案架构都是有上风有缺陷的，天地尚且不全何况我们的架构呢？分层架构固然会增长体系复杂度，也可能会有性能的损耗，但是相比于它能带给我们的好处来说，这些都是可以接受的，或者可以通过其它的方案解决的。我们在做决议的时间切不可以偏概全，因噎废食。

你知道的越多，你不知道的越多。

免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。

欢迎光临 ToB企服应用市场:ToB评测及商务社交产业平台 (https://dis.qidao123.com/)