Scribd
Upload
23 views3 pages

Microservices Architecture Guide

Uploaded by

mahakaal9724
Copyright
© All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
23 views3 pages

Microservices Architecture Guide

Uploaded by

mahakaal9724
Copyright
© All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd

Table of Contents

Who should read this book? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1


Who should not buy this book? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
How to get PDF version of the ebook? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
Already bought ebook in another format? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
Preface. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
The Outline . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
How to contact us. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
IDE and softwares required for microservices development . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
Part I - Core Concepts. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1. Core Concepts in Microservices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.1. Cohesion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.2. Coupling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.3. Immutability in Microservices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.4. Open/Close Principle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.5. DRY (Don’t Repeat Yourself) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.6. SOLID. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
1.7. Single Responsibility Principle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
1.8. 8 Fallacies of Distributed Computing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.9. Continuous Integration (CI) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
1.10. CAP Theorem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
1.11. 12 Factor App . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
1.12. Typical Git workflow for a real project . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2. Introduction to Microservices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.1. Characteristics of a microservices architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.2. Benefits of using Microservices Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.3. Challenges in Microservices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.4. Difference between Microservices and SOA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.5. References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
Part II - Microservices Recipes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
3. Microservices Interview Questions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
3.1. How will you define Microservices Architecture?. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
3.2. What is Domain Driven Design?. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
3.3. What is Bounded Context?. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
3.4. What is polyglot persistence? Can this idea be used in monolithic applications as well? . . 24
3.5. Why Microservices are better than Monoliths? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.6. Isn’t in process communication in monolithic application faster than tons of remote 27
network calls in microservices architecture?
3.7. How microservices are different than SOA? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
3.8. What is difference between small-services and microservices? . . . . . . . . . . . . . . . . . . . . . . . . 28
3.9. What are benefits of using microservices architecture? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
3.10. How to partition a large application into microservices architecture, correctly?. . . . . . . . 29
3.11. How big a single microservice should be?. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
3.12. How do microservices communicate with each other? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
3.13. What shall be preferred communication style in microservices: synchronous or 32
asynchronous?
3.14. What is difference between Orchestration and Choreography in microservices context? 33
3.15. How to maintain ACID in microservice architecture? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
3.16. How frequent a microservice be released into production?. . . . . . . . . . . . . . . . . . . . . . . . . . . 35
3.17. How to achieve zero-downtime during the deployments? . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
3.18. How to achieve zero downtime deployment(blue/green) when there is a database change?
38
3.19. How to slowly move users from older version of application to newer version? . . . . . . . . 39
3.20. How will you monitor fleet of microservices in production? . . . . . . . . . . . . . . . . . . . . . . . . . . 39
3.21. How will you troubleshoot a failed API request that is spread across multiple services?. 39
3.22. What are different layers of a single microservice? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
3.23. How will you develop microservices using Java? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
3.24. Is it a good practice to deploy multiple microservices in a single tomcat container (servlet
42
container)?
3.25. What are Cloud Native applications? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
3.26. What is Spring Boot? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
3.27. What is Spring Cloud?. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
3.28. What is difference between [Link] and [Link]? . . . . . . . . . . . . . . . . . . . . . . 47
3.29. How will you implement service discovery in microservices architecture? . . . . . . . . . . . . 49
3.30. How does Eureka Server work? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
3.31. How to externalize configuration in a distributed system? . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
3.32. How will you use config-server for your development, stage and production 54
environment?
3.33. What is difference between config first bootstrap and discovery first bootstrap in context
55
of Spring Cloud Config client?
3.34. How to halt a Spring Boot based microservice at startup if it can not connect to Config 57
Server during bootstrap?
3.35. How to refresh configuration changes on the fly in Spring Cloud environment? . . . . . . . . 58
3.36. How to achieve client side load balancing in Spring Microservices using Spring Cloud? . 59
3.37. How to use client side load-balancer Ribbon in your microservices architecture? . . . . . . 60
3.38. How to use both LoadBalanced as well as normal RestTemplate object in the single 60
microservice?
3.39. How will you make use of Eureka for service discovery in Ribbon Load Balancer? . . . . . 61
3.40. Can we use Ribbon without eureka?. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
3.41. How will you use ribbon load balancer programmatically?. . . . . . . . . . . . . . . . . . . . . . . . . . . 63
3.42. What is difference between @EnableEurekaClient and @EnableDiscoveryClient? . . . . . . 63
3.43. How to make microservices zone aware so as to prefer same zone services for inter- 64
service communication using Spring Cloud?
3.44. How to list all instances of a single microservice in Spring Cloud environment? . . . . . . . . 65
3.45. What is API Gateway? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
3.46. How to protect internal endpoints leaking from API Gateway? . . . . . . . . . . . . . . . . . . . . . . . 67
3.47. How to protect Sensitive Security Tokens from leaking into downstream system? . . . . . . 67
3.48. How to retry failed requests at some other available instance using Client Side Load 68
Balancer?
3.49. What is Circuit Breaker Pattern? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
3.50. What are Open, Closed and Half-Open states of Circuit Breaker? . . . . . . . . . . . . . . . . . . . . . . 69
3.51. What are use-cases for Circuit Breaker Pattern? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
3.52. What are benefits of using Circuit Breaker Pattern? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
3.53. Can circuit breaker be used in asynchronous communication? . . . . . . . . . . . . . . . . . . . . . . . 70
3.54. What is Hystrix?. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
3.55. What are main features of Hystrix library? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
3.56. How to use Hystrix for fallback execution? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
3.57. When not to use Hystrix fallback on a particular microservice? . . . . . . . . . . . . . . . . . . . . . . 72
3.58. How will you ignore certain exceptions in Hystrix fallback execution? . . . . . . . . . . . . . . . . 73
3.59. What is Strangulation Pattern in microservices architecture? . . . . . . . . . . . . . . . . . . . . . . . . 74
3.60. What is Circuit Breaker? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
3.61. What is difference between using a Circuit Breaker and a naive approach where we 75
try/catch a remote method call and protect for failures?
3.62. What is Request Collapsing feature in Hystrix? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
3.63. What is difference between Circuit Breaker and Hystrix? . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
3.64. Where exactly should i use Circuit Breaker Pattern? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
3.65. What is bulkhead design pattern? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
3.66. How does Hystrix implements Bulkhead Design Pattern? . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
3.67. What is Hystrix approach to Bulkhead Pattern? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
3.68. In microservices architecture, what are smart endpoints and dumb pipes? . . . . . . . . . . . . 79
3.69. What is difference between Semaphore and ThreadPool based configuration in Hystrix?79
3.70. How to handle versioning of microservices? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
3.71. What is difference between partitioning microservices based on technical capabilities vs80
business capabilities? Which one is better?
3.72. Running Spring boot app at different port on server startup. . . . . . . . . . . . . . . . . . . . . . . . . . 81
3.73. How will you run certain business logic at the app startup? . . . . . . . . . . . . . . . . . . . . . . . . . . 82
3.74. How to correctly implement a reporting microservice in a distributed system? . . . . . . . . 84
3.75. What is Event Sourcing and CQRS? When should it be used? Should be use it for the entire
86
system?
3.76. How to send business errors from a RESTful microservice to client application? . . . . . . . 86
3.77. Is it a good idea to share common database across multiple microservices?. . . . . . . . . . . . 87
3.78. How will you make sure that the email is only sent if the database transaction does not 89

