Open Source |ns4_frame Distributed Service Framework Development Guide

Introduction:: Yixin officially opened the nextsystem4 (hereinafter referred to as “NS4”) series module on March 29, 2019. This open source NS4 series module is a distributed business system solution generated around the current payment system, which is cumbersome, highly code coupled and costly to maintain. NS4 series framework allows the creation of complex processes/business flows. The implementation of business service nodes can be connected in series and distributed. Its simplicity and light weight make it possible to “decapsulate” (independent of tomcat, jetty and other containers). The design concept of NS4 series framework is to separate business and logic. Developers can realize a business system with complex logic, high performance and stable function by simple configuration and business implementation.
[Click to view the overall introduction of the framework]

The NS4 series includes four open source modules, namely: ns4_frame Distributed Service Framework, ns4_gear_idgen ID Generator Component (NS4 Framework Demo Example), ns4_gear_watchdog Monitoring System Component (Service Guardian, Application Performance Monitoring, Data Acquisition, Automatic Alarm System) and ns4_chatbot Communication Component.This article will introduce the ns4_frame Distributed Service Framework Development Guide in detail.

Project address: …

I introduction of the framework

Ns4_frame is essentially a distributed business framework composed of two applications and three development frameworks.

1.1 Scope of Use

Ns4_frame distributed framework is mainly applicable to business systems with message flow as business type or flow as business core model. It supports message distribution, delivery and tracking, and supports step-by-step and batch-by-batch message processing. It is especially suitable for message-driven services such as information flow and data flow.

1.2 Project Structure

Ns4_frame framework is a set of MAVEN father and son projects, which consists of five projects:

  • NS_MQ: is responsible for communicating with the underlying message queue and provides an API for operating the message queue.
  • NS_TRANSPORTER: Collect, process and forward business messages by calling API provided by NS_MQ.
  • NS_CHAIN: An optional development framework that is responsible for the chain integration of business processing steps in the same jvm to form the busi ness processing flow of the current business module.
  • NS_CONTROLLER: a service message forwarding application, which is responsible for forwarding the received message to the corresponding service module for processing, and is also responsible for associating the service modules according to the overall service. NS_CONTROLLER is essentially an independent application system, built on NS_TRANPORTOR and NS_CHAIN.
  • NS _ Dispatcher: The message portal specified by NS4 _ Frame architecture accepts http requests outside the boundaries of the business system through t he http service provided, and converts the requests into the message protocol format used for internal communication of the business system.

Ii. basic income

2.1 Development Environment Configuration

Development language: JAVA

JDK Version: JDK1.7

MAVEN version: above 3.3

REDIS version: above 3.0

These are the necessary components and configurations for the development environment, of which java is the development language, maven is necessary for project compilation, packaging and deployment, and redis is used as message middleware.

2.2 operation

