Micro-Service "microservices" has become one of the most popular hot words in software architecture. There are a lot of articles about microservices on the web, but it feels a lot too far away from us, and we don't find many instances that really apply in enterprise scenarios. Omitted here 10,000 words ~ ~ ~ so want to use their recent period of time using micro-services and by looking at the masters of the article thought to comb out, share out, for your reference (eagerly welcome everyone to shoot bricks, badly beaten best).
What is Micro Service
Remember just when you see the micro-service, pay attention to the micro-word, and then the service, the preliminary understanding is: the entire block of services split into a number of similar tools of the small Web services, for other services to invoke, each service should be extremely small, like the various parts, their duties, assembled into a great service group
Because he is a technical origin, the theory is not very important, so based on the initial understanding, toward the "micro-service" (here to quote, or will be the decision brick) forward. First realized a variety of micro-service construction, heard that there are springboot, there are jersey+jetty, Python, there are nodejs and so on. It is understood that microservices are primarily a restful architecture to provide services (and thrift), and that rest is a "request-response" to HTTP, while rest is a resource-based API style, It can then be understood that microservices are a number of services that can represent the integration of a resource and the operations performed on this resource. Since it is the use and operation of a resource, each micro-service should be a separate individual.
Based on the above understanding, can not wait to use "micro-services" to achieve their own business needs, take a simple customer information management system as an example: the main customer information management, user management, organizational structure management (not many examples here). According to the previous understanding, the customer, the user, the organization structure, should be three different resources, then should divide into three different micro-services. But in a layer of organization, there will be multiple users, and a user will have their own multiple customers, so there is no way to completely separate the three services (or related relations), this does not accord with the previous understanding. However, the relationship between the three is necessary, the existence is reasonable, then it should be three micro-services and mutual cooperation and independent relationship. As a collaborative relationship between team members, they are independent and interdependent.
Summary: MicroServices are based on restful, resource-and resource-based sets of APIs that can implement a completely independent, granular, self-contained service within a module or a specific business scope. Each micro-service provides a set of APIs for use by other microservices or application clients.
What is a microservices architecture? Since the microservices architecture is mentioned, the monolithic application architecture and SOA architecture must also be talked about. 1. What is a monomer application:
When it comes to monomer applications, for example, the typical monomer application is ERP, CRM, BPM and other software. For ERP and large CRM applications, it is possible that one software contains hundreds of function points. The development, maintenance, deployment, error correction, extension, and upgrade of such software will be a major problem for the person concerned (nightmare).
2. What is the SOA architecture
SOA is a solution to the problem of monolithic application architectures: SOA is a service-oriented architecture and a component model that links different functional units of an application (called services) through well-defined interfaces and contracts between these services. Since each service is made up of different functional units, the scope of the service is very wide.
The SOA architecture is similar to the microservices architecture, so much so that many people in the foreign world are thinking that microservices are just two packages of SOA. The length of the SOA and microservices is not discussed here, it is estimated that it will be three days and three nights.
3. What is micro-service architecture
On the surface, the microservices architecture paradigm is very similar to SOA, both of which include a set of services. However, the microservices architecture paradigm is seen as an SOA that does not contain some functionality. These features include the commercialization of Network service descriptions (WS-*) and Enterprise service Bus (ESB) and request packages. MicroServices-based applications favor REST as simple, lightweight protocols rather than WS-*. They also strive to avoid using ESBS and similar functions in microservices. The microservices architecture paradigm also rejects other parts of SOA, such as the concept of the canonical schema (excerpted from the "Chris Richardson microservices series").
The benefits of MicroServices architecture are less than 4. Benefits of MicroServices Architecture
Can solve the complexity of the problem, in the case of the same function, decomposition into a number of collaborative microservices, defined by the rest API boundaries, which is greatly easier to develop, understand and maintain.
The microservices architecture is that each service can be developed by a dedicated development team or individual developer, and developers are free to choose technology without being subject to the prescribed technology and framework, as long as the API Service protocol is interactive (such as restful). This is not very difficult even if you re-technology outdated microservices module or rewrite the previous code.
The MicroServices architecture pattern allows each microservices to be deployed independently, and each service expands independently, and developers no longer need to coordinate the impact of other service deployments on the service. The MicroServices architecture model makes continuous deployment possible.
5. The inadequacy of the micro-service architecture
"MicroServices" emphasizes the size of services, so many people focus on the word "micro", although small services are easier to adopt, but microservices are only the result, not the ultimate goal. The purpose of microservices is to effectively split applications for agile development and deployment.
Micro-Service application is a distributed system, which inevitably brings inherent complexity, and the developer needs to choose the protocol message passing rule and complete interprocess communication. This technology is more complex than the single-use, micro-service.
With regard to the database schema of microservices, this transactional operation is easy to solve for monolithic applications because it is common to update multiple services in the same transaction, because there is only one database, and in the MicroServices architecture, because each microservices uses different databases, the use of distributed transactions is not necessarily a good choice. And now the highly scalable NoSQL database and messaging middleware do not support this requirement. This presents a higher level of requirements and challenges for developers.
Because of the distributed features of MicroServices architectures, it is also a complex task to test the application of a microservices-based architecture. A set of rest APIs to test a single microservices is relatively simple, but often starts all the services associated with it. As a result, the adoption of microservices architectures is not just about agile development and deployment, but also of some complexity.
Micro-service Architecture mode, the application changes will affect multiple services. For example, if you are completing a requirement, you need to modify services A, B, C, and a relies on b,b for C. In a single application, you only need to change the relevant modules, the integration of changes, the deployment is good. In contrast, the microservices architecture model needs to take into account the impact of related changes on different services. For example, you need to update service C, then B, and finally a. Fortunately, many changes typically affect only one service, and few changes require a coordinated multi-service change.
Deploying a microservices application is also complex, and a single application only needs to deploy its own server behind the complex equalizer. Each application instance needs to be configured with basic services such as databases and message middleware. In contrast, a microservices application is typically comprised of a large number of services. According to Adrian Cockcroft's share, Hailo is comprised of 160 different services, while Netflix has more than 600 services. Each service has multiple instances, which forms a large number of parts that need to be configured, deployed, scaled, and monitored. In addition, you need to complete a service discovery mechanism to discover the address (including the server address and port) of the communication service with it. The traditional problem-solving approach does not solve such a complex problem. Ultimately, a successful deployment of a microservices application requires the developer to have sufficient control of the deployment method and a high degree of automation. (Excerpt from "Chris Richardson microservices Series")
According to the above description, in the application of micro-service architecture, there are many instances of microservices, and each service has multiple instances, so the automated deployment of services must be solved with the service discovery mechanism.
Reference articles
Micro-service combat: from architecture to deployment
Create a microservices service? Please answer these 10 questions first
Micro Service guide North (i): what is microservices