“This article has participated in the call for good writing activities, click to view: the back end, the big front end double track submission, 20,000 yuan prize pool waiting for you to challenge!”

• 📢 welcome to like: 👍 collect ⭐ message 📝 if there are mistakes please correct, give people rose, hand left lingering fragrance!
• 📢 This article was originally written by Webmote and originally published by Nuggets.
• 📢 author’s motto: life is toss about, when you don’t toss about life, life will start to toss about you, let us come on together! 💪 💪 💪

Preface 🎏

“Rolling east of the Yangtze River, waves all heroes.”

On the road of technology, there are lots of stars. Today, let’s take a look at how “micro services” dominate.

The term “microservices” has been around for, like, a decade, and I’ve been fortunate enough to have been working on it since a long time ago. So always want to write about micro services split theme, but feel that their understanding is not in place, difficult to write.

Without systematic theoretical knowledge, it is difficult to write anything new. 🌷 🌷 🌷

Until RECENTLY, I attended a series of live classes on Thoughtworks. I thought it was time for me to systematically summarize my learning experience and explain it to the recent classes.

It is mixed with their own practice feeling, writing may not be comprehensive, also can not be accurate, welcome to correct! Common 📝 exchange and discussion.

🎏 01. What are microservices?

The concept of Microservice is said to have appeared in 2012. Once it appeared, it had a great impact on the Internet industry, because its idea just conforms to the idea of “divide and rule”. In the increasingly huge Internet industry, it can not help but gradually produce uncontrollable confusion of thoughts, and “micro” just can solve this pain point.

Without definition, we can see from the literal meaning that micro services are small services, and huge services are incompatible with “micro” in any way.

The nuggets dentist once wrote an article “My Three Years in the Nuggets – How to change the engine of a Plane in flight”, in which there is a paragraph of exposition, I think understand very well.

We split uP WordPress indefinitely, so that each function constitutes a service (since subdividing a function is meaningless, and breaking it up again only reduces performance complexity). Then a business consisting of a REPO with function as the smallest unit of service is the smallest pattern in the service.

For the sake of simplicity, we’ll call the minimal service mode Picoservice. The biggest model is called Polyservice. For Polyservice, we just mentioned WordPress is a good example. In reality, there are many polyservices, and traditional businesses may organize code in this way, I believe you have seen it. However, it is rare for every function to be divided into services. I have roughly counted about 10,000 functions in WordPress. You can imagine how scary it would be to split WordPress into Picoservice and eventually organize it into a business. In reality, only the business running on the FAAS platform may be composed and run as a single function.

Based on the definition of service size, we can sort the existing service types by size:

Picoservice <= FAAS(or ServerLess) < Microservice < Monoservice <= Polyservice

Note: Service size is independent of service deployment scale. Both Picoservice and Polyservice can be deployed on multiple machines to improve performance if designed properly.

After looking at the description of grounding, let’s go back and see what microservices really mean.

Microservices is an architectural pattern that advocates the partitioning of a single application into a set of small services, each running in its own separate process, and communicating with each other using a lightweight communication mechanism. Each service is built around a specific business and can be deployed independently into production.

In short, microservices are a way of building software from a single application as a suite of services made up of many tiny services, each with its own lightweight data-processing module and communication mechanism (usually in the form of HTTP apis). Microservices are built around business capabilities and their respective automated deployment mechanisms. Because microservices require minimal centralized management, individual services can use different programming languages and storage technologies.

In those days, luo Guanzhong, who wrote The Three Kingdoms, although he had not done the code farming, wrote the front and back end code, experienced the volume of 996, 007, assumed the system architect, but with their own keen insight, at that time has put forward the IT industry technology development and change of the law: IT is said that the world trend, separated for a long time, with a long time will be divided. At the weekend, the seven states were divided and merged into Qin. And after the end of the Qin Dynasty, chu and Han were divided and merged with Han. The Han Dynasty was divided into three kingdoms after Emperor Gaozu cut off the white snake and rose up to rule the whole country.

You taste, you fine taste! The broad and profound Chinese culture is impressive!

“Divide and conquer” is the essence of micro services! With this understanding, you can design your system architecture as pathetically as possible. Of course, in the future, there will certainly be some structure to unify the country and the trend of The Times.

🎏 02. The birth trajectory of microservices?

Now that we understand the theoretical knowledge of “long separation, long separation”, let’s take a look at the birth track of micro services.

Along the road of points, walk farther and farther.

The complexity of microservice construction due to the splitting of many independent businesses into different microservices generally manifests as follows:

• Registration and discovery of microservices
• Deployment and elastic scaling of microservices
• Communication between microservices
• Efficiency of communication between microservices
• Transactional between microservices (ACID)
• External gateway and current limiting fuse of micro service
• Global configuration of microservices
• Authentication and Authorization of microservices (OAuth2)
• Asynchronous communication and messaging between microservices
• Log of microservices
• Monitoring of microservices

These problems are also the problems of large distributed applications.

So until we get to scale, we can still do it step by step, singleton > SOA > microservices, considering the time cost and other complexity factors.

🎏 03. How to open microservices?

From point A to point B, the straight line is always the shortest distance, but it is often the hardest road to travel! So there are so many winding roads in the world!

Whether retrofitting an old system or building a new one, rushing directly to microservices is risky.

So the general practice recommendations are:

