As a fresh graduate, after entering the Reading Group and joining the Universal Platform Center, with the gradual deepening of my daily work, I gradually understand the technical system of reading, especially the Tencent TARS platform is the most important. At present, the TRAS platform carries most of the services inside the reading article. The daily maximum number of interface calls is nearly 10 billion. The peak value of a single service can be tens of thousands per second and nearly 300 business services. As a newcomer, let me talk about some of the knowledge points I have compiled during my journey from TARS Xiaobai to skilled workers.
TARS File
As a service governance framework, the most basic thing is to solve the problem of calling between services. This introduces a problem: how to publish interface protocols between multiple services. TARS innovatively designs an interface description language, that is, a TARS file. In the TARS file, you can write models, interfaces, and enumerations. On the service provider side, we can parse the TARS file through the tars-maven-plugin to generate the corresponding model, interface, and enumeration code, and then write the business logic in the interface implementation class. When providing services externally, the caller only needs to get the service provider's TARS file to understand all the interfaces and related descriptions provided by the service, so as to generate the client call code and make the service interface call.
Within the reading, we also provide a unified TARS management center, where we can find all the TARS files that have been uploaded to the management center, thereby avoiding the inconvenience caused by passing the TARS files offline; the management center supports the Tars files Automatically package into a jar package and publish it to the company's Maven image, eliminating the trouble caused by your own compilation.
Service deployment
To deploy services on the TARS platform, you only need to configure the code warehouse address to the TARS platform, select branches, choose a compiler, compile, package, and release in batches to deploy to the TARS platform. Currently, the TARS platform supports physical machine deployment, Docker deployment, and mixed deployment of physical machines and Docker, which greatly improves the experience of use and meets the diversity of service releases. At the same time, the TARS platform also supports special processing for each server. For example, you can choose a server to be set to no traffic for online interface testing, and you can modify the private template of a server for service settings, JVM settings, and log settings Modifications. These provide more methods and possibilities for daily development, testing, and troubleshooting.
When publishing online services, the TARS platform only supports specified tags for compilation and packaging, thereby standardizing the operation of service publishing in the process. In addition, the release can be customized in batches and non-destructive releases to minimize online service jitter caused by service restarts.
Service monitoring
The TARS platform provides multi-dimensional and diverse service monitoring and feature monitoring. Service monitoring options include traffic, average time, abnormal rate, timeout rate, etc., you can freely choose the time range, business name of the calling party, IP of the calling party, IP of the called party, and interface name, thereby narrowing the monitoring scope and facilitating positioning problem. Feature monitoring provides monitoring of features such as JVM memory, heap usage, threads, and request queues for each server, thereby enabling problem location from the server JVM level. These monitoring are currently performed at 5-minute intervals, and it is expected that the TARS platform will provide more fine-grained time monitoring in the future.
Service monitoring also provides the function of real-time data, real-time observation of the service's second-level operating conditions, and plays an important role in locating online problems.
Log
TARS-JAVA comes with a log system, which provides the basic functions of the log class. It supports asynchronous output, supports multiple log levels, and the log level can be modified in real time directly on the management platform of TARS by modifying the private template or sending a set log level command to the TARS service to achieve platform consistency. It also supports exception output, which makes it easy to print exception logs. The logging system does not require additional configuration files and does not need to rewrite the loading configuration (when using the sl4j logging system in the services.xml application, the initialization of the logging system needs to be arranged after the configuration file is loaded; sl4j logging is used in springboot applications System, you need to write the logic to reload the configuration file). Currently, the logging system provided by TARS is used as the only logging system in many projects.
However, it should be noted that the default log encoding of the log system is GBK format. When you use the remote shell tool parsed by UTF-8 to view the logs, you often find that some log contents are lost or garbled. You can adjust the encoding format of the remote tool to a GBK compatible encoding as needed, or use a tool such as iconv to convert the log encoding for viewing.
Configuration file
The TARS platform provides a service configuration center to manage configuration files, and multiple configuration files can be added here. When deploying services on the TARS platform, each server will automatically load all configuration files locally (provided that the load configuration file is configured in the service code) and place them on the Classpath path for the JAVA service to read and parse. For each configuration file, the TARS platform also provides a callback function that is triggered when the file content changes. Through the callback function mechanism, we can push the configuration file on the TARS platform after modifying a configuration file, thereby triggering a preset callback function in the code to achieve the effect of hot update of the configuration file. Of course, it is recommended to restart the service to update the configuration information of the database connection information and Redis connection information that needs to be re-established.
Interface test
The TARS platform provides a page for testing the TARS interface. On the test page, we can add multiple test case data for each interface, and you can arbitrarily choose a machine where the service is located for test case invocation. This call is convenient and fast, but not very friendly to automated scripts. In response to this situation, the article provides a way to use the HTTP interface to call the TARS interface internally, making it easier to perform automated interface testing. It is expected that the TARS platform will provide more support for automated interface testing in the future.
Coding problem
When developing TARS services, it is particularly necessary to pay attention to various encoding problems. Here are some possible encoding problems and solutions.
Service profile encoding
As mentioned above, the TARS platform provides a service configuration center to manage configuration files. The default configuration of the service configuration is GBK, and it does not support modification. However, the machines (including physical machines and Docker) used to deploy the service here are generally used. The encoding is UTF-8. Both GBK and UTF-8 are compatible with ASCII code, so when the configuration file does not involve Chinese or other characters that exceed the ASCII code coverage, the deployed microservice program uses the system default encoding to read the configuration file without any problems; however, When Chinese characters are involved in the configuration file, the program may read incorrect information because the operating system default encoding is not compatible with GBK.
Solution: Use GBK encoding to open the configuration file in the service code you wrote; use Unicode encoded strings instead of the original Chinese strings.
TARS-JAVA encoding
You want to try TARS, so you deploy TARS-Java on the newly tuned Linux (when the local language is set to zh_CN.UTF-8), when you publish the application, you will encounter some strange errors. When you look for the cause, you will find that the original program used GBK to read Linux command line output. At this time, you only need to change the source code of TARS-JAVA, change the encoding for reading the command line output to UTF-8, and then recompile it, which is very fast. Of course, the encoding of the operating system may not be set to zh_CN.UTF-8, and many tools may not display Chinese characters correctly.
Server file encoding
The server's default file encoding sometimes has a weird phenomenon that is not UTF-8 (often the locale is not configured to support UTF-8). At this time, if the code uses the default encoding, garbled characters will appear.
Solution:Do not use the default encoding. When you need to use the encoding, you must manually specify the encoding.
Some Trick shares
In the process of practicing TARS service development, I have accumulated some small skills.
System shutdown hook
In the TARS platform management, selected instances of specific services can be set to no traffic to facilitate operations such as publishing and online verification. But unfortunately, the platform's no-flow configuration cannot be sensed in the TARS service, which means that the TARS service written by itself cannot do some special actions before and after the no-flow configuration, such as blocking the queue at the same time when no traffic is enabled Consumption operations, etc. However, the shutdown hook of the TARS service support system can clean up the application resources before the system exits and ensure that certain tasks are completed before exiting. Exiting the TARS service is only completed by sending the shutdown command to the service's AdminObj, and then exiting the system through System.exit. Then you can use Runtime.getRuntime (). AddShutdownHook method to add a system shutdown hook to the TARS service.
Get the caller's IP
Sometimes it is necessary to record the caller's IP, but because TARS is not efficient for purposes such as obtaining client identification information from the server. We can get the caller's IP and port information from the TCP / UDP connection.
How to circumvent problems caused by Communicator instance reuse
In the implementation of the TARS service, it is inevitable to call other ready-made services, and in most cases, multiple services will be called. These called services may require different encodings when invoking, some need to use UTF-8, and some need to use GBK. Encoding issues may be encountered when clients with multiple encodings are mixed. Tracing the source, it was found that when a Communicator instance is obtained, it will be cached using a Map. The keys of the Map are locator or CommunicatorConfig instances. CommunicatorConfig only uses locator and moduleName as the calculation elements of the hashCode and equals methods. So when using a CommunicatorConfig instance with the same locator and moduleName to obtain a Communicator instance, you will get the same instance, even if the charsetName is not the same. There are two general solutions:
- Inherit CommunicatorConfig, and override the hashCode and equals methods, add charsetName as the calculation element, and then obtain the Communicator instance from the instance obtained by this derived class;
- Set a different moduleName for the CommunicatorConfig instance that needs to be specially configured with other properties.
Something From Tars Assistant
Thank you for your wonderful sharing. After watching this student's accumulated experience from TARS Xiaobai to the skilled worker, do you want to share your experience? Contributions are welcome to tarscloud@qq.com .
If you have n’t known about TARS yet, welcome to watch and communicate on GitHub. If you feel good, please give TARS a star ~!
GitHub address: www.github.com/TarsCloud