In the last chapter, we talked about the past and present life of micro-service architecture (I) : the transformation from traditional industry to Internet industry. In the next chapter, we will talk about the evolution of micro-service technology architecture.

The chart below shows the gradual shift from monolithic to microservice applications.

1. Single application architecture

Colloquially speaking, “Monolith Application” is a monolith that packages all the functionality of an application into a single unit. When site traffic is low, only one application is needed to deploy all functions together to reduce deployment nodes and costs.

1, the characteristics of

  • All functions are integrated in one project;
  • All functions are deployed to the server in a WAR package;
  • Applications and databases are deployed separately.
  • You can deploy application clusters and database clusters to improve system performance.

2, strengths,

  • “Easy to develop” : a single IDE can quickly build individual applications;

  • Shareable: A single archive contains all functionality that can be easily shared between teams and between deployment phases;

  • “Easy to test” : Once a single application is deployed, all services or features are available. This simplifies the testing process because there are no additional dependencies and each test can begin as soon as the deployment is complete.

  • “Easy to deploy” : The whole project is a WAR package, once Tomcat is installed, the application can be thrown on it. Cluster deployment is also easy, with multiple Tomcat and one Nginx in a minute.

3 and disadvantages

  • “Hindrance to continuous delivery” : Over time, individual applications can become larger and take longer to build and deploy, hindering frequent deployments and continuous delivery. This problem is particularly acute in mobile application development;
  • Not flexible enough: As projects grow bigger, and the whole development process will be a long time, even in the case of change by only one line of code, software developers need to spend a few minutes or more than one hour of time to compile all of the code, and then spend a lot of time just to redeploy generation product, to verify your changes are correct. If multiple developers work together on an application, then you have to wait for other developers to finish their work. This reduces team flexibility and frequency of functionality delivery;
  • “Constrained by the technology stack” : As projects get bigger, so do the technologies used by our applications. Some of these technologies are incompatible, such as the near-impossibility of mixing C++ and Java on a large scale in a single project. In this case, we need to abandon the use of incompatible technologies and choose a less suitable technology to implement a particular function.
  • “Poor reliability” : A link has an infinite loop, resulting in memory overflow, which will affect the whole project to hang.
  • ** Poor scalability: ** System capacity can only be expanded for applications, not for certain functions, which will inevitably lead to resource waste.
  • “Technical debt” : Suppose I have a messy module structure in my code base. At this point, I need to add a new feature. If the structure of this module is clear, maybe I only need 2 days to add this function, but now the structure of this module is chaotic, so I need 4 days. The extra two days are the interest on the debt. As time goes on and people change, technical debt is bound to increase.

Second, vertical application architecture

When the volume of traffic gradually increases, the acceleration caused by the increase of a single application machine is getting smaller and smaller. The application is divided into several unrelated applications to improve efficiency.

1, the characteristics of

  • Vertical division of projects with single structure scale is to divide a large project into one single structure project.
  • There is data redundancy and high coupling between projects. For example, there is user information in the three projects in the figure above.
  • Interfaces between projects are used for data synchronization, for example, databases between databases are synchronized through network interfaces.

2, strengths,

  • Low development cost and simple architecture;

  • Avoid unlimited expansion of single application;

  • System split realizes traffic sharing and solves the concurrency problem.

  • Capacity expansion and optimization for different systems;

  • Convenient horizontal expansion, load balancing, improved fault tolerance rate;

  • Different technologies can be used for different projects;

  • The systems are independent of each other.

3 and disadvantages

  • Systems call each other. If the port or IP address of a system changes, the calling system needs to be manually changed.
  • The same logical code in a vertical architecture needs to be copied over time and cannot be reused.
  • System performance can only be expanded by expanding cluster nodes, which is costly and has bottlenecks.

SOA service-oriented architecture

As more and more vertical applications become available, the interaction between applications becomes inevitable. Core businesses are extracted as independent services, gradually forming stable service centers. As the number of services increases, problems such as capacity evaluation and waste of small service resources gradually emerge. In this case, a scheduling center needs to be added to manage cluster capacity in real time based on access pressure to improve cluster utilization.

P.S. : from a software design perspective, an ESB is an abstract layer of indirection that extracts something common in the dynamic interaction between the invocation and the invoked during a service invocation, relieving the burden on the service caller. Java programming philosophy says, “All software design problems can be solved or simplified by adding an abstract layer of indirection!” Simply put, an ESB is a pipe that connects service nodes. To integrate services from different systems and protocols, the ESB translates and interprets messages and routes them so that different services can communicate with each other.

1, the characteristics of

  • SOA based architecture abstracts repetitive common functions into components and provides services to each system in the form of services.
  • Each project (system) communicates with the service through WebService, RPC, etc.
  • Use the ESB Enterprise Service Bus as a bridge for communication between projects and services.

2, strengths,

  • The repetitive functions are extracted into services to improve the development efficiency and the reusability and maintainability of the system.
  • Cluster and optimization schemes can be developed according to the characteristics of different services;
  • Adopting an ESB reduces interface coupling in your system.

3 and disadvantages

  • The blurred boundaries between systems and services are not conducive to development and maintenance.
  • Although the ESB is used, the interface protocol of the service is not fixed and various, which is not conducive to system maintenance.
  • The granularity of extracted services is too large and the coupling between system and services is high.
  • It involves a variety of middleware and has high requirements on the developer’s technology stack.
  • Complex service relationships make o&M, testing and deployment difficult

4. Microservice architecture

1, the characteristics of

  • Completely separate the system service layer and extract the service layer into microservices one by one.
  • Each service in microservices corresponds to a unique business capability and follows a single principle.
  • Lightweight protocols such as RESTful are used for transmission between microservices.

2, strengths,

  • Team independence: Each service is an independent development team, which can be a small team of two to five developers;
  • Technology independence: the decentralized idea is adopted, lightweight protocol communication such as RESTful is adopted between services, and the technology and language are used for development without interference from others;
  • Separation of the front and back ends: The front and back ends are developed separately to provide unified Rest interfaces, eliminating the need to develop different interfaces for PC and mobile terminals.
  • Database separation: Each microservice has its own storage capacity and can have its own database. You can have a unified database;
  • Finer granularity of service separation facilitates resource reuse and improves development efficiency.
  • New members of a team can go into production faster;
  • Microservices can be easily understood, modified, and maintained by a single developer so that small teams can focus on their own work. You don’t have to collaborate to be valuable;
  • The optimization scheme (such as expansion) of each service can be formulated more accurately to improve system maintainability;
  • Suitable for the Internet era, shorter product iteration cycle.

3 and disadvantages

  • Too many micro services, high cost of service management, is not conducive to system maintenance;
  • The technical cost of distributed system development is high (network problems, fault tolerance problems, call relationships, distributed transactions, etc.), which poses great challenges to the team;
  • Microservices change from functional invocation to service invocation, either using RPC or HTTP REST, increasing overall system latency. This is inevitable, this requires us to change the original serial programming to concurrent programming or even asynchronous programming, increasing the technical threshold;
  • Multi-service operation and maintenance is difficult. With the increase of services, the pressure of operation and maintenance is also increasing.
  • The difficulty of the test increased. Services interact with each other through interfaces. When the interfaces change, it will affect all callers. At this time, automated testing becomes very important.

That’s it for this article. To get a Java microservices Architecture learning video, please visit the Java Microservices Architecture Spring Bucket tutorial.

The next article will share two stories to help you better understand the difference between SOA and microservices.