Shuttle ESB (6)-Application in projects

If you carefully read the previous articles on ESB, I believe that you will find a lot of resonance in this article.

Although there are a lot of Open-Source ESB on the market, such as mule ESB in Java, JBoss ESB, and nservicebus in. net. Shuttle ESB is a new open-source framework with fewer resources on the network. Why did we choose shuttle ESB?

The so-called no best, only more suitable. Multiple surveys found that shuttle ESB has the following advantages: 1. Shuttle ESB is based on EDA; 2. Implementation of shuttle ESB is centered on publishing and subscription; 3. The core of the shuttle ESB does not rely on any third-party components.

These features of shuttle ESB are very consistent with fast project communication, broadcast messages, and high controllability.

After explaining the previous blogs, we should be familiar with the open-source project shuttle ESB.

However,It is not a simple task to apply it to a project, construct it, and run normally. I encountered a lot of such problems during my work (since I chose a newer technology, I will certainly encounter such problems).

Therefore, I decided to use the project as the main material and abstract a model for your reference. I hope to help anyone who wants to learn this framework. In addition, if you have any questions or new ideas, please contact me or leave a message in time. I will try my best.

Note: I have already checked whether this article is infringing. At present, we are not the only one in China to do this. We will imitate the sum company and commit to building a nationwide online system. Of course, other bureaus can do the same thing, but if multiple bureaus share the same information, we must refer to the standards we have developed. Since many companies are doing this, I will avoid the most important issues, avoid special things, and talk about common demands without infringement.

Next I will introduce the application of shuttle ESB in the project.

In a macro sense, this is a disaster monitoring system for Railway Bureau trains. The project area is relatively large, and it must implement a nationwide network. In this way, an ESB service bus is not enough. In addition, according to my performance tests on shuttle ESB, the message transmission speed decreases as the number of clients increases. Although this has little impact on the running of our current system, it limits the number of clients.

In addition, when a shuttle ESB instance is started, the system has a high Io throughput. I have not solved these two problems at present. Although Eben has told me many times that it is okay, it is still my biggest concern for this system.

Considering the problems mentioned above and the actual situation, we design the architecture of the ESB part in the system as follows:

In this way, each branch has at least one ESB service bus, which mounts the display terminal controller, rule engine, WCF Service, and related communication systems in the system. Because ESB is mainly used as a message router, once the relevant communication system or a terminal display sends a message, all the display terminals of this Bureau will receive the message.

How can we achieve nationwide networking? Each branch's ESB service bus follows certain standards. Then, we use the law to establish a new service bus between the ESB bus of the branch that frequently communicates with each other. In the end, there may be many service buses nationwide. However, all bus will be mounted on one bus to achieve nationwide networking.

Next, let me introduceDetailed architecture design of a Service Bus.

2. The procedure is as follows:

1. The shuttle ESB server is the receiving end of the alarm data and the sending end of the alarm data and alarm relief data. The communication system detects the alarm information. The communication system sends the alarm data to the queue in copydata mode, and the shuttle ESB server receives the message;

2. After receiving the message, the shuttle ESB server receives the message and processes the message accordingly (including format conversion, upgrade/downgrade judgment, and automatic release judgment ). Then, send the processed alarm message to machine A and machine B of the client ......

3. The terminal controller mainclient receives the message through handler, and then sends the processed alarm message to each terminal display on the local machine, such as the column adjustment terminal and integrated Dispatching Station;

4. After the terminal receives the alarm relief message, it will undergo some logic processing and then publish a message for the alarm relief;

5. handler of the shuttle ESB server will receive the release message. After some processing, it will send the alarm release message to the terminal controller again, then, it notifies all terminals that have subscribed to the message.

Through the above process, we will build the simplest shuttle ESB service bus on the system.

When I complete this process, I will share several difficult questions:

Shuttle ESB open-source project dll version

When I started to study shuttle ESB, there was always a dll version problem, which caused many problems during project integration.

Later, the nuget plug-in was used to block this problem.

Design defects

For example, 2. When the design is started, the ESB server publishes a message, the mainclient receives the message, and then the mainclient sends the message to each display terminal. The display terminal can also send messages to the ESB server again. In this process, two ESB instances are started (excluding the ESB server) because:

1. mainclient needs to start an ESB instance to listen to messages;

2. Multiple display terminals share a shuttle ESB instance to listen for messages.

This design is problematic, and various strange problems will be reported intermittently:

1. When an ESB instance is started, a large number of related services need to be started, which is time-consuming. It is unwise to start two instances upon logon;

2. the server sends a large number of messages, causing the client to fail to accept normal messages. It will receive error messages until there is no message in the message queue.

Later, I talked to Eben about this problem. He told me that in a process, only one shuttle ESB Service Bus instance can be started, otherwise the system may be unstable.

The solution is very simple. Since two instances cannot be started, and it is laborious and thankless, remove the mainclient's service bus instance and enable the display terminal to directly listen to messages of the shuttle ESB server.

Components do not recognize resources

The original error message is as follows:

component "ICT. RCS. modules. client. mainmenu. mainmenu "does not have the URI"/ICT. RCS. modules. client. mainmenu; component/mainmenu. resource identified by XAML.

The error message is also inexplicable. After repeated attempts, my solution is to change the generation path of mainframework to the module.

The idea is very simple. Because errors are always reported and resources are not displayed, I will change the paths generated for all projects to debug for each project. The project runs properly. However, I don't know which resource does not identify it, and I have not studied it in depth.

Normal system, unstable

When sending alarm data, an error is reported.

The reason is: My colleague from the C ++ group agreed that the interaction between C ++ and shuttle ESB is separated by commas. I split it as agreed and convert it to an array.

When she sends multiple segments (multiple segments are separated by commas, and multiple segments involve specific services), there will always be several more arrays, leading to cross-border errors.

Multithreading solves the problem of slow system startup

During system logon, a bunch of services need to be loaded and an ESB instance needs to be started. Very time-consuming. The user experience is poor.

Therefore, I have one idea: Simulate Ajax. When logging on to the system, another thread is started to start the client shuttle ESB bus instance.

Advantage: optimize programs with multiple threads, reduce startup time, and enhance user experience.

Disadvantage: no experience in designing thread synchronization.

Use ORACLE database table queue

Currently, shuttle ESB supports three types of Queues: MSMQ, sqlserver table-based queues, and rabbitmq. Currently, SQL server uses table-based queues. If you want to replace it with Oracle, you must write it by yourself, and there is no time.

Debugging is not good after integration

After the shuttle ESB is integrated into the project, a large amount of business data and related logic need to be processed. Some of the alarms I have judged here also need to be combined with the Rules Engine for judgment. At the same time, the ArcGIS map interface and business logic are constantly changing, and they also need to make constant adjustments. The data source C ++ is also under development, and it also needs to interact with the rule engine ......

That is to say, as long as there is a problem with the system, it is related to me. As long as the test colleagues test the problem, they will run on me. I followed the code step by step to find out who the problem was, and then let him change it. Time-consuming and laborious.

After a few days, I can't stand it anymore. In this way, I can't do anything else. Then, I added error handling to all the areas that interact with shuttle ESB, and wrote an obvious error prompt. In this way, I was a little less interested in testing.

Shuttle ESB (6)-Application in projects