Based on an understanding of architectural styles, you will review architectures for web applications, then explore the basics of Service-Oriented Architecture (SOA) in two approaches: Web Services (WS*) and Representational State Transfer (REST) architecture. In the Capstone Project you will connect a Java-based Android application with Elasticsearch, a web service with a REST application programmer interface (API). After completing this course, you will be able to: • Describe SOA (Service-Oriented Architecture) to structure web-based systems. • Explain WS* services (i.e., SOAP over HTTP, WSDL, UDDI, BPEL). • Apply REST architecture (i.e., JSON over HTTP, URI). • Identify REST design principles. • Create a system using REST interfaces. • Apply microservice architecture.
4.3.3 – Introduction to Microservices
Loading...
來自 University of Alberta 的課程
Service-Oriented Architecture
112 個評分
從本節課中
REST Architecture for SOA
RESTful web services are another style of web services based on lightweight HTTP methods. They have largely superseded WS*-style services because of their relative simplicity. In this module, you will learn about RESTful services and how to design them. You will also learn a bit about microservices, a software architecture for applications that is based on services.
與講師見面
Kenny WongAssociate Professor
Computing Science, Faculty of Science
[MUSIC]
Before we learn about what microservices are,
let's look back through time to see where the idea came from.
In the early days of software development, developers made large,
monolithic applications.
These applications usually were developed by a large team,
all working on the same code base, and were made of code,
written from the ground up, specifically for the application.
Large monolithic applications were hard to maintain and scale.
They took a long time to develop, and
as their complexity increased, they often suffered from performance issues.
As a response to this issues, service-oriented architecture,
SOA would introduced.
SOA provides principles to guide developers to break down the functionality
of their monolithic enterprises into smaller more manageable, modular services.
These services are loosely coupled and strictly encapsulates.
Each service is intended as a tool that the organization or
external organization can neutralize to perform some task.
SOA encourage the users remove services as well as local services,
they comprise the enterprise.
Microservices can be thought of as a variation of SOA applied on an application
scale rather than enterprise scale.
Additionally, some SOA principles have been refined to better support
application scale systems.
The microservice architectural style is the way of composing microservices to
produce complex applications.
A microservice is the process that is responsible for
performing a single independent task.
A microservice typically is built to perform a specific business capability.
For example in an application, one microservice can be responsible for
implementing a search feature.
Another microservice can implement a recommendation feature.
And yet another microservice can be responsible for
implementing a rating feature.
Microservices are developed and exist independently.
But ultimately,
they are composed together to provide the overall functionality of an application.
Often each microservice does not obey a full layered architectural style because
microservices are composed with other microservices and not always intended for
end users.
Presentation and application layers may not always be present, that being said,
usually each microservice controls and manages its own data.
As a result,
the overall application will not generally follow a layered architectural style.
Take for example,
an online library application compose of the following microservices.
Each microservice has a well define interface or
API that informs other microservices how it can be use and communicated with.
Most microservices communicate with each other over the web,
using communication standards and protocols such as HTTP or XML.
REST interfaces are use to keep communication between microservices
stateless.
It's desirable for
each request response to be independent of any other request response.
There's a growing trend in the software industry towards
the use of microservices in web applications.
Why are microservices so appealing?
A benefit of communication between microservices being independent of
the implementation of each microservice is that microservices can use languages,
frameworks and architectures that are best suited to the service.
In other words, this means that different microservices can use different languages,
frameworks and architectures,
independent of what other microservices within the same application are using.
The benefits of this are two-fold.
First, it allows developers to create a service using the most appropriate tools
for the job.
And second, it provides the opportunity for developers to try out new
technologies, without making an application-wide commitment.
They make applications easier to scale and maintain due to their loose coupling.
A particular microservice can easily be scaled by replication.
Introducing multiple copies of the same microservice allows several request
of the original microservice to be handled in parallel by the other instances of
the microservice.
For instance, a microservice responsible for processing orders could be replicated
to increase the throughout of processing large volumes of orders.
Each order, to be processed,
could be distributed evenly among instances to balance the work.
Introducing multiple copies of the same microservice also has the effect
of making the application more resilient to failure.
If one instance of the microservice fails,
the other instances can continue functioning.
Sticking with our previous example of a microservice responsible for
processing orders.
If this microservice has been replicated several times and
if all of a sudden one of the instances is no longer functional, the remaining
instances of the microservice can continue handling the orders.
The throughput of the system would decrease,
as there would be one less microservice instance processing.
But users of the system would not be aware of the failure.
Not all microservices within an application need to scale at
the same rate.
Due to their loose coupling, microservices can be scaled independently.
When the application needs to be updated, repaired, or replaced,
this can be achieved with one microservice at a time,
without effecting the rest of the application.
Each microservice is developed, deployed and
maintained by a small independent team.
Each team is responsible for
a small piece of functionality of the entire application.
So they don't necessarily need to be familiar with the whole application to be
able to do their jobs.
This allows for microservices to be developed quickly and in parallel.
Although many advantages come along with the microservice architectural style,
there are also some drawbacks to consider.
An application composed of microservices is the distributed system enabled through
asynchronous communication.
This means some centralized management of all microservices will be required
to coordinate all the microservices.
Databases will likely be distributed over multiple microservices, and
transactions may span multiple microservices.
Without some central management,
the overall application state could become inconsistent and result in errors.
Testing a distributed system is more complex, due to changing test conditions.
Difficult to reproduce bugs can be introduced from the complex interactions
between microservices.
Another thing to consider is how the application will cope when a microservice
fails and there's not another instance of the microservice to take its place.
The other microservices in the application must be robust enough to handle
the failure gracefully as they may rely directly on the failed microservice.
The microservice architectural style can be used to create entirely new
applications.
It's a style relevant for applications that can be broken down into a collection
of tasks or business capabilities.
Since most applications can have their functionality separated like this,
microservices have a wide reach of applicability.
The exception maybe older monolithic applications that rely on precompiled
binaries.
Replacing these could potentially be more challenging,
because the code base has become rigid and brittle in the sense that it is very easy
to introduce bugs when making seemingly small or simple changes.
Modernizing a code base like this may require much
of the application to be wrapped.
Another nice property of using microservices in your application is that
microservices can be local, remote, or some combination of both.
Microservices are ideal for promoting and facilitating code reuse.
By separating all tasks into compartmentalized microservices,
the functionality of these services can be easily composed and
recomposed to suit the needs of the application.
This makes microservices ideal for large applications.
Microservices help keep code understandable and manageable.
Another point to consider is the amount of communication that will be required
between microservices in an application.
The messaging between microservices, be that through HTTP, XML or
some other communication standard and
protocol have an overhead cost associated with their use.
Also, communication between microservices is stateless.
Depending on the application, however, it may be desirable to track the behavior
of a user interacting with your application.
For a web application, you can do so with web cookies.
But your application will now potentially have more data to transfer between
microservices.
Again, this will lead you to consider the overhead cost of communication.
Now that we have a better idea of what kind of applications benefit from
microservices, let's take a look at an example.
Consider a restaurant guide that allows users to find nearby restaurants, place
a reservation, and review a restaurant all using the same web application.
To provide these features,
we can break up this application into the following microservices.
A user interface microservice that allows the user to interact with the application.
A restaurant catalog microservice that provides all restaurants in the system.
A restaurant reservation microservice that places a reservation with the selected
restaurant.
And a restaurant review microservice to access and make restaurant reviews.
Assume all communication between microservices is HTTP and REST base.
When you visit the website for this application,
the user interface microservice, prompt you to enter your location.
When the address is entered the user interface microservice communicates with
the restaurant catalog microservice to determine nearby restaurants.
Then, this information is communicated back to the user interface microservice
and displayed to you.
When you click to view more details about a particular restaurant,
the user interface microservice communicates with the restaurant review
microservice to access the reviews of this restaurant, and then displays them to you.
It also gives you the option to write a review.
Also when you review more details about a restaurant,
you are given the option to place a reservation at a particular time.
When you click to place a reservation, the user interface microservice communicates
with the restaurant reservation microservice to inform the restaurant.
Then it displays a confirmation message provided by the reservation microservice.
If you choose to review the restaurant, the user interface microservice
communicates the review to the restaurant review microservice so
that it can be saved.
To stay relevant,
businesses need to adapt to the ever changing technological landscape.
The microservice architectural style allows developers to make applications
that can be easily updated and scaled.
In this lesson, we've explored some of the benefits and
disadvantages of using microservices, learned what makes an application
well-suited for the microservice architecture style and
explored how this style can be applied to an example application.
>> Congratulations, if you made it to the end of the video content in
the specialization, you should be proud of yourself for making it this far.
But you're not done yet.
You still have a few more assignments to complete the fourth module before you earn
that specialization certificate.
So go on and show us all this new knowledge that you've obtained.
It's been a pleasure having you join us, and
wish you the best of luck in your future endeavors.
So what are you waiting for?
Go on and earn the certificate.
