京东是中国最大的自营式电商企业，京东的应用系统繁多，系统间调用逻辑复杂；作为电商平台，响应要求块，保证良好的用户体验；面对618之类的促销活动，要能支撑访问量剧增的情况，因此京东技术架构需要做到快、准、稳，即高可用。《决战618》这本书里的很多方案都给我们提供了解决问题的思路。

未来已来
要应对各种可能存在的对网络、对应用的攻击；要做好系统监控，提前根据业务预估，进行流量压测；梳理应急预案，对预案进行实战演练。总之，目的就是确保系统的高性能，在遇到一场情况时都能快速处理，并可以进行系统、机房及网络的各种切换。
伴随着京东整体技术水平的不断进步，备战的智能化日益提升，很多预案都可以利用机器自动执行，人在其中大都是起到查漏补缺、监控的作用。

技术备战利器
“工欲善其事，必先利其器。”数年的618备战，研发团队不断积累经验，设计并制造了两个重要武器——ForceBot与Chaos Monkey。ForceBot（全链路军演压测系统）意为“军演机器人”，它部署在京东各地的CDN节点，能够发起模拟真实用户的、超大规模的、购物流程全覆盖的访问流量，以便进行有效的军演压测。Chaos Monkey（全场景故障演练系统）是一套工具链，用以进行各个场景的、不同层面的故障模拟，包括网络、机器、OS、DB、中间件、核心服务、流量入口、IDC。通过Chaos Monkey，各团队可以验证自身系统在出现故障情况下的可用性表现与应对的降级能力。

首页优化之路
（1）数据检验。对每个依赖的服务进行了严格的检验，并检查数据内容是否符合规范，是否有空字段抛出。如遇异常情况则自动降级，且返回一份几分钟前的无错数据，保证数据的有效性，杜绝出现天窗情况。
（2）多级缓存。在既要保证效率，又要展示个性化数据的情况下，技术人员在设计中使用多级缓存来尽量减少后端服务压力。
（3）降级开关。为了防止首页出现异常情况，设计了自动和手动的降级开关。同时充分建立各类系统容灾方案，保证首页在极端情况下可以随时切换至上一个正常版本，从而确保京东首页的正常展示和运行。
（4）托底页面。定时向CDN推送一份包含所有请求的静态文件夹，这样保证在源服务器网络异常不能访问的极端情况下，还能有一份完整的页面展示给用户。
（5）前端降级。后端接口可能偶尔会出现错误，或者直接宕机，但是不能因为接口出错而使得页面显示出现错误，这就需要前端来配合给出一套合理的灾备方案。

网站监控
通常在一个大型的web项目中有很多监控，比如对后端的服务API，接口存活、调用、延迟等监控，这些一般都用来监控后台接口数据层面的信息。但是对于大型网站系统来说，从后端服务到前台展示会有很多层，如内网VIP、CDN等。通常的网站监控并不能准确地反映用户看到的前端页面状态，比如：页面第三方系统数据调用失败、模块加载异常、数据不正确、空白开天窗等。这时候就需要从前端DOM展示的角度去分析和收集用户真正看到的东西，从而检测出页面是否出现异常问题。
解决方案：
1、前端规则录入。这是一个独立的web系统，系统主要用来收集用户录入的页面信息、页面对应的规则、展示错误信息。通过调用后端页面抓取服务来完成页面检测的任务，系统可以创建三种类型的检测页面：常规监控、高级监控、可用性监控。
（1）常规监控。录入一个页面地址和若干检测规则。注意这里的检测规则，研发人员把常用的一些检测点抽象成了一条类似测试用例的语句。每条规则用来匹配页面上的一个DOM元素，用DOM元素的属性来和预期做匹配，如果匹配失败，系统就会产生一条错误信息。
（2）高级监控。主要用来提供高级页面测试的功能，一般由有经验的工程师来撰写测试用例。这个测试用例写起来会有一些学习成本，但是可以模拟web页面操作，如：鼠标单击、移动等事件，从而做到精确捕捉页面信息。
（3）可用性监控。可用性监控测重于对页面的可访问性、内容正确性等比较严重的问题做即时监控。通常这类页面只需要在程序里面启动一个线程不断地去获取页面HTML，就可以对结果进行检测匹配了，所以选择了Node.JS来完成这种网络密集型任务。
2、主动错误上报
（1）页面脚本执行错误监控。页面引入一段监控脚本来监听页面生成错误事件返回的错误信息，自动上报给后端服务，在系统里面可以汇总所有报错信息，以及对应的客户端浏览器版本、操作系统、IP地址等。
（2）页面主动上报。这个功能需要工程师在代码中调用错误上报API，来主动提交错误信息。主要使用的场景有：页面异步服务延时无响应、模块降级托底主动通知等。

交易平台架构——基础用户服务
用户基础服务中间件根据调用方的重要程度、调用量、访问的用户信息字段等对数据层的访问进行动态规划：主数据还是从数据，是否击穿到数据库等，针对核心交易调用的数据，隔离出独立的数据缓存，同时支持自动容错访问到共享的基础用户数据。在数据隔离方面，按敏感度划分，敏感数据进行加密存储（如密码）、掩码传输（如昵称）；按访问频率划分，访问频繁的持久化存储到缓存，非频繁访问的进行临时存储；按调用方对用户服务的敏感级别划分，对敏感级别高的接入方，其用户数据单独隔离存储。在接口隔离方面，用户内部接口与外部调用接口隔离，数据更新接口和数据查询接口隔离，交易主流程依赖的服务接口跟非交易主流程依赖的服务接口隔离。这样就有效保障了交易主流程的可靠、稳定，经过了历年618考验，基础用户服务已稳如磐石。

