美团面试：能不能画一下你们项目架构图？(文末福利)

柔光的暖阳◎ 2022-09-11 02:22 115阅读 0赞

大家好，我是田维常，十年码农给你分享后端开发技术，记得关注我。

我手里有500G后端技术学习资料，文章末尾有我的联系方式，备注“**资源**”。

**文末有福利，送给爱学习的你。**

前面分享11篇，关于2017年，我去上海美团面试遇到的技术问题。

[**美团面试：熟悉哪些JVM调优参数，幸好我准备过！**][JVM]

[美团面试：讲清楚MySQL结构体系，立马发offer][MySQL_offer]

[美团面试：慢SQL有遇到过吗？是怎么解决的？][SQL]

[美团面试：String s = new String("111")会创建几个对象？][String s _ new String_111]

[美团面试：为什么就能直接调用userMapper接口的方法？][userMapper]

[**美团面试：接口被恶意狂刷，怎么办？**][Link 1]

[**美团面试：MySQL中有哪些锁？当时我就懵逼了！**][MySQL]

[**美团面试：使用MySQL，你遇到过哪些坑？**][MySQL 1]

[**美团面试：请手写一个快排，被我怼了！**][Link 2]

**   **[**美团面试：说说MySQL存储引擎原理，幸好我准备过！**][MySQL 2]

** ** ** **[**美团面试：你了解JDK版本相关特性吗？结果令人尴尬！**][JDK]

其实，这个问题，我在面试中遇到过很多，没有具体答案，只能靠着自己的经验来吹NB。

如果没有经验怎么办？

**看文章，学习，再结合自己的项目，模仿着搞。**

## 前言 ##

我们以`Java Web` 为例，来搭建一个简单的电商系统，看看这个系统可以如何一步步演变。

该系统具备的功能：

*  用户模块：用户注册和管理
 *  商品模块：商品展示和管理
 *  交易模块：创建交易和管理

## 正文 ##

### 阶段一、单机构建网站 ###

网站的初期，我们经常会在单机上跑我们所有的程序和软件。此时我们使用一个容器，如Tomcat、Jetty、Jboss，然后直接使用`JSP/Servlet`技术，或者使用一些开源的框架如`Maven + Spring + Struts + Hibernate`、`Maven + Spring + Spring MVC + Mybatis`。最后再选择一个数据库管理系统来存储数据，如`MySQL`、`SqlServer`、`Oracle`，然后通过`JDBC`进行数据库的连接和操作。

把以上的所有软件包括数据库、应用程序都装载同一台机器上，应用跑起来了，也算是一个小系统了。此时系统结果如下：

![7e91669193ff89f6f0d1bdf6071590e8.png][]

### 阶段二、应用服务器与数据库分离 ###

随着网站的上线，访问量逐步上升，服务器的负载慢慢提高，在服务器还没有超载的时候，我们应该就要做好准备，提升网站的负载能力。假如我们**代码层面**已难以优化，在不提高单台机器的性能的情况下，采用**增加机器**是一个不错的方式，不仅可以有效地提高系统的负载能力，而且性价比高。

增加的机器用来做什么呢？此时我们可以把**数据库服务器**和**Web服务器**拆分开来，这样不仅提高了单台机器的负载能力，也提高了容灾能力。

应用服务器与数据库分开后的架构如下图所示：

![68ad49ec42d1ea3f69ca6f415d74063f.png][]

### 阶段三、应用服务器集群 ###

随着访问量继续增加，单台应用服务器已经无法满足需求了。在假设数据库服务器没有压力的情况下，我们可以把应用服务器从一台变成了**两台甚至多台**，把用户的请求分散到不同的服务器中，从而提高负载能力。而**多台应用服务器**之间没有直接的交互，他们都是依赖数据库各自对外提供服务。著名的做**故障切换**的软件有`KeepAlived`，`KeepAlived`是一个类似于Layer3、4、7交换机制的软件，他不是某个具体软件故障切换的专属品，而是可以适用于各种软件的一款产品。`KeepAlived`配合上`ipvsadm`又可以做**负载均衡**，可谓是神器。

我们以增加了一台应用服务器为例，增加后的系统结构图如下：

![c4a74672d7ac9608f8c7c9965153986e.png][]

系统演变到这里，将会出现下面**四个问题**：

*  用户的请求由谁来转发到到具体的应用服务器？
 *  有那些转发的算法和策略可以使用？
 *  应用服务器如何返回用户的请求？
 *  用户如果每次访问到的服务器不一样，那么如何维护session的一致性？

