微服务 on 小盒子的技术分享

我用两句中文，让 Claude Code 帮我画了10张出版级技术图

Sun, 12 Apr 2026 08:38:12 +0000

前两天在写一篇技术文章，写到一半需要配一张微服务架构图。我打开了某在线画图工具，对着空白画布发了十分钟的呆，拖了两个方块，连了一条线，觉得丑，删掉，再拖两个方块。

半小时过去了，图还没画完，文章的灵感已经凉透了。

我相信很多搞技术内容的朋友都有过这种体验。你脑子里其实很清楚这张图应该长什么样，但你就是得花一两个小时在画图工具里对齐、配色、调字号。明明内容才是核心，结果时间全花在了排版上。

然后我发现了一个东西，彻底解决了这个问题。

它叫 fireworks-tech-graph，是一个 Claude Code 的 skill。装上之后，你跟 Claude Code 说一句中文，它就能给你吐出一张出版级别的技术图。SVG 矢量源文件加 1920px 高清 PNG，直接能往文章里塞。

我用它画了10张不同类型的图，从架构图到 ER 图到状态机，从白底极简到暗色霓虹到工程蓝图。每张图从下指令到拿到成品 PNG，平均不超过30秒。

30秒。

我之前在画图工具里对齐一个箭头的时间都不止30秒。

怎么装呢，你甚至不需要记任何命令。

打开 Claude Code，直接跟它说「帮我安装 fireworks-tech-graph 这个 skill」，它自己就把活干了。装完之后你说「画一个 xxx 图」，它就自动触发。

如果你喜欢手动装也行，就一句 claude skills install fireworks-tech-graph，完事。

触发词非常宽泛，「画图」「帮我画」「做个架构图」「生成一个流程图」「可视化一下」，随便怎么说都行，它都能识别。

它能画什么？

这个 skill 支持10种有模板的图表类型，外加4种无模板但有规则定义的类型。我挑几个最实用的说一下。

1，架构图。这是用得最多的，画微服务分层、系统组件关系。你告诉它有哪些服务、怎么分层、哪些组件之间有调用关系，它自动帮你排好。我画的那张微服务架构图有5层，右侧还挂了一个观测性旁路，出来的效果跟正经架构文档里的图一模一样。

2，流程图。CI/CD 流水线、审批流、业务决策流。菱形判断节点、圆角矩形处理步骤、失败回环，全都有。你只需要描述「从提交代码到部署生产」中间经过哪些步骤和判断就行。

3，时序图。微服务之间谁先调谁，消息怎么传递。标准的 UML 时序图，有生命线、激活框、alt 分组框。你列出参与者和消息序列，它帮你排好。

4，ER 图。数据库表之间的关系。支持鸦脚记法，PK 自动下划线，FK 标注。你把实体和属性列出来，告诉它哪些是一对多、哪些是多对多，它画出来的东西可以直接放进数据库设计文档。

5，状态机。订单生命周期、工单状态流转这种。每个状态是一个圆角矩形，转换线上标事件名，有初始态的实心圆和终态的同心圆。

6，对比矩阵。横评几个模型、几个方案的时候特别好使。我画了一张 LLM 模型对比表，5个模型7个维度，绿色打勾红色打叉，交替行填充，出来就是一张可以直接发朋友圈的表。

7，时间线。项目路线图、版本规划。甘特图样式，彩色横条加菱形里程碑。

除了这些，还有 Agent 架构图、用例图、数据流图。反正你在技术写作里能用到的图，它基本都覆盖了。

比较骚的是它有7种视觉风格，每种味道完全不一样。

默认的 Flat Icon 是白底彩色，适合博客和文档。Dark Terminal 是暗色霓虹风，发 GitHub 和技术社区特别帅。Blueprint 是工程蓝图风，深蓝色背景加网格线加角标，那种 CAD 图纸的感觉。Notion Clean 是极简白，一根线一个色。Glassmorphism 是毛玻璃卡片，适合产品官网和 Keynote。最近还加了 Claude Official 和 OpenAI Official 两种风格，分别是 Anthropic 和 OpenAI 的品牌调性。

你指定风格的方式就是在 prompt 里加一句「用蓝图风」或者「Style 3」，就这么简单。

我觉得这个 skill 最打动我的点，不是它画得多漂亮，而是它把「画图」这件事的心理门槛降到了零。以前我写文章需要配图的时候，经常会想「算了这里用文字描述一下也行吧」，因为打开画图工具、画完、导出、插入这一套流程太重了。现在不一样了，我在 Claude Code 里写着文章，写到需要配图的地方，直接说一句「帮我画一个 xxx」，30秒后图就在本地了。

这种体验就像是，你本来在用文本编辑器写代码，突然有人给你装了一个实时预览插件。功能上没变，但那个「随时能看到效果」的即时反馈感，会让你更愿意去做这件事。

画图也是一样。当成本足够低的时候，你会发现你开始「想画就画」了。

想试的朋友，打开 Claude Code，说一句「帮我安装 fireworks-tech-graph」，等它装完，再说一句「画一个 xxx 图」。

就这么简单。两句话的事。

下面附一些 demo 图：

Java老兵的十字路口：坚守还是突围？

Sat, 29 Mar 2025 05:33:55 +0000

Java在技术江湖中的现状：稳固基石还是夕阳西下？

Java 作为企业级开发的常青树，至今在大量核心系统中扮演着中流砥柱的角色。然而，资深 Java 开发者也明显感受到技术环境的变化。一方面，在银行、政府、互联网巨头等复杂业务场景中，Java 的地位依然稳固；大量遗留系统和核心业务仍运行在 Java 上，短期内很难被完全替换。以优酷的版权管理系统为例，这套长达10年的老系统采用了过时的技术框架，积累了 81万行 Java 代码和大量“没人敢动”的if-else逻辑，可谓技术债累累。像这样的遗留系统，全面重构风险极高，只能在业务推动下逐步演进。因此，在许多传统领域，Java 作为“老码农”的看家本领，仍是不可或缺的基石。

另一方面，新兴业务和初创项目对技术栈的选择更加多元。近年Go语言等后起之秀在性能、并发和开发效率上表现出色，成为云原生时代的“宠儿”。不少互联网大厂开始在核心服务中引入 Go：例如谷歌、滴滴、Uber、腾讯等都用 Go 开发高并发、高性能的服务。业界一度流传着“Java 老旧笨重、Go 崭新酷炫”的声音。面对这种冲击，不少资深 Java 工程师难免焦虑：Java 会不会像当年的 COBOL 一样淡出主流舞台？

事实证明，这种担忧有些过度。Java 拥有数百万开发者和完整生态，并非轻易就能被取代的工具。正如有分析指出，Go 的崛起为行业提供了新选择，但并不是对 Java 的简单替代；两种语言各有优势，未来将长期共存。换言之，Java 依旧是技术江湖里的定海神针，只是江湖规矩变了——老兵们需要适应新玩法。

Java 面临的核心挑战：笨重背后的突围

资深 Java 开发者在项目实践中遇到的挑战，往往并非语言本身跑不动，而是架构转型带来的“不适感”。近年来微服务、云原生风潮兴起，Java 传统的开发模式在新环境下面临诸多掣肘。

微服务部署压力

将单体应用拆成数十上百的微服务后，每个服务都需要独立部署运行。Java 应用启动慢、内存占用高的问题被放大。在同样功能下，一个简单的 Go 容器镜像可能只有十几MB，而等价的 Java（如采用 Helidon 框架）镜像初始体积高达 1.4GB！即使使用模块化手段缩减JDK体积（JLink可降至150MB左右），Java应用的容器仍显得臃肿。如此高的基础开销让追求极致弹性的微服务架构如临大敌：部署50个 Java 微服务可能需要远超预期的硬件资源，这正是很多团队转向更轻量语言的原因之一。有开发者调侃：“即便Java性能再好，内存占用是别人的 2～10倍，成本账算下来也让人犹豫。”而且在无服务器（Serverless）场景下，Java 冷启动延迟更是令人头疼——函数实例首次启动可能耗时数秒到十几秒。这一问题长期无法回避，直到 AWS 推出 SnapStart 等黑科技，把 Java 函数冷启动时间缩短到毫秒级，才算勉强止血。但需要注意，这类优化是云厂商额外提供的特殊支持，侧面说明 Java 在边缘计算、FaaS 等领域的先天劣势依然存在。

启动速度与样板代码

“万事开头难”在 Java 世界格外贴切。传统 Java Web 应用往往需要预热 JVM、加载大量类和配置，启动一个服务动辄数十秒甚至几分钟。这在强调弹性伸缩的云环境下难以接受。此外，Java 以模板代码多著称，同样的业务逻辑，用 Java 写可能需要冗长的类定义和 Getter/Setter，而用 Go/Kotlin 等语言则简洁得多。例如，Go 以极简的语法实现高并发，让开发者专注于业务；相比之下，过去的 Java 代码显得繁琐累赘，不少老兵自己也调侃天天在写“体力活”。虽然 Java 近年通过 Lambda、Streams、Records 等特性在不断精简，但是遗留项目中的大量样板代码依旧是维护负担。缺乏某些现代语言特性（如模式匹配、代数数据类型）也使Java在表达某些逻辑时不够优雅。这些痛点促使部分团队尝试用 Kotlin 等 JVM 语言替换 Java，以期获得更简洁的语法和更少的冗余。

并发与性能困境

高并发一直是 Java 的强项，但实现方式却日益受到挑战。传统 Java 使用操作系统线程实现并发，每个线程都对应一定的内存和调度开销，在大规模场景下显得“沉重”。为绕过这个瓶颈，过去几年兴起了基于 Reactive 异步编程的微服务框架，通过单线程事件循环避免线程阻塞。然而异步风格代码复杂度高、调试困难，让许多工程师“叫苦不迭”。好消息是，JDK 19/20 引入了虚拟线程（Project Loom）并在 JDK 21 成为正式特性。虚拟线程是由 JVM 管理的超轻量线程，实现了 Go 协程式的并发模型。这意味着开发者可以用以往同步阻塞的简单代码，实现过去需要复杂回调/响应式才能处理的高并发任务。正如 Java 架构师 Brian Goetz 所言：Loom 的出现有望“一举终结Reactive编程的必要”——因为过去Reactive是为解决线程不足的权宜之计。虚拟线程让我们能够创建成千上万个并发任务而不必担心线程耗尽，大幅降低了编写和维护高并发代码的心智负担。然而，新事物也伴随不确定性：老项目若迁移到虚拟线程模型，需要评估线程本地变量、同步机制等是否还能正常工作；调优方式也与传统线程有所不同。目前虚拟线程虽强大，但毕竟是新特性，在大型生产环境中的考验还不充分。Java 老兵们既期待它带来性能飞跃，也需要保持一份观望和谨慎。

GraalVM 与原生执行

为了解决启动慢、内存高的问题，Java 社区近年另一“大招”是 GraalVM 原生镜像。通过提前编译(AOT)，可以将 Java 应用直接打包成本地可执行文件，启动时间和内存占用都有数量级的优化。这项技术被视为让 Java 重返边缘计算和 Serverless 舞台的希望：原生镜像下，一个 Spring Boot 微服务的“Hello World”容器镜像可小到 ~几十MB；运行时不需要JVM，冷启动延迟大幅降低。实际测试中，采用 GraalVM 原生镜像的 Java 服务在某些基准下性能甚至超越 Go：平均延迟仅0.25毫秒，每秒处理事务达到82426次，吞吐率是 Go 实现的两倍多！这种结果令人振奋，仿佛看到了 Java 打了一场漂亮的翻身仗。

然而，理想很丰满，现实有时比较骨感。将复杂应用迁移到 GraalVM 原生镜像并非易事。例如，反射、动态代理等机制需要额外配置支持，许多成熟库在AOT编译下可能行为异常。构建原生镜像的过程也比较繁琐，往往需要调整代码、引入特定插件，并忍受较长的编译时间。调试诊断也更具挑战——原生应用无法使用 JVM 的丰富调试工具，需要新的手段排查问题。此外，引入 GraalVM 还意味着团队需要掌握一套新的知识体系。在的总结中作者就指出：“将 Spring Boot 应用打包为 Native 镜像并非没有挑战”，直接迁移复杂项目可能遇到种种坑，需要开发者充分评估和测试。因此，GraalVM 不是万能灵药，而是有门槛的新武器：用得好，Java 如虎添翼；用不好，反而可能引入新的不稳定因素。

综上，资深 Java 开发者面对的不是“Java 不行了”，而是如何让 Java 行得更轻、更快、更优雅。JVM 社区显然没有躺在功劳簿上吃老本，而是在微服务、云原生时代积极求变。从 Spring Boot 3 对原生镜像的支持，到 JDK 连续的功能升级（如Records、Pattern Matching等），Java 正在努力破除“笨重”的刻板印象。老兵们需要做的，是与时俱进地拥抱这些变化，用新工具、新思路来武装自己的Java技能库。

用舍之道：哪些场景放弃 Java，哪些场景坚持 Java？

技术选型从来都不是非黑即白，对于 Java 的去留更是如此。究竟在哪些业务场景下应该考虑放弃 Java？哪些场景下 Java 仍是首选？结合真实案例和趋势，我们可以做出以下判断：

场景一：边缘计算与Serverless – 谨慎使用 Java。

对于运行环境受限、对启动延迟敏感的场景，选择 Java 需要非常慎重。典型如物联网设备、边缘网关、函数计算等，这些环境往往内存有限且要求冷启动极快。在这些场合，运行一个庞大的 JVM 显然不如直接使用原生语言（C/C++、Rust）或轻量脚本语言（JavaScript、Python）来得高效。过去不少团队在实现事件驱动的小型服务时，就倾向于用 Node.js 或 Python 编写——不是因为Java不能实现功能，而是因为Java在每次调用都要“热身”的开销让人难以忍受。虽然有 GraalVM Native Image 可以大幅优化，但对小型团队而言，引入它的复杂度可能得不偿失。因此，对于边缘和无服务函数等应用，除非有充足理由和相应优化手段，否则倾向于选择更轻便的技术栈。当然，规则也非绝对：如果业务逻辑需要调用大量现有的 Java 类库（例如进行某种算法运算，而相关库只有Java实现），那么即便在 Serverless 环境下通过原生镜像等方式使用 Java 也是可以考虑的。总的来说，在这些场景，“能不用Java就不用”是较为实际的指导原则。

场景二：高性能微服务 – 视情况取舍

在互联网分布式系统中，每种语言都有用武之地。如果团队主要目标是极致的性能和资源利用率，并且成员对 Go/Rust 等语言驾轻就熟，那么把部分微服务用新语言实现未尝不可。例如某些网关服务、实时通信服务，行业里确有用 Rust 或 Go 重写后延迟降低、内存减半的成功案例。特别是低延迟、高并发的基础设施组件（消息队列、代理服务器等），很多开源项目早就避开 Java 转投 Go/Rust 怀抱，这是技术基因所致（Java 更擅长业务逻辑，系统编程领域C系语言传统更强）。但是，对于业务逻辑复杂的微服务，Java 仍然具有难以替代的优势：强大的生态提供了各种中间件客户端、成熟的 ORM 和事务框架、安全完备的验证和监控工具等等。这些“全家桶”式的支持使Java在开发业务系统时如鱼得水，大大减少了造轮子的成本。如果纯粹为了追新把此类服务改用另一种语言，可能会发现需要重建许多Java自带的轮子，得不偿失。因此，我们的立场是：对性能极限有追求的核心组件，可以考虑非Java实现以挖掘潜力；但大多数微服务尤其是业务导向的微服务，Java 依然是稳妥且高效的选择。况且随着Quarkus、Micronaut等专为云环境优化的Java框架出现，以及JVM自身的持续优化，Java 微服务的“笨重”正在被削平。正如某次测试所示，在较大的机器上，Java 的吞吐甚至可与 Go 持平甚至略胜一筹——只要用对了方式，Java 完全能胜任高性能微服务。

场景三：大型核心系统 – 坚定拥抱 Java

对于那些复杂度高、生命周期长、需要强一致性和可靠性的核心业务，Java 无疑仍是值得长期信赖的编程语言。例如银行的核心账务系统、航空公司的订票系统、阿里的电商交易中台等，这些系统往往经历多年演化，业务规则繁多且严谨，需要大量业内验证过的中间件支撑。Java 的严格类型体系和成熟框架在这里如鱼得水。特别是在金融、政府等对稳定性要求极高的领域，“Java + 大型商用中间件”的组合几乎是默认标配。从技术债的角度考虑，这类系统虽然也面临老旧架构的问题，但重构时通常还是在 Java 体系内升级（比如从 Struts 升级到 Spring Boot，或引入分布式事务框架等），而不会轻易迁移到一门全新的语言上。这不仅因为重写成本高，更因为 Java 多年沉淀的安全性和可靠性难以替代。可以说，在复杂业务长跑中，Java 是一匹稳健的“长途马”，跑得也许不算最快，但足够稳当，生态中现成的工具能够覆盖方方面面，让架构师和开发者更安心。基于这些原因，我们坚定认为：在复杂业务和核心系统场景下，坚持使用 Java 是明智之举。即便引入新的技术插件，也是作为补充而非颠覆，比如用 Python 做小部分AI预测，再把结果喂给Java主系统等等。Java 老兵在这些战场上大可发挥深厚经验，将系统设计得健壮且易于维护，为业务保驾护航。

归纳来说，用舍有道，视需而定：Java 并非万能，同样也远未过时。关键在于根据项目需求选择最合适的工具。在前沿领域不妨多尝试新语言新架构，以保持竞争力；而在关系到企业命脉的长线工程上，Java 依然值得我们托付。

Java老兵的自我进化：坚守阵地or华丽转型？

面对风起云涌的技术浪潮，10年以上经验的 Java 老将们该何去何从？是固守舒适圈，还是勇敢拓展边界？以下几点建议或许对处在十字路口的你有所启发：

拥抱Java新特性，跟上生态演进

不要认为“学了十几年Java就没有新东西可学”。相反，Java生态在飞速更新，每年两个版本迭代。老兵们应该主动学习 JDK近几版的新功能（如Records、Sealed Class、Pattern Matching、虚拟线程等），这些特性能显著改善代码质量和性能，使你的技能焕发新生。例如，试着用 Loom 虚拟线程改造一个老的并发模块，体会一下开发模式的简化；或者研究 GraalVM 如何将现有服务无缝打包为原生镜像，了解其中的限制和调优手段。拥抱新技术不仅能提升生产力，也向团队展示了你与时俱进的技术热情。作为Java老兵，切忌固步自封——持续学习是对抗职业倦怠和时代冲击的最好武器。

拓展多元技能栈，成为“T型”人才

在保持Java优势的同时，建议横向拓展一到两门其它语言或领域技能。比如，可以尝试学习 Go 或 Python，用它们做些小项目，体会不同语言在思维模型上的差异。再比如，深入了解一下前端技术或移动开发，哪怕不做前端，也能与前端同事更高效协作。这种“T”字型的技能结构（既有一门精深的主力技术，又对相关技术有所涉猎）将使你在团队中更具价值。很多架构师在成为架构师前，都曾是精通数门语言、熟悉多种数据库和中间件的全能型工程师。对Java老兵来说，学习一门新语言还能帮助跳出现有思维框架，把新理念反哺到Java日常开发中。例如，借鉴函数式编程思想优化Java代码，或者用脚本语言编写自动化工具提升开发效率。多元化的技能还为你提供了职业备胎：万一某天真的不想写Java了，你在其他领域的积累也足以支撑转型，不至于手足无措。

深入业务和架构，提升不可替代性

随着工作年限增长，“懂业务、能设计”往往比单纯的编码能力更重要。Java老兵应该充分利用在一个行业浸润多年的经验，去深入理解业务领域的本质问题，把握业务发展方向。将业务洞察与技术方案相结合，主动参与系统架构设计和重大技术选型，这会让你成为团队中不可或缺的核心人物。很多时候，业务专家+技术专家的复合型人才，比仅仅精通某种语法的程序员更有竞争力。如果你已经是某核心系统的Owner，不妨尝试推进架构优化和性能提升项目，展示自己在宏观层面的掌控力。同时，培养自己的系统设计能力，多研究业界大型系统的架构案例，学习它们如何权衡取舍。当你能从容驾驭分布式事务、异地多活、CQRS 等架构模式时，你的价值早已超越“Java 工程师”的范畴，而成为真正的技术专家。这种升级，无论未来Java的热度如何，都能让你的职业生涯保持上升。

考虑转型技术管理或其他新领域

并非每个人都要永远写代码。工作十年以上后，你也可以根据兴趣转型，选择最适合自己的道路。如果你热衷带团队和项目把控，可以逐步走向技术管理岗位，担任Team Leader、技术经理甚至CTO，把多年经验用于培养新人和决策把关。很多Java老兵在这一阶段选择带领团队，既可传承自己的开发哲学，又能获得管理成就感。又或者，你对某些新兴领域情有独钟，例如人工智能、大数据、安全等，不妨利用业余时间学习相关知识，寻求内部调岗或外部机会。资深程序员转做产品经理、解决方案架构师的例子也屡见不鲜——只要有心，完全可以跳出演员阵容，转到幕后编剧或导演的位置上。当然，做出转型决定前需要评估清楚：你的核心竞争力是什么，新领域是否真心喜欢，从头开始是否有心理准备。转型不是逃避，而是为了更长远的发展。无论选择深耕Java栈还是开拓新跑道，持续的学习和热情都是关键驱动力。

最后

想对每一位焦虑中的Java老兵说：技术江湖瞬息万变，但真正的资深工程师价值从不局限于某种语法。Java 之父 James Gosling 曾打比方说：“Java就像一辆可靠的卡车”，或许它没有跑车那样光鲜，但能载着重载货物稳稳前行。这辆卡车如今也在不断改装升级，动力和油耗都在改进。我们作为司机，要做的不是弃车而逃，而是练就更高超的驾驶技巧，并且学会在不同道路上换合适的交通工具。坚守初心并不代表故步自封，拥抱变化也不意味着全盘否定过去。当我们既掌握了Java这门老牌利器，又勇于学习新招式、新套路，在变化的浪潮中依然能找到自己的方向和节奏。

10+年开发生涯沉淀下来的经验与智慧，是宝贵的财富。无论Java的流行曲线如何波动，真正优秀的工程师都会不断进化，拓展自己的边界。在这个过程中，我们既要有克制冷静的思考，看清技术演进的本质；也要保持对编程的热爱，不忘初心地享受技术创造的乐趣。愿每一位Java老兵都能在时代洪流中找到属于自己的位置：该出手时果断出手，该坚守时稳如磐石，在新的十年里续写属于你的传奇。

云原生，你真的懂了吗？

Sat, 22 Feb 2025 04:00:00 +0000

啥是云？

说起云原生（cloud native），就不得不说明一下 “云” 是啥。

简单理解，云就是 “云计算”，如果给它下个定义的话是这样的：

云" 特指以云计算模型构建的现代化动态环境

为什么叫云呢？它怎么不叫其他的什么呢？

这个吧，就像你问马云为什么叫马云一样，那是因为给他起名的家长就是这么定的。对，云计算也是如此，计算机领域的专家就是这么定的。后来成了专业术语，大家都这么说。那你说叫 “云” 有没有道理呢？有道理。

我们类比地看，如果你将 “资源” 看成水的话，那么在天空上自由自在、飘来飘去的云就是资源的载体，在你有需要的时候，“呼风唤雨🌧️” ，一朵带着雨水（资源）的积雨云就能为你带来一场甘霖（你需要的资源）。

云在天上，不在地下，不像以前（过去的架构），你想吃水了得自己挖井，现在你可以 “呼风唤雨” 叫云给你水。而且很好管理和维护。所以你看，用 “云” 这个字还是有道理的。

“云” 可以有多种形态

云还有多种形态，一般来说有以下三种：

公有云（Public Cloud）：由第三方云计算提供商（如 AWS、Azure、Google Cloud、阿里云、腾讯云等）拥有和运营，面向公众提供服务。
私有云（Private Cloud）：由企业或组织自己拥有和运营，仅供内部使用。私有云可以部署在企业自己的数据中心，也可以托管给第三方提供商。
混合云（Hybrid Cloud）：结合了公有云和私有云的优势，允许应用程序和数据在两者之间迁移和共享。

还是用吃水比喻，公有云就像 “自来水”，打开水管就能喝。私有云就像自己找水源，自己挖井，自己舀水喝。混合云自然就是这两种的混合。

资源有啥？

说完了云，我们该说水了，云是提供资源的，那么具体有哪些资源呢？什么东西是云可以提供给我们的呢？你可能想到了：“嗨，不就是服务器嘛”。

其实 “资源” 是一个多维度的概念，远不止硬件设备。我们展开说说。

首先是：基础资源，它包括：

计算资源（CPU/GPU/FPGA）
存储资源（磁盘 / SSD / 对象存储）
网络资源（带宽 / IP / 负载均衡）
内存资源（RAM）

然后是抽象服务，比如：

容器编排（Kubernetes（EKS/GKE/ACK）、Nomad）
数据库服务（AWS RDS、阿里云 RDS）
消息队列（Kafka 云托管、AWS SQS、RabbitMQ）

接着是管理与安全，比如：

身份权限（AWS IAM、阿里云 RAM、Azure AD）
监控告警（Prometheus 云托管、Datadog、阿里云 ARMS）
日志分析（ELK Stack 云服务、Splunk）
安全防御（阿里云 WAF）

最后是高阶能力，比如：

Serverless（AWS Lambda、阿里云 FC）
服务网格（Istio、Linkerd）
边缘计算（AWS Wavelength、阿里云 ENS）
量子计算（AWS Braket、Azure Quantum）

我上面举的只是一些常见的例子，其实每一个分类下的资源条目是非常多的。所以你看，“资源” 可不止服务器那么简单，它是多维度的。现在几乎你能用的到的东西都上云了，都是资源。就算没有，经不住人家云厂商包装啊，只要你有需求，人家就有产品卖你，哈哈。

云原生

云其实还是比较好理解的，但是云原生（cloud native）就比较抽象了，在我刚接触这个概念的时候是一头雾水，无论别人给我讲，还是我给别人讲总是说不清楚，或者人家听不懂。

我们还是先来说说定义吧，我找到 CNCF （https://github.com/cncf/toc/blob/main/DEFINITION.md）的一个定义，算比较权威了。

云原生技术有利于各组织在公有云、私有云和混合云等新型动态环境中，构建和运行可弹性扩展的应用。云原生的代表技术包括容器、服务网格、微服务、不可变基础设施和声明式 API。

这些技术能够构建容错性好、易于管理和便于观察的松耦合系统。结合可靠的自动化手段，云原生技术使工程师能够轻松地对系统作出频繁和可预测的重大变更。

Cloud native practices empower organizations to develop, build, and deploy workloads in computing environments (public, private, hybrid cloud) to meet their organizational needs at scale in a programmatic and repeatable manner. It is characterized by loosely coupled systems that interoperate in a manner that is secure, resilient, manageable, sustainable, and observable.

说实话，如果你没有在这个领域干过，光看定义是不容易理解的。甚至就算在云原生环境下从事开发的工程师，如果不认真思考、理解，也不能把什么是“云原生” 讲的很明白。

原因是这个概念本来就比较抽象。所以我不用 CNCF 的定义，换一种说法来描述一下什么是 “云原生”

云原生是一种以云计算基础设施为基石，通过容器化封装、微服务拆分、声明式 API 和自动化运维，将应用的非功能需求（如弹性扩缩、故障自愈、安全策略）交由云平台管理的架构范式。其本质是通过技术手段让业务代码与底层资源解耦，使开发者只需关注业务逻辑，而由云平台自动处理部署、监控、容灾等复杂性。

你看，我这样说是不是清晰一些了？更好理解一些了？还没有？接着往下看。

本质

透过现象看本质，概念怎么说都行，重要的是要理解这个东西的本质。

那我们就来看一看 “云原生” 的本质：

云原生并非单纯的技术集合，而是一种 “以应用为中心” 的思维模式。它通过标准化技术栈（容器 / K8s / 微服务），将云计算从 “资源层” 提升到 “应用层”，让企业能像使用水电一样按需使用计算能力。它的目标是让技术复杂性对业务透明化。

说到这里，我们就不得不说一下为什么要使用或推崇“云原生”了。

云原生的出现源于传统应用架构在云计算时代的局限性。

传统架构有许多痛点，做的传统开发的同学一定都知道，比如：

部署效率低：传统应用依赖物理服务器或虚拟机，部署流程复杂（如手动配置环境、依赖冲突）。
扩展性差：单体架构难以应对流量突增，扩容需要数小时甚至数天。
运维成本高：故障恢复、监控、日志收集等运维工作需人工干预。
环境不一致：开发、测试、生产环境差异导致 “在我机器上能跑” 的问题。

采用 “云原生” 技术栈及应用架构可以有效的解决上面的所有问题。

什么是不可替代的？

不得不说，Docker 和 Kubernetes 技术的出现给了 “云原生” 极大的助力。那如果没有 Docker 和 Kubernetes 呢？云原生这个概念还立得住吗？

其实，云原生概念的出现（2010 年 Netflix 提出）比 Docker（2013）和 Kubernetes（2014）更早。核心思想在容器技术普及前就已萌芽。所以：云原生本质是一种架构哲学，而非特定技术捆绑

那么我们紧接着下一个问题就是：什么是云原生的核心内容，有什么是缺一不可的呢？或者说缺了什么就不能算是云原生了呢？

总结来说，有四大支柱：

弹性伸缩（Elasticity）

必须能力：根据负载自动扩缩资源
替代方案：AWS Lambda（Serverless）、Nomad（非 K8s 编排器）

故障自愈（Resilience）

必须能力：服务熔断、重试、健康检查
替代方案：Hystrix（微服务容错库）+ Consul（服务发现）

声明式管理（Declarative）

必须能力：通过 YAML/JSON 描述目标状态，而非手动操作
替代方案：Terraform（基础设施即代码）+ Ansible（配置管理）

自动化交付（Automation）

必须能力：CI/CD 流水线、蓝绿部署
替代方案：GitLab CI + Spinnaker（持续交付平台）

云原生的 “复杂性悖论”

云原生看起来真好呀，但事实是这样吗？对于软件开发，我们都知道一句著名的话：“没有银弹”，是的。云原生也不是哪儿哪儿都好，它也有它的问题。

云原生存在一个看似矛盾的现象：它承诺降低业务复杂性，却引入了新的技术复杂性。

这种矛盾的核心在于技术栈的 “分层复杂性转移”：

传统架构的复杂性集中在应用层（如单体重构困难、环境配置混乱）
云原生的复杂性下沉到基础设施层（如 K8s 集群运维、Istio 配置）

对企业而言，这相当于用 “可控的工程复杂度” 替代 “不可控的业务阻塞风险”。但关键在于，这种转移是否真正带来净收益。

说白了，你要会“算账”，在成本一定的情况下，要有所取舍，到底要不要上“云原生”，不是技术本身决定的。

云原生有它的显性与隐性成本：

技术债务：K8s 版本升级兼容性问题、Helm Chart 维护
人力成本：需要 DevOps 工程师（平均薪资比开发高 30%+）
认知负担：团队需掌握容器、服务网格、声明式 API 等新范式
工具链成本：监控（Prometheus+AlertManager）、日志（EFK）、追踪（Jaeger）的集成和维护

有成本当然也有收益：

部署效率：从手动部署 1 小时 → 全自动 CI/CD 5 分钟（效率提升 12 倍）
资源利用率：虚拟机静态分配 → 容器动态调度（CPU 利用率从 15% 提升至 60%+）
故障恢复速度：人工排查 1 小时 → 自动熔断 + 滚动更新（MTTR 从 60 分钟降至 5 分钟）
业务敏捷性：新功能上线周期从 1 个月 → 1 周（迭代速度提升 4 倍）

所以，关键是要根据你的实际情况 “算账”，一般来说，当企业规模超过临界点（通常≥50 个微服务 / 日部署次数≥10 次），云原生的收益将显著超越成本。

结论

所以说了半天云原生到底是什么？我不知道你明白了没有，我们上面林林总总写了那么多技术点，如果初次接触确实很头大。但这不重要。

因为：云原生不是工具集，而是「工业化软件生产」的方法论升级

用制造业的思维来理解：

传统软件交付 ≈ 手工作坊（每个陶器需手工塑形、烧制）
云原生交付 ≈ 汽车生产线（标准化零件 + 自动化流水线 + 质量检测体系）

如果你面试的时候，面试官让你谈谈对云原生的理解，我希望你能够把这篇文章的精华吸收了，从一个比较高的层次来谈，我不希望给你一个中规中矩的回答模板，虽然它是正确的，比如以下这样：

