-
系统架构是灵活的，根据需求的不同，不一定每一层的技术都需要使用。例如：一些简单的
CRM系统可能在产品初期并不需要K-V作为缓存；一些系统访问量不大，并且可能只有一台业务服务器存在，所以不需要运用负载均衡层。 -
业务系统间通信层并没有加入传统的
HTTP请求方式。这是因为HTTP请求-响应的延迟比较高，并且有很多次和正式请求无关的通信（这在下面的内容中会详细讲到）。所以，传统的HTTP请求方式并不适合在两个高负载系统之间使用，其更多的应用场景是各种客户端（WEB、IOS、Android等）->服务器端的请求调用。 -
我们把业务编码中常使用的缓存系统归入到数据存储层，是因为类似于
Redis这样的K-V存储系统，从本质上讲是一种键值数据库。为什么Redis会很快以至于可以作为缓存使用，我将在随后的文章中进行详细的描述。 -
还有一点需要注意的是，上面架构图中的每层之间实际上不存在绝对的联系（例如负载层一定会把请求转送的业务层，这样的必然性是不存在的），在通常情况下各层是可以跨越访问的。举例说明：如果
HTTP访问的是一张图片资源，负载层不会把请求送到业务层，而是直接到部署的分布式文件系统上寻找图片资源并返回。再比如运用LVS做Mysql负载时，负载层是直接和数据存储层进行合作。
image.png
image.png
网友评论