《京东技术详解》P1-50读后感

这本书大概就是京东构架的编年史,有兴趣了解京东的构架可以看看。特点是通过介绍京东某些重要的模块诞生在哪个场景下,最初运用了哪些技术,到后来原有构架遇到了怎样的挑战,技术团队怎么解决的……等等,通过案例,给读者展示了一条京东清晰的技术脉络借鉴。没有一般公司传那种很枯燥的叙述,喜欢RPG游戏的同学可能会更喜欢这本书一些。 我自己感觉,京东最开始也是把许多功能耦合在一块。后面由于流量的原因先做了页面模块划分,也就是和我们公司一样的动态缓存,模块化加载。之所以称之为动态缓存,因为一般情况下会把网页划分开,各个模块用一个简单的Controller,由于单个页面的各个Controller是异步执且均使用 ob_start 包裹,速度会快很多,最终的输出页面试用 ob_get_content 获取缓存到的各个模块的页面代码整合并添加 缓存key标签 输出页面。类似的我自己是感觉和现在前端流行的使用JSX直接生成html避免DOM无序调用这种思想类似。 【疑问1:我对JS这块也不太了解,React这种JS框架试用JSX操作页面难道不会加重浏览器渲染负担吗?这周读完这本水书,下周看JS高级程序设计再解答吧。 疑问2:事实上我对公司中页面各个子模块 load 时候是否异步并不清楚, 也不清楚每次load时访问缓存的规则。 疑问3:一直以来,我只知道只要页面更新,消息队列会得到刷新缓存的指令,这个我还是不清楚具体的实现。】 在解决完成简单的解耦后,内部网络的复杂通讯使得京东开始了自研负载均衡, 从最开始的商业产品到后来使用LVS实现的软负载。外部访问压力的提升,加上第三方CDN厂商的产品不太稳定,京东从最开始的squid作为前端代理服务,过渡到HAProxy + ATS。 在讲述整个变迁过程中,京东的技术团队一直在努力的为京东的各个模块进行可降级处理。也就是当首页动态访问量巨大后端不堪重负时候,替换为静态页面(同理,某个展示模块负载过大也会直接载入不那么及时的静态页面展示)不至于让用户无内容可看。 通过对业务流程的梳理,得到一些与主干流程相比较过于复杂的逻辑模块,并将其拆分为独立的模块比如:京东的秒杀业务、购物车模块、订单合单模块(多个第三方商家或者与京东自营产品的订单在同一个页面显示)以及订单展示页所涉及到的发票管理、拆单功能、拆单算运费并统计总价等等这些看似简单,但实际上当业务量到一定程度会严重影响业务稳定性的功能。 37开始讲的是一些分布式的问题,讲述了为什么要分布式云云,鉴于自身经验不够,无法获取到有价值的信息。略过 ~ 下一篇打算大概是京东的供应链管理以及内部金融管理 过两天写了~