前言
内容全部都为个人理解，不一定正确，如果你发现了文章中有存疑的地方或者你对某个地方有疑问，欢迎在评论区留言，大家一起学习。
前面完成了云计算应用实践3部分的笔记，这里对这3部分的笔记进行总结分析。
前情回顾
常见问题
在架构一中，我们给VPC的私有子网配置了一个NAT网关，然后一直就没去管它，那么我们这个NAT网关在整个架构中有什么作用？充当一个什么角色呢？
在AWS中其实就已经给出了相关的词条，解释了这个NAT网关的作用。公有 NAT 网关支持将私有子网中的实例连接到互联网，但会阻止它们接收来自互联网的未经请求的入站连接。您应将弹性 IP 地址与公有 NAT 网关关联在一起，然后将互联网网关附加到包含它的 VPC 中。所以简而言之，这个NAT网关的作用就是给我们VPC中私有子网访问互联网提供一个出口。这里面最常见的场景就是，在私有子网，我们的实例需要使用wget等命令下载某些互联网资源，但这些实例在内网中是无法去访问互联网的，我们也不可能为了下载这些资源就把整个私有子网连接到互联网网关中使其变成公有子网获得访问互联网的能力。这种情况下，给私有子网配置一个NAT网关就是最好的选择，让其流量能访问到互联网，而从互联网中是不能接触到这些私有子网中的实例，其只能访问到NAT，这就保证了私有子网中实例的安全。
在创建数据库时，可用性与持久性的部署选项中，我们选择的是--多可用区数据库实例，关于这个选项，官方文档是这样描述的：在多可用区数据库实例部署中，Amazon RDS 会自动在不同可用区中配置和维护一个同步备用副本。主数据库实例将跨可用区同步复制到备用副本，以提供数据冗余并在系统备份期间将延迟峰值降至最小。在计划内的系统维护期间，运行具有高可用性的数据库实例可以提高可用性。它还可以帮助您保护数据库，以防数据库实例发生故障和可用区中断。所以这个备用数据库实例是不支持读取工作负载的连接，我们的连接只能连接到主数据库上。至于上面问题关于控制台只有一个实例的现象，AWS也给出了回答。
在Web服务器的选择是我更推荐Linux，无论是稳定性、性能、还是成本Linux 都比 Windwos好。
为什么大部分软件行业的公司，都会把服务器部署在linux上面_请各位同学考虑一下,软件的服务器应该安装在企业还是厂商?理由是什么?-CSDN博客
而在众多的Linux映像中，我选择的是AWS发行的Amazon Linux 2023，因为使用的EC2就是AWS自家的产品，基于此，其发行的Linux版本无疑更适合。
这个问题是隔壁宿舍的一个小伙伴遇到的问题，他的web应用是一个使用session机制的登录组件。在他的实验EC2实例中是可以正常登录，但在使用负载均衡器访问Auto Scaling组创建的Web应用实例做这个登录操作就会一直重定向登录页。为什么呢？原因是这种基于session机制的登录不适用与这种场景。
我们都知道，在这种session机制的登录，是通过校验用户请求的Cookie来鉴权用户的操作，而我在实例一中签发的cookie，在实例二中是不存在的，而负载均衡器一般是以轮询机制决定请求流量的分发，那么，你这个登录的请求是在实例一种完成，实例一返回给你一个cookie，并且让你浏览器访问登录成功的页面，而浏览器接收到，继续请求负载均衡器登录成功的页面，这时候，基于轮询机制，你这个登录成功页的请求给到了实例二，但实例二中并没有这个cookie的session存在，那么它就会给负载均衡器返回没有相关权限，不允许访问这个登录成功的页面，并且让浏览器重定向回登录页。这就造成了一个循环，无论怎么登录，都会被重定向回登录页面。
那么有什么办法解决这个问题呢？有，使用Redis或者DynamoDB做登录会话的缓存，让登录实例共享会话缓存，都基于这个缓存做访问的鉴权。
这个问题是和上面那个问题一起出现的，原因是因为我们在创建Auto Scaling组的时候开启了基于ALB的弹性伸缩策略，什么意思呢？就是说这个Auto Scaling组会获取负载均衡器的请求情况，如果负载均衡器访问实例时，实例给负载均衡器返回了有异常的状态码，那么Auto Scaling组会以为实例出现了问题，是一个不健康的状态，就会终止实例并且重新启动一个新实例。而上面那个web应用的登录事件中由于负载均衡器的轮询，一直使用了无权限的cookie请求实例，导致实例一直给负载均衡器返回301状态码，就造成了Auto Scaling组以为实例不健康，不断刷新实例。
3 条评论
大佬大佬，请问一下为什么架构二中最后一步的目标组的两个目标都是不正常呢（404，求大佬指点
如果你得项目是Thymeleaf项目，那大概率是你项目中没有index.html文件，负载均衡访问web主页失败，报的404。如果还有问题可以加我微信：Sirhexs_404。博客可能回得没那么快。
已解决