# 引言在日常工作中，相信读者在项目中或多或少会进行日志的打印，然而当我们使用常用的日志组件，如log4j、slf4j时，这些组件的默认策略都是直接将日志保存在服务器的日志文件中，它存在几个问题 1. 从开发者排查问题/调试的角度： 1. 每次希望查看日志时，需要登到具体某个机器上的某个特殊目录下，然后查看日志。 1. 多实例部署时，日志分散存储。如果我们希望定位某个问题，我们要登上多个物理机查看日志。 1. 从日志存储的角度 1. 如果我们在另一台机器上部署了应用，那么之前打印的日志就不复存在。 1. 通常日志框架都会设置7天过期，超过7天的日志会被删除。如果我们延长该时间，又会造成占用服务器资源。互联网开发者们针对这些问题，提出了很多方案，这些方案通常需要几个组件 1. 日志生成组件：应用程序、服务、操作系统或设备在运行过程中产生的日志信息。 1. Java项目中通常使用log4j、logback、slf4j等组件将日志生成在文件中。 1. 有些框架选择自己实现这部分逻辑，将日志生成在内存中。 1. 日志采集组件：负责从日志生成源实时收集日志数据。 1. 推模式（Push-based）：主动从日志数据源（如应用程序、服务或设备）获取日志信息，并将它们发送到一个集中的日志存储或处理系统。如：Filebeat、Logtail 1. Filebeat：一个轻量级的日志数据收集工具，属于Elastic公司的Elastic Stack生态系统的一部分。Filebeat通过轮询监视数据源，将新数据采集并发送到目标位置，同时确保数据的安全传输和可靠性。 1. Logtail：阿里云日志服务提供的日志采集Agent，用于采集服务器上的日志，支持多种数据源和灵活的采集策略，具有实时采集日志、自动处理日志轮转等功能。 1. 拉模式（Pull-based）：日志存储或处理系统主动向日志采集组件请求日志数据，如我们通过日志查询服务查看某个日志时，日志查询服务器实时去某个应用服务器上拉日志，该方案不常见，但在某些特定场景下，如日志数据源不允许外部组件主动连接时，可能会采用这种方式。 1. 两者两结合：Logstash 的工作方式可以视为一种拉（Pull）和推（Push）的结合：推模式（Push-based）：当 Logstash 配置为从日志文件、数据库或消息队列等数据源主动拉取数据时，它表现出推模式的特点。数据源生成数据后，Logstash 会定期检查并拉取新数据。拉模式（Pull-based）：当 Logstash 配置为从网络协议（如 Syslog）、APIs 或其他实时数据流中接收数据时，它表现出拉模式的特点。在这种情况下，数据源将数据推送到 Logstash。 1. 数据存储和索引：用于长期存储日志数据的系统 1. 如 Elasticsearch、Amazon S3、HDFS 或 Loki 等。这些系统应该具备高可靠性、可扩展性和高效的数据检索能力。 1. 日志可视化与仪表板： 1. Grafana、Kibana 或 Splunk 提供了丰富的可视化功能，帮助用户通过图表、仪表板等形式理解日志数据。我们可以看到，以上的解决方案通常都包含多个组件，且可以自由组合。然而，还有一些厂商/开源社区提出了一整套的解决方案 1. PowerJob日志系统：PowerJob的日志系统以其小巧但功能强大的特点，实现了高效、可靠的日志收集和处理。它采用分布式架构，每个节点都有日志收集器，并将日志发送到中心服务器统一处理 1. Jlog：来自京东App秒级百G级日志搜集、传输、存储解决方案。较ELK系列方案（filebeat、mq传输、es存储等常见方案），该框架拥有10倍以上的性能提升，和70%以上的磁盘节省。这意味着，在日志这个功能块上，使用相同的硬件配置，原本只能传输、存储一秒100M的日志，采用该方案，一秒可以处理1GB的日志，且将全链路因日志占用的磁盘空间下降70%。（引用自JLog Readme）下面，我们正式进入JLog的世界，来剖析JLog框架。看本文前，可以先浏览 [京东 App 秒级百 G 日志传输存储架构设计与实战](https://my.oschina.net/1Gk2fdm43/blog/5312538) 一文，该文章出自框架的作者，详细叙述了框架的架构设计以及为何这样设计，写的非常好。想单纯了解该框架的架构设计，直接看该文章即可。如果想继续深入了解该框架的源码细节，可以继续往下浏览。 # 总体逻辑 ![jlog-第 2 页.drawio 1.svg](https://p6-xtjj-sign.byteimg.com/tos-cn-i-73owjymdk6/cb4cafca9bd3436c83b3bb41cdc305be~tplv-73owjymdk6-jj-mark-v1:0:0:0:0:5o6Y6YeR5oqA5pyv56S-5Yy6IEAg5LqR6Iqz:q75.awebp?rk3s=f64ab15b&x-expires=1772277282&x-signature=T9PGVSG4aJTahzVGfcWJTU9N8CM%3D) # client端逻辑 ## 1、日志生产端日志生产端主要逻辑是，client采集日志后，把数据放到tracerBeanQueue和logBeanQueue两个队列。为什么是两个队列呢？因为Jlog框架将日志大致分为两类， - 一类是对常用的框架，如Spring MVC的请求和响应进行采集，然后生成的日志，采集后放到tracerBeanQueue中。 - 一类是调用日志框架打印的日志，如我们常用的logger.info, logger.error 等操作生成的日志，采集后放到logBeanQueue中。 ### 首先看对Spring MVC的请求和响应的采集在client包下，Jlog提供了一个filter：HttpFilter用于对request和response进行采集，然后压缩后，结合uri，traceId，appname，costTime等信息写入tracerBeanQueue。如果我们需要使用该Filter，借助如下代码进行配置 ```java @Component public class Starter { @Bean public FilterRegistrationBean urlFilter() { FilterRegistrationBean registration = new FilterRegistrationBean(); HttpFilter userFilter = new HttpFilter(); registration.setFilter(userFilter); registration.addUrlPatterns("/*"); registration.setName("UserTraceFilter"); registration.setOrder(1); return registration; } } ``` 通过FilterRegistrationBean让HttpFilter拦截一切请求，这样当请求被打到服务器时，就会执行HttpFilter的doFilter方法 ```java @Override public void doFilter(ServletRequest servletRequest, ServletResponse servletResponse, FilterChain filterChain) throws IOException, ServletException { HttpServletResponse resp = (HttpServletResponse) servletResponse; RequestWrapper requestWrapper = new RequestWrapper((HttpServletRequest) servletRequest); long currentTImeMills = System.currentTimeMillis(); String uri = requestWrapper.getRequestURI().replace("/", ""); //设置随机数 Random random = new Random(currentTImeMills); //1-100之间 int number = random.nextInt(100) + 1; //此处要有个开关，控制百分比 if (iTracerPercent.percent() < number) { filterChain.doFilter(requestWrapper, servletResponse); return; } //如果是要忽略的接口，就继续执行，不搜集信息 if (iTracerPercent.ignoreUriSet() != null && iTracerPercent.ignoreUriSet().contains(uri)) { filterChain.doFilter(requestWrapper, servletResponse); return; } //链路唯一Id long tracerId = IdWorker.nextId(); TracerHolder.setTracerId(tracerId); TracerBean tracerBean = new TracerBean(); tracerBean.setTracerId(tracerId); tracerBean.setCreateTimeLong(System.currentTimeMillis()); tracerBean.setUri(uri); tracerBean.setApp(Context.APP_NAME); //处理request的各个入参 parseRequestMap(requestWrapper, tracerBean); try { //处理response tracerBean.setResponseContent(dealResponseMap(requestWrapper, servletResponse, resp, filterChain)); } catch (Exception e) { //异常信息 tracerBean.setErrmsg(LogExceptionStackTrace.erroStackTrace(e).toString()); filterChain.doFilter(requestWrapper, servletResponse); }finally { //设置耗时 tracerBean.setCostTime((System.currentTimeMillis() - tracerBean.getCreateTimeLong())); //udp发送 UdpSender.offerBean(tracerBean); } } ``` 主要逻辑为 1. 如果按照百分比采集或者有些接口需要忽略，那就不执行日志搜集逻辑。 1. 调用IdWorker.nextId()利用雪花算法生成一个唯一id，设置到TransmittableThreadLocal中 1. 将请求的入参封装到TracerBean的uid 和 requestContent中 1. 将响应的结果写到TracerBean的responseContent中 1. 如果发生异常，将异常信息写入TracerBean的errmsg中 1. 将耗时写入TracerBean的costTime中 1. 调用UdpSender.offerBean(tracerBean)将TracerBean写到tracerBeanQueue中。 #### IdWorker.nextId() ```java //雪花算法生成id public static long nextId() { long time = System.currentTimeMillis(); // 如果时钟回溯，就报错 if (lastTime > time) { throw new RuntimeException("Clock is moving backwards, last time is %d milliseconds, current time is %d milliseconds" + lastTime); } // 如果当前时间和上次生成ID的时间相同，则sequence自增1，如果自增后发现是0，则等下一个时间戳 // 如果当前时间和上次生成ID的时间不相同，则sequence从0开始 if (lastTime == time) { if (0L == (sequence = ++sequence & SEQUENCE_MASK)) { time = waitUntilNextTime(time); } } else { sequence = 0; } // 记录本次生成ID的时间 lastTime = time; // 雪花算法生生成id，时间戳为当前时间 - 2017.3.1的时间戳， workerId是根据ip地址确定的 return ((time - EPOCH) << TIMESTAMP_LEFT_SHIFT_BITS) | (workerId << WORKER_ID_LEFT_SHIFT_BITS) | sequence; } ``` #### 请求入参的封装 ```java // Filter中将servletRequest包装成RequestWrapper RequestWrapper requestWrapper = new RequestWrapper((HttpServletRequest) servletRequest); // 处理request的各个入参 parseRequestMap(requestWrapper, tracerBean); ``` ```java /** * 处理入参相关信息 */ private void parseRequestMap(RequestWrapper requestWrapper, TracerBean tracerBean) { // 获取request的各个入参，封装到变量requestMap中 Map params = requestWrapper.getParameterMap(); Map requestMap = new HashMap<>(params.size()); for (String key : params.keySet()) { requestMap.put(key, params.get(key)[0]); } // 将请求参数中的uid设置到tracerBean中 tracerBean.setUid((String) requestMap.get("uid")); //对于@RequestBody类型的，可以通过该方法读取字符串。是个json串 String body = requestWrapper.getBody(); if (StringUtil.isNotBlank(body)) { //将json转成map Map jsonMap = FastJsonUtils.toMap(body); // 设置到requestMap中 requestMap.putAll(jsonMap); } // 根据配置判断是否提取以及是否压缩，获得 Outcome，其中包括提取的tag以及将这些tag作为json字符串进行压缩 Outcome out = ClientHandler.processReq(requestMap); // 设置到 tracerBean的 requestContent中 tracerBean.setRequestContent((byte[]) out.getContent()); } ``` 处理入参的逻辑主要包括两大功能 1. 提取请求中的标签，具体该提取哪些标签，可配置 - 代码逻辑中先将所有的请求参数和body中的参数封装成map，然后根据配置的标签进行匹配，哪些需要入日志，因为请求参数量大，全部都保存也不现实，所以可以通过配置选择性地保存某些请求参数到配置中。 1. 请求可能会很大，比如上传图片，上传视频等，所以会根据配置决定是否将请求的内容进行压缩其中重点看一下 ```java Outcome out = ClientHandler.processReq(requestMap); ``` ```java public static Outcome processReq(Map reqMap){ // 根据配置决定是否提取 tag标签 Map tag = ExtractHandler.extractReqTag(reqMap); // 根据配置决定是否压缩tagMap return CompressHandler.compressReq(tag); } ``` 根据配置决定是否提取 tag标签 ```java /** * 提取请求参数里的标签 * @param reqMap 额外附加的,如ip等 * @return tags */ public static Map extractReqTag(Map reqMap) { if(instance == null || !isMatched(instance.extract, E_REQ) || CollectionUtil.isEmpty(reqMap)){ return null; } Map tagMap = new HashMap<>(instance.reqTags.size()); for (String tag : instance.reqTags) { Object val = reqMap.get(tag); if(val != null){ tagMap.put(tag, val); } }return tagMap; } ``` 怎么根据配置呢？ ```java isMatched(instance.extract, E_REQ) ``` instance.extract 是从配置文件中读的，E_REQ是个常量 1，isMatched就是判断按位与，是否是该常量。因此，我们如果想要配置不提取req，直接将instance.extract的最小位配置为0即可。 ```java public static boolean isMatched(long indicator, long position) { return (indicator & position) == position; } ``` ```java // 根据配置决定是否压缩tagMap CompressHandler.compressReq(tag) ``` ```java /** * req一般无需压缩除非图片base64等触发压缩 * @param map tagMap * @return Outcome */ public static Outcome compressReq(Map map){ if(instance == null || CollectionUtil.isEmpty(map) || !isMatched(instance.compress, C_REQ)){ return new Outcome(map); } return new Outcome(map, ZstdUtils.compress(JSON.toJSONBytes(map))); } ``` #### 响应的封装 ```java //处理response tracerBean.setResponseContent(dealResponseMap(requestWrapper, servletResponse, resp, filterChain)); ``` ```java /** * 处理出参相关信息 */ private byte[] dealResponseMap(ServletRequest servletRequest, ServletResponse servletResponse, HttpServletResponse resp, FilterChain filterChain) throws IOException, ServletException { // 包装响应对象 resp 并缓存响应数据 ResponseWrapper mResp = new ResponseWrapper(resp); filterChain.doFilter(servletRequest, mResp); // 把响应内容取出来，转成map byte[] contentBytes = mResp.getContent(); String content = new String(contentBytes); Map map = FastJsonUtils.toMap(content); // 根据配置判断是否提取tag，以及是否压缩 Outcome outcome = ClientHandler.processResp(contentBytes, map); //此处可以对content做处理,然后再把content写回到输出流中 servletResponse.setContentLength(-1); PrintWriter out = servletResponse.getWriter(); out.write(content); out.flush(); out.close(); return (byte[]) outcome.getContent(); } ``` 响应和请求一样 1. 根据配置判断是否需要提取tag 1. 根据配置判断是否需要压缩将请求以及响应，以及发生异常的异常信息，耗时都保存到TracerBean中后，就调用UdpSender.offerBean(tracerBean)将TracerBean写到tracerBeanQueue中。 ```java /** * 写入队列 */ public static void offerBean(TracerBean tracerModel) { //容量是否已满 boolean success = tracerBeanQueue.offer(tracerModel); if (!success) { long failCount = FAIL_OFFER_COUNT.incrementAndGet(); if (failCount % 10 == 0) { logger.info("用户跟踪队列已满，当前丢弃的数量为: " + failCount); } } else { long successCount = SUCCESS_OFFER_COUNT.incrementAndGet(); if (successCount % 1000 == 0) { logger.info("用户跟踪已产生数量：" + successCount + "，当前队列积压数量：" + tracerBeanQueue.size()); } } } ``` 调用offer方法将TracerBean加到tracerBeanQueue中，如果队列中还有空间，返回true，否则返回false。如果返回false，则直接丢弃，并记录丢弃的数量后，打印日志。 ### 日志框架打印的日志搜集 ![image.png](https://p6-xtjj-sign.byteimg.com/tos-cn-i-73owjymdk6/5fed98bff5554e8a8a1849abb67567ce~tplv-73owjymdk6-jj-mark-v1:0:0:0:0:5o6Y6YeR5oqA5pyv56S-5Yy6IEAg5LqR6Iqz:q75.awebp?rk3s=f64ab15b&x-expires=1772277282&x-signature=jyO%2B7xSowkKSX9EdPnnig8mRfJg%3D) 在logback-spring.xml中，配置了一个TracerLogbackAppender，这样当我们调用logger.info或者 logger.error时，会调用TracerLogbackAppender#append的方法每当调用TracerLogbackAppender#append方法时，会调用getLogMessage方法将iLoggingEvent转化为RunLogMessage，写入logBeanQueue中。 ```java @Override protected void append(ILoggingEvent iLoggingEvent) { try { long tracerId = TracerHolder.getTracerId(); if (0L == tracerId) { return; } RunLogMessage logMessage = getLogMessage(iLoggingEvent); UdpSender.offerLogger(logMessage); } catch (Exception e) { e.printStackTrace(); } } ``` getLogMessage转化方法如下： ``` /** * 转化为对象 */ private RunLogMessage getLogMessage(ILoggingEvent loggingEvent) { RunLogMessage logMessage = new RunLogMessage(); //设置链路唯一id logMessage.setTracerId(TracerHolder.getTracerId()); logMessage.setClassName(loggingEvent.getLoggerName()); logMessage.setThreadName(loggingEvent.getThreadName()); StackTraceElement stackTraceElement = loggingEvent.getCallerData()[loggerStage]; String method = stackTraceElement.getMethodName(); String line = String.valueOf(stackTraceElement.getLineNumber()); logMessage.setMethodName(method + "(" + stackTraceElement.getFileName() + ":" + line + ")"); logMessage.setLogLevel(loggingEvent.getLevel().toString()); logMessage.setCreateTime(loggingEvent.getTimeStamp()); String formattedMessage = getMessage(loggingEvent); Outcome out = ClientHandler.processLog(formattedMessage); // 放入标签 logMessage.setTagMap(out.getTagMap()); // 放入内容可能已经被压缩了 logMessage.setContent(formattedMessage); return logMessage; } ``` 其中，我们可以看到该方法将loggingEvent的属性都赋值给RunLogMessage。但其中有一串特殊的代码 ```java String formattedMessage = getMessage(loggingEvent); Outcome out = ClientHandler.processLog(formattedMessage); // 放入标签 logMessage.setTagMap(out.getTagMap()); // 放入内容可能已经被压缩了 logMessage.setContent(formattedMessage); ``` 该代码将loggingEvent中的日志正文信息转化为了字符串，并提取log标签后，赋值给logMessage。 ```java /** * 日志正文信息 */ private String getMessage(ILoggingEvent logEvent) { if (logEvent.getLevel() == Level.ERROR) { if (logEvent.getThrowableProxy() != null) { ThrowableProxy throwableProxy = (ThrowableProxy) logEvent.getThrowableProxy(); String[] args = new String[]{logEvent.getFormattedMessage() + "\n" + LogExceptionStackTrace.erroStackTrace(throwableProxy.getThrowable()).toString()}; return packageMessage("{}", args); } else { Object[] args = logEvent.getArgumentArray(); if (args != null) { for (int i = 0; i < args.length; i++) { if (args[i] instanceof Throwable) { args[i] = LogExceptionStackTrace.erroStackTrace(args[i]); } } return packageMessage(logEvent.getMessage(), args); } } } return logEvent.getFormattedMessage(); } ``` 再看TracerLogbackAppender#append方法中，当生成了RunLogMessage后，调用的UdpSender.offerLogger(logMessage);方法 ``` RunLogMessage logMessage = getLogMessage(iLoggingEvent); UdpSender.offerLogger(logMessage); ``` 然后将RunLogMessage写到logBeanQueue中 ```java /** * 写入log队列 */ public static void offerLogger(RunLogMessage runLogMessage) { //容量是否已满 boolean success = logBeanQueue.offer(runLogMessage); if (!success) { long failCount = FAIL_OFFER_COUNT.incrementAndGet(); if (failCount % 10 == 0) { logger.info("用户Logger队列已满，当前丢弃的数量为: " + failCount); } } else { long successCount = SUCCESS_LOGGER_OFFER_COUNT.incrementAndGet(); if (successCount % 10000 == 0) { logger.info("用户Logger已产生数量：" + successCount + "，当前队列积压数量：" + logBeanQueue.size()); } } } ``` ### 小结至此，我们分析完了client端的日志采集流程，主要通过HttpFilter和TracerLogbackAppender将日志分别封装成TracerBean（其中请求和响应根据配置决定是否压缩）和RunLogMessage。 ## 2. 日志消费端 client采集日志后，把数据放到tracerBeanQueue和logBeanQueue两个队列后，后续的工作呢？如何将这些内存队列中的数据搜集到服务端呢？首先我们从client模块下的TracerClientStarter#startPipeline方法开始看起 ```java /** * 启动监听 */ public void startPipeline() { // 初始化配置 initJLogConfig(); Context.MDC = mdc; ModeHolder.setSendMode(this.sendMode); Monitor starter = new Monitor(); starter.start(); UdpClient udpClient = new UdpClient(); udpClient.start(); //开启发送 UdpSender.uploadToWorker(); //开启大对象http发送 HttpSender.uploadToWorker(); } ``` 最关键的就是三部分代码 ### 1. 开始获取workerIp地址并保存 ```java Monitor starter = new Monitor(); starter.start(); public void start() { fetchWorkerInfo(); } /** * 每隔30秒拉取worker信息 */ private void fetchWorkerInfo() { ScheduledExecutorService scheduledExecutorService = Executors.newSingleThreadScheduledExecutor(); //开启拉取etcd的worker信息，如果拉取失败，则定时继续拉取 scheduledExecutorService.scheduleAtFixedRate(() -> { LOGGER.info("trying to connect to config center and fetch worker info"); try { fetch(); } catch (Exception e) { e.printStackTrace(); } }, 0, 30, TimeUnit.SECONDS); } /** * 从配置中心获取worker的ip集合 */ private void fetch() throws Exception { Configurator configurator = ConfiguratorFactory.getInstance(); //获取所有worker的ip List addresses; try { //如果设置了机房属性，则拉取同机房的worker。如果同机房没worker，则拉取所有 addresses = configurator.getList("workers"); //全是空，给个警告 if (addresses == null || addresses.size() == 0) { LOGGER.warn("very important warn !!! workers ip info is null!!!"); return; } //将对应的worker保存下来 WorkerInfoHolder.mergeAndConnectNew(addresses); } catch (Exception ex) { LOGGER.error("config server connected fail. Check the config address!!!"); } } ``` 从上面的代码中可以看到，每隔30s定时执行fetch方法，即从配置中心拉取worker信息，然后保存起来。 jlog模块提供了多种配置中心的实现 ![image.png](https://p6-xtjj-sign.byteimg.com/tos-cn-i-73owjymdk6/cc4ae18d426d44d5b5994e47144ec49e~tplv-73owjymdk6-jj-mark-v1:0:0:0:0:5o6Y6YeR5oqA5pyv56S-5Yy6IEAg5LqR6Iqz:q75.awebp?rk3s=f64ab15b&x-expires=1772277282&x-signature=DtouN3yEM6VMJG%2FnLAQQ3dKvNH4%3D) 当从配置中心获取了worker信息后，调用下面一行代码将worker保存 ```java WorkerInfoHolder.mergeAndConnectNew(addresses); ``` ```java /** * 保存worker的ip地址和Channel的映射关系，这是有序的。每次client发送消息时，都会根据该map的size进行hash * 如key-1就发送到workerHolder的第1个Channel去，key-2就发到第2个Channel去 */ private static final List WORKER_HOLDER = new CopyOnWriteArrayList<>(); /** * 监听到worker信息变化后 * 将新的worker信息和当前的进行合并，并且连接新的address * address例子：10.12.139.152:11111 */ public static void mergeAndConnectNew(List allAddresses) { if (allAddresses.size() == 0) { WORKER_HOLDER.clear(); return; } //将新的进行排序 Collections.sort(allAddresses); //对比是否两个list是否一样，如果一样就什么也不干 if (WORKER_HOLDER.equals(allAddresses)) { return; } //变更WORKER_HOLDER WORKER_HOLDER.clear(); WORKER_HOLDER.addAll(allAddresses); } ``` 逻辑简单粗暴，就是将配置中心的worker信息保存到本地。 ### 2. 启动UDP相关逻辑 ```java UdpClient udpClient = new UdpClient(); udpClient.start(); //开启发送 UdpSender.uploadToWorker(); ``` #### 先看udpClient.start(); ```java /** * startUdp */ private void startUdp() { //1.NioEventLoopGroup是执行者 NioEventLoopGroup group = new NioEventLoopGroup(); //2.启动器 Bootstrap bootstrap = new Bootstrap(); //3.配置启动器 bootstrap.group(group) //3.1指定group .channel(NioDatagramChannel.class) //3.2指定channel .handler(new ChannelInitializer() { @Override protected void initChannel(NioDatagramChannel nioDatagramChannel) { //3.4在pipeline中加入编码器，和解码器（用来处理返回的消息） nioDatagramChannel.pipeline().addLast(new MyUdpEncoder()); } }); //4.bind并返回一个channel try { Channel channel = bootstrap.bind(8887).sync().channel(); Context.CHANNEL = channel; //6.等待channel的close channel.closeFuture().sync(); //7.关闭group group.shutdownGracefully(); } catch (InterruptedException e) { e.printStackTrace(); } } ``` 这串代码就是简单的netty client的逻辑，只是在 netty的pipeline中增加了一个encoder：MyUdpEncoder，而这个MyUdpEncoder就是重头戏 ```java /** * 编码器，将要发送的消息（这里是一个String）封装到一个DatagramPacket中 */ private static class MyUdpEncoder extends MessageToMessageEncoder { @Override protected void encode(ChannelHandlerContext channelHandlerContext, TracerData tracerData, List