Youpin Wealth Management Co.,Ltd ("UP Wealth" or "the Company") is an intelligent securities service provider. It is committed to transforming the securities service industry with financial technology, and improving the efficiency of all aspects of the securities service industry with big data and AI technology. Providing intelligent investment services to provide various intelligent solutions for securities market operators.
So far, almost all of the company's business has migrated to the TARS platform. In terms of language selection, the company uses C++ for services with extremely high performance requirements, Node.JS full-stack development for strong WEB/strong business logic services, and Java development for big data-related platform development. At present, there are nearly 1500 C++ service modules online, more than 800 Node.JS service modules, nearly 100 Java service modules, and new service modules every day.
In the cross-IDC public network call, the development through a TarsProxyServer transparent protocol proxy module, each IDC's TarsProxyServer maintains a heartbeat, so that the business layer is transparent, only need to configure the agent's endpoint information when using, to achieve no impact The effect of converging the external network under the premise of development.
Due to the historical reasons of the company and the team, when preparing to migrate to TARS, the company has a number of technical teams. The language also includes Java, Node.JS and C++. The communication protocol between each service is basically based on short-chain HTTP/WebService. The shortcomings of overall inefficiency are obvious. The language supported by TARS also includes all the above languages. During the post-migration process, each technical team runs smoothly. When the communication is integrated to switch JCE-based RPC calls, both from performance indicators and division of labor. There has been a great improvement.
Previously, the struct used by our stock market system was transmitted directly, and the field could not be expanded. Domestic securities are constantly developing. When new business is launched, they can only rack their brains to find fields that can be reused. For example, a field indicates the volume of the stock, and the futures target indicates the position. This is for newcomers. It is difficult to understand. However, sometimes, when there are some new businesses that can't find the fields, only a new protocol can be redeveloped. After three or five years of change, not only the number of agreements, but also the field reuse is serious. It is very easy for people unfamiliar with the business to take pits. After the development has taken over, there is no courage to make any modifications. After switching to TARS, it solved a big pain point. Because the TARS protocol supports extension and can be seamlessly compatible with the old version of the client, we can only do one protocol for one service, and each field has its own role. Clear, maintenance costs are much smaller.
The company's business is wide. The hierarchical relationship and dependencies between services are relatively messy before switching to TARS. Often the scope of influence when updating a function or interface is relatively difficult to determine, and some are unpredictable. After using the TARS microservice design, the relationship between the services is much clearer, the iteration of each function is very smooth, and the compatibility of the old and new versions basically no longer has any problems.
From machine management to service deployment to data metrics monitoring, TARS brings us a range of visual management tools. This piece is very friendly for development, testing or operation and maintenance. It is no longer necessary to separately write code for the consumption of an interface and the consumption of an indicator. At the same time, some of the extended monitoring functions also make the operation and maintenance and background development students more assured.
The company has many businesses and systems. Before using TARS, the company did not have a comprehensive technical framework. The problems faced were low development efficiency, high operation and maintenance costs, and no guarantee of system stability.
TARS has multiple language versions such as C++/Node.JS/Java/PHP/Golang, which can open up technical barriers for the company's various teams. At the same time, it has its own powerful operating platform, which allows development to focus on logic only, and disaster recovery/distribution/monitoring/scheduling is completely automated. Not only can the development efficiency be improved, but also the operation and maintenance convenience and stability of the system will be greatly improved.
So far, almost all of the company's business has migrated to the TARS platform. In terms of language selection, we use C++ for services with extremely high performance requirements, Node.JS full stack development for strong WEB/strong business logic services, and Java development for big data related platform development. At present, we have nearly 1500 C++ service modules online, more than 800 Node.JS service modules, nearly 100 Java service modules, and new service modules every day.
The typical business architecture of our company using the TARS architecture is as follows:
In the cross-IDC public network call, we use a transparent protocol proxy module of TarsProxyServer, and keep the heartbeat between each IDC's TarsProxyServer, so that it is transparent to the business layer. When using, you only need to configure the endpoint information of the proxy, which does not affect. The effect of converging the external network under the premise of development, the solution is as shown below: