1. 用户层

架构的前端是用户层，用户可以使用手中的任何联网设备访问相应的服务，并获得相应的结果。

设备很多，大致可以分为以下几类：

APP(安卓/IOS)H5(移动)WEB(PC)在这一层，有一个离用户非常近的互联网服务组件，应用非常广泛，甚至在一些业务场景中也是如此。它就是CDN (Content Distribution Network)，主要用来存储一些静态资源，比如静态页面、静态图片等等。存储在CDN中的数据往往来自各个应用后台管理终端的数据更新推送。

严重依赖CDN的场景业务是尖峰活动。当高峰开始时，大量用户涌入服务。如果在服务集群中放置任何资源，不经常变化的静态资源往往会占用整个网络带宽的大部分，这将会给网关带来很大的接入压力。因此，许多公司会在活动开始前将静态资源推送到离用户最近的CDN节点。

主要的好处是：

加快静态资源访问和页面加载降低服务网关访问压力

2. 服务接入层

服务接入层是整个后台服务的前端，这一层往往有几个最重要的保护组件：保护墙、DDoS保护组件、SLB和流量防控组件。

防火墙、DDoS:主要用于屏蔽异常访问和攻击。

SLB:主要用于负载均衡下一个集群的访问请求。往往后台服务会部署在很多地方，接入也可以分布到不同的国家、城市、地区和这一层的机房。

流量防控组件：主要用于为网关设置一层保险。当整个请求流量达到一定阈值时，会直接阻塞冗余请求，避免后续服务崩溃，整个服务瘫痪。这里的阈值可以动态设置和调整。

3. 业务网关层

从业务接入层收到的请求分发到所有机房后，到达业务网关层。在这一层中，它通常具有以下特征：

权限检查(认证用户登录ID、加密参数等。)接口级请求转发(因为这是网络的第七层)，如果多个子业务数据参与分发到每个子业务，可以进行数据聚合和限流(IP级、用户级)融合监控。对于每个子服务来说，找出这一层的存在是非常重要的，如果没有这一层，可能会有一个耦合度非常高的巨大的单个服务。每个模块的代码都在一个代码仓库里，维护成本很高，容易出现问题，对以后的业务拓展来说会是一场灾难(笔者亲身体验过，所有代码都在一起，每个人都可以随意修改，真的是“牵一发而动全身”，线上的每个小功能都战战兢兢)。

4. 子服务层

通过服务网关的接口请求转发到达各个子服务层。在这一层中，每个子服务通常是单独部署的，有不同的机房和专用集群。每个子服务只实现功能模块的单一功能。在这一层中，它通常具有以下特征：

单一服务注册功能外部服务接口(http接口、rpc接口)通过mq或直接rpc/http与第三方交互发布。简单的子服务层许多公司经常使用带有特殊封装的rpc框架进行业务开发。然而，同样重要的是要注意，子服务的维度也非常重要。稍有不慎，可能导致子服务数量巨大，增加维护成本。

00-1010层主要提供数据存储支持，是整个服务架构的倒数第二层，位于数据库层之前。它存储的数据本质上不同于数据库中存储的数据。

这一层的组件都是大公司开发的，其他公司基本都使用云厂商提供的相应服务。

缓存：最常用的是基于内存的kv存储组件，如Redis和Memcache。

MQ:消息队列，主要有三个目的。

异步解耦流量调峰OSS:对象存储服务，一般是海量小文件存储。

在这一层中，它通常具有以下特征：

存储临时数据并发性高，对应数据快

5. 缓存/MQ/OSS存储层

。该层位于整个服务架构的底层，也称为持久层，用于在地面存储持久数据。最常用的是MySQL和其他数据库。

在这一层，它有以下特点：

一般来说，需要支持事务(独立事务、分布式事务)。数据丢盘(存储在断电后不会丢失数据的磁盘上，常用硬盘：机械硬盘和固态硬盘)响应速度较慢(由于需要I/O操作和硬盘的结构，响应速度会比其他组件慢)。稍有不慎就可能导致整个服务的崩溃。

6. DB数据库层

层基本嵌入上层，一般用于收集服务。

监控：

包括服务器硬件、系统

统监控以及业务监控一般各层业务之中会有封装好的监控API监控数据一般通过异步的方式投递到某些集群之中

日志：

常指业务日志链路追踪日志日志数据一般异步投递到某些集群之中

监控以及日志往往会用在检测整个服务健康度的功能之中，常用的组件是ELK技术栈。

这一层也至关重要，因为只有及时地看到各个服务的健康状态，才能对服务进行调整，以使整个服务健康的运行。

总结

至此，基于文章中一副简单的架构图，本文简单阐述了整个架构的构成以及每层的作用、所使用的组件。

在实际的开发过程之中，需要考虑的因素会更多，也需要相关的人员掌握更多的知识，相对来说对技能要求也是比较高的。

掌握架构同时又是比较重要的，因为只有了解了整个架构各个模块的交互，才能称之为熟悉业务。一般在新员工入职一家公司的时候，都是需要花时间对架构进行一次全面梳理的。正所谓：知己知彼百战百胜。