针对以上问题，常用的**解决方案**如下：

#### 1、负载均衡的问题 ####

一般以下有5种解决方案：

1.  HTTP重定向

> HTTP重定向就是应用层的请求转发。用户的请求其实已经到了HTTP重定向负载均衡服务器，服务器根据算法要求用户重定向，用户收到重定向请求后，再次请求真正的集群

*  优点：简单易用；
 *  缺点：性能较差。

1.  DNS域名解析负载均衡

> DNS域名解析负载均衡就是在用户请求DNS服务器，获取域名对应的IP地址时，DNS服务器直接给出负载均衡后的服务器IP。

*  优点：交给DNS，不用我们去维护负载均衡服务器；
 *  缺点：当一个应用服务器挂了，不能及时通知DNS，而且DNS负载均衡的控制权在域名服务商那里，网站无法做更多的改善和更强大的管理。

1.  反向代理服务器

> 在用户的请求到达反向代理服务器时（已经到达网站机房），由反向代理服务器根据算法转发到具体的服务器。常用的Apache，Nginx都可以充当反向代理服务器。

*  优点：部署简单；
 *  缺点：代理服务器可能成为性能的瓶颈，特别是一次上传大文件。

1.  IP层负载均衡

> 在请求到达负载均衡器后，负载均衡器通过修改请求的目的IP地址，从而实现请求的转发，做到负载均衡。

*  优点：性能更好；
 *  缺点：负载均衡器的宽带成为瓶颈。

1.  数据链路层负载均衡

> 在请求到达负载均衡器后，负载均衡器通过修改请求的MAC地址，从而做到负载均衡，与IP负载均衡不一样的是，当请求访问完服务器之后，直接返回客户。而无需再经过负载均衡器。

#### 2、集群调度转发算法 ####

1.  rr轮询调度算法

> 顾名思义，轮询分发请求。

*  优点：实现简单
 *  缺点：不考虑每台服务器的处理能力

1.  wrr加权调度算法

> 我们给每个服务器设置权值Weight，负载均衡调度器根据权值调度服务器，服务器被调用的次数跟权值成正比。

*  优点：考虑了服务器处理能力的不同

1.  sh原地址散列算法

> 提取用户IP，根据散列函数得出一个key，再根据静态映射表，查处对应的value，即目标服务器IP。过目标机器超负荷，则返回空。

*  优点：实现同一个用户访问同一个服务器。

1.  dh目标地址散列算法

> 原理同上，只是现在提取的是目标地址的IP来做哈希。

*  优点：实现同一个用户访问同一个服务器。

1.  lc最少连接算法

> 优先把请求转发给连接数少的服务器。

*  优点：使得集群中各个服务器的负载更加均匀。

1.  wlc加权最少连接算法

> 在lc的基础上，为每台服务器加上权值。算法为：（活动连接数 \* 256 + 非活动连接数） ÷ 权重，计算出来的值小的服务器优先被选择。

*  优点：可以根据服务器的能力分配请求。

1.  sed最短期望延迟算法

> 其实sed跟wlc类似，区别是不考虑非活动连接数。算法为：（活动连接数 +1 ) \* 256 ÷ 权重，同样计算出来的值小的服务器优先被选择。

1.  nq永不排队算法

> 改进的sed算法。我们想一下什么情况下才能“永不排队”，那就是服务器的连接数为0的时候，那么假如有服务器连接数为0，均衡器直接把请求转发给它，无需经过sed的计算。

1.  LBLC基于局部性最少连接算法

> 负载均衡器根据请求的目的IP地址，找出该IP地址最近被使用的服务器，把请求转发之。若该服务器超载，最采用最少连接数算法。

1.  LBLCR带复制的基于局部性最少连接算法

> 负载均衡器根据请求的目的IP地址，找出该IP地址最近使用的“服务器组”，注意，并不是具体某个服务器，然后采用最少连接数从该组中挑出具体的某台服务器出来，把请求转发之。若该服务器超载，那么根据最少连接数算法，在集群的非本服务器组的服务器中，找出一台服务器出来，加入本服务器组，然后把请求转发。

#### 3、集群请求返回模式问题 ####

1.  NAT

> 负载均衡器接收用户的请求，转发给具体服务器，服务器处理完请求返回给均衡器，均衡器再重新返回给用户。

1.  DR

> 负载均衡器接收用户的请求，转发给具体服务器，服务器出来玩请求后直接返回给用户。需要系统支持IP Tunneling协议，难以跨平台。