交易平台质量控制
1、自动化测试：能在软件开发流程中提升效率的、能在质量保证环节提升质量的自动化是可以去做的自动化测试，不为了自动化而去做自动化
（1）初始化测试数据
（2）调用被测应用接口
（3）结果对比
问题和挑战：存储的分库分表、接口入参不能重用、测试执行的自动化调度、测试结果的可视化、与持续集成系统的接入等。
线上环境的日常测试中，我们的初期目标定位于线上多实例的存活、连通性验证。如果是HTTP接口，可以遍历某个应用下的所有IP，针对每个IP单独发送请求，检查返回值是否符合预期。如果是JSF接口，我们可以针对每个分组，遍历分组下所有的实例IP，在上线过程中灰度发布，发布完成后进行验证，验证没问题后再进行下一个分组的发布。
在618期间的线上自动化测试场景中，我们更关注流量高峰下系统的稳定性，系统会不会出现因为性能问题造成响应慢、拒绝服务的问题。为了解决这一问题，我们在线上从各个流量入口（PC端、微信端、App端、M端等）来发起请求，针对核心系统的核心业务，在UI层面进行自动化巡检，一旦发现如页面响应时间过长、超时等问题，立刻报警，团队成员立刻介入，第一时间定位问题、解决问题。
在线上环境的自动化测试中，我们也尝试过对线上的读写接口进行业务逻辑的回归验证，只不过如何保证测试数据与线上真实数据的分离，如何保证线上测试执行不影响线上流量，如何对测试过程写入的脏数据进行过滤删除等，都是需要考虑的问题。
2、线上压测
性能测试模型由三部分组成：web管理工具集群、Agent代理集群和目标服务器集群。在该模型中，Controller可通过HTTP协议调用Agent测试代码中的测试场景，再由Agent对目标服务器发起请求，以完成整个压测过程。该模型有三个优点：
（1）管理端是Web管理页面，可以统一发送请求、统一收集数据，结果准确、可靠。
（2）支持在线编辑脚本、启动场景，同时支持多用户同时操作，大大降低性能测试场景执行和推广的难度。
（3）Agent端支持水平扩展，通过J-one.jd.com（统一工作平台）任意扩展Agent，最大限度模拟生产环境的流量。目标服务器作为压力承受端，也可以水平扩展，模拟多服务器负载均衡、容灾等场景。
性能分析：在分布式框架下，针对不同的系统应用、不同的测试目标，以及不同的性能关注点，根据性能指标的表现，采取逐步定位、从外到内、由表及里、逐层分解的分析原则。通常可按以下顺序进行：中间件配置（Apache/JBoss/JSF参数配置、数据库参数配置）->应用系统日志->应用系统瓶颈（线程池配置、代码、SQL语句、算法等）->第三方服务提供者性能瓶颈。

app技术支持
1、HTTP状态码：快速发现web问题
当某个域名在指定时间单位出现50x和40x的次数超过一定阈值，系统就会默认发送告警。这样运维团队就能及时得知当时的域名、具体的HTTP状态码、具体发生问题的机器、当时单位时间内发生的次数以及请求的URI。
2、网络拨测：发现用户真实的网络问题
通过该监控系统，当运维团队发现某地区的运营商出现延迟增大或者丢弃频繁的情况时，就会切换该地区的入口VIP，以提升该地区用户的访问质量。
3、性能测试平台TP
为了让压测过程更人性化，平台功能也在不断优化和完善中，2017年再次简化了创建任务、执行测试任务的方式，同时加入和优化了对被压系统的监控视图，测试人员可以更为全面地观察测试发送的流量以及系统实际承受的流量，便于随时调整压测方案。

秒杀系统
1、海量服务，日常大规模高并发
采用微服务架构，每个服务安排一个团队维护，不同服务之间低耦合，有利于代码的开发和优化，相互之间独立工作，提高了开发效率。并且微服务的架构也更有利于进行水平扩展，按需扩容可只对需要的系统进行扩容，一方面有利于快速扩容，另一方面也降低了扩容对整体系统带来的潜在危险。
2、卓越性能，瞬时流量涌入低延时
在预加载时间段，客户端会向服务端请求数据，服务端根据一定规则判断下发当前场次数据或下一场次预加载数据。如果客户端预加载成功下一场次的数据，则在场次到点切换之后不再向服务器发送请求，直接使用本地预加载数据。通过这种预加载的方式将整点切场的部分流量分摊到预加载时间段，大大削弱了切场整点的尖峰流量。
3、高效可用，全面稳定无宕机
在迭代频繁的情况下保持线上业务服务的持续稳定可用：立体式的系统和业务监控，完善清晰的降级路径，严密科学的容错兜底逻辑

流控策略
使用nginx+openresty将流控策略功能从业务服务前置到了前端nginx模块中，作为独立的流控服务
1、在前端nginx中接入风控系统，非法流量将在防刷限流服务中被直接拦截
2、对于超出业务服务处理能力的正常流量，综合考虑业务服务集群性能指标，如cpu使用率、负载、QPS等，把它们加到流控策略，指标值由上述数据采集系统收集。当这些性能指标达到一定阈值后，由于这些流量不是异常流量，不能直接生硬地拦截，所以流控服务与客户端建立排队策略，将这部分流量的请求结果直接设置为排队消息。客户端接收到排队消息后，将弹出排队提示，排队时间由服务端下发，排队时间达到后重新请求获取正常的业务数据
3、进行入口检查和接口调用频率检查策略

崩溃自动化分析
升级底层SDK，增加了内存警告崩溃的捕获。同时，完全自主地实现了一套崩溃自动化分析系统。该系统从日志分析、问题模块统计归类、日志展示、筛选纬度以及监控上都做了更深层次的优化和探索。

