某零售云技术的互联网架构发展演进之路讲解

最新推荐文章于 2024-07-04 00:09:48 发布

ysfshine

最新推荐文章于 2024-07-04 00:09:48 发布

阅读量183

点赞数

分类专栏：个人日志

本文链接：https://blog.csdn.net/ysfshine/article/details/88080500

版权

个人日志专栏收录该内容

7 篇文章 0 订阅

订阅专栏

互联网产品的发展速度是很快的，若发展速度增快技术跟不上，是影响业务的发展和用户的体现。

今天我们以电商为例讲解决下分布式的技术架构的演进

1.一开始我们搭建一个初始版本的系统或在市场买一个系统，他们的架构或许是这样的如下图

一个机器部署一个tomcat和一个数据库。tomcat容器下部署所有的业务。由于你的业务发展的很好，用户量访问比较多。当某一天发现访问界面非常慢，可能会发生卡死的情况。由于我们会自己对架构进行调整，若不调整你的老板很快找到你。让你提出架构方案，若心里没有准备那么在老板眼里你就......

于是我们提出加一台机器做数据库分离开，分离后成为应用服务器和数据库服务器，如下图

刚刚拆分完没几天，发现流量又支持不住了，那么还是同样方法加一个机器，那么这次加的是应用服务器，把应用服务器搭建成一个集群，集群可以平滑对应用扩展，避免开发成本和开发速度两次都是采用加机器的方式来解决访问速度慢的问题。

刚做了集群后遇到一个问题，那就是一个用户发起两次请求时发现总是让提示登录，这样是体现不好的。是因为HTTP是无状态的我们通过用户本地（cookie+sessionid）方式保存会话。服务器以（sessionid，Object）的方式保存用户信息，若用户与服务器匹配成功，则允许访问否则会提示登录。若用户禁止cookie，则采用url请求带sessionId的方式。

那么集群是多个服务器，那么一个会话请求多个服务器会认识是两次会话。会造成总是提示登录问题。由于我们需要解决共享Session的问题，在用户每次请求时都会请求session服务器，判断用户的请求是否有效。

于是我们可以采用硬负载或软负载，搭建的集群架构引入硬负载或软负载如下

当用户越来越多，我们的界面能够抗的住，但发现我们数据库是个瓶颈，那我们会拆分数据库，添加一台数据库。那么我们可以做主备方案/主从方案，写操作放到写库中，读操作放到读库中，通过主备方案进行数据同步。

在互联网的产品场景下，搜索功能比较多，数据库搜索在当前场景下已经不满足要求。于是我们引入搜索引擎来解决检索问题。因为搜索引擎的数据是由数据库来，那么我们又有一些问题，如哪些数据是采用全量搜索，哪些数据采用增量数据。是采用同步同步还是异步同步等等问题，这里在不同场景所要关注的问题。

对于搜索还需要对搜索词进行分词、语义、sku进行处理等在这里是比较复杂的一个技术。

根据用户的请求越来越多，为了增加高访问量我们采用通过热点数据加入缓存处理。缓存可以对页面缓存、数据缓存。

对于缓存我们后面讲解决加入缓存后对缓存的存储、缓存雪崩、缓存击穿、布隆过滤器、缓存持久化，还有在使用缓存时如何对缓存和数据库之间的数据同步。

大多我们是把缓存是应用服务器和数据库之间，在应用服务器访问时优先访问缓存，若缓存不存在时在访问数据库，这样减少对数据库IO的访问。当修改时先修改数据库在修改缓存或先修改缓存在修改数据库的方式。那么对造成两边数据一致性问题，这些是引入缓存所带来的一些问题，当然引入后带来的性能也是非常大的。

网站大了用户量大了，对于数据量和IO也会非常大。所以我们在数据库层次上，会考虑到对数据库按照业务维度进行垂直分库

拆分以后我们每一个DB都是独立的，用户模块的应用访问用户的数据库，商品模块访问数据库。这样的好处有两种一种是对数据隔离，一种是对每个Db进行独立部署。可以利用多个计算资源来完成整合操作。通过垂直拆分可以解决对IO问题和访问量大的问题。

如果访问量还是很大，那么就会存在大表的情况。这种情况我们是采用水平拆分，水平拆分的规则是对于大数据表（100W条或1000W条以上的表），拆成每个表100W或1000W的小表。拆成小表了，那么在SQL检索时的性能会更大。这就是通过拆分所带来的好处。水平拆分又分为分库分表或分区分表，我们应该采用哪种方式也是我们要考虑的问题。