1.  TUN

> 同上，但无需IP Tunneling协议，跨平台性好，大部分系统都可以支持。

#### 4、集群Session一致性问题 ####

1.  Session Sticky

> Session sticky就是把同一个用户在某一个会话中的请求，都分配到固定的某一台服务器中，这样我们就不需要解决跨服务器的session问题了，常见的算法有ip\_hash算法，即上面提到的两种散列算法。

*  优点：实现简单；
 *  缺点：应用服务器重启则session消失。

1.  Session Replication

> Session replication就是在集群中复制session，使得每个服务器都保存有全部用户的session数据。

*  优点：减轻负载均衡服务器的压力，不需要要实现ip\_hasp算法来转发请求；
 *  缺点：复制时网络带宽开销大，访问量大的话Session占用内存大且浪费。

1.  Session数据集中存储

> Session数据集中存储就是利用数据库来存储session数据，实现了session和应用服务器的解耦。

*  优点：相比Session replication的方案，集群间对于宽带和内存的压力大幅减少；
 *  缺点：需要维护存储Session的数据库。

1.  Cookie Base

> Cookie base就是把Session存在Cookie中，由浏览器来告诉应用服务器我的session是什么，同样实现了session和应用服务器的解耦。

*  优点：实现简单，基本免维护。
 *  缺点：cookie长度限制，安全性低，带宽消耗。

值得一提的是：

*  Nginx目前支持的负载均衡算法有wrr、sh（支持一致性哈希）、fair（lc）。但Nginx作为均衡器的话，还可以一同作为静态资源服务器。
 *  Keepalived + ipvsadm比较强大，目前支持的算法有：rr、wrr、lc、wlc、lblc、sh、dh
 *  Keepalived支持集群模式有：NAT、DR、TUN
 *  Nginx本身并没有提供session同步的解决方案，而Apache则提供了session共享的支持。

解决了以上的问题之后，系统的结构如下：

![d3a5d4bf5d8bd1709ab3f69620311a5a.png][]

### 阶段四、数据库读写分离化 ###

上面我们总是假设数据库负载正常，但随着访问量的的提高，数据库的负载也在慢慢增大。那么可能有人马上就想到跟应用服务器一样，把数据库一份为二再负载均衡即可。

但对于数据库来说，并没有那么简单。假如我们简单的把数据库一分为二，然后对于数据库的请求，分别负载到A机器和B机器，那么显而易见会造成两台数据库数据不统一的问题。那么对于这种情况，我们可以先考虑使用**读写分离**和**主从复制**的方式。

读写分离后的系统结构如下：

![46f078cff1df7a6980691544aae0d90b.png][]

这个结构变化后也会带来两个问题：

*  主从数据库之间数据同步问题。
 *  应用对于数据源的选择问题。

解决方案：

*  使用MySQL自带的Master + Slave的方式实现**主从复制**。
 *  采用**第三方数据库中间件**，例如MyCat。MyCat是从Cobar发展而来的，而Cobar是阿里开源的数据库中间件，后来停止开发。MyCat是国内比较好的MySql开源数据库分库分表中间件。

### 阶段五、用搜索引擎缓解读库的压力 ###

数据库做读库的话，常常对**模糊查找**力不从心，即使做了读写分离，这个问题还未能解决。以我们所举的交易网站为例，发布的商品存储在数据库中，用户最常使用的功能就是查找商品，尤其是根据商品的标题来查找对应的商品。对于这种需求，一般我们都是通过like功能来实现的，但是这种方式的代价非常大，而且结果非常不准确。此时我们可以使用**搜索引擎**的**倒排索引**来完成。

> 搜索引擎具有的优点：它能够大大提高查询速度和搜索准确性。

#### 引入搜索引擎的开销 ####

*  带来大量的维护工作，我们需要自己实现索引的构建过程，设计全量/增加的构建方式来应对非实时与实时的查询需求。
 *  需要维护搜索引擎集群

> 搜索引擎并不能替代数据库，它解决了某些场景下的精准、快速、高效的“读”操作，是否引入搜索引擎，需要综合考虑整个系统的需求。

引入搜索引擎后的系统结构如下：

![406dcee7bfe099968ea210b644f9b040.png][]

### 阶段六、用缓存缓解读库的压力 ###

常用的缓存机制包括页面级缓存、应用数据缓存和数据库缓存。

#### 应用层和数据库层的缓存 ####

