Hello everyone, welcome to Wanmao Academy, learn with me, and you can also become a microservice expert .

The microservice architecture has been summarized by the technical experts in the following nine characteristics:

Service componentization
around business functions
product not project
strong terminal weak pipe
decentralized management
Decentralized Data Management
Infrastructure Automation
fault-tolerant design
evolutionary design

Let's take a closer look at each of them one by one.

Service componentization

When we talk about components, we generally mean functional units that are independently replaceable and independently upgradeable. In the previous architecture, when we introduced components, we used dynamic link libraries or jar packages, or even a set of codes. In the microservice architecture, services are used as components, and lightweight HTTP is used for remote calls.

What are the benefits of doing this? The introduction of dynamic link libraries or jar packages is not safe, and technical means such as reflection can be used to modify the modules. However, when the service is used as a component in a microservice, it is not in the same thread and cannot be modified at all.

around business functions

In the previous monolithic architecture, all code, all logic, and all modules were concentrated in one project. According to Conway's theorem, the organizational structure of the technical team should be divided into: front-end R&D personnel, back-end R&D personnel, and database operation and maintenance personnel, as shown in the following figure:

Microservices tend to divide services around business functions, so the team of each service is cross-functional and may include personnel from all functions, as shown in the following figure:

Here is a casual mention of Conway's theorem, which was proposed in a paper published by Melvin Edward Conway in April 1968.
marvin conway

Its core arguments are:

Organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations
.

In layman's terms: the system design essentially reflects the organizational structure of the enterprise, and the interfaces between the various modules of the system also reflect the information flow and cooperation methods between the various departments of the enterprise.

product not project

Under normal circumstances, the purpose of the project is delivery. When the project is completed, it will be delivered to Party A or the operation and maintenance team, and even the development team of the project will be disbanded.

In the microservice architecture, the output is the product. The so-called product requires continuous evolution and iteration, and a team is responsible for the entire life cycle of the product.

strong terminal weak pipe

In the SOA architecture, the enterprise service bus (ESB) is used as a strong pipeline, because the enterprise service bus undertakes multiple functions such as transmission protocol conversion, data format conversion, service routing, and monitoring and alarming. As shown below:

In microservices, lightweight HTTP is used to make remote calls between services, that is, weak pipelines. In the service itself, some functions such as transmission protocol conversion and data format conversion need to be implemented, that is, strong terminals. As shown below:

decentralized management

Microservices are decentralized when it comes to team management. The team responsible for each service is generally autonomous, including development, testing, operation and maintenance, and implementation, rather than traditional centralized management.

Decentralized Data Management

This feature is very similar to the previous feature, it is decentralized in terms of data management. In the previous monolithic architecture, a central data was used, as shown in the figure below;

In the microservice architecture, the database linked to each service can be different, and even the type of database can be different, as shown in the following figure:

Infrastructure Automation

A monolithic system can be easily built, tested and pushed through these environments.

Due to the finer granularity of service splitting, a large number of services will be generated, and it is very necessary to use automated infrastructure. That is the CI/CD (Continuous Integration, Continuous Integration, Continuous Delivery, Continuous Delivery) that we often refer to.

Current DevOps practices involve continuous development, continuous testing, continuous integration, continuous deployment, and continuous monitoring of software applications throughout their development lifecycle.

fault-tolerant design

Remote calls between a large number of services will inevitably fail due to the unreliability of the underlying hardware or network. Therefore, errors can be tolerated when the service is designed, such as: timeout, retry, failover, idempotency, fuse, current limiting and other mechanisms.

evolutionary design

Because each service is independently developed and deployed, it is relatively easy to change, upgrade, and replace services.

To transform a large monolithic application into microservices, it is definitely not to kill the large monolithic application directly and build a new microservice system, but to transform a certain business step by step in an incremental and non-destructive way. step by step to form a new service.

learn more about

The above is an easy-to-understand introduction to the nine characteristics of microservices. If you are not satisfied with this, you can read Microservices (https://martinfowler.com/articles/microservices.html) for a deeper understanding.

Finally, thank you for being so handsome and giving me a thumbs up .

"Learning Microservices from Scratch" General Catalog

[Learn microservices from scratch] 04. Characteristics of microservice architecture