AWS全称Amazon Web Service，和Amazon的关系就像阿里云和淘宝的关系。大家都是电商起家，一个卖书，一个为商家提供线上商铺。做着做着，用户越来越多，业务需求越来越复杂，要求也越来越苛刻，面对的技术挑战随之越来越大。比如巨大的流量会在促销活动时，一股脑儿涌过来。用户遍布在世界各地，如何给不同区域的用户提供良好的用户体验。如何按照需求动态的调整服务器的配备，避免浪费，等等。这些统统都是他们自己面对过的问题。然后这些聪明的工程师们想到了办法，并完美的解决了这些问题。这是起源。

在软件领域，大家面对的业务场景多多少少都会不太一样，但技术方案大部分却是类似的。如何让这些沉淀下来的技术经验发挥更大的价值，而这一部分的需求又是如此的大，“歪打正着”。这是AWS们的由来。

按照二八定律，和Amazon有同样高要求的服务毕竟是少数，绝大多数的服务并没有那么复杂的应用场景。今天我们就来看一看用AWS，如何满足大部分Web服务对基础设施的需求：

• 自定义域名，默认HTTPS
• 为用户提供稳定可靠的服务，七层负载均衡
• 服务可以按需拓展，水平拓展
• 保证服务的安全性，公有服务和私有服务的隔离和交互

自定义域名，默认HTTPS

互联网联接了世界，而域名则是这世界的入口。拿sunwei.xyz举例，用AWS的服务支持，如下所示：

DNS

1. 浏览器输入https://sunwei.xyz
2. DNS解析器将域名发送给DNS根name server，进行查询
3. DNS根name server会告诉DNS解析器，根据该域名的特点，更多详细信息请找.xyz TLD(Top-level Domain) name server查询
4. DNS解析器将域名查询请求再次发给.xyz TLD
5. TLD name server查询后告知现在sunwei.xyz由AWS Route53提供解析服务。当然，这里需要我提前配置好。
6. DNS解析器将服务再次发给AWS的Route53 name server进行查询
7. Route53根据当前用户的的流量政策(Traffic Policies)进行流量分发，如上图所示最终返回的是37.68.44.56。这里也可以理解为第四层，也就是网络层负载均衡。顺带介绍一下常见的几种策略：
1. 延迟策略(Latency-based) -- 根据区域最短延迟，响应用户请求
2. 地理策略(Geo DNS) -- 根据用户地理位置，进行路由
3. 失败策略(DNS failover) -- 将用户请求路由到可正常响应的服务器，避免失败
4. 轮询策略(Weighted round-robin load balancing) -- 将用户请求，以轮询的方式，依次分发给不同的服务器
8. 浏览器查询到服务ip地址，准备获取内容
9. 当请求抵达服务器时，这里用的是AWS ALB(Application Load Balance)，应用程序负责均衡服务会将请求分发给对应的服务
10. 最终根据http请求，返回对应的内容

如果要支持HTTPS？根据 ，HTTPS属于应用层，Route53只是负责网络层，自然对应的服务不应该Route53，而是ALB。AWS有提供Certificate Manager服务提供免费的证书，也可以参考 这篇文章来进行更直观的理解。毕竟知其然，并知其所以然才能做计算机的好朋友嘛。

为用户提供稳定可靠的服务，七层负载均衡

ALB

根据上图，我们看到了针对sunwei.xyz的服务分布。可以看出：

• 有两台ALB，第一台管理了2个服务，第二台管理了8个服务，根据策略，我们可以对流量按不同的策略进行分发：1，50/50，分别分发给这两台ALB。2，20/80，与实际情况做相应的匹配。
• 两台ALB的服务分别在两个不同的空间中，如图，一个是Zone A，一个是Zone B。这样做的好处就是鸡蛋不要放在一个篮子里。

那么ALB是如何做到精准投递的呢？

• Listener(监听者)：是主要的流量管理对象，可以配置多条转发规则，如通过路径配置，请求https://sunwei.xyz/orders到达时，根据多条rule的优先级按序匹配，如path相匹配/orders，优先级为1，优先处理，响应动作(action)为转发(forward)，这时就会将请求按转发规则转发出去
• Target Group(目标群组)：根据服务的特性，划分群组，方便转发时定位服务。通常需要指定health check(健康检查)，会根据服务的健康情况，来决定服务是否可达。还需要定义service protocol(服务协议，本例为http)和container port(容器端口) - 这里用容器化ECS为例，这是外部访问服务的基础

服务可以按需拓展，水平拓展

流量已经清晰的知道从哪儿来到哪儿去了，那么接下来就是服务的可靠性，我们可以按需来配置拓展规则：

Scalling Group(可拓展群组)：

• Capability(能力): 可以指定最大，最小的服务器数量。数量越多，可承载的流量就越大。
• Policy(政策): 可以更加明确不同情况下服务器是新启还是关停；在服务启动的过程中多长时间不受政策的干扰，也就是冷静时长，以避免陷入正在准备，一直响应政策的死循环
• Alarm(预警): 当碰到了以下的实际预警时，需要能采取措施，消除预警。光预警，没有行动是没有意义的。比如当cpu的使用量到达一定值时，需要采取行动

保证服务的安全性，公有服务和私有服务的隔离和交互

可以看到服务的可靠性已经得到了保证，那服务的安全性呢？哪些服务因该是公有可访问的，而哪些服务是不因该被暴露到公网的？

入网：

• 公网流量，首先经过Internet Gateway，经过路由器Router的转换，通过EIP(Elastic IP)访问
• 公网流量不能直接访问私有子网(Private Subnet)里的服务

出网：

• 公有子网(public subnet)，直接通过路由器Router，通过Internet Gateway访问外网
• 私有子网(private subnet)，不能直接访问外网，需要通过路由器Router，将自己请求投递到NAT gateway(网络地址转换网关)，再像公有子网的服务一样，通过路由器，经Internet Gateway发出

以上流程还有一个专有的名词，叫VPC(Virtual Private Cloud - 虚拟私有云)，是AWS用来协调管理网络的通用组件。

可以看出AWS提供了所有我们需要的网络服务，来满足我们的需求。如何管理好这些服务将会是另一个话题，如AWS推出的CloudFormation，我们可以通过这个服务，很方便的对这些基础设施进行管理，就像现在DevOps所推崇的IaC - Infrastructure as code(基础设施即代码)。

待续

閱讀更多 仲謀說 的文章

關鍵字: DNS 淘宝网 服务