• Single or coarse-grained services are preferred to avoid excessive design;
• Deepen understanding of business boundaries during business evolution;
• Avoid a lot of reconstruction work caused by unreasonable service division in the early stage;

Of course, if the bad taste is rampant in the team, it’s time to make the first move. Yeah, I made the first move.

There are several important ways to split:

🎏 03.1 Event storm method

This approach comes from the traditional DDD domain modeling community. The DDD approach is rarely used in Internet applications for a number of reasons, but here are some important points for your reference:

• The dispute is too big, everyone has different understanding of DDD, and there is no good standard to persuade each other;
• Slow, after all, it is not so easy to make clear the boundaries of each business, and Internet applications are generally agreed to do;
• The concepts of events, commands, aggregate roots, entities, and so on are difficult to understand.

Although there are many shortcomings, but the flaws do not cover up, in the microservice division, DDD has played a key theoretical guidance significance.

The event storm approach brings together business people, domain experts, technicians, architects, and testers to find events, commands, and domain models until the bounded context is demarcated and the problem domain is identified.

The following steps are a bit boring. Read with caution.

03.1.1 Looking for domain events

• Domain events: Capture what is happening in the modeling domain
• Identification: Things that domain experts care about, that actually happen in the business, have a sequence of events
• Identification: Domain events must be valuable to the business and must lead to further business operations

An example: in the commodity order business.

Domain events:

• The product has been created and edited
• The product has been released
• Order created, order cancelled
• Inventory has been reduced
• Outgoing order has been generated
• The outgoing order has been distributed
• The outbound order has been shipped
• The order has been shipped
• The order has been signed
• The order has been confirmed

03.1.2 Searching for commands

• Command: A domain action or domain activity that produces an event
• Identification: user actions, external system triggers, scheduled tasks

As an example, possible commands are:

• Add goods, edit goods
• Release goods
• Add order, cancel order
• Periodically generate outgoing order
• distribution
• The delivery
• Order to sign for
• Order confirmation

03.1.3 Looking for domain models

• Domain model: A visual representation of conceptual classes or real-world objects within a business domain
• Identify: whether it can be accessed independently (yes: is an aggregation, no: belongs to the aggregation it depends on)
• How to do it: Leave an aggregate post-it note with commands on the left and events on the right.

03.1.4 Demarcating bounded contexts

• Bounded context: the business boundaries of a scenario or environment
• Identification: Define business scenarios and then find business boundaries
• Methods: Identify the relationship between adjacent events and establish upstream and downstream roles. Generally speaking, those who publish events are downstream and those who subscribe are upstream.

For example:

03.1.5 Identify the problem domain

• Problem domain: The scope of the problem to be discussed
• Identify: Looking at a problem from the perspective of a business expert can only be done by working with the people who understand the field best.

🎏 03.2 8X Flow business modeling method

8X Flow is a methodology developed and designed by Hao Xu, CTO of Thoughtworks China.

The most confusing aspect of DDD interpretation is the concept of the domain itself, which is popularly regarded as a collection of problems and problems as business abstractions.

So what’s the difference between a domain and a business?

Xu Hao’s point of view: Domain + Operation (operation and maintenance) = business, the Domain is relatively abstract, and the further abstraction can become Domain expert system, and experts can support the business.

8X Flow analysis method steps:

The main idea is to look for business contracts (order payment credentials, order delivery credentials, order receipt credentials, etc.), and based on these credentials, construct payment processes, delivery processes, receipt processes, etc. Even evolved into a bounded context.

🎏 04. Principles for splitting microservices

The principles to be followed for microservice splitting are described as follows:

• Low coupling, single responsibility

The design of microservices is similar to object-oriented design in that it also needs to conform to low coupling, single responsibility design principles.

• One-way dependence

Eliminate loops and two-way dependencies. Use message decoupling for upstream and downstream services.

• Defining upstream and downstream

As the figure below makes clear, upstream and downstream services should follow the following invocation pattern.

• Data operation independence

Data isolation, allowing services to manipulate their own data.

• Tectonic BFF

Construct BFF service for front-end application and integrate the fusion between microservices.

🎏 05. Conclusion

Perhaps as Xu Hao said, the applications of many companies should be business first, not domain first, that is, a lot of business logic, little domain logic, then we will be confused when we split these businesses completely according to DDD.

What works for us is best, and we have so many methods in order to be flexible and solve real problems, rather than getting stuck in these weapons and even making the fallacy that without DDD, micro services are not good.

There’s going to be a lot of real practice, and then we’ll come back to it.

Routine summary, rational view!

Knot is what ah, knot is I want you to praise but can not get lonely. 😳 😳 😳

👓 have seen this, but also care about a thumbs-up?

👓 has been liked, but also care about a collection?

👓 are collected, but also care about a comment?

And a series of front-end articles, guest officer, will you see?

👉 about the micro front end — online a “micro front end” forced away 2 post-90s

👉 front-end project, see me here to manage the global background initialization data, ask you sayin not sayin?

👉 10 minutes to teach you how to design simple and easy to use component level test questions (single choice, multiple choice, fill-in-the-blank, pictures), suggested favorites

👉 Liberate the front End engineer – hand in hand to teach you to develop your own custom list and custom form series one of the reasons

👉 Liberate the front End Engineer – a hands-on guide to developing your own custom lists and the second interface in the custom forms series

👉 Liberate the front End Engineer – A step-by-step guide to developing your own custom lists and custom forms series three tables

👉Vue component customization – Dynamic query rule generation component