基于 serverless 的项目方案

目前基于 serverless 有两种比较有代表性的项目

1.基于 serverless 实现的活动接口方案

2.基于 lambda@edge 实现的 AB 测试方案

(由于代码强业务相关，以下不方便展示 code)

serverless 数据扒取维护方案

对于一些隐秘性不高的，业务逻辑相对较简单的，设计相对独立的需求，FE 可以不麻烦 BE ，基于 serverless 自己实现一套数据存储，请求，返回的方案，包括数据控制后台。

使用到的工具：

IP代理池，googlesheet，AWS 中的 dynamodb ， lambda 函数， apigateway 路由, cloudwatch 定时任务。

设计流程：

1.通过一些方式，获取到我们想要的数据

2.安装 google-spreadsheet 插件，根据使用文档，将我们的账号维护在代码请求里，方便我们在代码中可以请求到 googlesheet

3.通过 lambda 函数，将我们获取到的数据经过处理后写在 googlesheet

4.通过 lambda 函数，取我们的 googlesheet 数据写在 dynamodb （写在dynamodb的原因是，dynamodb有一些自己对于并发和超量的处理和控制，我们只要配置自动扩容即可）

5.通过 lambda 函数，取dynamodb的数据，返回给页面

6.通过 apigateway 将路由与 lambda函数关联起来，方便 FE 调用

7.通过 cloudwatch 配置一个定时任务，定时拉取更新 googlesheet 表和 dynamodb 的数据，完成数据更新

基本通过以上流程，我们可以自己实现一个可供运维人员手动维护，同时也是自动更新的一个数据展示工具，完成我们的业务需求。如果不是完整的业务，我们也可以使用 lambda + apigateway + dynamodb 的工具组合实现 FE 自己写接口自己调用，节省 BE 成本。（就是要注意成本问题，使用 AWS 的资源要控制成本）

AB Test 方案

我们自己的服务使用分别使用了 nginx 代理和 cdn 缓存。

介绍一下 nginx

Nginx 使用来做什么的？

1.静态HTTP服务器

Nginx是一个HTTP服务器，可以将服务器上的静态文件（如HTML、图片）通过HTTP协议展现给客户端。

server {
listen80; # 端口号
location / {
root /usr/share/nginx/html; # 静态文件路径
}}

2.反向代理服务器

客户端本来可以直接通过HTTP协议访问某网站应用服务器，网站管理员可以在中间加上一个Nginx，客户端请求Nginx，Nginx请求应用服务器，然后将结果返回给客户端，此时Nginx就是反向代理服务器。

server {
listen80;
location / {
proxy_pass http://192.168.20.1:8080; # 应用服务器HTTP地址
}
}

3.负载均衡

当网站访问量非常大，网站站长开心赚钱的同时，也摊上事儿了。因为网站越来越慢，一台服务器已经不够用了。于是将同一个应用部署在多台服务器上，将大量用户的请求分配给多台机器处理。同时带来的好处是，其中一台服务器万一挂了，只要还有其他服务器正常运行，就不会影响用户使用。

upstream myapp {
server192.168.20.1:8080; # 应用服务器1
server192.168.20.2:8080; # 应用服务器2
}
server {
listen80;
location / {
proxy_pass http://myapp;
}
}

以上配置会将请求轮询分配到应用服务器，也就是一个客户端的多次请求，有可能会由多台不同的服务器处理。可以通过ip-hash的方式，根据客户端ip地址的hash值将请求分配给固定的某一个服务器处理。

upstream myapp {
ip_hash; # 根据客户端IP地址Hash值将请求分配给固定的一个服务器处理
server192.168.20.1:8080;
server192.168.20.2:8080;
}

另外，服务器的硬件配置可能有好有差，想把大部分请求分配给好的服务器，把少量请求分配给差的服务器，可以通过weight来控制。

upstream myapp {
server192.168.20.1:8080weight=3; # 该服务器处理3/4请求
server192.168.20.2:8080; # weight默认为1，该服务器处理1/4请求
}

4.网关

nginx 可以作为网关，对不同情况的访问打到提供不同页面的服务器

 location ~ ^/(($|ar|es|pt|en)/)?downloading/?$ {
        if ($COOKIE_stExp){
            return 'https://www.baidu.com';
        }
        return 'https://myApp';
     }

介绍一下 cdn

CDN的基本原理是广泛采用各种缓存服务器，将这些缓存服务器分布到用户访问相对集中的地区或网络中，在用户访问网站时，利用全局负载技术将用户的访问指向距离最近的工作正常的缓存服务器上，由缓存服务器直接响应用户请求。

基本功能

(1)节省骨干网带宽，减少带宽需求量；

(2)提供服务器端加速，解决由于用户访问量大造成的服务器过载问题；

(3)服务商能使用Web Cache技术在本地缓存用户访问过的Web页面和对象，实现相同对象的访问无须占用主干的出口带宽，并提高用户访问因特网页面的相应时间的需求；

(4)能克服网站分布不均的问题，并且能降低网站自身建设和维护成本；

(5)降低“通信风暴”的影响，提高网络访问的稳定性。

主要特点

1、本地Cache加速：提高了企业站点（尤其含有大量图片和静态页面站点）的访问速度，并大大提高以上性质站点的稳定性。

2、镜像服务：消除了不同运营商之间互联的瓶颈造成的影响，实现了跨运营商的网络加速，保证不同网络中的用户都能得到良好的访问质量。

3、远程加速：远程访问用户根据DNS负载均衡技术智能自动选择Cache服务器，选择最快的Cache服务器，加快远程访问的速度。

4、带宽优化：自动生成服务器的远程Mirror（镜像）cache服务器，远程用户访问时从cache服务器上读取数据，减少远程访问的带宽、分担网络流量、减轻原站点WEB服务器负载等功能。

5、集群抗攻击：广泛分布的CDN节点加上节点之间的智能冗余机制，可以有效地预防黑客入侵以及降低各种D.D.o.S攻击对网站的影响，同时保证较好的服务质量

AB 策略

由于我们采用了 cdn 方案提升我们的响应速度，因此无法在代码中计算一个随机数来对流量进行分发，因为命中缓存的比例是不同的。

但是 AWS 提供了一个 lambda@edge 方法，可以在我们发送请求的时候调用这个方法，我们可以利用这个方法达到均分流量的目的。

介绍一下请求流程

流量 -> CDN -> Nginx -> 服务器 -> Nginx -> CDN -> 用户 在这几个过程中，我们可以通过 lambda@edge 插入方法控制四个过程，分别为

1.查看器请求对应 CDN -> Nginx 2.源请求对应 Nginx -> 服务器 3.源响应对应服务器 -> Nginx 4.查看器响应对应 Nginx -> CDN

所以我们的做法是，通过在查看器请求过程中绑定一个 lambda@edge 函数，对我们想控制的流量在这里做一个流量的切分，并且对切分出的流量传送不同的 cookie 值，我们在 nginx 和代码中都是可以获取到这里附加的 cookie 值的，这样我们根据判断不同的 cookie 就可以做不同的页面处理了。

这里也有两种方案，分别是在代码里判断和在 nginx 层判断不同 cookie 后返回不同的源。我们的做法是快速响应验证的需求在代码里完成，结论稳定后在 nginx 层做返回源的控制。

基于 serverless 的 AB 方案