Merge pull request #18 from loggie-io/feat-evolution-docs

Feat: add architecture and evolution doc

docs/user-guide/enterprise-practice/architecture-and-evolution.md

@@ -1,16 +1,20 @@
-# 不同场景和规模下的日志系统架构
+# 日志系统架构与演进
 
 在不同的业务类型、不同的使用场景、不同的日志规模下，我们可能会采用不同的日志系统架构，架构不存在好坏，只有合不合适。一个简单的场景下，使用复杂的架构搭建出来的日志系统，大概会带来运维灾难。  
 
 这里通过规模演进的视角，总结一下常见的日志系统架构，当然实际的技术选型及变种有很多，我们无法一一列出，相信你可以通过参考下文，搭建适合自己业务的架构。  
 
 ## 架构演进
-需要提前说明的是，以下的规模数据量只是作为一个参考值，具体的落地情况，还需要综合考虑更多因素，同时可以融合不同的选型，以达到最合适的架构。
+需要提前说明的是:
+
+- 下文的日志存储示例为Elasticsearch，消息队列为Kafka，**具体选型请根据实际情况来做决定**。
+- 以下规模数据量只是作为一个参考值，具体的落地情况，还需要综合考虑更多因素，同时可以融合不同的选型，以达到最合适的架构。
+
 
 ### 小规模业务场景
 每天的日志规模较小，比如只有几百G（预估500G以下）左右，日志的使用场景仅仅用于日常运维排查问题，可以采用Loggie直接发送至Elasticsearch集群的方式。  
 架构图如下所示：  
-![小规模业务场景架构]()
+![小规模业务场景架构](imgs/loggie-es.png)
 
 **优点：**  
 
@@ -18,23 +22,21 @@
 
 **缺点：**  
 
-- 由于Elasticsearch的性能有限，在日志量级突然增大时，Filebeat直接发送可能会导致大量的重试或者失败，导致Elasticsearch不稳定  
+- 由于Elasticsearch的性能有限，在日志量级突然增大时，Agent直接发送可能会导致大量的重试或者失败，导致Elasticsearch不稳定 
 - 可扩展性较差
 
 **变种：**  
 因为一直以来ELK架构的流行，Elasticsearch是最常用的日志存储。  
-如果有其他服务对Elasticsearch的依赖，或者有Elasticsearch的运维经验，Elasticsearch是一个不会错误的选择。  
+如果有其他服务对Elasticsearch的依赖，或者有Elasticsearch的运维经验，Elasticsearch是一个还不错的选择。  
 但是，Elasticsearch对资源和运维有一定的要求，在某些轻量级和资源敏感的环境下，可以考虑：  
 
 - 使用Loki存储  
-- 使用节点磁盘存储
-
-如果是存粹的大数据场景下，可以考虑直接发送至Clickhouse/Hive/Doris等。  
+- 如果有相关的技术储备，还可以考虑发送至Clickhouse/Hive/Doris等。  
 
 ### 中型规模业务场景
-在每天的日志量级稍大，比如在500G至1T的规模，架构和业务使用上有扩展性的考虑，可引入Loggie中转集群。  
+在每天的日志量级稍大，比如在500G至1T的规模，架构和业务使用上有扩展性的考虑，可考虑引入Loggie中转集群。  
 
-![中型规模业务场景]()
+![中型规模业务场景](imgs/loggie-loggie-es.png)
 
 **优点：**  
 
@@ -50,15 +52,11 @@
 ### 大型规模业务场景  
 如果日志量较大，比如1T以上场景，对性能与稳定性要求比较高，可考虑使用Kafka等消息队列集群。
 
-![大型规模业务场景]()
+![大型规模业务场景](imgs/loggie-kafka-loggie-es.png)
 
 需要注意的是，Kafka本身并不能直接发送至后端，所以这里需要考虑如何将Kafka的数据实时导入到后端存储中。  
 这时候，我们可以选择一些组件消费Kafka，发送至后端，比如Loggie/Logstash/Kafka connect/Flink等。
-
-Flink:  
-
-- 适合有自己的实时流平台或者运维能力的企业，否则可能引入更多运维成本
-
+但是Flink适合有自己的实时流平台或者运维能力的企业，否则可能引入更多运维成本。  
 
 **优点：**  
 
@@ -67,16 +65,21 @@ Flink:
 
 
 ### 超大型规模业务场景  
-几十TB至PB级，相比上面大规模场景，集群数量多，机房架构复杂，可以增加更多灵活的扩展。
-如下图所示：
-
-**优点：**  
-
-
-**缺点：**  
-
+几十TB至PB级，相比上面大规模场景，集群数量多，机房架构复杂，可以根据以上架构增加更多灵活的扩展。
 
+比如：
+
+- 使用Loggie的多Pipeline特性，将业务日志拆分发送至多个Kafka集群
+- 在大规模架构下增加前置Loggie中转集群，提前进行分流和转发
 
 
+## 更多
+实际在落地一套完善的日志架构和平台，还需要考虑：
+
+- 可靠性：采集、传输、处理、查询整个链路需要保障尽量不丢日志，同时日志不影响业务稳定性
+- 可观测性和可排障性：系统要有完善的监控指标，出现问题或者故障有快速排查的手段和方式，减少人力运维的成本
+- 性能：采集、传输和处理需要轻量级，不占用太多资源，但是在数据量大的情况下，也需要有较低延迟和较大的吞吐量
+- 易用性：日志采集配置使用方便，减少业务使用成本，同时不对应用的部署有侵入
+- 功能完善：满足所需的日志处理、查询、监控报警等需求