3年从0到300万用户，我们怎样在高速发展中扩展云基础设施？( 三 ) ：3年从0到300万用户

为了实现解耦，我们会在一个新服务上创建事件，该服务通过向后端发送请求调用这些事件。事件只会存储它需要调用的函数、函数的参数以及它需要调用的时间。这里会有自己的数据库，当请求后端的时候，后端将会填充事件。

文章图片
将Redis和Celery移到单独的服务中
这会带来一个很明显的不足：那就是不能使用pickle ，因为请求是通过HTTP调用的。但是，鉴于Celery不推荐使用Pickle ，所以我们没有在代码中使用它。
https://docs.celeryproject.org/projects/kombu/en/stable/userguide/serialization.html#serializers
7重定向和缩短链接
短链接的重定向会在客户端应用中出现。转向纯客户端应用意味着服务器无法在某个连接上提供301响应，这是因为所有的请求都转到了S3的桶中。当某个重定向要从/x转向/y时，客户端侧的应用必须要向服务器检查/x ，并通过向DOM中添加一个额外的参数告知Prerenderer该页面需要进行重定向。为了确保Prerenderer能够注意到这一点，我们创建一个页面，该页面显示“重定向中，请稍候”并添加了这个额外的参数。
对于内部重定向来讲，这还是可行的，因为我们没有太多这样的场景。但是对于短链接来讲，这种方式就不理想了，因为我们想要用户直接看到这些短链接，不需要进行任何的等待，尤其是当我们需要重定向到Meddy外部时尤为如此。
解决方案
为了解决这一点，我们创建了两个Lambda函数，这两个函数会从一个包含hash和链接的Dynamo表中读取数据。其中一个Lambda函数用来生成短链接，另外一个函数则负责重定向短链接。
除此之外，针对这些URL ，我们使用API网关作为重定向Lambda函数的入口，并将其关联到一个新的域中。

文章图片
使用Lambda添加链接重定向
这种方式能够很好地运行， Lambda几乎没有提供任何维护和使用图表，我们的数据库中不需要维护一个持有这些重定向的大表。
8日志和监控
对更好日志的需求是相当迫切的。服务器请求数量的增加意味着我们不能再依赖于在文件系统中轮流切换日志文件，因为文件会轮转地非常快。除此之外，我们所使用的服务数量也在增长，从不同的文件系统拉取文件是一个噩梦。为所有的服务提供一个中心化的日志系统是一项挑战。
解决方案
我们决定使用GrafanaLoki构建一个服务实现日志和监控功能。 Loki是一个开源的、可水平伸缩的、支持多租户的日志管理聚合系统，其灵感来源于Prometheus 。而Grafana是一个开源的分析和交互式可视化软件。实际上，我们使用Loki作为日志聚合工具，使用Grafana可视化这些日志。
https://grafana.com/oss/loki/
这里的理念是让我们的不同服务推送日志到Loki服务所打开的一个HTTP端点上。 Loki将会对它们进行索引并以二进制格式存储到S3和DynamoDB表的索引中。这样的话，我们就能够在日志中查找特定的标记，比如特定的状态码和特定的日志级别。通过这种方式，我们也能查询日志，甚至对它们使用聚合功能，比如计算过去5分钟内具有特定标记的日志的数量。

文章图片
使用GrafanaLoki添加日志和监控
在事件监控方面，我们依然使用Grafana ，但是，这次它搭配的是AWSCloudWatch 。 Grafana作为CloudWatch的客户端，按需获取数据并对其进行可视化。
如上所述，为了将日志推送至Loki ，我们必须为不同的服务采用不同的技术，比如在应用服务器上构建处理程序、为数据转储添加Lambda函数。 Lambda函数用来解析来自S3的LoadBalancer和CloudFront日志，并将它们推送至Loki 。

文章图片
通过混合使用数据处理程序和CloudWatch ，我们就能够为基础设施中的所有内容构建一个中心化的日志和监控系统，我们可以在一个地方监控所有的东西。
9整体方案

文章图片
这可能是到目前为止我们最喜欢的文章，因为它这展示了我们在经历这些挑战时所带来的成长。最令人兴奋的是，对Meddy来说仅仅是一个开始。
原文链接：
https://medium.com/swlh/scaling-our-aws-infrastructure-9e64e6817b8c