1. What are microservices

When introducing micro-service, we should first understand what micro-service is. As the name implies, micro-service should be understood from two aspects: what is “micro” and what is “service”.

Micro, in the narrow sense, means small size and the famous “2 Pizza Team “well explains this explanation. (2 Pizza team was first proposed by Bezos, CEO of Amazon, which means that the design of a single service requires only two pizzas from all participants in design, development, testing and operation and maintenance.) And the so-called service, must be different from the system, service one or a group of relatively small and independent function unit, is the user can perceive the minimum function set.

2. Origin of micro services

Microservices were first proposed by Martin Fowler and James Lewis in 2014. Microservices architecture style is a way to develop a single application using a set of small services. Each service runs in its own process and uses a lightweight mechanism to communicate, usually HTTP API. These services are built on business capabilities and can be deployed independently through automated deployment mechanisms, implemented using different programming languages, and different data storage technologies, with minimal centralized management.

3. Why microservices?

In the traditional IT industry software is mostly a pile of various independent systems, the problems of these systems can be summed up as poor scalability, low reliability and high maintenance costs. SOA servitization was introduced later, but because of the early use of the Bus pattern in SOA, the bus pattern was strongly tied to a technology stack, such as J2EE. As a result, the legacy systems of many enterprises are difficult to connect, the switching time is too long, the cost is too high, and the convergence of the stability of the new system takes some time. As a result, SOA looks beautiful, but becomes an enterprise luxury that small and medium-sized companies are afraid of.

3.1 Problems caused by the early monomer architecture

Monomer architecture works well in a relatively small scale, but with the expansion of the system scale, it is exposed to more and more problems, mainly as follows:

  • 3.1.1. Complexity gradually increases: For example, some projects have hundreds of thousands of lines of code, and the differences between modules are vague and the logic is chaotic. The more codes, the more complexity, and the more difficult it is to solve the problems.
  • 3.1.2. Gradual increase in technical debt: The company’s turnover is normal things, some employees before departure, neglect the self discipline code quality, leads to stay a lot of pit, because of the huge amount of monomer project code, pit is hard to find, it creates a lot of trouble for the new staff, the greater the flow of people left by the hole, the more the so-called technical debt more and more.
  • 3.1.3. Deployment speed gradually slow: it is easy to understand, monomer architecture module is very much, is a large amount of code, lead to the time it takes to deploy project more and more, once some launch should a 20 minutes, this is what a terrible thing, to start the project several times a day to the past, very little time for developers.
  • 3.1.4. Hindering technological innovation: For example, a previous project was written using Struts2. Due to the inextricably linked modules, the amount of code was large and the logic was not clear enough. It would be very difficult and costly to reconstruct this project with Spring MVC. So more often than not, companies have to stick with the old Struts architecture, which hinders innovation.
  • 3.1.5. Failure to scale on demand: Module is CPU intensive modules, such as movies, order module is IO intensive modules, if we want to improve the performance of the order module, such as more memory, hard drives, but because of all the modules in a framework, so we have to consider when extended order module performance factors of other modules, Because we cannot extend the performance of one module to the detriment of the performance of others, we cannot scale on demand.

3.2 Differences between microservices and individual architectures

All modules of a single architecture are coupled together, resulting in a large amount of code and difficulty in maintenance. Each module of microservice is equivalent to a separate project, with significantly reduced code volume and relatively easy to solve problems encountered.

In single architecture, all modules share a database with a single storage mode. Each module of microservices can use different storage modes (for example, some use Redis, some use mysql, etc.), and the database is a single module corresponding to its own database.

Single architecture The same technology is used in the development of all modules, microservices can use different development technology for each module, and the development mode is more flexible.

3.3 Differences between microservices and SOA

Microservices, by their very nature, are SOA architectures. However, the connotation is different. Microservices are not bound to any special technology. In a microservice system, there can be services written in Java or Python, which are unified into a system based on Restful architecture style. Therefore, the micro service itself has nothing to do with the specific technology implementation and has strong scalability.

4. The nature of microservices

Micro service, key in fact is not only the service itself, but the system to provide a basic architecture, this architecture makes the micro service can be independent of the deployment, operation, upgrading, not only that, the system architecture also let micro service and micro service between “loose coupling” in the structure, and on the function of a unified whole. This so-called “unified whole” shows a unified style of interface, unified permission management, unified security policy, unified online process, unified log and audit methods, unified scheduling, unified access and so on.

The purpose of microservices is to effectively split applications for agile development and deployment.