Ns4_frame requires at least three jvm projects to run completely. Starting the whole project is divided into the following three steps:

  • Step 1: The ns4_frame message portal is an http interface, and the http service is provided by the NS_DISPATCHER project, so our first thing is to run the NS_DISPATCHER. To run NS_DISPATCHER, run the main method of the Bootstrap class directly. The default NS_DISPATCHER listens for http requests on port 8027 of the local computer (127.0.0. 1). If an http request is received, the default is to convert the http request into an internal communication message and store it in redis of the local computer ( The default access redis port number is 6379.
  • Step 2: NS_CONTROLLER is responsible for receiving the message from NS_DISPATCHER and distributing the message according to the configuration. Therefo re, we need to run the NS_CONTROLLER project (hereinafter referred to as “CONTROLLER” for convenience) . We cannot run directly in the CONTROLLER project, we need to configure some east. The CONTROLLER needs to specify at least one profile location to run. This configuration file needs to be specified through java command parameters. Suppose I now specify the java running parameter -Dconfigfile=nsCONTROLLER.xml is essentially used by the NS_TRANSPOR TER at the bottom of the CONTROLLER. it indicates the location of the configuration file that the NS_TRANSPORTER must have so that the controller can u se the NS_TRANSPORTER to send and receive messages smoothly. By default, the CONTROLLER will also go to classpath to find the configuration files required by NS_CHAIN. the default path is the nschainconfig directory under c lasspath, and all xml files under this directory will be considered as the configuration file collection required by NS_CHAIN. After the configuration file is configured, the NS_CONTROLLER can be started by calling the main method of com.creditease.ns.transporter.context.xmlapptransportercontext.
  • Step 3: In this step, we need to start our own business project. In this business project, we must have the following three preconditions:

    • Business projects need to be built on the NS_TRANSPORTER framework.
    • The message queue name of the business project must be the same as the queue name configured in the CONTROLLER project.
    • Business startup must be started through the main method of com.creditease.ns.transporter.context.xmlapptransportercontext.

After completing the above three steps, a basic ns4_frame system is set up and running.

III. Project Structure

3.1 Hierarchy Division

The above figure shows the hierarchy of each ns4_frame system.

  • The bottom layer uses redis as the message middleware, and the operation of the message middleware is encapsulated into the NS_MQ project, which provides the upper layer with an API interface for the operation of the message queue.
  • The upper layer of NS_MQ is NS_TRANSPORTER, which is essentially a set of messaging processing framework. It is responsible for the reverse callback of business code after receiving the message and handing the message to the business layer for processing. When the business layer finishes processing, it is responsible for returning the processed message to redis.
  • NS_CHAINS is a set of development assistance framework, which is responsible for decoupling the business processing steps of a module into scattered tasks, and can be associated in any order at will.
  • NS_CONTROLLER is a project, which is essentially an independent application. It is responsible for decomposing the whole business into nodes, associating them in a certain order through configuration, and combining these nodes through message mechanism to form a business system.
  • NS_DISPATCHER is also a project. It is an independent application based on NETTY framework and developed to provide basic http services. At the same t ime, it is also the only boundary between business system and external communication.

3.2 Operation Process

Ns4_frame is actually a set of message middleware service plus development framework. The overall structure diagram is as follows:

The above figure shows the operation flow of an ns4_frame overall distributed project, and the operation flow of a message is in the following order:

  • NS_DISPATCHER receives the http request and converts the http request into an internal message protocol and puts it into the specified message queue (according to the configuration file).
  • NS_CONTORLLER receives the message from the queue specified in step 1 and starts to send the message to the message queue corresponding to each service step in sequence according to the configured service schedule.
  • The service system receives the message from the message queue designated by NS_CONTROLLER in step 2 and starts processing, and returns the result after processing.
  • NS_CONTROLLER receives the response from the business system and starts to send the returned message result to the message queue corresponding to the next service according to the configured service.

IV. Introduction of NS_MQ Framework

4.1 Core Classes and Interfaces

  • RedisMQTemplate class: encapsulates all API related to message queue operations
  • MQConfig: stores all configurations related to the underlying message middleware.

4.2 Configuration Scheme

By default, NS_MQ will automatically access redis on 6379 port of this machine ( without any configuration. If not, an exception will be reported. Normally, NS_MQ will look for the next configuration file named under classpath, which stores all the properties related to the underlying message middleware.

List some key configuration elements:

  • Redis.type 1 for redis Standalone 2 for redis Cluster Defaults to 1
  • Host Address (including Port) of Redis Single Machine or Cluster in redis.single/
  • The maximum number of connections for a single machine or cluster in Redis, redis.single/cluster.maxTotal
  • Minimum number of idle connections for a single machine or cluster in Redis, redis.single/cluster.miniIdle
  • The maximum number of idle connections for a single machine or cluster in Redis, redis.single/cluster.maxIdle
  • Timeout for attempted connection of a Redis stand-alone or cluster in redis.single/cluster.connectionTimeout (time to wait before connecting to the service)
  • Timeout for socket Idle after Connection of Redis Single Machine or Cluster in redis.single/cluster.socketTimeout

V. introduction of NS_TRANSPORTER framework

5.1 Framework

The above figure shows the overall architecture of the whole NS_TRANSPORTER. The whole framework is divided into the following three steps for sending and receiving messages:

  • First, the thread receiving the message (Fetcher thread) acquires the message from the underlying message middleware through NS_MQ and puts it into the local message cache.
  • The message processing thread (Handler thread) takes out the message from the local message cache and calls the service layer method to process the message. After processing, the processed message is put into the local sending cache.
  • After the sending thread (Sender thread) fetches the message from the local sending cache, it places the message into the underlying message middleware through NS_MQ.

5.2 Core Classes and Interfaces

  • ServiceMessage: java encapsulation of messages passed between modules, including any information needed for communication between modules;
  • Worker: The business layer needs to implement the doWork method of this interface. The object implementing this interface will be called back by the Ha ndler thread of NS_TRANSPORTER to process the information in ServiceMessage.
  • ActionWorker: The partially encapsulated abstract class implements the Worker interface. The business layer can directly inherit this abstract class to simplify development.

5.3 Configuration Scheme

By default, NS_TRANSPORTER will find a system variable named configfile. The value of this system variable is the path of the configuration file required by NS_TRANSPORTER. NS _ Transporter will find this xml configuration file and start it after parsing the relevant configuration.

The NS_TRANSPORTER-related profile templates are as follows:

<class name="类的全名" method="method方法名" property="" />
<class name="类的全名" static-method="method方法名" /> </launcher>
<fetchernum></fetchernum> <buffersize></buffersize> <handlersize></handlersize> <serviceClass></serviceClass> <sendernum></sendernum>

There are several key elements to note in the above xml template:

  • Launcher: Used to define the method to be executed before the entire framework is fully operational.
  • Queue: Under this element, the name element represents the queue name of the underlying message middleware that needs to be monitored.
  • Fetchernum: indicates the number of threads that listen to the message queue and get messages; the default is 1.
  • Buffersize: indicates that the default size of the local receive/send message queue is 100.
  • Handlersize: Indicates the number of threads processing messages; the default is 10.
  • Serviceclass: Represents a specific business class that processes messages. This class must implement the Worker interface.
  • Sendernum: Indicates the number of threads sent to the underlying message middleware after getting messages from the local send message queue.

VI. Introduction of NS_CHAIN Framework

6.1 Framework

Because NS_CHAIN is essentially a pure development framework, the framework of this framework is temporarily ignored.

6.2 Core Classes and Interfaces

For the time being

6.3 Configuration Scheme

This section details the configuration of NS_CHAINS.

When NS_CHAINS starts, it looks for the system variable chainconfig, whose value is the path where the NS_CHAINS configuration file is located. NS_CHAINS supports configuration directories (all xml format files in the directory are considered configuration files of NS_CHAINS framework) and configuration files.

For the configuration format of NS_CHAINS, we roughly list the key elements as follows:

  • Catalog: This is equivalent to a complete service or a namespace, and is the basic unit of NS_CHAINS external service. The NS_CHAINS external system can only see catalog.
  • Command: This is the smallest unit of NS_CHAINS task execution. All execution tasks can be called and executed in the form of Command.
  • Chain: This is a command container, which can combine multiple command tasks into one execution link.
  • Group: This is a combination of Commands. It can combine multiple Commands into a whole and execute them according to the configuration order.
  • At the same time, the configuration of NS_CHAINS has complete logic syntax, which supports if condition judgment, while loop structure and sequence structure.

VII. Introduction of NS_DISPATCHER Application

7.1 Framework

NS_DISPATCHER is essentially an independent application that can provide http services based on Netty framework, so the framework structure is omitted here.

7.2 Core Classes and Interfaces

NS_DISPATCHER is based on the NETTY framework, so its core classes are the following protocol processors:

  • HttpDispatcherServerHandler: Mainly responsible for parsing the incoming http request and encapsulating it into corresponding java objects for further processing by HttpRPCHandler.
  • HttpRPCHandler: Mainly receives the java object encapsulated in the previous step, takes out the corresponding request parameters, request contents, etc., encapsulates it into a protocol object for internal transmission of the system, and can put the protocol object into the underlying message middleware in synchronous request response mode/asynchronous transmission mode.

7.3 Configuration Scheme

The NS_DISPATCHER startup will look for the file. The following describes the key elements of the configuration:

  • Http.port: specifies the listening port of the http service.
  • Dispatcher.pool.num: specifies the number of concurrent threads of dispatcher. dispatcher’s performance has a great relationship with this parameter.
  • Dispatcher.queuename: The name of the queue into which the encapsulated internal protocol messages will be placed. NS_DISPATCHER also supports https. T herefore, if there are the following options in the file, NS_DISPATCHER will also start the corresponding https service.
  • Path: indicates the path of the trusted certificate.
  • Key.path: indicates the path of the public key.
  • Https.port: indicates the port on which the https service listens.

VIII. Introduction of NS_CONTROLLER Application

8.1 Framework

The essence of NS_CONTROLLER is an independent application based on NS_TRANSPORTER and NS_CHAINS. The core is the architecture of NS_TRANSPORTER with the assistance of NS_CHAINS, so its architecture will not be repeated.

8.2 Core Classes and Interfaces

DefaultPublishCommand: This is an extension of NS_CONTROLLER to NS_CHAINS. It supports sending messages synchronously and waiting for a response from the message. It can also set a timeout period for waiting for a response. At the same time, it also supports sending messages asynchronously without waiting for a response from the message.

8.3 Configuration Scheme

Following the configuration rules of NS_TRANSPORTER and NS_CHAINS, we will not repeat them here.
Note: In NS_CONTROLLER, some function extensions have been made for the configuration of NS_CHAINS, mainly adding the configuration element of publish, which can then provide a configuration template.

IX. Project Deployment

9.1 Deployment Plan

If you want to deploy the entire ns4_frame project, follow these steps:

  • Deploying NS_DISPATCHER Project: The NS_DISPATCHER project is a Maven project. First, the entire project needs to be converted into a zip package and uploaded to the server through mvn:package deploy, and then decompressed into a directory. In this directory, there are the following subdirectories: bin, config, lib, logs. Among them, bin directory contains DISPATCHER’s startup script; Config directory holds the necessary configuration files for NS_DISPATCHER; Lib directory holds all jar packages required by NS_DISPATCHER; The logs directory holds all logs printed by NS_DISPATCHER.
  • Deploying NS_CONTROLLER Project: NS_CONTROLLER Project is also a Maven Project, and the whole project needs to be packaged into a zip package through mvn:package deploy. The directory structure is the same as that of the NS_DISPATCHER project, which is not repeated here.
  • Deploy business codes: Please deploy business codes according to the rules of each team.

X. operation log

10.1 Log Classification

Ns4_frame project roughly divides logs into four categories:

  • *fram.log: System log, which belongs to the log inside the entire ns4_frame underlying system, including information such as system startup and thread startup and shutdown.
  • *biz.log: business log, all business-related logs will be directed here.
  • *flow.log: message flow log, which records the flow information of all messages in the system.
  • *mq.log: all information on the operation of the underlying message middleware is recorded here.

10.2 How to View Logs

  • Business Error Reporting: If the business reports an error, basically all error reporting information will be found in *biz.log.
  • Message Flow: If it is a problem of sending a response to a message, relevant information can be found or inferred basically in *flow.log.
  • Low-level message middleware interaction: if the problem cannot be inferred from the message flow or the corresponding message cannot be found, you need to go to *mq.log for query.

Xi. other

11.1 Frequently Asked Questions

Ns4_frame system is essentially a distributed system with message as its communication mechanism. Frequently occurring problems are divided into the following two parts:

  • Business anomaly

Since the service itself is executed by the underlying NS_TRANSPORTER callback, when the service is abnormal, it is likely to be captured by the underlying NS _ Transporter framework because there is no suitable catch. For the problems not found in *biz.log and stdoout.log, you can check the log of *flow.log to see if there is any abnormality captured by the underlying NS_TRANSPOTER.

  • Bottom anomaly

In some cases, there is no problem with the service itself, but the problem with message communication will cause the service not to be executed. In this case, we need to first find the corresponding messageId from the *flow.log of NS_DISPATCHER at the message entrance, and then query the corresponding deployment machine step by step according to the message flow path.

Source of content:Yixin Institute of Technology