Skip to main content

美团JBOX环境治理工具开发

首先我简单介绍一下业务和架构,我们属于美团到店这个大组,到店本质上就是一个平台会去售卖门票,消费者也可以以定餐厅和酒店等等,这些所有的商品信息本质上都是第三方提供给美团的,美团只是负责展示在C端,然后促成交易,把交易信息返还给商家。我在的小组主要是负责直接和第三方对接的这个系统,我们的干的事情就是只有两件,一件就是把信息从第三方那里同步到美团这里,比如说把商品的信息从第三方那里接收处理,调用商品的服务去入库,第二件事情就是把美团内部完成的交易通过我们处理之后去调用第三方。

架构上就是两层,一个网关层,一个业务层,第三方会通过网关层再到业务最后到美团其他业务方,反之亦然。其中网关层分为三个部分,对接、调度、容错,其中对接又分为两层,一层是标准化对接,该层抽象了通用的逻辑标准化了流程,主要是需要对方来根据我们的标准来取实现对接,标准对接之上是KA对接,也就是大客户对接,这一部分的客户也有超过几百家,大都是大客户,是我们美团根据对方的标准去对接。

那我们这个项目其实针对的就是这个KA对接的部分。其中这个KA对接他又去使用了一个插件化的技术,主要是基于那个SpringContainer机制去做的框架,分为核心服务和插件服务,同时也集成了这种公司的devops工具来进行运维和管理,他主要是支持这个插件在不重启核心服务的情况下去卸载再部署和发布某一个插件,同时他也基于这个SET化去做了一个隔离,这样也可以去去区别不同业务的流量也可以去区别不同商家的流量,也可以为了一些资源利用率去做一些合并和部署,其中核心服务依然是去收敛一些共同的服务,插件服务依然是去实现一些商家的个性化服务,业务耦合比较轻,通用性比较强。

(1)这些插件是谁开发的

(2)这些插件为什么要去开发这个插件

vip对接,流量隔离,高效快速部署,沉淀通用能力

(3)你是怎么检测到线上有插件需要更新的呢

目前是轮询,能不能去监听代码的变动呢?

(4)每五分钟轮询,如果上一个部署超过五分钟了,但是5分钟后你又去部署了,这个再怎么解决?----应该用缓存

(5)你部署的时候,自动化要去跑(你们自动化什么时候去跑啊?),这个时候一定会部署失败的,你怎么去解决啊?

(6)有没有插件复用的情况呢?一个插件服务于商家A,又服务于插件B

(7)插件多了之后,会不会之间互相干扰------支持分业务、系统商接口维度set隔离+线程池隔离,且支持不同的set加载不同的系统商插件,降低业务/系统商之间的互相影响

(8)你所指的 平台到底是什么,你能描述一下吗

(9)商家平台网关,几对几的关系,你能描述一下吗(还是架构的问题)