Wk 3 Storage Flashcards
Microservice bus function:
Connects microservices together with an open pluggable framework.
Instead of all services having a different protocol you have a common protocol “Bus”.
Microservice bus Characteristics :
It has a single:
- communication protocol
- Data format
- Interface convention
Ex:
Http
Json
Rest
Http:
Synchronous protocol.
Client sends a request and then blocks the channel until it receives a response form the server.
It is well understood, widely implemented and trusted
Http request sections:
- Request Line
- Headers
- Body ( optional)
Rest
Representational state transfer. ( Way to standardize APIs)
What are a the resources provided by microservices:
Resources are formed by combining smaller resources.
Not all resources fit together.
Resources archetypes:
- Documents
- Collection
- Store
- Controller
Documents:
Describe operations on files like resources.
Ex GET PUT DELETE
Collection:
Operations on directory like resources.
The server chooses the name of the resources.
Ex
Get reads directory
Post create new resource in the directory
Store:
Collection of objects.
Each item in the store is named differently.
Operations are directory like but the user decides the object name.
Controller:
Describes impossibile operations on external resources.
Posts causes the external resource to carry out some task and returns any result.
Google remote procedure call
Services connected through grpc are defined using protocol buffers (type safety) and binary data ( for efficient transfer)
How does grpc work:
You agree between two services a binary format that you are going to exchange there after you use your binary encoding.
Benefit or grpc
7 times faster than REST when recieving data and 10 times faster when sending.
( No need to change the data to JSON)
An enterprise computer system may store data using:
- centralised database
- distributed database
Centralised database / monolith database andvantages:
- easier
- ensures accuracy
- consistency of data is maintained
- completeness
Disadvantages of centralised databases:
Everything is coupled so you need an agreement from all departments to effect a change.
Centralised database transactions:
- Commit ( completes successfully) database is moved to a new consistent state
-Aborts ( completes unsuccessfully) the database is restored to a previous consistent state
ACID properties of a transaction:
- Atomicity
- Consistency
- Isolation
- Durability
Atomicity
Something either happens or it donts
Consistency
No transaction is half done
Isolation
One transaction can’t see the actions of another, doesn’t matter the order
Durability
If a transaction happens, it succeeds even if the system fails ( need to check this is correct)
Distributed database
Consists of a series of databases each assigned to a series of individual microservice.
Disadvantages of distributed databases:
Difficult to ensure accuracy, completeness and consistency.
Advantages distributed systems:
A database for each service enables independence in development.
Distributed transactions:
- Two phase commit
- sagas
Two phase commit:
A transaction coordinator asks a number of participant transactions to vote whether they are prepared to commit a change.
Each participant holds locks on its data involved in the transaction until the coordinator decides to commit or abort.
Issues with two phase commits:
- centralised coordinator
- while everyone is voting all databases are locked waiting for the coordinator to decide
Sagas
A coordinator transaction asks each participant to commit or abort a sequence.
The data involved in the transaction is locked only until it decides to commit or abort.
If all participants commit then everything is good otherwise the sequence ends and a compensating transaction is made to undo the work of those that have committed.
Sagas what do they sacrifice?
Atomicity and rely on consistency
Brewers convention:
You can’t have availability, consistency and partition tollerance all the the same time.
CAP theorem
There are 3 fundamental guarantees
Availability
Response is received from every node
( Always access)
Consistency
The same response is received from every node
Partition Tollerance
The system works even if it becomes disconnected
CP example
Banks even if there is a network failure they stay consistent
CA
Unable to tollerate a system failure, you cant have a network ( ex. mainframe )
How to decompose a database ?
- database then code
- code then database
- code and database
Database then code decomposition:
Split the database first then split the code.
No short term benefit
Cost atomisation
Code then database
Split the code first as it’s easier to revoke.
Short term benefits
Confidence to complete the decomposition
Code and database
Split the code and database as the same time
No benefits, more work all at once
Ap
Drops consistency sometimes.
Why would a cloud provider be dissatisfied with the use of JSON communication for documents
- overhead JSON imposes on binary data
- additional overhead processing
-additional storage overhead
From encoding and decoding binary using base64.
Provider use a custom binary format such as gRPC avoids processing and storing overheads , sacrifice flexibility
Problems of using a centralised database for microservices:
The database is distributed across many services:
- duplication : multiple copies of data
- consistency : copies up to date
- security : must have controls everywhere
- transaction management : must have ACID properties
Ap for microservices:
- partition tolerant( available even if there is a network partition)
- may have some inconsistency issues
Improve communication between microservices :
- standard protocol REST small set of common operations
- http : handles client server networking
- standard data format XML JSON easily processed and extended
- Remote procedure call grpc automatically generates networking code
