工具集小记

ELK（Elasticsearch、Logstash、Kibana）

Elasticsearch分布式搜索、

Logstash日志过滤

Kibana ELK图形化日志分析界面

消息队列 MQ，消息队列本质上拥有一定的缓存，屏蔽环境差异，中心化管理的功能，因此redis在一定程度上也有MQ的特质

https://blog.youkuaiyun.com/vtopqx/article/details/76382934

https://blog.youkuaiyun.com/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）