Why learn architecture?

Because architectural thinking is the cornerstone of coding, if you don’t have architectural thinking in mind, coding is blind, and you can’t write good code if you don’t see the whole picture. Don’t rush the code, first look at the theory, have a general idea. The principle may be understood by looking at it, but only through practice and pain points can we understand and absorb it.

At present, the popularity of the Internet industry and the surge of users make major companies start to consider capacity expansion and reconstruction, and the micro service is the first to be introduced. However, as far as I know, many small and medium-sized technical teams in China do not understand the concept of microservices, and do not agree on whether to introduce microservices or not. There are also some technical teams, without considering the actual business scenarios, just to pursue technical hot spots, blindly introduce microservices, but lack the corresponding technical control ability, and finally affect the stability of the business.

1. Structure selection

The organizational communication style determines the system design.

Choose the architecture according to the size of your company and the shape of your business. A good architecture will evolve step by step. Don’t be too obsessed with new technologies and new architectures.

Architecture must evolve from pain points.

If you don’t know what’s wrong with your current architecture and what the pain points are, you can’t evolve. There are a lot of companies or individuals to see the micro service is very popular, began to blindly pursue. This can only be the fate of the fish.

As for microservices, ALL I can say is, you can’t kill yourself.

The first issue of microservices:

• Should we introduce microservices
• What technologies are needed for microservices
• How does the team evolve and land

This series of articles has published some personal opinions on these issues, hoping to throw a brick to the jade, welcome the big guy to give advice.

Selection of the architecture

The organizational communication style determines the system design.

Conway’s Law: Conway’s Law

“The architecture of design systems is constrained by the communication structure of the organization that produces those designs.”

Each company has a different organizational structure and will evolve into a different structure. This is a key point, and we’ll come back to it again and again.

For example, if your company is a vertical architecture, it is a progressive relationship. There is only one line: back end – front end – test – operation.

If your company has a horizontal architecture, it’s a distributed relationship, such as:

Game department + video department + live broadcast department —- big back end (middle station), then your architecture must be distributed, and made the service split, the public logic into services.

So, are there any silver bullets? No!

Just like why did Ali build the middle platform and then tear it down? With continuous business improvements and architectural evolution, it’s all about better serving the business and reducing development costs.

So:

Choose the architecture according to the size of your company and the shape of your business. A good architecture will evolve step by step. Don’t be too obsessed with new technologies and new architectures.

Architecture must evolve from pain points.

If you don’t know what’s wrong with your current architecture and what the pain points are, you can’t evolve. There are a lot of companies or individuals to see the micro service is very popular, began to blindly pursue. This can only be the fate of the fish.

As for microservices, ALL I can say is, you can’t kill yourself.

So, let’s get to the pain point.

Single structure, monolith structure

Before we start talking about micro services, I want you to talk about individual apps. If you don’t understand the pain of individual apps, you don’t understand the value of microservices.

When the team size is small, individual applications are the best option. The main modes are: LANMP (Linux + Apache or Nginx + MySQL + PHP) and MVC (Spring + iBatis/Hibernate + Tomcat). Its advantages are low learning cost, fast development, testing, deployment, operation and maintenance is more convenient, even a person can complete the development and deployment of a website.

1-4 people small team preferred, let go of the arm is a wanke.

Do not come up on the micro service, a few developers of a small company, to pursue micro service, to pursue the middle platform architecture, this is the pursuit of perfection? No, it’s death.

Advantages of a single architecture

• Fast, in addition to fast or fast, all together, the function is called directly, how not fast, log is also together, what a concern and move the whole body, I am the whole body.

Disadvantages of single architecture

• Complex applications, all coupled together.
  • It makes refactoring harder, agile development harder, and when it collapses, it collapses. One touch touches the whole body.
  • Difficult to expand, may be a long time who dare not move. New colleagues have to read a lot of code, which is expensive to learn. If those responsible leave, it will be an avalanche.
• IDE card, code all together, of course card.
• Slow compilation and startup. When a single application has more code and more resources to rely on, it takes more than 10 minutes to compile, package, deploy and test the application.
• The framework is difficult to upgrade. Upgrade can only be full rise, can not be targeted to use the language advantage.
• Collaborative development costs are high. In my experience, in the early days, when there were only two or three developers on the team, it was manageable to collaborate on code changes, merge them into the same master branch, and then package and deploy them. But once the team expands, more than five people change the code, and then package and deploy it together, every time a piece of functionality fails during the testing phase, you have to recompile the package and deploy it, and then repreview the test, and all the developers involved are involved, which is inefficient and expensive to develop.

What is servitization

Separate the logic in the single application, set up a separate project, develop, test, go online, and operate and maintain independently, and then change the inter-process call into remote RPC call. Each module is not coupled, and can be managed by different teams, and different languages can be selected according to the characteristics of each module. In this way, the problems of single application expansion, high coupling degree of team development and low collaboration efficiency can be solved.

Micro service 1.0

When something is too big, the best way to solve it is to make it small.

Divide and conquer. Simplify.

In my opinion, microservices are also graded. That’s the degree of micro.

For example, we can first split according to the big logic, for example, e-commerce, commodity display, purchase, logistics, so divided. It can also be divided into commodity services, order services, payment services, etc.

Vertical split: Split from the business dimension. For example, we can first split according to large logic, such as e-commerce, commodity display, purchase and logistics information.

Horizontal split: Split from a common, independent functional dimension. The criteria are based on whether there is a common resource that is invoked by multiple other services and is dependent on resources that are not coupled to other businesses. Such as goods service, order service, payment service, evaluation service, etc.

What’s the difference? The former is only divided by interface, I show the interface into a single write, so that the single hung, the purchase of people are not affected. The problem is that I need to write multiple sets of common modules (authentication, underlying methods). Suitable for medium-sized teams, because common modules are not changed every day.