Micro-service advocates the concept of inter-operate and not integrate between teams. Inter-operate is to define the boundaries and interfaces of the system, stack the whole within a team, and let the team be autonomous. The reason is that if the team is organized in this way and the communication cost is maintained within the system, each subsystem will be more cohesive, the dependence and coupling energy of each other will be weakened, and the communication cost across the system will be reduced.

5. What kind of projects are suitable for microservices

Microservices can be divided according to the independence of the business function itself, if the business provided by the system is very low-level, such as: The operating system kernel, storage systems, network systems, database systems, and so on, these systems are partial bottom, closely cooperate relationship between function and the function, if forced to break up into smaller service units, will make the integration work has risen sharply, and this man-made cutting can’t bring real isolation on the business, so I can’t do it to deploy and run independently, It is not suitable for micro services.

The success of micro services depends on four factors:

  • Small: Small size of micro service, 2 pizza team.
  • Independent: Can be deployed and run independently.
  • Light: Uses lightweight communication mechanisms and architectures.
  • Loose: Services are loosely coupled.

6. Micro service folding and design

Moving from a monolithic architecture to a microservice architecture is a constant problem with demarcating service boundaries: For example, if we have a User service that provides basic information about the user, should users’ avatars, pictures, etc., be separated into a new service or should they be merged into a User service? If the granularity of the service is too coarse, it is back to the old way of singleton; If you go too far, the overhead of interservice calls becomes significant and the difficulty of managing them increases exponentially. So far there is no standard that can be called service boundary demarcation, which can only be adjusted according to different business systems.

The general principle of the split is that when a business has little or no dependence on other services, has independent business semantics, and provides data to more than two other services or clients, it should be split into a separate service module.

6.1 Principles of microservice design

  • The single responsibility principle: this means that each microservice only needs to implement its own business logic, such as the order management module, which only needs to handle the business logic of the order, and nothing else.
  • Service autonomy principle: It means that each micro-service is independent from development, testing, operation and maintenance, including the stored database. It has a complete set of procedures, and we can treat it as a project. You don’t have to rely on other modules.
  • The principle of lightweight communication: firstly, the communication language is very lightweight; secondly, the communication mode needs to be cross-language and cross-platform. The reason for cross-platform and cross-language communication is that each micro-service has enough independence and can not be restricted by technology.
  • Interface clear principles: because may exist between the service invocation relationship, in order to avoid later due to a micro service interface changes other micro service do adjustment, at the beginning of the design will consider all situation, let interface to try to do a more general, more flexible, so as to avoid other modules also do adjustment.

7. Advantages and disadvantages of micro-services

7.1 features

Each microservice can run independently in its own process;

A series of independent microservices together build the whole system;

Each service is an independent business development, and a micro service generally completes a specific function, such as order management, user management, etc.

Microservices communicate with each other through some lightweight communication mechanism, such as calling through REST apis or RPC.

7.2 the characteristics of

  • Easy to develop and maintain: since a single module of microservices is equivalent to a project, we only need to care about the logic of the module to develop this module, which reduces the amount of code and logic complexity, thus making it easy to develop and maintain.
  • Faster startup: This is relative to a single microservice, which is significantly faster to start a module than an entire project with a single architecture.
  • Local changes are easy to deploy: Found a problem in the development, if is a monomer architecture, we need to release and start the whole project, is very time-consuming, but service is different, which module the bug we only need to solve the bug of the module is ok, after solving the bugs, we only need to restart the module service, deployment is relatively simple, Not having to restart the entire project saves a lot of time.
  • The technology stack is not limited: for example, the order microservice and the movie microservice were originally written in Java, and now we want to change the movie microservice to nodeJs technology, which is perfectly fine, and since the focus is only on the movie logic, the cost of technology change is much lower.
  • Scaling on demand: We mentioned above that when a single architecture wants to expand the performance of a module, it has to consider whether the performance of other modules will be affected. For us, it is not a problem at all. How to improve the performance of a movie module does not have to consider the situation of other modules.

7.3 disadvantages

  • High operation and maintenance requirements: For a single architecture, we only need to maintain this one project. However, for a microservice architecture, since the project is composed of multiple microservices, problems in each module will cause abnormalities in the operation of the whole project. It is often not easy to know which module causes the problems. Because we cannot track it step by step through debugging, it puts forward high requirements for operation and maintenance personnel.
  • Distributed complexity: For individual architectures, we can not use distribution, but for microservice architectures, distribution is almost a necessary technology. Due to the complexity of distribution, microservice architectures also become complicated.
  • Micro interface high adjustment costs: for example, the user service is to be invoked by order micro service and film micro service, once the user has big change of micro service interface, then all the micro services rely on it to do the corresponding adjustment, due to the micro service may be very much, then adjust the interface caused by the cost will be increased significantly.
  • Repetitive work: For monomer architecture, if a particular section of the business is common used by multiple modules, we can abstract into a utility class, is called all module directly, but the service is unable to do so, because of the micro service utility class is cannot be invoked by other micro service directly, so we had to be built in each micro service such a utility class, This leads to code duplication.

