Welcome to广告户外媒体-高速广告-高炮媒体广告-广西媒体网!

1996 8222228

联系我们

PRPULAR PUSH

ATTEN:
李丰
phone:
1996 8222228
QQ:
qin19968222228
ADD:
广西南宁青秀区仙葫蓉茉大道东城美景7栋602

河池广告发布系统

author:广告户外媒体-高速广告-高炮媒体广告-广西媒体网

【Font size: big medium smail

time:2020-04-07 16:42:22

本文由广西媒体吧/广西媒体网/高炮媒体网提供,重点介绍了广告发布系统相关内容。广西媒体吧/广西媒体网/高炮媒体网专业提供广告平台投放,高铁广告投放,影视广告制作公司等多项产品服务。公司秉承信誉至上、至诚至信、以信为本,力求服务好每一个客户。

广告发布系统经过之前几次重构,总算有了1.0版本的广告系统,之前的一些历程也被记录了下来

许怀远:广告系统成长记许怀远:广告系统重构 之 点位和素材cache许怀远:广告系统成长记(续)时隔半年,我们终于有了2.0版本,如果说1.0版本是从丑陋到演化到普通,那么2.0版本可以说开始有一些别致了。

2.0的最大的改进有两点,一是服务化,整个系统被分拆成十来个独立部署的子系统。二是异步化,所有的新系统都是异步的,不依赖多线程模型。

服务化服务注册与发现

目前这块儿手动处理,这是单个项目的架构,不是公司层面的基础设施,所以没有投入很多精力在里面,以简单实用为准。一个月都改不了一次,自动化也就没有很大的必要性了。我在每一台服务器上都安装了Nginx,并且用nginx监听了127.0.0.1:8888,作为所有服务的入口。配置大致如下所示。

server {

listen 127.0.0.1:8888;

server_name ad.local;

access_log off;

error_log /data/logs/nginx/local_error.log;

proxy_ignore_client_abort on;

location ^~ /service1/ {

proxy_pass ;

}

location ^~ /service2/ {

proxy_pass ;

}

keepalive_timeout 300s;

proxy_http_version 1.1;

proxy_set_header Connection "";

}

upstream service1 {

server 192.168.1.2:8080 max_fails=100 fail_timeout=30s slow_start=120s;

server 192.168.1.3:8080 max_fails=100 fail_timeout=30s slow_start=120s;

server 192.168.1.4:8080 max_fails=100 fail_timeout=30s slow_start=120s;

keepalive 100;

}

upstream service2 {

server 192.168.1.2:8088 max_fails=3 fail_timeout=30s slow_start=120s;

server 192.168.1.3:8088 max_fails=3 fail_timeout=30s slow_start=120s;

server 192.168.1.4:8088 max_fails=3 fail_timeout=30s slow_start=120s;

keepalive 100;

}如果有新注册的服务,那么依葫芦画瓢,增加service3就行了。所有的调用者,只要使用本机调用就行了,如 和

故障转移

有集群就必有失效,失效时把机器从集群中移除,恢复时再重新加入集群,这是很自然的策略。我们依旧使用nginx自带的failover机制,30秒内失败超过3次的调用,认为这台主机坏了,自动从集群中移除,30秒后尝试重试,如果仍然失败则再过30秒。

我自己动手给nginx打了补丁,增加了商业版才有的slow_start功能,当服务器重归集群时,降低它的权重,分配更少的流量给它,再逐步恢复它的权重。这么做是为了给JVM的JIT预留一些时间,等跑热了再当正常主机用。

流量分配

有时候需要做灰度发布,或者测试性能,需要把流量按照比例分配。很幸运,nginx早就支持按weight分配流量了。广告发布系统

服务监控

我写了个监控nginx error_log的cron任务,每隔5分钟就扫一下日志的最后1000行,如果过去5分钟内发生错误次数超过阈值,会自动发钉钉报警给我和几个运营同事。除了error_log,我还设置了一份slow_log,把超过一定时间的服务请求,记录下来。当然了,每个服务自身是有自己的log的,此处只是记录服务之间互相调用的基础设施层面的log。

限流和熔断

目前性能远超实际需求,即使3台服务器倒了2台,也扛得住。业务对限流和熔断暂时没有需求,这块儿目前没有实现。

异步化选型

JVM上的自然是vertx了,Kotlin的协程还没有release,不想冒险,回调就回调吧,七八层调用,还不算复杂,辅以CompletableFuture减少回调,并没有觉得难维护。PHP自然是Swoole 2.0了(最近刚升级到4.0),协程用的飞起。踩过的坑

Swoole底层设计问题,为每个请求准备一个数据库连接,导致偶尔会有几千个数据库连接,屡屡被dba发来贺电。最近swoole开发组解决了这个问题,灰度了一台上去,没问题下周可以全发了。异常导致CompletableFuture没有被完成,解决方式是抑制和抽样记录异常,再加上超时处理机制。vertx的web客户端,队列深度限制,如果不限制深度,在第三方出故障时,队列可能会挤压过大,导致JVM内存耗尽而崩溃,不管会不会遇到,都需要设置一个。总结至此,2.0在架构和设计上已经比较完善了,即使业务翻倍也无需调整,翻倍再翻倍的时候,加几台机器也搞定了,在流量达到现在10倍以前,基本就这样了。

因地制宜就好,没必要为了服务而服务,为了技术而技术。广告发布系统