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前身Taxi Go在3年前上线时，便选择以聊天机器人，来提供叫车服务，黄佩恩也分享了聊天机器人的优缺点。相较App，聊天机器人有导入用户快速、成本低、回应人性化等优点，但，用户需进入Line App并加入服务的官方帐号后，才能进行注册，使Line Taxi无法追蹤用户来源，掌握用户是透过何则广告接触到服务。

黄佩恩与团队经过多方尝试，最后，他们在注册对话讯息内加入了一个巧思，嵌入追蹤像素，相当于一个网址连结。当用户点击注册按钮，后端API伺服器会比对用户点击广告时，于伺服器里留下的记录，前后比对，来掌握用户的来源。黄佩恩表示，这个设计就像是发送电子邮件时，追蹤收件者是否有读取信件的方式。

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