simple store intro - dbones-simple-shop/docs GitHub Wiki
Welcome to the simple store, this is a small project to demonstrate monitoring across a distributed architecture (for now)
- slides
- Docker images - please note the lastest known working versions of each container is specified in the deployments.yaml
The solution looks at using:
- Rancher / Graphana - Dashbaords
- Istio (Envoy) / Prometheus - to provide metrics
- Kiali - Topology, note Kiali can use data from Prometheus and Jaeger
- Jaeger - Tracing (via OpenTracing)
- Datadog - Logging (note this can be used for all)
an alternative for Metrics, Topology, Tracing and Dashboards look at Apache Skywalking.
an alternative service mesh consider https://linkerd.io, or https://mae.sh/
Repositories
- core - shared .net application/framework code (setup of logging, messagebus, database, monitoring etc)
- apigateway - implementation of the api gateway using Ocelot (its mainly configuration)
- basket - users store items in the basket, the basket can be created and checkedout. Uses redis as a quick temporary store.
- catalog - items which the shop offer, images are stored on disk and the metadata is in a prosgres database.
- ordering - contains all the orders, these are created from the basket being checked out and are set in the ready state once the stock as been reserved.
- warehouse - contains the stock information, i.e. quantity, when a basket is checked out this will reserve stock and when the order is completed, the stock will be removed.
- infra - setup of the cluster (k8s and terraform)
stateful services
at the moment all services are inside a container, consider using a PaaS instance instead.
- Redis - used for a fast data cache
- RabbitMq - the message bus between services
- PostgreSql - is being used as a document database (JsonB fields) this is fully supported by Marten.
Repo structure
service repos have:
- src - all the source files
- .circleci - Circle CI build scripts
- k8s - kubernetes deployment files - not using helm atm.
Design issues
as this is a demo for monitoring there are some design issues which have been skipped:
- REST model - the anemic domain model is stored in the db and exposed directly to over the web api - look at ports and adaptors to solve this.
- Domain model - it's anemic, this maybe ok for you, consider DDD or Transcript
- Eventing without transactions - all events are happening within a DB transaction, meaning that if the transaction fails the event has already been published - consider Event filters and the CAP (dotnet opensource project with regards to events), NServiceBus or AllAboard
- Dead letter queue - we have a retry policy, however look into how to handle messages which cannot be processed.
- API Versioning - this is a quick impl, all API (HTTP and AMQP) need to be versioned
- Security - there is none - consider OpenId Connect, and integrate with the api gateway
- HELM Charts - consider using them, and set the deployment to be rolling
- Secrets - currently stored in config files, consider Hashi Corp Vault
- Concurrency - consider version number on models (Optimistic).
- dotnet core ioc registrations - in .NET Core we can register services, the core project is a quick impl of this, consider neatening it up.
- Application Framework Packages - Core is 1 package, consider separating this into multiple, 1 for each concern, as at the moment your service will have a dependency on packages it does not use.
- Interfaces - the code uses direct dependencies, this debatable, even more so with micro-services (i can see the point both ways)
- Automated testing - any good automated testing framework should work, consider contract testing minimum, as it acts as documentation.
These are a few things we would normally need to consider for the production version.