Service-oriented and microservice Architecture

Background

I recently read an article by Martin Fowler and James Lewis, which describes and explores a recently popular service architecture model-microservices, I feel deeply inspired by my practice in recent years. This article draws on some original ideas and explores the evolution of the Service Architecture Model Based on its own practical experience.

Service-Oriented Architecture (SOA)

The concept of SOA for service architecture is nothing new. Many books have introduced it about 10 years ago. At that time, J2EE was still the mainstream in the Java Enterprise application field, and applications were deployed in a large and unified J2EE compliant container to run, providing all the functions in a single process. Some architecture principles proposed by SOA were undoubtedly revolutionary at that time. Because a large number of single and large applications already exist, the transformation based on the SOA ideology and Architecture Principles is undoubtedly equivalent to re-development, which is difficult to accept in terms of cost. Therefore, early SOA is usually associated with another term-ESB (Enterprise Service Bus ). At that time, the implementation of SOA had chosen the ESB mode without exception to integrate a large number of single and large applications to protect enterprises' initial investment costs. Therefore, ESB is actually an implementation method in a specific historical stage of SOA.

However, the desire is always beautiful, but the reality is much more cruel. Over the past few years, we have seen many projects that have screwed up the implementation of ESB, with millions invested and almost zero output. Therefore, the concept of SOA has become unknown. In a service-oriented architecture that has become popular in recent years, its advocates have begun to reject the label of failure-shadow-wrapped SOA, which is called microservice architecture style ). However, in fact, the microservice architecture is still an implementation of the SOA architecture.

Microservices)

We do not have a clear definition of the microservice architecture, but simply put, the microservice architecture is:

A group of services are used to build an application. Services are deployed independently in different processes. Different Services communicate through lightweight interaction mechanisms, such as RPC and HTTP, services can be expanded and scaled independently. Each service defines clear boundaries. Different services can even be implemented in different programming languages and maintained by independent teams.

Characteristics)

1. Implement componentization through services
Traditional components are implemented through libraries. Traditional components run with applications. local changes in components mean the redeployment of the entire application. Components implemented through services mean that applications are split into a series of services and run in different processes. Therefore, local changes of a single service only need to redeploy the corresponding service process. In addition, services can be used as components to define the boundaries of components more clearly, because calls between services are cross-process, and clear boundaries and responsibility definitions must be considered during design.

2. Division of service and organization teams by business capability
Conway's law points out:

Organizations which design systems... are constrained to Produce designs which are copies of the communication structures of these organizations.
The final design of any design system organization is equivalent to the communication structure within and between the Organization.

In traditional development methods, engineers are divided into front-end layer, middle layer, and data layer based on skill expertise. The front-end roles are UI and page builders, the role corresponding to the middle layer is the service-side business development engineer, and the data layer corresponds to DBA and other roles. In fact, the layered structure of the traditional application design architecture reflects the communication structure of different roles. The development model of microservice architecture is different from the traditional one. It divides applications into different services based on their business capabilities, each service requires full-stack (from the front-end to the back-end) software implementation in the corresponding business field, from the interface to data storage to external communication and collaboration. Therefore, the Team's organization is cross-functional and includes all the skills required to implement the business. The emergence of Full-stack engineers in recent years is due to the transformation of the architecture and development model. Of course, there are very few engineers with full-stack engineers, however, it is much easier to organize engineers in different fields into a full-stack team.

3. Services are products
Traditional application development is based on the project model. After the development team develops a software application based on a bunch of function lists and delivers it to the customer, the software application enters the maintenance mode, the responsibility of the development team is terminated by another maintenance team. The advocates of microservice architecture proposed to avoid adopting this project model and prefer to let the development team take charge of the entire product lifecycle. Amazon puts forward a point of view:

You buidl it, you run it.

The development team is fully responsible for the running of software in the production environment, so that service developers and service users (customers) form daily feedback, feedback from direct clients helps developers improve service quality.

4. Smart terminals and dumb Channels
The microservice architecture discards the over-complicated business rule orchestration and message routing of ESB. As a smart terminal, all business intelligence logic is processed inside the service, while inter-service communication is lightweight as much as possible, without adding any additional business rules.

5. Decentralized unification
Traditional applications tend to adopt a unified technical platform or product to solve all problems. Not every problem is a nail, nor every solution is a hammer. The problem is specific, and the solution should also be targeted. It is difficult to solve specific problems with the most appropriate technical solutions in the traditional application of the big unification, while the microservice architecture means that, you can select different technical platforms or products based on different business service features to solve specific business problems.

6. Infrastructure Automation
After traditional applications with a single process are split into a series of multi-process services, the complexity of development, debugging, testing, integration, monitoring, and release increases accordingly. Appropriate automated infrastructure must be provided to support the microservice architecture model. Otherwise, the development and O & M costs will be greatly increased.

7. Design for failure
This is because additional failure factors are introduced after the service is independent in different processes. A call to a service at any time may fail because the service provider is unavailable. This requires the service consumer to handle such errors elegantly. This is actually a disadvantage of traditional application development methods. However, with the emergence of some open-source service frameworks, business developers can properly block similar error handling, however, developers still need to know that service calls are completely different from in-process methods or function calls.

8. Evolutionary Design
Once the microservice architecture model is adopted, we should be very careful when the service needs to be changed. Changes to the service provider may cause incompatibility damage to the service consumers. Always remember to maintain the service contract (interface). For decoupling service consumers and service providers, the Postel's law is particularly applicable:

Be conservative in what you send, be liberal in what you accept.
Be conservative when sending and open when receiving.

To design and implement service calls according to the bertal rule, the sent data should be more conservative, which means to transmit the necessary information to a minimum, more open reception means to tolerate the compatibility of information to the maximum extent. You can ignore unnecessary information, rather than reject or throw an error.

Microservice Architecture Application

The first problem facing microservices architecture is how to split a single application into multiple services. There is a general principle that the functions provided by a single service can be replaced and upgraded independently. That is to say, if there are two functions, A and B, and the function B needs to change at the same time when the function a changes, then the functions A and B should be included in a service.

Over the past few years, more and more successful experiences have been gained in microservice architecture applications, such as Amazon and Netflix outside China, and many positive success stories have been made in adopting microservice architectures in China such as Alibaba. However, we can see from the features of the microservice architecture described above that the microservice architecture model has both advantages and disadvantages and needs to be carefully weighed based on the actual business, team, and environment. The extra development, testing, O & M, and monitoring complexity brought about by service splitting can be well supported in the existing environment and team.

In addition, some people may say that at first I did not adopt the microservice architecture method, but in a single process, I implemented a clearly defined modular approach, through interface calls between modules, to an appropriate stage, split the module into services when necessary. In fact, this idea seems too ideal, because well-defined interfaces in processes are usually not very good service interfaces. The service-oriented design method was not taken into account at the beginning, so the split time is still a painful process.

Summary

As Martin Fowler said in his article, whether microservice architecture is the future of enterprise application development remains to be tested. As for the current situation, we can be cautious and optimistic about this. This road is still worth exploring. Any actual architecture decisions are made based on our imperfect status quo, which is precisely the subtlety of architecture trade-offs, surpassing any methodology.

Service-oriented and microservice Architecture