Overview of overall development

The service architecture is constantly evolving, constantly adapting to suit its business.

The overall development process is as follows:

Developer perspective

As a Java developer, I have experienced the following experiences:

Stage 1: Single architecture

In the early days, most IT systems were monolithic systems, such as the traditional SSH architecture, where the front and back ends were not separated and UI components were included in the control layer:

This is the old ma just graduated when the structure, SSH is the basic interview must ask.

These things have changed a bit, however, and the mainstream is now Spring MVC + Spring Contaienr + Mybatis.

Spring, the eternal spring in Java world!

Stage 2: Distributed architecture

In order to facilitate the expansion of the system, and increase the reuse of the system, the emergence of distributed systems.

On the other hand, the system module expands rapidly. In order to reduce the internal complexity of the system, the system module is disassembled so that it cannot be divided into different systems, which reduces module coupling and speeds up iteration.

Ps: It’s really about reducing the complexity of individual apps and making each app focus on one thing. This can greatly reduce the maintenance cost, in other words, after the development, can let a new graduate to do the operation and maintenance. Get rid of developers and cut costs.

The mainstream systems are SOA and MSA.

SOA

Early distributed systems were based on a service-oriented architecture called SOA.

SOA is the predecessor of microservices, mainly to get rid of the problem of single application, to achieve the following effects:

1. Make full use of existing infrastructure;

2. SOA architecture relies on messaging (AMQP, MSMQ) and SOAP as the primary remote access protocols.

3. Quick response to business changes;

The architecture diagram is as follows:

Heterogeneous systems can also call each other through protocol transformation of messaging middleware.

I did experience this for a while, when the business system was developed in C# and the back-end service I worked on was developed in Java technology. The protocol used Web Services.

However, it does not feel very smooth in use. The main disadvantages are as follows:

(1) SOAP communication protocol commonly used in WebService, usually using XML format for communication, data redundancy, protocol overload

(2) Service governance is very imperfect.

Later, it evolved into the current MICRO-Service Archeticture (MSA), which enables looser coupling and more flexible systems.

MSA

Microservices are a variation of the service-oriented Architecture (SOA) architectural style, a software development technique, that constructs applications as collections of loosely coupled services.

In microservices architecture, services are fine-grained and protocols are lightweight.

• Microservices architecture illustration

advantages

Microservices architecture has a number of important advantages.

First, it solves the problem of complexity. It breaks down individual applications into a set of services. While the total amount of functionality remains the same, the application has been decomposed into manageable modules or services.

These services define explicit RPC or message-driven API boundaries. Microservices architecture reinforces a level of application modularity that is difficult to achieve with a single code base.

As a result, microservices are much faster to develop and easier to understand and maintain.

Third, the microservice architecture enables each microservice to be deployed independently.

Finally, the microservice architecture allows each service to be independently extensible.

Now this kind of architecture mode has become the mainstream, and what I feel most is that if you are only responsible for a single service, you can understand it more thoroughly, and it is not so complicated to maintain. If a function is changed, only the corresponding application can be online.

disadvantages

Some of the ideas of microservices are good in practice, but they also present complications when implemented as a whole.

• Increased operation and maintenance expenses and costs

• Must have solid DevOps integration skills

• Implicit interfaces and interface matching problems

• Code duplication

• The complexity of distributed systems

• Asynchronous mechanisms

• The challenge of testability

In my opinion, the biggest problem of microservices is that after the system is broken down, it is difficult for one person to know the whole picture of the system, so the positioning problem becomes very complicated.

, for example, if a failure occurs, you may want to from the business system API gateway = “=” core transaction is core = “=” risk control system asked again to know the reason, finally found to be returned to the underlying system a failure, it involves multiple communication cost of the system, and basic half ran out of time.

SOA vs microservices

SOA	Microservices Architecture
Maximize the reusability of application services	Focus on decoupling
Systemic change requires modification of the whole	The systematic change is to create a new service
DevOps and continuous delivery are becoming popular, but not mainstream	Strong focus on DevOps and continuous delivery
Focus on business functional reuse	More emphasis is placed on the concept of “context boundaries”
The communication uses the enterprise Service Bus ESB	For communication, less elaborate and simple messaging systems are used
Supports multiple messaging protocols	Use lightweight protocols such as HTTP, REST, or Thrift apis
Use a common platform for all services deployed to it	Application servers are not really used and are usually used on cloud platforms
The use of containers (like Docker) is less popular	Containers work well for microservices
SOA services share data stores	Each microservice can have a separate data store
Common governance and standards	Easy governance with a greater focus on teamwork and freedom of choice

challenge

The challenges of microservices can be summarized as follows:

• API Gateway

• Interservice invocation

• Service discovery

• Service fault tolerance

• Service deployment

• The data call

Fortunately, a lot of mature middleware has solved these problems for us.

First generation microservices framework

Dubbo architecture

Dubbo’s architecture is as follows:

Dubbo does a good job with RPC, but that’s about it.

But why is it still so popular?

Many architecture upgrades have historical baggage, unless you’re a new company, a new application.

Most of the applications are spring or Springboot, so now most companies are springboot + Dubbo technology selection solution, so that the smooth migration of architecture.

If your company is a brand new technology type, consider Spring Cloud.

Spring cloud architecture

The Spring Cloud architecture is as follows:

You’ll find that Spring Cloud is arguably the most complete microservices framework in the Java technology stack.

Of course, spring, however great, is only responsible for the declaration cycle within the JVM, and application deployment operations need to be considered.

Each technique has its advantages and limitations, so it needs to be used in combination.

Recommended reading:

Microservice Architectures With Spring Cloud and Docker

At present, Docker virtualization technology is in its heyday, combined with K8S palm tray.

I’m going to call it the golden age of the coffee-poor migrant, carrying 996 bricks on a freighter in the spring!

Next-generation microservices: Service Mesh?

Service Mesh is also one of the most popular technologies, which will be explained in detail later.

Personal feeling

The evolution of technological architecture and biological evolution are similar, natural selection, survival of the fittest.

Technology learning is not limited to the present moment, learn to look back at the history of technology, why is it so? If it has the ability to lead the future of technology, why not?

I consider myself lucky to have been introduced to singleton applications in the era of Spring XML configuration.

I think I’m very unlucky. Frameworks are coming out and technologies are changing so fast that if you don’t keep learning, you’ll be out of business in five years.

In order not to be eliminated so quickly, this series will gradually understand microservices from the development history of microservices, theoretical knowledge, introduction to use, practical application, implementation principles, and re-building wheels.

I am old ma, looking forward to witnessing the spring of developers together with you!