京东详情页怎么做,京东详情页技术解密？

京东手机单品页在每次大促时承载所有流量的入口，它被天然赋予的一个标签就是抗压，对系统的稳定性、性能方面要求极其苛刻，另外单品页本身业务复杂度较高，单品页有几十种垂直流程业务，并且展示上都要求个性化的单品页，加上依赖有50+的基础服务，稍有抖动，对整体服务质量都会有比较大的影响，因此之前大促也出现过各种问题，不断打磨，持续优化升级，当前系统架构可支撑接近百万的QPS瞬时访问，并且今年双11表现非常平稳，借此机会一块和大家做一次分享。
一、先聊聊APP接口开发的特点
1. 手机网络、流量受限
手机单品页提供给APP的API受限于运营商的网络，手机的信号时有时无、时好时坏极其不稳定，为了减少客户端和后端建连握手的过程，因此接口下发内容大而全，涵盖了页面上的所有内容，没办法像浏览器BS的结构可以有大量的ajax请求；
API接口依赖了几十个基础服务，任何接口的抖动对整体接口性能影响很大，因此必须是并发请求依赖，减少接口抖动叠加的影响；
单品页有大量的图片信息，商品主图、插图、推荐商品、手机配件商品、排行榜等等图片信息量比较大，单个图片的大小对手机流量影响较大，所有下发的图片采用是webp格式，极大减少网络传输流量。
2. 手机不同分辨率、网络环境、系统版本的适配
不同环境下用户的体验存在差异，比如在弱网、低版本、分辨率差的手机会保持最基本的购物车流程，会减少一些增值的体验；
图片的展示尺寸也会根据网络环境、分辨率大小进行适配。
3. APP版本兼容
新业务需求变更尽可能兼容老版本，但有些业务很难兼容老版本，因此系统里面存在很多版本适配的逻辑，增加了系统的复杂度；
客户端如果出现重大bug并且没办法进行hotfix的情况下，需要服务端针对特定版本进行打补丁，也增加代码复杂度以及后期的维护成本。
因此APP的接口开发逻辑复杂度和后续的维护成本被放大很多。
二、单品页业务系统架构
这是当前单品页系统的整体架构图，其他的核心交易流程，比如购物车、下单等也都基本类似，单品页系统主要有三个进程：OpenResty、Tracer-Collect、Tomcat，以及包含几个旁路系统。OpenResty是nginx层的web容器，主要职责是做静态化和限流防刷，只有经过清洗过的流量才会流转到tomcat的java进程真正的业务处理，Tracer-Collect进程是通过旁路的方式异步埋点到统一的监控平台，进行实时的数据分析。
三、核心技术点
1. OpenResty
这个是在今年618之前架构上做的一个变化，主要有以下几点考虑：
业务需要，业务流量到一定程度，需要把静态化数据以及限流策略前置，更多把流量挡在前端，减少业务系统压力；
ngx_openresty模块有效地把Nginx 服务器转变为一个强大的 Web 应用服务器，在其他0级系统中已经很好验证了带来的高可用、高并发的能力。
使用规范上
Lua属于脚本语言，开发相对java语言比较开放，比如方法可以返回多对象，这对长期java开发人员就有很多不适应，在灰度过程中及时发现并进行修复，因此利用lua来满足特殊需求外，不会进行过多业务逻辑处理；
任何技术上的变动都要极度谨慎，不断的进行灰度测试，我们是从一台机器逐步灰度到一个set，再扩散到一个渠道，最后全量，并且具备实时的异常数据埋点能力，及时发现灰度过程中问题，一旦发现问题要有开关能实时降级。
Lua语言对于很多团队都使用过程中都遇到各种问题，今年双11的总结会上也有团队分享大促期间lua死锁问题，我们这里遇到的一个场景是zk的配置数据同步到lua时一定概率出现死锁。