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.
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.
Server is the service name, the name of the program providing business services
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
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)
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):
The development mode of tars server and client in any language is basically the same:
`ps -ef`After you see the start mode of the service, you can execute it locally (note that there may be a configuration file, and you need to modify the port and other information)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 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!
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();
>- The communicator can also be assigned to the main control of the corresponding framework, so there is no need to specify the corresponding IP port. All languages are basically the same, such as C + + Language:
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
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
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}/pages/server/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: