feat: typesetting issues 🧐

_posts/2023-10-19-test-markdown.md

@@ -63,13 +63,15 @@ OpenTelemetry为应用程序提供了追踪和度量的能力。当使用OpenTel
 
 > Jaeger的内存存储
 
+
 内存存储：Jaeger的一个简单配置是使用内存存储，这意味着所有的追踪数据都保存在内存中，不持久化到磁盘。这种配置适用于开发和测试环境，但不适用于生产环境，因为重启Jaeger实例会导致数据丢失。
 
 Badger存储：Badger是一个嵌入式的键/值存储，可以在本地文件系统中持久化数据。Jaeger可以配置为使用Badger作为其存储后端，这为那些不想设置外部存储系统（如Elasticsearch或Cassandra）的用户提供了一个简单的持久化选项。
 
 外部存储后端：虽然Jaeger支持Elasticsearch、Cassandra和Kafka作为存储后端，但这并不意味着它们在默认配置中都被使用。需要明确地配置Jaeger以使用这些后端，并确保相应的存储系统已经设置并运行。
 
-```shell
+> Jaeger 请求处理的过程
+
 代理和收集器：当发送追踪数据到Jaeger时，通常首先发送到Jaeger代理，然后代理将数据转发到Jaeger收集器。收集器负责将数据写入配置的存储后端。
 
 应用程序/服务：这是开始点。当一个请求进入的应用程序或服务时，OpenTelemetry或Jaeger客户端库会开始记录一个追踪。追踪包含了请求从开始到结束的所有信息，包括调用的各个服务、函数和外部资源。
@@ -89,7 +91,7 @@ Jaeger-collector：收集器接收来自一个或多个代理的追踪数据。
 Jaeger UI：当用户想要查看追踪数据时，他们会使用Jaeger UI。这个UI从存储后端查询数据，并以图形化的方式展示追踪和spans。
 
 总结：一个请求的追踪数据从应用程序开始，通过Jaeger客户端库、Jaeger代理、Jaeger收集器，最后存储在配置的存储后端中。当需要查看这些数据时，可以通过Jaeger UI进行查询和可视化。
-```
+
 
 > jaeger-agent 和 jaeger-collector 通过gRPC 通信
 
@@ -150,6 +152,7 @@ jaeger-agent --reporter.grpc.host-port=jaeger-collector.example.com:14250
 通过以上步骤，可以在分布式环境中部署Jaeger，从而实现高可用性、扩展性和故障隔离。这种部署方式特别适合大型或复杂的微服务和分布式系统。
 
 > 使用Docker模拟部署分布式Jaeger的步骤
+
 使用Docker部署分布式Jaeger是一个很好的选择，因为Docker提供了一个轻量级、隔离的环境，可以轻松地模拟分布式部署。以下是使用Docker模拟部署分布式Jaeger的步骤：
 
 设置存储后端：
@@ -189,8 +192,7 @@ docker run --name jaeger-query -d -p 16686:16686 -e SPAN_STORAGE_TYPE=elasticsea
 总之，使用Docker可以轻松地模拟Jaeger的分布式部署，这对于开发、测试和学习都是非常有用的。
 
 
-> 当引入Jaeger进行分布式追踪时，有哪些常见的性能考虑？
-
+> 当引入Jaeger进行分布式追踪时，常见的性能考虑？
 
 采样策略：
 
@@ -223,9 +225,7 @@ Jaeger支持多种存储后端，如Elasticsearch、Cassandra和Kafka。每种
 根据追踪数据的量和查询需求为Jaeger分配足够的计算和存储资源。
 引入Jaeger时，应该在测试环境中进行性能测试和调优，确保在生产环境中不会出现性能问题或故障。
 
-
-
-> 采样策略
+> 采样策略？
 
 Jaeger支持多种采样策略，以允许用户根据其需求和环境来选择最合适的策略。以下是Jaeger支持的主要采样策略：
 
@@ -284,7 +284,7 @@ docker run -d -p 5775:5775/udp -p 6831:6831/udp -p 6832:6832/udp -p 5778:5778/tc
 
 > 假设在一个微服务环境中，发现一个服务的追踪数据没有出现在Jaeger UI中，会如何调查和解决这个问题？
 