随着访问量的增加，逐渐出现了许多用户访问同一部分**热门内容**的情况，对于这些比较热门的内容，没必要每次都从数据库读取。我们可以使用**缓存技术**，例如可以使用Google的开源缓存技术Guava或者使用Memecahed作为**应用层**的缓存，也可以使用Redis作为**数据库层**的缓存。

> 另外，在某些场景下，关系型数据库并不是很适合，例如我想做一个“每日输入密码错误次数限制”的功能，思路大概是在用户登录时，如果登录错误，则记录下该用户的IP和错误次数，那么这个数据要放在哪里呢？假如放在内存中，那么显然会占用太大的内容；假如放在关系型数据库中，那么既要建立数据库表，还要简历对应的Java bean，还要写SQL等等。而分析一下我们要存储的数据，无非就是类似\{ip:errorNumber\}这样的key:value数据。对于这种数据，我们可以用NOSQL数据库来代替传统的关系型数据库。

#### 页面缓存 ####

除了数据缓存，还有页面缓存。比如使用HTML5的localstroage或者Cookie。除了页面缓存带来的性能提升外，对于并发访问且页面置换频率小的页面，应尽量使用页面静态化技术。

*  优点：减轻数据库的压力， 大幅度提高访问速度；
 *  缺点：需要维护缓存服务器，提高了编码的复杂性。

值得一提的是：

> 缓存集群的调度算法不同与上面提到的应用服务器和数据库。最好采用**一致性哈希算**，这样才能提高**命中率**。

加入缓存后的系统结构如下：

![a1e2852ff0c157490b4a3a62c47a44a5.png][]

### 阶段七、数据库水平拆分与垂直拆分 ###

我们的网站演进到现在，交易、商品、用户的数据都还在同一个数据库中。尽管采取了增加**缓存**和**读写分离**的方式，但随着数据库的压力继续增加，数据库数据量的**瓶颈**越来越突出，此时，我们可以有数据**垂直拆分**和**水平拆分**两种选择。

#### 数据垂直拆分 ####

垂直拆分的意思是把数据库中不同的业务数据拆分到不同的数据库中，结合现在的例子，就是把交易、商品、用户的数据分开。

优点：

*  解决了原来把所有业务放在一个数据库中的压力问题；
 *  可以根据业务的特点进行更多的优化。

缺点：

*  需要维护多个数据库的状态一致性和数据同步。

问题：

*  需要考虑原来跨业务的事务；
 *  跨数据库的Join。

解决问题方案：

*  应该在应用层尽量避免跨数据库的**分布式事务**，如果非要跨数据库，尽量在**代码**中控制。
 *  通过**第三方中间件**来解决，如上面提到的MyCat，MyCat提供了丰富的跨库Join方案，详情可参考MyCat官方文档。

数据垂直拆分后的结构如下：

![a2338f5d14e615ba9feba1f41088806f.png][]

#### 数据水平拆分 ####

数据**水平拆分**就是把同一个表中的数据拆分到**两个**甚至**多个**数据库中。产生数据水平拆分的原因是某个业务的**数据量**或者更新量到达了**单个数据库**的瓶颈，这时就可以把这个表拆分到两个或更多个数据库中。

优点：

*  如果能克服以上问题，那么我们将能够很好地对数据量及写入量增长的情况。

问题：

*  访问用户信息的应用系统需要解决SQL路由的问题，因为现在用户信息分在了两个数据库中，需要在进行数据操作时了解需要操作的数据在哪里。
 *  **主键** 的处理也变得不同，例如原来**自增字段**，现在不能简单地继续使用。
 *  如果需要**分页**查询，那就更加麻烦。

解决问题方案：

*  我们还是可以通过可以解决第三方中间件，如MyCat。MyCat可以通过SQL解析模块对我们的SQL进行解析，再根据我们的配置，把请求转发到具体的某个数据库。我们可以通过UUID保证唯一或自定义ID方案来解决。
 *  MyCat也提供了丰富的**分页查询方案**，比如先从每个数据库做分页查询，再合并数据做一次分页查询等等。

数据水平拆分后的结构如下：

![5971638e941128a1c334c0cc0daa4a50.png][]

### 阶段八、应用的拆分 ###

#### 按微服务拆分应用 ####

随着业务的发展，业务越来越多，应用越来越大。我们需要考虑如何避免让应用越来越臃肿。这就需要把应用拆开，从一个应用变为俩个甚至更多。还是以我们上面的例子，我们可以把用户、商品、交易拆分开。变成“用户、商品”和“用户，交易”两个子系统。

