首页 文章 精选 留言 我的

精选列表

搜索[全模态推理]，共10000篇文章
优秀的个人博客,低调大师

得物视频编辑工具优化全指南

一、背景介绍 随着4G网络的推广和网络带宽的提升，视频成为互联网用户主要的消费载体，用户通过短视频来分享和浏览信息。由此视频的编辑功能越来越重要、越来越普遍。视频编辑的App也如雨后春笋般涌现。 为更好地推动得物App社区业务的发展，得物也自研符合得物需求的视频编辑工具。我们致力于打造一个“更快、更强”的视频编辑工具。 二、视频编辑工具介绍 为了让大家更好地了解得物App的视频编辑工具，我们先简单介绍一下视频编辑工具的主要功能。 下面是得物App视频编辑工具的主要功能： 视频编辑工具的重点如下： 视频编辑工具需要操作的资源： 文字：包括普通的文字、特殊的艺术字、花字等等； 图片：包括静态图，如JPEG/PNG等等，也包括HEIC/GIF等动态图； 视频：包括各种各样的视频（各种编码和封装格式），主流的格式一般是MP4的封装格式、H264视频编码格式、AAC音频编码格式等等； 音频：包括各种各样的音频（各种编码和封装格式），当然视频当然也是包含音频轨道的。 视频编辑工具主要的操作方式： 操作图片、视频帧：我们知道视频是一帧一帧的图片组成的，所以操作视频帧和操作图片是一样的道理，我们通过添加一些特效在图片和视频帧上面，实现一些有趣的效果来吸引用户。 操作音频：主流的操作音频方式如倍速、调整音量、变调等等，都是现今短视频的主要玩法。 视频编辑工具最终生成的是一个新的视频，这个视频将特定的资源应用一些特效生成一个新的视频。 下面的流程图可以很方便地让大家了解视频编辑的工作流程。为了方便，我们输入一个视频，加上一些特效，生成一个新的视频。 从上面的流程可以看出来，原始视频A.mp4经过解封装分离出音频轨道和视频轨道，对它们解码之后，对音频数据应用音频特效、对视频帧数据应用视频特效，然后编码封装合成一个新的视频。当然解码和编码都是有一个队列控制的，流程图上标注了，没有深入展开，大家了解即可。 经过上面的介绍，大家对视频编辑工具有了大概得了解，其实衡量一个视频编辑工具做得好不好，主要从下面这几个方面着手： 内存占用情况 导出视频的速度如何 导出视频的清晰度如何 下面从这三方面详细展开给大家阐述得物App的视频编辑工具优化的心路历程。 三、内存优化 性能是所有程序好不好的首要指标，一个工具即使功能再强大，但是一点就崩溃，或者用着用着内存暴涨、应用卡死，估计这个应用不能称为一个优秀的应用，下面我们具体谈一谈视频编辑工具的优化检测方案。 优化内存从良好的编码习惯开始，尤其对音视频这种对内存需求非常高的应用而言。例如一个1080 * 1920的视频，解码出来原始数据一帧图片大小也是1080 * 1920，占用内存是1080 * 1920 * （8 * 3 ) / 8 = 5.93 MB，一个视频帧就占用这么大，1秒一般有30帧，那得占用177.9MB，如果不加控制，那不管多高性能的手机也经不住这样的折腾。希望下面的内存检测和优化方案可以给你带来一些帮助。 3.1 合理设计队列 上面我们在介绍视频编辑流程的视频谈到了解码队列和编码队列的概念。其实队列这个概念在音视频中使用非常频繁，正是因为内存的限制，所以才引入队列这个控制方式。大家可能还有点懵，但是看完下面的流程图，我相信你一定会豁然开朗。 我们仅选取解码的部分来分析一下队列的重要应用。 在视频编辑工具中有几个重要的队列： 解码过程中： Video Packet Queue：视频解码之前Packet存放的队列，一般建议的队列大小是100 Audio Packet Queue：音频解码之前Packet存放的队列，一般建议的队列大小是150 Video Frame Queue：视频解码之后Frame存放的队列，一般建议的队列大小是3 Audio Frame Queue：音频解码之后Frame存放的队列，一般建议的队列大小是8 编码过程中： Encode Video Packet Queue：视频编码之后Packet存放的队列，一般建议的大小是100 Encode Audio Packet Queue：音频编码之后的Packet存放的队列，一般建议的大小是150 按照上面的方式设计队列的大小，可以在保证功能正常的情况下最大程度的降低内存占用，提升用户体验。 3.2 排查内存泄漏 Android上排查内存泄漏的方式有很多，这里介绍两种： Asan检测 Profile检测 Asan全称是AddressSanitizer是一种基于编译器的快速检测的工具，用于检测原生代码中的内存错误问题，Asan可以解决如下四种核心问题： 堆栈和堆缓冲区上溢、下溢 释放之后堆重新使用问题 超过范围的堆栈使用情况 重复释放、错误释放问题 Asan的使用方式建议参考google官方文档，这儿就不多作介绍了： https://github.com/google/sanitizers/wiki/AddressSanitizer 关于Profile的使用，如果需要检测Native内存使用情况，需要满足API>=29，大家在使用的时候需要非常注意。 下面是我们在demo中应用Asan抓取的堆栈： 20042-20042/? A/DEBUG: *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** 20042-20042/? A/DEBUG: Build fingerprint: 'samsung/t2qzcx/t2q:11/RP1A.200720.012/G9960ZCU2AUGE:user/release-keys' 20042-20042/? A/DEBUG: Revision: '13' 20042-20042/? A/DEBUG: ABI: 'arm64' 20042-20042/? A/DEBUG: Timestamp: 2021-09-17 00:32:31+0800 20042-20042/? A/DEBUG: pid: 19946, tid: 20011, name: AudioTrack >>> com.jeffmony.audioplayer <<< 20042-20042/? A/DEBUG: uid: 10350 20042-20042/? A/DEBUG: signal 6 (SIGABRT), code -1 (SI_QUEUE), fault addr -------- 2021-09-17 00:32:31.157 20042-20042/? A/DEBUG: Abort message: '================================================================= ==19946==ERROR: AddressSanitizer: heap-use-after-free on address 0x004ac1e41080 at pc 0x007157f69580 bp 0x00705c0bb350 sp 0x00705c0bab08 READ of size 1792 at 0x004ac1e41080 thread T32 (AudioTrack) #0 0x7157f6957c (/data/app/~~G094WKQQj7KZvdhvGYDLDA==/com.jeffmony.audioplayer-kcu1nmgzpBIQDRJDxCJDOQ==/lib/arm64/libclang_rt.asan-aarch64-android.so+0x9f57c) #1 0x706549c228 (/data/app/~~G094WKQQj7KZvdhvGYDLDA==/com.jeffmony.audioplayer-kcu1nmgzpBIQDRJDxCJDOQ==/lib/arm64/libltpaudio.so+0x14228) #2 0x706549bcd4 (/data/app/~~G094WKQQj7KZvdhvGYDLDA==/com.jeffmony.audioplayer-kcu1nmgzpBIQDRJDxCJDOQ==/lib/arm64/libltpaudio.so+0x13cd4) #3 0x70654994f0 (/data/app/~~G094WKQQj7KZvdhvGYDLDA==/com.jeffmony.audioplayer-kcu1nmgzpBIQDRJDxCJDOQ==/lib/arm64/libltpaudio.so+0x114f0) #4 0x70654a9cbc (/data/app/~~G094WKQQj7KZvdhvGYDLDA==/com.jeffmony.audioplayer-kcu1nmgzpBIQDRJDxCJDOQ==/lib/arm64/libltpaudio.so+0x21cbc) #5 0x70654a91d4 (/data/app/~~G094WKQQj7KZvdhvGYDLDA==/com.jeffmony.audioplayer-kcu1nmgzpBIQDRJDxCJDOQ==/lib/arm64/libltpaudio.so+0x211d4) #6 0x715af9d188 (/system/lib64/libwilhelm.so+0x1c188) #7 0x71570ea290 (/system/lib64/libaudioclient.so+0x8b290) #8 0x71570e9480 (/system/lib64/libaudioclient.so+0x8a480) #9 0x7156b664d4 (/system/lib64/libutils.so+0x154d4) #10 0x71593e9974 (/system/lib64/libandroid_runtime.so+0xa5974) #11 0x7156b65db0 (/system/lib64/libutils.so+0x14db0) #12 0x7156ace234 (/apex/com.android.runtime/lib64/bionic/libc.so+0xb6234) #13 0x7156a68e64 (/apex/com.android.runtime/lib64/bionic/libc.so+0x50e64) 0x004ac1e41080 is located 0 bytes inside of 1792-byte region [0x004ac1e41080,0x004ac1e41780) freed by thread T32 (AudioTrack) here: #0 0x7157f74c64 (/data/app/~~G094WKQQj7KZvdhvGYDLDA==/com.jeffmony.audioplayer-kcu1nmgzpBIQDRJDxCJDOQ==/lib/arm64/libclang_rt.asan-aarch64-android.so+0xaac64) #1 0x70654a6d2c (/data/app/~~G094WKQQj7KZvdhvGYDLDA==/com.jeffmony.audioplayer-kcu1nmgzpBIQDRJDxCJDOQ==/lib/arm64/libltpaudio.so+0x1ed2c) #2 0x70654a6af0 (/data/app/~~G094WKQQj7KZvdhvGYDLDA==/com.jeffmony.audioplayer-kcu1nmgzpBIQDRJDxCJDOQ==/lib/arm64/libltpaudio.so+0x1eaf0) #3 0x706549bf4c (/data/app/~~G094WKQQj7KZvdhvGYDLDA==/com.jeffmony.audioplayer-kcu1nmgzpBIQDRJDxCJDOQ==/lib/arm64/libltpaudio.so+0x13f4c) #4 0x706549bcd4 (/data/app/~~G094WKQQj7KZvdhvGYDLDA==/com.jeffmony.audioplayer-kcu1nmgzpBIQDRJDxCJDOQ==/lib/arm64/libltpaudio.so+0x13cd4) #5 0x70654994f0 (/data/app/~~G094WKQQj7KZvdhvGYDLDA==/com.jeffmony.audioplayer-kcu1nmgzpBIQDRJDxCJDOQ==/lib/arm64/libltpaudio.so+0x114f0) #6 0x70654a9cbc (/data/app/~~G094WKQQj7KZvdhvGYDLDA==/com.jeffmony.audioplayer-kcu1nmgzpBIQDRJDxCJDOQ==/lib/arm64/libltpaudio.so+0x21cbc) #7 0x70654a91d4 (/data/app/~~G094WKQQj7KZvdhvGYDLDA==/com.jeffmony.audioplayer-kcu1nmgzpBIQDRJDxCJDOQ==/lib/arm64/libltpaudio.so+0x211d4) #8 0x715af9d188 (/system/lib64/libwilhelm.so+0x1c188) #9 0x71570ea290 (/system/lib64/libaudioclient.so+0x8b290) 显示message是：heap-use-after-free on address 0x004ac1e41080 说明是使用了已经释放掉的内存了，再继续看，这个内存具体在什么地方被释放的？0x004ac1e41080 is located 0 bytes inside of 1792-byte region [0x004ac1e41080,0x004ac1e41780) Asan一个很大的优势就是可以追踪内存释放的路径，防止出现内存泄漏和野指针问题，特别是野指针，一旦出现特别难排查，简直是C++开发的噩梦，希望大家用好工具，同时培养良好的C++编码习惯。 3.3 优化线程 另一个影响内存的重要因素是线程，视频编辑工具涉及到的线程非常多，线程的使用得遵循一些基本的原则： 尽量少创建线程 尽量少使用pthread_mutex_t 本着功能隔绝原则使用线程 能同步就别异步 以编辑模块为例，这儿列一下我们使用到的所有线程： GL处理线程 视频解封装线程 视频中视频轨道解码线程 视频音频轨道解码线程 抽取缩略图线程 音频编码线程 视频编码线程 视频封装线程 如果插入了独立的音频文件，还需要添加两个额外的线程： 音乐文件播放线程 音乐文件解码线程 上面列出的是一个视频编辑工具能正常工作所必备的最少线程，如果你的视频编辑工具中多了什么线程，我们建议可以适当优化一下，毕竟少一个线程，可以少一分开销，而且少一分线程同步的工作。 我们在底层也按照Android的消息机制重写了一套C++层的消息分发SDK，这个我们后续会另外分享文章阐释我们定制的消息分发SDK，这儿点到为止。 四、提升导出视频的速度 我们使用视频编辑工具，最终是希望导出一个视频，如果这个导出的过程很慢，那肯定是无法忍受的，从上面的介绍我们已知视频的导出需要经过“解码——应用特效——编码”的过程，其中解码和编码这两个过程对速度的影响至关重要。因为解码和编码视频需要耗费大量的资源，目前主要有两种方式——“软解/编码”和“硬解/编码”。 如果你使用过FFmpeg或者其他使用CPU进行视频编解码的来处理视频的话，你可能已经遇到了处理速度慢的问题。这主要是因为软编码和软解码使用CPU进行运算，而CPU在处理视频上的速度远低于DSP芯片；简而言之“软解/编码”主要通过CPU来工作，通过CPU来主导大量的计算工作，是原始的处理方式，当然耗费的时间也比较长；“硬解/编码”是通过GPU来处理，GPU是专用的图形处理芯片，对视频的解码和编码有专门的优化，所以编码和解码的速度非常快。 Android上使用MediaCodec来实现“硬解/编码”，iOS上使用VideoToolBox来实现“硬解/编码”，这里着重介绍Android上编码解码的速度优化。 从上面的流程我们可以看出，编码在解码的后面，一个时长60s（30fps）的视频，需要解码1800帧，然后编码1800帧视频才能完整生成另外一个视频，这样串行的等待是耗时的主要原因。 这时候我们参考多线程方案，将一个60s的视频均分为两段，然后这两段视频同时进行解码操作，生成导出了两个30s的临时缓存视频文件，随后将这两个30s的视频合并为一个60s的B.mp4视频，最后删除临时缓存文件，这样我们只需要同时处理900帧的数据，理论上可以提升一倍的导出速度。 这就是并行导出，下面是得物App并行导出的基本流程。 首先我们要明确导出视频是需要消耗资源的，这个资源就是MediaCodec，最终是送入到GPU中处理，一个手机中的MediaCodec实例是有限的，正常情况下，一个手机可以提供的MediaCodec实例最多有16个，如果当前使用的MediaCodec实例超过16个，那么手机将无法正常工作。MediaCodec资源是手机中的所有App共同持有。所以并行分段的个数不是越多越好。 只有一段，需要两个MediaCodec（一个用来解码视频，一个用来编码视频），注意：音频的解码和编码可以不要用MediaCodec，毕竟音频的耗时少多了，不是瓶颈。 分成两段需要四个MediaCodec，分成三段需要六个MediaCodec，分成四段需要八个MediaCodec，以此类推。 下面是并行导出的测试结果： 两段并行速度提升50% ~ 70%，内存增加20%， 三段并行速度提升60% ~ 90%，内存增加80%；并行超过三段的话就无法明显提升速度了。我们比较建议并行两段，在一些性能很好的机型上并行三段。 如果有些同学对视频导出过程中文件操作还有疑问的，下面的示意图可以比较清楚地看出并行导出操作本地文件的过程： 并行导出的过程中，生成了两个临时文件 并行导出完成后，这两个临时文件合并为一个新的文件，两个临时生成的文件被删除了（节省用户宝贵的存储空间） 原始文件jeffmony_out.mp4并没有被删除/修改 Tips：目前我们在处理过程中生成的临时文件和最终的适配文件都会保存在/sdcard/Pictures/duapp/Compile/下，而在处理完成后的临时文件清理过程会触发在某些机型上的保护机制，建议后续调整到App的私有目录下。 当然还有其他的提升导出速度的建议，例如在视频帧特效处理的过程中，我们建议： 尽量采用FBO/EBO/ABO方式处理texture 纹理如果过大要进行压缩 严禁采用glFinish() 这些做法都是我们在视频编辑开发过程中的切实经验，希望能给大家带来一些帮助。 五、提升导出视频的清晰度 一个视频编辑功能是否足够优秀，其中的一个重要指标就是同等条件下导出的视频是否足够清楚，通常而言，衡量视频是否清晰的有两种方式： 主观标准：找一些用户观看不同的视频，根据用户的观感输出视频清晰度的对比结果，用户一般根据色彩、画面亮度、柔和度等来评估清晰度。 客观标准：利用算法计算视频画面质量分，目前比较推荐Netflix推出的开源库VMAF来计算视频帧的质量分。 实际上主观标准是比较准确的，但是可操作性比较差，特别是处理海量视频的时候，需要大量的人力，无法有效开展，因此日常工作中还是推荐客观标准进行海量计算，主观标准进行重点判断。具体的可以结合业务的重要程度来开展。 下面结合我们实际的工作给出具体提升视频清晰度的方式： 视频基础编码信息优化 Profile优化：Profile有三种Level，分别是Baseline、Main、High，其中Baseline Profile对应清晰度最低，Android 3.0之后的版本都支持的，Main Profile清晰度比Baseline Profile清晰度要好，但是从Android 7.0之后才支持，High Profile清晰度最高，也是从Android 7.0之后才支持。我们在设置Encoder Profile Level之前，需要判断一下当前是否支持。 Bitrate码率设置： 视频码率是视频数据传输时单位时间内传送的数据位数。单位是kbps，望文生义，码率越大，单位时间填充的数据就越多，视频质量就越高。但码率也不是设置的越大越好，超过必要限度，对视频画质的提升已不明显，建议采用合适的factor来调整码率。Bitrate = width * height * frameRate * factor，其中factor=0.15。 Bitrate Mode： 有三种通过的编码模式——VBR（可变码率）、CBR（固定码率）、ABR（平均码率），其中ABR是最好的方式，可以兼顾质量和视频大小。 B帧设置： 视频有I帧、P帧、B帧构成，其中I帧最大，P帧次之，B帧最小，我们在编码时尽量多设置B帧（在合理的范围内），并不会降低清晰度，但是可以大大降低视频的大小，这样我们就可以相应地调大码率，最终实现了提升清晰度的目标。 HEVC编码优化： 使用HEVC编码，可以保证在不增加文件大小的情况下，大大提升视频的清晰度。在相同的图像质量下，HEVC编码的视频比H.264编码的视频约减少40% 色彩调优 综合调整亮度、对比度、色温、饱和度、锐度等颜色参数，进而优化整体的视频画面，让视频画面看上去“更清晰”。 **超分算法 **： 采用ESRGAN算法，利用机器学习的优势对图片和视频进行去模糊、Resize、降噪、锐化等处理，重建图片，实现对图片的超分辨率处理。 特征提取：计算噪点 非线性映射：放大，模糊化噪点 图像重建：差分，平滑过度，去噪 下面是使用超分算法处理前后的对比图，可以很明显地看出右边的图更加清晰，少了很多噪点、图片更亮、过度更平滑。 如果大家想了解视频清晰度优化的技术细节，可以参考文章--视频清晰度优化指南 六、总结 本文开篇从介绍得物App的主要功能展开，提出了视频编辑工具优化的三个维度： 优化内存占用 提升视频导出速度 提升导出视频的清晰度 其中在“提升视频导出速度”时重点谈到了“并行导出”的技术方案，从最终的结果来看，视频导出速度的提升非常明显，同时也非常清楚地解释了“并行导出”过程中为什么生成临时文件？为什么有必要在导出完成之后删除临时文件？尽力给用户带来较好的体验。 最后在“提升导出视频的清晰度”中重点提到的超分算法应用效果提升明显，超分之后的视频帧相比原帧图更加清晰、噪点更少，而且细节部分更加真实。 后续我们还会结合AR特效输出更多有意义的技术分享，敬请期待。 *文 /JeffMony 关注得物技术，每周一三五晚18:30更新技术干货 要是觉得文章对你有帮助的话，欢迎评论转发点赞～
2022-11-29
优秀的个人博客,低调大师