benefit

The business coupling is reduced to the maximum extent. The failure of module A does not affect module B, and modules can be allocated to different people for independent governance.

Trouble offline, but stability online.

For example: account module, at this time, there may be a set of account data generation code in each unit, and then maintain with the same Git. Once updated, all units should be updated.

Although it is also modular logic, it will eventually be packaged and deployed as a singleton application.

The problem

• Code redundancy is severe.
• A single machine can not carry only load balancing, log may be checked on multiple machines. Update, too. Batch code.
• Databases are hard to isolate, especially for users with the largest amount of data, and a bug may cause overall slowdowns.
• Failure cannot be transferred, machine A hangs up, machine B’s code is the same, basically will hang up.
• The impact is an overall business, can not be downgraded, can not be circuit breaker. A hang is a business hang.

Micro service 2.0

The other is by module, or by data, which is really microservice. SOA (Service-oriented Architectural Pattern)

Suitable for large companies with large volumes of business, each module is responsible for a small team.

Minimize communication costs.

When the number of people is up, the biggest cost is not coding time, but communication time.

For example, I will gather accounts into one service, and everyone who needs account information will come to me. Then I will use load balancing and clustering to ensure my high availability. If someone wants to update user data, I will use my interface or my message queue, and I will maintain the consistency of account data.

Built around business or data, services focus on a single business. Lightweight communication mechanisms are used between services, which can be deployed automatically and independently, and can use different programming languages and data storage technologies. Microservice architecture realizes service componentization through business separation. The system is developed rapidly through component composition. Service components with single business can be independently deployed, making the whole system clear and flexible.

• Small is beautiful: Small services have less code, fewer bugs, easier to test, easier to maintain, and easier to iterate and improve refinement and beauty.
• Single responsibility: A service also only need to do one thing, focus to do well.
  • A service does only one thing
  • A bag does only one thing
  • A function only does one thing
• Prototype as early as possible: Provide the service API as early as possible, establish the service contract, and agree on the communication between the services. The implementation and refinement can be done slowly.
• Portability is more important than efficiency: lightweight protocols for interaction between services still consider compatibility and portability first and foremost between efficiency and portability.

What’s the problem?

Fred Brooks wrote 30 years ago,

“There are no silver Bullets.”

But every coin has its downside and microservices are not a panacea.

• Natural complexity
  • Are there bugs in calls between modules?
  • Module A adjusts B, C, D, A link has A problem, is it necessary to check the error log of each module?
  • How is data consistency guaranteed?
• Communication costIt may even rise in the short term.
  • It was my local method, and now I’m going to turn it into a remote call, an interface, or an RPC, and I’m going to check to see if I can ping it.
  • I could see the logic in the code directly, but now the call has questions to ask, and the provider has to add documentation.
• The test difficulty
  • The original single application is updated, the test is done. Now the code of module B is updated, incompatible or buggy, is the module that depends on it all hanging?
• Avoid a chain reaction. The upstream (caller) writes a for loop to the downstream (provider), and then downstream to its downstream, and it can be exponentially amplified.
• Compatibility issues. Once everyone is different, there will be a lot of compatibility issues.
• Dependencies are complex. In the end, the interdependencies between services may become a mess.
• Distributed transaction problem.

How to solve it?

• Infrastructure is in place: message queuing, log collection, container orchestration, etc.
• The document is written, and the gRPC code is the document.
• Automatic deployment, CICD: Gitlab + Gitlab Hooks + K8S
• Dye release for easy development and pressure measurement.
• Monitoring system: K8S, and a series of Prometheus, ELK, Conrtol Panle
• Testing: Test environment, unit test, API automation test

benefit

Since so many people are opting for microservices, the benefits surely outweigh the disadvantages.

• Extremely low coupling. (Decentralization)
  • Data decentralization: monopolize DB to reduce data interference. There will be no longer a case where a slow SQL server is suspended.
  • Technology decentralization: you can use any language you want, as long as you implement the protocol. Ease of refactoring and iteration.
  • Governance decentralization:
    • Independent process, deployed in isolation. Targeted on the cluster, hotspot services on the machine.
    • Monitoring and logging together can quickly detect problems.
• You can call data in parallel, faster than in serial.
• Reduce the cost of communication, everyone can maintain their own services.
• There’s less code, and bugs are easier to spot.

Implementing microservices

• Kit: a basic library (framework) for microservices.
• Service: business microservice composed of business code + Kit dependency + third party dependency
• RPC + Message Queue: lightweight communication

In essence, multiple microservice compositions complete a complete user scenario.

availability

This is a big topic, but I’ll talk about it later.

• isolation
• Timeout control
• Load protection
• Current limiting
• demotion
• retry
• Load balancing

compatibility

Be conservative in what you send, be liberal in what you accept.

Be conservative when sending, open when receiving. When designing and implementing a service according to Bostarr’s law, the data sent should be more conservative, meaning that the necessary information sent should be minimized, and the data received should be more open, meaning that the redundant data should be tolerated to the maximum, ensuring compatibility.

Everything you depend on will collapse. Everything you depend on will collapse. Everything you depend on will collapse.

conclusion

There is no best architecture, only the one that works best for you. A good architecture is one that can be delivered quickly, iterated quickly, and refactured continuously, and is customized to your business and team.

Related reading:

• I heard you don’t know Conway’s Law?
• [Microservice Theory] Practical application of CQRS
• 【 Microservice Theory 】 How to divide microservices
• How can a small company launch micro-services
• [Micro-service landing] Communication mode between services: introduction to gRPC
• API + BFF no longer worries about compatibility and adaptation
• [Microservice Theory] Overview of microservices