-如果在微服务环境中某个服务的追踪数据没有出现在Jaeger UI中，以下是一些调查和解决问题的步骤：
+如果某个服务的追踪数据没有出现在Jaeger UI中，以下是一些调查和解决问题的步骤：
 
 检查服务的Jaeger客户端配置：
 
@@ -325,8 +325,7 @@ docker run -d -p 5775:5775/udp -p 6831:6831/udp -p 6832:6832/udp -p 5778:5778/tc
 在服务中添加更多的日志或指标，以帮助诊断问题。
 通过上述步骤，应该可以定位并解决服务追踪数据没有出现在Jaeger UI中的问题。
 
-
-> 请解释以下术语：Span、Trace、Baggage和Context。
+> Span、Trace、Baggage和Context？
 
 Span:
 
@@ -401,7 +400,8 @@ Jaeger的架构设计为模块化，这使得它更容易扩展和自定义。
 
 
 
-> 如何传递追踪信息：
+> 如何传递追踪信息？
+
 HTTP Headers：在基于HTTP的微服务架构中，追踪信息（如trace ID和span ID）通常作为HTTP headers传递。例如，使用B3 Propagation headers（由Zipkin定义）。
 
 消息队列：在基于消息的系统中，追踪信息可以作为消息的元数据或属性传递。
@@ -425,12 +425,12 @@ Context Propagation：在同一进程内的不同组件之间，可以使用编
 
 > 链路追踪
 
-1. 链路追踪
+链路追踪:
 链路追踪通常使用一个称为“span”的概念来代表一个工作单元或一个操作，例如一个函数调用或一个数据库查询。每个span都有一个唯一的ID，以及其他关于该操作的元数据，如开始和结束时间。
 
 这些span被组织成一个树结构，其中一个span可能是另一个span的父span。最顶部的span称为“trace”，它代表一个完整的操作，如一个HTTP请求。
 
-2. 传递追踪信息
+传递追踪信息:
 为了跟踪一个完整的请求，当它穿越多个服务时，我们需要将追踪信息从一个服务传递到另一个服务。这通常是通过在HTTP头部或消息元数据中添加特殊的追踪标识符来实现的。
 
 常用的标识符有：
@@ -439,7 +439,7 @@ Trace ID：代表整个请求的唯一标识。
 Span ID：代表单个操作或工作单元的标识。
 Parent Span ID：标识父span的ID。
 
-3. 多线程追踪
+多线程追踪:
 在多线程或并发环境中进行追踪略有挑战，因为不同的线程可能并发地执行多个操作。为了在这样的环境中准确地跟踪操作，我们需要注意以下几点：
 
 线程局部存储（Thread-Local Storage, TLS）：使用TLS存储当前线程的追踪上下文。这意味着即使在并发环境中，每个线程也都有自己的追踪上下文，不会与其他线程混淆。
@@ -448,7 +448,7 @@ Parent Span ID：标识父span的ID。
 
 正确的父/子关系：确保在多线程环境中正确地标识span的父/子关系。例如，如果两个操作在不同的线程上并发执行，它们可能会有同一个父span，但是它们应该是兄弟关系，而不是父/子关系。
 
-线程局部存储 (TLS):
+> 线程局部存储 (TLS)?
 
 Go 的 goroutines 不直接映射到操作系统的线程，因此传统的线程局部存储不适用。
 为了解决这个问题，可以使用 context 包来传递追踪信息。context 提供了一个键-值对的存储方式，可以在多个 goroutine 之间传递，并且是并发安全的。
@@ -512,7 +512,6 @@ Parent Span ID: 如果当前span是由另一个span触发或创建的，则这
 
 > 如何传递追踪信息?谁来生成 id，什么算法?
 
-如何传递追踪信息：
 HTTP Headers：在基于HTTP的微服务架构中，追踪信息（如trace ID和span ID）通常作为HTTP headers传递。例如，使用B3 Propagation headers（由Zipkin定义）。
 
 消息队列：在基于消息的系统中，追踪信息可以作为消息的元数据或属性传递。
@@ -521,19 +520,22 @@ gRPC Metadata：对于使用gRPC的系统，追踪信息可以通过gRPC的metad
 
 Context Propagation：在同一进程内的不同组件之间，可以使用编程语言提供的上下文（如Go的context.Context）来传递追踪信息。
 
