background
Recently, I read an article Microservices co-authored by Martin Fowler and James Lewis. The article mainly describes and discusses a service architecture pattern that has become popular recently - microservices. I feel inspired by the practice of my work in recent years. . This article absorbs some of the original views, combined with its own practical experience to discuss the evolution of the service architecture model.
Service Oriented Architecture (SOA)
The concept of service-oriented architecture SOA is nothing new, and it was introduced in many related books about 10 years ago. At that time, J2EE was still the mainstream in the field of java enterprise applications. Applications were deployed in a large unified container that conformed to the J2EE specification and provided all functions in a single process. Some architectural principles proposed by SOA were undoubtedly revolutionary at the time. Due to the existing large number of single huge applications, the transformation according to SOA's ideas and architectural principles is undoubtedly equivalent to overthrow and redeveloping it again, which is difficult to accept in terms of cost. So early SOA is often associated with another term - ESB (Enterprise Service Bus). At that time, in the SOA implementation idea, the ESB model was selected without exception to integrate a large number of single and huge applications to protect the enterprise's initial investment cost. So ESB is actually an implementation of a specific historical stage of SOA.
However, the wish is always good, but the reality is much crueler. Over the past few years we have seen a lot of ESB implementation messed up projects with millions of dollars in investment and almost zero output, so the concept of SOA has also been given an ominous label. The service-oriented architecture that has become popular in recent years, its proponents have begun to reject the label of SOA, which is wrapped in the shadow of failure, and call it the Microservices Architecture Style. But in fact, the microservice architecture is still an implementation of the SOA architecture idea.
Microservice Architecture (Microservices)
We do not have a clear definition of microservice architecture, but in simple terms microservice architecture is:
A set of services is used to build an application. Services are independently deployed in different processes. Different services communicate through some lightweight interaction mechanisms, such as RPC, HTTP, etc. The boundaries of different services can even be implemented in different programming languages and maintained by independent teams.
Microservice Architecture Characteristics (Characteristics)
1. Componentization through services The
traditional way to implement components is through libraries. Traditional components run in-process with applications, and local changes to components mean redeployment of the entire application. Implementing components through services means splitting the application into a series of services running in different processes, so that local changes to a single service only need to redeploy the corresponding service process. In addition, using services as components can define the boundaries of components more clearly, because calls between services are cross-process, and clear boundaries and responsibilities must be considered during design.
2. Divide service and organizational teams by business capabilities
Conway's law states:
organizations which design systems ... are constrained to produce designs which are copies of the communication structures of these organizations
.
In the traditional development method, we stratify engineers into front-end layer, middle layer, and data layer according to their skills and expertise. The roles corresponding to the front-end are UI, page builder, etc. The roles corresponding to the middle layer are server-side business development engineers, and the data layer corresponds to Playing roles such as DBA. In fact, the hierarchical structure of traditional application design architecture reflects the communication structure of different roles. The development model of the microservice architecture is different from the traditional way. It divides the application into different services according to business capabilities. Data storage to external communication and collaboration, etc. The organization of the team is thus cross-functional and contains the comprehensive skills needed to implement the business. The rise of full-stack engineers in recent years is precisely because of changes in architecture and development models. Of course, there are very few full-stack engineers, but it is much easier to organize engineers from different fields into a full-stack team.
3. Service as a product
The traditional application development is based on the project model. After the development team develops a software application according to a bunch of function lists and delivers it to the customer, the software application enters the maintenance mode, and another maintenance team is responsible for the development of the software application. The team's responsibilities are over. Advocates of the microservices architecture propose avoiding this project model, preferring to have the development team responsible for the entire life cycle of the product. Amazon makes a point about this:
You buidl it, you run it.
The development team is fully responsible for the operation of the software in the production environment, allowing service developers and service users (customers) to form daily feedback and feedback. Feedback from direct clients helps developers improve service quality.
4. Smart terminals and dumb pipes
The microservice architecture abandons the overly complex business rule orchestration and message routing of ESBs. The service is an intelligent terminal, all business intelligence logic is processed within the service, and the communication between services is as lightweight as possible without adding any additional business rules.
5. Decentralization and unification
Traditional applications tend to use a unified technology platform or product to solve all problems. Not every problem is a nail, and not every solution is a hammer. The problem has its specificity, and the solution should also have its specificity. Solving specific problems with the most suitable technical solutions is actually difficult to achieve in traditional applications. The microservice architecture means that you can choose different technology platforms or products for different business service characteristics. Targeted solutions to specific business problems.
6. Infrastructure automation
After a traditional application of a single process is split into a series of multi-process services, it means that the complexity of development, debugging, testing, integration, monitoring and publishing will increase accordingly. There must be a suitable automation infrastructure to support the microservice architecture pattern, otherwise the development, operation and maintenance costs will be greatly increased.
7. Design for failure
introduces additional failure factors by separating services into separate processes. Calls to a service at any time may fail because the service side is unavailable, which requires the consumer of the service to handle such errors gracefully. This is actually a disadvantage compared to traditional application development methods. However, with the emergence of some open source service-oriented frameworks, business developers are appropriately shielded from similar error handling, but developers still need to know that the invocation of services is completely Unlike in-process method or function calls.
8.
Once the evolutionary design adopts the microservice architecture mode, we must be very careful when the service needs to be changed. The change of the service provider may cause the compatibility damage of the service consumer. Always remember to maintain the compatibility of the service contract (interface). . For decoupling service consumers and service providers, Postel's law applies in particular:
Be conservative in what you send, be liberal in what you accept
.
When designing and implementing service calls according to the idea of Bostar's Law, the data sent should be more conservative, which means that the necessary information should be transmitted to a minimum, and the more openness when receiving means that the compatibility of information should be tolerated to the greatest extent. Unrecognized redundant information can be ignored and should not be rejected or throw an error.
Microservice Architecture Application
The first problem with adopting a microservices architecture is how to split a single application into multiple services. There is a general principle that functionality provided by a single service can be independently replaced and upgraded. That is to say, if there are two functions of A and B, and if the function of A needs to be changed at the same time, the functions of A and B should be included in one service.
There have been more and more successful experiences in the application of microservice architecture in recent years. For example, Amazon, Netflix in foreign countries, and Alibaba in China have all adopted microservice architecture and achieved many positive success stories. However, from the characteristics of the microservice architecture described above, it can be seen that the microservice architecture model has advantages and disadvantages, and the advantages and disadvantages need to be carefully weighed according to the actual business, team, and environment. The additional complexity of development, testing, operation and maintenance, and monitoring brought about by service splitting can be well supported in the existing environment and team.
In addition, some people may say that I did not adopt the microservice architecture approach at the beginning, but based on a clearly defined modular approach within a single process, the modules are called through interfaces, and at the appropriate stage, the modules will be split when necessary. service for something. In fact, this idea seems too ideal, because the well-defined interface in the process is usually not a very good service interface. The service-oriented design method was not considered at the beginning, so the later splitting is still a painful process.
Summarize
As Martin Fowler said in his article, it remains to be seen whether microservices architecture is the future of enterprise application development. From the current situation, we can remain cautiously optimistic about this, and this road is still worth exploring. Practically any architectural decisions are made based on our imperfect status quo, which is the subtlety of architectural trade-offs, beyond any methodology.
http://blog.csdn.net/mindfloating/article/details/24583369