Line Taxi上线逾半年，CTO首度对外分享叫车服务的技术挑战，并揭露每日可处理千万笔资料量的架构设计

在台有逾2千万活跃月用户数的Line，不断扩大平台功能，去年底，其把用自家聊天机器人来提供叫车服务的TaxiGo，也纳入生态系，成为叫车平台Line Taxi。

如今，Line Taxi上线逾半年，注册会员数已突破80万，并有超过6千位司机，提供载客服务。随着用户数逐渐成长，Line Taxi服务背后的架构现每日需处理超过千万笔资料，Line Taxi技术长同时也是服务共同创办人的黄佩恩，日前在一场技术分享会上，揭露服务至2017年上线以来，背后架构的转变。

黄佩恩回顾服务架构最初的样貌。刚上线时，服务架构仅由API服务器、Bot服务器和数据库所组成，半年后，由于用户数不断的增长，进入系统主机的流量也连带增加，架构缺乏扩展性和弹性的问题逐渐浮现。

庞大的数据库流量，是Line Taxi首先面临的架构瓶颈，而数据库流量主要的来源，就属派遣作业。网络叫车服务藉派遣作业，来配对司机和叫车用户，需不断将车辆所在地资讯记录于数据库。原先，车辆位置只要一有变动，就需回报资讯给系统，这虽能精准地掌握车辆位置，但每秒回传数笔资料，却带给系统庞大的流量压力。

于是，Line Taxi技术团队调整了派遣逻辑，从掌握车辆定位点每一次的变化，一秒便回传多笔资料，调整为，车辆若不在服务旅程期间，每12秒回报一次其所在地资讯即可，而若车辆处于服务旅程中，再提高资讯回报的频率，以掌握车辆即时位置。经调整后，除大大减少了数据库流量，且黄佩恩表示，数据库成本更只剩原先的八分之一。

此外，Line Taxi也从单一数据库的结构，走向多数据库组成的应用资料储存空间，分别是关联性数据库、开源内存数据库Redis、NoSQL数据库和储存空间，来分散资料流量。黄佩恩表示，团队依照资料类型，来选择资料的储存处，她举例，像是NoSQL数据库储存的是电话记录、行程路径等，而关联性数据库储存的则是维运面资料，如司机行驾照。

除了调整派遣逻辑，还有改变数据库的结构设计，来减少数据库流量带给系统的负荷外，技术团队也重新改造整体系统架构，以提升架构的稳定性和扩展性。考量架构的稳定性，Line Taxi增加了负载平衡机制的设计，流量现进入系统时，会先由负载平衡器进行分流。

另外，API服务器、Bot服务器和新增的Web服务器，皆从单一台服务器支援服务的设计，调整为多台服务器架构，来满足扩展性需求，且各类服务器会依据服务的使用量，利用自动扩充功能来调整服务器数量，以因应服务量。Line Taxi技术长黄佩恩直言，过去，一旦一台服务器故障，整个服务就会停摆，很恐怖。

用户数增长除使系统面临流量上的压力，原先派遣逻辑的设计也遭受了挑战。过去，派遣器依单笔叫车需求，分配邻近所有车辆来与用户做配对，因此，一旦有其他用户同时或相隔不久叫车，而该地区却没有可受派遣的新车辆出现，就会发生无车可派的状况。黄佩恩表示，尤其又以上下班高峰时间，最常出现这个问题。

为解决叫车需求集中出现时，服务遭遇的无车可派情形，Line Taxi技术团队修改了派遣逻辑，改以全局派遣机制来因应。现在，分派器在派遣车辆时，会同时掌握当下的叫车用户数量，以及可受派遣车辆数量，来平均分配车辆给该期间内的所有叫车用户，让各用户都有车辆可进行配对。黄佩恩表示，系统每2秒会掌握一次需配对的用户数量。

不过，派遣逻辑仍还是有待优化的空间，那就是，如何依车辆的位置，还有用户的行程路径，来安排最相宜的两者配对，因为仅只考量车辆与用户间的相对位置，是不够的。黄佩恩指出，车辆行驶方向、GPS定位误差等，都会影响车辆抵达用户所在地所需要的时间，她进一步表示，未来计划纳入图资，来优化派遣逻辑。

在不断改善技术设计的同时，Line Taxi也在持续拓展新的商业模式。近日，Line Taxi通过了交通部多元化计程车的审核，将招募多元计程车司机，采系统计算里程并提前预告车资的方式，取代跳表计费，提供叫车服务。Line Taxi计划先在台北市试行多元化计程车的服务，之后，再逐步扩展到新北市与其他县市。文⊙黄郁芸