360搜索基于微服务架构的技术平台--Thor

为什么要做Thor?

360搜索有多个团队,几百号人。每个团队各自有多个平台工具,但各团队各自为战,带来的问题是没有统一的开发、管理规范,不论是交接还是扩展,做的人都很痛苦。当老人离开,新人接手会掉入无尽的坑中

Thor的目标

重新定义工具&平台该如何优雅的开发和产生

简洁、快速地将现有的平台工具集成进来

以工厂化的思维,让平台能产生平台,不再为了同类需求造轮子

简略架构

架构简略图

从Web端发起请求到Gateway,Gateway做一系列校验和处理后请求底层微服务;底层微服务提供服务,再由Gateway 返回响应。

完整架构

完整架构图

这是完整的架构图,在thor中,每个服务都运行在Docker下,放在(Kubernetes)K8S集群中,对外暴露host:port,挂在最上层LVS(其实就是K8S提供的VIP)下,然后统一对外提供服务,这种方式大大提高了我们系统的可用性

web

web

Web端对前端提供HTTP RESTful API,这里的Auth 权限校验,实际也是一个微服务,放在这里是因为它主要在这里使用。我们也在这一层加上打点监控之类,用于统计PV、UV情况等。

gateway

gateway流程
ETCD作为元信息存储介质,它存储了Gateway的路由表等元信息。然后Gateway另外提供了一个admin作为元信息的后天管理系统,也就意味着,admin写,proxy读。

每个server就是一个运行中的DOCKER容器
多个微服务容器挂在一个Cluster下,对外提供服务,这里Cluster就是一个LVS的概念,一个Cluster可以视作一个微服务对外暴露的入口,但我们没有这样做,因为我们使用的K8S已经提供了统一对外的一个K8S-VIP(LVS),所以其实在Thor下,一个Cluster就只是挂了一个K8S-VIP(LVS),然后K8S-VIP(LVS)下才挂了多个Server。

proxy读取etcd流程

proxy读取etcd流程

proxy启动时,先从etcd获取路由表routetable加载到自身内存,当有请求到达时,直接从内存中查找对应转发规则,然后对底层微服务进行调用并将结果返回给上游。

proxy会watch住etcd服务,当etcd上路由表有更新时,则实时拉取更新,保证自身缓存的routetable为最新

结果

我们在Thor的架构下,完成了通用数据管理系统(通过界面配置,5分钟生成一个功能强大的CURD工具)、智能分析平台(承接90%的数据分析需求,不懂技术的小白用户也能轻松使用)、通用文件服务(为其他平台提供文件存取服务,解决各个平台各自为战的尴尬)、SSO+权限管理系统(单点登陆、配置化的访问权限控制)等多个系统。并接入了多个其他团队开发的平台和工具。

收益

覆盖了95%的内部平台工具

节省80% 人力

减少开发成本 40% 以上