加入收藏 | 设为首页 | 会员中心 | 我要投稿 核心网 (https://www.hxwgxz.com/)- 科技、建站、经验、云计算、5G、大数据,站长网!
当前位置: 首页 > 建站 > 正文

京东服务市场高并发下SOA服务化演进架构

发布时间:2019-03-19 07:29:36 所属栏目:建站 来源:张俊卿
导读:京东服务市场是京东商家与第三方独立软件提供商(ISV)进行服务类的在线交易平台。作为京东生态圈重要的一环,伴随着整个京东的快速增长,也在快速的发展。随着服务市场访问、交易量指数级的增长,系统由原来的ALL IN ONE架构,快速的演进成为SOA架构。 木桶
副标题[/!--empirenews.page--]

京东服务市场是京东商家与第三方独立软件提供商(ISV)进行服务类的在线交易平台。作为京东生态圈重要的一环,伴随着整个京东的快速增长,也在快速的发展。随着服务市场访问、交易量指数级的增长,系统由原来的ALL IN ONE架构,快速的演进成为SOA架构。

木桶的容量由木桶最短的木板决定,高并发环境下,单个服务的性能决定了整个服务市场的性能。 “可用插件列表服务”是服务市场的核心服务之一,优化该服务性能的过程,带动整个服务市场服务架构的演进。

宏观的看,大到系统小到模块都由自身+外部依赖组成,性能优化主要从自身与外部依赖两个方面来进行。

一、优化自身

单线程到多线程的升级,尝试通过并行提高服务性能。

SOA服务化

根据日志分析,整体调用中“服务详细信息”占用时间最多,并行虽然压缩了一些可并行服务的调用时间,但对于无法并行的“服务详细信息”环节,依然没有改善。要改善必须找到“商品服务”性能不高的原因。

可见自身优化能起一些作用,但外部依赖起着更决定性的作用。

二、解决外部依赖冲突

“商品服务”性能不高,这是为什么呢?先从“商品服务”的依赖开始分析。单独调用该服务,或压测该服务,性能都不差,但为何线上性能却不佳?

1. 不同服务外部依赖资源冲突

对“商品服务”依赖的资源进行梳理,发现“商品服务”与“类目服务”使用相同数据库资源,非调用高峰期资源足够不相互影响,大并发环境下两个服务开始争夺资源。

将依赖资源分开,不同的服务使用不同的资源,通过调用不同的数据源解决冲突。

2. 相同服务外部资源依赖冲突

解决了两个服务对数据库资源的依赖冲突,性能有所提高,但性能总有很大的波动,排除其他服务外部资源的依赖冲突,看看“商品服务”自身对资源是如何使用的。

“商品服务”所有功能都单一的依赖数据库资源。服务上线后,自身多个功能开始争抢数据库资源。

按使用场景进行外部依赖资源解耦:

  • 为保证交易一致性,继续采用MySQL。MySQL的 INNODB引擎长于 OLTP 在线事务处理,为了保证数据强一致性的场景继续选择使用MySQL数据库。
  • 客户端登录用户需要获得最新的数据反馈,且有PIN这个固定的维度。查询条件简单,能符合KEY-VALUE方式,Redis很适合这个场景。
  • 大前端非登录状态下,访问的用户无须登录,有很大的访问量,更多的是获取服务的一些介绍。大数据量,可容忍一定程度的延迟,所以采用ES来进行查询支撑。
  • 外部系统希望获得最新服务的变化,推的方式远强于轮训拉取的方式。通过MQ订阅服务的变化情况。
  • 有复杂计算,但对实时性要求不高,服务统计分析系统通过大数据平台获取数据进行分析。

三、建立统一的内存缓存模型

计算机的世界里没有魔法,时间换空间、空间换时间是所有方案的基础。

参考常用的MySQL INNODB引擎,,为加快查询速度会在内存中设置一块内存作为缓冲区,将查询结果从硬盘中加载到缓冲区,下次相同的查询直接使用缓冲区数据。同样的,如果要提高查询响应速度,必须把服务数据缓存到内存中。单机内存有限,无法容纳所有数据,且服务器重启时整个内存重建所耗费的时间也是无法接受的,于是选择用Redis与ES按照不同的使用场景来构造内存缓存。

1. 选择主动缓存

常规的缓存方案:查询构建+定期失效。对有大量重复查询的环境效果很好,但在实际情况下,在某些场景却无法发挥预想中的作用。

场景特征:

  • 每个用户只会打开一次客户端,获取一次插件信息,不会重复频繁的去拉取列表。
  • 访问集中在8点到9点这个时间段。
  • 使用被动缓存的后果:
  • 8点前Redis缓存内是空的。
  • 8点到9点,所有的列表信息都是第一次获取,查询全部穿透缓存直接打到数据库。
  • 8点到9点之间获取插件列表后做了插件的续订或权限变更,由于缓存定时失效,导致更新无法反馈,用户不断刷新插件列表直到缓存失效获取到更新结果。人为制造流量洪峰,Redis抗住的也是这些无用的人为重复调用量。
  • 9点以后缓存逐渐过期,不再被使用。

一个测试性能很好,实际却没有用的缓存。

基于以上,缓存层决定通过主动构建的方式建立缓存。在数据修改后,将变化数据主动的加载到Redis缓存中,缓存不再设置过期时间。

有的服务每次获取结果都要通过非常繁琐的计算,如果这些繁琐的计算集中在同一时间点,对于后端资源(数据库)是非常大的负担。

错峰使用资源,把构建缓存的过程分散在离散的调用中,集中使用时直接调用缓存获取最终结果。

上面提到过“类目服务”获取类目层级列表需要多次查询数据库,这对数据库是很大的负担。

提前构建,在类目创建或类目变更时就重新构建类目层级列表,将结果存入缓存,高峰期使用时直接获取已构建完成的类目层级列表。

2. 缓存碎片化

(编辑:核心网)

【声明】本站内容均来自网络,其相关言论仅代表作者个人观点,不代表本站立场。若无意侵犯到您的权利,请及时与联系站长删除相关内容!

热点阅读