Focusing on MicroServices
Subscriber and Publisher (Message Broker)
- Long-Running Work should not be done on a Socket, it should be done in a queue with Rabit MQ or Active MQ any other queuing technology.
- The queue application makes sure that the queue message is distributed to only one subscriber as needed at a time. You can have real load balancing and Auto Scaling.
- Brokers allow subscribing and publishing possible in Queuing Application
- Multiplexing with Exclusive Consume
- Multiplexing funnels sequence of related messages concurrently through one route
- Exclusive consumers snap to sequences and the queue guarantees consistent routing of the message to the same consumer.
- Often used with scenarios where huge numbers of contexts must be handled, e.g. in workflow processing.
- Stateful Processing
- Stateful processing is simplified by pulling a stream stepwise towards a state aggregator (like calculating a rolling average)
- Consumption can be easily suspended, the state moved, and consumption resumed elsewhere when needed.
- Sparse Connectivity
- Sparse connectivity is common with the wireless application, including IoT edge applications
- Mobile users switch networks, go out of range, hit bandwidth caps, etc.
- Mobile applications get frequently suspended.
- You can make communication paths more robust by making them strictly async and using a local store/forward queue setup.
Message Broker Protocols
- Protocols we prefer must be vender-neutral, have a formal definition independent of any implementation, and must be under neutral governance.
- We prefer formal standardization venues such that standards can be composed and be the basis of formal certification programs: W3C, OASIS, IETF, ISO, IEC.
- Multiple, competing implementations of the full protocol feature range must exist, not just clients.
- Protocols must be secure, integrate with federated authorization models, and be compatible with common enterprise network policy practices.
- Protocols must fit the target scenario and not require product-specific extensions for the scenario to work. Still, they must be extensible to allow for backward-compatible evolution in the context of standards collaboration.
Protocol We Prefer
- Protocols We Prefer
- IETF HTTPS & WebSocket Protocol
- Request-response application protocol
- Azure Services: Azure Event Hubs, Azure Service Bus, Azure Event Grid, Azure Relay, Azure IoT Hub.
- OASIS AMQP 1.0
- Vendor-independent and product-independent, symmetric, reliable message transfer protocol with support for multiplexing and flow control.
- Azure Services: Azure event Hubs, Azure Service Bus, Azure IoT Hub
- OSS: Apache ActiveMQ Classic, Apache ActiveMQ Artemis, Apache Qpid Broker-J, Apache Qpid C++, Apache Qpid Dispatch Router, Apache Camel, CNCF Strimzi Bridge, Eclipse Hono, Eclipse Ditto, Pivotal RabbitMQ.
- OASIS MQTT 3.x/5.x
- Vendor-independent and product-independent, a reliable publish-subscribe protocol for telemetry transfer and state synchronization.
- OSS: Apache ActiveMQ Classic, Apache ActiveMQ Artemis, Eclipse Hono, Pivotal RabbitMQ, Eclipse Mosquitto, HiveMQ, VerneMQ, etc.
- CNCF CloudEvents
- Vendor-independent and product-independent event data model with multiple bindings to protocols and encodings
- Azure Service: Azure Events Grid, Azure Service Bus and Event Hubs via AMQP
- If you want Entity Framework to know of the primary key on the table, then do
Designing an Agregate and Utilizing Mapping.
//This let Entity Framwork use that column as an Index, helps in retrieving the data and inserting the data.
//Another good practice is to encopsulate certain properties that you don't want other class to access.
//If you have a private field Property in your Model Class, you can late Entity Framework know about that field property by explicitly including it HasField("_nameOfField")
modelEntity.Entity<YourModelName>().Property(b => b.TeamName).HasField("_YourPrivateField"); This way even when your Field Property is private EFCore can still utilize it.?
Container Orchestrations Best Practices
- Tip: Ask yourself as you're making Microservices, does this add value or create unnecessary complexity?
Kubernetes Best Practices
- Build small containers
- Multistage builds
- Application architecture
- Use Namespaces
- Helm charts
- Implement health Checks
- Liveness / Readiness Probes
- Set requests and limits
- Be mindful of your services
- Map external services
- Don't rely on load balancers (Use proxies, load balances are expensive)
API Communication in Microservices
Monoliths with .NET 5 and Kubernetes
- If one microservice gets broken into, build security around that service.
Building and Debugging Microservices with Kubernetes and Visual Studio