Golang在京东列表页实践总结
Posted Golang语言社区
tags:
篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了Golang在京东列表页实践总结相关的知识，希望对你有一定的参考价值。
Golang在京东列表页实践总结
10余年软件开发和设计经验，曾就职于搜狐、搜狗、前matrixjoy公司联合创始人、甘普科技CTO。
目前线上状态
基于搜索实现；
全量数据，搜索结果不理想；
接口响应时间长，影响了用户体验；
没法针对数据做二次优化；
转化率相对较低；
基于以上原因，需要做出改变，所以就需要对老进行重构，如下
重构版本
非全量数据，线下异步根据数据模型进行进行筛选部分最优数据；
要求时时过滤计算，接口相应时间要快，保证用户体验；
数据进行优化，提高转换率，提搞GMV；
为何选择golang
golang语言强大的并发能力；
与C相媲美的性能，新版对cpu计算要求较高；
基于以上两点，所以选择了golang语言作为服务端计算使用的语言。
重构后的架构图
解释下架构图各个模块功能
nginx+Lua: 用来渲染页面，拿到go计算服务的json数据渲染到页面端，最终呈现给终端用户；
Config Center 是用来协调worker、lua服务以及go计算服务的控制中心；
Score Worker、Data Worker 是一个用来线下异步计算数据的2个worker，从数据平台拿到数据加上各种数据模型计算最优数据，计算完成后会通知 Config Center，同时数据会进入DB，进行持久化；
深黄色部分是go计算服务，只要分2个集群，一个线上集群、一个线下集群，异步计算服务根据配置中心选择一个线下集群进行数据计算，计算完成后会通知Config Center，然后相应的线下集群会进行数据预加载到分片的redis以及go计算服务的各个节点中，然后线下集群准备就绪，可以随时切到线上提供服务；
MQ Worker是一个处理消息的服务，主要包括sku上架、下架、库存变动、以及价格变动等消息；
Msg Receiver 接受到MQ worker的消息后进行消息处理，然后发送的go计算服务的各个节点中；
线上部署的多个机房，避免单机房故障；
数据处理流程如下图所示：
上图是一个完整的数据处理流程，整个流程中最核心的部分是架构图中的Config Center，数据流程中的每一步操作都依赖于配置中心。所以整个架构中配置中心非常重要。
内存计算模型图
简单介绍下计算过程：
解析页面传过来的参数，整理成相应的结构体；
格式化的结构体，比如品牌、价格、sku属性、库存、产品标签、排序类型等；
通过格式化的结构体进行内存中计算，包括过滤、排序等计算操作；
计算完成后会拿到当前页面需要的产品ids；
然后通过id列表获取到产品的详细信息，并对产品属性过过滤；
最终把结构化的json数据返回给lua，进行页面渲染；
内存计算数据结构
如下图所示：
以上结构是go的一个结构体，包括了页面上所有要进行计算的属性，后续所有的内存中计算过滤、排序都是基于此结构体进行，每个商品对应一个相应的结构体，每个分类大约有几万个商品，内存中也有对应的结构体。这些结构体是在数据异构完成后，数据预先加载内存，避免在提供服务的时候再去初始化。
开发过程中遇到的问题
遇到2个比较严重的问题：
Golang自身序列化性能低下
GolangGC困扰
针对第一个序列化、反序列化问题，我们尝试过golang内置的encoding/json、encoding/gob两种方式，但是效果都特别不理想，耗费cpu过多，qps 一直上不去。
后来请教beego作者的谢大同学，给推荐了ffjson，也亲自写了一些测试ffjson的代码，最终ffson以3倍优势完胜golang内置json序列化，所以最后采用了ffjson。
第二个问题，golang GC问题，相信不少同学在开发的过程中也遇到过这个问题，其实我们认真分析，发现GC时候很大部分时间是浪费的Marking阶段，所以我们可以从以下几个点优化我们的代码：
减少内存中对象数量
尽量重复内存申请，采用对象池，避免重复申请、释放内存，可以非常有效的减少GC；
开启GODEBUG=gctrace=1，可以非常清晰的看到内存中对象数量、内存使用情况。以及各个阶段的时间开销；
另外可以使用golang内置的性能监控工具pprof包，可以方便得监控到内存、cpu的是使用情况。
Go 技术栈选择
json序列化，https://github.com/pquerna/ffjson，里边有详细的使用说明文档；
redis：http://github.com/go-redis/redis 在这之上我们内部又对主从操作封装了一层；
以上是关于Golang在京东列表页实践总结的主要内容，如果未能解决你的问题，请参考以下文章