+> 如何生成 id?
+
 谁来生成ID：
 边缘服务：第一个接收到请求的服务（通常是API网关或边缘服务）负责生成trace ID。这确保了整个请求链中的所有spans都共享相同的trace ID。
 
 每个服务：每个服务在开始处理请求时都会生成一个新的span ID。这标识了该服务处理的操作或任务。
 
-什么算法：
+> 什么算法？
+
 随机生成：使用强随机数生成器生成随机ID。例如，使用UUID（通常是UUID v4）。
 
 雪花算法（Snowflake）：这是Twitter开发的一个算法，用于生成唯一的ID。它结合了时间戳、机器ID和序列号来确保在分布式系统中生成的ID是唯一的。
 Snowflake 是一个用于生成64位ID的系统。这些ID在时间上是单调递增的，并且可以在多台机器上生成，而不需要中央协调器。
-```shell
-这个64位ID可以被分为以下几个部分：
 
+这个64位ID可以被分为以下几个部分：
+```shell
 时间戳 (timestamp) - 通常占41位，用于记录ID生成的毫秒级时间。41位的时间戳可以表示约69年的时间。
 机器ID (machine ID) - 用于标识ID的生成器，可以是机器ID或数据中心ID和机器ID的组合。这样可以确保同一时间戳下，不同机器产生的ID不冲突。
 序列号 (sequence) - 在同一毫秒、同一机器下，序列号保证ID的唯一性。
@@ -543,8 +545,7 @@ Snowflake 是一个用于生成64位ID的系统。这些ID在时间上是单调
 增量或原子计数器：对于单一服务，可以简单地使用一个原子计数器来生成span IDs。但是，这种方法在分布式系统中可能不是很实用，除非它与其他信息（如机器ID）结合使用。
 
 
-> RPC
-从头实现 RPC 会怎么写
+> 从头实现 RPC 会怎么写？
 
 实现一个简单的 RPC (Remote Procedure Call) 系统需要考虑以下几个方面：
 
