设为首页 | 加入收藏
197_45px;
资讯中心
企业理念
Corporate Philosophy
您当前所在位置:首页>新闻中心>通知公告
爱奇艺广告平台的架构设计与演进之路
来源(广告买卖网)  作者(广告买卖网)  阅读()   时间(2018-11-9 8:43:34)

在同一台机器上部署多个服务,上游服务只请求本机的下游服务,服务之间使用 http 协议传输 protobuf 数据,每个机器都是一个完备的投放系统。

这个架构有很多的优点:结构清晰,运维简单,网络延迟最小化等。

当然也有一些缺点,同一台机器上可部署的服务数量是有限的,因而会限制架构的增长,多个模块混合部署不利于整体的性能优化,一个服务的异常会影响整个机器的服务质量;这个架构在微观上满足了单一服务的原则,但在宏观上还不是真正的微服务化,为了解决上面的一些问题,按照自然的演进我们必然走上微服务化这条路;我们从 16 年中开始进行微服务化的实践。

微服务化过程中我们也遇到了很多问题,分享一下我们的解决方法及效果:

1. 技术选型问题

RPC 选型,必须满足的条件是要支持 C++、protobuf 协议和异步编程模型。最初的可选项有 sofa-pbrpc、pbrpc 和 grpc,这三者中我们选中了 grpc,主要看中了它通用(多语言、多平台和支持代理)、流控、取消与超时等特性;在我们选定 grpc 之后不久百度开源了它的高性能 rpc 框架 brpc,相比之下 brpc 更具有优势:健全的文档,高性能,内置检测服务等非常多的特性;为此我们果断地抛弃了 grpc 和已经在上面投入的一些开发成本,快速地展开了 brpc 相关的基础功能开发和各服务的改造。

名字服务选型,排除了 zookeeper,etcd 等,最终选定的是 consul+consul template 这个组合,它很完美地支持了我们的业务需求;除服务注册与发现外,还有健康检查,服务列表本地备份,支持权重设置等功能,这些功能可以有效地减少团队成员的运维工作量,增强系统的可用性,成为服务的标准配置。

2. 运维成本增加

这是微服务化带来的问题之一,微服务化要做服务拆分,服务节点的类型和数量会增多,同时还要额外运维一些基础服务(譬如,名字服务的 Agency)。考虑到大部分运维工作都是同一个任务在多个机器上重复执行,这样的问题最适合交由机器来完成,所以我们的解决方案就是自动化运维。我们基于 Ansible 自研了一个可视化的自动运维系统。其实研发这个系统最初目的并不是为了支持微服务化,而是为了消除人工运维事故,因为人的状态是不稳定的(有时甚至是不靠谱的),所以希望由机器来替代人来完成重复的标准动作;后来随着微服务化的推进,这个系统很自然地就接管了相关的运维工作。现在这个系统完成了整个团队 90% 以上的运维工作量。

上篇:

下篇:

地址:兰州市城关区中山路一号佳润酒店20F      联系电话:0931-8831301
传真:0931-8831301      网址:www.huobanmedia.com
关注我们:
  • 100_100px;
  • 100_100px;
  • 100_100px;
Copyrights © 2018 版权所有 兰州伙伴广告传媒有限公司 陇ICP备09000722号 设计制作 宏点网络       甘公网安备 62010002000030号