日本最大的社交APP Line的服务架构（1）

前言：

在2012年，在一家日本的小公司工作，主要负责了面向一款面向企业用户的聊天类APP的服务器和客户端的设计开发。app画面和功能主要参照的是日本当时刚火起来的Line，服务器用的是Http，当时觉得自己做的东西特别土,一直在想Line或者微信的架构是什么样的。过去了好几年，当时开发的这款APP也已经成为这家公司的主打产品了。2015年的日本杂志也推出一个连载，大概介绍了Line的服务器架构。竟然发现很多原理是一样的，感觉到大道至简，殊途同归，http并不落后，关键在于如何完善和使用。
于是想把这篇文件的主要部分转译过来，当作对自己曾经工作过认真思考过的一段过程的一个纪念,和一次再学习再提升。

LINE的服务端架构

LINE主要是聊天服务，除了聊天消息处理外，也提供了一些其他的服务。
如图 1.其中Talk Server是聊天消息服务的核心程序。除此之外，也有比如用作语音通信的VOIP服务，时间轴服务，这些都是独立的服务，通过API来协同工作。

聊天服务的架构

前端服务器和后端服务器

客户端通过负载平衡服务器跟前端和后端服务器通信。前端服务器实际为后端的代理服务器（reverse proxy），后端服务器即为实际的Talk服务器，构成和一般的Web服务是相同的。前端服务器为自己开发的LEGY。LEGY和Talk服务器在后章介绍。

存储

主要是使用Redis和HBase，详细在后章介绍

图2，现在的LINE的服务器通信简单架构

图3，服务初期的服务器通信简单架构

LINE的核心 Talk-Server

Talk-Server的作用

Talk服务器是Line的核心程序服务器。主要用途有两点，配送消息和社交关系的管理

配送消息

配送消息即为将文字图像等发送到用户的客户端。如果用户的客户端没有启动，就会推送通知。用户看到通知打开客户端，就会如上图2，3，到服务器来获取，服务器从存储中取出，给客户

社交关系的管理

为了正确的配送消息，也需要对用户的社交关系进行管理。另外还实现了
- 通过电话簿建立社交关系
- 通过检索ID，寻找好友
- 通过物理位置等寻找好友

Talk-Server的开发

Talk服务器是基于Java的Servlet的服务，通过Tomcat来运行。与传统的网页服务不同的地方是，使用了Apache Thrift的字节协议，这样的话确保了API的可扩展性。利用了Spring Framework来实现了DI。利用AOP的开发方式，有效的利用了认证，日志，监控等功能。

自己开发的高速通信代理前端LEGY

LEGY的作用

请求路由

负责路由，是前端代理的基本功能。代理请求，根据请求的种类，选择不同的后端来恢复。

客户端和后端的协议转换

Line的客户端和前端服务器间是SPDY协议，后端的服务器是正常的HTTP服务器。因此LEGY将SPDY变换成HTTP同后端通信。

客户端的连接管理

因为LINE需要即时的与客户端通信，因此需要尽可能的维持与客户端的连接。所以前端还有一个功能是管理客户端与服务器的连接状况。

LEGY的开发

LEGY是使用Erlang来开发的，之前是使用Nginx和相关的模块来开发的。现在更适合轻量级的并行处理和大规模的连接管理

微服务架构的高速开发

现在LINE使用微服务架构

微服务架构的好处

便于服务器的分开配置
便于代码的分离开发
便于开发团队的分离管理

根据产品的状况来选择架构

初期是用一个完整的代码来实现所有的功能。
在用户和功能不断扩大后，开发团队也在扩大，现在改成了微服务架构

微服务架构的基础框架技术

API基架

微服务环境的性能分析

横向的日志收集
分散存储系统zipkin,来监控API的调用情况

总结

LINE选择的技术，都是随着发展的过程中，不断试错的选择结果。将来也会随着成长，不能进行技术更新。