Common questions

Powered by AI

Microservices architecture focuses on building small, independent services that perform a single function and communicate over lightweight protocols. This approach excels in scenarios requiring flexibility and rapid deployment. SOA (Service-Oriented Architecture), meanwhile, is more focused on achieving integration between different existing systems through a service layer, which is beneficial in enterprises that need to leverage various complex systems together. SOA generally involves more extensive use of messaging and reliance on service buses, whereas microservices rely on direct service-to-service communication .

Cohesion in microservices refers to the degree to which the tasks performed by a single service are related and focused. High cohesion means that the services are well-designed and their functionalities are closely related, which enhances maintainability and scalability. Coupling, on the other hand, refers to the dependency among different services, with low coupling being desirable. It ensures that changes in one service do not necessitate changes in others, thus increasing the flexibility and robustness of the system .

Continuous integration (CI) is vital in microservices development as it allows for frequent integration of code into a shared repository. This practice ensures that each integration is verified by an automated build to detect issues early, thereby facilitating rapid development cycles and reducing integration problems. CI is essential in microservices to manage the complex dependencies and varied release cadences of independent services, ensuring that they work cohesively .

Immutability in microservices helps in maintaining the system's reliability and performance by ensuring that data and configurations are not altered unintentionally. It allows services to run independently and reproduce computations, which can reduce errors and make debugging easier. With immutable configurations, developers can ensure consistency across deployments and rollback configurations safely .

The Open/Close Principle (OCP) is crucial in microservices as it promotes the idea that software entities should be open for extension but closed for modification. This means services can adapt to changes and add new functionalities without altering existing code, which minimizes the risk of introducing defects. In microservices, this principle encourages developers to design systems in a modular way, facilitating easier updates and ensuring that changes are managed without impairing existing service functionalities .

The primary challenges in implementing microservices include managing data consistency across services, handling inter-service communication, ensuring high availability, and dealing with increased operational overhead. These can be addressed by adopting strategies such as eventual consistency models, implementing robust service discovery and load balancing mechanisms, utilizing container orchestration platforms, and employing observability tools to monitor service health and performance .

The DRY (Don't Repeat Yourself) principle focuses on removing duplicate code by abstracting common functionalities, enhancing maintainability, and reducing bugs through consistency. The Single Responsibility Principle (SRP), part of SOLID principles, advocates that a module or service should have one, and only one, reason to change, promoting focused and easier-to-understand code. In microservices contexts, DRY can be challenging to enforce due to distributed systems, and SRP helps maintain service boundaries but can lead to microservices that are too granular and interdependent if over-applied .

Client-side load balancers like Ribbon improve microservices' efficiency by distributing traffic intelligently among multiple instances of a service. This reduces the risk of overloading any single instance, enhances resource utilization, and improves response times. They provide capabilities like retrying failed requests to alternate instances, thus making the microservices architecture more resilient to failures and enhancing the overall user experience .

The Circuit Breaker Pattern enhances service resilience by preventing continuous failure calls to a service that is likely down, thus reducing the system’s load. When repeated failures are detected, the circuit 'opens', preventing further requests from being made. This allows affected services time to recover and prevent cascading failures across the system. Its effectiveness lies in the ability to manage faults gracefully, but it requires careful configuration to avoid excessive false positives that could deny service .

Deploying multiple microservices in a single Tomcat container can reduce resource usage and simplify management in smaller-scale applications. However, it disrupts independent scaling of services, which negates a key benefit of microservices. It also increases the risk of service conflicts and reduces fault isolation, meaning a failure in one service could potentially affect others hosted in the same container .

You might also like