F10 Intro to microservices
Principles of REST: Addressable Resources
- Every "thing" should have an ID - Every "thing" should have a URI
Principles of REST: Connectedness
- The resources contain URIs to other resources
Principles of REST: Communicate statelessly
- The server never needs to know about previous requests
Principles of REST: Constrained/Uniform interface
- Use the standard methods of the protocol - HTTP: GET, POST, PUT, DELETE
Hypertext Transfer Protocol (HTTP)
How data is transferred through the servers. ● Transport Independence - The HTTP protocol generally takes place over a TCP connection, - but the protocol itself is not dependent on a specific transport layer. ● HTTP has a simple structure: - client sends a request - server returns a reply. ● HTTP can support multiple request-reply exchanges over a single TCP connection.
ACID
In computer science, ACID (atomicity, consistency, isolation, durability) is a set of properties of database transactions intended to guarantee data validity despite errors, power failures, and other mishaps.
Synchronous and asynchronous interaction
Synchronous interaction("I synk") ● service A issues a request to service B. Service A then suspends processing while B is processing the request. ● It waits until service B has returned the required information before continuing execution. Asynchronous interaction("I osynk") ● service A issues the request that is queued for processing by service B. A then continues processing without waiting for B to finish its computations. ● Sometime later, service B completes the earlier request from service A and queues the result to be retrieved by A. ● Service A, therefore, has to check its queue periodically to see if a result is available.
RESTful Services
Representational State Transfer ● The REST architectural style is based on the idea of transferring representations of digital resources from a server to a client. - You can think of a resource as any chunk of data such as credit card details, an individual's medical record, a magazine or newspaper, a library catalogue, and so on. - Resources are accessed via their unique URI and RESTful services operate on these resources. ● This is the fundamental approach used in the web where the resource is a page to be displayed in the user's browser. - An HTML representation is generated by the server in response to an HTTP GET request and is transferred to the client for display by a browser or a special-purpose app. There are 2 extra verbs available in rest ● HEAD - Retrieve meta data about a Resource, such as a hash of the data or when it was last updated. ● OPTIONS - Retrieve information about what the Consumer is allowed to do with the Resource. A good RESTful API will make use of the four and a half HTTP verbs for allowing third parties to interact with its data, and will never include actions / verbs as URL segments.
Coupling
a measure of the number of relationships that one component has with other components in the system. Low coupling means that components do not have many relationships with other components.
Cohesion
a measure of the number of relationships that parts of a component have with each other. High cohesion means that all of the parts that are needed to deliver the component's functionality are included in the component.
Software services / web APIs
● A software service is a component that can be accessed from remote computers over the Internet. - Given an input, a service produces a corresponding output. ● Accessed through its published Application Programming Interface (API) all details of the implementation are hidden. (Om du inte fattar, kolla bilddokumentet)
CCP - 'common closure principle'
states that classes that change for the same reason should be in the same package. Perhaps, for instance, two classes implement different aspects of the same business rule. The goal is that when that business rule changes developers, only need to change code in a small number - ideally only one - of packages. This kind of thinking makes sense when designing services since it will help ensure that each change should impact only one service.
HTTP Response codes
● 1xx range is reserved for low-level HTTP stuff, you shouldn't need to send these. ● 2xx range is reserved for successful messages where all goes as planned. Sending these in response is good practice. ● 3xx range is reserved for traffic redirection. Most APIs do not use these requests. ● 4xx range is reserved for responding to errors made by the Consumer (user of the API), e.g. they're providing bad data or asking for things which don't exist. ● 5xx range is reserved as a response when the Server makes a mistake. Often times, these errors are thrown by low-level functions even outside of the developers hands, to ensure a Consumer gets some sort of response.
Microservices architecture
● A microservices architecture is an architectural style ● It addresses two problems with monolithic applications - The whole system has to be rebuilt, re-tested and re-deployed when any change is made. - As the demand increases, the whole system has to be scaled, even if the demand is localized to a small part of the system.
Microservice characteristics
● A well-designed microservice should have high cohesion and low coupling. ● Each microservice should have a single responsibility i.e. it should do one thing only and it should do it well. - One thing only is difficult to define in a way that's makes sense in all situations. - Responsibility does not always stop at a single, functional activity. ●Self-contained Microservices do not have external dependencies. They manage their own data and their own user interface. ●Lightweight Microservices communicate using lightweight protocols, so that service communication overheads are low. ●Implementation-independent Different parts of a system can be built with different languages and frameworks. ●Independently deployable Each microservice runs in its own process and is independently deployable, using automated systems. ●Business-oriented Microservices should be built for the purpose of solving the overall goals, and that purpose should be defined and understandable.
Principles of REST
● Addressable Resources ● Constrained/Uniform interface ● Connectedness ● Communicate statelessly
Inconsistency management
● An ACID transaction bundles a set of data updates into a single unit so that either all updates are completed or none of them are. ACID transactions are impractical in a microservices architecture. ● The databases used by different microservices or microservice replicas need not be completely consistent all of the time. ● Dependent data inconsistency - The actions or failures of one service can cause the data managed by another service to become inconsistent. ● Replica inconsistency - There are several replicas of the same service that are executing concurrently. These all have their own database copy and each updates its own copy of the service data. You need a way of making these databases 'eventually consistent' so that all replicas are working on the same data.
APIs
● Application Programmer Interface ● Specifies how software components communicate with each other - Java Filesystem API, etc
Constrained/Uniform interface all HTTP methods that are used in REST
● Create Implemented using HTTP POST, which creates the resource with the given URI. If the resource has already been created, an error is returned. ● Read Implemented using HTTP GET, which reads the resource and returns its value. GET operations should never update a resource so that successive GET operations with no intervening PUT operations always return the same value. ● Update Implemented using HTTP PUT, which modifies an existing resource. PUT should not be used for resource creation. ● Deleate Implemented using HTTP DELETE, which makes the resource inaccessible using the specified URI. The resource may or may not be physically deleted.
Eventual consistency
● Eventual consistency is a situation where the system guarantees that the databases will eventually become consistent. ● You can implement eventual consistency by maintaining a transaction log. ● When a database change is made, this is recorded on a 'pending updates' log. ● Other service instances look at this log, update their own database and indicate that they have made the change.
Resources
● Every resource has a URI - http://su.se/students/992211- http://su.se/students/992211/email - http://su.se/students?id=99221 - From a URI we know •. The protocol (How do we communicate) • The host/port (Where it is on network) • The resource path(What resource are communicating with)
Communication Protocols
● Identification - URIs ● Interaction - HTTP ● Standardized Document Formats - HTML,XML,JSON,etc.
Benefits of microservices architecture
● Microservices are self-contained and run in separate processes. ● In cloud-based systems, each microservice may be deployed in its own container. ● If the demand increases, replicas can be quickly created and deployed.
Microservices
● Microservices are small, stateless, services that have a single responsibility. ● They are combined to create applications. ● They are completely independent with their own database and UI management code. ● Software products that use microservices have a microservices architecture. ● They (help) make things adaptable, scaleable and resilient.
HTTP Request Headers
● Request Headers provide information to the server about the client - whatkindofclient - whatkindofcontentwillbeaccepted - whoismakingtherequest ● Each header line contains an attribute name followed by a ":" followed by a space and the attribute value. GET /news/article332 Host: www.newspaper.com User-Agent: Mozilla/5.0 ...
Document formats
● Resources can have more than one format - JSON, HTML, XML, etc ● If there are multiple formats they can be requested - In the URI : http://bigburgers.com/menu.json - Or in the Headers: GET /menu Host: bigburgers.com Content-Type: application/json
HTTP Response Headers
● Response Headers come before the content returned from the server - Status line (e.g. 404 Not Found, or 200 OK) - What kind of document is being sent - How big the document is - How the document is encoded - When the document was last modified - If the document should be cached HTTP/1.x 200 OK Transfer-Encoding: chunked Date: Sat, 29 Mar 2014 14:22:20 GMT Server: Newspaper2 ...
Constrained/Uniform interface Safe and Idempotent Methods
● SAFE methods -can be ignored or repeated without problems -HTTP methods that do not modify/change resources. ● IDEMPOTENT methods -can be repeated without problems -HTTP methods that can be called many times without different outcomes. It would not matter if the method is called only once, or ten times over. The result should be the same(This only applies to the result, not the resource itself). EX: a= 4; a++; The first example is idempotent: no matter how many times we execute this statement, a will always be 4. The second example is not idempotent. Executing this 10 times will result in a different outcome as when running 5 times. Since both examples are changing the value of a, both are non-safe methods. HTTP Method Idempotent Safe OPTIONS yes yes GET yes yes HEAD yes yes PUT yes no POST no no DELETE yes no (Head: Retrieve meta data about a Resource, such as a hash of the data or when it was last updated. Options: Retrieve information about what the Consumer is allowed to do with the Resource.)
Service communications
● Services communicate by exchanging messages that include information about the originator of the message, as well as the data that is the input to or output from the request. ● Services return a response to service request messages. - An authentication service may send a message to a login service that includes the name input by the user. - The response may be a token associated with a valid user name or might be an error saying that there is no registered user. ● We will look at: - should service interaction be synchronous or asynchronous? - should services communicate directly or via message broker middleware? - what protocol should be used for messages exchanged between services?
Uniform Resource Identifier (URI)
● URIs identify things - These can be documents - Or they can be bits of data within a set ● HTTP URIs name and address resources on the web - A URI identifies ONE resource - But one source can have more than one name • http://cloudsandthunder.com/todaysForecast • http://cloudsandthunder.com/forecast/1-04-15
WEB API
● WEB Application Programmer Interface ● Specifies how applications communicate with each other over the Web
Decomposition guidelines(Hur man ska bryta ned och skala av)
●Balance fine-grain functionality and performance ●Follow the 'common closure principle' ●Associate services with business capabilities ●Only give them access to the data that they need
