1.【Apache SkyWalking】实战系列教程（三）- SkyWalking部署与配置
2.Skywalking8.9.1源码解析<一>-Skywalking简介及系统架构解析
3.分布式链路追踪 SkyWalking 源码分析 —— DataCarrier 异步处理库
4.博云违反 Apache 2.0 开源协议被要求整改，源码阅读开源协议应如何遵守？
5.从分析 SkyAPM-dotnet 源码学习现代 APM 探针设计理念（一）
6.线上环境OOM频发，源码阅读MyBatis有坑...
【Apache SkyWalking】实战系列教程（三）- SkyWalking部署与配置
选择免费服务器平台，源码阅读如华为云，源码阅读安装CentOS系统，源码阅读以便后续能够顺畅运行Docker和Apache SkyWalking相关组件。源码阅读桃花岛社区源码
利用宝塔面板，源码阅读作为服务器管理界面，源码阅读简化Linux管理流程。源码阅读通过宝塔面板安装过程，源码阅读确保系统配置正确，源码阅读如开放端口。源码阅读
安装Docker于宝塔面板中，源码阅读便于后续部署Apache SkyWalking所需应用。源码阅读
为部署Apache SkyWalking，源码阅读首先确保使用特定版本的镜像，如elasticsearch:7.5.1和apache/skywalking-oap-server:6.6.0-es7，避免兼容性问题。下载agent源码包，准备后续的安装流程。
借助docker环境，安装并配置Elasticsearch，进行持久化存储设置，确保数据安全稳定。在服务器上启动Elasticsearch并验证其正常运行。
通过Docker安装Apache SkyWalking OAP，并指定Elasticsearch用于数据存储，完成部署。
接着安装SkyWalking UI，青岛北站离栈桥源码并设置端口为，避免与系统其他服务冲突。确保在华为云中开放相应端口。
应用接入部署中，Java应用接入以SpringBootDemo为例，通过Maven构建并打包应用，使用skywalkingagent实现监控功能，指定agent服务名和服务地址，启动应用时自动集成SkyWalking监控。
对于非Java应用接入，暂未详细说明，后续将补充相关流程。
访问SkyWalking UI，展示应用监控数据，包括拓扑图、API调用详情等，实现全链路监控功能。
总结，通过Docker环境部署Apache SkyWalking，实现应用监控与优化，简化服务器管理，并提供直观的可视化界面，便于监控应用性能与问题定位。
Skywalking8.9.1源码解析<一>-Skywalking简介及系统架构解析
Skywalking 8.9.1源码解析系列旨在深入探讨该版本的Skywalking-OAP及其探针Skywalking-java8.9.0。本文基于官方文档、博客和个人理解，对Skywalking进行简介和系统架构解析。
Skywalking是按键精灵保存源码一款强大的分布式追踪系统，提供详尽的UI界面，可通过OpenTrace官方文档了解其Trace概念。核心功能包括性能监控和分布式追踪，以帮助开发者理解和优化应用程序的性能。
Skywalking的代码模块构建在微内核架构上，这种架构允许通过插件形式扩展核心功能，如IDEA和Eclipse的插件模式。SkyWalking Agent和OAP都采用微内核架构，利用ModuleManager管理组件和ModuleProvider，实现模块间的高效通信和功能扩展。
在通信方面，Skywalking探针和服务器主要通过Grpc进行数据交换，考虑到性能和数据丢失风险，有人提议用Kafka替代，但官方仅支持Grpc和SSL。Skywalking UI与后端的交互采用GraphQL，尽管restful更为常见，但GraphQL提供了更灵活的数据获取方式。
存储方面，Skywalking支持模块化存储选择，官方推荐内存数据库Es，但在线上环境中可能需要特定数据库支持。本地开发环境通常使用Mysql，生产环境将根据需求进行选择。数据库表结构会在后续文章中详细讨论。
数据流方面，Skywalking的数据经过OAL处理后入库，OAL层的车牌识别源码在哪里具体作用官方未明示，但可能是为了进一步处理和优化数据。本文从整体架构深入到细节，助力需求文档和开发文档的完善。
分布式链路追踪 SkyWalking 源码分析 —— DataCarrier 异步处理库
本文基于 SkyWalking 3.2.6 正式版，主要分享 SkyWalking Collector Remote 远程通信服务，用于 Collector 集群内部通信。Remote Module 应用于 SkyWalking 架构中，实现跨节点的流式处理。
本文从接口到实现顺序解析 SkyWalking Collector Remote 的项目结构和组件，包括 RemoteModule、RemoteSenderService、RemoteClientService、RemoteClient、CommonRemoteDataRegisterService、RemoteDataRegisterService、RemoteDataIDGetter、RemoteDataInstanceCreatorGetter、RemoteSerializeService、RemoteDeserializeService。RemoteModule 实现 Module 抽象类，定义服务如 RemoteSenderService、RemoteDataRegisterService，创建 RemoteClient 实现远程通信。CommonRemoteDataRegisterService 用于注册数据类型对应的远程数据创建器和获取数据协议编号。
接着，本文深入探讨基于 Google gRPC 的远程通信实现，包括 RemoteModuleGRPCProvider、GRPCRemoteSenderService、r语言欧式距离源码GRPCRemoteClientService、GRPCRemoteClient、RemoteCommonServiceHandler、GRPCRemoteSerializeService、GRPCRemoteDeserializeService。RemoteModuleGRPCProvider 提供基于 gRPC 的组件服务实现类，实现远程发送服务、客户端选择器和远程客户端服务。GRPCRemoteClient 实现基于 gRPC 的远程客户端，支持异步发送消息。
最后，本文提及 SkyWalking Collector Remote 也支持基于 Kafka 的远程通信实现，但目前暂未完成。为了进一步学习 SkyWalking 的分布式链路追踪和远程通信机制，读者可以关注公众号芋道源码，获取 Java 源码解析、原理讲解、面试题、学习指南，回复「书籍」领取 Java 从入门到架构的 本书籍，加入技术群讨论 Java、后端、架构相关技术。
博云违反 Apache 2.0 开源协议被要求整改，开源协议应如何遵守？
博云因在使用Apache SkyWalking时违反Apache License Version 2.0开源协议，被Apache基金会要求整改，提醒我们在享受开源便利的同时，需重视开源协议的遵守。开源协议旨在保护知识产权，如同软件作者与用户间的合同，不遵守将可能引发法律纠纷。企业使用开源软件时，务必理解协议内容，确保性能检测和知识产权风险的考量，并在产品发行、Notice文件和源码中明确标注开源许可。Apache License Version 2.0鼓励代码分享，但要求在修改后公开声明并保留原作者版权。在分发衍生作品时，务必注明版权归属并提供许可证拷贝。开源虽好，但合规使用至关重要，以避免潜在法律风险。SegmentFault思否社区推出开源项目支持计划，助力优质开源项目的传播和成长，共同构建开源新生态。
从分析 SkyAPM-dotnet 源码学习现代 APM 探针设计理念（一）
在后端软件行业的快速变迁中，从SOA到微服务、从业务一体化到中台战略、从虚拟化到云原生，技术更新速度日新月异。这种变革背后的核心动力在于硬件发展的瓶颈，促使行业转向追求软件的规模化效益。现代后端软件工程师面临的挑战之一是如何对服务性能有全面的理解，而APM（Application Performance Monitoring）工具成为了解决这一问题的关键。
APM的基本构成包括指标性统计、分布式追踪和日志记录。指标性统计，如服务的吞吐量、成功率、流量等，是对单个指标或数据库的分析。分布式追踪则关注一次请求的全过程，从客户端发起到服务完成，甚至涉及业务流程，如商品订购流程，追踪请求的流转轨迹。日志记录则是程序运行过程中产生的信息收集，提供实时的事件记录。
随着技术的发展，性能监控工具的使用变得越来越普遍。早期，开发人员可能需要自己构建监控系统，但这既耗时又费力。SkyWalking等APM系统应运而生，旨在简化性能监控的实现，减少重复工作。
在SkyWalking中，dotnet探针的设计遵循核心规范。dotnet探针主要基于DiagnosticSource实现，这提供了一种消息的生产者消费者模型，使得事件可以在任意地方被接收。微软官方库中，如HttpContext、HttpClient、SqlClient等，都预留了性能打点，以捕获关键事件。第三方库如gRPC、CAP、SmartSql也提供了同样的功能。
开发人员可以通过适配SkyWalking，为自己的库添加性能打点，即向DiagnosticSource发送事件信息。这涉及到创建自定义采集器，监听特定事件，并将数据发送到数据中心。
探针的核心代码在于监听消息，其关键在于DiagnosticListener，它实现了消息的监听与数据的上报。监听的事件由特定的Processor负责处理，这些Processor实现了ITracingDiagnosticProcessor接口，具体负责数据的收集与转换。
两个有代表性的Processor示例展示了如何实现这一过程。一个针对AspNetCore请求管线，监听并收集请求相关的事件；另一个是针对System.Net下的通用httpclient，同样监听特定事件，以构建完整的请求上下文，并生成标准的tracing信息。
通过安装SkyWalking并加入探针，后端服务的性能数据将被收集并上传至OAP平台进行分析，最终提供直观的APM信息。这一过程不仅简化了性能监控的实施，还极大地提高了数据分析的效率与准确性。建议读者亲自尝试安装SkyWalking，体验探针在实际服务中的应用。
线上环境OOM频发，MyBatis有坑...
线上服务频繁遭遇 OutOfMemoryError（OOM）问题，对业务造成了严重影响，一天内服务重启多达五次，导致整个系统几乎瘫痪。通过Skywalking追踪，发现链路调用大部分呈现红色，亟待解决。作为排查者，我接手了这个任务。
首先，我分析了OOM的常见原因，主要包括堆内存和元空间不足。在我们的案例中，Mybatis的问题浮出水面。源码分析显示，Mybatis在拼接SQL时，通过集合存储SQL和参数，当SQL参数过多导致SQL过长时，集合会变得庞大，回收不及时就会引发内存溢出。
由于环境限制，无法直接通过jstack、jmap工具定位问题，这增加了排查的难度。但在网络搜索中，我找到了一篇与DruidDataSource和Mybatis相关的问题，这让我找到了问题的线索，即多线程并发操作可能导致内存占用过高，从而触发OOM。
进一步的源码分析揭示，DynamicContext类中的ContextMap（继承自HashMap）在存储SQL参数和占位符时，存在无法被GC回收的问题。当并发查询量增加时，这可能导致内存溢出。我通过线上复现情景，验证了这一理论，发现服务频繁进行Full GC，最终引发了OOM。
针对问题，我提出解决方案：优化SQL拼接，避免过长的SQL体积，强调代码和SQL编写的重要性。同时，为了应对未来可能的故障，我配置了docker中的OOM保留dump文件，以备不时之需。
