MicroServices architecture practices based on Openresty and node. js

What is micro-service?

The traditional single service architecture is a separate service package, sharing code and data, development cost is high, maintainability, scalability is poor, technology transformation, cross-language cooperation is relatively difficult. While the MicroServices architecture emphasizes that a service is responsible for a business, the service can be deployed separately, the technology is selected and developed independently, the service is loosely coupled, and the data dependent on the service is independently maintained and managed. Although the micro-service has complex deployment, operation and maintenance difficulty, distributed transaction control difficult, fault-tolerant requirements of high disadvantage, but overall, the advantages of microservices far greater than its complexity.

What issues does the microservices architecture need to be aware of?

Micro-service architecture, first of all to consider the client-server communication problems. There are two solutions, one is the client and multiple server directly communicate, but there are external exposed interface details, a number of interface protocols can not be unified, the client's code complexity, the server upgrade is relatively difficult and so on. Second, the client accesses the Unified API gateway, the API gateway calls a number of service interfaces, easy to implement unified communication protocol, reduce the client and server code coupling, but also to achieve a unified authentication and flow control, however, there is a risk of delay increase in this way, may make API Gateway become the bottleneck of system development.

Micro-service architecture is a distributed service architecture, and how to register and discover services is also a problem to be solved. One is through the client discovery, the caller needs to know all the service-dependent addresses, the development cost is high, the protocol upgrade is more difficult. The other is to find the address of the specific service through the unified gateway, it is simple for the client, can unify authentication and flow control in the gateway, and requires the gateway to be highly available.

Call microservices to be as orderly as possible, avoid calls to each other, and eliminate cyclic calls. Services to have a clear hierarchical relationship, the upper layer of services can rely on lower services, if you encounter the lower service needs to synchronize the message to the upper level of the caller, you can consider asynchronous decoupling through Message Queuing, such as the order/audit system when creating orders or Change Order status, you can consider using double write (that is, after writing to the database, Also write a copy of the message queue, heterogeneous systems (such as order execution systems) can save heterogeneous data by subscribing to messages.

What are some of the practices that push a micro-service?

There are three main types of service scenarios to push. One is a push-to-send scenario, through the Java language Development, SOA architecture approach to achieve, to ensure the real-time and high concurrency of information push, this micro-service transformation is more difficult, the other is the advertising platform, such as the platform, DMP data Management, Java-based development, the number of concurrent requirements, We are stepping up the micro-service of Java-based microservices framework, the third is the web business system, which provides a stateless business API interface for the front-end, is a typical request/response way, at the same time, this is our current micro-service practice most scenarios.

With the rapid development of business, the company's web-related business system development needs continue to increase, these systems are related to user management, background management, rights management and so on. In order to further improve the team development efficiency, we are platform-based services, modular transformation, selected as the above technology selection.

The overall architecture of the push is shown. The request passes through Lvs/haproxy to reach the API gateway based on the Openresty implementation, and the API gateway upstream traffic to the service unit on request. As a whole, the service unit supports the implementation of business logic through the languages of Lua, node. js, and Java, registering with zookeeper at startup, and the API Gateway getting the Service Unit deployment information from zookeeper.

The service unit is as shown. It is openresty unified external exposure server, Openresty built-in Lua language, you can write Lua program in the Weblua Framework for business logic processing. Openresty requests are routed through Proxy_pass,upstream to Webnode processing, and Java business logic can be processed in Openresty through configuration. The service unit is like a drawer cabinet, the specific business (app) is like a drawer, as long as the size of the drawer cabinet requirements, you can push the drawer into the drawer cabinet, drawer language is not required.

Openresty integrates LUA scripting as a programming language and registers with the zookeeper service. To solve the problem of Lua and zookeeper mismatch, start the WebSocket service at openresty startup, The node. JS process starts synchronously with the WebSocket client, so that each node. JS Process maintains a long connection and heartbeat with Openresty, Openresty selects a node. js process and initiates zookeeperclient to complete the service registration. The API Gateway is also based on a service unit that accomplishes service registration in a similar way.

The service unit completes the unified authentication at the Openresty layer without additional performance overhead.

We can use "channel" to describe the problem of call between services. We liken a call between microservices to a water pipe, which flows from one end of the pipe to the request information, and the other end should be requesting information, and we only require that the information flowing in and out be consistent, without concern that the information has been transformed or otherwise processed during transmission. For example, calls between A and B can be implemented through in-process require, and calls between A and C are done through HTTP within the service unit.

Q&a

Q: Is the microservices architecture cumbersome to deploy in operations?

A: With the continuous development of micro-services, the number of services is bound to be more and more, this needs to consider devops. For example, after the code is submitted, it automatically triggers the package compilation through Jenkins, automatically generates the version number, which triggers the automated test deployment and automated testing, a one-click Deployment Upgrade after the test, support for upgrade failure auto-rollback, and so on. We have now implemented automated packaging and test deployment, and the follow-up process is advancing.

Q:openresty The session management has been processed, will developers feel inconvenient?

A: Before the introduction of the MicroServices framework, the company has many independent business services, each with its own account system

System to implement login validation logic. Although there are ready-made code modules available, it is necessary to re-test the validation every time. Today, the specific business services can be done through openresty authentication and unified external, for the development and testing personnel, but reduced a certain amount of work.

MicroServices architecture practices based on Openresty and node. js