With the development of the Internet, more and more businesses are not only carried by a single Node or a single language, but tend to multi-language distributed collaborative development, for example, the access layer is completed by node.js, the logic and data layer is implemented by C++/GO/Python, and thus form a large heterogeneous system.

Tars. Js is developed based on Tars overall architecture system, so that users can quickly build and migrate Node.js services without changing the overall architecture of the heterogeneous system, and it is very convenient to split the original single service into multiple logical sub-services, and support tens of billions of traffic in Tencent.


After more than 5 years of precipitation and iteration in Tencent ([email protected] version is supported), tars.js is widely used in dozens of important businesses such as Tencent QQ browser, Tencent desktop browser, Tencent Map, App Treasure, Tencent Mobile Housekeeper, Internet +, Tencent Medical, Tencent Miying, insurance, lottery and so on.

Tars.js 2.0 releases the following 9 features:

  • 100% written in JavaScript without any C/C++ code.
  • Multi-process load balancing and management.
  • Code exception monitoring and restart.
  • Collect and process service logs.
  • HTTP(S) monitoring and reporting, and supports custom reporting.
  • Conforms to Tars IDL codec specification.
  • Supports Tars RPC calls and coloring.
  • Supports sending management commands and pulling service configurations.
  • Original LongStackTrace exception tracking mechanism.
  • … More features can be found at @tars/ Node-agent

Three design concepts of Tars.js 2.0:

High degree of freedom:

  • Compatible with all official Node.js versions (≥0.10).
  • Node.js source code no intrusion, no modification.
  • The bottom layer is completely transparent to the top layer and supports a variety of top frameworks without change.

In other words:

You can use any framework you are familiar with (such as Express.js/koa.js, including but not limited to Web frameworks) and you do not need to make any changes to the framework (without introducing any middleware). You can run from tars.js and enjoy the various monitoring and management features provided by the platform.

At the same time, the modules provided by tars.js can also be introduced according to your needs (if not used, not introduced).

High performance:

Tars. Js for high performance and large amount of concurrent design, use a lot of front end (V8) optimization techniques (such as FlattenString/FastProperties) provided by minimizing the ability for the influence of business performance.

According to our test (Web Server), the impact of the default off-line reporting and monitoring on service performance is less than 5%, and the performance of common modules (RPC, log, etc.) is in the forefront of the industry.

» Differentiation:

Tars.js provides differentiated operation solutions according to different business types:

  • High-traffic business: Try to minimize the impact of the framework on business performance.
  • Low-traffic services: Make full use of hardware resources to improve development experience.

“Hello World”

By deploying your code through tars.js, you can have all of the following features directly, without changing any of the code.

const http = require('http'); Const hostname = '127.0.0.1; const port = 3000; const server = http.createServer((req, res) => { res.statusCode = 200; res.setHeader('Content-Type', 'text/plain'); res.end('Hello World\n'); }); server.listen(port, hostname, () => { console.log(`Server running at http://${hostname}:${port}/`); });Copy the code

(Even the node.js official website example can be run directly)

✓ Process management

The default load balancing function is based on the Cluster module. The number of processes can be set to 1 to Max (number of CPU cores) or auto (same number of physical cores) to reduce memory pressure and improve cost performance.

Process architecture

At the same time, process zombie detection is also enabled to monitor service processes in real time.

» Case Description

A service uses unoptimized regular expression for XSS attack filtering when the UBB code of the forum is transferred to HTML, but the BASE64 encoding is used when the user posts, resulting in a long computation time of regular expression and a surge of CPU usage to 100% :

The service does not respond. You can only restart the service manually

After zombie detection is enabled, tars. js automatically restarts the service process when it detects that the service process is dead, shortening the service non-response time:

Service non-response time (CPU 100%) decreased significantly

Although tars.js cannot solve the bugs in the business code, it does its best to keep the business usable.

✓ Service Monitoring

Collect statistics on total traffic, average time, timeout rate, and exception rate based on the service name and interface name (urL-PATH).


The return code greater than 400 (configurable) is reported as an exception.