Hanami 2.0 发布，全栈 Ruby Web 框架

经过三年多的努力，Hanami 2.0 正式发布，随着这个版本的发布，Hanami 进入了框架成熟的新阶段，并为 Ruby 社区开启了新的篇章。 更好 Hanami 2.0 的核心是现在的 app/ 目录，在这里，你可以随心所欲地组织你的代码，同时还可以享受常见组件的合理默认值。随着你的应用程序的增长，你可以利用切片的优势，将你的代码分成若干域。 Hanami 2.0 提供了一个既简单又强大的框架： 新的应用程序核心提供了以容器和组件为中心的高级代码加载功能 代码自动加载帮助你以最小的代价工作 新的内置切片随着你的应用程序的增长而逐渐提供模块化。 一个始终存在的依赖关系混合器帮助你在你的应用程序的组件之间建立更清晰的联系 重新设计的 action 类与你的应用程序的业务逻辑无缝集成 带有 dotenv 集成的类型安全的应用程序设置，确保你的应用程序在每个环境中都有它所需要的东西。 新的供应商管理你的应用程序的关键组件和集成的生命周期 自上而下的模块化使您能够构建各种类型的应用程序，包括非 Web 应用程序 我们重写的入门指南可以帮助你开始使用上述所有内容 更快 Hanami 2.0 完全重写了 HTTP 路由引擎，基准显示它超过了几乎所有其他引擎。 当在开发中使用 Hanami 时，由于我们的智能代码加载，你的应用程序将立即启动和重新加载。无论你的应用程序有多大，你的控制台将在几毫秒内加载，你的测试将保持快速。 更多详情可查看：https://hanamirb.org/blog/2022/11/22/announcing-hanami-200/
2022-11-23
优秀的个人博客,低调大师

