This article is the great fear was later deleted. Go to my blog to the list - -
text:
Developers tend to produce a series of problems at the beginning of trying to achieve their own micro-service architecture:
- Micro Services division should in the end how?
- A typical service in the end should be more micro-micro?
- If you made a micro-service design, the last really good for you?
Answer the above questions need to first understand the micro-service design logic, science and architecture should be designed through a number of input and gradually deduced result, architects and design of thin air to avoid "shot forehead" approach.
Decoupling monomers service applications and micro-systems on the same logic. For split the service logic, the first field of the design of high cohesion and low coupling model, then the respective distributed system is to achieve a more suitable manner.
There are some basic services division of methods and principles, make these methods more operational micro-services division. Eventually you can find what you want at the time of landing the implementation of micro-services, both for the transformation of legacy systems or new system architecture can ease.
Several stages of micro-split service
Before starting micro-services division, architects need to have a significant understanding of the brain: Micro service is only a means, not an end.
Micro-service architecture is to make the system easier to expand, more elastic. Before the single application to become reliable micro services architecture, each module monomer system should be reasonable and clearly.
In other words, there is no difference from single logical system and micro-service, micro-services just put each module separately under certain monomer system ideally deployed only (recent popular monorepo the code repository services to multiple modules organized together, we proved this point).
A lot of practice lesson tells us that chaos micro-services architecture, brings more trouble than good decoupling monomer app.
(VS good service chaotic micro monomer)
The open source community has been carrying out a lot of discussion, trying to decouple the system to find an effective way, and therefore more than 10 years history of the field-driven design (DDD) methodology is re-understanding. Domain Driven Design based on the abstract object-oriented thinking, from the business, reflect the system by way of a domain model to obtain reasonable service division.
When using DDD services to business modeling and resolution, you can refer to the following stages:
- Using DDD (FIELD driven modeling) business modeling, obtaining abstract models (e.g. orders, user) from the business, divided bounded context according to the relational model.
- Check whether the right model abstraction, and design systems to reflect and respond to business changes.
Services into the gauge to the micro context of DDD, and get the system architecture, API list, integrated approach, etc. output.
(DDD process of using micro-partitioning services)
How abstract?
Abstract need to find the intrinsic link seemingly unrelated matters, the design of micro-services is particularly important.
Suppose one day you buy electricity supplier at a site of an air conditioner, when you pay the cost of air conditioning orders, letting you pay the cost of installation orders again, you must be furious. The reason may be the only architect in the design of the system, such as air-conditioning a common production order, and installed as an additional business logic to generate a separate order.
You must think this is too silly example, the architect did not take into account this point, "installation" should be abstracted into a product, and the "installation behavior" as another service implementation. However, the reality examples abound, Telecom Business Hall or requiring the user to go through a two-step number card business, broadband business. Original abstract model is inappropriate due, and ultimately affect the division of micro-services.
We can use the concept map to describe the relationship of some abstract concept.
(Conceptual diagram of the concept of merchandise)
If there is no abstract domain model, it is not correct micro-services division.
Business modeling using DDD
From the business perspective of system analysis using DDD, after the system abstraction, to obtain a higher cohesive set of business models, a set of concepts in the DDD close, and the height of cohesion can find a clear boundary is referred to as business models bounded context (bounded context).
Context can be regarded as micro-bounded service logical, or a monomer component application. In the field of electronic business is one of several most common concept in the field of electricity supplier orders, merchandise and payments; in the social field is that users, groups, news and so on.
DDD methodology of how to find the boundary subsystem is it?
One practice is called storm event workshops, workshops, business requirements demand author and collaborate on technology implementers domain modeling.
Event the system state to make a change as the key point, from the perspective of system events triggers a reaction system can extract the business model works. Still further identify relationships between model, divided bounded context can be seen as a logical micro-services.
Event is a key point in the system in the data stream, similar to filmmaking keyframes. Before the model is not established, the system is like a black box, the continuous change in the state of the spy system can identify certain physical changes in the reaction system.
For example, a system administrator can log on, create a product, goods shelves, changing the corresponding state of the system is the user has logged in, merchandise has been created, merchandise ready to hit; the corresponding customers can log in, create orders, payments, corresponding to the system state changes the user logged in, order has been created, the order has been paid.
So can understand the above event collection, "Oh, is commodity-related event is the change in the system of goods made in the state, goods can be expressed in one part of the system, goods can be used as a model."
(Using the event spying operations and abstract black box model)
After obtaining the model, derived context bounded by analyzing the relationship between models. And commodities such as product attributes relative to the user, user group more closely, to make the basic context clues bounded by splitting these relationships.
Followed by ambiguous recognition model, so that more accurate gauge context demarcation.
For example, in the field of electronic business, Another example of an inappropriate design are: the as the same concept line items and goods orders are divided into goods and services, but the items in the order in fact and commodity libraries goods are not the same concept .
When an order need to modify the item information in the order, it requires access to goods and services, which will inevitably cause the coupling orders and goods and services.
Reasonable design should be: service providers of goods merchandise information to service orders, service orders, but there is no reason to modify product information, visit as a commodity but a snapshot of line items.
The line item should be divided as an independent concept to order service, rather than goods and use the same concept, even share with a database table.
(Typically having "ambiguous" trap scene)
"Under the orders of goods" and "goods" actually mean different things in different systems, which is the origin of the term "contexts". A group of closely related model forms a context (context), the ambiguity of identification can help us find a context boundary (bounded). As well as the distinction between "orders address" and "user address" in the same example.
Of course, the specific identification DDD bounded context clues are still many, for example, we will gradually unfold in a later article model life cycle. In future articles, we will introduce more ideas and principles on DDD and storm events.
Verification and assessment domain model
Speaking in front of us as micro-bounded context service on logic, but it does not mean that we can directly bounded context become micro-services. Prior to this very important thing is to validate the model, if we get bounded context is abstract not good, after the implementation of micro-services and can not get good scalability and reuse.
After bounded context is designed to verify that our method can be adopted from the two micro-service purposes: reducing the coupling, easy to expand and to be bounded on an assessment of the context of the principle:
Principle 1, bounded between the context designed as possible interdependence should, should not know dependency information upstream to downstream. (To be addicts, such as order-dependent commodities, do not need to know the information in the order).
Principle 2, using a potential business adapt, if they can respond to business change to a certain extent, then prove it with the guidance of micro-out services sufficient to support application development for quite some time.
(General level of abstraction domain model)
The figure is a partial domain model of telecom operators, this section shows the number of telecommunications resources and groups, users, broadband services, telephone services these bounded context.
The main business logic, the system provides a number of resources, users will be bound write card operation when creating and numbering resources, and finally opened the phone or broadband services. In the opening of this telephone business processes, the number of resources does not need to know the information the caller.
But the ideal level of abstraction is often the domain model, cost, reusability these factors in obtaining the balance, the software design is often not ideal domain model, in most cases are struggling to balance a variety of factors, so when the domain model also review to consider the constraints of reality.
( "Abstract" costs)
With a simple diagram to express words, our domain model design is often only achieved a balance of practical value in the middle area of reusability and cost.
The same scene in front of telecom services, business experts and architects that we need a more high degree of abstraction to meet future access to more business for both business and therefore, we need to further abstract concepts and product orders.
But at the same time need to be aware, micro-services will become when we finally landed more, have become more complex, of course, the advantage is obvious - more business can access service orders, service orders at the same time does not need to know specific service access.
For the user's perception, it can handle multiple business and a unified pay, which is currently one of the pain points a telecommunications.
(Highly abstract domain model)
Some typical errors
After extensive use of micro-practice guidance services DDD split, we find that there are some common myths many systems design, divided into three categories: not successfully make abstract, high level of abstraction, false abstraction.
Not successfully make abstract
In the actual development process, we have come to realize, the design phase only consider some common services, but found the project a large number of logic can be reused, and should be made a separate service. When we do service split, missing service is the result of some business logic is distributed to each service, and repeat.
The following is a checklist to help abstract the common items to check if you have:
-
- user
- Competence
- Order form
- Product
- Pay
- Bill
- address
- Notice
- Reports Single
- Journal
- Collect
- invoice
- Financial affairs
- SMS
- Behavior analysis
Abstract error
Inadequate understanding of the micro-service or DDD. Model is ambiguous, being bounded into different contexts. For example, orders shipping address, user configurable standard common address and address in the address database.
These three address Although the name is similar, but not the same thing in concept, if architects will "address" is divided into the standard address database, will inevitably lead to user context and system configuration context, there is the context of the order unnecessary coupling.
(Left to bring abstract error depends on the right to correct dependencies)
The figure on the right is normal dependencies, the left had abnormal dependence, will further generate bi-directional dependence.
In the system design, ambiguous domain model is a more difficult to identify and understand the problem. Fortunately, we can sort out by drawing a conceptual diagram of the relationship between these concepts, concept map is a large number of secondary school supplementary explanation of the concept of the usual means of expression as useful in system design.
(Carding electricity supplier system in the concept of "address")
The concept of a membership between users and user groups;; and also address similar common goods and line items in the product concept should be more specific message to a specific difference between SMS text messages and templates.
Organizational intervention framework
Another surprising architecture issue is the company's organizational structure and team divided affect the proper establishment of the domain model.
There are some companies in accordance with the channel to divide the team, even according to To C (for the user) and To B (for internal) division team, the final design out of the bounded context is out there "C end of the article service", "B-side article service. "
There are plenty of companies because of team responsibilities, this should be a last resort delegated to a centralized service application or BFF (front-end-oriented backend). For such problems, in fact, beyond the scope of DDD can be resolved, such acts can only be vigilant in modeling cause very serious impact on the system.
In addition the relationship between organizational structure and technical architecture, please refer to Conway's Law narrative. A team composed of numerous agile enterprise, and micro-services have a natural link; the traditional waterfall model of enterprise real-time, large-scale software in the era of full competition, but in the Internet age but unable to respond to change.
(Some companies common organizational structure)
The high level of abstraction
Too high a level of abstraction most typical feature was extremely small bounded context. Back to our cost, reusability and extent of these abstract concepts up, we have discussed above, although the degree of abstraction can bring improved reusability, but bring cost is very high, even unacceptable.
The high level of abstraction to bring costs are: service deployment brings more micro-pressure operation and maintenance, development and debugging more difficult to improve inter-service communication brings performance overhead, coordination of transactions across distributed services. So abstract is not as high as possible, it should be based on actual business needs and cost considerations.
That Accordingly, the micro-services in the end should be more small?
Industry spread word to describe how small micro-services should be: "a micro-rewrite service should be completed in two weeks." This sentence may be just a laugh, as if it should be more micro-micro-service standard is not desirable.
Should depend on the size of micro and services within each context is divided bounded bounded context poly extent.
Order service is often a lot of the most complex IT systems, cohesive highest degree of service, often relatively large, but not forced into "orders part1" "orders part2" and other micro-services;
Similarly, SMS services may only be responsible for docking and external systems, performance is extremely simple, but we often need to be deployed separately.
The context of the gauge to the system architecture
After obtaining the domain model and the context bounded by DDD, in theory, we've got a split micro services. However, the context bounded to the system architecture also need to complete the following few things.
Dependencies between micro design services
A reasonable distributed systems, dependencies between systems should be very clear dependence,
In the middle is a software development application or component requires another component to provide the necessary functionality to work properly. Therefore dependent component is not known applications that depend on it, in other words, the caller does not need to know the information of the caller, otherwise this is not a reasonable reliance.
In the micro-service design, if required by a domain service from parameter, make a different behavior depending on the channel, which is fatal to expand the system. For example, users access the service for his source should not be aware of; customer service should provide non-discriminatory service orders, merchandise, logistics and other visitors.
Therefore, the dependence of micro-services can be summarized as follows: upstream downstream system does not need to know the system information, otherwise re-examine the system architecture.
Between micro design services in an integrated manner
Split micro-services in order to better integrate together, for the subsequent landing, there are still integrated service this important stage. Integrated approach between the micro-services will be affected by many factors, earlier when discussing how the micro-micro service in the end of it mentioned in passing will bring integration costs, for different purposes in different integration approach can be used.
- Integrated use of RPC (remote call) way. The way to use RPC allows developers to easily switch to a distributed system development in the past, but coupling RPC remains high, while the need to rely on RPC platform. The industry's best RPC framework dubbo, Grpc, thrift, etc.
- Message using integrated manner. Asynchronous transfer mode using message data between the service using a publish - subscribe interact. Another idea is to transfer to system events, thus creating Event Sourcing this integration model, so that micro-services have a natural elasticity.
- Using RESTful way integration. RESTful API design is a way to maximize the use of the HTTP protocol, the integration between service through HTTP API. In this way let coupling becomes extremely low, even minor modifications can be exposed to the external system.
These three high to low degree of coupling an integrated manner, for different scenarios need to be selected according to the actual situation, it may even exist in the system. Service integration between the way there are other ways, in general, the above three micro-service integrated approach can be summed up most of the current demand common system.
Visualization Architecture and precipitation output
When you first read the DDD relevant information and books, do not remember many of the concepts of DDD, but divided into sub-domains like most of the division-map Chaoshan beef hot pot, left me a deep impression. DDD emphasis on technical and operational staff work together very casual nature DDD drawing performance of map.
But in doing system design should be used more accurate and easy transfer organization chart, for example, using panorama systems (System Landscape diagram) C4 model to express the relationship between the micro-services. Of course, you can also use UML to complete the architectural design. C4 just hierarchical (architectural scaling) way of expressing architectural design, and UML are not in conflict.
System Architecture In addition to the relationship between the micro and services, but also need to talk about technology selection expression.
In addition to micro-services in an integrated manner by the architecture of Figure identifier preferably also convert an event storm events through the API API list; In addition, the model may be refined into the polymerization art DDD root entity, the value of the object, Please refer to the tactical design of DDD.
to sum up
Logic is often more important than experience. The original intention of writing this article is to answer a question: If the boss asked me, based on your micro-services division of what this is, how can I have a convincing reply?
I answer "to analyze specific circumstances? By experience?" Or that I get to analyze the business logic through a set of methods. When there is not enough direct experience to solve the problem, or huge problem to solve when not enough experience, you can support decision-making on issues only to enter a valid analysis.
DDD guidance using micro-services division, can make up for lack of experience in a certain extent, to make well-founded system architecture design.