1. looking for the ideal integration technology
Select micro-service communication between the very diverse ways, but which one is correct? SOAP? XML-RPC? REST? Protocol Buffers? Will later discuss one by one.
First of all, we have to consider is that in the end we want from these technologies.
1.1 avoid destructive modification
Sometimes, some changes will result in a service consumer to do the service also will be changed. However, we hope that the choice of technology can avoid this from happening.
1.2 API technology to ensure independence
Technology-independent communication between the micro-guarantee service is very important. This means that, in an integrated manner which specific implementation of micro-services technology should not be limited choice.
1.3 makes your service easy to use consumer
Consumer should be easy to use our services. Ideally, the consumer should be able to use any technology to achieve, on the other hand, provides a client library can also simplify the use of the consumer side. But generally this library and other things that we want to get can not have both. For example, using a client library is very convenient for the consumer, but will result in increased coupling.
1.4 Internal hide implementation details
We do not want internal consumer and service implementation details are bound together, as this will increase the coupling. So, all tend to expose the internal implementation details of the technology should not be used.
2. Create a user interface
3. Sharing Database
The most common form of integration is the database industry should be integrated. When using this mode, if you want to get information from other services, a service that can access the database directly. If you want to modify, or you can modify directly in the database.
In this way it looks very simple, and probably the fastest way to integration, which is the reason it's so popular.
But it has some drawbacks.
As shown, the integrated database to access and modify data
One drawback, first of all, which makes it possible to view the interior of the external system implementation details, and bound thereto . Data structure stored in a database for everyone equal and full access to all services database. If I decide to better represent data or increase the maintainability and modify table structure, my consumer will not be able to work.
The database is a large shared API, but also very unstable. In order not to affect the other services, I must be very careful to avoid modification and other services related to the table structure. In this case, usually it takes a lot of regression testing to ensure the function correctness energy.
Shortcoming Second, secondly, consumer choice and specific technical bind together . May now view, the use of relational database storage is reasonable to do, so the consumer can use an appropriate drive (most likely associated with a particular database ) to work together with them. After a period of time maybe we will realize that the use of non-relational database is the better choice.
If consumers and customer service very closely bound together, so the database can easily replace it? The answer is definitely not. Therefore, as previously mentioned before, hiding the implementation details are very important, because it allows us to have a certain degree of service autonomy, which can easily modify its internal implementation. This is related to the loosely coupled.
Shortcoming Third, and finally, we consider the behavior. Will certainly be part of the logical responsible for the customer to be modified. Well, this logic should be placed where it? If the consumer directly manipulate the database, then they are responsible for these logic . Similar logic operation of the database may appear in many services. That is, if the warehouse, registration user interface, the call center will need to edit customer information, so as to fix a bug, you need to modify three different places, and to deploy those changes were made. This is related to cohesion.
We know that the core principles on good micro service is high cohesion and loose coupling . However, the use of database integration makes both of which are difficult to achieve. It is easy to share data through database integration between services, but can not be shared behavior. Exposed to the internal representation of our consumer, but also difficult to achieve non-destructive changes, and thus inevitably lead to dare to make any changes, so by all means avoid this.
In the following section, we will introduce integrated approach between the different styles of service, these methods can ensure internal service implementation to be hidden.
4. The synchronous and asynchronous
Before presenting specific technical choices, we first discuss how collaboration between services. Communication between services should be synchronous or asynchronous it? The different selective basis, will lead us to use different implementations.
If you use synchronous communication to initiate a remote service call, the caller will block your own and wait for the completion of the entire operation. If you are using asynchronous communication, the caller does not need to wait until the operation can return, might not even need to be concerned about whether the operation is complete.
Asynchronous communication is useful for a long time to run tasks, otherwise you will need to open a persistent connection between the client and the server, and then not very practical.
These two different collaborative communication modes have their own style, i.e., the request / response or event-based . Request / response, the client sends a request and waits for a response. This pattern well matches with the synchronous communication mode, but can also use this asynchronous communication mode . We can initiate a request to register a callback and then, after the end of the server operation, it will call back the tone.
For event-based collaborative approach, the situation will be reversed. The client is not initiated the request, but a release event, then expect other collaborators received the message and know how to do. Event-based systems are inherently asynchronous. Event-based collaboration coupling is very low. In other words, the client publishes an event, but does not need to know who or what will make this response, it also means that you can add new subscribers at the request of the event does not affect the client.
5. Arrangement and synergistic
At the beginning of more and more complex logic modeling, we need to deal with cross-service business processes, and the use of micro-services, the issue will come faster.
When we create a user in MusicCorp of what happened:
(1) create a record in the customer's account integration
(2) through the postal system to send a welcome pack
(3) to send a welcome e-mail client
When we consider the specific implementation, there are two architectural styles may be used.
First, the use of choreography. We will rely on a certain centers in the brain to guide and drive the whole process. Second, the use of synergies. We will only inform the system of the various parts of their respective responsibilities, and how to do specific details are left to themselves.
Imagine the orchestration solutions , make customer service without making center of the brain.
When you create, it will follow points account, e-mail services and postal services to communicate by way of response to the request. Customer service itself can currently be what step to be tracked.
The disadvantage is that the presentation of customer service as a central point of control logic to assume too much, it will become the starting point of a network structure in the central hub and a lot of logic. This approach may result in a small amount of the service of God, and those dealing with their service usually become anemic, the CRUD-based services.
If you use a collaborative , can use asynchronous from customer service only way to trigger an event, the event name can be called to create a customer. E-mail services, postal services and points account can simply subscribe to these events and make the appropriate treatment. This method can significantly eliminate coupling.
The disadvantage is that, look at that 4-2 shows the obvious business processes can not view chart.
This means that the need to do some extra work to monitor the process to ensure its proper conduct . A method of handling this problem is to build a monitoring system shown in FIG. 4-2 matches the business process. The actual monitoring activities for each service, but eventually the need to monitor the results of mapping into business processes. In this flow chart, we can see how the system works.
In general, a synergistic manner can reduce the coupling system, and you can more flexible modification of an existing system. However, it does require extra work to do cross-service monitoring of business processes. Moreover, most heavyweight choreography are very unstable and modify the program at great cost. Based on these facts, it is recommended to use a synergistic manner. Because in this way, each service is smart enough and can be very good to complete their task.
If you want to request / response style semantics want to avoid trouble on the time-consuming business, plus asynchronous callback request can be used. On the other hand, the use of asynchronous manner conducive to the implementation of cooperative programs, thus greatly reducing the coupling between services, this is precisely what we can to pursue independent publishing services and features.
Request / response mode, two techniques can be considered: the RPC ( the Remote Procedure Call, Remote Procedure Call) and the REST ( for Representational State Transfer, representational state transfer).
6. Remote Procedure Call
Remote Procedure Call allows you to call a local, but in fact the results are generated by a remote server. RPC wide variety, some of which depend on the definition of the interface (the SOAP , the Thrift , Protocol buffers , etc. ) .
Different technology stack can easily generate client stub code and server via the interface definition.
However, all of these technologies have a central feature of that use local and remote calls to interact.
Some RPC implementation with a particular network protocol bound to ( such as SOAP nominally used is HTTP) , of course, different implementations use different protocols, different protocols can provide different additional features. For example, TCP can guarantee delivery, UDP although it can not guarantee delivery but less protocol overhead, so you can select a different network technologies based on their usage scenario.
RPC implementation that will help you generate server and client stub code, allowing you to quickly start programming. This is usually the RPC one of the main selling points: easy to use.
But there are some RPC implementations do exist some problems .
6.1 Coupling technology
There are some RPC mechanism, such as the Java RMI , closely tied to a specific platform, which caused some restrictions on the server and client technology selection. Thrift and protocol buffers for different languages supported well, thus reducing the impact of this problem to some extent.
To some extent, this coupling is technically a manner exposed internal implementation details.
For example, the use of RMI client binding not only in the JVM on the server as well.
6.2 local calls and long-distance calls are not the same
RPC's core idea is to hide the complexity of remote calls. The use of local calls will not cause performance problems, but RPC will spend a lot of time to carry out a load packing and unpacking, not to mention time network communication. This means that, to use a different design ideas to remote and local API. Simply put a local API Remote API transformed into cross-service often cause problems.
You should also consider the network itself. A well-known distributed computing misconception is the "network is reliable," in fact, the network is not reliable. Even if the client and server are operating normally, the entire call also may be wrong. You should make a hypothesis: there is a malicious attacker may at any time destruction of the network, so the error mode network has more than one.
6.3 Vulnerability
There are some very popular RPC implementation may cause some nasty vulnerabilities.
Here to Java RMI example.
If specification (refer to the interface server definitions, such as adding a new interface ) has been modified, all clients will need to rebuild the pile ( pile here should refer to the way clients achieve ) , regardless of whether the client whether this new approach requires.
There is a form of vulnerability. If we made changes to the server in an object field (such as deleting a useless field ) , if the client does not make the appropriate changes, then even if they have never used this field, or in the course will problems. Therefore, in order to modify these applications, you need to service and client deployment.
This is a challenge to use any mechanism to generate binary pile of RPC to be faced: the deployment of client and server can not be separated.
6.4 RPC bad?
of course not.
If you decide to opt for RPC in this way, then, we need to pay attention to some problems: Do not over-abstraction of remote calls that network element is completely hidden; make sure you can upgrade an independent server interfaces without forcing clients to upgrade, so write to the attention of the client code balance in this regard; the client must not hide that we are doing network calls this fact; in RPC often use the library in the client's way, but these libraries if the organization is structurally inadequate well, it may cause some problems.
6.5 Summary:
RPC request is a request / response in a collaborative way, compared to the use of the database to do an integrated manner, RPC is obviously a huge step forward.
7. REST
REST is an architectural style produced by the Web-inspired. REST style contains a lot of rules and restrictions, but here we only focus on how to use the REST better solve integration problems in the world's micro-services. REST is an alternative to RPC.
The most important point is that the concept of resources . Resources, such as Customer, is within the Service. Service request can be created based on the content of Customer different representations of the object. In other words, there is no coupling between the external display and internal storage of a resource.
REST itself does not mention what should be the underlying agreement, despite the fact that the most common HTTP . In fact, there are other protocols to implement REST example, such as serial or USB, of course, this will introduce a lot of work.
7.1 REST和HTTP
In fact, REST architectural style statement a set of standard methods for all resources, but also just HTTP defines a set of methods are available.
Conceptually, for a Customer resources, access interface is only one, but may be different operations with different verbs HTTP protocol.
HTTP also has a large surrounding ecosystem, which contains a lot of support tools and techniques. For example, such a similar Varnish HTTP caching proxy, mod proxy such as load balancing, a large number for HTTP monitoring tools. These components can help us a good deal HTTP traffic, and use clever way to route it, and these operations are basically transparent to the end customer. HTTP also offers a range of safety control mechanisms for us directly. From basic authentication certificate to the client, HTTP ecosystem provides a number of tools to simplify the security process.
It should be noted, HTTP can also be used to implement RPC. For example, SOAP is HTTP-based routing, but unfortunately it only uses HTTP few features.
7.2 hypermedia as the engine of the state program
REST introduced to avoid further a coupling between a client and server principle "HATEOAS" (Hypermedia As The Engine of Application State, hypermedia engine as a state of the program.)
Hypermedia concept is: a piece of content that contains links to other content, links, content and format of these may be different (such as text, images, sounds, etc.).
HATEOAS idea behind it is that the client should interact with the server through those links to other resources, and these interactions may cause a state transition.
This is similar icon with hyperlinks in web pages, for example, you want to join the shopping cart, you just need to click on the icon, there will be a hyperlink icon next to complete the action to join.
7.3 JSON, XML or other
Because the server using a standard text in the form of a response, the client can be very flexible use of resources, and can provide a variety of different forms of response HTTP-based REST. Such as XML, or the more popular JSON.
7.4 pay attention to too many conventions
Because REST increasingly popular, helping us build a framework RESTFul Web services also will be popular.
It is easy to store data directly exposed to consumers, how to avoid this problem? (Inherent coupling in this way the pain will be far greater than the cost of beginning to eliminate coupling between the concepts required.)
An effective model is to design the external interface, stable and lasting until after the external interface of the data to achieve the micro internal services.
This ensures that the service's interface is driven by consumer demand out so as to avoid affecting the way data is stored on the external interface. The disadvantage is the delayed integrated data storage portion.
7.5 HTTP-based REST shortcomings
From the point of view of ease of use, HTTP-based REST can not help you generate the client stub code, and RPC can .
In addition, you may also experience performance problems . HTTP-based REST support different formats, such as JSON or binary, so the load is relatively SOAP is more compact, and of course, like Thrift such binary protocol is immeasurably. In the low delay requirement scene, each HTTP request may be a problem encapsulation overhead.
Although HTTP communication scenario may be used for a large flow rate , but for low delay communication is not the best choice . In contrast, there are some constructs with the TCP ( Transmission Control Protocol, protocol over Transmission Control Protocol) or other network technologies more efficient. Such as WebSockets, in the initial HTTP After the handshake between the client and the server simply by TCP connected. For transmission of data to the browser in terms of this scenario, WebSockets more efficient.
For communication between the service and the service, if the low latency or smaller messages size is important to you, then generally speaking HTTP is not a good idea . You may need to select a different underlying protocols, such as UDP ( the User Datagram Protocol, User Datagram Protocol) to meet your performance requirements. Many RPC framework can be a good run in addition to TCP on the outside of other network protocols.
RPC support to achieve some advanced serialization and de-serialization mechanism, but for REST , this would own part of the work done.
Despite these drawbacks, the choice of interaction between services, HTTP-based REST default selection is still a relatively reasonable.
Unfinished, continued ...