无线业务安全
1、数据聚合及分发模块。解析各个业务方传来的数据，并且可能在处理过程中需要聚合一些调用其他第三方接口回传回来的数据，在转换为统一的数据格式后，落入DB或者分发到每个业务的流式计算模块中。DB中的数据可供数据分析人员进行离线分析，开发可实施的风控策略并进行离线验证
2、流式计算模块。接收数据聚合和分发模块传入的统一格式的业务请求数据，实时地实现各种复杂的风控策略，并且将风控的结果写入缓存中，供规则引擎模块查询
3、规则引擎模块。为每个业务分配一个固定的业务标志AppID，然后通过传入的请求携带的AppID区分业务，进而明确需要查询的缓存，这个缓存中的数据恰恰是流式计算模块为该业务计算出的风控结果

渠道引流技术运营
1 立体监控
数据采集：红绿灯渠道 秒级渠道 模调渠道 变更追踪
故障识别：规则引擎 宏观视图 走向智能
故障处理：定位工具 故障知识库 自动处理网关
2 快速扩容
中控式、模板化的扩容流程系统。扩容中控系统在最高层负责流程的调控、执行；在扩容流程各环节的层面上，扩容中控系统提供模板化的能力，把每个环节里的各个操作步骤整合到模板里来，供高层的中控系统进行操控执行。在更下一层的步骤层面上，则需要把各种具体操作变成可以由机器执行的标准化接口。
3 自动容灾
对于一般服务的数据，采用一主两备跨机房的灾备模式；对于重要服务的数据，采用同城双活的灾备模式；对于核心服务的数据，则实现了异地双活。
4 质量保障
前端页面扫描与监控
后台接口自动化测试
自动化压测
自动化安全扫描
一站式智能发布验证
小程序测试探索：静态代码的扫描、调试与性能测试平台、小程序自动化

数据库SQL优化
1、慢SQL平台，对线上慢SQL进行自动化，可视化管理
2、邮件推送，当有慢SQL产生，每天会定时发邮件给相关研发，提醒他们及时进行关注和优化，并且会把慢SQL提交Jira系统，进行有效的跟踪，直至该慢SQL被优化完成

缓存平台
1精确的故障检测和自动故障切换
2无损扩容
3监控和报警
4自动弹性调度，对集群的各项指标进行监控，比如OPS、内存使用率、网络流量等进行监控，统计这些指标一段时间内是否达到了设置的阈值，当超过扩容的阈值时则自动触发扩容，当低于缩容的阈值时自动进行缩容，释放资源。
5服务端升级，在同一台物理机上创一个新版本的实例，当旧实例销毁后并不会导致物理机上实例数超限等问题，通过数据复制流程把旧实例上的slot全部迁移到新的实例上，由于数据是在同一个物理机上流动，因此速度会比网络传输快很多。

故障演练系统
系统总会遇到各种各样无法预料的问题，有些基础设施的故障是无法避免的，不可控的。研发团队在做系统架构时，就针对基础设定前提：
1、机房宕机
2、网络交换机宕机，导致整个机柜设备脱离网络
3、服务器主机宕机
4、网络会因“渣土车”导致网络的延迟、丢包
5、系统所依赖的中间件、DB有可能会无法正常连接
6、系统的进程宕机
7、系统的主机环境会面临磁盘写满、CPU高负载运行、内存满等
当面临这些故障时，系统应当正常运行，至少应当受限运行，绝不允许将错误抛给用户。也就是说，当系统遇到这些故障时，应当在不影响用户访问、下单等用户体验的情况下正常运行。

多中心网络监控和灾备
1 各中心会有到全国省份城市的网络质量速度检测数据API，提供给GSLB作为调度数据依据之一，实时调度避开拥堵网络，选择最优中心提供服务
2 各中心机房内部网络监控，包括网络设备、专线、服务器等，点到点分布式监控每个节点的网络质量

网络自动化
白盒监控，对全网所有设备进行100%的监控，针对不同种类的端口制定不同的采集策略，从端口流量、CRC到设备的CPU、内存和ICMP探活。
黑盒监控，将大量业务部署到监控客户端(Agent)，中央模块根据Agent的位置(Rack、POD、机房)为其下发不同的探测任务，同时Agent之间进行交叉探测，并将监测到的数据上报给中央模块，这样可以站在业务侧的角度，更加真实客观地反映出网络的健康状态。通过各种细颗粒度的监测，中央模块支持按服务进行汇聚，获得网络服务各种纬度的健康状况，如机架、集群、POD、机房、专线等。
对于公网部分，在所有机房的出口部署监控程序，针对三大运营商全国所有省市的探测节点进行探测，通过这部分数据可以得知数据中心出口的网络健康状态和各地运营商的网络健康状态。

全局流量调度系统
当访问域名目标IP不可用或有预期问题时，通过域名解析或其他手段调度到正常IP地址，以达到正常访问网站目的，即流量调度。

防攻击系统
物理资源：京东在数年前就已完成异地多机房、多线路的网络布局，核心业务在京东的每个骨干节点中都会部署热备服务，同时依靠用户接入部维护的智能调度系统进行负载均衡，当任意一个节点可用率下降时，通过智能调度系统便可以将业务流量收敛到正常节点中，保证业务稳定性不受损失。
网络结构：防攻击系统需要在攻击流量进入业务集群之前进行清洗，保证业务集群能够正常稳定运行。
软件架构：传统的DDoS攻击检测是靠简单的阈值来进行的，通过统计某个周期内发现的数据包数目，与配置的攻击阈值进行比较，超过阈值的就是攻击行为，小于阈值的就没有攻击。新的防攻击分为两大核心：攻击发现系统、攻击清洗系统

反刷单系统
刷单作为一个缺乏标注数据的识别场景，如何在此场景下提升模型的识别率和准确率是业界公认的难题。对此，反刷单团队主要采用了两种解决方案：一是无监督的样本增强，通过样本聚类的方式扩展正负样本；二是构建了刷单的GoldenSet，在这个订单聚合上可以计算出模型在召回和准确率上的提升效果，实现模型的自动化效果评估，加速模型迭代。

信息安全
安全的攻防不再是个人或团队的技术对抗，而是体系的对抗。安全也不应该是后加的内容，而是在产品或服务构建初期就嵌入其中，就像一架飞机的每一个零件都必须是安全可用的。
一、安全体检后自主选择改善目标。通过对各部门所用的CI系统、项目管理系统、上线系统、漏洞管理系统、人资系统等系统的分析，得出各团队执行SDL前的安全体检值。业务部门根据自身的发展现状，自行选择希望达到的安全体检值。有了目标之后，信息安全部有针对性地为业务部门导入所需的SDL阶段和活动，并指导业务部门如何提升。
二、宽进严出。信息安全部在每一个阶段都制定了考核标准，比如，在安全测试阶段，信息安全部为部门提供对应的培训，每个团队完成培训后必须定期反馈结果。没有完成考核的部门不予通过，没有通过考核的部门需要重做本阶段的活动，直至指标达到要求。
三、授人以渔而非授人以鱼。通过SDL的推行，将信息安全部的能力输出给各业务部门。POP团队通过执行SDL，在部门内部建立了测试的标准化和自动化的工具，保证部门内的所有项目都统一执行标准，不但自行测试出项目中的安全漏洞，而且自行发现隐藏在现有系统中的安全漏洞。

安全保障
一、备战阶段
1 安全风险 在每一次重保的备战时，把京东针对大促期间存在的风险都会列出来，做差距的比较。包括引导发布、资产分析、隐患自查、响应演练、监控感知。为了保证比较高效地完成跨部门的协调工作，引入了引导发布的工作机制，通过引导发布机制让所有人都能够知道每个层面应该如何加强安全，安全团队首先自己会把所有涉及不同层面的东西来复盘，制定好之后让各个业务部门自查。
2 资产分析 重保备战前一个半月，安全团队集中搜集各个业务部门的核心业务系统，各业务线安全官负责对业务系统的系统架构、网络通信、数据存储、业务逻辑、账号权限、系统部署配置等安全控制点进行检查，对系统进行源代码级别的安全检查和渗透测试，将核心业务系统的安全风险降低至可接受的水平。
3 JSRC 每年的重保之前的一个多月，京东安全响应中心每周都有一些不同的活动，2016年618保障时最大的奖项是无人车，通过重奖，保证重保之前把所有的风险都发现出来。在2017年618大促，信息安全部发动JSRC的1000多名白帽子，开展了全民保障618活动，在618之前积极告知网络中安全漏洞，累计提交漏洞217个，其中深层次、影响范围大的高危严重漏洞20余个，在618大促前消除了隐藏的安全漏洞。
4 实操演练 2016年的重保，安全团队准备了十大预案，根据这些预案，在真实生产环境中演练重大漏洞、信息泄露、DDoS攻击的应急和响应。如在DDoS的演练中，安全团队分级专门做了不同场景的联动，当测试流量引过来时，首先看自己怎么防；如果防不住的，IDC有什么能力帮我们扛一部分；如果IDC扛不住，运营商怎么在这个基础上帮我们联动抵制流量。用这种方法充分地把这个事情全部做一遍。
二、保障阶段
1 监控 2017年哮天犬监控系统在原有的一个大屏幕的基础上，增加了2块屏幕，12个监控点。用户登录、恶意账号登录、资产、入侵、web攻击、安全漏洞、威胁情报等30多类数据从不同层面汇聚，呈现整体的安全态势。
2 总结-复盘-改善 首先把整个漏洞发现的风险都做了折损，发现多少问题，处理多少问题，所有的漏洞和安全事件都有价值。对出现的问题进行复盘，确认持续改进的计划和监督保证落地。

安全漏洞闭环管理
业务部门所属的应用系统及其IP地址、端口、服务和组件信息同步到大海资产管理系统中，扫描引擎定期从大海系统中增加扫描对象并加载扫描任务，并提交到扫描引擎。业务部门的源代码管理系统也与扫描引擎自动化对接。一旦扫描完成，将扫描结果发送至脉象平台，用于整体安全态势的分析。一旦发现安全漏洞，则通过ITSM工单系统进行跟踪，安全漏洞的跟踪和修复状态定期通过安全数据周报的形式告知各业务部门。
安全官检查和外部接报的信息安全事件，经过验证后，一方面通过ITSM工单进行跟踪；另一方面，在大海系统中检查存在问题的关联系统和信息，调度引擎再次执行关联检查和扫描，杜绝安全漏洞的次生影响。

预测系统
历史数据的获取、数据清洗、模型选择和训练、模型应用、模型效果监控和更新等。

订单履约中心自动化工作流系统架构
引入工作流，实现了流程集中控制，避免了流程分散造成的数据不一致和流程混乱现象。与“流程集中控制”相对的是“流程分散”，即流程由各业务系统本身控制，由于业务系统关注于业务本身，往往难以兼顾流程逻辑。
客户端流量控制技术。该技术也是在引入工作流过程中实现的。在工作流的前端是接单系统，它的职责是接收从上游传来的订单数据，也就意味着会受到618订单洪峰的冲击。从历史上看，这个洪峰最高达到10000次/s调用。而供应链履约中心通过客户端流量控制技术，把洪峰削平了，下游十几个系统只需要按平滑后的流量来建设系统，大大节约了系统建设成本。通过客户端流量空值技术，供应链履约中心还可以在运行时维护整个订单履约流程流量的稳定性，保证各个生产终端（例如各个仓库）可以按约定的节奏均衡地生产。
分环节内存队列技术。通过使用“内存队列”技术，以及流程中各系统服务的SLA达成，将订单履约工作流时效从原来的30min缩短到了秒级，为保证定时达（1天内可以选择三个配送时段）、极速达（2h内将商品送达）等业务提供了保障。前不久，京东创造了从下单到送到用户手中最快10min的世界纪录。“环节”指的是工作流的环节，每个环节都有自己的任务队列，这样做不是为了速度，而是为了控制，包括流量控制、流程拦截、优先级调整等。
监控与报警方案。除了接入京东的统一监控平台实现基本的监控功能外，还根据业务特点，实现了任务积压及趋势、有积压情况下处理能力的趋势、异常数据等方面的监控，报警前加了一定的分析功能。例如，如果系统出现了积压，同时系统处理能力在不断上升，说明这时狐仙了业务高峰，而不是系统出问题了；如果系统吞吐量在下降，响应时间正常，且没有积压，则说明是业务量在降低。

618前的工作
知己知彼，百战不殆。为了应对618，首先要评估系统会有多大的流量。其次，评估在这么大流量下，系统要保持什么样的状态才能满足下游系统生产。最后，需要通过压测来评估验证我们的系统能否经得住考验。
评估的依据还是业务部门给出的促销方案，以及历史上的促销数据和流量数据。并同上游系统沟通，了解上游系统的流量以及扩容方案，一起来评估自己系统的调用数据。有了流量数据后，再来评估现有的应用系统、缓存系统、存储系统能否支持这一流量。如能支持，会有什么样的表现，什么样的QPS，什么样的并发量，什么样的TP99，什么样的CPU使用率和负载。如果不能支持，有哪些地方需要改进，哪些地方可以优化，哪些地方可以降级。针对降级，又如何定义启用场景，启用后又有哪些不足和补救措施。如果某系统或某服务出现故障，可以采取哪些应急的措施能降低影响。有了这些数据，再去找下游系统，协商SLA、并发数、TP99等信息。当然，对下游系统的要求会宽泛许多，也要协同考虑仓配系统的实际生产要求，根据木桶原理定义出每一个系统的并发数和调用量的限制。
在评估完成后，需要根据评估结果进行线上的压力测试，检验现有资源情况能否满足618的需要。由于线上一直都有用户订单数据在执行，因此压测时间就选在了用户相对较少的凌晨时分。压测的方式，主要是模拟大量的调用，以较高的并发量来调用某个系统，观察该系统的表现。对于某些特定的系统，还可以采用减少线上应用实例个数的方式来辅助压测。压测之后，就能得到某个量级的冲击下各个系统的表现，评估出是否能满足本次618的需要。如果无法很好地满足，则需要依据生产能力来评估，最低调用量要满足多少，以及相应的降级措施和之后的系统改进方案。
对于定义出的降级方案和应急的策略，需要整理成详实的、可操作的文档，并通过实际演练的方式让团队中的每个人都熟练掌握。除了面向整个团队的宣贯之外，还采用问答考试的方式，线上的Chaos Monkey演练等方式来确保每个人都能掌握。

物流架构
1、基于业务的数据库拆分 该服务器上的非核心库全部原封不动地迁移到其他服务器上；核心时效库中的非核心表也拆分到其他服务器的新库上。核心库只应付海量订单信息写入，是的后续TPS的优化变得更加有针对性
2、网络I/O优化 按照峰值调用量、峰值数据传输流量大小等评估缓存结构设计是否合理，在调用次数与数据冗余上进行综合考虑和取舍，同时将分布式缓存集群也按业务进行了合理的分离
3、磁盘I/O优化 从根本上优化应用日志输出（精简、有效、每个请求的日志都绑定唯一的标志，方便排查问题），真正做到打印日志是一门艺术；日志按业务或分包文件，配置不同的日志级别和滚动策略，控制所有日志文件总大小不能超过服务器磁盘空间大小的70%；根据实际情况调整日志工具的BufferSize，在适当场景下使用异步日志
4、多级缓存策略 为应对618等高流量的特殊时期，并且为了进一步提升服务的高并发、高性能，团队采用多级缓存的方式对数据进行处理，同时针对不同的业务应用，采用不同的缓存策略。例如，对于京配服务、特色服务推荐等响应时间要求较高，而数据一致性要求相对较低的应用而言，采用了分布式缓存加本地热点缓存的方式。对于分布式缓存，采取的是定期全量缓存更新策略，数据首先写入数据库系统，每天在固定的时间将数据同步到分布式缓存系统。同时针对本地缓存，采用热点数据的方式，针对某些秒杀活动，基于历史数据或者其他信息进行本地缓存预加载的方式。并且针对不同的业务数据，设定合理的本地缓存的时效时长，从而更有效地提升系统的访问效率，进而提高系统性能
5、平衡海量数据和实时计算的架构
（1）选用ElasticSearch作为数据落地的存储引擎，借助ElasticSearch高效的读写性能，完成实时数据模型的存储和查询功能
（2）通过Kafka实时接收线上业务数据，通过实时数据引擎，根据预先设定的实时数据模型进行数据实时处理，并将实时处理明细落地到ElasticSearch
（3）通过调度系统汇总查询统计需求，由调度系统转发用户查询请求，并提供动态查询参数，这样能够控制非常消耗ElasticSearch集群的查询请求，保证ElasticSearch集群的资源消耗是可控的，又能够做到满足用户复杂的查询统计需求
（4）对于实时性能没有非常高的查询统计需求，增加数据中间缓存层，将固化的统计需求结果定时刷新到数据缓冲层，这样就可以将ElasticSearch集群压力转移到数据缓冲层，缓解ElasticSearch集群查询压力的同时，提高请求的吞吐能力
6、自定义的业务监控系统 目前京东公司级监控系统做到的监控包含：网络层面、服务器层面、应用层面、JVM层面、数据库层面。但是各个业务系统也有可能对自身的业务数据的正确性也比较敏感，针对此类需求，公司级监控系统就很难做到深入所有的业务系统，所以团队自研发了一套表数据级别的监控系统FDM。
FDM系统可以针对不同的表配置不同的监控任务：异常数据扫描SQL、异常判定条件、任务执行计划、报警策略等。