Limited to the platform space reasons, but also for you to better read, micro-services related information and interview materials, the author has sorted out, interested friends can viewBlogger pageTo get it for free

Spring Cloud micro services practice

Basic knowledge of

It mainly covers what is a microservice architecture, the difference between a single system, why Spring Cloud is chosen, and what is Spring Cloud

Microservice Builds (Spring Boot)

It mainly includes: introduction to the framework, quick start, project construction and analysis, implementation of RESTfulAPI, detailed configuration, custom parameters, parameter reference, command-line parameters, multi-environment configuration, loading sequence, monitoring and management, firsthand knowledge of the actuator, and native endpoints.

Service Governance (Spring Cloud Eureka)

The main content includes: Service governance, Netflix Eureka, Registration service provider, high availability registry, service discovery and consumption, Eureka details, service governance mechanism, source code analysis, configuration details, service registration class configuration, service instance class configuration, cross-platform support.

Client Load Balancing (Spring Cloud Ribbon)

The main contents include: Client load balancer, RestTemplate Detail, GET request, POST request, PUT request, DELETE request, source code analysis, load balancer, load balancing policy, detail configuration, automatic configuration, Camden version optimization of RibbonClient configuration, parameter configuration, integration with Eureka, retry mechanism.

Service Fault Tolerance Protection (Spring Cloud Hystrix)

The main contents include: Quick start, Principle analysis, Workflow, Circuit breaker principles, Dependency isolation, Usage details, Create request commands, define service degradation, exception handling, Command names, groups, and thread pool division, request caching, request consolidation, Attribute details, Command properties, Collapser properties, Thread Pool properties, Hystrix dashboard, Turbine cluster monitoring, building monitoring aggregation services, and combining with message brokers.

Declarative service invocation: Quick start, Inheritance features, Parameter binding, Ribbon Configuration, Global Configuration, Specified Service Configuration, Retry mechanism, Hystrix Configuration, Global Configuration, Disabled Hystrix, Specified Command Configuration, Service degradation Configuration, Other Configuration, Log configuration.

API Gateway Services (Spring Cloud Zuul)

Quick start, Gateway Building, Request Routing, Request Filtering, Route Details, Traditional Route Configuration, Service Route Configuration, Default rules for Service Routes, custom route mapping rules, Path matching, Route prefixes, local hops, Cookies and Headers, Hystrix, and Ribbon Support, filter parsing, filters, request life cycle, core filters, exception handling, Disabled filters, Dynamic loading, dynamic routing, dynamic filters.

Distributed Configuration Center: Quick start, build configuration center, configuration rules, rounding, client configuration mapping, service details, infrastructure, Git configuration warehouse, SVN configuration, the local warehouse, local file system, health monitoring, attributes, covers, safety protection, encryption, decryption, high availability configuration, customer details solution, the configuration of service center, fast response and try again, access remote failure Configure and dynamically refresh configurations.

Message bus: Message broker, RabbitMQ implementation message Bus, Basic concepts, Installation and use, Quick start, integrate Spring Cloud Bus, Principle analysis, specify refresh scope, architecture optimization, RabbitMQ configuration, Kafka implementation message Bus, Introduction to Kafka, quick start, integrate Spring Cloud Bus, Kafka configuration, in-depth understanding, source code analysis, other message broker support.

Message-driven microservices: Quick start, core concepts, binder, publish-subscribe pattern, consumer group, message partition, use explanation, unlock the function of binding, binding message channels, news production and consumption, reactive programming, consumer groups, message type and message partition, binder, rounding, binder SPI, automation configuration and binding configuration, the RabbitMQ and Kafka binding Controller, configuration details, basic configuration, binding channel configuration, binder configuration.

Distributed service tracing: Quick start, preparation, implementation tracing, tracing principles, sampling collection, Logstash integration, Zipkin integration, HTTP collection, messaging middleware collection, collection principles, data storage, API interface.

Due to space constraints, the author only selected part of the content, interested friends can viewBlogger pageTo get it for free

Micro-service combat: Dubbox+Spring Boot+Docker