阿里腾讯都做不到的技术，京东做到了：构建响应式亿级商品详情页
商品详情页是什么？商品详情页顾名思义，就是展示商品详细信息的一个页面，该页面承载在网站的大部分流量和订单的入口。就京东商城来说，通用版、服装、今日抄底、闪购、惠买车、易车、全球购、...
商品详情页是什么？
商品详情页顾名思义，就是展示商品详细信息的一个页面，该页面承载在网站的大部分流量和订单的入口。就京东商城来说，通用版、服装、今日抄底、闪购、惠买车、易车、全球购、拼购等各类模板。目前商品详情页个性化需求非常多，数据来源也是非常多的，而且许多基础服务做不了的都放我们这，因此我们需要一种架构能快速响应和优雅的解决这些需求问题。因此我们重新设计了商品详情页的架构，主要包括三部分：
商品详情页系统（负责静的部分）
商品详情页统一服务系统（负责动的部分）
商品详情页动态服务系统（负责给内网其他系统提供一些数据服务）；
更多图片这里就不一一截图，相信有兴趣的会自己去打开。
商品详情页前端结构
前端展示可以分为这么几个维度：
商品维度(标题、图片、属性等)
主商品维度（商品介绍、规格参数）
分类维度、商家维度、店铺维度等；
另外还有一些实时性要求比较高的如实时价格、实时促销、广告词、配送至、预售等是通过异步加载。
京东商城还有一些特殊维度数据：比如套装、手机合约机等，这些数据是主商品数据外挂的。
我们的性能数据
618当天PV数亿，618当天服务器端响应时间<38ms。此处我们用的是第1000次中第99次排名的时间。
单品页流量特点
离散数据，热点少，各种爬虫、比价软件抓取。
单品页技术架构发展
讲讲历史构架：
架构1.0
这算是最原始的架构，IIS+C#+Sql Server，直接调用商品库获取相应的数据，缓存则是memcached。这样会受到依赖的服务不稳定而导致的性能抖动。
架构2.0
这种方案使用的是动静分离技术，按照商品维度生成静态化HTML，数据动起来。
1、通过MQ得到变更通知（消息队列）；
2、通过Java Worker调用多个依赖系统生成详情页HTML；
3、通过rsync同步到其他机器；
4、通过Nginx直接输出静态页；
5、接入层负责负载均衡。
该方案的主要缺点：
1、rsync是一大瓶颈，扛不住商品量的增多；
2、只有一点数据变更，均要重刷。假设诺基亚由手机分类变更为砸核桃工具分类，那么所有相关的商品都要重刷；
3、不能快速响应一些页面需求变更，大部分都是通过JavaScript动态改页面元素。
没办法，瓶颈又到了，咋办，有钱的大爷，横向扩展即可。
该方案主要缺点：
1、碎片文件太多，导致如无法rsync；
2、机械盘做SSI合并时，高并发时性能差，此时我们还没有尝试使用SSD；
3、模板如果要变更，数亿商品需要数天才能刷完；
4、到达容量瓶颈时，我们会删除一部分静态化商品，然后通过动态渲染输出，动态渲染系统在高峰时会导致依赖系统压力大，抗不住；
5、还是无法迅速响应一些业务需求。
主要思路：
1、容量问题通过按照商品尾号做路由分散到多台机器，按照自营商品单独一台，第三方商品按照尾号分散到11台；
2、按维度生成HTML片段（框架、商品介绍、规格参数、面包屑、相关分类、店铺信息），而不是一个大HTML；
3、通过Nginx SSI合并片段输出；
4、接入层负责负载均衡；
5、多机房部署也无法通过rsync同步，而是使用部署多套相同的架构来实现。
我们的痛点
1、之前架构的问题存在容量问题，很快就会出现无法全量静态化，还是需要动态渲染；不过对于全量静态化可以通过分布式文件系统解决该问题，这种方案没有尝试；
2、最主要的问题是随着业务的发展，无法满足迅速变化、还有一些变态的需求。
高性能及分布式、高性能、深入浅出。高架构。性能调优、Spring，MyBatis，Netty源码分析和大数据学习交流群号为：521479582
注：加群要求
1、具有1-5工作经验的，面对目前流行的技术不知从何下手，需要突破技术瓶颈的可以加。
2、在公司待久了，过得很安逸，但跳槽时面试碰壁。需要在短时间内进修、跳槽拿高薪的可以加。
3、如果没有工作经验，但基础非常扎实，对java工作机制，常用设计思想，常用java开发框架掌握熟练的，可以加。
4、觉得自己很牛B，一般需求都能搞定。但是所学的知识点没有系统化，很难在技术领域继续突破的可以加。
5.一线互联网Java高级架构直播讲解知识点，分享知识，多年工作经验的梳理和总结，带着大家全面、科学地建立自己的技术体系和技术认知！