the app itself is not new, it's good old Nutracker (a macro nutrition log & diary) I wrote this app as a monolith before and now I split it into different microservices with my focus on the architectural components that becomes essential with moving to a distributed system.
In microservices you basically leave the easy-to-debug and easy-to-write monoliths behind you to embrace a new mindset of thinking, one that is more complex and challenging to code, test, debug and deploy. and the reason why you may want to do that is to achieve more flexibility and scalability gains that will become more costly when the application gets beyond the early development stages.
Software starts simple but over time we add more features, we change old ones and we adapt new technologies, and if we are successful we receive more traffic, because all of that and other reasons, we need to write code in a way that:
1- allows good definitive boundaries between our different domains, and allows each domain to grow in somewhat isolated autonomous manner.
2- allows ease of change and replacement, code is as alive as we are, it's an abstraction of our thoughts and behaviors and needs, you can't write code, leave it, and expect it to live forever, it should grow, and then it should die, to be replaced, it's a natural life cycle that we should embrace.
monoliths can be hard to be let go because we then have to rewrite the whole thing, which is impossible.. we can only rewrite small chunks at a time.
3- Reactive: reactivity according to the reactive manifesto means being:
responsive, elastic, message driven & resilient. our app, infrastructure, processes to write and ship code should revolve around those concepts. we should be able to respond quickly, scale up and down, react to and publish events that drive our app behavior and be resilient to failures in a way that the whole app doesn't collapse in case of the unexpected.
more resources about this in case you need a start:
- Building Microservices: Designing Fine-Grained Systems
https://www.amazon.ca/Building-Microservices-Designing-Fine-Grained-Systems/dp/1491950358/
- https://12factor.net/
- https://www.amazon.ca/Cloud-Native-Java-Designing-Resilient/dp/1449374646
The code
In this repository you can find the code, you should be able to pull and run with docker.https://github.com/blabadi/nutracker-microservices
here is the description and highlights of this architecture :
- Domain services: entries, food-catalog, identity
- Support services: config-server, eurka discovery, boot admin, OAuth2 auth-server
- frameworks: spring boot 2 stack, webflux (reactive).
- docker for containers, docker-compose for local dev env
- concerns and design goals:
- Isolated and autonomous
- Resilient, Fault tolerant
- Responsive
- Efficient
- Scalable/ Elastic/ Highly available
- Monitored & traceable
- Developer quality of life (strong tooling and fast workflow)
- patterns:
- service registry & discovery (Eurka)
- central runtime-changable configurations (spring config server)
- circuit breakers (resilience4j)
- client side load balancing (Ribbon)
- reactive async I/O flow (reactor)
- stateless token based authentication (OAuth2 + jwt)
- Api gateway as single point of entry (spring cloud gateway)
- Monitoring:
- health checking
- logs aggregation
- Technologies:
- Spring boot 2: spring data, webflux, test
- Netflix OSS: eurka, ribbon
- resilience4j, circuit breaker
- Monitoring: Elastic stack (filebeat, elastic search, kibana) , spring actuator & admin, Zipkin, slueth
- containerization: docker
- spring security 5, oauth2 + jwt tokens
- data stores: mongo db
- junit 5, mockito, embedded dbs
- kafka as message bus (currently used by zipkin & slueth for traces)
- maven, git, shell scripts
- java 11
There is a lot here and a lot to explain and talk about, however that will be the topic of other posts as part of this series.
No comments:
Post a Comment
Note: Only a member of this blog may post a comment.