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
