Service-oriented and micro-service architecture _soa

Background

A recent reading of an article by Martin Fowler and James Lewis, MicroServices, describes and explores a recently popular service architecture pattern--micro-service, which is inspired by the relative experience of my work in recent years. This paper absorbs some of the original viewpoints and discusses the evolution of the service architecture model with the experience of oneself.
Service-Oriented Architecture (SOA)

Service-oriented architecture The concept of SOA ideas is not new, about 10 years ago, a lot of related books introduced. Java enterprise applications were still in the mainstream, the application was deployed in a large unified container that conforms to the Java EE Specification, and provides all the functionality in a single process. Some of the architectural principles proposed by SOA were revolutionary at the time. Due to the existence of a large number of single large applications, according to the concept of SOA and architectural principles to transform it is tantamount to a reversal of redevelopment, the cost is difficult to accept. So early SOA is often associated with another term--ESB (Enterprise service Bus). At that time, the implementation of SOA in the idea of a choice of ESB model to integrate a large number of single large applications to protect the enterprise upfront investment costs. So the ESB is actually a way to implement SOA-specific historical phases.

However, the desire is always good, the reality is more brutal. In the past few years we've seen a lot of projects that have been messed up by the ESB, with millions of of inputs and almost 0 output, so the concept of SOA is also labelled with an ominous label. The service architecture, which has become popular in recent years, advocates reject the use of SOA, which is wrapped in the shadow of failure, as a micro-service architecture (MicroServices architecture Style). In fact, however, the micro-service architecture is still an implementation of the SOA architecture idea.
Micro-Service Architecture (MicroServices)

We don't have a clear definition of the micro-service architecture, but in simple terms, the micro-service architecture is: a set of services to build an application, the service independently deployed in different processes, the different services through a number of lightweight interaction mechanisms to communicate, such as RPC, HTTP, and so on, the service can be expanded to scale independently, Each service defines clear boundaries, and different services can even be implemented in different programming languages, maintained by an independent team.
Micro-service architecture features (characteristics)

1. Implementation of the component through the service
The traditional way to implement components is through libraries (library), where traditional components are run in the process with the application, and the partial change of the component means the redeployment of the entire application. Implementing components through services means splitting applications into a range of services running in different processes, so local changes to a single service simply redeploy the corresponding service process. In addition, the service as a component can define the boundaries of the component more clearly, because calls between services are across processes, and clear boundaries and responsibility definitions must be considered at design time.

2. Division of services and organizational teams by business capability
Conway's Law (Conway's laws) states: Organizations which design systems are constrained to produce designs which are copies of the CO Mmunication structures of these organizations.
The organization of any design system, the resulting design, is equivalent to the communication structure within and between organizations.

In the traditional development way, we have the engineers layered into the front-end layer, the middle tier, the data layer, the front-end corresponding role for UI, page builder, etc., the middle tier corresponding role is the service end business Development engineer, the data layer corresponds to the role of DBA. In fact, the hierarchical structure of traditional application design architecture is responding to the communication structure of different roles. The development pattern of the micro-service architecture differs from the traditional one, which divides the application into different services according to the business capability, and each service requires a full stack (from the front to back end) software implementation in the corresponding business domain, from interface to data storage to external communication collaboration, etc. The organization of the team is therefore cross-functional, encompassing the full range of skills required to achieve the business. In recent years, the rise of the entire stack of engineers because of the transformation of the architecture and development model, of course, with the entire stack of engineers in fact, but the different areas of the engineers to organize a whole stack of the team is much easier.

3. Service is product
Traditional application development is based on the project model, the development team based on a list of functions to develop a software application and delivery to the customer, the software application into the maintenance mode, the other maintenance team is responsible for the responsibility of the development team to end. Advocates of the micro-service architecture are proposing to avoid this project pattern, preferring to let the development team take over the entire lifecycle of the product. Amazon puts forward a point of view: You buidl it, 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 communication feedback, and feedback from direct clients helps developers improve the quality of their services.

4. Intelligent terminals and dumb pipes
The micro-service architecture abandons the overly complex business rules orchestration, message routing, etc. of the ESB. Services as intelligent terminals, all business intelligence logic is handled within the service, while communication between services is as lightweight as possible without adding any additional business rules.

5. Go to the center of Unification
Traditional applications tend to adopt 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 specific nature, and the solution should also be targeted. Using the most appropriate technical solutions to solve specific problems, in the traditional application of unification is difficult to do, and micro-service architecture means that you can be tailored to different business service characteristics of different technical platforms or products, targeted to solve specific business problems.

6. Infrastructure Automation
When the traditional application of a single process is split into a series of multiple process services, it means that the complexity of development, debugging, testing, integration, monitoring, and publishing increases correspondingly. There must be an appropriate automation infrastructure to support the micro-service architecture model, otherwise the development, operation and maintenance costs will be greatly increased.

7. Design for failure
The additional failure factor is introduced because the service is isolated in different processes. Any time a call to a service may fail because the service is unavailable, which requires the consumer of the service to gracefully handle such errors. This is actually a disadvantage relative to the traditional application development approach, but with the advent of some open Source services frameworks, it is appropriate for business developers to mask similar error handling, but developers still need to know that calls to services are completely different from processes or function calls.

8. Evolutionary design
Once the micro-service architecture pattern is adopted, we should be particularly cautious when the service needs to change, and service provider changes may trigger compatibility breaches of service consumers, keeping in mind the compatibility of service contracts (interfaces). For decoupled service consumers and service providers, Bostalfa (Postel's Law) is particularly applicable: be conservative in what you send, is liberal in what and you accept.
Be conservative when you send, and open when you receive it.

According to Bostalfa's idea to design the implementation of service invocation, the data sent to be more conservative, meaning that the minimum transfer of the necessary information, more open when receiving means to maximize tolerance of information compatibility. Unnecessary information can be ignored and should not be rejected or thrown out.
Application of micro-service architecture

The first issue facing the adoption of a micro-service architecture is how to split a single application into multiple services. There is a general principle that the functionality provided by a single service can be replaced and upgraded independently. That is to say, if there is a and B two functions, if a function changes while the B function also needs to change, then A and b these two functions should be divided into one service.

The successful experience of the application of micro-service architecture has been more and more recently, such as foreign amazon,netflix, the domestic such as Ali are using micro-service architecture has made a lot of positive success stories. However, through the characteristics of the micro-service architecture described above, the micro-service architecture model has both advantages and disadvantages, which need to weigh the pros and cons according to the actual business, team and environment. The service split brings the additional development, testing, operation, monitoring complexity, in the existing environment, the team can be very good support.

In addition, one might say that I did not start with a micro-service architecture, but in a single process based on a well-defined modular approach, between modules through the interface calls to the appropriate stage, when necessary, and then split the module into services. In fact, this idea is too ideal, because the well-defined interfaces in the process are often not very good service interfaces. In the beginning, the service design method is not considered, so the late splitting is still a painful process.
Summarize

As Martin Fowler in his article, whether the micro-service architecture is the future of enterprise application development remains to be tested in time. As things stand, we can be cautious and optimistic, and this road is still worth exploring. Virtually any architectural decision is made based on our imperfect status, which is the subtlety of architectural trade-offs beyond any methodology.