拆分后的结构：

![14c0382c3c5f4bff27de83083f6b9f10.png][]

问题：

> 这样拆分后，可能会有一些相同的代码，如用户相关的代码，商品和交易都需要用户信息，所以在两个系统中都保留差不多的操作用户信息的代码。如何保证这些代码可以复用是一个需要解决的问题。

解决问题：

> 通过走服务化SOA的路线来解决频繁公共的服务。

#### 走SOA服务化治理道路 ####

为了解决上面拆分应用后所出现的问题，我们把公共的服务拆分出来，形成一种服务化的模式，简称SOA。

采用服务化之后的系统结构：

![7a0d8be31295b4b5313eba3e764b23d4.png][]

优点：

*  相同的代码不会散落在不同的应用中了，这些实现放在了**各个服务中心**，使代码得到更好的维护。
 *  我们把对数据库的交互业务放在了各个服务中心，让前端的Web应用更注重与浏览器交互的工作。

问题：

> 如何进行远程的服务调用？

解决方法：

> 可以通过下面的引入消息中间件来解决。

### 阶段九、引入消息中间件 ###

随着网站的继续发展，的系统中可能出现**不同语言**开发的子模块和部署在不同平台的子系统。此时我们需要一个平台来传递可靠的，与平台和语言无关的数据，并且能够把**负载均衡透明化**，能在调用过程中**收集**并**分析**调用数据，推测出**网站的访问增长率**等等一系列需求，对于网站应该如何成长做出预测。开源消息中间件有阿里的`Dubbo`，可以搭配Google开源的分布式程序协调服务`Zookeeper`实现服务器的**注册**与**发现**。

引入消息中间件后的结构：

![4ae7383a23b42ed071d6eb33d6e73949.png][]

## 总结 ##

以上的演变过程只是一个例子，并不适合所有的网站，实际中网站演进过程与自身业务和不同遇到的问题有密切的关系，没有固定的模式。只有认真的分析和不断地探究，才能发现适合自己网站的架构。

**福利**

哈，差点忘记发福利了...

最近 SpringCloud alibaba 非常火热，同时为了感谢各位读者朋友的支持，决定送2本《Spring Cloud Alibab微服务实战》，本书从微服务基础理论开始，基于Spring Boot框架搭建微服务系统。介绍了使用Spring Cloud Alibaba套件及其他热门微服务组件构建微服务系统的方法、微服务系统中常见的问题及解决方案，以及如何快速部署项目，使读者从开发到上线整体流程有一个清晰的认识。

![7b1aa4a38c0479e753cadba7a4560c25.png][]

**参与方式**：进入公众号：后台回复“**老师好**”，即可参与。

当然，不差钱的朋友也可以直接通过下面的小程序直接购买。

????????～**再来求波在看呀～**????????