“云原生是云计算时代的一种架构范式，旨在通过标准化技术栈（如容器、K8s）和自动化运维体系，将非业务功能（如弹性扩缩、故障自愈）从应用代码中剥离，由云平台接管。其核心驱动力是解决传统单体应用部署慢、环境不一致、扩展难的问题。

从技术分层看，云原生包含：

基础设施层：Docker 实现环境一致性，K8s 完成资源调度，比如我们通过 Deployment 的滚动更新实现零停机发布；

应用架构层：微服务拆分业务能力，Istio 服务网格处理服务间通信的熔断、监控，例如在订单服务中配置超时自动重试；

交付运维层：GitOps 工具链（如 Argo CD）确保声明式配置的版本可控，配合 Prometheus+Grafana 实现实时监控。

关键设计原则包括不可变基础设施（容器镜像一次构建多次运行）、声明式 API（通过 YAML 描述目标状态而非手动操作）。但引入云原生也带来挑战，比如团队需要掌握复杂的 K8s 生态，我们通过建设内部开发者平台（IDP）封装底层细节，让开发者只需关注业务代码。”

云原生应用

什么样的应用是云原生的？

一个应用是否云原生，而要看是否具备以下特征：

容器化部署：

应用打包为 Docker 镜像，在 Kubernetes 集群中运行。
示例：电商大促时，通过 HPA（水平扩缩）自动增加订单处理服务的 Pod 数量。

微服务架构：

业务拆分为独立服务（如用户服务、支付服务），通过 API 通信。
示例：视频网站将视频转码服务独立部署，利用 GPU 节点加速，不影响主站稳定性。

DevOps 流水线：

代码提交后自动触发 CI/CD，完成测试、镜像构建、灰度发布。
示例：金融 App 通过蓝绿部署实现零停机更新，降低发布风险。

依赖云原生中间件：

使用云托管的数据库（如 AWS RDS）、消息队列（如 Kafka on K8s）、缓存（如 Redis Cluster）。
示例：社交平台用云原生数据库 TiDB 处理海量关系数据，自动分片扩容。

跨云与混合云兼容：

应用设计不绑定特定云厂商，可在 AWS、Azure、私有云间迁移。
示例：跨国企业采用 Anthos 实现跨公有云和本地数据中心的统一管理。

最后

云原生不是终点，而是通往智能软件时代的必由之路。当我们将视角从工具本身移开，看到的是一场关于效率、可靠性与创新速度的认知革命。正如 Linux 之父 Linus Torvalds 所说：“技术终将老去，但优秀的架构思想永存。” 在这场变革中，比掌握某个工具更重要的，是建立持续进化的云原生思维体系。

nginx 如何做针对 ip 的限流

Tue, 23 Jul 2024 14:10:00 +0000

闲白

说到限流，大家一定能想到很多算法，比如 令牌桶 、漏桶 、计数器限流、 信号量 等等。解决方案也有很多，以 java 为例，Guava 库中的 RateLimiter 类可以实现，Semaphore 类也可以实现。再复杂点儿，比如你是一个分布式微服务系统，可以上 Hystrix、Resilience4j 这种现成的方案。

从系统架构上来说，无非是在单体应用的当前进程中实现，还是分布式应用的非当前进程中之实现。当然还有另一种方案，就是不在业务应用中实现，而是把这种跟业务不那么紧耦合的功能抽象出去，在网络层面对所有进入系统的请求进行统一的限流控制，这种方式的好处是可以避免每个微服务都实现自己的限流逻辑。

现在很多 API 网关，尤其是新晋的 “云原生” 网关都具备这个功能（基本是标配），比如：Zuul、Kong、Ambassador、APISIX 等。

我们先不论系统是不是分布式微服务的，就单说限流这个事儿，其实也完全可以用 API 网关的思路来实现。就是我不用非要把代码写在应用中，如果我就是不想改代码呢？我想随时调整个限流策略还得重启应用？应用那么重，生效时间那么长，我可不想重启！

所以我们回头看看自己架构中的这些软件，一定能想到这位老朋友 Nginx 。当然无论是原味的 Nginx 还是跟它有血缘关系的 openResty 都一样。

想像一下，用 nginx 配置一下然后 nginx -s reload 就能搞定了，岂不痛快？!

正题

下文我们开始介绍在 nginx 怎么配置能实现针对某些（讨厌的）ip 进行限流，且不影响系统正常运行。（感叹：nginx 是个好东西！！！）

可能有些朋友看到标题就已经开始写 prompt 了，喝着 coffee 等着 AI 给你一行行输出答案，然后心里想：“什么年代了，大哥，还用写个文章专门说这事儿吗？你得学会用工具呀” 。

我想说的是，关于这个问题 AI 能给你回答对 90% 的内容，剩下的 10% 你得自己改。开发同学都知道，别说 10% 了，0.1% 不对，程序也不 work 呀。我是不会告诉你我花了一下午时间跟 AI 都聊了什么的。因为那显得我很弱智。

你也别抬杠说我用的工具不对，市面上但凡有的我都用了，真不行，所以我觉得还是值得写一下的。

配置详解

其实改的地方不多，首先我们要在 nginx 默认配置文件的 http 下面配置：

 1 geo $limit_ip {
 2 default 0; # 默认为 0，表示不受限制
 3 1.2.3.4 1; # 需要被限制的 IP
 4 # 添加更多需要限制的 IP 地址
 5 }
 6
 7 map $limit_ip $limit_key {
 8 0 "";
 9 1 $binary_remote_addr;
10 }
11
12 # 定义限流区域
13 limit_req_zone $limit_key zone=mylimit:10m rate=2r/s;

我们解释一下。

geo 指令：

geo 名字来源于“geographic”，意指地理位置。但是值得注意的是，geo 指令实际上只基于 IP 地址进行匹配，而 IP 地址与地理位置之间的映射需要额外的数据库或服务来提供。许多第三方服务和数据库（如 MaxMind GeoIP、GeoLite2 等）可以用来更精确地将 IP 地址转换为地理位置信息。

解释一下我们上文中中 geo 的配置：

geo $limit_ip { ... }：定义了一个名为 $limit_ip的变量，用于根据客户端 IP 地址设置不同的值。
default 0;：默认情况下，如果客户端 IP 地址不在列表中，$limit_ip 的值为 0。
1.2.3.4 1;：如果客户端 IP 地址是 1.2.3.4，则 $limit_ip 的值为 1。这里的 1 是一个标记，表示这个 IP 地址需要被限制。

总结来说就是用 geo 指令标记需要限制的 IP 地址

map 指令：

map $limit_ip $limit_key { ... }：根据$limit_ip的值来设置另一个变量$limit_key。
0 "";：如果$limit_ip的值为 0（即默认情况），则$limit_key的值为空字符串。
1 $binary_remote_addr;：如果$limit_ip的值为 1（即被标记的 IP 地址），则$limit_key的值为客户端 IP 地址的二进制形式（$binary_remote_addr）。

不知道聪明的你看出来没有，我们这里其实设置的是 “黑名单” （即我想限制哪些 ip 我就配置哪些，剩下的不限制），在 geo 配置的 ip 到了 map 这里以后，将这些 IP 地址映射到了一个变量上，即 limit_key 。如果你想设置白名单（即我想让哪些 ip 不被限制我就配置哪些，剩下的都限制）不就是反过来操作嘛。

举个白名单的例子：

 1geo $limit {
 2 default 1;
 3 10.0.0.0/8 0;
 4 192.168.0.0/24 0;
 5 172.20.0.35 0;
 6}
 7map $limit $limit_key {
 8 0 "";
 9 1 $binary_remote_addr;
10}

limit_req_zone

接着是整块配置的最后一行。

1limit_req_zone $limit_key zone=mylimit:10m rate=2r/s;

使用 limit_req_zone 指令定义了一个限流区域，对标记的 IP 地址进行请求速率限制。如果一个 IP 地址不在 geo 指令中定义，则不受限制。如果一个 IP 地址被标记，则它的请求速率会被限制在每秒 2 个请求。

$limit_key：使用$limit_key 变量作为限流的键。
zone=mylimit:10m：设置共享内存区域的大小为 10MB，用于存储限流信息。
rate=2r/s：设置每个键值（即每个 IP 地址）的请求速率限制为每秒 2 个请求。

其实这些指令都有一些详细参数，简单起见，我就不介绍了，都有 AI 了，需要的话自己查吧。我们说点儿重点。

我猜你可能关心 zone=mylimit 里面到底是什么样的，里面到底有啥。是的，这很重要，了解清楚 zone 的结构很关键，关于 zone 的数据我没细看过，但结构大致类似这样：

 1{
 2 "mylimit": {
 3 "123.124.210.242": {
 4 "current": 0, // 当前请求计数
 5 "last": 1618305483, // 上次请求的时间戳
 6 "tokens": 2, // 当前令牌桶中的令牌数
 7 "delay": 0 // 由于限流导致的延迟（秒）
 8 },
 9 // ... 其他被限流的 IP 地址信息
10 "192.168.1.100": {
11 "current": 1,
12 "last": 1618305495,
13 "tokens": 1,
14 "delay": 0
15 }
16 }
17}

好了，到这里我们第一部分的配置就结束了，是不很简单？然后我们进行第二部分的配置，也很简单。

前文我们第一部分的配置只是定义了一个限流的策略，我们还没应用呢呀。所以我们要在需要的地方把它用起来。

很简单，在需要限流的 location 中这样写：

1 location /abc/api {
2 limit_req zone=mylimit;
3 }

没了？就一句？

对，没了。是不很简单？简单到我都不想解释，如果你理解了前文你就懂了，我就不解释了。毕竟你会用 AI 不是。

然后你就可以重新加载配置，或重启 nginx 了。再然后你就要耐心等待和观察，等待之前那些讨厌的恶意 ip 再次造访，顺利地话你会在 nginx 的 error 日志中看到类似这样的信息：

1... [error] ..limiting requests,excess:0.996 by zone "mylimit", client:1.2.3.4 ...

Make Jar, Not War.

Tue, 05 Jul 2022 09:51:29 +0000

大约在 4 年前，关于 java 应用最终打成 jar 包还是 war 包的选择令我比较疑惑。

那时候更多的应用是打成 war 包的，即使我们知道可以打成 jar 包，但之前都是打成 war 包，并且好像打成 jar 包并没有什么特别明显的好处。

但当时令我困惑的是越来越多的实践正在不怎么说明理由的情况下转而打 jar 包，于是我开始思考……

war 包的理由

在某大型 OTA 企业内部，应用仍然打成 war 包, PaaS 平台会自动安装并配置好 tomcat，我知道这对于 web server 的统一配置和运维来说是有好处的。基于 war 背后的一系列 CI/CD 、DevOps 流程都一定有相应的适配，且就算 jar 包有我不知道的某些优势也不可能一夜之间在大型企业内部使用，需要平台和系统做出调整。

