互联网分层架构的本质

互联网分层架构的本质

Original 2017-10-11 58沈剑 架构师之路

上图是一个典型的互联网分层架构

  • 客户端层:典型调用方是browser或者APP

  • 站点应用层:实现核心业务逻辑,从下游获取数据,对上游返回html或者json

  • 数据-缓存层:加速访问存储

  • 数据-数据库层:固化数据存储

 

如果实施了服务化,这个分层架构图可能是这样:

中间多了一个服务层

 

同一个层次的内部,例如端上的APP,以及web-server,也都有进行MVC分层

  • view层:展现

  • control层:逻辑

  • model层:数据

 

可以看到,每个工程师骨子里,都潜移默化的实施着分层架构

 

那么,互联网分层架构的本质究竟是什么呢?

如果我们仔细思考会发现,不管是跨进程的分层架构,还是进程内的MVC分层,都是一个“数据移动”,然后“被处理”“被呈现”的过程,归根结底一句话:互联网分层架构,是一个数据移动,处理,呈现的过程,其中数据移动是整个过程的核心

 

如上图所示:

数据处理和呈现要CPU计算,CPU是固定不动的

  • db/service/web-server都部署在固定的集群上

  • 端上,不管是browser还是APP,也有固定的CPU处理

 

数据是移动的

  • 跨进程移动:数据从数据库和缓存里,转移到service层,到web-server层,到client层

  • 同进程移动:数据从model层,转移到control层,转移到view层

 

数据要移动,所以有两个东西很重要:

  • 数据传输的格式

  • 数据在各层次的形态

 

先看数据传输的格式,即协议很重要:

  • service与db/cache之间,二进制协议/文本协议是数据传输的载体

  • web-server与service之间,RPC的二进制协议是数据传输的载体

  • client和web-server之间,http协议是数据传输的载体

 

再看数据在各层次的形态,以用户数据为例:

  • db层,数据是以“行”为单位存在的row(uid, name, age)

  • cache层,数据是以kv的形式存在的kv(uid -> User)

  • service层,会把row或者kv转化为对程序友好的User对象

  • web-server层,会把对程序友好的User对象转化为对http友好的json对象

  • client层:最终端上拿到的是json对象

 

结论:互联网分层架构的本质,是数据的移动。

 

为什么要说这个,这将会引出“分层架构演进”的核心原则与方法:

  • 让上游更高效的获取与处理数据复用

  • 让下游能屏蔽数据的获取细节封装

 

弄清楚这个原则与方法,再加上一些经验积累,就能回答网友经常在评论中提出的这些问题了:

  • 是否需要引入DAO层,什么时机引入

  • 是否需要服务化,什么时机服务化

  • 是否需要抽取通用中台业务,什么时机抽取

  • 是否需要前后端分离,什么时机分离

(网友们的这些提问,其实很难回答。在不了解业务发展阶段,业务规模,数据量并发量的情况下,妄下YES或NO的结论,本身就是不负责任的。)

更具体的分层架构演进细节,下一篇和大家细究。

 

总结

  • 互联网分层架构的本质,是数据的移动

  • 互联网分层架构中,数据的传输格式(协议)与数据在各层次的形态很重要

  • 互联网分层架构演进的核心原则与方法:封装与复用

 

思考

哪一个系统的架构,不是“固定CPU,移动数据”而是“固定数据,移动CPU”呢?

Scan QR Code via WeChat
to follow Official Account


### 分层架构与微服务架构的区别、联系及使用场景 #### 一、分层架构概述 分层架构是一种传统的软件设计方法,通常将应用程序划分为多个逻辑层次,每一层负责处理特定的功能。常见的分层包括表示层(UI)、业务逻辑层(BLL)以及数据访问层(DAL)。这种架构的优点在于其清晰的职责划分和较低的技术复杂度[^2]。 - **特点**:各层之间通过接口通信,下一层仅向上一层暴露必要的功能。 - **优点**: - 易于理解和实现。 - 各层可以独立测试和维护。 - **缺点**: - 当系统规模增大时,可能导致性能瓶颈。 - 层间耦合可能增加系统的复杂性。 #### 二、微服务架构概述 微服务架构则强调将单一的应用程序分解为一组小型的服务,这些服务围绕具体的业务能力构建,并能够独立部署和扩展[^3]。 - **特点**:每个服务运行在其自己的进程中,与其他服务通过轻量级机制(通常是HTTP资源API)进行通信。 - **优点**: - 提高了模块化程度,便于团队并行开发。 - 支持按需扩展,优化资源利用效率。 - **缺点**: - 增加了分布式系统的复杂性,如网络延迟和服务间的协调问题。 - 需要额外的投资用于监控、日志记录和自动化运维工具。 #### 三、两者的区别 | 特性 | 分层架构 | 微服务架构 | |--------------------|-------------------------------------------|-----------------------------------------| | **粒度** | 整体应用被分割成几个大块 | 应用由许多细小且自治的服务组成 | | **部署方式** | 单独打包和部署 | 每个服务单独部署 | | **技术栈灵活性** | 所有层共享相同的技术栈 | 不同服务可以选择适合各自需求的技术 | | **数据库管理** | 共享同一数据库 | 每个服务拥有自己私有的数据库实例 | #### 四、两者之间的联系 尽管存在显著差异,但分层架构与微服务架构并非完全对立的概念。实际上,在某些情况下,微服务内部仍然会遵循某种形式的分层组织原则[^4]。例如,一个典型的微服务可能会包含控制器(Controller)、服务(Service)以及存储库(Repository),这本质上也是一种简化版的分层模型。 #### 五、适用场景分析 - **分层架构的最佳应用场景** - 对于中小型项目或初期阶段的产品原型来说,由于其简单明了的特点,非常适合快速迭代开发周期短的小型至中型企业信息系统[^1]。 - **微服务架构的理想用途范围** - 大型互联网公司面对海量并发请求时更倾向于采用这种方式来提升整体吞吐能力和用户体验质量;另外对于那些需要频繁更新发布新特性的领域也非常合适,比如电商平台、社交网络等动态性强的行业[^5]。 ```python # 示例代码展示了一个简单的分层架构中的调用流程 class DataAccessLayer: def fetch_data(self, id): pass class BusinessLogicLayer: dal = DataAccessLayer() def process_request(self, request_id): data = self.dal.fetch_data(request_id) processed_result = ... # Some processing logic here return processed_result def main(): bll_instance = BusinessLogicLayer() result = bll_instance.process_request(101) if __name__ == "__main__": main() ```
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值