APP
That APP application name, identifies a set of services of a small set, developers can define their own needs, usually expressed implement a business system name.
-
In Tars system, application name must be unique, such as: TestApp
-
Usually a name corresponding to the application name space code
-
tars This application name is used by the framework, business services do not use
Server
Server as a service name, service name of the process.
- Server name based on business service function name, it will appear on the left side of the tree service TARS web platform
- A Server must belong to a App, Server name under App possess uniqueness
- Generically named: XXServer, e.g. LogServer, TimerServer etc.
- A Server represents a separate program, to bind at least one ip, implement a set of related interfaces
Servant
Servant-service provider, provides a more specific interface (interface), provided to the client calls
- Servant a service code corresponding to class inherits from the interface protocol file tars (connotation more specific functions), realized by service developers
- A Servant must belong to a Server, Servant Name Server under all have uniqueness
- Servant needs a name, such as: HelloObj, when provided to a client uses, full name is: App.Server.Servant, such as: Test.HelloServer.HelloObj
- When a client calls Server, only you need to specify the name of the Servant to complete telecommunications (how to implement the follow-up will introduce)
Tars take this three-layer structure, as much as possible to avoid different service developers to develop the service name and the name of the conflict Servant
module
module is tars protocol file keyword, define the space protocol, also corresponds to the respective language namespace (c ++) or package name (java, go) or module (nodejs, php)
Tars file directory specification
Tars file is the protocol communication interface TARS services, particularly the client a Tars Server will need to rely tars protocol file of the Server when calling Server, it is very important in the management we recommend as follows management (of course you can not take change mode, build your own suitable open way):
- tars and the corresponding file server principle together;
- Each server to establish / home / tarsproto / [namespace] / [server] subdirectory on the developing machine;
- Tars all files need to be updated to the directory / home / tarsproto the corresponding server;
- The tars when using other file server, the need to / home / tarsproto used, can not copy to the catalog;
- So, on the same server development services, you only need to release tars file to the directory, you can easily use other callers
- In principle, the interface tars can only increase, not reduce or modify
- Tars service tools under the framework of various languages, provide a quick release tars files to / home / tarsproto / [namespace] / [server]
Server development mode
Any Tars service and client development methods are basically the same:
- Determining APP, Server, Servant name
- Write tars files, interface and interface functions defined in the following services provided externally, there must be a main interface, the following interface can have multiple functions
- Use tars2xxx tool (different language tools), the generated code file tars different languages
- Achieve Tars service (please refer to the document in different languages), class inheritance Servant generated files, the interface to achieve Servant
- Build Service, published on the management platform (management platform to configure App, Server, Servant Obj name, etc.), can refer to the subsequent chapters
- Of course, you can also run local services, the service may start after, ps -ef see the service is started on the platform, can be placed in the local execution (note might have a configuration file, you need to modify the information ports, etc.)
Under normal circumstances, the service eventually released by tarsweb running on each node in the tars server platform, but expect the machine to run, how to handle the debugging process?
Service starts in fact nothing more than a command line, such as c ++ services are:
HelloServer --config=xxxxx.conf
Config startup configuration here representing the service configuration file on the tars platform it is tarsnode by pulling template configuration generated and pulls HelloServer, if you want to run the service locally, it is necessary to have this local configuration file.
- The main recommendations config configuration items to figure out the meaning of
- config ip pay attention to the cost of providing machine
bashnode=tars.tarsnode.ServerObj@xxxx, Address tarsnode connected said that if no local tarsnode, this configuration can be removedlocal=...Ports by opening the machine to tarsnode connected, if not tarsnode, you can configure this outlocator=..., Indicates the address (frame address) the main control center for acquiring ip list in accordance with the service name- If you are independent of the client, there is this configuration, you can not specify a different service address access
Note that this configuration is not a service configuration file, but configure services framework, the corresponding template tars on the platform!
How to get the configuration file it?
You can post a node to the first service platform, and then landing node server, run:
ps -efww | grep ${your server name}
You can see the command to start the service line, the configuration file that corresponds to the local copy, and open the configuration file, modify the configuration file which corresponds ip port and associated path, and then use the same command line can be run locally!
Similar to the way other languages!
Client Development Methods
After the completion of the preparation and starting the server, the client can write, and get the name of Servant according to the corresponding service proxy object file generated by reference tars client code, and construct a communication device using a communication device, communication using a proxy object completes .
Communicator (Communicator) is a class client management and network threads, it is the major language has a corresponding class, usually the service will provide a framework initialized for your use (usually you can use this object) If the client is kept, then you need to create your own communicator
If your client is another service, and deployed in the frame, then your communication can use the framework to provide a good communicator (with reference to the language of the document), when this time calling Server, do not need to specify the ip port, need only Servant the Obj name to, and addressing the framework will automatically call completion
If your client is independent of the client program is not deployed on the frame, you can create your own communicator, then call the service in two ways:
1. Direct ip manner specified server port (you can specify a plurality of frame switching automatically DR), substantially the same for each language, such as c ++ language:
Communicator *communicator = new Communicator();
HelloPrx helloPrx = communicator->stringToProxy<HelloPrx>("Test.HelloServer.HelloObj@tcp -h xxx -p yyy:tcp -h www -p zzz");
helloPrx->call();
You may also communicate to the master device corresponding to the designated frame, thereby eliminating the need to specify the corresponding ip port, each of substantially the same language, 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();
This way the client calls, although service can be addressed and disaster recovery, but did not report the information required to be reported if the information also need to specify other attributes, such as:
communicator->setProperty("stat", "tars.tarsstat.StatObj");
communicator->setProperty("property", "tars.tarspropery.PropertyObj");
Of course, you can directly use the configuration file to initialize the communicator, client web platform part of the reference template configuration. In addition service here reported similar, if not the master address locator designated frame, you will need to specify their own reported ip port.
Template configuration
On the web platform, operation and maintenance management configuration template, the template configuration is very important for the framework, it is necessary to understand the role of template configuration.
Each deployed in the framework of TARS service, in fact, is eventually released into the framework of the corresponding node (tarsnode), then how do you know tarsnode port service binding when pulled this service, start number and other thread information? The answer is by: template configuration
tarsnode going to pull service platform corresponding template (when configured service deployment), and then based on the template to generate a corresponding service configuration, and this configuration the user to start the service.
Note the use of different languages in different template configuration file, refer to the follow-up documentation for each language.
It is strongly recommended that you do not need to modify the frame comes with a template, because the subsequent upgrade framework may modify these templates content, if you need to change, you can inherit the template that allows you to use the service template inheritance
Published development and debugging
If the development process, always need to manually publish to the web platform debugging, debugging efficiency is very low, therefore Tars platform provides a way can one-click publishing services to the Tars frame.
Used as follows:
This requires web> = 2.0.0, tarscpp> = 2.1.0 version to support.
After completing the installation frame, the center of the logged in user, create a token
Upload and publish on linux use the curl command to complete services to Test / HelloServer for example, reference cmake management practices
curl http://${your-web-host}/pages/server/api/upload_and_publish?ticket=${token} -Fsuse=@HelloServer.tgz -Fapplication=Test -Fmodule_name=HelloServer -Fcomment=dev
Note Replace your token
c ++ version of cmake has been embedded CMakeLists.txt command line service, such as creating service after using cmake_tars_server.sh, just:
cd build
cmake .. -DTARS_WEB_HOST=${WEB_HOST} -DTARS_TOKEN=${TOKEN}
make HelloServer-tar
make HelloServer-upload
To complete the upload and publishing services (advance needs to configure the web platform)
note:
And token replacement WEB_HOST
HelloServer.tgz release package is c ++, java correspondence is war package, similar to other languages, you upload it to the corresponding web platform release package