京豆安全检验机制
狭义的安全性每一个需要接入京豆台账的系统都需要申请统一的密钥，并且对所申请的密钥要有相应的角色控制，即在发起系统间调用的时候，需要传入相应的密钥，并查看密钥是否与所申请的接口匹配
广义的安全性 采用了多中心交易实现多个异地机房同时提供交易服务，任何一个机房出问题后都能由其他机房接管。用户尽可能在最近的机房完成交易，并且在单机房内形成流量闭环(将用户数据封闭在一个机房，解决了数据复制延迟带来的后发先至的问题。实现单机房流量闭环，需要移动网关、单品页、购物车、结算页、优惠券等多个系统路由规则一致，统一合作)。

商家系统升级优化
一 高并发下的多级缓存技术 商家系统提供的店铺信息、类目、品牌信息会被下游核心系统(如购物车、结算页、财务系统等)依赖，这些下游系统的特点是并发高、要具备99.99%的可用性。对于这种场景，我们不仅使用分布式缓存，如Redis，还会使用如Google Guava这种本地缓存，以提高可用性和接口性能。
二 异常情况下的降级特技 系统跟机器一样，在高并发场景下会出现各种问题，例如访问突然剧增、网络超时等，此时，需要有各种降级策略来保护系统，主要分为自动降级、人工降级
自动降级：有些服务在一段时间内有可用率波动时可通过自动降级来减少故障时间，例如店铺信息读服务接口依赖的Redis可用率在90%以下的时候，会把读服务自动降级为本地缓存。
人工降级：当出现严重错误的时候，例如在数据库宕机主从自动切换不了的时候会有个大开关人工一键降级，将所有的读库服务切到从库上，保障核心服务正常可用。
三 多机房部署与容灾 对于京东这种交易规模线上服务宕机都是以秒来计算的，宕机的每一秒都会成为事故，针对一些诸如天气、施工导致的线缆被破坏等不可控因素，也要有应对方案。商家系统应用依赖的资源，例如MYSQL集群、Redis集群、ElasticSearch集群，同时部署在双机房，平时流量均匀分布，一旦出现机房网络异常，运维可以切换，同时商家系统通过降级系统可以从应用纬度进行热切换，实现在1min之内恢复服务可用率
四 隔离术
1 进程隔离 应用按业务拆分后独立部署，每个业务单元都部署在不同的实例上，这样保证每个实例之间是物理隔离的，任何一个子系统出问题不会影响其他系统
2 线程隔离 我们会将应用内部的请求进行分类，不同的请求使用不同的线程
3 集群隔离 针对不同的业务领域，我们使用不同的集群进行物理隔离，例如店铺数据和画像数据分别在不同的缓存集群，任何一个集群出现问题均互相不影响
4 读写隔离 商家系统提供了不同纬度的读写服务，读服务占比90%，写服务占比10%，例如通过Redis主从模式将读写分离

商智系统接口可靠性备战
梳理 从优先级、应急联系人、影响范围(菜单与业务级别)、接口文档、历史压测性能报告、接口是否经历过大促六个方面，对所有外部接口进行梳理和分类，并整理成完善的文档，以备发生问题时及时跟踪定位。
压测 对所有的外部接口进行统一压测。研发团队根据商智当前的QPS等系统压力数据，预测出618期间接口可能产生的压力值，然后同接口提供方逐一进行沟通，提出性能预期，并进行压力测试。对于不满足性能预期的接口，团队与接口提供方进行了沟通，在保障618的大前提下，接口提供方迅速地进行了对应的改造和优化。
监控 对所有外部接口添加UMP监控，并配置短信报警，当接口不可用或者请求量超出预估值时，系统将通过短信的方式通知相关人员，第一时间做出调整或者处理。
应急预案 对四个高优先级的核心接口制定应急预案，采用类似快照的方式，在每天接口压力最小时，预先抓取所有商家的接口返回值，并且持久化到本地Hbase中。与此同时，在Hbase上添加了一层Redis缓存，以提升访问性能。一旦接口不可用，可以在1min内将接口依赖切换回本地数据，最大限度地避免商家的使用受到影响。
对于优先级较低的接口，制定了接口压力过大时通过人工控制接口的访问频次进行降级的应急预案。例如，实时流量与实时销售的相关接口，在原定的秒级间隔刷新的基础上，新增了可配置的开关。当接口压力过大时，可以人工将缓存时间延长，进而降低对外调用的频次；当接口压力下降之后，又可以人工将缓存时间缩短或直接关闭缓存，在商家无感知的情况下，动态控制调用压力，保障系统的稳定可用。

