爱用科技CTO 江树源
本文讲述了在电商新零售行业下，电商服务商爱用科技如何借助Elasticsearch，应对在业务系统中的大规模交易订单数据管理，以及全观测日志运维场景下的痛点和挑战，为其百万电商商家用户提供稳定高效的商家服务。
爱用交易，实现交易全流程管理
随着10年来零售经验的积累，阿里零售云内汇聚了一批拥有天然的场景、业务数据流以及客户网的电商服务商。这些电商服务商通过其全面的零售产品，帮助数百万家品牌商家快速构建业务场景。
爱用科技是基于淘宝服务平台的最早一批应用软件与信息技术服务提供商之一。专注为淘宝电商商家提供包含订单处理、商品管理、分销供应、数据分析、营销打折等功能的软件产品，目前已经服务于400万淘宝商家。
在交易管理场景，爱用科技基于“爱用交易”这款交易管理软件，支持卖家用户从接单、订单管理、打印发货、物流跟踪、到评价管理实现全流程管理覆盖，付费版本还支持更多自动、批量操作等功能，帮助卖家用户高效、实时管理订单动态。
订单管理中心是整个爱用交易管理的核心模块，订单管理下通常包括各个状态的不同订单：等待买家付款的订单、等待您发货的订单、已发货的订单、退款中的订单、需要您评价的订单、已成功交易的订单、及订单查询模块。而对于不同状态的订单状态，会显示不同的订单信息，并在订单详情页支持不同的操作。如【待付款】的订单，会显示订单编号、买家ID、待付款等待时间、备忘、订单状态、详情，是否关闭订单、宝贝属性、实收款（包括价格与运费）、旺旺是否在线等；而【待发货】的订单，则会显示订单订单编号、成交时间、卖家备忘、宝贝名称、宝贝属性、详情、宝贝价格等。
爱用交易为商家用户，提供了非常丰富和强大的订单查询能力，可以支持通过订单号、买家昵称、关键词、收件人姓名、手机号、运单号、收货地址、交易时间以及卖家备注、买家留言等等非常全面的订单信息字段进行各类高级查询、筛选和标签过滤，同时也支持卖家进行不同维度的订单排序，比如拍下时间或者商品的SKU排序等。
在这样的业务场景下，交易订单作为电商系统的"纽带"贯穿了整个系统的关键流程，承载着所有购买信息与支付信息。在618、双11等各种大促的高流量下，不论是各类独立品牌商家，还是我们爱用科技这样的电商服务商，极高并发的订单查询请求，给整个订单系统的对接效率、处理能力、灾备能力，系统互通效率，都带来了极大的考验。
与此同时，大规模业务数据带来的是，更为复杂的日志分析与系统运维工作。如何收集分散在各层的日志、指标数据，进行集中的收集存储、并完成后续的分析监控，快速搭建整套日志平台，以保障整体业务的平稳运行，也是我们在业务发展过程中所持续面临的问题。
方案架构：基于Elasticsearch的订单检索
在接触阿里云Elasticsearch整体产品与方案前，我们仅依靠传统关系型数据库实现业务系统的订单检索，随着业务的发展，检索延迟高、效率差的问题日益明显，主要体现在以下几点：
海量数据带来性能和稳定性瓶颈：电商行业遇到诸如大促的业务高峰期，会产生高达百万、千万级的订单数据量，面对这样的高流量、高并发查询，关系型数据库有天然的处理瓶颈，对整体系统稳定性的巨大挑战。
复杂字段与查询条件导致查询效率低：电商订单往往包含复杂的商品信息、优惠、用户、地址等多维度字段信息。在商家进行订单查询过程中，往往存在大量的模糊查询场景，如不完整的卖家地址或昵称等。DB在复杂条件下查询能力弱，对模糊匹配的处理效率低，仅仅依靠关系型数据库，无法满足订单系统的检索需求。
面对流量波动缺乏灵活伸缩能力：为顺利承载活动带来的流量，电商这个行业具有明显的业务波动，一方面，高峰流量所需要的临时扩容，带来了极大的人力运维成本；另一方面，业务低峰期的闲置机器也是极大的资源成本浪费。
说到检索能力，我们开始学习和考虑业内最主流的全文检索引擎Elasticsearch。它在DB-Engine指数排行上是全球热度No.7的数据库、No.1的检索引擎。可在PB级数据中找到匹配信息，并具备毫秒级数据时效性，能够快速处理文本、数字、日期、IP 以及地理数据等各类数据类型。面对订单场景，数据膨胀会导致传统数据库方案逐渐暴露性能、查询能力的瓶颈，横向的膨胀即不断迭代引入的新字段维度，纵向即总的存储数据量。而Elasticsearch可作为关系型数据库二级索引，弥补原先传统关系型数据库在大数据量、高并发查询的局限性，混合应用从而实现能力和性能上的互补。
因此，基于这样的能力和背景，我们整体系统的订单查询能力，正是基于MySQL+Elasticsearch组合方案实现的。我们爱用主要服务于淘宝的长尾商家，对于这些小微商家，每天的订单量可能不超过200单，而目前这类商家客户数量在40万左右，因此我们主要通过建立集中存储的存储集群和计算集群，进行订单数据的集中管理。在零售云内，部分其他的服务商，当单个商家体量达到一定规模时，也会为单个商家建立独立的运算集群，也就是MySQL/PG/ADS/ES等等存储和计算资源都是独立的。
Part1 ：分库分表和集中索引方案
在整个系统链路中，我们将业务应用服务系统将全部商家的全量订单数据存入MySql数据库，对订单数据用商家ID取模的形式进行分库分表，作为持久化存储；同时将需要检索的字段和基础属性字段存入Elasticsearch，提供可以应付维度膨胀的订单数据，在复杂查询、模糊匹配场景下借助Elasticsearch的检索能力，必要时反查MySql获取订单完整信息。
Part2：数据全增量同步方案
关于从数据库到Elasticsearch的数据同步，通用方案可借助云上产品或开源方案实现MySQL向ES进行全量数据同步，当业务系统产生业务表信息变更时，由增量数据更新的方式补充/变更ES中的数据。增量更新主要是以mysql binlog订阅的方式，利用DTS、Canal、Logstash或DataWorks等多种工具实现。这其中会有几个常见问题，一方面，通过MySQL到ES增量同步会有一定的延迟，当RDS主库产生较大负载，会无法保证ES的数据写入；而Canal在实际的测试过程中有数据延迟和数据丢失，需要每天晚上再手动做一次同步。
这种情况下，我们为保证数据的时效性，选择了另一种方案，直接通过业务系统实现对MySQL和ES双写，自行保证两条链路的质量。并在业务端通过补偿脚本，保证两条链路的数据均写入成功才算写入成功，否则会回滚重试，以保证整体数据一致性。
Part3：索引方式和字段定义
在订单检索场景下，将需要检索的字段和基础属性字段存入Elasticsearch。在这个流程中的海量数据，可以通过hash映射将海量数据分割成相应的小块数据，然后再针对各个小块数据通过hash_map进行统计或其它操作。
如果将所有数据均分在几十个节点中，虽然能保证写入无法满足实时高效的查询要求。因此，在整个订单数据索引中可以采用双分片处理，首先对商家ID进行哈希处理，将商家ID聚集在某个小片的集合里，再通过相应的routing设置。同时，再对订单进行哈希，从而保证整体查询的高效性。
Part4：云上ES服务能力和优势
相比于自建的Elasticsearch方案，最终选择阿里云Elasticsearch，也是考虑云托管服务本身，所具备的弹性平滑扩缩、以及在安全方面更加丰富的能力。
一方面，云上ES服务可以帮助我们在较短的时间在集群中拉起新的节点或者使用更高规格的节点，而不需要考虑供应链上潜在的问题，来扛住大促这种情况下的流量洪峰，并且扩容过程平滑对业务无影响。同理，当负载降低时，我们也能够减少节点个数，只针对非高峰时段的流量保有计算资源，触发并完成集群缩容，从而在满足业务需求的同时，降低在非大促的日常经营期间的业务成本。
而为了保证服务的高可用性，尽可能降低系统的数据存储、安全访问等可能造成的风险，阿里云Elasticsearch为我们直接提供了OSS备份、多可用区、CCR跨集群实时同步等多种容灾能力。
相比于开源ES服务，阿里云Elasticsearch还免费提供各类X-pack功能，在安全和权限管理上，具备更加全面和专业的安全特性。尤其是对于我们这种服务商，在面向多个商家提供服务时，有强数据权限的管控需求，而阿里云ES基于X-pack安全插件能够支持精确到字段级别的数据权限分割能力链接，从而为我们的商家客户提供灵活的用户-角色-权限定制能力，在数据共享、访问隔离、防止误操作及泄露等方面，实现了更强的权限控制。
总体而言，通过以上这些方案，我们实现了订单查询服务的整体架构的升级改造，不仅借助Elasticsearch作为数据库二级索引，达到了毫秒级数据时效性的准实时查询，带来了近一倍的IOPS大幅提升；也降低了MySql主数据库的查询压力，避免了高并发查询下造成的写入数据丢失风险。
与初始的架构方案相比，这套利用Elasticsearch实现的订单检索方案，在资源方面为我们降低了50%的成本。而基于ES的检索能力、数据权限体系再进一步进行上层的业务封装，为各个商家提供在客户端、移动端的订单管理。最终完美的实现了我们爱用科技对客户的承诺——“在1~5s内进行所有订单数据的检索和打单发货”。
方案架构：基于Elasticsearch的全观测运维方案
除了订单场景外，系统及日志运维也是我们爱用科技使用Elasticsearch的另一个重要场景。随着技术的发展演进，Docker微服务化的技术架构被越来越多的企业所采用，同时带来容器中各种日志统一收集和分析的需求。各大服务商纷纷进行服务和技术升级，整体架构越来越复杂，多种服务器、存储、网络设备、安全设备，基础设施与架构的复杂化给我们带来的是更加海量的数据。
另一方面，服务的分布化导致数据的集中和追溯困难，各层业务服务之间的调用错综复杂，由此带来全链路的监控诉求，而服务的分布化，增加了链路上各个环节的故障分析排查难度。对于我们爱用科技或者其他服务商而言，开发运维的结合对我们的技术同学带来了更高的要求，随着大数据应用发展，开发与运维环节紧密结合，共享同样的信息来源，更需要对日志、指标、APM进行立体、统一观察分析， 通过“全观测”打破数据与工具之间的壁垒。
基于以上的问题，我们也需要一套更成熟的方案，不仅实现容器、业务系统日志的收集、集中存储、搜索分析，并可以快速搭建上线的日志分析系统。经过多方选型后，我们决定通过ELK体系搭建集中的日志分析平台。
众所周知，在运维监控全观测方面，Elastic Stack包含Beats、Logstash、Kibana的整套产品生态组件，具备对多种数据类型和数据来源的采集能力、同时可支持进行灵活的数据结构化处理，并最终实现可视化分析与监控。这样一整套具备端到端能力的产品组件，都已经在阿里云Elasticsearch平台上实现了全托管。
借助这样的方案，我们可以充分利用分散在系统各层的日志、指标、APM数据，在较短的时间内，快速的搭建一套完善的智能诊断与分析、智能监控报警的全观测平台，更好的发挥整体业务流程中的各类数据价值，进行业务情况的实时追踪。目前，已在线上环境稳定运行，也为我们在整体系统和服务的运维成本方面带来了大幅降低。
远不止电商新零售下的Elasticsearch与商家服务
放眼未来，包含我们爱用科技在内的广大服务商还在不断调研和开发基于Elasticsearch更多图片、音视频检索、以及智能客服等更多的场景应用；同时，基于Elastic Stack打造更完善的业务数据、指标分析大盘。探索在新零售以及新场景下，如何更好的为广大商家客户提供商家服务，实现业务的快速发展。
我们也相信，阿里云Elasticsearch所具备的检索能力和方案不仅仅只是在订单场景下的应用；而全托管下的Elastic Stack全链路观测分析能力，在所有电商之外其他的行业和领域，一定会有更多的企业和服务商，有更多更好的运用实践方案。也欢迎大家交流分享。
谢谢大家。
更多大数据客户实战案例：https://developer.aliyun.com/article/772449
