https://guangmingluo.github.io/post/Recent content in Posts on Guangming BlogHugozh-cnFri, 08 May 2026 17:00:00 +0800https://guangmingluo.github.io/post/eino-ai-framework-deep-dive/Fri, 08 May 2026 17:00:00 +0800https://guangmingluo.github.io/post/eino-ai-framework-deep-dive/Go 开发者做 AI 应用，痛在哪？ 过去两年，AI 应用开发几乎成了 Python 的专属领地。LangChain、LlamaIndex、AutoGen……这些耳熟能详的框架，无一不是 Python 原生。作为一个写了多年 Go 的开发者，我经常面对一种尴尬：明明后端服务是 Go 写的，明明线上跑的是微服务架构，一旦要接入 LLM 能力，就不得不引入 Python 中间层，或者手搓一堆 HTTP 调用。 这种"语言割裂"带来的问题远不止于多写几行胶水代码。更深层的是：你失去了 Go 最引以为傲的东西——编译期类型检查帮你挡住的一大类错误，goroutine 带来的优雅并发模型，还有单一二进制部署的简洁运维体验。而在 AI 应用场景下，这些恰恰又是最需要的：LLM 的 I/O 延迟高、流式输出复杂、工具调用的参数校验容易出错、Agent 状态管理需要并发安全…… 所以当 CloudWeGo 团队推出 Eino 这个 Go 语言 AI 应用开发框架时，很多人的第一反应是：终于有人认真对待这件事了。 Eino 是什么：不止是 “Go 版 LangChain” Eino（发音 [‘aino]，接近 “I know”）是 CloudWeGo 开源的 Go 语言 LLM 应用开发框架。很多人第一眼会把它理解为"Go 版 LangChain"，这个类比不算错——Eino 确实从 LangChain、LlamaIndex 等框架汲取了灵感——但它又不只是简单地把 LangChain 的概念用 Go 重写一遍。 Eino 的设计哲学更接近于：用 Go 的方式，解决 AI 应用开发的工程化问题。什么意思呢？LangChain 生于 Python，天然带着 Python 的思维——动态类型、鸭子类型、隐式的链式调用。这些在原型阶段很爽，但在生产环境中，尤其是 Go 开发者习惯的强类型、显式错误处理、编译期保证的语境下，就显得格格不入。https://guangmingluo.github.io/post/kitex-2026-evolution/Fri, 08 May 2026 14:30:00 +0800https://guangmingluo.github.io/post/kitex-2026-evolution/2026 年的 Go RPC 框架格局正在经历一轮静默但深刻的变化。gRPC 依然是跨语言通信的事实标准，但在纯 Go 微服务场景下，开发者对性能和治理深度的需求远超 gRPC 标准库所能提供的上限。Kitex 在过去几个月连续推出 v0.16.0、v0.16.1、v0.16.2 三个版本，更新频率之快、改动之深，让我这个社区贡献者都觉得有些意外——这不是常规的 Bug 修补版本节奏，而是一次围绕流式 RPC 成熟度和运行时内存效率的系统性攻坚。 本文是从一个长期跟踪 Kitex 演进的开发者视角，聊聊这三个版本背后的技术脉络和设计取舍。 版本演进总览：一条清晰的主线 先看时间线： 版本 发布日期 核心主题 v0.16.0 2026-04-05 流式 RPC 可观测性与安全性 v0.16.1 2026-04-05 gRPC 写缓冲复用 & ttstream 背压 v0.16.2 2026-05-08 进程内调用、gRPC 内存池化、服务发现优化 v0.16.0 和 v0.16.1 同一天发布，但解决的问题截然不同。前者聚焦流式 RPC 的"正确性与可观测性"，后者解决的是流式场景下的"内存安全与资源效率"。v0.16.2 则把优化范围从流式扩展到整个运行时——从服务发现的对象分配到 gRPC 的 framer buffer 池化，再到一个全新的进程内调用机制。 贯穿这三个版本的核心线索是：Kitex 正在从"功能可用"走向"生产级可靠"。这话听起来像是废话，但如果你关注过流式 RPC 在生产环境踩过的坑（LLM 流式响应 OOM、跨流状态泄漏、连接池泄漏），就会理解这背后的工程量。 核心特性深度解读 一、流式 RPC 的"三连击"：超时、可观测、状态安全（v0.16.0） v0.16.0 的三个流式特性拆开看都是修复性质，合在一起却是一次完整的问题闭环。 1. Recv Timeout：流式调用终于有了精确的"时间窗口" 在 v0.https://guangmingluo.github.io/post/harness-engineering-deep-dive/Fri, 08 May 2026 14:00:00 +0800https://guangmingluo.github.io/post/harness-engineering-deep-dive/一个反直觉的发现 如果你有机会翻开一个生产级 AI 编码 Agent 的源码，你最先期待看到什么？模型调用的逻辑？工具执行的编排？权限控制的判断？ 你可能不会期待看到这个：在 Claude Code 中，控制模型行为的主要手段不是代码逻辑，而是提示词。 这不是比喻。当我们说"控制面"的时候，在传统软件中，它意味着 if-else 分支、策略模式、配置中心——总之，是代码。但在 Claude Code 的世界里，系统提示词的每一段落都在引导模型该做什么、不该做什么、优先做什么、什么条件下放弃。工具描述不是静态字符串，而是根据权限模式动态生成的函数。89 个 Feature Flag 中的大部分不是控制代码路径，而是控制注入到提示词中的内容。 这就像你发现一辆汽车的转向系统不是机械连杆，而是驾驶员的语音指令——而且它真的管用。 《驾驭工程》这本书，把从 Claude Code v2.1.88 源码中逆向分析出的这些发现，提炼成了一个更深的命题：当 AI 成为系统的执行者，“控制"这件事本身需要被重新定义。 这不是一个 Prompt Engineering 的问题，而是一个全新的工程学科的问题。 驾驭工程 ≠ Prompt Engineering 先说清楚一件事：驾驭工程不是 Prompt Engineering 的升级版。 Prompt Engineering 解决的核心问题是：如何让模型在一次交互中给出更好的回答。它的基本单位是"一条提示词”，它的优化目标是"这一次的输出质量"。 驾驭工程解决的核心问题是：如何设计一个系统，让 AI 在长时间、多轮次、有状态的执行过程中，始终表现出可预测、可控、可靠的行为。它的基本单位是"一个系统"，它的优化目标是"整个运行周期的行为一致性"。 这个区别是本质性的。打个比方：Prompt Engineering 是教你如何跟一个聪明的临时工说清楚一次任务的要求；驾驭工程是设计一套组织架构、流程规范和文化系统，让一千个聪明的临时工在没有任何直接监督的情况下，持续做出一致的决策。 从 Claude Code 的源码中，我们可以清楚地看到这种系统性思维的具体形态： Agent Loop 不是一个简单的 while 循环，而是一个包含了权限拦截、并发编排、流式中断和压缩触发的状态机 系统提示词 不是一个静态文本块，而是一个由多个段落按条件拼接的动态文档——模型身份、工具描述、上下文压缩结果、用户覆盖层，每一层都在运行时注入 工具注册 有四种策略：无条件注册、构建时 Flag 守卫、运行时环境变量守卫、运行时函数守卫——同一套工具在不同模式下呈现给模型的面貌完全不同 工具描述是函数而非字符串 ——同一个 Write 工具在 allowlist 模式下和默认模式下的描述不一样，因为模型需要知道的信息取决于它当前被授予的权限 这些不是"高级提示词技巧"，这是系统架构。https://guangmingluo.github.io/2024/08/12/enterprise-transformation-in-open-source-innovation/Mon, 12 Aug 2024 08:00:00 +0000https://guangmingluo.github.io/2024/08/12/enterprise-transformation-in-open-source-innovation/下面这段话是马云对刘振飞（阿里技术保障部负责人）关于阿里云内部争议的回复，反应了一个领导者在企业变革过程中起到的作用： 在王坚加入阿里之前，我跟教授（曾鸣）讨论公司的未来，觉得云计算和大数据代表未来，对国家和社会的发展有长远的意义，所以我们要干，这是第一点。 但是怎么做云计算、大数据？我们谁也不知道。现在来了个人叫王坚，他说“我知道怎么做”，为什么不支持呢？这是第二点。 第三点，即使万一做失败了，那也没有关系，咱们的人倒下 70%，还有30%活着，咱们活下来的人打扫战场，换个方向继续干，总要把它做出来。 变革的过程往往伴随着挑战和阻力，而这些阻力不仅来源于外部环境，更是内部力量的反应。尤其是在企业内部推动开源和创新时，这种阻力表现得尤为明显。 一方面，创新的实施必然涉及打破现有的流程和体系。许多公司已经习惯了既有的运营方式，在这种情况下，任何改变都会被视为对现有秩序的威胁。因此，“顽固派”往往会以保护“公司特色”和“本土化”的名义，对创新产生怀疑和抵制。他们害怕失去既得利益，担心新事物带来的不确定性，这使得他们在面对变革时倾向于保守。 另一方面，领导者在变革中的作用至关重要。正如马云在应对阿里云内部争议时所表现出的果断和决心，领导者必须坚定地推动变革，即使在面临内部反对时，也要保持对未来的信心。变革的方向可能并不总是明确的，尤其是在面对新技术和未知领域时，更是如此。然而，领导者的远见和决策力可以为团队指明前进的方向，并提供必要的支持和资源。 在企业内部做开源项目，就是一次创新，也是一次变革。在开源项目的推动中，领导者的坚定信念尤为重要。开源是一种共享和协作的精神，它打破了传统封闭的研发模式，使得更多的人能够参与进来，共同推动技术进步。然而，这也意味着要面对来自各方的挑战，包括团队内部的怀疑和团队外部的挑战。在这种情况下，领导者不仅要为团队提供技术和资源的支持，更要在理念上坚定不移，笃信开源对社会、公司、团队的价值，以引领团队克服困难，实现开源和创新目标。 此外，领导者推动公司相关方认可开源的投入和价值也是至关重要的，这里包括绩效评定和技术晋升体系中开源的投入和产出是否能够被认可。 此外，变革不仅是技术层面的，也是文化层面的。开源项目的成功需要团队成员从思想上接受和认同这一新的研发模式。这需要时间和教育，也需要在实践中不断调整和完善。领导者不仅要在变革之初做出果断决策，更要在过程中不断传递信心，帮助团队成员理解变革的意义，激发他们的参与热情。 变革的道路注定不会一帆风顺，但正是在面对挑战时，领导者的坚决和团队的信念才显得尤为重要。最终，只有那些勇于变革、敢于突破的企业或团队，才能在激烈的竞争中脱颖而出，成为行业的引领者。开源项目的推进正是这样的变革过程，它需要企业上下齐心协力，共同面对挑战，最终实现从量变到质变的飞跃。 企业变革往往伴随着巨大风险和不确定性，而推动变革的过程更是充满挑战。正如上文所述，变革的道路上充满了顽固派的抵制与反对，这些人往往是既得利益的受益者，他们对于现状的维护远超对新事物的接纳。他们习惯于利用“我们要走自己的路”这种说辞来妥协甚至拖延变革的进程。事实上，企业的每一步创新都意味着对传统模式的挑战，而这正是变革的核心——破旧立新。 马云的言论突显了领导者在推动企业变革时所需的决心和勇气。面对未知的未来，即使所有人都对云计算、大数据的发展方向感到迷茫，企业的高层仍然需要凭借对大局的把握和对未来趋势的洞察，果断地做出决定。正如马云所说，即便最后的结果不尽如人意，也要有勇气承担失败，继续前行。换句话说，真正的领导者是在面对不确定性时，敢于承担责任，并且能够在失败后迅速调整方向，带领团队继续前进。 这种领导力在当下尤为重要。随着科技的发展，企业面临的竞争环境日趋复杂，市场瞬息万变。在这种情况下，保持稳固和原地不动并不能保证成功。只有不断创新，不断进行自我变革，企业才能在激烈的市场竞争中保持领先地位。开源项目作为一种新兴的研发模式，正是在这种背景下诞生的。开源不仅是一种技术创新，更是一种文化和理念的变革。它强调的是合作、透明和共享，与传统的封闭式开发模式形成了鲜明的对比。 然而，正是因为开源的这种颠覆性，才使得它在推广过程中面临着巨大的阻力。对于许多研发团队而言，开源意味着改变习惯、重新学习新的工作方式，以及面对不确定的未来。但如果我们坚定地相信开源对社会、公司和团队的长远价值，那么无论遇到怎样的困难，都应该坚持下去。变革的过程中必然会遇到各种挑战和阻力，但只有在这些挑战中坚定前行，才能最终实现创新的突破和企业的长足发展。 总结来说，企业变革是一场持久战，成功与否不仅取决于技术和策略，更取决于领导者的决心和远见。对于那些敢于拥抱变化、不断创新的企业来说，未来的挑战既是风险，也是机遇。而真正的领导者，正是在这种不确定性中，带领团队开辟出一条通往未来的道路。https://guangmingluo.github.io/2024/04/26/microservice-macroservice-monolith/Thu, 25 Apr 2024 12:00:00 +0000https://guangmingluo.github.io/2024/04/26/microservice-macroservice-monolith/在科技领域，趋势变化的速度快得难以跟上。引人注目的术语会在聚光灯下闪耀一至两年，然后被归类为过时的技术。昨天的热门趋势将成为明天被遗忘的时尚。 微服务是近年来一直受到关注的趋势。自 2016 年以来一直被宣传为下一个大事件，但现在技术博客都在发布文章，质疑微服务是否已经死了。 即使是亚马逊这样的世界最大的微服务提供商之一，亚马逊 Prime 也已经回归到了单体架构。 与一些更为耸人听闻的标题所暗示的相反，微服务并没有完全死去。它们只是在不断演变，因为显而易见的是，微服务并不是所有问题的答案。考虑到这一点，让我们深入了解一些围绕微服务的不断发展的术语。我们将重点定义微服务、宏服务和单体架构，以帮助您决定哪种架构风格是下一个项目的最佳选择。 什么是微服务？ 微服务：Microservices 理解微服务、宏服务和单体架构之间的差异最简单、最直接的方法是先简要解释每种架构。让我们从最明显的开始：什么是微服务？简而言之，微服务是专门提供特定功能的小型组件。它们通常是解耦的，并设计为在项目和应用程序之间重用。 亚马逊的微服务是微服务实施中最著名且广泛使用的例子之一。它们是亚马逊去中心化和分布式软件策略的一个组成部分。亚马逊的微服务可用于从缓存到存储对象再到构建数据库的各个方面。 如果您正在寻找一个功能齐全、强大的微服务环境的示例，几乎可以做任何事情，那么亚马逊对微服务的定义值得一看。 Airbnb 对微服务的使用是微服务在分布式平台上如何使用的另一个很好的例子。 Netflix、Uber、Etsy 和 SoundCloud 也在内部正确使用和实践了微服务架构。 微服务允许每个组件都能够扩展，同时也更容易维护，因为每个组件可以由更小的工程团队管理。 微服务的优点 部署速度更快 多个团队可以在同一个组件上工作 可扩展 可在多个应用程序中重复使用 微服务的缺点 成本可能较高 增加了处理时间 需要 API 管理（和零信任策略） 监控可能会复杂化 版本控制在多个团队使用同一微服务时可能会变得复杂 单体架构是什么？ 单体架构：Monolith 单体架构，也称为“单体”，在近年来也是一个热门话题。然而，实际上，单体架构只是传统归一化软件设计模型的另一个名称。单体也可以被描述为“自包含”，其中每个函数或组件都紧密耦合，而不是微服务架构的模块化开发。 单体架构的例子很多，因为大多数自包含的软件和应用程序都是单体架构。电子商务应用程序可能是单体架构的一个示例，因为每个组件都与同一代码库和后端交互。传统软件，如文字处理器和金融应用程序，也经常是单体架构。 单体架构的优点 比基于微服务的架构具有更好的吞吐量 更容易测试和调试 只需跟踪一个代码库，日志记录更简单 比微服务更容易配置和监控 部署更简单，因为只需要下载一个包到服务器 单体架构的缺点 代码库可能难以理解 修改速度较慢且更难掌控 更改可能导致意想不到的下游影响 编译时间更长 加载时间更长 什么是宏服务？ 宏服务：Macroservices 如果您熟悉技术，您大概已经听说过微服务和单体架构。但宏服务是相对新兴的技术理念，所以它的趋势性还不如前者那么明显。这种情况很可能会改变，因为宏服务或许可以在微服务和单体架构之间取得平衡。 SystemSoft Technologies 将宏服务描述为“大型或笨重的微服务，服务来自SOA（面向服务的架构）或部分单体”。 Even Financial 更广泛地描述了宏服为“几个大型、松散耦合的服务”。 简单来说，它们是非常大或复杂的微服务，或者它们是简化和精简的单体。然而，它们不仅仅是这样，因为这三种架构风格之间仍然存在一些关键差异。 在 Even Financial 的 PPT 中，他们阐述了他们对宏服务的使用方法和使用宏服务的理念。 Even Financial 对宏服务的采用旨在作为从单体架构过渡到微服务的桥梁。在他们的示例中，他们建议每个团队决定他们将需要的服务，比如操作目录或处理图像。他们建议使用宏服务，一旦架构设置完成，然后可以将其转换为微服务。 软件架构师 Mehmet Ozkaya 通过一个方便的示意图详细解释了软件架构的演变。https://guangmingluo.github.io/2024/01/27/new-evolution-for-microservice/Sat, 27 Jan 2024 12:00:00 +0000https://guangmingluo.github.io/2024/01/27/new-evolution-for-microservice/原文发布在 InfoQ 尽管微服务架构长期以来被视为云原生应用的事实标准，但在 2023 这一年，来自各方的反思声音逐渐增多。去年 3 月，AWS 分享了一个案例，Prime Video 团队将其 Serverless 应用程序中的部分微服务调整成为了一个单体，称此举节省了 90% 的运营成本。 DHH 对此评论道：“亚马逊也无法理解无服务器或微服务。”谷歌也于去年开源了一个名叫 Service Weaver 的框架，在相关论文中，他们表示这种方法可以将发布式系统带来的延迟降低 15 倍，成本降低 9 倍。 那么，微服务到底有没有什么问题？Service Weaver 是否能够成为微服务架构的“新解”呢？ 微服务架构今年已经满十岁了，它的演进关键阶段如何？目前分布式架构还面临的最大挑战是什么？ 微服务架构在过去十年中经历了几个关键阶段的演进： 初期探索阶段（2010-2013 年）： 微服务概念的提出和初步探索，尝试将传统的单体应用拆分成小型、自治的服务。 技术领域开始出现一些支持微服务架构的工具和平台，但尚未形成成熟的最佳实践。 早期采用和成熟化（2014-2016 年）： 微服务架构得到更广泛的关注和采用，许多组织开始将其应用于生产环境中。 持续集成和持续交付（CI/CD）、容器化技术（如 Docker）、编排工具（如 Kubernetes）的出现和广泛应用，为微服务的部署和管理提供了更多支持。 成熟阶段和生态系统建设（2017- 至今）： 微服务架构成为主流，许多大型企业和组织开始采用，并建立了成熟的最佳实践和模式。 服务网格（Service Mesh）的兴起，为微服务架构中的服务通信、可观测性和服务治理提供了更多的解决方案。 基于云原生和 Serverless 的发展，微服务架构更趋向于弹性、自动化和灵活性。 微服务架构的一些挑战包括： 微服务拆分与粒度：微服务粒度的控制对整个架构的性能、可维护性和扩展性都有很大的影响。微服务粒度的控制是一个动态的且充满挑战的事情。 微服务需要治理：随着服务数量的增加，需要解决服务发现、负载均衡、版本控制等问题，确保服务之间的通信可靠性和一致性。 分布式系统复杂性管理：微服务架构涉及多个分布式组件，因此需要处理分布式系统带来的复杂性，如一致性、事务管理和错误处理。 安全性需求变高：分布式系统面临着更多的安全挑战，需要确保每个服务都能得到充分的保护，防止安全漏洞和攻击。 文化和组织变革：采用微服务架构需要组织文化的变革，包括团队间的协作、持续交付和 DevOps 文化的推广。 解决这些挑战需要不断演进的工具、最佳实践的制定以及组织文化上的变革，以确保微服务架构能够持续发展、能在复杂的环境中稳定运行以及获得真实的收益。 2023 这一年架构领域有哪些关键框架 / 组件有关键更新或演进？ 架构领域一直在不断演进和更新，在 2023 年，一些关键框架和组件经历了重要的更新或者取得了进展： 服务网格：更加成熟的实现和标准化。继 Proxyless Mesh，Istio 今年推出 Ambient Mesh 模式，并正式从 CNCF 毕业，成为 CNCF 活跃度排名第三的项目。https://guangmingluo.github.io/2023/11/28/thought-on-open-source-license/Tue, 28 Nov 2023 12:00:00 +0000https://guangmingluo.github.io/2023/11/28/thought-on-open-source-license/仅代表个人观点，不构成任何法律意见，如有法律相关问题，请咨询律师或者公司法务 在当今数字时代，开源软件的普及和影响力日益增长，使得选择适当的开源许可证成为软件开发领域的一个关键决策。开源许可证的思考不仅仅是技术层面的问题，更是对知识产权、社区合作和创新模式的深刻思考。 而源码公开的许可包括开源、Source Available 以及介于两者之间的许可模式。本文将探讨基于 Copyright（版权）的 Copyleft（版权左转）和 Non-copyleft（Permissive） 两类主要的开源许可方式， 以及商业源码许可（Source Available，也被称为半开源或变种开源许可），剖析它们的优势与劣势，以及在不同场景下的适用性。 通过深入了解这些许可证的工作原理和影响，我们将能够更好地理解如何在开源项目中平衡创作者权益和社区自由，为开源社区的可持续发展和开源许可证的选型提供有益的参考，在理想主义与实用主义之间做一个选择或者妥协。 Copyright 在软件和开源领域，Copyright（版权）是一个非常重要的概念，它与软件的创作、分发和使用密切相关。 版权是指作者或其他版权所有者对其作品所享有的法律权利。这些权利包括复制、分发、修改和公开展示作品等。在软件领域，版权通常适用于软件的源代码、文档、图像和其他相关材料。 对于专有软件或闭源软件，版权所有者通常会通过软件许可证来限制软件的使用、复制和分发。这些许可证通常会规定用户在使用软件时需要遵守的条件，例如禁止反向工程、禁止修改软件等。违反这些许可证可能会导致法律责任。 在开源软件领域，版权所有者通常会通过开源许可证来授权用户使用、复制、修改和分发软件。这些许可证通常会规定用户在使用软件时需要遵守的条件，例如要求用户在修改软件后将修改后的版本开源、要求用户在分发软件时提供源代码等。 总的来说，版权在软件和开源领域中扮演着非常重要的角色，它保护了软件作者和其他版权所有者的权益，同时也促进了软件的创新和发展。 而开源许可证的目的是保护开源软件的知识产权，同时促进软件的自由使用、修改和分发，是一种法律许可。开源许可证的种类很多，通常来说，我们会把其分为宽松型/声明型许可证和（弱/强）限制性许可证，在这篇文章里面，我希望用更专业一点的术语来表达，Permissive 和 Copyleft。 此外，为了更好地保护了软件专有功能和知识产权，同时鼓励付费订阅以获得额外的增值服务，近些年来出现了半开源或变种开源许可，在业界形成了一定的争议，有人认为其限制了开源软件的自由使用，违背了开源精神。 Permissive Licenses Permissive Licenses 是指宽松型许可证，也称为非传染性许可证。这类许可证允许用户自由使用、修改、共享和分发软件，并且不强制要求用户将修改后的软件开源。 优点： 自由度高：允许用户自由使用、修改、共享和分发软件，并且不强制要求用户将修改后的软件开源。 商业友好：这些许可证对商业使用也非常友好，用户可以将软件用于商业目的，并且不需要公开源代码。 简单易懂：这类许可证通常比较简单易懂，不需要用户过多地了解法律术语和细节。 促进创新：由于这类许可证允许用户自由修改和分发软件，因此可以促进软件的创新和发展。 缺点： 知识产权问题：如果用户修改了使用 Permissive Software Licenses 的软件，并将其分发出去，那么可能会涉及到知识产权问题。以 MIT 为例，如果修改后的软件中没有正确保留原始的 MIT 许可证和版权声明，这可能构成违反许可证的行为。需要详细审查许可证要求，确保对原始软件的修改和分发都遵循了原始许可证的规定。 不利于知识自由传播：由于这类许可证不强制要求用户将修改后的软件开源，因此可能会导致一些商业公司基于开源项目的修改和优化封闭在公司内部，不往上游贡献，限制了知识的自由传播和开源项目的发展，衍生软件可变为专有软件。这也对应了为什么会有 “Upstream First” 这一呼吁，因为这类协议本身没有强制。 例子： Apache License 2.0 ，宽松许可证，常见于 Apache 软件基金会的项目，也用于 TiDB、CloudWeGo 等项目。 注：虽然 Apache License 2.0 是一种相对宽松的许可证，但它仍然基于版权法，同时也基于专利法，并规定了在遵循一些条件的情况下允许使用、修改和分发软件的条款。Apache License 2.0 允许用户在遵循一些基本的条件和限制的情况下使用和分发软件，包括用于商业用途，但与一些更严格的版权保护不同，它不强制对衍生作品采用相同的许可证。因此，Apache License 2.0 在一定程度上属于“Permissive（宽松）”类别的开源许可证。 MIT License，宽松许可证，用于许多小型和大型开源项目，如 Node.js、Ruby on Rails 等 BSD-2-Clause License & BSD-3-Clause License，宽松许可证，允许自由使用、修改和分发，如 PostgreSQL。 Copyleft Licenses Copyleft 是一种使用版权法的方法，旨在确保作品及其派生作品的源码自由使用、修改和分发。Copyleft 强制要求将基于受保护作品创建的衍生作品在对外分发时，也使用相同或类似的许可证对接收者提供源码，从而保持自由性。Copyleft 通常与开源软件关联，确保源码的自由流通，并防止将其变成专有软件。 优点：https://guangmingluo.github.io/2023/10/17/hashicorp-ceo-interview-on-open-source/Tue, 17 Oct 2023 12:00:00 +0000https://guangmingluo.github.io/2023/10/17/hashicorp-ceo-interview-on-open-source/HashiCorp 的首席执行官预测，除非社区重新思考如何保护创新，否则硅谷将不再有“开源公司”，他在本月的用户大会上为公司的许可证切换进行了辩护。 这家基础架构即代码（IaaC）先驱在旧金山的 HashiConf 大会上发布了一系列产品更新和功能，仅仅两个月前，他们将整个产品组的未来版本从 Mozilla Public License 切换到 Business Source License。 当时，HashiCorp 表示：“允许所有生产用途，除了将软件托管或嵌入在与 HashiCorp 商业产品竞争的产品中，不论是托管还是自行管理。” 然而，这一举措引起了开源社区的激烈反应。在 Linux Foundation 的支持下，不久之后就推出了 Terraform 的 Fork 版本 OpenTofu。 首席执行官 Dave McJannet 本周表示，由于 HashiCorp 的技术对现代云至关重要，而且随着全球最大公司完成从本地技术向云的转变，它只会变得更加重要，所以许可证切换是必要的。 尽管开源倡导者抨击了许可证切换，但 McJannet 表示，最大的客户对此反应“非常积极”。他说：“因为你对我们来说是一个至关重要的合作伙伴，我们需要你成为一个大公司。” 事实上，他声称，“很多反馈是‘我们希望你早点这样做’”，并补充说这一举措在公布之前已与主要云供应商讨论过。 “在过去的三四年里，每个供应商都得出了同样的结论，” McJannet说。 他声称，传统的基金会模式已经破裂，因为它们被传统供应商所主导。他以 Hadoop 为例，说：“它们是大公司保护自己免受创新影响的一种方式，确保如果 Hadoop 变得流行，IBM 仍可以以更低的价格销售，因为他们是基金会的一部分。” 将开源产品放在 GitHub 上的演变“非常非常成功”，但一旦项目变得流行，就会有“克隆供应商开始复制这些东西”的动机。 他声称：“我们宣布这一消息后，我的电话响个不停，来自硅谷每个开源初创公司的电话都在说‘我认为这是正确的模式’。” “悲剧…” 他说 Linux Foundation 接纳 OpenTofu 引发了严重的问题。他说：“如果基金会只是将它接纳过来并提供一个组织，那将对开源创新的未来有何影响？这对开源公司是个悲剧。我告诉你，如果这种情况发生，硅谷将不再有开源公司。” 更具体地说，McJannet表示，许可证的变更是其赢得企业信任的策略的一部分。 “其他供应商错误地传达我们的产品是危险的，对我们长期来说不仅不利，对我们的客户也是危险的。” HashiCorp 在切换许可证时提出与受影响的四家主要公司继续合作，并表示：“你只需要承担一些研发成本。”他们回应：“不，不，我们会采用其他选择。” 这也是可以的。 原文：https://www.thestack.technology/hashicorp-ceo-predicts-oss-free-silicon-valley-unless-the-open-source-model-evolves/https://guangmingluo.github.io/2023/03/29/why-get-involved-in-the-open-source-community/Wed, 29 Mar 2023 12:00:00 +0000https://guangmingluo.github.io/2023/03/29/why-get-involved-in-the-open-source-community/2023 年 3 月 25 号，开源社理事长陈阳在中国开发者生态峰会发表了 “社区的力量” 的主题演讲。关于「为什么要参与到开源社区中来」这个话题，陈阳老师整理了六个要点： 获取资源和寻求帮助，解决工作上的实际问题 开源技能培养和理论实操，提升职业经验和专业知识 跟开源专家交流和碰撞，跟世界级的开发者一起工作 提升个人影响力，工作被更多人看到，找到更好的工作 贡献和创造事物的乐趣，培养好奇心 结交朋友，感到有趣，充电，跟志同道合的一群人一起成长 这六个要点整理得很好，让我产生了强烈的共鸣，让我回忆起了参与开源社区经历的点点滴滴。回过头来看，我希望从另一个层面把上述参与社区的收益总结为：成就感和幸福感。 成就感是指一个人做完一件事情或者做一件事情时，为自己所做的事情感到愉快或成功的感觉，即愿望与现实达到平衡产生的一种心理感受。具体来说，参与开源社区，与社区成员协作举办一场成功的技术沙龙、协同完成交付一组高质量的翻译任务、独立完成一个功能开发或者 bug 修复从而解决实际问题，这些事情的完成都能获得成就感。 幸福感是指人类基于自身的满足感与安全感而主观产生的一系列欣喜与愉悦的情绪，幸福感是一种长久的、内在的、坚定的心理状态，并非短暂的情绪体验。在开源社区的工作被更多人看到且收到持续认可和点赞、结识许多志同道合可以共同成长的朋友、相关软技能和硬技能的提升与成长，这些都是持久的内在的情绪体验，能让人获得幸福感。 文化洗礼 2018 年，那个时候云原生和微服务在国内刚刚掀起一股龙卷风，如同刚刚过去敏捷训练浪潮一样迅猛。我机缘巧合在比较早的时间节点就探索了 Spring Cloud 全家桶以及 K8S、Docker、Prometheus 等云原生技术。软件吞噬世界，开源吞噬软件，而云原生技术就是被开源所吞噬。 基于云原生技术的探索，我对于开源充满了好奇，加入了 ServiceMesher 社区，认识了很多社区小伙伴，一起协作做了不少文档和博客翻译的工作。文档成为了大家研究 Istio 开源项目的资料，博客发布到了多个公众号和技术网站上。这是我对于开源社区和开源文化的初体验。 2019 年底，一个机缘巧合下了解到清华大学举办开源之道大讲堂且面向社会开放，我和好友 Jimmy 一起去参加了这个活动。在这个活动中，我第一次见到了许多著名的开源 KOL 和领袖，初步了解了 Apache 基金会以及国内参与开源和主动开源的进展，并了解到了 Apache 文化 Apache Way。 这场活动和文化盛宴对我来说影响是潜移默化的，是影响深远的，更是多个层面的，包括将开源的种子植入到了我的内心深处。 神奇的是，直到几年后的某一天，我们不经意的一次谈话中了解到，字节开源法务专家孙振华老师以及最近加入字节的 Apache 基金会董事姜宁老师，都参加了这场开源文化活动，虽然当时我们并不相识，但是冥冥之中让我们后来成为了同事和朋友，深感缘分之奇妙。 那么开源文化究竟是什么呢？业内有很多专家做了探索，不同人可能会有不同的理解，我认为是开放、共享、协作、共赢。保持开放，让知识能够为所有人共享，大家共同协作，一起推动技术进步；开源不是零和游戏，社区共同体可以在其中实现共赢多赢，绝对不是只有一个赢家； 开源世界没有绝对权威，没有任何一个开源项目没有 bug，也没有人永远不犯错，挑战权威是被鼓励的，也是常态；开源世界里也没有阶级，大家通过贡献赢取声望和地位，停止贡献，声望和地位就会下降。 开源布道 2020 年，感谢 Jimmy Song 的邀请，几个志同道合的朋友一起成立了**云原生社区**，希望在国内布道更多云原生技术并提供一个交流的平台，不再局限于服务网格技术。渐渐地，我在业务时间承载了更多社区治理和布道的工作，也认识了非常多的开源技术专家和终端用户，与此同时我对服务网格以及 Istio 相关开源项目有了较深入的理解。 兴许也是因为我的社区身份，受到了百度开源办公室谭中意老师的邀请，面向百度内部开源社区全员分享了 Service Mesh。很荣幸，这个课程让很多百度同学了解了服务网格这个技术和 Istio 相关开源项目，据了解，后来有很多新加入的同学都看了这个视频录播，有的主动和我建立了个人联系。大家的鼓励和点赞让我获得很强的幸福感和成就感，让我深刻体会了技术布道的价值，这也是知识共享带来的力量。 2020 年底，感谢当时领导的信任，推荐我去报名参加了 Top 100 全球软件案例研究峰会，代表团队对外分享了 “百度云原生开源项目与落地实践”，具体内容涵盖了 bRPC 在内的三个百度开源项目的进展介绍和落地实践分享。在这场分享的尾声，我提出了两个案例启示：https://guangmingluo.github.io/2023/02/23/where-to-go-when-microservices-enter-the-deep-water/Thu, 23 Feb 2023 12:00:00 +0000https://guangmingluo.github.io/2023/02/23/where-to-go-when-microservices-enter-the-deep-water/2022 年，关于微服务发生了几件有趣的事情。其一，正式掌管 Twitter 不久的 Elon Musk 对 Twitter 的开发团队 “批判” 了一番。他表示自己为 Twitter 在许多国家的极慢运行速度感到抱歉。之所以如此慢是因为 App 需要执行 1000 多个 “糟糕” 的批处理 RPC，而这只是为了渲染主页的时间线。Musk 表示 “今天的部分工作将是关闭臃肿的"微服务" 。 实际上，只有不到 20% 的微服务是 Twitter 需要的。” 其二，GitHub 前 CTO Jason Warner 在社交媒体上表示：“我确信过去十年中，最大的架构错误之一就是全面使用微服务。” “任何构建过大型分布式系统的人都知道他们并不真的那样工作，但还必须适应它。”那么，微服务架构是否是一个错误，或者微服务是否已经过时了呢？ 业务是否需要微服务 微服务的起源，最早可以追溯到 2005 年 Peter Rodgers 博士提出的 Micro-Web-Service，即将应用程序设计成细粒度的 Web 服务。2014 年，Martin Fowler 与 James Lewis 首次正式提出了微服务的概念，定义了微服务架构是以开发一组小型服务的方式来开发一个独立的应用系统，每个服务都以一个独立进程的方式运行，每个服务与其他服务使用轻量级通信机制（RPC、HTTP）通信。这些微服务是围绕业务功能构建的，可以采用不同的编程语言。 微服务的诞生绝非偶然，CICD & Infrastructure As Code 的出现与发展，使得基础设施管理逐步简化、功能迭代也更快速和高效，推动与促进了微服务的进一步发展和落地。 然而，微服务架构并非银弹，微服务架构给业务带来收益的同时，也会带来相应的副作用。在合适的阶段采用微服务架构、合理决定微服务架构的拆分粒度以及恰当的微服务技术选型是决定微服务成败的核心。摒弃上述三点不谈，大肆抨击微服务存在的必要性，摇旗呐喊重回单体时代的言论都是站不住脚的。仔细分析 GitHub 前 CTO Jason Warner 的观点，你会发现，其倡导的是从单体到微服务的有序拆分和推进，并且微服务的拆分数量需要适合组织规模，Warner 鼓励企业根据自己的情况来选择，而不是盲从。这和上述倡导的观点本质上是一致的。 合适的阶段采用微服务架构 据观察，几乎所有成功的微服务架构都是从一个巨大的单体架构开始的。面对一个新的产品以及一个新的领域，很难在一开始就把业务理解清晰，往往是经过一段时间后，业务逐渐弄清楚之后，才会逐渐转型成微服务架构。此外，在物理资源和人力资源受限的情况下，采用微服务架构的风险较大，很多优势无法体现，尤其在技术选型不当时，微服务性能上的劣势反而会更加突出。 在微服务划分之前，也应该保证公司内部的基础设施及公共基础服务已经准备完备。可以通过监控组件和产品快速定位服务故障，可以通过工具自动化部署与管理服务，可以通过一站式开发框架降低服务开发的成本，可以通过灰度发布和泳道验证和提升服务的可用性，可以通过资源调度平台快速申请与释放资源，可以通过弹性伸缩服务快速扩展应用。 合理决定微服务架构的拆分粒度 微服务架构的拆分粒度应当合理，微服务架构中的微字，并不代表粒度越小越好，也不代表越多越好，应当追求一个合理的中间值。粒度过微，微服务的缺点将被放大，此时的微服务相对于原先的单体确实弊大于利；粒度不够，单体的缺点并未消除，微服务的优点并未凸显，也是不合理的。微服务架构的粒度拆分是一件相当复杂的事情，对于业务和团队组织架构理解不深的新人或者外部人员，根本无法判断合理的微服务拆分粒度。https://guangmingluo.github.io/2022/01/18/some-insights-about-open-source/Tue, 18 Jan 2022 12:00:00 +0000https://guangmingluo.github.io/2022/01/18/some-insights-about-open-source/开源是共同体，没有“对手”一说 从共同体的角度看，围绕一个开源项目/组织的所有团体成员是一个共同体，整个开源世界也是一个共同体，大家利益相关，相互协作，相互关联，一荣俱荣，一损俱损。 从项目的角度看，相同领域的开源项目，彼此不是对手，更多是合作的关系，大家共同促进了这个领域的繁荣，一座孤岛是不可能长久繁荣的。 从个人的角度看，开源的世界里，有前辈，有晚辈，有先行者，有后行者，有领先者，有落后者。大家相互帮助，相互协作，没有也不应该有“对手”。 避免纸上谈兵，到实践中去，成为开源项目共同体的一份子 社会不只需要实践家，也需要理论家，理论研究是很重要的，这一点应该是共识。 但是“实践是检验真理的唯一标准”，理论需要实践的检验，才能验证理论是否是正确的。 鼓励大家多多实践，真正参与到开源项目中去，去一线做贡献，成为开源项目共同体的一份子。 开源是建设圈子，但也要跳出圈子，避免画地为牢 开源需要建设圈子，这一点是共识。需要积极参与圈内活动，多发言，多表达自我，多结交伙伴，认识开源路上的同行者，相互鼓励，相互支持，相互认可。 开源也需要适度地跳出圈子，多去认识并且虚心学习自己圈子外面的人，避免成为井底之蛙，思路闭塞，画地为牢。 开源有前辈，虚心向前辈学习，但是不要盲从 “弟子不必不如师，师不必贤于弟子，闻道有先后，术业有专攻，如是而已。” “生乎吾前，其闻道也固先乎吾，吾从而师之；生乎吾后，其闻道也亦先乎吾，吾从而师之。”学习的对象没有年龄限制，只要他懂的比我多，即可向他学习；三人行，必有我师焉。 鼓励大家向“闻道先乎吾”的前辈学习；但是开源项目大不同，开源项目背靠的企业背景也不同，很多经验可以借鉴，但是不可盲目复制；需要根据项目具体情况和相关背景，因地制宜，因材施策。https://guangmingluo.github.io/2021/12/31/how-to-look-at-service-mesh-in-2022/Fri, 31 Dec 2021 12:00:00 +0000https://guangmingluo.github.io/2021/12/31/how-to-look-at-service-mesh-in-2022/背景 Service Mesh 一词最早由开发 Linkerd 的 Buoyant 公司提出，这一术语于 2016 年 9 月 29 日第一次公开使用，并被翻译成“服务网格”，逐步在国内传播开来。William Morgan，Buoyant CEO，对 Service Mesh 这一概念定义如下： A service mesh is a dedicated infrastructure layer for handling service-to-service communication. It’s responsible for the reliable delivery of requests through the complex topology of services that comprise a modern, cloud native application. In practice, the service mesh is typically implemented as an array of lightweight network proxies that are deployed alongside application code, without the application needing to be aware.https://guangmingluo.github.io/2020/09/11/microservices-in-cloud-native/Fri, 11 Sep 2020 12:00:00 +0000https://guangmingluo.github.io/2020/09/11/microservices-in-cloud-native/微服务架构可谓是当前软件开发领域的技术热点，它在各种博客、知识媒体和业界知名会议演讲上的出镜率非常之高，无论是做基础架构还是做业务系统的工程师，对微服务都相当关注，而这个现象与热度已经持续了近 5 年之久，经久不衰。 然而，随着云原生技术的推广，以及大量的微服务落地，反微服务的声音越发响亮。尤其是在今年 3 月初，服务网格的著名开源项目 Istio 发布了 1.5 版本，其控制面由原先的多个微服务组件，合并成了一个单体应用，大大简化了其架构与部署运维的复杂性，赢得了满堂喝彩。社区关于微服务模式质疑的声音此起彼伏，也有文章大声呼喊：“醒醒，你不是真的需要微服务！” 那么，在云原生时代，是否需要微服务？什么时候应该采用微服务？微服务究竟能给业务带来哪些好处？如何在不同环境下正确合理地落地微服务？希望读完本文后，每位读者都能在心中有个答案。 微服务是什么 2014 年，Martin Fowler 与 James Lewis 共同提出微服务的概念，定义了微服务架构是以一组小型服务的方式来开发一个独立的应用系统，每个服务都以一个独立进程的方式运行，每个服务与其他服务使用轻量级（通常是 HTTP ）通信机制。这些服务是围绕业务功能构建的，可以通过全自动部署机制独立部署，同时服务会使用最小规模的集中管理能力，也可以采用不同的编程语言和数据库，实现去中心化的服务管理。 而早在 2005 年，Peter Rodgers 博士在云端运算博览会上就提出了微 Web 服务，将程序设计成细粒度的服务（Granular Service），以作为 Microsoft 下一阶段的软件架构。 由此可以看出，微服务并不是一个新的概念，在很早之前就有了充足的理论基础。大系统终究会拆解成小系统，“合久必分，分而治之”；传统行业的系统架构大多都是庞大的单体架构，微服务是架构发展的一个非常自然的演变状态。 遗憾的是，微服务模式并非“银弹”，微服务也有其弊端和痛点。Martin Fowler 也在他的博客中写道：“除非你的系统太复杂，作为单体应用会很难管理，否则不要考虑微服务。绝大多数软件系统都应该构建为单体应用。要注重在单体应用中实现良好的模块化，但不要试图将其拆分成单独的服务。” 微服务架构的优点 通常来说，架构没有好坏优劣之分，只有适合与不适合。但是当把微服务架构与单体架构进行比较，会发现微服务有如下一些优点： 因素 单体架构 微服务架构 说明 故障隔离 线程级 进程级 微服务独立运行，通过进程的方式隔离，使故障范围得到有效控制、架构变得更可靠。 整体可用性 较低 较高 微服务架构由于故障得到有效隔离，整体可用性更高，有效降低了单点故障对整体的影响。 架构持续演进 困难 容易 微服务的粒度更小，架构演进的影响面相应也更小，架构演进不需要大规模重构，只需调整个别微服务即可。 可重用性 低 高 微服务架构可以实现以服务为粒度，通过接口共享重用。 可扩展性 笨重 灵活 微服务架构可以根据服务对资源的要求以服务为粒度进行扩展，而单体应用只能整体进行扩展。 交付速度 较慢 较快 服务拆分后，各个服务可以独立并行开发、测试、部署，交付效率大大提升，产品更新换代速度更快，用户体验更好。 微服务还有许多优点，如“反脆弱性（anti-fragility）”、架构抽象、技术隔离等。但并不是说采用了微服务就自然地具备了这些特性。 微服务的先决条件 准确地来讲，要想享受微服务的福利，需要具备一些先决条件。 团队调整 需要重新组建团队，以服务为核心，按照业务领域划分全功能团队，改变原有的研发流程、决策机制。例如，倡导敏捷文化、快速迭代，做更多的自动化测试，加强 Code Review 等。https://guangmingluo.github.io/2020/07/15/what-does-service-mesh-bring-to-microservices/Wed, 15 Jul 2020 12:00:00 +0000https://guangmingluo.github.io/2020/07/15/what-does-service-mesh-bring-to-microservices/微服务架构概述 微服务架构可谓是当前软件开发领域的技术热点，在各种博客、社交媒体和会议演讲上的出镜率非常之高，无论是做基础架构还是做业务系统的工程师，对微服务都相当关注，而这个现象与热度到目前为止，已经持续了近 5 年之久。 尤其是近些年来，微服务架构逐渐发展成熟，从最初的星星之火到现在的大规模落地与实践，几乎已经成为分布式环境下的首选架构。微服务成为时下技术热点，大量互联网公司都在做微服务架构的落地和推广。同时，也有很多传统企业基于微服务和容器，在做互联网技术转型。 而在这个技术转型中，国内有一个趋势，以 Spring Cloud 与 Dubbo 为代表的微服务开发框架非常普及和受欢迎。然而软件开发没有银弹，基于这些传统微服务框架构建的应用系统在享受其优势的同时，痛点也越加明显。这些痛点包括但不限于以下几点： 侵入性强。想要集成 SDK 的能力，除了需要添加相关依赖，往往还需要在业务代码中增加一部分的代码、或注解、或配置；业务代码与治理层代码界限不清晰。 升级成本高。每次升级都需要业务应用修改 SDK 版本，重新进行功能回归测试，并且对每一台机器进行部署上线，而这对于业务方来说，与业务的快速迭代开发是有冲突的，大多不愿意停下来做这些与业务目标不太相关的事情。 版本碎片化严重。由于升级成本高，而中间件却不会停止向前发展的步伐，久而久之，就会导致线上不同服务引用的 SDK 版本不统一、能力参差不齐，造成很难统一治理。 中间件演变困难。由于版本碎片化严重，导致中间件向前演进的过程中就需要在代码中兼容各种各样的老版本逻辑，带着 “枷锁” 前行，无法实现快速迭代。 内容多、门槛高。Spring Cloud 被称为微服务治理的全家桶，包含大大小小几十个组件，内容相当之多，往往需要几年时间去熟悉其中的关键组件。而要想使用 Spring Cloud 作为完整的治理框架，则需要深入了解其中原理与实现，否则遇到问题还是很难定位。 治理功能不全。不同于 RPC 框架，Spring Cloud 作为治理全家桶的典型，也不是万能的，诸如协议转换支持、多重授权机制、动态请求路由、故障注入、灰度发布等高级功能并没有覆盖到。而这些功能往往是企业大规模落地不可获缺的功能，因此公司往往还需要投入其它人力进行相关功能的自研或者调研其它组件作为补充。 以上列出了传统微服务框架的局限性，但这并不意味着它们就一无是处了。在中小企业，采用 Spring Cloud 这样的传统微服务框架已经可以满足绝大部分服务治理的需求，并且借此快速推进微服务化改造。这些痛点往往是技术发展到一定的程度必然要经历的阶段，这些痛点促使技术不断发展、不断前进。 在众多热门技术趋势中，云原生的关注度居高不下，很多开发者都对由此兴起的一众技术十分追捧，众多企业又开始探索云原生架构的转型与落地。这一年，中国的开发者们经历了从关注“云原生概念”到关注“云原生落地实践”的转变。而 Service Mesh 技术也因此越来越火热，受到越来越多开发者的关注，并拥有了大批拥趸。那么 Service Mesh 是什么呢？它为什么会受到开发者的关注？它和传统微服务应用有什么区别？ Service Mesh 定义 Service Mesh 一词最早由开发 Linkerd 的 Buoyant 公司提出，并于 2016 年 9 月29 日第一次公开使用了这一术语。William Morgan，Buoyant CEO，对 Service Mesh 这一概念定义如下： A service mesh is a dedicated infrastructure layer for handling service-to-service communication.https://guangmingluo.github.io/2020/06/06/particiate-in-the-open-source-community/Sat, 06 Jun 2020 12:00:00 +0000https://guangmingluo.github.io/2020/06/06/particiate-in-the-open-source-community/开源已经无处不在，当下已经很难找到一款软件是完全和开源没有任何关系的了。开源软件，正在成为现代社会的基础设施。 “Open up your phone. Your social media, your news, your medical records, your bank: they are all using free and public code.” - Nadia Eghbal 《Roads and Bridges: The Unseen Labor Behind Our Digital Infrastructure》 开源，并非与你不相关，并非离你很遥远，开源就在你身边！ 而谈到开源软件的开发模式，不得不提及 Eric S.Raymond 在其著名的论文《大教堂与集市》中论证了开源的软件工程理论。如他所定义的 Linus 定律：众目睽睽之下，Bug 将无处藏身，模块化、去中心化、快速发布快速反馈等等是可行的，Kernel 就是成功的案例。 随着 Linux、Apache、Perl/Python/PHP、MySQL/PostgreSQL 等开源技术的崛起，以及技术的更新迭代，开源已经不再是稀缺，而是一种过剩，架构师在最初构建业务系统的时候，面临的不是创造，而是选择。于是开源项目又有了新的优势： 可以让业务快速的搭建原型 几乎以零成本的方式来进行 让产品迅速进入市场，获得及时反馈。 开源的理论知识或许太过深奥、晦涩。接下来我就接地气地讨论下面几个实际问题： 为什么要加入开源社区？ 加入社区的门槛有哪些？ 加入社区你能做什么？ 加入社区如何正确互动提问？ 加入社区有哪些收益？ 为什么要加入开源社区？ 本文开篇说到过，开源已经无处不在，不管你是从事架构、开发、运维、算法还是产品、运营，只要你从事计算机与互联网相关工作，总有“一款”开源社区适合你，你可以从该社区中获益。 加入社区的门槛有哪些？ 最近在邀请身边的朋友加入社区时，偶尔发现有人这样回答：我现在水平还不够，等以后知识水平提升了再加入吧。如果这位是在诚实地回答，我想告诉你的是，加入开源社区原则上并没有门槛。不限于其经验水平、性别、性别认同和表达、性取向、残疾、个人外貌、体型、人种、种族、年龄、宗教或国籍等。如果一定要在加上一个门槛的话，我希望你能有参与社区建设的热情、你懂得社交的基本礼仪、你有一定责任心与荣辱感，你能遵守社区的行为准则与国家地区的法律法规！ 加入社区你能做什么？ 很重要的一点，加入社区的个体可以做什么，可以在其中扮演怎样的角色！这个可能需要看社区本身的性质。如果是开源项目官方社区，加入社区后，你可以参与讨论如何贡献代码，参与技术方案的决策，当然也可以参与“疑难杂症”的讨论或者提问。如果社区的性质是终端用户社区，比如某个技术领域或者某个开源项目在中国的本地社区，那么加入社区你有很多事可以做，包括但不限于： 参与技术话题讨论与交流 参与官方文档汉化活动（翻译） 参与或协办线上线下活动 技术文章（原创/翻译）投稿 在社区内进行技术分享 参与社区组织的电子书的写作 参与社区网站的构建和维护 宣传自己热爱的开源项目 其它 正如第二点所说，加入社区本身没有门槛，但是加入社区后具体能做些什么取决于个体本身的水平和能力。社区是由个体组成，社区伴随个体共同成长。