ELK（Elasticsearch、Logstash、Kibana）
Elasticsearch分布式搜索、
Logstash日志过滤
Kibana ELK图形化日志分析界面
消息队列 MQ，消息队列本质上拥有一定的缓存，屏蔽环境差异，中心化管理的功能，因此redis在一定程度上也有MQ的特质
https://blog.csdn.net/vtopqx/article/details/76382934
https://blog.csdn.net/linsongbin1/article/details/47781187
KafKa、RabbitMQ、ZeroMq、ActiveMQ
RabbitMQ is designed as a general purpose message broker, employing several variations of point to point, request/reply and pub-sub communication styles patterns.
Apache Kafka is designed for high volume publish-subscribe messages and streams, meant to be durable, fast, and scalable.
Let’s examine some scenarios best for RabbitMQ, like:
- Your application needs to work with any combination of existing protocols like AMQP 0-9-1, STOMP, MQTT, AMQP 1.0.
- You need a finer-grained consistency control/guarantees on a per-message basis (dead letter queues, etc.) However, Kafka has recently added better support for transactions.
- Your application needs variety in point to point, request / reply, and publish/subscribe messaging
- Complex routing to consumers, integrate multiple services/apps with non-trivial routing logic
So let’s unpack that a bit and get some clarity on which messaging scenarios are best for Kafka for, like:
- Stream from A to B without complex routing, with maximal throughput (100k/sec+), delivered in partitioned order at least once.
- When your application needs access to stream history, delivered in partitioned order at least once. Kafka is a durable message store and clients can get a “replay” of the event stream on demand, as opposed to more traditional message brokers where once a message has been delivered, it is removed from the queue.
- Stream Processing
- Event Sourcing
Nacos
coreDNS
k8s
spring-cloud-ali
golang caddy（http）