Introduction

Established in 2008,Longtu Game has over 600 staffs and was established by a core team led by Mr.Yang Shenghui,a graduate of Tsinghua University.Headquartered in Beijing,with branches in Shenzhen,Tianjin,Seoul,and other territories,Longtu Game is dedicated to developing and operating online games.Now,it is one of leading game developers and publishers in China. Yulgang:Mobile,Tales of Cuties,MU:The Mighty,New Sword and Magic,POP LINE2,etc.are all highly claimed by players.

Why TARS

Our company has many R & D lines, different languages ​​and platforms used by different R & D teams, and the company does not have a unified technical framework. The problems it faces are low development communication efficiency and high operation and maintenance costs between the teams. In addition, the performance of RPC calls implemented by some teams is also problematic.
TARS is available in multiple languages ​​such as C ++ / Node.JS / Java / PHP / Golang, which can open up technical language barriers for all teams in the company. At the same time, the performance of its RPC has passed the rigorous test of Tencent and other manufacturers, and the test results are very good. Its built-in operation and maintenance platform allows development to focus on logic only, and disaster recovery / release / monitoring / scheduling is fully automated.

Use of TARS

So far, the company is still in the process of advancing game development at a high speed. The use of TARS is mainly pre-researched on its language support and RPC performance improvement. Later, it will use TARS more to improve service calls and network protocol performance. The operation support team used TARS to transform some services, and the performance has been greatly improved after testing. At the same time, we have explored the use of TARS in containers and deployment methods on Kubernetes, and these results have also contributed to the TARS community.

Performance testing of TARS

We have implemented a go server with redis cache; gRPC currently only supports the client in PHP, so using its development method generated the PHP client code ad_grpc.php and implemented the same ad.php as before (using tars) Logic (also added client-side redis cache). From the results of the stress test

1. gRPC service is relatively stable without failure;
2. The time consumption of the service is also relatively stable, but using pure php and using tars takes 3-8 times more time, which has a limited improvement over the gRPC test results without using the redis cache;
3. The system overhead of the PHP client (Nginx) is still high, and some optimizations have been tried, and the possible optimization methods still need to be adjusted;
4. The pressure of the Mysql server is small, with 13 connections.

Combining the results of the non-cached gRPC test with the test results, from a development perspective, the development process of gRPC is similar to Tars. After the message interface is defined, the tool automatically generates the server and client stub code. The developer only needs to implement the interface. And calling interface; from the perspective of deployment, Tars needs to be more complete, and Tars provides a web interface for service management. GRPC should be developed and implemented by itself. From the perspective of PHP client overhead, gRPC costs more than TARS does.

Conclusion

TARS is a high-performance RPC framework, which is very friendly to support different languages. It also has an active community. If the company team is integrated and the development language is not uniform, it is a good way for companys to coordinate the construction of the company's microservice system.