智能调度出口流量平台
1、智能负载均衡——客户端进程内负载。当客户端所在机房的网络运营商与商家所在机房的运营商属于同一网络运营商时，可以直接在本地调用商家接口，即客户端根据不同的商家选择不同的机房作为流量出口。通过智能匹配的方案，即可从根本上解决这些跨运营商或跨地域的问题，从而提升调用的成功率。
2、智能负载均衡——服务端均衡。如果部署应用所在机房与商家所在机房不是用同一个运营商网络，此时业务系统会通过PEER系统提供的接口，并通过JSF将流量导向与商家机房相同运营商的机房，这样就可以实现与商家在同一个运营商网络上进行接口交互，大大提高了接口的可用率。
3、智能调度流量出口机房。关于机房的智能筛选，我们会提供三个策略：
策略一：手动设置默认机房，手动调整，即为每个代理商设置一个默认的机房ID，保存商家信息
策略二：根据实时可用率，选择一个服务性能最高的机房，通过监控平台根据key或者实时可用率，筛选出最近5min可用率最高的机房
策略三：综合策略一和策略二，通过阈值&开关控制，避免网络抖动可用率不稳定，可能会造成商家的不良切换。增加一个开关和阈值，当开关打开时，默认机房可用率不低于阈值即可使用，低于阈值再通过监控平台筛选出一个可用率最高的机房
通过这三个策略，可以真正实现整体机房的智能调用，为系统服务的稳定性提供了坚实的保障
4、智能降级。引入熔断机制，优雅降级，避免某个业务线或某个接口出现问题后长时间占用系统资源
5、智能平衡流量。通过权重平衡每个机房的出口流量

户簿系统的特性
1、存储可扩展
2、组件化服务
3、图像预处理
4、多维度查询
5、安全访问控制
6、安全存储与安全传输
7、图片水印
8、智能识别

单机部署遇到分布式部署产生了分布式日志收集系统，单体应用遇到微服务产生了分布式调用跟踪系统，短流程遇到长流程产生了足迹系统

印尼电商平台
1、异步化 异步化能很好地控制并发，并提高效率。例如在用户注册的过程中，如果涉及日志的记录，将日志记录做异步化处理能很好地减少注册功能的响应时间。另外，针对一些实时性要求比较高的场景，如库存的扣减，仍然可以用异步化的思想，将扣减在缓存中进行操作，异步到数据库中。这样能减少数据库的并发压力，当然也需要考虑实现缓存和数据库中的数据的最终一致性
2、多级缓存 缓存在业界各个系统中都用得很多，也被谈及得很多，说明缓存仍然是提升系统性能的一大利器。从浏览器缓存到CDN，再到Nginx缓存，JVM缓存、分布式缓存，从前到后，将用户所需要的信息尽快地返回给用户。例如，印尼电商平台的M站，PC站首页等实时性要求不是很高的数据，在浏览器和CDN缓存后，大量的请求不用经过后台服务器就可以返回给用户。对实时性要求比较高的数据，如库存数据、促销数据，仍然可以在Nginx中缓存几秒来有效地控制并发请求。除了这些常用的缓存，我们还使用了Google的PWA技术，让用户在移动端断网的情况下仍然可以浏览内容
3、降低依赖 在大型分布式系统中，如果访问量比较大，有一个系统响应慢，可能会导致整个系统崩溃效应的发生。所以，根据业务的重要性，有一些优先级比较低的服务，针对这个服务的调用超时时间可以设置得低一些。访问超时了就不返回结果，即相当于降级了，例如商品评论。还有一些服务，例如在商详页的库存查询，如果库存访问超时就默认返回1，让用户可以进入结算页下单，在结算页和下单流程中会对库存做校验
4、系统拆分，请求分散 在印尼电商平台的促销活动中，曾经发生过搜索量过大导致整个主站访问不了的情况。将搜索和主站分拆能有效地降低相互的影响，即使搜索系统出现问题，用户仍然可以浏览下单。另外，将请求进行分散也能降低单一系统的压力。在商品详情页中有价格、库存等信息，如果所有这些请求都需要经过商品详情页的服务无疑会对系统造成过大压力，而将这些请求在页面上分拆到其他域名，则能提升整个系统的承载力和稳定性。
5、串行改并行 在微服务化后，实现一个业务常常需要调用多个服务，例如实现一个业务需要调用A、B、C三个服务，如果这三个服务并不依赖对方的请求结果，那么可以并发调用这三个服务再对结果进行组合，这样能大大提升整个服务的响应时间

在研发团队规模较小、应用数比较少、人员相对稳定的情况下，以jar包复用代码的方式是能起到比较好的效果的，jar包复用避免远程RPC调用的开销，应用数较少的情况下测试成本也不高。这种方式对人员要求较高，需要大家有判定系统边界的能力并遵守规则，但在业务逐渐复杂，团队人员规模扩大，系统演进因拆分而变多的情况下，很难保证JAR中的代码是一些公共服务，结果就是jar中的代码会越来越臃肿，越来越庞大，包含各种业务，系统间耦合性越来越高，同时系统数量的增加也对研发效率造成了巨大的冲击，一个功能同时需要改多个业务系统，发布时间也在不断膨胀。

京东全球购可用性保障
1、Nginx、JIMDB、JVM多级缓存，以及数据托底，确保门户网站的高可用
2、双机房部署，防单点，确保每个机房能独立承担百分百流量
3、限流，以确保流量冲击时，系统高可用
4、依赖服务自动降级，避免非必要功能影响系统可用性
5、重新规划PC、M、App，不同平台应用彻底解耦，去除相互影响