SpringBoot 在当时并未像现在这样流行，这并不意味着大家不用它，我的意思是相对新的项目来说，企业内部会有非常多 “老系统” 需要维护，我们不能指望一下子把这些老系统都用新的技术栈替换掉，就像你知道现在 web application 一般是前后端分离开发，但如果接手一个使用 jsp 的老家伙，你还得维护不是？

jar 的时代

时代不同了，说得好像过了几十年的样子，但其实也就几年光阴而已。不过仅仅是这几年的光阴却足以改变一些事情的面貌。

如今，云原生、微服务大行其道，大家好像已经非常适应这种开发模式，没有人纠结要不要用 SpringBoot，只会讨论使用的版本高还是低。更不用说打包的事情，很自然的会使用 jar,虽然这种看起来的 “最佳实践”，在长期开发的过程中会形成 “肌肉记忆”，但我们还是要讨论一下为什么。

方便

可运行 Jar 是打包自包含可运行应用程序的便捷方法。这样，我们可以最大限度地减少依赖关系。可以通过 Spring boot Maven 和 Gradle plugin 来管理依赖。

云原生友好

在自备容器的情况下（docker,k8s), jar 包可以直接作为一个 single application 来管理。

在过去我们使用 war 是为了让多应用共享 web server，现在是容器的天下，在容器内，一般情况只跑一个应用进程。由于只有一个进程，我们就可以轻松地管理它，比如重启（不会影响其他的应用，因为没有其他应用）。

版本控制

利用 git 等版本控制软件，可以控制程序运行所需要的一切（比如配置文件）

易于扩展

例如，将其复制到另一台服务器，然后“ just run it!” 无需安装和/或配置容器

参考

https://medium.com/@satyajit.nalavade/make-jar-not-war-josh-long-d6ce5fbb8a23

面试不会问的Hystrix实现资源隔离

Mon, 25 Apr 2022 03:37:31 +0000

资源是什么？又为什么要隔离？

我们设想一个这样的场景：

在某分布式微服务系统中的某个服务 A ，它依赖外部的 B 、C、D 三个服务，通过 RPC 远程调用它们。
假设服务 A 是一个 springboot 启动的 java 进程，内部 wrap 的 web server 是 tomcat。
假设 tomcat 采用的线程模型是 NIO 模式，它默认的最大连接数是 10000 ，也就是最多同时接收处理10000个用户请求。

在正常情况下，只要同时请求数不超过10000 且服务 A 及内外部服务都正常运行就没有问题。（理论上虽然是这样，但实际情况可能不太严谨）

考虑这样一种情况：

假设依赖的 B 服务由于各种原因不正常了，比如出现了超时，而且 B 服务是一个业务核心依赖（基本所有请求都要过它）。那么这时候用户从 A 服务入口进来的正常请求线程将不能正常 终止（terminated），而会 阻塞（Blocked） 或者 等待 (waiting) 在 B 服务这里。

这时 tomcat 的可用线程数将下降，也就会导致用户对 A 服务的正常请求受到影响，如果 B 服务的情况不能得到改善，那么 A 服务将有可能面临

线程资源不足，A 服务的非核心请求也受到影响（不走 B 服务的）
雪崩 的风险，有可能会因为线程资源不足而 hang 死，产生连锁反应，导致 A 也不可用。

可见，我们并不想产生这样的影响，我们希望无论 B 服务是不是核心依赖，它出了问题，都尽量不要或最小范围影响我本服务。

所以，总结来看，资源具体来说就是线程 ，而隔离的目的，是为了在依赖服务出问题的情况下，影响范围最小化。

Hystrix

Hystrix 模型

Hystrix 将远程服务的请求托管在一个线程池中。即默认情况下，所有 Hystrix 命令 (@HystrixCommand) 共享同一个线程池来处理这些请求。该线程池中持有 10 个线程来处理各种远程服务请求，可以是 REST 服务调用、数据库访问等。如下图所示：

如何隔离

有两种策略分别是

线程池隔离
信号量隔离

两种隔离方式都是限制对共享资源的并发访问量，线程在就绪状态、运行状态、阻塞状态、终止状态间转变时需要由操作系统调度，占用很大的性能消耗；而信号量是在访问共享资源时，进行 tryAcquire，tryAcquire 成功才允许访问共享资源。

1HystrixCommandProperties.Setter().withExecutionisolationStrategy(ExecutionlsolationStrategy.THREAD)
2HystrixCommandProperties.Setter().withExecutionisolationStrategy(ExecutionisolationStrategy.SEMAPHORE)

线程池隔离

@HystrixCommand 的默认配置适用于只有少量远程调用的应用。幸运的是，Hystrix 提供了简单易用的方法实现舱壁来隔离不同的远程资源调用。下图说明了 Hystrix 将不同的远程调用隔离在不同的“舱室”（线程池）中：

Hystrix 可以为每一个依赖建立一个线程池，使之和其他依赖的使用资源隔离，同时限制他们的并发访问和阻塞扩张。每个依赖可以根据权重分配资源（这里主要是线程），每一部分的依赖出现了问题，也不会影响其他依赖的使用资源。

如果简单的使用异步线程来实现依赖调用会有如下问题：

线程的创建和销毁
线程上下文空间的切换，用户态和内核态的切换带来的性能损耗。

使用线程池的方式可以解决第一种问题，但是第二个问题计算开销是不能避免的。

Netflix 在使用过程中详细评估了使用异步线程和同步线程带来的性能差异，结果表明在 99%的情况下，异步线程带来的几毫秒延迟的完全可以接受的。

优点：

一个依赖可以给予一个线程池，这个依赖的异常不会影响其他的依赖。
使用线程可以完全隔离第三方代码，请求线程可以快速放回。
当一个失败的依赖再次变成可用时，线程池将清理，并立即恢复可用，而不是一个长时间的恢复。
可以完全模拟异步调用，方便异步编程。
使用线程池，可以有效的进行实时监控、统计和封装。

缺点：

使用线程池的缺点主要是增加了计算的开销。每一个依赖调用都会涉及到队列，调度，上下文切换，而这些操作都有可能在不同的线程中执行。

线程池的创建和管理

虽然 Hystrix 可以为每个依赖建立一个线程池，但是如果依赖成千上万，建立那么多线程池肯定是不可能的。所以默认情况下，Hystrix 会为每一个 Command Group 建立一个线程池。Hystrix 的线程池在 HystrixConcurrencyStrategy 初始化，线程池是由 ThreadPoolExecutor 实现的。每个线程池默认初始化 10 个线程。Hystrix 有个静态类 Factory，创建的线程池会被存储在 Factory 中的 ConcurrentHashMap 中。ConcurrentHashMap 的 Key 则是上文说到的 CommandGroupKey 或者指定的 ThreadPoolKey。每次命令执行的时候，都会根据 ThreadPoolKey 去找到对应的线程池。线程池拥有一个继承于 rxjava 中 Scheduler 的 HystrixContextScheduler，用于在执行命令的时候，把命令在这个线程池上调度执行。

信号量隔离

“

每次调用线程，当前请求通过计数信号量进行限制，当信号大于了最大请求数（maxConcurrentRequests）时，进行限制，调用 fallback 接口快速返回。

”

信号量的资源隔离只是起到一个开关的作用，例如，服务 X 的信号量大小为 10，那么同时只允许 10 个 tomcat 的线程（此处是 tomcat 的线程，而不是服务 X 的独立线程池里面的线程）来访问服务 X，其他的请求就会被拒绝，从而达到限流保护的作用。

信号量的调用是同步的，也就是说，每次调用都得阻塞调用方的线程，直到结果返回。这样就导致了无法对访问做超时（只能依靠调用协议超时，无法主动释放）

什么时候适合用信号量隔离而不是用线程池？

隔离的细粒度太高，数百个实例需要隔离，此时用线程池做隔离开销过大
通常这种都是非网络调用的情况下

选用

两种策略对比

线程池隔离	信号量隔离
线程	与调用线程非相同线程	与调用线程相同
开销	排队、调度、上下文开销等	无线程切换，开销低
异步	支持	不支持
并发支持	支持（最大线程池大小）	支持（最大信号量上限）

对于那些本来延迟就比较小的请求（例如访问本地缓存成功率很高的请求）来说，线程池带来的开销是非常高的，这时，你可以考虑采用其他方法，例如非阻塞信号量（不支持超时），来实现依赖服务的隔离，使用信号量的开销很小。但绝大多数情况下，Netflix 更偏向于使用线程池来隔离依赖服务，因为其带来的额外开销可以接受，并且能支持包括超时在内的所有功能。
当请求的服务网络开销比较大的时候，或者是请求比较耗时的时候，我们最好是使用线程隔离策略，这样的话，可以保证大量的容器 (tomcat) 线程可用，不会由于服务原因，一直处于阻塞或等待状态，快速失败返回。而当我们请求缓存这些服务的时候，我们可以使用信号量隔离策略，因为这类服务的返回通常会非常的快，不会占用容器线程太长时间，而且也减少了线程切换的一些开销，提高了缓存服务的效率。

 1@HystrixCommand(
 2 commandProperties = { //利用 commandProperties 更改线程池的一些默认配置
 3 //选择“线程池”模式、"信号量"模式
 4 @HystrixProperty(name="execution.isolation.strategy",value = "THREAD"/"SEMAPHORE"), 
 5 //超时
 6 @HystrixProperty(name="execution.isolation.thread.timeoutInMilliseconds",value = "3000"),
 7 //信号量大小为 10，那么同时只允许 10 个 tomcat 的线程（此处是 tomcat 的线程，而不是服务的独立线程池里面的线程）来访问服务，其他的请求就会被拒绝，从而达到限流保护的作用
 8 @HystrixProperty(name="execution.isolation.semaphore.maxConcurrentRequests",value = "10"),
 9 }，
10)
11public List<License> getLicensesByOrg(String organizationId){
12 //....
13}

注意，如果选用线程池，要合理的设置线程池的大小，和超时时间。

spring cloud 的 yaml 配置可以参考：

 1feign:
 2 hystrix:
 3 # 启用熔断降级策略
 4 enabled: true
 5
 6ribbon:
 7 # 请求建立连接超时时间，单位：毫秒，默认：2000
 8 ConnectTimeout: 3000
 9 # 读取数据超时时间长，单位：毫秒，默认：5000
10 # 这里设置为 10 秒，表示请求发出后，超过 10 秒没有读取到数据时请求超时
11 ReadTimeout: 10000
12 # 对所有操作都进⾏重试，默认：false
13 OkToRetryOnAllOperations: false
14 # 对同一个实例的最大重试次数，默认：0
15 MaxAutoRetries: 1
16 # 切换实例重试的最大次数，默认：1
17 MaxAutoRetriesNextServer: 1
18
19hystrix:
20 command:
21 default:
22 execution:
23 timeout:
24 # 配置 HystrixCommand 命令执行是否开启超时，默认：true。
25 enabled: true
26 isolation:
27 # 隔离策略，分为 THREAD 和 SEMAPHORE，默认为 THREAD。
28 strategy: THREAD
29 semaphore:
30 # 信号量大小，当隔离策略为信号量时，最大并发请求达到该设置值，后续的请求将被拒绝，默认：10
31 maxConcurrentRequests: 100
32 thread:
33 # 表示设置是否在执行超时时，中断 HystrixCommand.run() 的执行，默认：true
34 interruptOnTimeout: true
35 # hystrixCommand 命令执行超时时间，单位：毫秒，默认：1000
36 # 首先要考虑接口的响应时间，其次要考虑 ribbon 的超时时间和重试次数
37 timeoutInMilliseconds: 30000

