Service is hot now, the industry is popular comparison are so-called Monolithic applications, and a large number of systems in more than ten years ago were already distributed systems, so microservices as a new concept and the original distributed system, or SOA (service-oriented architecture) what is the difference?



Let’s look at the similarities:

  • Registry is needed to realize the dynamic service registration discovery mechanism.
  • The consistency of distributed transactions should be considered. Under CAP principle, two-stage commit cannot guarantee performance, and transaction compensation mechanism should be considered.
  • Synchronous invocation or asynchronous messaging, how to ensure message reliability? SOA integrates all messages by the ESB;
  • A unified Gateway is required to aggregate and arrange interfaces, realize a unified authentication mechanism, and provide RESTful interfaces for external applications.
  • Similarly, we should pay attention to how to locate system problems under redistribution and how to do log tracking, just as we have done signaling tracking for more than ten years in the field of telecommunications.

Similarities:

  • Is it continuous integration, continuous deployment? For CI, CD (continuous integration, continuous deployment), which itself is intertwined with Agile and DevOps, I think it’s more in the realm of software engineering than microservices technology per se;
  • Is there a difference between using different communication protocols? The benchmark communication protocol for microservices is RESTful, while traditional SOA is generally SOAP. However, lightweight RPC frameworks such as Dubbo, Thrift and gRPC are widely used. In Spring Cloud there is also the RPC-like behavior of Feign framework turning standard RESTful apis into code. These communication protocols should not be the core difference between microservices architecture and SOA;
  • Is it popular container-based framework or virtual machine based? Docker and virtual machine or physical machine are both ways of architecture implementation, not the core difference;



The essence of microservices architecture is sharding

There is a big difference in service segmentation. SOA originally emerged as an “integration” technology. Many technical solutions encapsulate the original internal services of the enterprise into an independent process, so that new business development can reuse these services, which are likely to be very large particles such as supply chain and CRM. The “micro” of micro service shows that he is exquisite in segmentation and does not compromise. There are countless examples that show that if your shards are wrong, you can have more trouble with Monolithic than with the “low coupling, no-impact upgrade, high reliability” benefits that microservices promise.

Microservices that do not split storage are pseudo-services: In practice, we often see a kind of architecture, the back-end storage is all and in a database, just split the front end of the business logic to different service process, in essence, as a Monolithic, just change the module between the in-process calls to call between process, this kind of segmentation is not desirable, in violation of the distributed first principles, Module coupling is not resolved, but performance suffers.

First Principle of Distributed Design – “Don’t distribute your objects”

The word “Micro” for microservices is not as small as possible, but rather we need a smaller and more appropriate granularity than coarse-grained services like SOA, and the Micro is not infinitely small.

If we combine two-way (synchronous) communication with small/micro services and follow principles such as “1 class =1 service”, then we are effectively back in the 1990s with Corba, J2EE, and distributed objects. Unfortunately, the new generation of developers, who have no experience with distributed objects and therefore do not realize how bad this idea is, are trying to repeat history, only this time using new technologies such as HTTP instead of RMI or IIOP.

Microservices and Domain Driven Design

A simple library management system certainly does not require a microservice architecture. Since the micro-service architecture is adopted, the problem space must be relatively large, such as the whole e-commerce and CRM.



How to disassemble the service?

What method is used to dismantle the service? The industry is popular 1 class =1 service, 1 method =1 service, 2 Pizza teams, can rewrite in 2 weeks and other methods, but these lack the implementation basis. We have to look at some software design approaches where the problem space where object-oriented and design patterns apply is a module, whereas the idea of functional programming works more at the micro level of code.

Eric Evans’s domain-Driven Design book is a great guide to microservices architecture, which presents a technique that can break down a large problem space into relationships and behaviors between domains and entities. For now, this is the most reasonable solution to the problem of separation. Through the concept of Bounded Context (hereinafter referred to as BC), we can encapsulate the implementation details, so that ALL BC can realize SRP (single responsibility) principle. Each microservice is a physical mapping of BC in the real world, and the microservices that conform to BC idea are independently and loosely coupled to each other.

Microservices architecture is a good thing, forcing people to focus on the rationality of software design. If Monolithic domain analysis, object-oriented design is not done properly, switching microservices will multiply the problem

With electricity in the two fields, for example, order and the goods in accordance with the DDD apart, they should be two independent bounded context, but the order must be contain goods, if rushed down to two BC, query, call relations are coupled together, even with the troublesome problem of distributed transaction, how the association apart? BC theory holds that in different BCS, even if it is a term, its focus is different. In commodity BC, the focus is on attributes, specifications, details, etc. (In fact, commodity BC has price, inventory, promotion, etc., so it is unreasonable to treat it as a single BC. In order to simplify the example, We first consider commodity BC as basic commodity information), while in order BC, we pay more attention to commodity inventory and price. Therefore, in the actual coding design, the order service will often focus on the commodity name, price and other attributes redundancy in the order, this design freed from the strong association with commodity BC, two BC can provide services independently, independent data storage

summary

Micro service architecture must first concern is not RPC/ServiceDiscovery/Circuit Breaker, these concepts are not Eureka/Docker/SpringCloud/Zipkin the technical framework, but the boundary of the service, responsibility, Partitioning errors can lead to numerous intercalls and distributed transactions between services, in which microservices can be troublesome rather than convenient.