Mastering microservices java domain driven microservice based 16 pdf

Mastering Microservices with Java Second Edition Build domain-driven microservice-based applications with Spring, Spring Cloud, and Angular Sourabh Sharma BIRMINGHAM - MUMBAI Mastering Microservices with Java Second Edition 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: June 2016 Second edition: December 2017 Production reference: 1051217 Published by Packt Publishing Ltd Livery Place 35 Livery Street Birmingham B3 2PB, UK ISBN 978-1-78728-144-8 www.packtpub.com Credits Author Copy Editor Reviewer Guido Grazioli Project Coordinator Vaidehi Sawant Commissioning Editor Aaron Lazar Proofreader Safis Editing Acquisition Editor Denim Pinto Indexer Aishwarya Gangawane Content Development Editor Zeeyan Pinheiro Production Coordinator Melwyn D'sa Sourabh Sharma Technical Editor Romy Dias Safis Editing About the Author Sourabh Sharma has over 15 years of experience in product/application development His expertise lies in designing, developing, deploying, and testing N-tier web applications and leading teams He loves to troubleshoot complex problems and look for the best solutions Throughout his career, he has successfully delivered various on-premise and cloud applications/products to some of the fortune 500 companies that has amazed stakeholders, including happy satisfied customers Sourabh believes in the continuous process of learning and has been continuously updating his skill set—from standalone application development to microservices development, from JDK 1.2 to Java 9, from IE dependent frontend code to cross-browser development, and from on-premise deployment to cloud deployment He has effectively managed delivering single products to bouquets of applications About the Reviewer Guido Grazioli has worked as an application developer, software architect, and systems integrator for a wide variety of business applications across several domains He is a hybrid software engineer with deep knowledge of the Java platform and tooling as well as Linux systems He is particularly interested in SOAs, EIPs, continuous integration and delivery, and service orchestration in the cloud 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.com and as a print book customer, you are entitled to a discount on the eBook copy Get in touch with us at service@packtpub.com 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/​1787281442 If you'd like to join our team of regular reviewers, you can e-mail us at customerreviews@packtpub.com 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 Chapter 1: A Solution Approach Evolution of microservices Monolithic architecture overview Limitation of monolithic architecture versus its solution with microservices Traditional monolithic design Monolithic design with services Services design One dimension scalability Release rollback in case of failure Problems in adopting new technologies Alignment with Agile practices Ease of development – could be done better Microservices build pipeline Deployment using a container such as Docker Containers Docker Docker's architecture Deployment Summary Chapter 2: Setting Up the Development Environment NetBeans IDE installation and setup Spring Boot configuration Spring Boot overview Adding Spring Boot to our main project Sample REST program Writing the REST controller class The @RestController annotation The @RequestMapping annotation The @RequestParam annotation The @PathVariable annotation Making a sample REST application executable Adding a Jetty-embedded server Setting up the application build 8 10 10 12 12 13 14 15 16 17 18 19 19 21 21 22 23 31 31 32 37 40 40 41 41 42 45 46 47 Table of Contents Running the Maven tool Executing with the Java command REST API testing using the Postman Chrome extension Some more positive test scenarios Negative test scenarios Summary Chapter 3: Domain-Driven Design 47 48 49 52 52 54 56 Domain-driven design fundamentals Fundamentals of DDD Ubiquitous language Multilayered architecture Presentation layer Application layer Domain layer Infrastructure layer Artifacts of domain-driven design Entities Value objects FAQs Services Aggregates Repository Factory Modules Strategic design and principles Bounded context Continuous integration Context map Shared kernel Customer-supplier Conformist Anticorruption layer Separate ways Open Host Service Distillation Sample domain service Entity implementation Repository implementation Service implementation Summary Chapter 4: Implementing a Microservice OTRS overview 57 58 58 59 60 60 60 60 61 61 62 63 64 65 67 68 70 70 71 71 72 73 74 75 75 75 76 76 77 77 79 81 85 86 87 [ ii ] Migrating a Monolithic Application to Microservice-Based Application Chapter 11 On-premise only solution On-premise solutions are deployed on customer infrastructure On top of that, you might have many clients with different versions deployed on their infrastructure You don't have full control of these deployments You need to work with customers and a team effort is required for successful migration Also, before you approach a customer, you should have the full flesh migration solution ready Having different versions of your product makes this extra difficult I would recommend offering migration only of the latest version and while you developed migration, only security and break fixes should be allowed for customers Yes, you should not offer new functionality at all Both cloud and on-premise solution If your application has both cloud and on-premise offering, then migration of on-premise solution to microservices could be in synchronization with the cloud or vice versa This means that if you spent efforts on migrating one, you can replicate the same on the other Therefore, it includes challenges mentioned earlier for either cloud or on-premise migration with addition to replication on other environments Also, sometimes on-premise customers may have their own customization It also needs to be taken care of while migrating Here, your own cloud solution should be migrated first to microservices, which can be replicated on on-premises later Migrating a production/solution offering only on-premise deployment, but you want of start cloud deployments also; this is most challenging You are supposed to migrate your existing code as per my microservice design, while making sure it also supports existing onpremise deployments Sometimes, it could be a legacy technology stack, or even existing code might have been written using some own proprietary technology like protocols It could be that the existing design is not flexible enough to break into microservices This type of migration offers the most challenges An incremental migration of on-premise solution to microservices should be done, where you can first separate the UI applications and offer external APIs that interact with UI applications If APIs are already in place or your application is already divided into separate UI applications, believe me, it removes tons of baggage from migration Then, you can focus on migrating the server-side code, including the APIs developed for UI applications You might ask why we can't migrate all UI applications, APIs, and server code together Yes, you can But, doing an incremental migration would give you surety, confidence, and quick failures/learning After all, Agile development is all about incremental development [ 281 ] Migrating a Monolithic Application to Microservice-Based Application Chapter 11 If your existing code is not modular or contains lots of legacy code, then I would advise you to first refactor it and make it modular It would make your task easier Having said that, it should be done module by module Break and refactor whatever code you can before migrating it to pure microservices We'll discuss a few approaches that might help you to refactor a large complex monolithic application into microservices Approaches and keys to successful migration Software modernization has been done for many years A lot of work is done to perform successful software modernization You will find it useful to go through all of the best practices and principles for successful software modernization (migration) In this chapter, we will talk specifically about software modernization of the microservice architecture Incremental migration You should transform monolithic applications to microservices in an incremental manner You should not start the full-fledged migration of the whole code all together It entangles the risk-reward ratio and increases the probability of failure It also increases the probability of transition time and, hence, cost You may want to break your code into different modules and then start transforming each of the modules one by one It is quite likely that you may want to rewrite a few modules from scratch, which should be done if the existing code is tightly coupled and too complex to refactor But, writing the complete solution from scratch is a big no You should avoid it It increases the cost, time to migration, and the probability of failures [ 282 ] Migrating a Monolithic Application to Microservice-Based Application Chapter 11 Process automation and tools setup Agile methodologies work hand in hand with microservices You can use any Agile processes, such as Scrum and Kanban with modern development processes, such as testdriven development or peer programing, for incremental development Process automation is a must for microservice-based environments You should have automated CI/CD and test automation in place If containerization of deliverables is not yet done with the CI/CD pipeline, then you should it It enables successful integration of newly developed microservices with the existing system or other new microservices You would want to set up the service discovery, service gateway, configuration server, or any event-based system in parallel or prior to the start of your first microservice transformation Pilot project Another problem I have observed in microservice migration is starting development with different modules altogether Ideally, a small team should perform the pilot project to transform any of the existing modules to microservices Once it is successful, the same approach can be replicated to other modules If you start the migration of various modules simultaneously, then you may repeat the same mistake in all microservices It increases the risk of failures and the duration of transformation A team that performs successful migration offers the way to developed modules and its integration with existing monolithic applications successfully If you successfully developed and transformed each module into a microservice one by one, at some point in time, you would have a microservice-based application instead of a monolithic application Standalone user interface applications If you already have standalone user interface applications that consume APIs, then you are already steps away from a successful migration If this is not the case, it should be the first step to separate your user interface from the server code UI applications would consume the APIs If the existing application does not have the APIs that should be consumed by the UI applications, then you should write the wrapper APIs on top of the existing code [ 283 ] Migrating a Monolithic Application to Microservice-Based Application Chapter 11 Take a look at the following diagram that reflects the presentation layer before the migration of UI applications: Before UI Applications migration The following diagram reflects the presentation layer after the migration of UI applications: After UI applications Migration You can see that earlier, the UI was included inside the monolithic application along with business logic and DAO After migration, the UI application is separated from the monolithic application and consumes the APIs for communicating with the server code REST is standard for implementing the APIs that can be written on top of existing code [ 284 ] Migrating a Monolithic Application to Microservice-Based Application Chapter 11 Migrating modules to microservices Now, you have one server-side monolithic application and one or more UI applications It gives you another advantage of consuming the APIs while separating the modules from existing monolithic applications For example, after separation of UI applications, you might transform one of the modules to a microservice Once the UI applications are successfully tested, API calls related with this module can be routed to the newly transformed module instead of the existing monolithic API As shown in next diagram, when the API GET/customer/1 is called, the web Gateway can route the request to the Customer Microservice instead of the Monolithic application You can also perform the testing on production before making the new microservice-based API live by comparing the response from both monolithic and microservice modules Once we have consistently matching responses, we can be sure that the transformation is done successfully and API calls can be migrated to the refactored module API As shown in the following figure, a component is deployed that makes another call to a new customer microservice whenever a customer API is called Then, it compares the responses of both of the calls and stores the results These results can be analyzed and a fix should be delivered for any inconsistency When a response from a newly transformed microservice matches with the existing monolithic responses, you can stop routing the calls to existing monolithic applications and replace it with new microservice Following this approach allows you to migrate modules one by one to a microservice, and at one point in time, you can migrate all monolithic modules to microservices API routing, comparison, and migration [ 285 ] Migrating a Monolithic Application to Microservice-Based Application Chapter 11 How to accommodate a new functionality during migration A new functionality should be avoided in ideal scenarios during migration Only important fixes and security changes should be allowed However, if there is an urgency to implement a new functionality, then it should be developed either in a separate microservice or in a modular way to existing monolithic code that makes its separation from existing code easier For example, if you really need a new feature in the customer module that does not have any dependency on other modules, you can simply create a new customer microservice and use it for specific API calls, either by external world or through other modules It is up to you whether you use REST calls or events for inter-process communication Similarly, if you need a new functionality that has dependency on other modules (for example, a new customer functionality having a dependency on booking) and it is not exposed as an API to a UI or service API, then it can still be developed as a separate microservice, as shown in the following diagram The customer module calls a newly developed microservice and then it calls the booking module for request processing and provides the response back to the customer module Here, for inter-process communication, REST or events could be used Implementing a new module as a microservice that calls another module [ 286 ] Migrating a Monolithic Application to Microservice-Based Application Chapter 11 References Read the following books for more information on code refactoring and domain-driven design: Refactoring: Improving the Design of Existing Code by Martin Fowler Domain-Driven Design by Eric J Evans Summary Software modernization is the way to move forward and in the current environment since everything is moved to the cloud and the way resource power and capacity is increased, microservices based on design look more appropriate than anything else We discussed a combination of cloud and on-premise solutions and the challenges of transforming those into microservices We also discussed why an incremental development approach is preferred as far as monolithic application migration to microservices is concerned We talked about various approaches and practices that are required for successful migration to microservices [ 287 ] Index A Advance Messaging Queue Protocol (AMQP) 126 aggregate root 65 Amazon Machine Image (AMI) 253 Amazon Web Services (AWS) 253 Angular Seed project reference 242 Angular UI reference 242 AngularJS framework controllers 202 directives 203 filters 202 model-view-controller (MVC) 198 model-view-viewmodel (MVVM) 198 modules 199 overview 198 providers and services 200 scopes 201 UI-Router 203 Apache Avro reference 156 Apache Kafka reference 156 API Gateway 10 Application Binary Interface (ABI) 244 application build executing, with Java command 48 Maven tool, executing 47 setting up 47 approaches, to successful migration about 282 incremental migration 282 modules, migrating to microservices 285 new functionality, accommodating 286 Pilot project 283 process automation 283 standalone user interface applications 283 tools setup 283 Archaius 257 artifacts, DDD about 61 aggregates 65 entities 61 factory 68 modules 70 repository 67 services 64 value objects (VOs) 62 Atlas 255 authentication providing 162 authorization providing 162 Avro Specs reference 156 B best practices, microservice-based architecture about 245 continuous integration and deployment 247 monolithic 246 nanoservice 245 self-monitoring and logging 248 separate data store, for microservice 250 size 245 system/end-to-end test automation 248 transaction boundaries 251 C certificate authority (CA) 159 Chaos Monkey 255 circuit breaker design pattern 122 client profiles, OAuth 2.0 native application 170 user agent-based application 169 web application 168 client, OAuth 2.0 authentication 171 confidential client type 167 identifier 171 profiles 168 public client type 167 registration 167 cloud solution about 280 versus on-premise solution 280 common name (CN) 161 Conformity Monkey 256 containers about 18 used, for deployment 17 used, for microservice deployment 131 context map about 72 anticorruption layer 75 conformist pattern 75 customer-supplier pattern 74 distillation 76 open host service 76 separate ways pattern 75 shared kernel 73 correlation ID using 273 using, for service calls 273 create, read, update, delete (CRUD) operation 87 D Data Access Objects (DAO) dependencies about 275 analyzing, while system designing 276 cyclic dependencies 275 designs, monolithic architecture monolithic design with services 10 services design 10 traditional monolithic design Display Report button 64 Docker about 19 architecture 19 Docker container 20 Docker image 20 reference 19, 142 domain-driven design (DDD) about 22, 56 artifacts 61 concepts 58 model 57 multilayered architecture 59 software design 57 ubiquitous language 58 Unified Modeling Language (UML) 58 E Elasticsearch, Logstash, Kibana (ELK) stack and logging 261 executing, Docker Compose used 268 implementation tips 272 logs, pushing to 270 overview 263 setup 265 Elasticsearch about 263 installing 265 reference 277 Enterprise Archive (EAR) Enterprise Service Bus (ESB) entities 61, 88 Eureka 253 Eureka client about 105 Booking and User services 105 executing 106 Eureka service creating 104 Maven dependency 104 registration 103 spring configuration 104 startup class 104 [ 289 ] F I fallback method, Hystrix circuit breaker, enabling 123 configuring 123 defining 124 Maven dependencies 124 properties, adding in application.yml file 124 features, Edda configuration 257 dynamic querying 257 history/changes 257 Fenzo about 258 features 258 Fully Integrated Defense Operation (FIDO) 258, 259 Ice 258 identity, creating automated generated ID, using 62 composite key, using 62 primary key, using 62 user-defined identifiers 62 Integrated Development Environment (IDE) 22 integration testing 247 Interface Segregation Principle (ISP) 77 Internet Engineering Task Force (IETF) 162 G K J Janitor Monkey 256 Jenkins reference 260 grant types, OAuth 2.0 authorization code grant 174 client credentials grant 183 implicit grant 178 resource owner password credentials grant 181 Gulp reference 242 H Home page/restaurant list page about 204 app.js 210 index.html 206, 209 restaurants.html 219 restaurants.js 212, 216 Hyper Text Transfer Protocol over SSL (HTTPS) 159 Hyper Text Transfer Protocol Secure 159 Hystrix dashboard setting up 126 Hystrix about 254 reference 142 Kibana about 264 download link 267 installing 267 reference 268, 277 L limitations, of monolithic architecture versus its solution alignment, with agile practices 14 development ease, improving 15 microservices build pipeline 16 new technologies adoption, issues 13 one dimension scalability 12 release rollback 12 lines of code (LOC) 246 Loggly reference 260 Login page about 223 login.html template 224 login.js 224 Logstash about 264 installation link 266 installing 266 [ 290 ] reference 266, 277 M mandatory services, microservices circuit breakers 113 edge servers 112 Hystrix dashboard 113 load balancing 112 Netflix Eureka server 112 Mapped Diagnostic Context (MDC) 250 master data management (MDM) 251 microservice architecture circuit breakers 122 client-side load balancing 119, 122 Hystric's fallback method 123 Hystrix, monitoring 125 load balancing 115 overview, using Netflix OSS 113 server-side load balancing 115, 118 Turbine services, creating 128 microservice deployment, containers used Docker containers, managing 139 Docker images, building with Maven 132 Docker machine, with GB 132 Docker, executing with Maven 135 Docker, installation 132 image, pushing to registry 138 integration testing, with Docker 136 microservice-based design overview 243 microservices frameworks and tools about 252 Netflix Open Source Software (OSS) 252 microservices deployment, with Docker 21 developing 88 evolution implementing 88 mandatory services 112 Restaurant microservice 89 model 57 model-view-controller (MVC) Controller 198 Model 198 View 198 model-view-viewmodel (MVVM) Model 198 View 198 View model 198 modules about 199 Angular library and application module, loading 199 application DOM configuration 200 application module 199 features 199 monolithic application migrating, to microservice application 280 monolithic architecture overview versus solution, limitation multilayered architecture, DDD about 59 application layer 60 domain layer 60 infrastructure layer 60 presentation layer 60 N Nebula 252 NetBeans IDE download link 23 installation 23, 26, 30 Netflix Open Source Software (OSS) about 252 Archaius 257 Atlas 255 Edda 256 Eureka 253 Fenzo 258 Fully Integrated Defense Operation (FIDO) 258 Hystrix 254 Ice 258 Nebula 252 Ribbon 253 Scumblr 258 Simian Army 255 Spinnaker with Aminator 253 using, in microservice architecture 113 Vector 257 [ 291 ] Zuul 254 Netflix Ribbon reference 141 Netflix Zuul reference 141 npm (Node.js package manager) about 226 installation link 227 O OAuth 2.0 about 162 Authorization Framework, reference 196 client registration 167 grant types 174 protocol endpoints 171 roles 165 specifications 163 uses 163 OAuth implementation authorization code grant 189, 192 client credentials grant 195 implicit grant 193 resource owner password credential grant 193 Spring Security, using 184, 189 object-oriented programming (OOP) 63 on-premise solution about 281 versus cloud solution 280 online table reservation system (OTRS) about 86, 261 implementing 91 overview 87 Open Source Software (OSS) 252 OTRS application building 131 running 131 OTRS features developing 204 Home page/restaurant list page 204 login page 223 reservation confirmation 226 restaurant details, with reservation option 220 restaurant.html 221 restaurants, searching 220 OTRS implementation controller class 93 controller class, API versioning 93 entity classes 100 repository classes 98 service classes 96 OTRS, functionalities booking service 87 restaurant service 87 user service 87 P Performance Co-Pilot (PCP) 257 Pivotal 31 Plain Old Java Object (POJO) 39 Postman Chrome extension used, for REST API testing 49, 51 protocol endpoints, OAuth 2.0 authorization endpoint 172 redirection endpoint 173 token endpoint 172 R RabbitMQ reference 141 Reactive Manifesto reference 144 reactive microservice architecture elastic principle 145 event-based/message-driven microservices 144 message driven principle 145 overview 143 resilient principle 145 responsive principle 145 REST-based microservices 144 reactive microservice implementation about 146 event, consuming 153, 156 event, producing 146, 149, 152 recipe types, AngularJS constant 201 factory 201 provider 201 service 201 value 201 [ 292 ] Remote Procedure Call (RPC) repository objects 88 Representational State Transfer (REST) 40 REST API testing negative test scenarios 53 positive test scenarios 52 Postman Chrome extension, using 49, 51 REST application executing 45 REST controller class @PathVariable annotation, using 42 @RequestMapping annotation, using 41 @RequestParam annotation, using 41 @RestController annotation, using 40 creating 40 REST program about 37 Jetty-embedded server, adding 46 REST application , executing 45 REST controller class, writing 40 Ribbon 253 roles, OAuth 2.0 authorization server 166 client 166 resource owner 166 resource server 166 S sample domain service creating 77 entity implementation 78 repository implementation 79 service implementation 81, 84 Scumblr 259 Search Providers 259 Secure Socket Layer (SSL) enabling 158 Security Monkey 256 service objects 64, 88 Service-Oriented Architecture (SOA) 7, 245 Simian Army 255 Simple Object Access Protocol (SOAP) single-page applications (SPAs) 203 Sleuth used, for tracking 273 software design 57 Spinnaker 253 SPR-9888 reference 31 Spring Boot adding, to main project 32, 36 configuration 31 overview 31 Spring Cloud Stream reference 157 Spring Initializr reference 31 Spring OAuth2 reference 196 Spring Security reference 196 used, for OAuth implementation 184 strategic design and principles about 70 bounded context 71 context map 72 continuous integration 71 Subject Alternative Names (SANs) 161 T Teamcity reference 260 test-driven development (TDD) 248 testing enabling 106, 108 Transport Layer Security (TLS) 158, 162 Turbine reference 142 Twitter URL 159 U User Interface (UI) 10 V value objects (VOs) 88 Vector 257 versions about 275 exploring 277 [ 293 ] maintaining 276 Virtual Machines (VMs) 17 W web application setting up 226, 230, 233, 236, 241 Web Archive (WAR) Z Zipkin used, for tracking 273 Zuul 254 go to it-eb.com for more ... Resource owner password credential grant Client credentials grant [ iv ] 158 162 162 163 163 165 166 166 166 166 167 167 167 171 171 171 172 172 173 174 174 178 181 183 184 189 193 193 194 Table.. .Mastering Microservices with Java Second Edition Build domain- driven microservice- based applications with Spring, Spring Cloud, and Angular Sourabh Sharma BIRMINGHAM - MUMBAI Mastering Microservices. .. deploy microservices and develop them on Docker You will also learn to write the Java test client for microservices Chapter 6, Reactive Microservices, shows how to design and implement reactive microservices