一、简介京东到家依托达达的高效配送和一大批优秀的零售合作伙伴，为消费者提供新鲜果蔬、日用品、医药健康、鲜花蛋糕、洗护、美妆等海量产品一小时送货上门的极致服务体验。在整个服务过程中，京东到家基于LBS连接消费者和线下商家，从而促进交易，为消费者提供便利。这背后是定位系统如何为京东到家提供基础定位能力？本文从技术角度介绍京东到家定位系统的演进过程和遇到的问题。2、定位系统有什么作用？1、业务介绍打开京东到家APP，进入首页下拉，我们可以看到附近的店铺模块，如下图所示：这个“附近”模块是定位系统的一个典型应用。图中蓝色框区域的内容为当前坐标的POI名称，红色框区域的内容为当前坐标附近的店铺信息，红色椭圆区域的内容为当前坐标之间的距离和商店。简单介绍一下实现过程：第一步，打开app，手机可以通过内置的GPS模块获取当前所在位置的经纬度；Step2，首页网关获取当前所在位置的经纬度向地址系统请求，地址系统访问对应的GIS服务获取POI信息并返回；步骤3，首页网关根据POI信息请求定位系统，定位系统返回附近商铺列表和距离信息；Step4，首页网关完成其他店铺信息，如ratings，sales，Freight等信息，返回app端展示。大致流程如下图所示：除了这个典型的应用，到家的很多系统都依赖定位系统，比如多店搜索、运费计算、提单时的跨区校验、订单时效计算等。..统计显示有50+个系统，这些系统几乎涵盖了用户的整个购物过程，仔细想想也是有道理的，到家的很多业务都是基于位置的，这是和o2o电商的一个重要区别和传统电子商务。2.核心职责从众多业务场景中总结，定位系统有两个核心职责，如下图所示：距离计算：计算两个坐标点之间的距离，大部分是店铺坐标和用户坐标之间的距离店铺定位：获取用户坐标附近的店铺信息。商店的送货范围是多种多样的。用户看到的是配送范围覆盖用户坐标的店铺。3.架构演化过程根据职责不同分为远程服务和位置服务。两种服务的演变过程。(一)远程服务直线距离这就是所谓的直线距离，实际上是一个球面距离。我们认为地球是一个规则的球体。球面上的两点可以从一系列几何公式推导出来。公式，将两点的经纬度代入公式即可计算出球面距离，这里不再展开，大家可以自行搜索相关资料。那么为什么我们需要升级呢？直线距离有什么问题？如下图所示，起点和终点之间的直线距离为390米。由于两点一河一桥相隔，实际步行距离达1766米，实际步行距离是直线距离的四倍之多。在这种情况下，向用户显示的直线距离不合理，影响用户体验；另一方面，由于达达端计算运费采用的是步行距离，到家端采用的是直线距离，双方测量的距离不一致，无形中给到家平台带来了一定的损失。基于以上原因，距离服务升级为步行距离。b.Walkingdistance计算两点之间的步行距离，因为涉及到道路规划、测距等要素，自己实现不太现实。我们使用GIS服务来计算步行距离，但距离服务被用作回家的方式。对于基础服务，同步请求GIS服务显然不能满足我们的性能需求，所以我们现在的解决方案也诞生了，如下图：大致分为两个阶段：Stage1，初始化阶段，初始化服务拉近半年订单信息，利用订单中店铺地址的经纬度和用户收货地址的经纬度结合GIS服务，计算步行距离，并初始化到距离信息数据库中。阶段2，自更新阶段，下单的老用户请求步行距离时，可以命中距离信息库中的步行距离；对于新用户，距离信息数据库无法命中，此时我们采用估计的方法步行距离，用直线距离乘以经验参数作为估计的步行距离返回给用户，新用户继续放置远程服务实时监控订单系统的订单信息，进一步丰富远程信息库。当用户再次请求距离时，距离服务可以打到图书馆的步行距离；随着用户不断下单，远程服务实时订阅订单消息，实现自动更新和自我充实。（2）基于位置的服务基于位置的服务的演进基本上分为三个阶段，如下图所示：简易家居配套发展初期，门店数量寥寥无几。将这些店铺一一列出，判断配送范围是否覆盖用户坐标。为了匹配覆盖的门店，但是随着门店的增加，这个方案不再适用，进入下一阶段。b.最小覆盖矩形计算门店配送范围的最小覆盖矩形，将所有门店的最小覆盖矩形坐标持久化到数据库中，通过SQL语句过滤掉覆盖用户坐标的门店。本方案支持一段时间到家业务的发展，随着用户量的增加，上门次数也越来越多，查询数据库的方式逐渐不能满足我们的性能需求，然后继续发展。C。基于墨卡托投影InvertedMercatorprojection墨卡托投影是正轴上的等角圆柱投影。假设在地球上截取或切割一个与地轴方向一致的圆柱体，根据等角条件，将经纬网投影到圆柱面上，将圆柱面展开成平面后，此投影为获得。经过墨卡托投影后，子午线分布均匀，纬度是一组垂直于子午线的平行直线。也就是说，经过投影，我们把球面变成了平面。墨卡托坐标系基于上述公式。经度λ和纬度θ对应的墨卡托坐标为(x\*R,y\*R)，其中R为地球半径。通过墨卡托投影，将坐标系转换为平面坐标系。因此，我国所覆盖的区域可以按照一定的规则划分为若干个大小相同的正方形区域进行标记和编号。这些方块是我们构建倒排索引的地方。根据。倒排索引假设有s1、s2、s3三个店铺，三个店铺的送货范围形状各不相同，每个方格都有自己的编号，如上图所示。正向索引：构造一个每个店铺覆盖的网格列表，即正向索引-s1:B2,C2,D2,B3,C3,D3,B4,C4,D4-s2:C1,D1,C2,D2-s3:C0,D0,E0,C1,D1,E1,D2倒排索引：依靠正向索引构建对应网格的覆盖门店列表，即倒排索引-C0:s3-C1:s2,s3-D2:s1,s2,s3-...构造倒排：store分布范围的倒排索引构造过程如下：定位过程：依赖倒排索引，定位一个store的过程如下：（3）定位服务架构采用倒排索引方案实现了基于位置的服务，大大提高了基于位置服务的性能。系统不再是业务发展的瓶颈。当覆盖区域发生变化时，节点需要重建相应的倒排信息，同步店铺的基本信息。后台web：处理换店消息，构建相应的正向索引，生成换店任务供服务节点使用。3、问题与优化结构趋于稳定，但随着业务的发展，也出现了一些新的问题。针对这些问题我们也做了进一步的优化。1.新问题定位精度不够。如下图，虽然店铺的配送范围覆盖了格子，但是红色标注的区域其实不在店铺的配送范围内。实际操作过程中出现过很多类似的问题。给商家和用户带来了困扰。瞬时流量影响服务稳定性。平台上有一些店铺配送范围特别大。例如，花店的配送范围覆盖了整个城市。由于倒排索引的构建会在各个服务节点进行，一旦此类门店下线，服务节点性能波动较大，导致调用超时。JVM内存暴涨。由于倒排索引存储在服务节点的JVM内存中，因此存储的数量不断增加，JVM占用的内存也越来越大，达到了22G+。大内存下的GC时间也会随着服务器的运行而增加，yongGC时间过长，这会影响服务的响应时间。一旦oldGC服务发生，该服务将处于不可用状态。这个问题相当严重。2.优化策略精准定位，在定位过程中加入实时计算覆盖模块，过滤掉不覆盖用户坐标的店铺。后索引和流量调峰优化架构的服务架构也进行了一些调整。新的架构如图：3.优化效果经过这次优化，问题得到很好的解决。数据对比如下图所示。值得一提的是，该服务的平均性能从原来的2ms提升到了4ms。虽然响应时间有所增加，但增加幅度完全在业务可接受的范围内，收益还是比较明显的。不再需要大内存机器来支持服务，节省了资源，也不再需要定期手动GC，降低了人工运维的成本。服务性能更稳定，响应时间不会再有较大波动，为到家提供核心定位和远程服务。随着到家平台的不断发展，定位系统也在进化和优化。每一次演进和优化，都是朝着提供稳定、高可用服务的目标迈出坚实的一步。家居业务的快速发展提供了有力保障。作者简介：赵帅，软件工程师，就职于京东到家后台研发部，负责交易、售后、定位、api网关等系统。【本文来自专栏作者张凯涛微信公众号（凯涛的博客）公众号id：kaitao-1234567】点此查看作者更多好文
