# 水平分层架构

对单体架构在水平方向进行拆分，就会演变成水平分层架构，水平分层架构解决了单体架构存在的高耦合、低扩展性的问题，

如图2：

![](/files/-Ltdv8YtHsgSWYGfED84)

图2水平分层架构

水平分层架构分为网关层、业务逻辑层、数据访问层以及DB/Cache。每一层都是独立的进程，每个进程职责分明。

## 1.   分层描述

### 1.1   网关层

网关层接收客户端请求，对请求合法性校验以及鉴权、对请求根据URI路由转发到相应的业务逻辑层

### 1.2   业务逻辑层

业务逻辑层负责请求具体的业务逻辑处理，在微信端发送消息给好友，业务逻辑层会对发送消息进行黄反等策略检查、会校验发送者的权限（你遇到过“消息已发送，被对方拒收”的情况吗？）、判断接收方是否在线等等。

### 1.3  数据访问层

业务逻辑层不会直接和数据库交互，它需要的数据通过数据访问层获取。数据访问层有三部分功能构成：

l 第一是ORM，接收业务逻辑层发送的数据协议（JSON等文本协议或者PB等二进制协议）转换成SQL协议；

l 第二是Sharding，数据库存储数据超过千万级别时，为了进一步提升性能，会按照业务功能垂直拆分库以及水平方向拆分表。因此在此层提供分库分表支持，对业务逻辑层透明，使之无感知。

l 第三是随着业务请求量继续增大，Sharding后依然无法满足性能需求，进一步增加Cache功能，对业务逻辑层透明。存储层往往使用MySQL提供关系存储，使用Redis提供缓存。

大家熟知的MVC架构，本质上是水平分层架构，分为Model层、View层、Control层。水平分层架构分层不易过多，每增加一层，请求响应延迟相应会增加；分层越多，定位线上问题难度越大。根据业务使用场景的不同，常常对水平分层架构分为三层（MVC）、四层（图2）、五层（图3）。


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://tuonioooo-notebook.gitbook.io/micro-services-subject/jia-gou-she-ji-pian/hu-lian-wang-jia-gou-yan-jin-fen-xi/shui-ping-fen-ceng-jia-gou.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.