微服务 1 springboot

1.介绍microservice

2.介绍springboot

3.创建协作的微服务

4.docker部署微服务

5.添加api描述，openapi/swagger

6.添加持久层

7.reactive microservice

构建 scalable, resilient and manageable microservice

问题：

• How I learned about microservices and what experience I have of their benefits and challenges

autonomous software component, having its own persistence and communicating with api

多个好处：Decomposing the platform's functionality into a set of autonomous software components provides a number of benefits:

好处1：deploy parts of system, integrating existing systems

好处2：replace components with customers'

好处3：being delievered and upgraded seperately

好处3：scaled out to serveral server instances independently

面临挑战：

挑战1：manually configuring load balancers and manually setting up new nodes. time-consuming and error-prone.

挑战2：chain of failures

挑战3：keepping the configuration consistent and up-to-date in all of instances of components

挑战4：monitoring, in terms of latency issues and hardware usage(CPU, memory, disk and the network)

挑战5 collecting log files and correlating related log events

• What is a microservice-based architecture?

defining microservice: splitting up a monolithic application into smaller components, achieving two goals:

1. faster development, enabling continuous deployments

2.easier to scale, manually or automatically

an autonomous software component: independently upgradable and scalable

条件1：mircroservices don't share data in database

条件2：communicating with well defined interface

条件3：deployed as seperate runtime processes, such as docker

条件4：microservice instance is stateless

How big should a microservice be?

1.small enough  to fit to the head of a develper

2.not jeopardize performance(latency) or data consistency

• Challenges with microservices

1.many small components, synchronise communication, a chain of problems

2.configuration up-to-date, many small components,  challenging

3.track a request involved many components, root cause analysis, log events locally

4.analyzing the usage of hardware resources

5.manual configuration, error prone

the 8 fallacies of distributed system

1.the network is reliable

2.latency is zero

3.bandwidth is infinite

4.the network is secure

5. topology doesnt change

6.there is an adminstrator

7.transport cost is zero

8.the network is homogenous

the rule of thumb:

detecting problems, restarting failed components, request to failed component should be resumed when fixed, all of these need to be fully automated.

• Design patterns for handling challenges

the design patterns:

service discovery, edge server, reactive microservices, central configuration, centralized log analysis, distributed tracing, circuit breaker, control loop, centralized monitor and alarm.

spring boot, spring cloud, kubernetes

service discovery

problem: discover microservice

solution: a service discovery service

solution requirments:

1.automatically register or unregister microservices

2.logic endpoint,  request will be routed to one of the microservices

3.load banlance

4. detect instances that are not currently healthy.

two different strategy:

1.client side routing

2.server side routing

edge server:

problems:expose some of the microservices to the outside, and hide the remaining. protected against the requists from malicious clients.

solution:edge server that all incoming requists will go through.

reverse proxy, intergrated with discover service to provide dynamic load balancing capabilities.

solution requirments:

1.internal services should not be exposed to outside; only ruote requests to microservices that are configured to allow external requiests.

2.expose and protect external services from malicious requiests, use OAuth, OIDC, JWT TOKENs and api keys to ensure the clients are trustworthy.

reactive service

problem:synchronize communication using blocking I/O(a restful json api over http),the number of concurrent requests, longer response time, crashing server. overusing breaking I/O, error prone,  a chain of failures, Circuit Breaker,.

solution: use non-blocking I/O， no thread are allocated while waiting

solution requirements: an asynchronous programming model, resilient

central configuation

problem: how do I get a complete picture of configuration, how do I update the configuration

solution: a configuration server

solution requirments: store configuration information for a group of microservices, with different settings for different enviroments(dev, test, prod, qa)

centalized log analysis

problem: How I get an overview of what is going on in the system landscape?find out microservices getting into trouble and start writing error message, find related log messages, Identify which microservice instance is the root cause of the problem

solution: centralized logging,

collecting new logs, interpreting and storing log events in a structured and searchable way in a central database

providing APIs and graphic tools

distributed tracing:

problem: track requests and messages that flow between microservices

ideantify the root cause, find log message related to a specific order number

solution:correlation ID

solution requirments:assign correltion ID to a request, add the correlation ID when a micrservice makes a request.  add the correlation ID to all log events

circuit breaker

problem: synchronized intercommunication, a chain of failure

synchronous requests, blocking I/o

solution: a circuit breaker that prevents new and outgoing requests.

solution requirements: open the circuit and fail fast

probfor failure correction(half open circuit)

close the circuit if the probs detect the service is healed (self heal)

control loop

problem: difficult to manually detect and correct problems

solution:

a control loop constantly observers and , if required, takes action

solution requirements:

kubernetes

centralized monitoering and alarms

problem:

very hard to discover the root cause of problem

solution:

a monitor service

solution rquirements:

collect metrics from all the servers

detect new microservice instance

privide apis and graphic tools

• Software enablers that can help us handle these challecornges

spring boot

spring cloud

Docker

Kubernates

Istio(a service mesh)

• Other important considerations that aren't covered in this book

other important configuration

1.Importance of dev/ops: shorter delivery time,

2.conway's law:

3.decomposing a monolithic application into microservices:slow delivery, slow performance, inconsistant data

4.importance of api design: the same concept, the same description in terms of naming and data type; evolve in a controller manner

5.migration path from on-premise to the cloud

6.good design principles for microservices, the 12 factor api