微服务电商项目技术全解析

一、项目介绍 7d-mall-microservice是一套微服务电商，其是在开源电商项目 mall-swarm 上进行了改造，采用了 Spring Cloud Hoxton & Alibaba、Spring Boot 2.3、Oauth2、MyBatis、Docker、k8s、Elasticsearch 等核心技术。7d-mall-microservice在电商业务的基础集成了注册中心、配置中心、监控中心、网关等系统功能。。 项目地址：https://github.com/xncssj/7d-mall-microservice 二、整体结构 系统架构： 工程组织结构： 7d-mall├──mall-common--工具类及通用代码模块├──mall-mbg--MyBatisGenerator生成的数据库操作代码模块├──mall-auth--基于SpringSecurityOauth2的统一的认证中心├──mall-gateway--基于SpringCloudGateway的微服务API网关服务├──mall-monitor--基于SpringBootAdmin的微服务监控中心├──mall-member--会员系统服务├──mall-order--订单系统服务├──mall-cart--购物车系统服务├──mall-admin--后台管理系统服务├──mall-search--基于Elasticsearch的商品搜索系统服务├──mall-portal--商城后台系统服务├──mall-demo--微服务远程调用测试服务└──config--配置中心存储的配置 主要技术栈： 技术 说明 官网 Spring Cloud 微服务框架 https://spring.io/projects/spring-cloud Spring Cloud Alibaba 微服务框架 https://github.com/alibaba/spring-cloud-alibaba Spring Boot 容器+MVC框架 https://spring.io/projects/spring-boot Spring Security Oauth2 认证和授权框架 https://spring.io/projects/spring-security-oauth MyBatis ORM框架 http://www.mybatis.org/mybatis-3/zh/index.html MyBatisGenerator 数据层代码生成 http://www.mybatis.org/generator/index.html PageHelper MyBatis物理分页插件 http://git.oschina.net/free/Mybatis_PageHelper Knife4j 文档生产工具 https://github.com/xiaoymin/swagger-bootstrap-ui Elasticsearch 搜索引擎 https://github.com/elastic/elasticsearch RabbitMq 消息队列 https://www.rabbitmq.com/ Redis 分布式缓存 https://redis.io/ MongoDb NoSql数据库 https://www.mongodb.com/ Docker 应用容器引擎 https://www.docker.com/ Druid 数据库连接池 https://github.com/alibaba/druid OSS 对象存储 https://github.com/aliyun/aliyun-oss-java-sdk MinIO 对象存储 https://github.com/minio/minio JWT JWT登录支持 https://github.com/jwtk/jjwt LogStash 日志收集 https://github.com/logstash/logstash-logback-encoder Lombok 简化对象封装工具 https://github.com/rzwitserloot/lombok Seata 全局事务管理框架 https://github.com/seata/seata Kubernetes 应用容器管理平台 https://kubernetes.io/ Sentinel 服务保护 https://sentinelguard.io/zh-cn/ SkyWalking 分布式追踪、服务网格遥测分析、度量聚合和可视化一体化解决方案 http://skywalking.apache.org 三、预备知识 1、什么是 SpringCloud ？ 构建分布式系统是复杂的，SpringCloud 对常见的分布式系统模式提供了简单易用的编程模型，帮助开发者构建弹性、可靠、协调的应用程序。SpringCloud 是在 SpringBoot 的基础上构建的，使开发者可以轻松入门并快速提高工作效率。SpringCloud 为开发人员提供了快速构建分布式系统架构的工具，例如配置管理，服务发现，断路器，智能路由，微代理，控制总线，一次性令牌，全局锁定，领导选举，分布式会话，集群状态等。 2、Spring 、SpringBoot 和 Spring Cloud 的关系 Spring 两大核心功能Ioc和Aop成就了 Spring，Spring 在这两大核心的功能上不断的发展，才有了 Spring 事务、Spring Mvc 等一系列伟大的产品，最终成就了 Spring 帝国，到了后期 Spring 几乎可以解决企业开发中的所有问题。 SpringBoot 是在强大的 Spring 帝国生态基础上面发展而来，发明 Spring Boot 不是为了取代 Spring ,是为了让人们更容易的使用 Spring 。所以说没有 Spring 强大的功能和生态，就不会有现在的 SpringBoot 火热, SpringBoot 使用约定优于配置的理念，重新重构了 Spring 的使用，让 Spring 后续的发展更有生命力。 Spring Cloud 是一系列框架的有序集合。它利用 SpringBoot 的开发便利性巧妙地简化了分布式系统基础设施的开发，如服务发现注册、配置中心、消息总线、负载均衡、断路器、数据监控等，都可以用 SpringBoot 的开发风格做到一键启动和部署。 Spring 并没有重复制造轮子，它只是将目前各家公司开发的比较成熟、经得起实际考验的服务框架组合起来，通过 SpringBoot 风格进行再封装屏蔽掉了复杂的配置和实现原理，最终给开发者留出了一套简单易懂、易部署和易维护的分布式系统开发工具包。 Spring Cloud 是为了解决微服务架构中服务治理而提供的一系列功能的开发框架，并且 Spring Cloud 是完全基于 SpringBoot 而开发，Spring Cloud 利用 SpringBoot 特性整合了开源行业中优秀的组件，整体对外提供了一套在微服务架构中服务治理的解决方案。 来自官网 综上所述，正是由于Spring Ioc和Spring Aop两个强大的功能才有了 Spring ，Spring 生态不断的发展才有了 SpringBoot ，使用 SpringBoot 让 Spring 更易用更灵活，Spring Cloud 是基于 SpringBoot 开发的一套微服务架构下的服务治理方案。 用一个简单的包含关系来表达它们之间的关系。 3、Spring Cloud Alibaba 和 Spring Cloud 的关系 在这几年 Netfilix Eureka 为代表的 SpringCloud 核心中间件纷纷停止更新，再加上许多组件设计老旧，在性能上已无法满足国内大厂的要求，我们迫切需要一套符合中国特色的微服务架构解决方案。 Spring Cloud Alibaba 就是在这种背景下诞生的，Spring Cloud Alibaba 是国产的微服务开发一站式解决方案，与原有 Spring Cloud 兼容的同时对微服务生态进行扩展，通过添加少量的配置注解，便可实现更符合国情的微服务架构。 Spring Cloud Alibaba 技术架构 相比 Spring Cloud，Spring Cloud Alibaba 提供了更完整的功能、更好用的 API，同时在中文的加持下让复杂的微服务架构变得不再高不可攀，目前 Spring Cloud Alibaba 已经是事实上的国内微服务技术标准。 下面是 Spring Cloud 与 Spring Cloud Alibaba 的对比表格： Spring Cloud 与 Spring Cloud Alibaba 的对比 将两者从不同维度进行比对，可以发现 Spring Cloud Alibaba 对服务注册、配置中心与负载均衡功能都整合进 Nacos，这样简化了微服务架构的复杂度，出问题的概率也会降低。原有的服务保护组件也调整为 Sentinel，功能更强大，使用也更加友好。最下方高亮处也可看到 Spring Cloud Alibaba 基于阿里云强大的能力提供了更多的商业组件，很多复杂的应用场景通过 结合阿里云便可实现。 四、核心组件介绍 1、Spring Cloud Alibaba：Nacos 注册和配置中心 注册中心是微服务架构最核心的组件。它起到新服务节点的注册与状态维护的作用。微服务节点在启动时会将自身的服务名称、IP、端口等信息在注册中心中进行登记，注册中心会定时检查该节点的运行状态。注册中心通常会采用心跳机制最大程度保证其持有的服务节点列表都是可用的。 现在微服务开发的主流技术是基于 Spring Boot 进行的，我们都知道 Spring Boot 默认配置文件为 application.yml 或者 application.properties。它保存了应用的主要配置信息，这些配置文件会随着应用发布被打包放入 Jar 文件，随着应用加载并运行。当我们的应用只有几个微服务时这些配置文件分散的存放在各个 Jar 中还没有问题。但是如果我们开发了大型应用，涉及几十个研发团队、上百台服务器、上千个服务实例时，运维团队就要面对因为数量级增加带来的挑战了，必须额外的引入“配置中心”这一组件。 配置中心的职责就是集中管理微服务架构中每一个服务实例的配置数据。当微服务架构引入配置中心后，微服务应用只需持有应用启动的最小化配置，在应用启动时微服务应用所需的其他配置数据，诸如数据库连接字符串、各种用户名密码、IP 等信息均从配置中心远程下载，不再本地保存。 Nacos 官方地址为：https://nacos.io/zh-cn/index.html Nacos 阿里开源，官方定义为：一个更易于构建云原生应用的动态服务发现、配置管理和服务管理平台。 官方定义 关键特性： 一图看懂 Nacos： 一图看懂 Nacos 因为官网有完整的功能介绍，这里不再赘述。 2、Spring Cloud Ribbon：服务负载均衡 通常在微服务彼此调用时并不是直接通过 IP、端口直接访问，而是首先通过服务名在注册中心查询该服务拥有哪些可用节点，然后注册中心将可用节点列表返回给服务调用者，这个过程称为“服务发现”。因服务高可用的要求，服务调用者会接收到多个可用节点，必须要从中进行选择，因此在服务调用者一端必须内置负载均衡器，通过负载均衡策略选择适合的节点发起实质的通信请求。 Netfilx Ribbon 是 Netflix 公司开源的一个负载均衡组件，是属于客户端负载均衡器。目前 Ribbon 已被 Spring Cloud 官方技术生态整合，运行时以 SDK 形式内嵌到每一个微服务实例中，为微服务间通信提供负载均衡与高可用支持。 官网地址：https://github.com/Netflix/ribbon 关键特性： 负载均衡 容错 异步响应模型中支持多个协议(HTTP、TCP、UDP) 缓存和批处理 一般会使用 Feign 调用，并在消费者服务加上 Ribbon 负载均衡，配合 Nacos 手动可以调节权重，为了更容易理解，我们通过图说明 Ribbon 的执行流程： Ribbon 的执行流程 3、Spring Cloud Fegin：服务通信 Netflix Feign 是 Netflix 设计的开源的声明式 WebService 客户端，用于简化服务间通信。Netflix Feign 采用“接口+注解”的方式开发，通过模仿 RPC 的客户端与服务器模式（CS），采用接口方式开发来屏蔽网络通信的细节。官网地址：https://github.com/OpenFeign/feign 这是一张由 feign 提供的当前主要功能的地图： 功能地图 Spring Cloud OpenFeign 底层是基于 Netflix Feign，在其基础上进行封装，结合原有 Spring MVC 的注解，对 Spring Cloud 微服务通信提供了良好的支持。使用 OpenFeign 开发的方式与开发 Spring MVC Controller 颇为相似。OpenFeign 技术大幅简化了服务间高可用通信处理过程。 入门教程：https://spring.io/projects/spring-cloud-openfeign 特征：声明式 REST 客户端：Feign 创建一个用 JAX-RS 或 Spring MVC 注释修饰的接口的动态实现。 示例代码如下： @SpringBootApplication@EnableFeignClientspublicclassWebApplication{publicstaticvoidmain(String[]args){SpringApplication.run(WebApplication.class,args);}@FeignClient("name")staticinterfaceNameService{@RequestMapping("/")publicStringgetName();}} 4、Spring Cloud Gateway：服务网关 Spring Cloud Gateway 是 Spring 自己开发的新一代 API 网关产品。它基于 NIO 异步处理，摒弃了 Zuul 基于 Servlet 同步通信的设计，因此拥有更好的性能。同时，Spring Cloud Gateway 对配置进行了进一步精简，比 Zuul 更加简单实用。 官网地址：https://github.com/spring-cloud/spring-cloud-gateway 以下是 Spring Cloud Gateway 的关键特征： 基于 JDK 8+ 开发； 基于 Spring Framework 5 + Project Reactor + Spring Boot 2.0 构建； 支持动态路由，能够匹配任何请求属性上的路由； 支持基于 HTTP 请求的路由匹配（Path、Method、Header、Host 等）； 过滤器可以修改 HTTP 请求和 HTTP 响应（增加/修改 Header、增加/修改请求参数、改写请求 Path 等等）； ... 当下 Spring Cloud Gateway 已然是 Spring Cloud 体系上 API 网关标准组件。Spring Cloud Gateway 十分优秀，Spring Cloud Alibaba 也默认选用该组件作为网关产品。 Spring Cloud Gateway 的执行流程： 执行流程 按执行顺序可以拆解以下几步： Gateway Client：发起请求 Gateway Handler Mapping：确定请求与路由匹配 Gateway Web Handler： 处理请求并经过一系列的Filter链 在Filter链中，通过虚线分割 Pre Filter 和 Post Filter。所有的 Pre 类型的 Filter 执行完毕之后，才会转发请求到被代理的服务处理。被代理的服务把所有请求完毕之后，才会执行 Post 类型的过滤器 5、自建ELFK：集中式日志管理 微服务架构默认将应用日志分散保存在每一个微服务节点上，当系统进行用户行为分析、数据统计时必须收集所有节点日志数据。那如何有效收集所有节点的运行日志，并对其进行分析汇总呢？业内常见的方案有 ELK、EFK，通过搭建独立的日志收集系统，定时抓取增量日志形成有效的统计报表，为决策提供数据支撑。 ELK 即 Elasticsearch、Logstash、Kibana，组合起来可以搭建线上日志系统，本文主要讲解使用 ELK 来收集测试框架产生的日志。 ELK 中各个服务的作用： ELK 中各个服务的作用 Elasticsearch：用于存储收集到的日志信息； Logstash：用于收集日志，测试框架应用整合了 Logstash 以后会把日志发送给 Logstash,Logstash再把日志转发给Elasticsearch； Kibana：通过Web端的可视化界面来查看日志。 6、SkyWalking：分布式链路追踪 一个复杂的业务流程可能需要连续调用多个微服务，我们需要记录一个完整业务逻辑涉及的每一个微服务的运行状态，再通过可视化链路图展现，帮助软件工程师在系统出错时分析解决问题。 随着微服务体系的不断完善，链路追踪已经不是什么新兴的概念与技术，很多厂商也提供了自己的链路追踪产品，例如 Spring Cloud Slueth、Zipkin、阿里鹰眼、大众点评 Cat、SkyWalking 等。但这些产品都有一个共同的名字：APM（Application Performance Management），即应用性能管理系统。 顾名思义这些产品的根本目的就是对应用程序单点性能与整个分布式应用进行监控，记录每一个环节程序执行状况，通过图表与报表的形式让运维人员随时掌握系统的运行状况，其中在这些著名的产品中我非常推荐各位掌握 SkyWalking 这款 APM 产品，理由很简单，它在简单易用的前提下实现了比 Zipkin 功能更强大的链路追踪、同时拥有更加友好、更详细的监控项，并能自动生成可视化图表。相比 Sleuth+Zipkin 这种不同厂商间混搭组合，SkyWalking 更符合国内软件业的“一站式解决方案”的设计理念，下面咱们来了解下 SKyWalking。 SkyWalking 是分布式系统的应用程序性能监视工具，专为微服务、云原生架构和基于容器（Docker、K8s、Mesos）架构而设计。提供分布式追踪、服务网格遥测分析、度量聚合和可视化一体化解决方案。 官网地址：http://skywalking.apache.org/ 关键特性： 多种监控手段，语言探针和 Service Mesh 多语言自动探针，Java，.NET Core和Node.JS 轻量高效，不需要大数据 模块化，UI、存储、集群管理多种机制可选 支持告警 优秀的可视化方案 整体结构：整个架构，分成上、下、左、右四部分： 考虑到让描述更简单，我们舍弃掉 Metric 指标相关，而着重在 Tracing 链路相关功能。 上部分 Agent ：负责从应用中，收集链路信息，发送给 SkyWalking OAP 服务器。目前支持 SkyWalking、Zikpin、Jaeger 等提供的 Tracing 数据信息。而我们目前采用的是，SkyWalking Agent 收集SkyWalking Tracing数据，传递给服务器。 下部分SkyWalking OAP：负责接收 Agent 发送的 Tracing 数据信息，然后进行分析(Analysis Core) ，存储到外部存储器( Storage )，最终提供查询( Query)功能。 右部分 Storage ：Tracing 数据存储。目前支持 ES、MySQL、Sharding Sphere、TiDB、H2 多种存储器。而我们目前采用的是 ES ，主要考虑是 SkyWalking 开发团队自己的生产环境采用 ES 为主。 左部分SkyWalking UI：负责提供控台，查看链路等等 简单概况原理为下图： 为了能够让各位有个直观认识，我们通过表格对比，看不同产品的优劣。 对比项 CAT Sleuth+Zipkin Pinpoint Skywalking 调用链可视化 有 有 有 有 报表 非常丰富 少 中 中 ServerMap 简单依赖图 简单 好 好 埋点方式 侵入 侵入 不侵入字节码增强 不侵入字节码增强 性能损耗 高 高 高 低 Hearbeat支持 有 无 有 有 Metric支持 有 无 无 有 Java/.Net支持 有 有 只有Java 有 Dashboard中文支持 好 无 无 好 社区支持 好，文档较丰富，作者在携程点评 好，文档一般，暂无中文社区 一般，文档缺，无中文社区 好，文档丰富，中文社区活跃 调国内案例 携程、点评、陆金所 京东、阿里不开源 华为、小米、当当等 很多 源头祖先 eBayCAL~Centralized Application Logging Google Dapper Google Dapper Google Dapper 7、Spring Cloud Alibaba：Sentinel 服务保护 在服务间通信过程中，如果某个微服务出现响应高延迟可能会导致线程池满载，严重时会引起系统崩溃。这里就需要引入服务保护组件实现高延迟服务的快速降级，避免系统崩溃。 在 Spring Cloud Alibaba 生态中有一个重要的流控组件 Sentinel。Sentinel 以流量为切入点，从流量控制、熔断降级、系统负载保护等多个维度保护服务的稳定性。 Sentinel 服务保护 官网地址：https://sentinelguard.io/zh-cn/ Sentinel 具有以下特征: 丰富的应用场景：Sentinel 承接了阿里巴巴近 10 年的双十一大促流量的核心场景，例如秒杀（即突发流量控制在系统容量可以承受的范围）、消息削峰填谷、集群流量控制、实时熔断下游不可用应用等。 完备的实时监控：Sentinel 同时提供实时的监控功能。您可以在控制台中看到接入应用的单台机器秒级数据，甚至 500 台以下规模的集群的汇总运行情况。 广泛的开源生态：Sentinel 提供开箱即用的与其它开源框架/库的整合模块，例如与 Spring Cloud、Dubbo、gRPC 的整合。您只需要引入相应的依赖并进行简单的配置即可快速地接入 Sentinel。 完善的 SPI 扩展点：Sentinel 提供简单易用、完善的 SPI 扩展接口。您可以通过实现扩展接口来快速地定制逻辑。例如定制规则管理、适配动态数据源等。 Sentinel 的主要特性： Sentinel 的主要特性 Sentinel 的开源生态： Sentinel 的开源生态 Sentinel 分为两个部分: 核心库（Java 客户端）不依赖任何框架/库，能够运行于所有 Java 运行时环境，同时对 Dubbo / Spring Cloud 等框架也有较好的支持。 控制台（Dashboard）基于 Spring Boot 开发，打包后可以直接运行，不需要额外的 Tomcat 等应用容器。 控制台 Sentinel 工作主流程：在 Sentinel 里面，所有的资源都对应一个资源名称以及一个 Entry。Entry 可以通过对主流框架的适配自动创建，也可以通过注解的方式或调用 API 显式创建；每一个 Entry 创建的时候，同时也会创建一系列功能插槽（slot chain）。 这些插槽有不同的职责，例如: NodeSelectorSlot 负责收集资源的路径，并将这些资源的调用路径，以树状结构存储起来，用于根据调用路径来限流降级ee； ClusterBuilderSlot 则用于存储资源的统计信息以及调用者信息，例如该资源的 RT, QPS, thread count 等等，这些信息将用作为多维度限流，降级的依据； StatisticSlot 则用于记录、统计不同纬度的 runtime 指标监控信息； FlowSlot 则用于根据预设的限流规则以及前面 slot 统计的状态，来进行流量控制； AuthoritySlot 则根据配置的黑白名单和调用来源信息，来做黑白名单控制； DegradeSlot 则通过统计信息以及预设的规则，来做熔断降级； SystemSlot 则通过系统的状态，例如 load1 等，来控制总的入口流量； 总体的框架如下: 总体的框架 因为官网有完整的功能介绍，这里不再赘述。 8、消息队列：RabbitMQ 消息队列（Message Queue）简称 MQ，是一种跨进程的通信机制，通常用于应用程序间进行数据的异步传输，MQ 产品在架构中通常也被叫作“消息中间件”。它的最主要职责就是保证服务间进行可靠的数据传输，同时实现服务间的解耦。 在架构领域，很多厂商都开发了自己的 MQ 产品，最具代表性的开源产品有： Kafka AtiveMQ ZeroMQ RabbitMQ RocketMQ 每一种产品都有自己不同的设计与实现原理，但根本的目标都是相同的：为进程间通信提供可靠的异步传输机制。RabbitMQ 是最受欢迎的开源消息中间件之一，在全球范围内被广泛应用。RabbitMQ 是轻量级且易于部署的，能支持多种消息协议。RabbitMQ 可以部署在分布式系统中，以满足大规模、高可用的要求。 官网地址：https://www.rabbitmq.com/ 提供的功能： 提供的功能 核心特性： 可靠性：RabbitMQ 使用一些机制来保证可靠性，如持久化、传输确认、发布确认 灵活的路由：在消息进入队列之前，通过 Exchange 来路由消息的。对于典型的路由功能，RabbitMQ 已经提供了一些内置的 Exchange 来实现。针对更复杂的路由功能，可以将多个 Exchange 绑定在一起，也通过插件机制实现自己的 Exchange 消息集群：多个 RabbitMQ 服务器可以组成一个集群，形成一个逻辑 Broker 高可用：队列可以在集群中的机器上进行镜像，使得在部分节点出问题的情况下队列仍然可用 多种协议：RabbitMQ 支持多种消息队列协议，比如 STOMP、MQTT 等等 多语言客户端：RabbitMQ 几乎支持所有常用语言，比如 Java、.NET、Ruby 等等 管理界面：RabbitMQ 提供了一个易用的用户界面，使得用户可以监控和管理消息 Broker 的许多方面 跟踪机制：如果消息异常，RabbitMQ 提供了消息跟踪机制，使用者可以找出发生了什么 插件机制：RabbitMQ 提供了许多插件，来从多方面进行扩展，也可以编写自己的插件 ...... 主要组成： 主要组成 Broker：简单来说就是消息队列服务器实体。 Exchange：消息交换机，它指定消息按什么规则，路由到哪个队列。 Queue：消息队列载体，每个消息都会被投入到一个或多个队列。 Binding：绑定，它的作用就是把exchange和queue按照路由规则绑定起来。 Routing Key：路由关键字，exchange根据这个关键字进行消息投递。 vhost：虚拟主机，一个broker里可以开设多个vhost，用作不同用户的权限分离。 producer：消息生产者，就是投递消息的程序。 consumer：消息消费者，就是接受消息的程序。 channel：消息通道，在客户端的每个连接里，可建立多个channel，每个channel代表一个会话任务。 9、Spring Cloud Alibaba：Seata 分布式事务 在微服务架构中由于全局数据一致性没法保证产生的问题就是分布式事务问题。简单来说，一次业务操作需要操作多个数据源或需要进行远程调用，分布式处理时无法通过单点数据库利用一个事务保证数据的完整性，我们必须引入某种额外的机制来协调多个事务要么全部提交、要么全部回滚，以此保证数据的完整性，这便是“分布式事务”的由来。 Alibaba Seata 是一款开源的分布式事务解决方案，致力于在微服务架构下提供高性能和简单易用的分布式事务服务。 官网地址：http://seata.io/zh-cn/ Alibaba Seata Seata 提供了多种分布式事务的解决方案，包含 AT 模式、TCC 模式、SAGA 模式以及 XA 模式。其中 AT 模式提供了最简单易用且无侵入的事务处理机制，通过自动生成反向 SQL 实现事务回滚。从 AT 模式入手使用，使我们理解分布式事务处理机制是非常好的学习办法。 Seata 的特色功能 因为官网有完整的功能介绍，这里不再赘述。 五、运行效果展示 部署架构图： API文档： 调用链监控： 服务注册： 服务注册 服务监控: 日志聚合： 配置管理： 系统保护： 六、总结 技术点很多，最后通过一张脑图做个总结： 核心技术点 参考资料： [1]：《 SpringCloud Alibaba 实战》 [2]：《高楼的性能工程实战课》 [3]：https://github.com/macrozheng/mall-swarm
2021-05-12