系统的DevOps之路
1、质量保障的平台化自动化
DevOps的本质是在平台化自动化基础上的敏捷。团队正在持续迭代开发一套DevOps平台，它给面向最终用户的线上服务、数据服务和运营平台提供闭环支撑。闭环支撑包括两层含义：从系统研发的生命周期角度来看，从研发的调试环境，到测试环境，再到预发布环境，最终到线上环境部署，DevOps平台提供一致的编译方式、配置管理和部署方式，用平台化自动化方式提高研发工作的效率；从自动化运维角度来看，DevOps提供了故障管理、系统管理、变更管理、资源管理和数据管理等一整套解决方案。通过UI和自动化方式，保证运维操作准确度，提高工作效率。
2、测试从线下延伸到线上
由于平行搜索系统中业务的重要性，除了系统和应用级别的监控，我们添加了大量核心业务的监控。具体实现是通过业务测试脚本不断地验证线上服务，把测试结果写入监控数据库，并通过报表系统以时间序列展示业务状态。我们选用的监控系统架构是OpenTSDB+HBase+Grafana。监控只能看到业务历史状态，还需要告警系统第一时间把业务失效的信息通过邮件和短信方式告知相关人员，具体实现是在Icinga系统上进行二次开发。
3、大数据支撑质量管理
平行搜索系统业务涉及数千个三级类目、数十亿个商品和数亿个用户行为，我们把用户行为的大数据进行抽取、清洗、汇总和分析，定期生成测试数据。以最少的测试用例，覆盖更多的功能和用户行为，并且保证了测试用例的实效性。

浏览器端的日志采集
1、日志采集 浏览器的日志采集方式，首先需要在统计页面日志的页面中预先植入一段JavaScript脚本，当页面被浏览器加载时，会执行该脚本。脚本中预设了一些采集需求，包括收集页面信息、访问信息（访次、上下文）、业务信息、运行环境信息（浏览器信息、访问时间、访问地址）等信息。日志采集脚本在被执行后，会向服务器端发送一条HTTPS的请求，请求内容包含了收集到的日志信息。
2、服务器日志接收 日志服务器在成功接收到浏览器发送的日志请求后，立刻向浏览器发送一个请求成功的响应，日志请求的响应不影响页面的加载。日志服务器在接收到日志请求后，会对日志请求进行分析处理，包括判断其是否为爬虫、是否为刷流量行为、是否为恶意流量、是否为正常的日志请求等，对日志请求进行屏蔽和过滤，以免对下游解析和应用造成影响。
3、日志存储 服务器接收到日志请求后，会依据请求的内容及约定的格式对其进行格式化落地。例如，当前页面，上一页面、业务信息、浏览器等信息以特定的字段标识，字段之间使用特定的分隔符，整条日志以特定的格式记录下来。结合业务的时效性需求，将日志分发到实时平台或者落地成离线文件。
经过数据的收集（采集-上报-接收-存储），我们将用户在浏览器端的行为日志实时记录下来。除植入代码人工干预外，可以保证数据的准确性，数据的过滤和筛选保证了异常流量的干扰，格式化数据方便了后续的数据解析处理。

移动设备的日志采集
1、采集方式 移动设备上app应用的数据采集主要使用的是SDK工具，App应用在发版前将SDK工具集成进来，设定不同的事件行为场景，当用户触发相应的场景时，则会执行SDK相应的脚本，采集对应的行为日志。
2、日志存储 用户的各种场景都会产生日志，为了减少用户的流量损耗，我们将日志先在客户端进行缓存，并对数据进行聚合，在适当时机对数据进行加密和压缩后上报至日志服务器，同时由于数据的聚合和压缩也可以减少对服务器的请求情况。

数据产品服务
产品设计之初，主要解决两大业务痛点，首先是整合众多的数据产品，统一访问入口，统一数据分析逻辑，统一数据指标体系。另一个是快速实现各事业部的数据可视化需求。

项目经理能力要求
1、项目管理专业技能
项目、项目集和项目组合中特定领域相关的知识、技能与行为，包括项目管理专业知识和技能，同时加上业务领域的专业知识，可以称之为“硬实力”，是成为一个优秀项目经理必要但不充分条件。
2、领导力
对企业完成事业目标有帮助的领导方面及跨领域的相关知识、技能与行为，可以称之为“软技能”，通俗来说包括人际交往能力、认知能力、学习能力、管理能力、解决问题的能力、影响力以及情商等。
3、战略与商业管理
为提高工作表现以及更好地传递工作成果的相关行业和组织的知识与专业技能。作为项目经理，要懂业务，要有商业敏锐度，要看到并能够挖掘项目的意义和价值，厘清用户真正的需求和痛点，这一条特别符合由多个项目组成的项目集或项目组合的管理。

项目管理的监控阶段
1、建立问题跟踪机制，做好进度跟踪和控制
为监控项目进度与项目计划的偏差程度，项目组采取了以下问题跟踪机制：在周例会、日例会及其他渠道反馈的需跨部门协调，且无法立即解决的问题，项目经历记录到问题跟踪表中，限定解决时间，并分配责任人和责任部门；跟进人每日跟进问题解决进度，协调资源并推进问题解决，在每周五向所有干系人发送的项目周报中附上问题跟踪表，同步最新解决进展。
2、问题重要紧急程度不同，触达渠道也不同
根据问题或风险的重要紧急程度，建立不同的反馈渠道，常规问题反馈至备战接口人群，抄送备战工作小组；重要问题反馈至备战工作小组群组，抄送主管副总裁、备战总指挥及项目经理，同时在备战咚咚群中发送消息；紧急问题必须第一时间发送至微信“0级系统负责人群”，相关负责人会第一时间关注并尽快解决；重要且紧急的问题除第一时间发送至微信“0级系统负责人群”紧急处理外，还需在问题解决之后，把问题描述、原因、解决方案发送至邮件发送相关干系人，并抄送主管副总裁、备战总指挥、项目经理、备战工作小组及项目管理/接口人小组。
3、利用项目管理系统(PMP)，辅助做好项目管控
京东自研的项目管理系统——京东研发管理平台，从项目基本信息、工时填报及审批、风险和问题管理、干系人管理、项目进度管理、变更管理、成本核算等方面，对项目全方位进行管控，尤其是支持基于任务填报工时、审核工时，成本估算精细到具体任务，对项目进行高效率的指导和控制。