Distributed monomer brought by microservice architecture

Distributed monomers brought by microservice architecture

Catalog

• Preface
• One 、 Good microservice Architecture
• Two 、 Distributed monomer architecture
  • Coupling example
  • Bad local multi - service development model
  • Poor debugging and testing strategies
  • High cost compensation measures
• 3、 ... and 、 Solutions
  • Focus on core indicators
  • Make a migration plan

Preface

The goal of microservice architecture is to develop services independently 、 Independent deployment , Fast iteration , And technological diversity .
However, we often fail to make clear the boundary of microservices when developing microservices , It leads to a bigger pit , from Monomer architecture Split into Microservice monomer architecture , Has brought even greater disaster ： There is no shortage of pain in developing monomer , The benefits of service orientation are nowhere to be found . If we don't solve these problems , As the service ecosystem grows , Things are getting worse .

One 、 Good microservice Architecture

 

1. Single responsibility , High cohesion and low coupling
2. It can be developed independently 、 Independent deployment 、 Independent expansion and contraction capacity
3. Has its own data storage , Independent database 、 cache 、 Resources such as message queues
4. Speed up the iteration

Two 、 Distributed monomer architecture

 

Although the microservice architecture is very good , Very advanced , But the development process is often due to temporary emergency needs 、 The business personnel don't understand abstraction and other reasons, so they split it into a distributed monomer architecture

Coupling example

 

Left ： service A Call the service B, service B Call the service C, then A Call the service again C To get the results
Right ： service A Call the service B, service B dependent service C, And the service C And relying on services A. Dependency produces a ring
Such a structure will eventually become a distributed monomer , The following problems arise ：

1. Update both services at the same time , I don't know which one to update first , Because of interdependence .
2. A simple logic may span multiple services . If something goes wrong , Only someone who knows more than one service can diagnose the problem

Bad local multi - service development model

Running most of the infrastructure locally , Very likely to encounter “ Unable to run ” The problem of

1. Developers don't know how to run all the dependent services
2. The configuration of developers can not support the running services
   This is the development mode of the single architecture shown , Local people need to run everything , It becomes a micro service unit , Still need to run everything

Poor debugging and testing strategies

1. Difficult to diagnose across networks . In normal development, it is only necessary to simply lower the breakpoint , It is very difficult to diagnose after becoming a distributed monomer , Open all kinds of projects and read the log , Lower breakpoint
2. There is a problem with data synchronization between multiple services , Preparing data requires more time and effort
3. Incorrect configuration , Connection timeout 、 Read write timeout 、 Number of work processes 、 Scalable configuration and so on .
4. Difficult to simulate system interaction （ The message broker 、 Asynchronous queue, etc ）
   One of the benefits of the microservice architecture is to speed up iteration , If you waste a lot of energy on local debugging and testing , The meaning of microservices has been lost

High cost compensation measures

1. Invest heavily in infrastructure and testing , To ensure that the data is synchronized correctly
2. Do a lot of visibility and anomaly detection , Ensure that when synchronizing exceptions and alarms , Can diagnose and solve in time .
3. Train developers , So they don't accidentally introduce changes that can cause data synchronization problems
4. After enough data is synchronized between multiple services , Developers are bound to make mistakes （ Murphy's law ）

3、 ... and 、 Solutions

The current architecture has gone wrong , The most important thing should be to analyze the maintenance cost of the current system 、 The relationship between the modification cost and the cost saved by the new system .
This is a difficult point , We should pay attention to some core indicators , for example

Focus on core indicators

• Delivery time
• Bug Number
• Downtime times
• Number of affected users

Make a migration plan

If the system is not well designed , Such a data coupling architecture has emerged , Make an architecture adjustment plan , Step by step Existing architecture Over to Target architecture

• Gradually merge the coupled services
• Gradually merge the coupled databases
• A large and comprehensive test , For example, black box 、CICD automated testing 、 unit testing 、 Stress testing, etc .

Reference material ：Signs of Failing Service-Oriented Architecture

Link to the original text ：https://www.cnblogs.com/chenqionghe/p/12965074.html