@@ -627,46 +628,46 @@ func main() {
 
 
 
-> 有没有了解其他链路追踪工具（Skywalking）？
+> 其他链路追踪工具（Skywalking）？
+
+
+Skywalking。Skywalking 是一个可观测性平台，用于收集、分析和聚合服务应用的追踪数据，性能指标和日志。它可以帮助开发和运维团队深入了解系统的性能，找出瓶颈或故障点。
+
+Skywalking 支持多种语言，如 Java, .NET, PHP, Node.js, Golang 和 Lua，并且它可以无缝地集成到许多流行的服务和框架中。它的 UI 提供了一个直观的仪表板，用于展示系统的各种指标和追踪数据。
 
+> 什么是分布式追踪？为什么它是重要的？
 
-是的，我对一些其他的链路追踪工具有所了解，例如 Skywalking。Skywalking 是一个可观测性平台，用于收集、分析和聚合服务应用的追踪数据，性能指标和日志。它可以帮助开发和运维团队深入了解系统的性能，找出瓶颈或故障点。
+> 解释Skywalking的主要功能和优点。
 
-我了解到 Skywalking 支持多种语言，如 Java, .NET, PHP, Node.js, Golang 和 Lua，并且它可以无缝地集成到许多流行的服务和框架中。它的 UI 提供了一个直观的仪表板，用于展示系统的各种指标和追踪数据。
+> ELK是什么？请描述其组成部分（Elasticsearch, Logstash, Kibana）的功能。
 
-虽然我个人主要使用（熟悉的追踪工具，例如：Jaeger、Zipkin 等）进行链路追踪，但我认为了解和比较不同的工具是很有价值的。每个工具都有其独特的特点和优势，而了解多个工具可以帮助我们根据特定的需求和场景选择最合适的解决方案。
 
+> 怎样在一个微服务应用中集成 Skywalking？
 
-什么是分布式追踪？为什么它是重要的？
-解释Skywalking的主要功能和优点。
-ELK是什么？请描述其组成部分（Elasticsearch, Logstash, Kibana）的功能。
+> 怎样将 Skywalking 的数据与 ELK 集成？
 
-集成与应用：
-怎样在一个微服务应用中集成 Skywalking？
-怎样将 Skywalking 的数据与 ELK 集成？
-当有一个性能问题时，怎么使用 Skywalking 和 ELK 来进行诊断？
-深入探讨：
+> 当有一个性能问题时，怎么使用 Skywalking 和 ELK 来进行诊断？
 
-Skywalking 和其他追踪系统（如 Jaeger、Zipkin）有什么区别？
-ELK 在大数据量下可能遇到哪些性能和存储问题？如何解决？
-如何确保追踪数据的完整性和准确性？
 
-高级使用与优化：
-当Skywalking的数据量非常大时，如何优化存储和查询？
-如何配置和优化Elasticsearch以满足高并发的日志查询需求？
-怎样使用Kibana创建有意义的可视化面板来显示追踪数据？
-安全与合规：
+> Skywalking 和其他追踪系统（如 Jaeger、Zipkin）有什么区别？
 
-如何确保在ELK中存储的数据安全？
-在集成Skywalking和ELK时，如何处理敏感数据？
-实际场景模拟：
+> ELK 在大数据量下可能遇到哪些性能和存储问题？如何解决？
 
-假设某个服务的响应时间突然增加，如何使用 Skywalking 和 ELK 来找出原因？
-如何设置告警，以便当某个服务出现问题时能够及时得知？
-未来与趋势：
+> 如何确保追踪数据的完整性和准确性？
 
-近年来分布式追踪和日志管理有哪些新的趋势和发展？
-通过这些问题，面试官可能希望了解面试者对于分布式追踪和日志管理的深入理解，以及在实际应用中的经验和解决问题的能力。
+> 当Skywalking的数据量非常大时，如何优化存储和查询？
+
+> 如何配置和优化Elasticsearch以满足高并发的日志查询需求？
+
+> 怎样使用Kibana创建有意义的可视化面板来显示追踪数据？
+
+> 如何确保在ELK中存储的数据安全？
+
+> 在集成Skywalking和ELK时，如何处理敏感数据？
+
+> 假设某个服务的响应时间突然增加，如何使用 Skywalking 和 ELK 来找出原因？
+
+> 如何设置告警，以便当某个服务出现问题时能够及时得知？
 
 
 > 数据库中间件链路追踪
@@ -720,13 +721,12 @@ UUID: 利用算法和系统特点生成全局唯一标识符。
 遍历完成后，堆中的K个数就是最大的K个数。
 
 
-> 请解释什么是 Go 中的 Context 及其主要用途?
+>  Go 中的 Context 及其主要用途?
 
 考察 Golang 的 Context 主要是为了评估对并发编程中的超时、取消信号以及跨 API 的值传递的理解。
 
 Context 的主要用途：
 
-
 超时和取消：可以设置某个操作的超时时间，或者在操作完成前手动取消它。
 请求范围的值传递：虽然不鼓励在 Context 中存储大量的数据，但它提供了一种跨 API 边界传递请求范围的值（例如请求 ID、用户认证令牌等）的方法。
 跟踪和监控：可以用来传递请求或任务的跟踪信息，如日志或度量。
@@ -782,7 +782,7 @@ ctx.Done() 返回一个channel，当 Context 被取消或超时时，这个chann
 
 总之，当Context被取消或超时时，与之相关的goroutines需要通过Context提供的机制来感知这一事件，并采取适当的行动。但是，Context本身并不强制执行任何特定的行为，goroutines需要自己管理和响应取消或超时。
 
-> 请解释 context.WithValue 的用途和工作原理。
+> context.WithValue 的用途和工作原理。
 
 用途：context.WithValue函数允许在Context中关联一个键值对，这为跨API边界或goroutines传递请求范围内的数据提供了一种机制。这对于传递如请求ID、认证令牌等在请求生命周期中需要可用的数据特别有用。
 
@@ -803,7 +803,6 @@ ctx.Done() 返回一个channel，当 Context 被取消或超时时，这个chann
 避免使用非context包中定义的类型作为键，以减少键之间的冲突。最佳实践是定义一个私有类型并使用它作为键，例如 type myKey struct{}。
 最后，对于context.WithValue，关键是明智地使用。确保它是在请求范围内传递少量关键数据时的合适工具，而不是用于通用的、全局的或大量的数据传递。
 
-描述一个曾经遇到的，需要使用 Context 来解决的实际问题。
 
 > 如果有一个与数据库交互的长时间运行的查询，如何使用 Context 确保它在特定的超时时间内完成或被取消？