[JVM]: http://mp.weixin.qq.com/s?__biz=MzU4MDM3MDgyMA%3D%3D&chksm=fd557df9ca22f4efc57b8abeea251aa4e965c9b08af4428057d8062f8d60032c33f335679d39&idx=1&mid=2247505170&scene=21&sn=36ffb753df777d1b892163e07c22e312#wechat_redirect
[MySQL_offer]: http://mp.weixin.qq.com/s?__biz=MzU4MDM3MDgyMA%3D%3D&chksm=fd557ab0ca22f3a6754bdd71d976fd22bb3bc65e87f059c9a74f1db3e01f8fdff8d9844ac3e8&idx=1&mid=2247504475&scene=21&sn=11130bc937218b5e052c10cd8fa85a0c#wechat_redirect
[SQL]: http://mp.weixin.qq.com/s?__biz=MzU4MDM3MDgyMA%3D%3D&chksm=fd557949ca22f05fdf97feeb9f339951bfb62a592823578ae02b557d8f79022e6c02ab85aaab&idx=1&mid=2247504290&scene=21&sn=8431458c6d46bdccc8a91afd95f906de#wechat_redirect
[String s _ new String_111]: http://mp.weixin.qq.com/s?__biz=MzU4MDM3MDgyMA%3D%3D&chksm=fd554e7cca22c76a2c897360afa9e0c6f4ed7da42a571673158c2524cf46b2fea901163a474b&idx=1&mid=2247493271&scene=21&sn=f3c5bf9f67971ee6c9dacc0eb757b0e3#wechat_redirect
[userMapper]: http://mp.weixin.qq.com/s?__biz=MzU4MDM3MDgyMA%3D%3D&chksm=fd555a1dca22d30b64ae0760054523998b79277c5b6886813011504b7e717a8c29159223596f&idx=1&mid=2247496438&scene=21&sn=02020dac3415ac5d1887b88053d30ffb#wechat_redirect
[Link 1]: http://mp.weixin.qq.com/s?__biz=MzU4MDM3MDgyMA%3D%3D&chksm=fd557a94ca22f382326479915ee56139a95ac500a84f057544d8a279be42cfe468c29fd64638&idx=1&mid=2247504511&scene=21&sn=307daa44f37c3d55464e696f0423325d#wechat_redirect
[MySQL]: http://mp.weixin.qq.com/s?__biz=MzU4MDM3MDgyMA%3D%3D&chksm=fd557b5bca22f24d05c7add694d82f3e3598ed55c4ae4ba8fe133c2dd588da5c841c6f89d313&idx=1&mid=2247504816&scene=21&sn=527ed15852f11904728cb0da164bfa85#wechat_redirect
[MySQL 1]: http://mp.weixin.qq.com/s?__biz=MzU4MDM3MDgyMA%3D%3D&chksm=fd557d79ca22f46f643c98c5c4ac55292085a31545580c8f3ba8514aa0138f3391e6979d7ba3&idx=1&mid=2247505298&scene=21&sn=2c3551ca51dabd6943fcc53f66153676#wechat_redirect
[Link 2]: http://mp.weixin.qq.com/s?__biz=MzU4MDM3MDgyMA%3D%3D&chksm=fd557eddca22f7cb04e89e0ab32a303c43a32c1d38ffbbc529702f436b13bacfd901de5b4769&idx=1&mid=2247505462&scene=21&sn=58a19247ff95aadb47641f80caa5eda4#wechat_redirect
[MySQL 2]: http://mp.weixin.qq.com/s?__biz=MzU4MDM3MDgyMA%3D%3D&chksm=fd557e94ca22f7829c73f4f8903290e28875c6e305c3492528d5cbbd76752033660ffcdfcca2&idx=1&mid=2247505535&scene=21&sn=923d3e67149589110a3f292718cd248e#wechat_redirect
[JDK]: http://mp.weixin.qq.com/s?__biz=MzU4MDM3MDgyMA%3D%3D&chksm=fd557e2dca22f73bb372a16b75192a1429814027e40bfc8b60f5c78dca6e43afe1c6538c8045&idx=1&mid=2247505606&scene=21&sn=78754649ec0a67dcf059d4247a081a05#wechat_redirect
[7e91669193ff89f6f0d1bdf6071590e8.png]: /images/20220829/02752c590752445c88bf7e4925eb7b6f.png
[68ad49ec42d1ea3f69ca6f415d74063f.png]: /images/20220829/ef9885362cf8468f8919a2dba9e4338d.png
[c4a74672d7ac9608f8c7c9965153986e.png]: /images/20220829/c63a4d6e41e242adb3a8f661a3c8e7ac.png
[d3a5d4bf5d8bd1709ab3f69620311a5a.png]: /images/20220829/e0e4994ecc3748e1a4a819dd994da3c4.png
[46f078cff1df7a6980691544aae0d90b.png]: /images/20220829/14163281e155404a89a53bb31e9798dd.png
[406dcee7bfe099968ea210b644f9b040.png]: /images/20220829/18e41bda0c034d47aad9d0d4496dea16.png
[a1e2852ff0c157490b4a3a62c47a44a5.png]: /images/20220829/cfe49ac0c6154d4bb87c400c1f149b54.png
[a2338f5d14e615ba9feba1f41088806f.png]: /images/20220829/d34daec3ed8b44bbb615f26081b46709.png
[5971638e941128a1c334c0cc0daa4a50.png]: /images/20220829/fa47ee80b59d44dca3fccebf0eae1b6e.png
[14c0382c3c5f4bff27de83083f6b9f10.png]: /images/20220829/95fcbb4357464bbcbe4ece893a46802f.png
[7a0d8be31295b4b5313eba3e764b23d4.png]: /images/20220829/684b19a32f6641efa0c5d91db9604388.png
[4ae7383a23b42ed071d6eb33d6e73949.png]: /images/20220829/fdc1e0c509ff470b8d3b3f2dbf025215.png
[7b1aa4a38c0479e753cadba7a4560c25.png]: /images/20220829/d8e590f0836548499481e1658ac302cc.png