更多配置请参考：https://github.com/Netflix/Hystrix/wiki/Configuration

参考

自顶向下学习 RocketMQ（二）SpringCloud 整合 RocketMQ

Mon, 06 Dec 2021 10:49:07 +0000

why

上文中我们讨论了 RocketMQ 的安装问题，有些重要的问题忘了说，即：

为什么要用消息队列
消息队列有什么用？
用了消息队列有什么好处？

来讨论为什么之前，先来看一下消息模型，即 “是什么？”，我们引用 RocketMQ 的消息模型：

“

RocketMQ 主要由 Producer、Broker、Consumer 三部分组成，其中 Producer 负责生产消息，Consumer 负责消费消息，Broker 负责存储消息。Broker 在实际部署过程中对应一台服务器，每个 Broker 可以存储多个 Topic 的消息，每个 Topic 的消息也可以分片存储于不同的 Broker。Message Queue 用于存储消息的物理地址，每个 Topic 中的消息地址存储于多个 Message Queue 中。ConsumerGroup 由多个 Consumer 实例构成。

”

可以看到，主要是有 Producer、Broker、Consumer 这三部分。利用这样的模型，一般来说我们可以做到几点应用：

异步
解耦
削峰填谷

异步

相对同步，异步理论上执行的速度更快，效率更高，主线程执行完自己的逻辑然后发一条消息给消息队列就结束了，另外一个异步线程去订阅然后消费这条消息。

解耦

其实异步和解耦关系很密切，如果你把一个业务从同步的改成异步的了，实际上它从业务上就已经解耦了，至于形式上，无论你是用多个微服务进行拆分解耦，还是多个线程进行拆分解耦，都是解耦的。举个比较常见的例子，也是异步场景的，比如电商的用户下单购买后，增加消费积分场景：订单服务主业务逻辑结束后会给消息队列发一条增加消费积分的消息，下游营销服务会去订阅这条消息消费它，异步地执行增加积分的逻辑。

当然解耦后，系统间调用关系从大的业务上是同步的还是异步的，完全是由业务自己决定的。

削峰填谷

说白了，就是根据系统的处理能力来处理信息。在我们没有用消息队列之前，系统接收多少请求就都要处理完响应回去，处理的能力是根据单机或集群的处理能力而定，当然这是有上限的，虽然可以扩展，但可扩展的粒度比较粗：scale out 或 scale up，要么增加机器，要么扩展单机性能。如果我只是有某一类请求有问题处理不过来，其他的没啥事儿，这种扩展粒度就不太合适了。

利用消息队列，我们完全可以实现灵活的扩展，即将更细粒度的请求，解耦抽象为消息，发送到消息队列，让下游服务根据自身的能力去进消费。这里还涉及一个“流控”的问题，即像控制水流的流速一样，我们也要根据上下游系统及消息队列的处理能力来控制消息的流量，以 RocketMQ 为例：

生产者流控，因为 broker 处理能力达到瓶颈
消费者流控，因为消费能力达到瓶颈。

所谓削峰填谷，讲究的是一个平衡，这个平衡是系统和消息队列处理能力与消息流量之间的平衡。峰值的时候控一控让它下来，低谷的时候填一填让它上来，仅此而已。

Spring Cloud Stream

聊完 why, 我们回到本文的正题，既然是 SpringCloud 的整合，那我们先聊一下 SpringCloud 吧。

Spring Cloud 体系内本身是有基于消息驱动的微服务框架的，即 Spring Cloud Stream。

“

Spring Cloud Stream is a framework for building highly scalable event-driven microservices connected with shared messaging systems.

The framework provides a flexible programming model built on already established and familiar Spring idioms and best practices, including support for persistent pub/sub semantics, consumer groups, and stateful partitions.

”

Spring Cloud Stream 提供了消息中间件配置的统一抽象，推出了 publish-subscribe、consumer groups、partition 这些统一的概念，有效的简化了上层研发人员对 MQ 使用的复杂度，让开发人员更多的精力投入到核心业务的处理。

Spring Cloud Stream 解决什么问题？

无感知的使用消息中间件 Stream 解决了开发人员无感知的使用消息中间件的问题，因为 Stream 对消息中间件的进一步封装，可以做到代码层面对中间件的无感知。
中间件和服务的高度解耦 Spring Cloud Stream 进行了配置隔离，只需要调整配置，开发中可以动态的切换中间件（如 rabbitmq 切换为 kafka)，使得微服务开发的高度解耦，服务可以关注更多自己的业务流程。

应用模型

Spring Cloud Stream 由一个中立的中间件内核组成。Spring Cloud Stream 会注入输入和输出的 channels，应用程序通过这些 channels 与外界通信，而 channels 则是通过一个明确的中间件 Binder 与外部 brokers 连接。

列举下 Binder 的实现：

RabbitMQ
Apache Kafka
Amazon Kinesis
Google PubSub (partner maintained)
Solace PubSub+ (partner maintained)
Azure Event Hubs (partner maintained)
Apache RocketMQ (partner maintained)

另外还有一个概念叫 Binding,Binding 在消息中间件与应用程序提供的 Provider 和 Consumer 之间提供了一个桥梁，实现了开发者只需使用应用程序的 Provider 或 Consumer 生产或消费数据即可，屏蔽了开发者与底层消息中间件的接触。Binding 包括 Input Binding 和 Output Binding。

注意这里的 input 和 output 是站在生产者和消费者的角度，而不是 broker 的角度，如果你生产消息，那么对应使用的应该是 output, 如果你消费消息，那么对应使用的应该是 input。

接入 RocketMQ

依赖

使用 SpringCloud SpringBoot SpringCloud Alibaba 的组合，版本信息如下：

1 <spring.boot.version>2.3.2.RELEASE</spring.boot.version>
2 <spring.cloud.version>Hoxton.SR9</spring.cloud.version>
3 <spring.cloud.alibaba.version>2.2.6.RELEASE</spring.cloud.alibaba.version>

依赖包

 1<dependency>
 2 <groupId>org.springframework.boot</groupId>
 3 <artifactId>spring-boot-starter-web</artifactId>
 4</dependency>
 5<dependency>
 6 <groupId>com.alibaba.cloud</groupId>
 7 <artifactId>spring-cloud-starter-stream-rocketmq</artifactId>
 8</dependency>
 9<dependency>
10 <groupId>org.springframework.boot</groupId>
11 <artifactId>spring-boot-starter-actuator</artifactId>
12</dependency>

配置

 1spring:
 2 mvc:
 3 throw-exception-if-no-handler-found: true # 处理 404 问题
 4 resources:
 5 add-mappings: false # 关闭 404 资源映射
 6 application:
 7 name: mq-example
 8 cloud:
 9 stream:
10 bindings:
11 # 定义 name 为 input 的 binding
12 input:
13 content-type: application/json
14 destination: test-topic
15 group: test-group
16 # 定义 name 为 output 的 binding
17 output:
18 content-type: application/json
19 destination: test-topic
20 rocketmq:
21 binder:
22 # 配置 rocketmq 的 nameserver 地址
23 name-server: 127.0.0.1:9876

生产&消费

生产者 controller

 1 @GetMapping("/produce")
 2 public void produceMsg() {
 3
 4 Map<String, Object> headers = new HashMap<>();
 5 headers.put(MessageConst.PROPERTY_TAGS, "test");
 6 Message message = MessageBuilder.createMessage("Hello RocketMQ!", new MessageHeaders(headers));
 7 output.send(message);
 8 System.out.println("发送了消息 "+message);
 9
10 }

消费者订阅

 1@Service
 2public class ReceiveService {
 3
 4 /**
 5 * 订阅消息
 6 * @param receiveMsg
 7 */
 8 @StreamListener("input")
 9 public void receiveInput1(String receiveMsg) {
10 System.out.println(" 接受到消息 input receive: " + receiveMsg);
11 }
12}

测试

首先启动 RocketMQ(nameserver 和 broker) ，然后启动服务，调用 controller 接口发送消息，查看接收到的消息内容。

也可以通过 dashboard 查看消息的接收状态。

参考

上了 istio 的贼船之 API Gateway

Mon, 21 Jun 2021 05:02:18 +0000

上了 istio 的贼船之 API Gateway

现状

下图是我们系统的架构现状，大致介绍一下：

基础设施在华为云上
基本上是基于 istio on k8s 架构。
istio 版本为 1.3，所以组件较多（galley、pilot、citadel、telemetry……）
微服务后端用 spring boot 单体，前端有 nodejs、vue等
应用的链路监控主要基于 skywalking, istio 的通讯层面利用 kiali可视化调用链
其他比较传统

历史架构

主要介绍下作为服务通讯基础设施的 istio 在这里的作用

服务间通讯，依赖 envoy sidecar
注册中心，依赖 istio 控制面
服务治理（熔断、超时、重试）这部分还没有完完全全切干净，还有些 spring boot 应用依赖 hystrix，后面会全部改成利用 istio。
流量管理（ingress gateway、egress gateway、负载均衡）
测试（错误注入）

通过将传统微服务架构的这些控制面功能解耦到 istio,可以让微服务应用本身专注于业务开发，是一个比较简的单体 springboot 应用。再结合 k8s 的高扩展性，研发整体的迭代速度和运维效率还是比较高的，缺点是无论是 k8s 还是 istio ，学习成本偏高，需要团队至少 2 人具有专业知识，对于招聘成本、系统升级都有风险。

上了贼船

坦白讲，如果系统最初的设计是我来做，是不会用如此“激进”的方案的，会转而用 spring cloud 为基础的架构，当然，k8s 是非常可能会使用的。但可惜我是中间接手，也想过换架构，但迫于公司业务和迭代的压力，再加上人手有限，再换架构的风险会非常高，所以既然上了 istio 的贼船，就只能走下去了，等什么时候时机成熟再并行其他架构，或切换回合适的架构。这里我要强调的是，做架构选择或者选型不是为了技术而技术，一定是要非常适合当时公司的发展现状、业务场景、团队能力、招聘成本等等，综合多种条件而得出的结论。巧合的是 istio 的 logo 也是一个帆船的样子，果真是上了贼船

API Gateway

