Content

This paper mainly introduces some common basic concepts in the tars platform, which is helpful for the use of the platform. This document can be read repeatedly. If you can’t understand it for the first time, it doesn’t matter. After writing HelloWorld, you will have different feelings.

1. APP

App is the application name, which identifies a small set of services. Developers can define it according to their own needs, usually indicating the implementation of a business system name.

2. Server

Server is the service name, the name of the program providing business services

3. Servant

Servant is a service provider, which provides a number of specific interfaces for clients to call

Tars adopts this three-tier structure to avoid the conflict between service name and service name developed by different business developers

4. module

Module is the key word in the tars protocol file, which defines the protocol space and also corresponds to the language namespace (c + +) or package name (Java, go) or module (nodejs, go)

5. Tars file directory specification

The tars file is the protocol communication interface of the tars service, especially when the client calls the server, it needs to rely on the tars protocol file of the server, so it is very important. In terms of management, we recommend the following management methods (of course, you can build your own appropriate open mode without changing the mode):

6 Server development mode

The development mode of tars server and client in any language is basically the same:

Under normal circumstances, the services are ultimately running on each node server of the tars platform through tarsweb publishing, but in the process of debugging, you want to run on the local machine, how to deal with it?

Service startup is actually a command line. For example, C + + service is:

HelloServer --config=xxxxx.conf

Here, config indicates the configuration file for service startup. On the tars platform, tarsnode generated the config through template config and helloserver is pulled up. If you want to run the service locally, you must have this configuration file locally.

Note:

Note that this configuration file is not a business configuration, but a service framework configuration, corresponding to the templates on the tars platform!

How do I get this profile?

You can first publish the service to a node of the platform, and then log in to the node server to run:

ps -efww | grep ${your server name}

You can see the command line of the service startup, copy the corresponding configuration file to the local, open the configuration file, modify the corresponding IP port and related path in the configuration file, and then use the same command line to run locally!

Other languages are similar!

7. Client development mode

After completing the writing and starting of the server, the client can be written. The client code generated by referencing the tars file is used to build the communicator. The communicator is used to obtain the proxy object of the corresponding service according to the servant name, and the proxy object is used to complete the communication

Communicator *communicator = new Communicator();
HelloPrx helloPrx = communicator->stringToProxy<HelloPrx>("Test.HelloServer.HelloObj@tcp -h xxx -p yyy:tcp -h www -p zzz");
helloPrx->call();

Communicator *communicator = new Communicator();
communicator->setProperty("locator", "tars.tarsregistry.QueryObj@tcp -h xxxx -p 17890");
HelloPrx helloPrx = communicator->stringToProxy<HelloPrx>("Test.HelloServer.HelloObj");
helloPrx->call();

In this way, although the service can address and recover the disaster, it does not report information. If it needs to report information, it needs to specify other related attributes, such as:

communicator->setProperty("stat", "tars.tarsstat.StatObj");
communicator->setProperty("property", "tars.tarspropery.PropertyObj");

Of course, you can use the configuration file to initialize the communicator directly. Refer to the client part of the web platform template configuration. In addition, the reporting service is similar here. If you do not have the locator to specify the tarsregistry address of the framework, you need to specify the IP port

8 Template configuration

On the web platform, there is template configuration in the operation and maintenance management. Template configuration is very important for the framework, so we need to understand the role of template configuration

Every service deployed in the tars framework is actually published to the corresponding node by the framework. How does the tarsnode know the port of service binding, the number of threads started and other information when it pulls up the service? The answer is through: template configuration

Tarsnode will go to the platform to pull the template corresponding to the service (configured during service deployment), then generate the corresponding configuration of the service according to the template, and start the service according to the configuration of the user

Note that the template configuration files used in different languages are different. You can refer to the following documents in different languages

It is strongly recommended that you do not need to modify the template provided by the framework, because the content of these templates may be modified in the subsequent framework upgrade. If you need to modify, you can inherit the template and let your service use the inherited template

9 Bussiness Config

As mentioned in the previous section, template configuration is actually a public configuration used by RPC server. It is generated by tarsnode. However, for business services, there are generally their own configuration information, which we call business configuration

The business configuration is generally managed by the configuration center on the web platform. The usage is as follows:

For specific usage of business configuration, please refer to business configuration

10 Log System

Business services usually need to print logs, and the framework also provides a centralized log center.

Generally, there are two types of logs:

Through the log API, you can output the log directly to the remote log center, that is, the machine where the tarslog is located (the log path is: /usr/local/app/tars/remote_app_log)

All language frameworks provide APIs for remote logging.

In addition, on the web platform, click the service details interface, click the service name, and you can also quickly view the local log of the service

11 Development and debugging release

If in the development process, it needs to be manually published to the web platform for debugging every time, the debugging efficiency is very low, so the tars platform provides a way to publish services to the tars framework with one click:

curl http://${your-web-host}/api/upload_and_publish?ticket=${token} -Fsuse=@HelloServer.tgz -Fapplication=Test -Fmodule_name=HelloServer -Fcomment=dev

The C++ version of cmake has embedded the command line in CMakeLists.txt of the service. The user only needs to:

cd build
cmake .. -DTARS_WEB_HOST=${WEB_HOST} -DTARS_TOKEN=${TOKEN}
make HelloServer-tar
make HelloServer-upload

complete upload and publish the service.

Note: