公司级通用业务如呼叫中心，需要查询各业务线订单，对接业务工程繁琐。
订单数据没有统一的整合，不利于订单的统计与分析。
用户订单列表强行区分业务线，用户体验差。
订单数据格式与状态不统一，业务跨业务线使用不方便。
订单中心概况介绍订单中心主要提供以下功能。通用订单查询接口，根据手机号、用户名、客户端设备号、订单号等多维度查询订单，用于呼叫中心、业务线。订单变更消息，比较每次订单变更内容，发送消息，用于订单类提醒与推荐类业务。订单列表，提供统一基于用户的通用订单列表。订单数据仓库，统一存储订单数据，建立统一用户画像。1订单中心使用订单中心承载各终端订单列表服务。
Web订单列表
订单卡片：
订单列表：
订单中心接口目前每天承载上亿请求。
订单中心数据量。根据以上对订单中心业务的分析，订单中心主要有以下几个特点：提供通用服务，提供一套通用的存储结构与接口抽象，供不同场景使用。
保证服务可靠，订单中心对接公司各业务部门，需保证部分业务问题时，订单中心其他业务的服务整体可用。
订单中心1.01JSON存储于MySQL二级索引订单中心设计在存储结构上采用非结构化方式存储，订单内容保存到订单表content字段中，通过配置文件配置抽取业务线订单数据中索引字段，将其保存到订单索引表中。通过这种设计，订单中心将公司不同垂类的订单数据统一化到相同的数据结构中，不同业务垂类的订单通过配置文件抽取业务订单中心的通用查询索引，方便订单中心内部使用。订单中心接收业务线通知消息，消息保存在Task表中(用于错误异常处理)，保存后抓取业务线提供的订单接口，检查业务线返回数据正确后，调用业务模块保存订单。业务模块保存订单时首先根据业务线与配置文件抽出订单索引数据，分别将订单索引与订单数据保存到订单索引表与订单数据表中。最后根据订单数据的变更发送订单变更消息。2基于JSON的Merge与Diff通用服务订单中心核心逻辑是基于JSON的Merge与Diff实现，基于Merge与DIff提供订单消息变更事件与订单操作。抽象各业务操作与数据结构。订单保存后，根据本次订单数据变化(JSONDiff)发送订单变化消息，配置文件匹配变更内容发送订单事件消息。抽象订单数据变化与核心事件变化，将通用参数从业务中抽象出来，通过配置文件的形式，灵活配置。订单操作时例如删除订单操作，订单中心会根据用户请求构建一块业务JSON，将业务JSON与订单库内部的数据进行合并。3异步IO抓取业务线接口订单中心需要对接公司各业务线，不同业务线接口相应时间与可靠性各不相同。这就对订单中心整体可靠性可用性造成了较大挑战。为此订单中心在集成各业务接口的时候使用的是全异步的方式，当某一个或多个业务的接口出现高延迟甚至不可用的时候，不会阻塞订单中心的调用线程，并且会自动的降级(比如不显示该业务订单的动态信息)。4订单中心1.0架构图订单中心1.0版本中同步负责订单同步，用户接口负责业务灵活动态数据请求，业务核心模块负责，存储于核心业务逻辑。列表模块负责前端交互。5订单中心1.0存在的挑战随着业务的不断接入，查询订单的条件也不断多样化。订单中心最初构建时使用内存过滤解决业务查询的多样化，内存过滤采用流式的方式从数据库中获取订单在内存中通过逻辑过滤。添加新的过滤条件时，订单中心需要做相应开发。订单单库的容量已经无法满足业务发展的需求。订单中心2.01引入ElasticSearchElasticSearch是一个基于Lucene的搜索服务器。它提供了一个分布式多用户能力的全文搜索引擎，基于RESTfulweb接口。Elasticsearch是用Java开发的，并作为Apache许可条款下的开放源码发布，是当前流行的企业级搜索引擎。设计用于云计算中，能够达到实时搜索，稳定，可靠，快速，安装使用方便。为了解决订单中心查询条件多样化的需求，订单中心在15年初引入了ES，用于灵活的提供订单中心条件支持，辅助支持MySQL索引。订单中心使用ES中采用全订单字段索引，动态模板。按照业务与年份划分索引块。ES数据同步采用消息驱动的方式，订单数据发生变更后，ES端监听消息，查询数据库中字段，更新ES数据索引。采用消息驱动方式原因为订单中心内部有统一内容变更消息，consumer端逻辑处理简单，通过订单自版本号处理ES并发更新。2订单数据扩容与索引拆分随着公司业务的快速发展，Qunar的订单也在增长，订单数据面临着容量拆分。订单库拆分首先面临几个问题。复杂的底层存储结构。
订单索引与订单数据保证一致性。
数据变更类消息，保证正确性。
历史数据的不断增加。
订单中心在自己的实践中，引入了TC提供的QClientDB数据中间层来屏蔽数据库复杂的结构。使用QMQ可靠消息中间件，来保证订单数据与订单索引数据的一致性。通过内部与外部消息隔离的模式，解决外部读取数据时的正确性。历史数据上，订单中心将一段时间前的历史数据导入HBase中，线上保留近期数据。订单中心内部采用消息驱动的形式。订单数据保存后，对内发送消息。MySQL订单索引，ES索引与HBase，每个数据源更新完成后，发送ack消息。ack消息接收端，更新更新记录表，全部数据源ack后，对公司广播消息。3订单中心2.0架构图订单中心2.0版本中主要将存储层进行了优化，将索引与数据进行了分离。抽象出ES模块单独负责Es存储的查询。订单中心3.01业务隔离与业务限流订单中心在2月份出现一次严重故障，故障原因是黄牛用户高流量导致服务不可用。公司黄牛用户订单多，个别黄牛用户3月内订单高达几十万订单。黄牛用户大量订单与内存过滤结合，造成应用内大量数据堆积，内存无法释放，造成应用频繁FullGC，出现故障。通过这次故障教训，订单中心完全的废弃了内存过滤模式，引入了通用的业务限流模块，业务与用户特征进行隔离，多维度防护系统。我们在用户接口模块中根据用户特性，将请求分流到不同核心业务服务器中，两部分用户使用两套数据库，从而在业务层与数据层将用户隔离。限流服务中，订单中心根据应用维度、用户维度等多维度进行限流。在日常运行阶段，根据用户特性与请求频率，对请求量过高的用户进行限流。因订单中心对接公司所有业务线，业务线的可用性各不相同，在同步任务模块与动态数据获取模块中，我们引入了隔离机制，通过动态配置，将问题业务线与正常业务线隔离，保证订单中心总体可用性。2订单适配层订单中心接入无线订单列表后，面临着客户端版本迭代与版本兼容问题，为此订单中心引入了订单适配层。查询订单中心主模块后，经过订单适配模块，适配层使用Groovy脚本，脚本在QConfig中管理，业务同学可以编辑脚本，完成快速修复线上兼容bug与灵活业务线使用目的。3微服务化与配置中心随着业务的发展，订单中心业务核心模块，内部承载了过多业务。根据业务特点与内部逻辑。我们将订单中心核心业务模块中拆分，MySQL索引模块、订单存储模块。随着模块的拆分，业务配置不断零散化，订单中心添加新业务时，修改众多模块系统，导致系统发布流程长，回归难度增大。订单中心基于以上问题，单独抽出了配置模块，配置系统整合各模块通用的配置，不同系统通过选用不同的解析器完成对配置解析。配置系统统一管理与分发通用配置。4订单中心3.0结构订单中心3.0版本中，对核心业务模块进行了拆分，提出基础服务层，基础服务层，保证服务稳定性。抽象出配置中心与适配层，增加开发效率与灵活度。去哪儿技术嘉年华去哪儿工程师内部学习交流平台。秉承务实、创新的宗旨，致力于促进公司内部各开发团队之间技术业务交流，促进个人以及团队能力提升，营造技术学习文化氛围。年技术嘉年华分三个场次：Qmobile-移动端开发方向、Qdata-数据相关方向、Qarch-业务系统架构方向，分别在8月三个周六进行；我们也邀请了携程、艺龙的小伙伴共同分享交流。本文根据Qarch上主题演讲内容编辑整理，方便更多小伙伴一起来交流学习。更多精彩请继续专业治疗白癜风医院天津市白癜风医院