终于说到本文的重点 API Gateway 了，对于这个话题，之前写过一篇文章，读者可以先脱离现在的架构从功能层面来了解下 API Gateway。

 [![Image](https://pub-f29bf2b53160470c9a85250116509a24.r2.dev/post/2021-06-21-shang-le-istio-de-zei-chuan-zhi-api-gateway/003-65589640.png)API 网关选型及包含 BFF 的架构设计](http://mp.weixin.qq.com/s?__biz=MzI3Njk5ODg4OQ==&mid=2247484717&idx=1&sn=8162d7957b29504162490780e8d3763d&chksm=eb6dbaabdc1a33bd14c244069e44e3b84dfea8bae546c09facfa42bb5dbf90c1c70421efa6dc&scene=21#wechat_redirect)

回到我们现在的架构，你会发现，虽然我们有前置的 openResty,但应用层这边并没有一个担当 API Gateway 角色的服务。而无论是 openResty 或者是 nginx 对于云原生 API Gateway 的需求是不能完全满足的。

当然了解 istio 的读者可能会问：

istio ingress gateway 不也具有网关的功能吗？
为什么没有用 nginx ingress controller ？

首先，我承认基于 k8s ingress 实现的各种 ingress controller 功能越来越完善，如果我们没有用 istio 可能会采用这种方案，但我们使用了，那么再结合 k8s ingress 就会有如如何为服务网格选择入口网关[1]中说的如下问题：

K8s Ingress 是独立在 Istio 体系之外的，需要单独采用 Ingress rule 进行配置，导致系统入口和内部存在两套互相独立的路由规则配置，运维和管理较为复杂。
K8s Ingress rule 的功能较弱，不能在入口处实现和网格内部类似的路由规则，也不具备网格 sidecar 的其它能力，导致难以从整体上为应用系统实现灰度发布、分布式跟踪等服务管控功能。

其次，没错 istio ingress gateway 除了基础的通讯功能之外，还有一些其他的应用层功能。但我们综合来比较下 k8s ingress、istio ingress gateway 和我们理想中的 API Gateway，就会发现它还不够完善,主要是对于 API 管理的这部分功能欠缺。

未来

前文已经对各种 API Gateway的实现方案进行了讨论，结论是在目前难以找到一个同时具备API Gateway和Isito Ingress能力的网关。那么再回顾一下我们的需求：

我们使用 istio
我们需要 API Gateway

所以，经过思考，我们未来的方案设计如下图：

仍然利用 istio ingress gateway作为入口
将 istio ingress gateway接到 LB
将API Gateway纳入到istio cluster管理的范畴当中，即拥有sidecar proxy，可被istio控制面控制。API Gateway的选型很有可能使用云原生应用网关，如 API SIX
应用层微服务不会利用如 spring cloud gateway 编码一个服务网关

总结：使用API Gateway和Sidecar Proxy一起为服务网格提供外部流量入口。

还有没有问题？

有的，根据 Service Mesh 和 API Gateway关系深度探讨[2]上述方案的优势在于API Gateway和Sidecar独立部署，职责明确，架构清晰。但是，和Service Mesh使用sidecar被质疑多一跳会造成性能开销影响效率一样，API Gateway使用Sidecar也被同样的质疑：多了一跳……

对了多了这一跳，从整个架构每一段的网络耗时及其作用来看，这一跳多出的时间，几乎可以忽略不计。

性能如何？

作为 sidecar 的 envoy的性能应该是毋庸置疑了。至于istio ingress gateway虽然官方给出的数据也不错，但还是要在实践中观察。而作为 Cloud Native API Gateway 比如 API SIX 我对它有足够的信心，至少在我司现阶段业务体量以及未来百倍增长规模下都不会担心性能问题。

参考资料

[1]

如何为服务网格选择入口网关？: https://zhaohuabing.com/post/2019-03-29-how-to-choose-ingress-for-service-mesh/#k8s-ingress

[2]

Service Mesh和API Gateway关系深度探讨: https://www.servicemesher.com/blog/service-mesh-and-api-gateway/

API 网关选型及包含 BFF 的架构设计

Tue, 13 Oct 2020 04:14:35 +0000

API 网关选型及包含 BFF 的架构设计

一背景介绍

下图是我从网络上找到的一个微服务架构的简单架构图，如图可见 API Gateway 在其中起到一个承上启下的作用，是关键组件。

图片来源于网络

在更通用的场景下我们会使用 NGINX 这样的软件做前置，用来处理SLB负载均衡过来的流量，作用是反向代理、集群负载均衡、转发、日志收集等功能。

然后再将 NGINX 的请求 proxy 到 API Gateway 做统一网关处理。

在上面的这个场景下 API Gateway 可以包含以下功能：

安全
限流
缓存
熔断
重试
负载
反向路由
认证、鉴权
日志收集和监控
其他

熟悉 NGINX 的朋友应该可以看出来，上面列出的这些功能和 NGINX 的部分功能是重合的，不过由于架构结构不同，在上面我提到的场景中，即 NGINX 在前 API gateway 在后的结构中，他们两者关注的维度也不一样，所以即使有重合也正常。

二架构调整

下图是我基于云原生微服务架构设计的架构图其中前端流量是通过 SLB -> NGINX -> API Gateway 再到具体服务。

三 java技术栈的 API Gateway 选型

由于后端采用java 的 spring cloud 开发的，所以在语言一致性上更倾向 java 语言开发的组件。如上图虽然在 API Gateway 的位置上写的是 spring cloud gateway，然而也可以采用像 zuul、zuul2 这些同样是 java 语言开发的组件。对于具体 zuul 和 spring gateway的选型，是这样考虑的：

spring cloud gateway	zuul
性能	性能比 Netflix Zuul 好将近一倍	Zuul1 的性能较差 Zuul2 较 Zuul1 有较大的提升
社区和文档	spring社区非常活跃	一般
可维护性	基于spring官方维护性强	经常跳票、Spring Cloud暂时还没有对Zuul2.0的整合计划
亮点	异步、配置灵活	成熟、简单门槛低
不足	早期产品、新版本踩坑	性能一般、可编程一般

Spring Cloud Gateway 的性能比 Zuul 好基本上已经是业界公认的了，实际上，Spring Cloud Gateway 官方也发布过一个性能测试，这里节选如下数据：

Spring Cloud Gateway 构建于 Spring 5+，基于 Spring Boot 2.x 响应式的、非阻塞式的 API。同时，它支持 websockets，和 Spring 框架紧密集成。从目前来看，gateway替代zuul是趋势。基于以上这些，综合考虑在架构中使用Spring Cloud Gateway。

四非java技术栈的 API Gateway 选型

现代 API Gateway 越来越需要或者流行可编程网关了。上面介绍的都是基于 java 语言开发的可编程的 API Gateway。下面我们来聊聊非 java 语言开发的网关。从前面的架构图上看，我们完全可以将 NGINX 和 API Gateway 合并起来，他们的功能的重合点自然消除了，也能降低架构的复杂性和运维成本。

NGINX 是一款优秀的软件，然而它在动态性方面的不足导致不太灵活，后面出现的 OpenResty、tengine 这些基于NGINX 和 Lua 的软件在动态性、灵活方面有本质上的改善，加上基于Lua脚本和插件，可以实现所谓的可编程。

市面上基于OpenResty 以 API Gateway 为应用场景的应用软件有 Kong、APISIX、tyk 等。以下是CNCFland scape 的一个概览

比较了一下 NGING 和 KONG

经过考虑，在架构上，后期有可能将 NGINX、Spring Cloud Gateway 替换成KONG 或其他软件。

比较了一下，目前最火的应用是Kong，另一个国产的 APISIX 趋势也是很猛，且他们的技术栈雷同，所以我在选型上找到了APISIX的作者做的对比：

从 API 网关核心功能点来看，两者均已覆盖：

更详细的比较：

通过性能测试可以看到，在不开启插件的情况下，Apache APISIX 的性能（QPS 和延迟）是 Kong 的2倍，但开启了两个常用插件后，性能就是 Kong 的十倍了。

无论从性能、可用性、可编程代码量等各个维度APISIX都是非常优秀的，目前唯一担心的就是这种早期项目没有太多大规模应用实践，如果上生产还是有风险，可在测试环境调研，并等待有更多生产实践作为依据。当然如果架构师认为风险并不大，且经过了测试调研也是可以上的。😁

五 BFF 层建设迭代

前面我们将 API Gateway 的网关选型介绍了一下，请求通过网关后一般不会直接打到具体微服务上的，而是会通过BFF层，所谓的BFF，即 backend for frontend 面向前端的后端。具体来说它的职能包括：

api数据裁剪
接口编排
接口调用

这层有的公司会按业务进行多个BFF的建设，在BFF中又有可能拆成多个服务，比如支撑首页的，支持列表页的，或者只有一个服务，支撑某个应用的所有请求的。

有了BFF层，前后端就会更好的解耦，前端不用再调用多个接口，然后再组织数据，微服务后端也只需要关心自己服务边界内的事情。

然而在实践的过程中会出现一些问题：

大量业务逻辑从前后端集中在了BFF层
BFF层逻辑复杂，代码量越来越大，难以维护
BFF API版本维护复杂
前端端接口职责不清，扯皮的结果就是放在BFF层

以上是我真实遇到过的场景。所以在后面的架构设计和实施中，这些情况会尽量避免，但没有从技术上解决根本问题。直到 GraphQL 的出现，让我眼前一亮，给了我一个很好的解决方案。关于GraphQL的搭建，数据交换等细节这里就不展开说了，感兴趣的可以从网上找到很多资料。

下图是我从网络上找的一个符合我心目中的理想架构。

图片来源于网络

说起来简单，做起来没那么容易，细节是魔鬼，每利用一个新的技术都会经历一波打怪升级的过程。不过总体来说利用GraphQL确实能从理论上解决上面所说的问题。而重点是如何将它结合进你的系统架构中，并且发挥出它的优势。架构很多时候是在做权衡和选择

关注公众号获取更多精彩内容

如何使用skywalking 进行全链路监控

Tue, 29 Sep 2020 06:41:07 +0000

如何使用skywalking 进行全链路监控

本文涉及内容

skywalking 全链路监控
skywalking 的参数配置
skywalking UI 监控视角与指标介绍
一些很有用的点

skywalking 全链路监控

下图是我从网上找到的一个比较常见的微服务架构，看的出来使用的是 spring cloud 框架组件，后端服务是 java。我所谓的全链路监控是从 Nginx 到数据库这个链路的监控。

我们知道 skywalking 可以通过 agent 比较方便的监控到后端的 java 应用。有关 skywalking 的安装请参考官方文档[1]

以下是几个界面截图：通过 skywalking , 我们可以从服务入口开始一直监控到数据库，甚至是数据库的 sql 以及参数都可以一览无余（sql 参数显示需要单独配置，后面会讲）。

然而我们并没有监控到请求的上游源头，即 Nginx 入口，如果我们将从 Nginx 入口来的并且经由 java 服务最终到数据库的请求全部监控起来，就完成了请求的全链路监控。上面我们处理了下半段，现在我们来处理上半段。

skywalking-nginx-lua[2] 这是 skywalking 的另一个项目，可以通过它来对nginx进行监控。skywalking-nginx-lua 是使用lua来织入 agent 的。所以要求你的 nginx 要么有 lua 模块，要么用 openResty 这样的自带 Lua 功能模块的软件。

我使用的是openResty，只需要加以下配置就可以实现监控（注意中文注释部分）：

 1http {
 2 lua_package_path "/Path/to/.../skywalking-nginx-lua/lib/skywalking/?.lua;;";
 3
 4 # Buffer represents the register inform and the queue of the finished segment
 5 lua_shared_dict tracing_buffer 100m;
 6
 7 # Init is the timer setter and keeper
 8 # Setup an infinite loop timer to do register and trace report.
 9 init_worker_by_lua_block {
10 local metadata_buffer = ngx.shared.tracing_buffer
11
12 -- Set service name
13 metadata_buffer:set('serviceName', 'User Service Name')
14 -- Instance means the number of Nginx deployment, does not mean the worker instances
15 metadata_buffer:set('serviceInstanceName', 'User Service Instance Name')
16 #这是你的skywalking server地址
17 require("client"):startBackendTimer("http://127.0.0.1:12800")
18 }
19
20 server {
21 listen 8080;
22
23 location /ingress {
24 default_type text/html;
25
26 rewrite_by_lua_block {
27 ------------------------------------------------------
28 -- NOTICE, this should be changed manually
29 -- This variable represents the upstream logic address
30 -- Please set them as service logic name or DNS name
31 --
32 -- Currently, we can not have the upstream real network address
33 ------------------------------------------------------
34 require("tracer"):start("upstream service")
35 -- If you want correlation custom data to the downstream service
36 -- require("tracer"):start("upstream service", {custom = "custom_value"})
37 }
38
39 # 这是你的目标下游服务，比如java的微服务网关
40 proxy_pass http://127.0.0.1:8080/backend;
41
42 body_filter_by_lua_block {
43 if ngx.arg[2] then
44 require("tracer"):finish()
45 end
46 }
47
48 log_by_lua_block {
49 require("tracer"):prepareForReport()
50 }
51 }
52 }
53}

下面是几个监控到的nginx数据的截图

至此我们就完成了整个链路的监控。

skywalking 的参数配置

一些中文文档

agent的文档[3]
ui的文档[4]

通过修改agent/config/agenet.config 文件得到的能力

根据文档 https://github.com/apache/skywalking/blob/v8.0.0/docs/en/setup/service-agent/java-agent/README.md 得知

1 可以获取 sql中的参数，默认是获取不到的。当然还要设置参数最大长度。但获取参数有可能引起性能问题。

property key	Description	Default
plugin.mysql.trace_sql_parameters	If set to true, the parameters of the sql (typically java.sql.PreparedStatement) would be collected.	false
plugin.mysql.sql_parameters_max_length	If set to positive number, the db.sql.parameters would be truncated to this length, otherwise it would be completely saved, which may cause performance problem.	512

2 收集http参数

1#收集SpringMVC plugin插件请求参，在tomcat上时这俩设置一个即可plugin.tomcat.collect_http_params or plugin.springmvc.collect_http_params
2 plugin.springmvc.collect_http_params=true
3 #请求参数收集的最大字符长度, 配置过大会影响性能.
4 plugin.http.http_params_length_threshold=1024

3 skywalking-oap 的配置文件中关于数据存储时长的配置

 1core:
 2 selector: ${SW_CORE:default}
 3 default:
 4 # Mixed: Receive agent data, Level 1 aggregate, Level 2 aggregate
 5 # Receiver: Receive agent data, Level 1 aggregate
 6 # Aggregator: Level 2 aggregate
 7 role: ${SW_CORE_ROLE:Mixed} # Mixed/Receiver/Aggregator
 8 restHost: ${SW_CORE_REST_HOST:0.0.0.0}
 9 restPort: ${SW_CORE_REST_PORT:12800}
10 restContextPath: ${SW_CORE_REST_CONTEXT_PATH:/}
11 gRPCHost: ${SW_CORE_GRPC_HOST:0.0.0.0}
12 gRPCPort: ${SW_CORE_GRPC_PORT:11800}
13 gRPCSslEnabled: ${SW_CORE_GRPC_SSL_ENABLED:false}
14 gRPCSslKeyPath: ${SW_CORE_GRPC_SSL_KEY_PATH:""}
15 gRPCSslCertChainPath: ${SW_CORE_GRPC_SSL_CERT_CHAIN_PATH:""}
16 gRPCSslTrustedCAPath: ${SW_CORE_GRPC_SSL_TRUSTED_CA_PATH:""}
17 downsampling:
18 - Hour
19 - Day
20 - Month
21 # Set a timeout on metrics data. After the timeout has expired, the metrics data will automatically be deleted.
22 enableDataKeeperExecutor: ${SW_CORE_ENABLE_DATA_KEEPER_EXECUTOR:true} # Turn it off then automatically metrics data delete will be close.
23 dataKeeperExecutePeriod: ${SW_CORE_DATA_KEEPER_EXECUTE_PERIOD:5} # How often the data keeper executor runs periodically, unit is minute
24 recordDataTTL: ${SW_CORE_RECORD_DATA_TTL:3} # Unit is day
25 metricsDataTTL: ${SW_CORE_RECORD_DATA_TTL:7} # Unit is day

主要是这四行

1enableDataKeeperExecutor: ${SW_CORE_ENABLE_DATA_KEEPER_EXECUTOR:true} # Turn it off then automatically metrics data delete will be close.
2dataKeeperExecutePeriod: ${SW_CORE_DATA_KEEPER_EXECUTE_PERIOD:5} # How often the data keeper executor runs periodically, unit is minute
3recordDataTTL: ${SW_CORE_RECORD_DATA_TTL:3} # Unit is day
4metricsDataTTL: ${SW_CORE_RECORD_DATA_TTL:7} # Unit is day

skywalking UI 监控视角与指标介绍

cpm 每分钟请求数

cpm 全称 call per minutes，是吞吐量(Throughput)指标。下图是拼接的全局、服务、实例和接口的吞吐量及平均吞吐量。

第一条185cpm=185/60=3.08个请求/秒。

SLA 服务等级协议

SLA 全称 Service-Level Agreement，直译为 “服务等级协议”，用来表示提供服务的水平。在IT中，SLA可以衡量平台的可用性，下面是N个9的计算：

1年 = 365天 = 8760小时
99 = 8760 * 1% => 3.65天
99.9 = 8760 * 0.1% => 8.76小时
99.99 = 8760 * 0.01% => 52.6分钟
99.999 = 8760 * 0.001% => 5.26分钟

因此，全年只要发生一次较大规模宕机事故，4个9肯定没戏，一般平台3个9差不多。但2个9就基本不可用了，相当于全年有87.6小时不可用，每周(一个月按4周算)有1.825小时不可用。下图是服务、实例、接口的SLA，一般看年度、月度即可。

Percent Response 百分位数统计

表示采集样本中某些值的占比，Skywalking 有 p50、p75、p90、p95、p99 一些列值。其中的 “p99:390” 表示 99% 请求的响应时间在390ms以内。而99%一般用于抛掉一些极端值，表示绝大多数请求。

Slow Endpoint 慢端点

Endpoint 表示具体的服务，例如一个接口。下面是全局Top N的数据，通过这个可以观测平台性能情况。

Heatmap 热力图

Heapmap 可译为热力图、热度图都可以，其中颜色越深，表示请求数越多，这和GitHub Contributions很像，commit越多，颜色越深。横坐标是响应时间，鼠标放上去，可以看到具体的数量。通过热力图，一方面可以直观感受平台的整体流量，另一方面也可以感受整体性能。

apdex

是一个衡量服务器性能的标准。apdex有三个指标：

满意：请求响应时间小于等于T。
可容忍：请求响应时间大于T，小于等于4T。
失望：请求响应时间大于4T。

T：自定义的一个时间值，比如：500ms。apdex = （满意数 + 可容忍数/2）/ 总数。例如：服务A定义T=200ms，在100个采样中，有20个请求小于200ms，有60个请求在200ms到800ms之间，有20个请求大于800ms。计算apdex = (20 + 60/2)/100 = 0.5。

一些很有用的点

在拓扑图中

红色代表当前节点的请求有一段时间内是响应异常的。当节点全部变红的时候证明服务现阶段内就彻底不可用了。我们可以通过Topology迅速发现某一个服务潜在的问题，并进行下一步的排查并做到预防。

仔细看线是有流向的，有单向和双向的，单向有从左至右的或从右至左的，这样你就知道你的服务是谁依赖了谁。双向的就证明你的服务有循环引用依赖问题。

在最新版本8.1中有endpoint端口依赖的分析，可以分析出接口级别的依赖关系，可以知道某接口是被谁调用，它又调用了谁。

关注公众号获取更多精彩内容

参考资料

[1]

skywalking官方文档: https://github.com/apache/skywalking/blob/master/docs/en/setup/README.md

[2]

skywalking-nginx-lua项目地址: https://github.com/apache/skywalking-nginx-lua/

[3]

skywalking-agent文档: https://skyapm.github.io/document-cn-translation-of-skywalking/zh/8.0.0/setup/service-agent/java-agent/

skywalking-ui 文档: https://skyapm.github.io/document-cn-translation-of-skywalking/zh/8.0.0/ui/

微服务 on 小盒子的技术分享

我用两句中文，让 Claude Code 帮我画了10张出版级技术图

Java老兵的十字路口：坚守还是突围？

Java在技术江湖中的现状：稳固基石还是夕阳西下？

Java 面临的核心挑战：笨重背后的突围

微服务部署压力

启动速度与样板代码

并发与性能困境

GraalVM 与原生执行

用舍之道：哪些场景放弃 Java，哪些场景坚持 Java？

场景一：边缘计算与Serverless – 谨慎使用 Java。

场景二：高性能微服务 – 视情况取舍

场景三：大型核心系统 – 坚定拥抱 Java

Java老兵的自我进化：坚守阵地or华丽转型？

拥抱Java新特性，跟上生态演进

拓展多元技能栈，成为“T型”人才

深入业务和架构，提升不可替代性

考虑转型技术管理或其他新领域

最后

云原生，你真的懂了吗？

啥是云？

“云” 可以有多种形态

资源有啥？

云原生

本质

什么是不可替代的？

云原生的 “复杂性悖论”

结论

云原生应用

什么样的应用是云原生的？

最后

nginx 如何做针对 ip 的限流

闲白

正题

配置详解

limit_req_zone

Make Jar, Not War.

war 包的理由

jar 的时代

方便

云原生友好

版本控制

易于扩展

参考

面试不会问的Hystrix实现资源隔离

资源是什么？又为什么要隔离？

Hystrix

Hystrix 模型

如何隔离

线程池隔离

信号量隔离

选用

参考

自顶向下学习 RocketMQ（二）SpringCloud 整合 RocketMQ

why

异步

解耦

削峰填谷

Spring Cloud Stream

应用模型

接入 RocketMQ

依赖

配置

生产&消费

测试

参考

上了 istio 的贼船之 API Gateway

上了 istio 的贼船之 API Gateway

现状

上了贼船

API Gateway

未来

还有没有问题？

性能如何？

参考资料

API 网关选型及包含 BFF 的架构设计

API 网关选型及包含 BFF 的架构设计

一 背景介绍

二 架构调整

三 java技术栈的 API Gateway 选型

一背景介绍

二架构调整

四非java技术栈的 API Gateway 选型