资源下载

更多资源
Mario

Mario

马里奥是站在游戏界顶峰的超人气多面角色。马里奥靠吃蘑菇成长，特征是大鼻子、头戴帽子、身穿背带裤，还留着胡子。与他的双胞胎兄弟路易基一起，长年担任任天堂的招牌角色。

时间: 2026-10-18 大小: 211.28KB 下载: 56次
Nacos

Nacos

Nacos /nɑ:kəʊs/ 是 Dynamic Naming and Configuration Service 的首字母简称，一个易于构建 AI Agent 应用的动态服务发现、配置管理和AI智能体管理平台。Nacos 致力于帮助您发现、配置和管理微服务及AI智能体应用。Nacos 提供了一组简单易用的特性集，帮助您快速实现动态服务发现、服务配置、服务元数据、流量管理。Nacos 帮助您更敏捷和容易地构建、交付和管理微服务平台。

时间: 2026-09-24 大小: 189MB 下载: 9次
Spring

Spring

Spring框架（Spring Framework）是由Rod Johnson于2002年提出的开源Java企业级应用框架，旨在通过使用JavaBean替代传统EJB实现方式降低企业级编程开发的复杂性。该框架基于简单性、可测试性和松耦合性设计理念，提供核心容器、应用上下文、数据访问集成等模块，支持整合Hibernate、Struts等第三方框架，其适用范围不仅限于服务器端开发，绝大多数Java应用均可从中受益。

时间: 2026-08-21 大小: 5MB 下载: 2次
Sublime Text

Sublime Text

Sublime Text具有漂亮的用户界面和强大的功能，例如代码缩略图，Python的插件，代码段等。还可自定义键绑定，菜单和工具栏。Sublime Text 的主要功能包括：拼写检查，书签，完整的 Python API ， Goto 功能，即时项目切换，多选择，多窗口等等。Sublime Text 是一个跨平台的编辑器，同时支持Windows、Linux、Mac OS X等操作系统。

时间: 2026-08-21 大小: 9.84MB 下载: 40次
热门标签
DeepSeek Jdk25 OpenAi HarmonyOS6 Nacos3 SpringBoot4 SpringCloud Docker Kubernetes Service Mesh Redis Gemini3 Rocky

欢迎您来访！

登录后，您将获得更多功能！
热门文章
联系我们

有任何问题或合作意向欢迎联系我们

Email: 99873273@qq.com

QQ: 99873273

用户登录
用户注册