» Monitoring Description

Web services are generally composed of static and dynamic resources (interfaces). Since the request time of static resources (local files) is much lower than that of dynamic resources (business logic), the request volume is often high, which lowers the overall service time.

Based on this, tars. js uses the PATH section in the request URL as an interface. Each interface can view its total traffic, average time, and exception rate, facilitating users to comprehensively understand service performance.

✓ Feature Monitoring

Regardless of the type of service you are serving, the following features are always reported for traceability and performance evaluation:

  • MemUsage: memory usage. RSS, heapUsed, and heapTotal will be reported (in bytes).
  • CpuUsage: indicates the CPU usage. The data is summarized as a single logical unit (percentage).
  • EventloopLag :(task) queue delay, sampling every 2 seconds (in milliseconds)
  • ActiveHandles activeRequests libuv: activeHandles activeRequests ests

Statistics of all policies are made by nodes in terms of average value (Avg), maximum value (Max) and minimum value (Min) :


✓ Log Output

All logs generated by the Console module (such as console.log) are exported to the local service file. The following information is added to facilitate fault locating.

Log format: date/time process PID | | | log level output file name and line number | log content


2018-07-01 12:00:00|332|DEBUG|app.js:13|Server running at
http://127.0.0.1:3000/

✓ LongStackTrace

Due to the asynchronous mechanism of Node.js, the stack is incomplete when an exception occurs, resulting in complex locating problems.

For this reason, we provide long link tracing technology that automatically appends the preemptive call stack when an exception is generated, and also supports filtering out the user code portion of the exception stack.

This feature is disabled by default because it causes performance loss. You can directly enable performance insensitive services such as the management platform.

» Case Description

Promise.resolve(1).then(val => {
    setTimeout(()=>{
        try {
            ThisMayThrowError;
        } catch(err) {
            console.error(err);
        };
    }, 1000);
});
Copy the code

Executing the above code throws the following exception:

ReferenceError: ThisMayThrowError is not defined


at Timeout.setTimeout as _onTimeout


at ontimeout (timers.js:427:11)


at tryOnTimeout (timers.js:289:5)


at listOnTimeout (timers.js:252:5)


at Timer.processTimers (timers.js:212:10)

The setTimeout stack is missing, making the problem hard to trace.

When this feature is turned on (and user code is filtered out), exceptions thrown by the above code (without modification) are automatically appended to the preceding call stack (as follows) :

ReferenceError: ThisMayThrowError is not defined


at Timeout.setTimeout [as _onTimeout] (test.js:4:13)


at Promise.resolve.then.val (test.js:2:5)


at Object.<anonymous> (test.js:1:82)

In order to facilitate users to locate problems, this also reflects the tars. js differentiated operation philosophy.

All of these features are available without modifying the business code (without introducing any modules).

Because there is not enough space to show all the capabilities, if you have more requirements (such as RPC calls, etc.) you can use the modules provided by tars.js (as follows) :

  • @tars/ RPC: Tars RPC call module.
  • @tars/stream: TARS (Tup) protocol codec module.
  • @tars/logs: Log component that contains (by size and time) rolling and remote logs.
  • @tars/config: Used to obtain service configuration files online.
  • @tars/monitor: Supports service monitoring, feature monitoring, and PP monitoring reporting.
  • @tars/notify: Reports service (alarm) messages.
  • Tars /utils: A collection of assistive tools, including tars configuration files and the Tars RPC Endpoint parser.
  • Tars /dyeing: TARS RPC dyeing definition module.

Each module (click on the name to jump to) has a README of extremely detailed documentation that you can refer to at any time.

In the world of tars.js, you just focus on the business code and do the rest.

Github

Github.com/tars-node/T…

Github.com/Tencent/Tar…

The authors introduce



@SuperZheng· Core contributor of Tencent Tars open source project, mainly responsible for the development of basic operation architecture of Node.js language within Tars framework. From the full stack architect of Tencent QQ browser [SuperTeam], familiar with Web(3D), terminal, back-end and big data computing.