命令查询的责任分离Command Query Responsibility Segregation 通常被简化为 命令查询分离，即读写分离。
在特定的场景下，它可以提供更好的性能。但是，在强一致性方面，它并不能够保证。而且，还会带来认知负担。所以，实际运用上，需要谨慎。
什么是 CQRS
这个概念出自于 命令与查询分离（CQS, Command Query Separation），出自于1987 年 Bertrand Meyer 的 《面向对象软件构造》一书，其原始概念是我们可以把对象操作分为：命令（Command）和 查询（Query）两种形式。
- 命令（Command）：在执行之后，会改变对象的状态。
- 查询（Query）：仅仅是查看对象的数据，而不会对对象产生改变。
而 命令查询的责任分离Command Query Responsibility Segregation (简称CQRS)模式是一种架构体系模式，能够使改变模型的状态的命令和模型状态的查询实现分离。
在单体应用时代，它是读写分离:
而在微服务的时代，就变成了命令查询的责任分离:
读写分离解决了什么？
数据库的读写分离就是：将数据库分为了主从库，一个主库用于写数据，多个从库完成读数据的操作，主从库之间通过某种机制进行数据的同步。
大多数互联网业务，往往读多写少。这时候，数据库的读会首先成为数据库的瓶颈。这时，如果我们希望能够线性的提升数据库的读性能，消除读写锁冲突从而提升数据库的写性能，那么就可以使用读写分离的架构：主从，主主等。
MySQL用的最多的就是主从，主数据库通过BinLog同步到从数据库。这就产生了一个问题，数据不一致问题。如果写数据的压力很大，binlog就会拥塞，从库数据更新不及时，就会读到老旧的脏数据。所以这个方案局限了它的应用范围：只有对一致性要求不高的场景才好使。比如，日志查询，报表等。
实现CQRS
在这里讨论是物联网的时序数据的存取场景。
我们分为两个微服务：
日志查询服务(kratos.logger.service)
主要是开放了API用于查询数据库，获取日志数据。
日志写入服务(kratos.logger.job)
订阅Kafka的日志数据写入Topic，写入到时序数据库中去。
Docker部署开发服务器
TimeScaleDB
Kafka
Consul
Jaeger
测试
下载工具
进行测试
测试写
logger.sensor.ts测试读
使用Postman向日志服务发起gRPC请求进行查询。