360搜索在微服务架构下的技术平台实践（三） -- Thor

为什么要做Thor？

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

Thor的目标

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

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

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

简略架构

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

完整架构

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

web

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

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获取路由表routetable加载到自身内存，当有请求到达时，直接从内存中查找对应转发规则，然后对底层微服务进行调用并将结果返回给上游。

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

结果

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

收益

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

节省80% 人力

减少开发成本 40% 以上