Characteristics of micro-service and principles of its construction
Constraints: MicroServices Follow the UNIX philosophy that applications are a collection of services, and that each service does one thing and does a good job.
Loosely coupled: MicroServices-based applications are a collection of small services that interact with each other using HTTP and rest through a non-specific implementation interface. As long as the service interface has not changed, the inside of the microservices can be modified more freely.
Abstraction: MicroServices have their own data structures and data sources, and the data owned by MicroServices can only be modified by the service.
Standalone: Each micro-service can be compiled and deployed independently.
Granularity of service
You can start with a broader range of microservices, and then refactor it to smaller services.
Focus on how services interact with each other.
As the understanding of the problem domain grows, the responsibilities of the service will change over time.
The service grain is thick, it manifests as: The service takes on too much responsibility, the meal manages the data across a large number of tables, and the test cases become excessive.
Service granularity is very small, it will behave as follows: MicroServices breed like rabbits, and services rely heavily on each other as a collection of simple crud services.
Best Practices for micro-service building
Code base: Each microservices and server information should be in version control and have its own separate code repository.
Dependencies: Explicitly declare dependencies through the build tool (e.g. Maven).
Configuration: Store application configuration (especially environment-specific configuration) separately from code.
Backend services: communicates with a database or messaging system over a network.
Build, publish and run: Keep your application building, publishing and running completely separate, and the built services are immutable.
Process: MicroServices should always be stateless, and they can be killed and replaced at any timeout, without worrying about the loss of a service instance that results in data loss.
Port binding: A running microservices to include a run-time engine (no separate Web server required), the service should start on its own at the command line, and be accessed immediately through the exposed HTTP port.
Concurrency: To initiate more micro-service instances to scale horizontally when demand increases.
Can be arbitrarily disposed of: you can start and stop as needed.
The development environment is equivalent to the production environment: minimizing the gap between all the environments in which the service runs.
LOG: Use the tool to log and view the log visually.
Management process: Use generic scripting to perform administrative tasks on the service.
Build a Hello World Micro Service
This example builds with Spring-boot-web and uses MAVEN Docker plug-ins to create images more easily.
Https://github.com/lyz170/spring-cloud-demo/tree/master/spring-cloud-service-helloworld
Spring Cloud (2): Building microservices-Spring Boot