41,99 €
Mehr erfahren.
- Herausgeber: Packt Publishing
- Kategorie: Wissenschaft und neue Technologien
- Sprache: Englisch
Learn how to implement the microservice architecture using Java
About This Book
- Leverage the power of microservices to build a flexible and efficient system in Java
- See Docker and Spring Boot in practice to form easily deployable microservices
- Hands-on approach throughout the book in order to familiarize and grasp the details
Who This Book Is For
This book is for Java developers who want to get started with microservices and implement it in their workplace. No knowledge of microservice is necessary.
What You Will Learn
- The role of a discovery service and externalized configuration in the overall architecture
- Use of message brokers for event driven microservices
- How to intermix data management strategies across components
- Implementing different types of tests in Spring Boot environment
- Applying CI to our microservices style architecture
- Walk through of monitoring and scaling the sample application
In Detail
A microservice architecture helps you build your application as a suite of different services. This approach has been widely adopted as it helps to easily scale up your application with reduced dependencies. This way if a part of your application is corrupted, it can be fixed easily thereby eliminating the possibility of completely shutting down your software. This book will teach you how to leverage Java to build scalable microservices. You will learn the fundamentals of this architecture and how to efficiently implement it practically.
We start off with a brief introduction to the microservice architecture and how it fares with the other architectures. The book dives deep into essential microservice components and how to set up seamless communication between two microservice end points. You will create an effective data model and learn different ways to test and deploy a microservices. You will also learn the best way to migrate your software from a monolith to a microservice architecture.
Finishing off with monitoring, scaling and troubleshooting, this book will set a solid foundation for you to start implementing microservices.
Style and approach
Starting with the fundamentals, this book explains all the essential concepts gradually with the help of numerous examples.
Sie lesen das E-Book in den Legimi-Apps auf:
Seitenzahl: 297
Veröffentlichungsjahr: 2017
Ähnliche
BIRMINGHAM - MUMBAI
< html PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN" "http://www.w3.org/TR/REC-html40/loose.dtd">
Practical Microservices
Copyright © 2017 Packt Publishing
All rights reserved. No part of this book may be reproduced, stored in a retrieval system, or transmitted in any form or by any means, without the prior written permission of the publisher, except in the case of brief quotations embedded in critical articles or reviews.
Every effort has been made in the preparation of this book to ensure the accuracy of the information presented. However, the information contained in this book is sold without warranty, either express or implied. Neither the author, nor Packt Publishing, and its dealers and distributors will be held liable for any damages caused or alleged to be caused directly or indirectly by this book.
Packt Publishing has endeavored to provide trademark information about all of the companies and products mentioned in this book by the appropriate use of capitals. However, Packt Publishing cannot guarantee the accuracy of this information.
First published: July 2017
Production reference: 1270717
ISBN 978-1-78588-508-2
www.packtpub.com
Credits
Author
Umesh Ram Sharma
Copy Editor
Karuna Narayan
Reviewer
Yogendra Sharma
Project Coordinator
Vaidehi Sawant
Acquisition Editor
Chaitanya Nair
Proofreader
Safis Editing
Content Development Editor
Zeeyan Pinheiro
Indexer
Francy Puthiry
Technical Editor.
Vivek Pala
Production Coordinator
Nilesh Mohite
About the Author
Umesh Ram Sharma is a developer with more than 8 years of experience in the architecture, design, and development of scalable and distributed cloud-based applications.
He was awarded a master's degree from Karnataka State Open University in Information Technology. With a core interest in microservices and Spring, he is an expert in the utilization of various offerings of the J2EE, Java Script, Struts, Hibernate, and Spring stack. He also has hands-on experience of technologies such as AWS, J2EE, MySql, MongoDB, memchached, Apache, Tomcat, and Hazelcast.
Currently working as a Principal Lead Engineer at ZestMoney, he helps his team migrate their running project to microservices.In his free time, he enjoys driving, cooking, and attending conferences on new technologies.
About the Reviewer
Yogendra Sharma is a Java developer with a Python background, with experience mainly in middleware development. He has completed a bachelor's degree of technology in computer science.
He is currently working in Pune at Intelizign Engineering Services Pvt. Ltd as an IoT Cloud Architect. He constantly explores technical novelties, and he is open-minded and eager to learn about new technologies and frameworks.
Yogendra has also technically reviewed Mastering Python Design Patterns, Test-Driven Development with Django, Spring 4.0 Microservices, and Distributed Computing with Java 9, and video courses Python Projects, Learning Python Data Analysis, Django Projects: E-Learning Portal, and Basic and Low-Level Python Network Attacks, all by Packt.
www.PacktPub.com
For support files and downloads related to your book, please visit www.PacktPub.com.
Did you know that Packt offers eBook versions of every book published, with PDF and ePub files available? You can upgrade to the eBook version at www.PacktPub.comand as a print book customer, you are entitled to a discount on the eBook copy. Get in touch with us at [email protected] for more details.
At www.PacktPub.com, you can also read a collection of free technical articles, sign up for a range of free newsletters and receive exclusive discounts and offers on Packt books and eBooks.
https://www.packtpub.com/mapt
Get the most in-demand software skills with Mapt. Mapt gives you full access to all Packt books and video courses, as well as industry-leading tools to help you plan your personal development and advance your career.
Why subscribe?
Fully searchable across every book published by Packt
Copy and paste, print, and bookmark content
On demand and accessible via a web browser
Customer Feedback
Thanks for purchasing this Packt book. At Packt, quality is at the heart of our editorial process. To help us improve, please leave us an honest review on this book's Amazon page at https://www.amazon.com/dp/1785885081.
If you'd like to join our team of regular reviewers, you can e-mail us at [email protected]. We award our regular reviewers with free eBooks and videos in exchange for their valuable feedback. Help us be relentless in improving our products!
Table of Contents
Preface
What this book covers
What you need for this book
Who this book is for
Conventions
Reader feedback
Customer support
Downloading the example code
Errata
Piracy
Questions
Introduction to Microservices Architecture
General microservices architecture
Characteristics of microservice architecture
Problem definition
Solution
How much proposed solution is aligned with microservice architecture?
Challenges for a successful microservice architecture
Debugging through logging
Monitoring microservices
Common libraries
Messaging between services
Deployment and versioning of microservices
Future of microservices
Serverless architecture
Microservices as PaaS
Dominance of microservice architecture over traditional architecture
Huh? Doesn't it seem like SOA?
Assorting large business domains into microservice components
Organizing microservice components around business capabilities
To go or not to go for microservices
Organization buy-in
Experience DevOps
Analyze existing database model
Automation and CI/CD
Integration
Security
Example of successful migration
Sample project (credit risk engine)
Spring
Spring Boot
Things are easy with Spring Boot!
Summary
Defining Microservice Components
Definition of a microservice
Service Discovery and its role
DNS
Discovery service need
Registry/deregistry of services
Discovering other services
Example of service discovery pattern
Externalized configuration in the overall architecture
API Gateway and its need
Authentication
Different protocol
Load-balancing
Request dispatching (including service discovery)
Response transformation
Circuit breaker
Pros and cons of API Gateway
Example of API Gateway
Sample application used throughout the book
Development of user registration microservice
Configuration server
Table structure
Summary
Communication between Microservices Endpoints
How should microservices communicate with each other?
Orchestration versus choreography
Orchestration
Choreography
Synchronous versus asynchronous communication
Synchronous communication
Asynchronous communication
Message-based/event-based asynchronous communication
Implementing asynchronous communication with REST
Implementing asynchronous communication with message broker
Financial services
Summary
Securing Microservice Endpoints
Security challenges in microservices
Mix technology stack or legacy code presence
Authentication and authorization (access control)
Token-based security
Responsibility of security
Fear with orchestration style
Communication among services
Using JWT along with OpenID and OAuth 2.0
OpenID
OAuth 2.0
JWT
A few examples
Header
Sample application
Summary
Creating an Effective Data Model
Data and modeling
Comparison with a traditional data model
Data model in monolithic architecture
Data model in SOA
Data model in microservice architecture
Restricted tables for each microservice
Database per microservice
The Saga pattern
Intermixing data technologies when needed
Migrating a data model from monolithic to microservices
Domain-Driven Design
Methods of data model migration
Views
Clone table using trigger
Event sourcing
Sample application data model
Summary
Testing Microservices
The purpose of testing in the microservices world
Unit testing
Integration testing
Component (service) testing
Contract testing
Pact
Spring Cloud Contract
End-to-end testing
One step further
Summary
Deploying Microservices
Continuous integration
Continuous delivery
Configuring tools for CI and CD with our microservices
Dockerizing our microservice
Docker
Docker engine
Docker images
Docker storage
How things work in Docker
Public, private, and official image repositories
Docker versus VMs
Installing Docker in Linux
Using open source CI tools with our Dockerized microservices
Summary
Evolving the Existing System
Where to start
Architectural perspective and best practice
Database perspective and best practice
Sample application and its evolution
User management service
Cart/order service
Payment service
Shipping/tracking and communication service
Recommendation service
Scheduler service
Summary
Monitoring and Scaling
Principles in monitoring a microservice system
How and who will see the alerts
Monitoring and channeling from the start
Autoscale and autodiscovery
Monitor front door
Changing face of monitoring
Logging helps in monitoring
Principles in scaling a microservices system
X axis
Y axis
Z axis
Thoughts before scaling
Practical options for both monitoring and scaling microservices
Summary
Troubleshooting
Common issues with microservices
Slow performance
Different logging locations from different programming languages
Coupling or dependency issues in multiple components
Per-day deployment for more number of services
Monitor many services for performance degradation or issues
Relation between logs and different components
Techniques to solve the common issue
Steps to help with performance issues
Handle logging in different locations and from different languages
Dependencies between services
High DevOps involvement
Use smart tools
Use smart developers
Monitoring
Summary
Preface
Microservices is becoming a buzzword in the technology world. It is getting lots of attention among technology enthusiasts, developers, and articles. This book is intended to be a practical guide for developers to write, test, secure, and deploy microservices. It has many benefits and also unique challenges; I intend to shed light on the best practices in an easy-to-read manner, and also to avoid the pitfalls associated with the complexity that can arise due to this architecture.
What this book covers
Chapter 1, Introduction to Microservices Architecture, introduces the overall concepts of a microservices architecture, including a basic definition of what is meant by microservices in this book. The chapter will then quickly move to a high-level walk-through of a comprehensive sample application that will be used throughout the rest of this book.
Chapter 2, Defining Microservice Components, explains the guiding principles to define microservice components, along with teaching how these components form the backbone of the microservices architecture. These guidelines are then made practical by showing how a Spring Boot-based Java project structure can be used to effectively define microservice components. Finally, a sample microservice is used to demonstrate a practical example of Java-based microservice components, along with configuration and a discovery service.
Chapter 3, Communication between Microservice Endpoints, talks about the principles for effective communication between microservices, along with the appropriate reasoning. Options are then introduced for synchronous and asynchronous communication using various technologies ranging from Spring Framework's own capabilities to message brokers. We will also cover how common problems are handled by best practices.
Chapter 4, Securing Microservice Endpoints, discusses common security and security challenges. JWT, OpenID, and OAuth2.0 are introduced for better security in a microservices architecture.
Chapter 5, Creating an Effective Data Model, starts with explaining the difference between creating a microservices-based data model versus a traditional data model and why microservices does it differently. It also explains how data technologies can be intermixed, and how to select the appropriate data management strategy for each microservice component. We will also walk through the sample application data model and explain the various data model decisions and why they were made.
Chapter 6, Testing Microservices, talks about how testing is even more important in a system that is intended to be changed constantly and deployed automatically. However, are our traditional testing approaches and test quality criteria a perfect match for a microservice-style architecture, or do we need to focus on entirely different approaches? Probably a mix of both.
Chapter 7, Deploying Microservices
What you need for this book
To run examples given in this book, it is recommended that you have a Linux-flavored operating system. You can use Windows or Mac-based systems as well, but the steps described here to install any particular software are explained, keeping the Linux-based system in mind. Other than that, you need to have Maven, Java 8, and any Java-based IDE. It can be Eclipse, IntelliJ, or STS. For the database side, the MySQL community version is recommended.
Who this book is for
This book is for Java developers who want to get started with microservices and implement it in their work place. No knowledge of microservices is necessary.
Conventions
Reader feedback
Feedback from our readers is always welcome. Let us know what you think about this book-what you liked or disliked. Reader feedback is important for us as it helps us develop titles that you will really get the most out of.
To send us general feedback, simply e-mail [email protected], and mention the book's title in the subject of your message.
If there is a topic that you have expertise in and you are interested in either writing or contributing to a book, see our author guide at www.packtpub.com/authors.
Customer support
Now that you are the proud owner of a Packt book, we have a number of things to help you to get the most from your purchase.
Downloading the example code
You can download the example code files for this book from your account at http://www.packtpub.com. If you purchased this book elsewhere, you can visit http://www.packtpub.com/support and register to have the files e-mailed directly to you.
You can download the code files by following these steps:
Log in or register to our website using your e-mail address and password.
Hover the mouse pointer on the
SUPPORT
tab at the top.
Click on
Code Downloads & Errata
.
Enter the name of the book in the
Search
box.
Select the book for which you're looking to download the code files.
Choose from the drop-down menu where you purchased this book from.
Click on
Code Download
.
Once the file is downloaded, please make sure that you unzip or extract the folder using the latest version of:
WinRAR / 7-Zip for Windows
Zipeg / iZip / UnRarX for Mac
7-Zip / PeaZip for Linux
The code bundle for the book is also hosted on GitHub at https://github.com/PacktPublishing/Practical-Microservices. We also have other code bundles from our rich catalog of books and videos available at https://github.com/PacktPublishing/. Check them out!
Errata
Although we have taken every care to ensure the accuracy of our content, mistakes do happen. If you find a mistake in one of our books-maybe a mistake in the text or the code-we would be grateful if you could report this to us. By doing so, you can save other readers from frustration and help us improve subsequent versions of this book. If you find any errata, please report them by visiting http://www.packtpub.com/submit-errata, selecting your book, clicking on the Errata Submission Form link, and entering the details of your errata. Once your errata are verified, your submission will be accepted and the errata will be uploaded to our website or added to any list of existing errata under the Errata section of that title.
To view the previously submitted errata, go to https://www.packtpub.com/books/content/support and enter the name of the book in the search field. The required information will appear under the Errata section.
Piracy
Piracy of copyrighted material on the Internet is an ongoing problem across all media. At Packt, we take the protection of our copyright and licenses very seriously. If you come across any illegal copies of our works in any form on the Internet, please provide us with the location address or website name immediately so that we can pursue a remedy.
Please contact us at [email protected] with a link to the suspected pirated material.
We appreciate your help in protecting our authors and our ability to bring you valuable content.
Questions
If you have a problem with any aspect of this book, you can contact us at [email protected], and we will do our best to address the problem.
Introduction to Microservices Architecture
Software architecture can be defined as a set of rules or principles designed for a system that defines the elements, behavior, structure, and relationship between different components of a software system.
In the early 80s, when large-scale software systems started coming into existence, a need emerged to have generic patterns (or architecture) that would solve common problems faced while designing all those systems. The term ,"software architecture" started evolving from there. Since then, many types of architectures have been introduced to design large-scale software systems. The software industry has seen architecture styles from shared nothing to monolithic to client-server to n-tire to service-oriented architecture (SOA) and many more. One more addition to this list is microservice architecture.
Microservice is a word that has taken an exponential path of popularity in recent times among the software developer/architecture community. Organizations working on monolithic application architecture often complain about long release cycles, tedious debugging issues, high-maintenance road maps, scaling issues, and so on. The list is never ending. Even the exceptionally well-managed monolithic applications would need a tremendous amount of effort to handle these issues. Microservice is evolving rapidly as it offers an efficient way to cope with these kinds of issues. In simple words, we can explain it as breaking a large problem into relatively smaller services, and each service will play its own part.
The basic philosophy of the microservices architecture is, "Do one thing and do it exceptionally well".
The heart of microservices architecture is the Single Responsibility Principle (SRP). In microservices architecture, business tasks are broken into smaller tasks, and to accomplish each task, there is a microservice. In a system, there could be two microservices or 100 microservices, depending on business requirements and how well the task has been broken down. This type of architecture gives an organization many benefits, which were not possible in monolithic applications, and also, it has its own kind of overhead as well. We will discuss the benefits and tradeoffs of this kind of architecture in the upcoming sections.
General microservices architecture
Microservice architecture is basically inspired by SOA. There is no golden rule for the architecture in microservice. If we go by different architectures implemented in the industry, we can see everybody has their own flavor of microservice architecture. There is no perfect or certain definition of microservice. Rather microservices architecture can be summarized by certain characteristics or principles.
Characteristics of microservice architecture
Any architecture demonstrating the following six principles or characteristics could be placed in the microservice architecture zone:
The system should consist of two or more running units or components. These components should expose their functionality as services. Each component should serve a business purpose, and the components should be loosely coupled. Components should communicate with each other through predefined protocols, such as messaging queues, HTTP request/response models, and so on.
Systems should be language agnostic. One component can be developed in Java, and another can be developed in .NET. The decision of choosing a technology platform for a particular service should not affect the application architecture.
Systems should have a decentralized database. Ideally, each component or microservice should have its own database, with whom only that service is interacting. No other component or service can fetch or modify the data in that database.
Each component in the system should be cohesive, independent, and self-deployable. It should not be dependent on any other component or resource to work or to deploy. It should have
Continuous Integration/Continuous Deployment
(
CI/CD
) in place to ship faster.
The system should have automated testing in place. Speed is the one of the most desirable features of microservice architecture. In the cycle of build, test, and ship, if automated testing is not in place, then it cannot meet the goal.
Any component/service's failure should be in isolation. Failure of one service should not make the whole application go down. If it fails, it should not affect other components/services. Some kind of failure roll back mechanism should be in place. That means if one service fails, it should be easy to roll it back to an older working version.
This simple and small example given below may give a better understanding and more insight into these principles.
Problem definition
An application is required, that generates coupons for shopping online on the basis of privileges given to a registered user. If a user is from the platinum category, they will have a 20 percent discount coupon, gold users 15 percent, silver 10 percent, and guests 5 percent.
Solution
In this architecture, there is scope for two microservices. The first is for authentication that gets users logged in based on the credentials provided and sends the privilege level back to the consumer as a response. The second is based on privilege level. The service should return the percentage of discount that may be applied on the cart (another service) built by the consumer.
In the following diagram, there are two components having two different Databases. Assuming both components have exposed their services as REST interfaces, consumers can hit Authentication Service MS1 with credentials and get the user object, including privilege level, and then, it can hit the second microservice with privilege level and get the discount coupon percentage:
How much proposed solution is aligned with microservice architecture?
Each service servers a business purpose (rule 1). Both services can be on different platforms; it will not affect the existence of the other service (rule 2). Both services have different databases with which only that particular service is communicating (rule 3). Services are independent of each other which means not sharing any database among themselves and self-deployable ( assuming CI/CD in place rule 4).
If we assume here Authentication Service MS1 dies in some rare circumstances because of a runtime exception or memory leakage issue, the consumer will get an HTTP response of 404. 404 (Not Found) is treated as user not found in the database, which will lead the consumer to treat this user as a guest, and it will still keep asking for a discount coupon for the guest. The system/website will be up and running. Failure of Authentication Service MS1 will not hamper any other running service. (rule 6 isolation failure.)
If the same problem occurred in a monolithic application (memory leak), it would require rebooting the whole application, including all components, and it would cause a downtime.
The success of microservice architecture is based on how efficiently one analyze the problem domain and broke down the application into smaller independent components. The better the assorting of problems, the better the architecture will evolve. The typical architecture of microservices is as shown in the following diagram:
Normally, each team is responsible for one microservice. The size of a team can vary from one member to many with the size and complexity of microservices. Each microservice has its own release plan. Deployment of one microservice doesn't affect the deployment of an other microservice. If, at a particular time, five microservices are in testing and quality analysis (QA) and only two pass the QA phase, then only those two can ship to production, and they should not be affected by or dependent on the release of the rest of the services.
Challenges for a successful microservice architecture
Microservice architecture is not a silver bullet to solve all the architecture problems in the existing world. It gives a solution to many of the problems raised, but it comes with its own challenges. Decomposing database, communication between APIs, heavy DevOps work, and a team with aligned mentality are some of the initial factors to cope with while moving towards microservices. Even with successful implementation of a microservice, here are the challenges that an organization will face.
Debugging through logging
Debugging in microservices architecture will be hard for a developer. A single request to an application can result in multiple internal hits of different microservices. Each microservice will generate its own log. To find the root cause of any wrong behavior in any particular request could be a nightmare for a developer. In a distributed logging environment, it's hard to debug any issue. Setting up proper tools/scripts to collect logs from different services in some centralized place also gives a challenge to the DevOps team.
Monitoring microservices
Monolithic applications are easy to monitor. In a monolithic application, there are fewer points to monitor as it is one service(big fat war). Points to monitor would include the database service, disk spaces, CPUs usage, any third-party tools and so on. Monitoring effort in microservices architecture increases exponentially. Each service requires the same number of points to monitor as normally found in one monolithic application. Imagine the alert rate when microservices numbers keep increasing in 100s. Monitoring and self-healing tools/script such as Nagios and Monit should be in place to handle and react to alerts coming from different services.
Common libraries
Using a shared library among different services may not be a good idea. There could be a case where one microservice A, generates user object JSON, and other microservice B, consumes user object JSON. The suggestion here is to define the user class in one JAR and add that JAR into both the microservices. This leads to two new issues. The first one is that sharing a common library will again lead microservices to stick with the same language. A secondly, this idea will increase the coupling between services, which is against the idea of microservices. Solution could be the User class should be written in both the microservices. This can result in the failure in the Don't Repeat Yourself (DRY) principle.
Messaging between services
In microservices architecture, serving a single request from outside (frontend or API consumer), can result in multiple internal communications between different microservices, which can result in a network latency. This can, in turn, degrade the overall application performance. It can be solved by choosing the right type of communication between APIs. It can be synchronous like RESTful web services or asynchronous like messaging. Depending on the application requirement, both types of communication can co-exist in one place. If a direct response is required, it should be synchronous like HTTP. If there is some intermediate result that should pass to the next service or services, the best way to do so is by publishing the events to topics or queues, such as Kafka or SNS.
Deployment and versioning of microservices
Microservices can be deployed in different ways. Microservices usually ship with containers such as packer, Dockers, or for Amazon Web Services (AWS), one can also use Amazon Machine Image (AMI) to ship the microservice. However, AMIs take longer to create and deploy than Dockers, and Docker is a better tool for deploying a microservice. Proper versioning rules should be in place; otherwise, the whole architecture will be in a versioning hell. Typically, xx.xx.xx is the versioning format. The right most is for smaller bugs or patches, while the middle section increases by adding any new feature in the component. The left most number increases when you have changed something big, like the communication interface model.
We will talk in detail about communication between services and deployment in the upcoming chapters.
Future of microservices
Along with their pros and cons, microservices are gaining popularity these days. With more and more people using this concept, there can be new problems, new patterns to implement microservices, and new demands from microservices on the table. Those demands and common problems will give the direction or lead the future of microservices.
