Istio on 小盒子的技术分享

拒绝内卷！为什么我们应该抵制用 LeetCode 考查真实的工程师？

Wed, 04 Mar 2026 08:41:32 +0000

拒绝内卷！为什么我们应该抵制用 LeetCode 考查真实的工程师？

如果你要招募一位主刀医生，你会让他当场默写《人体解剖学》的第一章吗？如果你要找一位米其林大厨，你会蒙住他的眼睛，让他比赛在一分钟内切出多少根标准厚度的土豆丝吗？

显然不会。但在如今的软件工程招聘中，我们却在做着同样荒谬的事情：让那些在复杂的业务泥潭中摸爬滚打、主导过千万级并发系统、熟练操纵复杂云原生架构的资深工程师，站在白板前，徒手写出一个“翻转二叉树”或者“接雨水”的最佳时间复杂度解法。

不知从何时起，“刷 LeetCode”已经从一种思维训练，演变成了一场病态的军备竞赛。是时候戳破这个泡沫了：LeetCode 根本选拔不出优秀的软件工程师，它正在毁掉我们的行业生态。

一、真实的工程世界，从来不是一道“闭卷考试”

让我们先来看看，一个现代软件工程师的真实一天是怎样度过的。

你可能会花一整个上午，在一堆没有注释的“屎山”代码中追踪一个诡异的内存泄漏问题；你可能会在下午和产品经理反复拉扯，确定一个新功能在微服务架构下的 API 边界；你可能会在排查为什么 Kubernetes 集群里的 HPA（水平Pod自动扩缩容）没有按预期触发，或者研究 Istio 网关的流量路由策略。

如果你身处最前沿的 AI 领域，你可能正在评估是用 LangGraph 还是 AutoGen 来构建多 Agent 协同流，或者在调试大模型 API 的 Top-p 采样参数，试图让生成的回答既准确又具有随机性。甚至，在业余时间，你可能在设计一款解决自己痛点的小工具——比如一个用来清理、分类和管理繁杂书签的浏览器插件。

这些工作有一个共同点：它们都是极其复杂的、高度依赖上下文的、开放性的问题。

而在真实的工作环境中，我们解决这些问题依靠的是什么？

1.查阅文档与搜索能力：我们有 Google、有官方文档、有开源社区，甚至现在还有 AI 助手。

2.调试与试错能力：我们通过打日志、单步调试、看监控指标来定位问题。

3.架构视野与经验直觉：我们知道什么时候该用单例模式，什么时候该用工厂方法；我们知道在高并发下如何设计缓存策略，如何保证数据一致性。

4.沟通与协作：我们需要阅读别人的代码，也需要让别人看懂我们的设计。

反观 LeetCode 面试，它创造了一个极其不真实的无菌实验室环境：

●题目边界清晰，输入输出明确。

●只有单一的“最优解”（通常是时间复杂度和空间复杂度的极限）。

●不允许查阅文档，甚至不允许使用趁手的 IDE（有时只能在网页的纯文本框里写代码）。

●偏离日常使用的技术栈（你可能用 Python 写了十几年业务，却要用 C++ 的思维去考虑指针和内存管理）。

这就像是要求一个现代战争中的王牌飞行员，在面试时去比拼谁的射箭准头更好。它考察的不是“解决问题的能力”，而是“在极其受限条件下的默写能力”。

二、刷题面试，正在惩罚真正有经验的“老兵”

在软件开发领域，经验是一笔巨大的财富。一个拥有 10 年、15 年工作经验的研发架构师，他最大的价值并不在于写代码的速度有多快，而在于他踩过足够多的坑。

资深工程师知道，一个系统最大的危机往往不是算法复杂度从变成了（很多时候硬件资源和缓存机制完全能弥补），而是：

●数据库连接池配置不当导致的雪崩。

●缺乏熔断降级机制导致的服务级联故障。

●领域模型设计错误导致的后续需求无法扩展。

●业务逻辑耦合过深导致的测试困难。

然而，当这位资深架构师带着一身的实战本领走进面试房间时，等待他的却是一道“动态规划（DP）”的 Hard 题。

这是一种极大的资源浪费。一个能在生产环境中稳稳掌控全局、能设计出高可用 AI 基础设施、能带领团队攻坚克难的资深人才，仅仅因为最近几个月忙于项目交付、或者忙于应对生活中的变故（比如寻找新机会、照顾家庭），没有抽出几百个小时去死记硬背算法题库，就被无情地贴上“技术不过关”的标签淘汰出局。

这种现象导致了一个极其荒谬的倒挂：

那些刚刚毕业、没有写过一行生产环境代码、不懂得什么是持续集成、不知道如何进行线上排障的学生，只要花三个月把 LeetCode 刷个滚瓜烂熟，就能在面试中大杀四方；而那些真正在一线扛过枪、打过仗，能够解决复杂工程灾难的老兵，却在白板前因为忘记了一个状态转移方程而涨红了脸。

企业以为自己招到了“绝顶聪明”的天才，结果新人一入职，面对极其复杂的微服务依赖和一团乱麻的业务逻辑，立刻束手无策。因为真实的业务系统里，没有人会为你准备好整洁的 ListNode 或者 TreeNode。

三、算法题面试的本质：一场低效的“智商服从性测试”

为什么即便怨声载道，这么多公司依然痴迷于 LeetCode 面试？很多面试官会辩解说：“算法题能考察候选人的聪明程度和逻辑思维。”

这其实是一个伪命题。

1. 算法题早就不测智商了，它只测“准备度”。

在互联网早期，用算法题面试确实能筛选出一些思维敏捷的人，因为那时没有题库。但现在，LeetCode 已经有上千道题，“面经”满天飞。面试不仅变成了开卷考试的闭卷化，更变成了一门应试产业。能解出 Hard 题，往往不意味着你绝顶聪明，只意味着你刷到过原题，或者你花了大把时间去背诵套路。这充其量是一场“服从性测试”——看候选人愿不愿意为了这份工作去吃毫无意义的苦。

2. 忽视了工程中最关键的“可维护性”。

在 LeetCode 的评价体系里，“代码跑得快”是唯一的真理。哪怕你的代码里全是 i, j, k, dp, res 这种毫无语义的变量名，哪怕你的逻辑晦涩难懂如天书，只要能 AC（Accepted），你就是赢家。

但在实际工程中，这种代码是灾难。好的工程师写出的代码是给人看的，其次才是给机器执行的。如果你的代码在生产环境中出了 Bug，同事半夜被叫醒排查，看到满屏追求极致技巧却毫无注释的“炫技代码”，他大概率会在心里把你骂上一万遍。LeetCode 培养出的“做题家”思维，与团队协作所需的工程素养往往是背道而驰的。

3. 面试官的“安全牌”与偷懒。

其实，很多面试官也根本不知道该怎么面试。对他们来说，从题库里随机抽一道题扔给候选人，是最省事、最没有风险的做法。如果你没写出来，那是你不行，面试官不需要承担招错人的责任。这种做法掩盖了面试官自身架构视野和识人能力的匮乏。要深入了解一个人的项目经验、技术深度和系统设计能力，需要面试官投入极大的精力和极高的技术水平去进行深度的技术探讨，而“考一道题”则轻易地把压力全抛给了候选人。

四、如何打破僵局：回归工程本质的面试方法

批判之后，我们需要建设。如果不考 LeetCode，我们该怎么筛选优秀的软件工程师？真正的面试，应该是一场对日常工作的高度模拟。

1. 结对编程 (Pair Programming)

不要让候选人在白板上写代码，给他一台配置好 IDE 的电脑。面试官准备一个真实但简化过的业务小项目，或者直接在公司的一个开源代码分支上，两人结对协作。

●“我们现在有一个 Python 的服务端，用 FastAPI 写的，现在需要增加一个中间件来做简单的限流，你打算怎么做？”

●允许候选人查阅文档，允许使用 Google。

●观察他的编码习惯、他对框架的熟悉程度、他如何拆解问题，以及更重要的——他如何与你沟通和协作。

2. 代码审查 (Code Review)

给候选人一段存在各种“坑”的代码（可以是以前团队写出的真实烂代码，隐去敏感信息）。这段代码可能存在并发竞争、内存泄漏、或者设计模式的滥用。

让候选人进行 Code Review。优秀的工程师能立刻嗅出代码中的“坏味道”，并提出合理的重构建议。这比让他默写快速排序要有效得多。

3. 深度系统设计与项目复盘

抛弃那些假大空的“如何设计一个推特”的八股文。让候选人深度讲解他简历中最自豪的一个项目。

●“你在简历中提到主导了容器化改造，能画一下当时的 Kubernetes 架构图吗？”

●“在使用 Ingress 和服务网格（比如 APISIX 或 Istio）时，你们遇到了什么性能瓶颈？是如何排查的？”

●“你提到在做 AI 相关的研发，在整合底层大模型接口时，你们是如何处理长上下文带来的延迟问题和 token 消耗的？”

通过深度的追问，直到触及他的知识边界。真正的行家，在谈论自己亲手一砖一瓦建起来的系统时，眼里是有光的，细节是经得起推敲的。

4. 聊聊他创造的“小玩意儿”

一个真正的工程师，往往是对技术充满热情的创造者。与其问算法，不如问问他平时都在折腾什么。如果他告诉你，他因为受不了浏览器书签太乱，正在自己设计开发一个管理书签的插件；或者他为了解某种新技术栈，自己搭了一个爬虫和数据展示网站。请让他展示一下！这种对痛点的敏锐察觉和动手解决问题的能力，是任何算法题都无法衡量出的核心特质。

五、结语：放过工程师，也放过企业自己

技术招聘走到今天“无算法不面试”的地步，是整个行业的悲哀。它消耗了工程师们原本可以用来学习新框架、钻研底层原理、甚至陪伴家人的宝贵精力；它也让企业错失了大量踏实肯干、经验丰富的实战派人才。

编程，是一门结合了逻辑、工程、设计甚至艺术的创造性活动。它不该被简化为一场机械的背诵比赛。

作为面试官，下次当你准备掏出一道 LeetCode Hard 题时，不妨停下来问问自己：“这道题，真的能帮我找到那个能和我并肩作战、一起扛住双十一流量洪峰、一起在深夜排查诡异 Bug 的可靠队友吗？”

如果不能，请放下那道该死的算法题，和候选人像真正的工程师一样，聊聊真实的架构，看看真实的代码。

把时间还给工程，把尊严还给工程师。

2025北京 IT技术岗位市场趋势分析

Thu, 17 Apr 2025 02:20:56 +0000

过去一年，北京数字经济对 GDP 的贡献继续攀升、AI + 传统产业融合提速，拉动技术岗位需求在 2025 年保持“量稳、质升”——总招聘量与 2024 年大体持平，但 高端与 AI‑相关职能增幅 15% 以上；与此同时，普通开发与测试岗位竞争加剧、薪酬增速放缓。整体呈现“尖端紧缺‑常规内卷”的双轨格局。

下面按岗位类型分述趋势、薪酬区间与热门技能。

宏观驱动与整体需求

北京仍是全国数字经济第一城，数字产业增加值年均增速 9%，5G、人工智能、信创（国产软硬件）成为新增岗位主引擎
2025 Hays 人才趋势显示，生成式 AI 项目扩张、混合办公、用工灵活化 是企业技术团队的三大关键词。
拉勾《一线城市数字科技人才迁徙洞察》指出，北京对高端技术人才的 净流入率 17.8% ，居四大一线城市之首，但应届生流入比例下降 4 pct，反映供给结构趋紧。
信息技术业 2024Q2‑2025Q1 招聘量同比下滑 27.8%，但算法、运维支持、产品管理等职能逆势增长。

细分岗位趋势

前端开发

重点趋势	说明
框架	React18、Vue3 + TypeScript 成主流；大厂面试开始考察 RSC、微前端落地经验。
多端融合	ByteDance、京东等推行 Modular/Universal mode，将 H5 + 小程序 + 桌面统一到一套代码。
AI‑Assist	高频使用 GitHub Copilot、ByteDance CodeGeeX 等 AI 辅助，企业更看重 Prompt‑Engineering 基础。

平均月薪区间 2 – 3.5 万元；头部公司核心前端 > 4.5 万元。

后端／全栈开发

Go + Rust 在高并发与可信场景快速渗透，Java 依旧占 48% 招聘量。
Cloud‑Native：K8s、Service Mesh、Sidecar 架构写入 JD；Serverless FaaS 试点项目增多。
薪酬与前端近似，但 3–6 年经验段的涨幅（+6.8% YoY）高于前端。

运维 / SRE

自动化 & AIOps：日志可观测、LLM‑based Root Cause Analysis 成新卖点。
大厂 DevOps‑SRE 岗位给出 15k–50k/月，中位值 34k，高于全国均值 21k
需求集中在云平台运维、容器治理、CI /CD 流水线二次开发。

测试 / QA

Shift‑Left：招聘 JD 要求能写 E2E、契合 DevSecOps；懂 API/性能/安全一体的 Full‑Stack QA 稀缺。
普通功能测试招聘量降 12%，月薪中位值 14k；自动化 / 安全测试可达 2 – 2.5 万元。

架构 / AI 大模型

大模型平台化：企业亟需能打通推理服务、RAG、知识治理的“业务 + 算法 + 云”复合型架构师。
北京人社局薪酬季报：AI 大模型架构师、深度学习研究员一季度月薪中位值 > 4 万元，位列所有 IT 职位之首。
供应缺口：相关岗位投递比仅 1 : 7，而常规开发已超过 1 : 40。

薪酬对比（中位值，税前 / 月）

职能	初级 (0‑3 年)	中级 (3‑6 年)	高级 / 专家	YoY 涨幅
前端	14 k	23 k	32 k+	+3.5 %
后端	15 k	25 k	35 k+	+6.8 %
运维 / SRE	16 k	28 k	40 k+	+5.9 %
测试	12 k	18 k	25 k	+2.1 %
架构 / AI	25 k	38 k	45‑60 k	+11.4 %

（数据综合北京 HR 局薪酬季报、Indeed、Jobui 与 iHR360 行业库）

🔥 技能热点与企业偏好

AI 嵌入：Prompt‑based 代码补全、Auto‑Test、知识库问答等场景让 Python / LLM SDK 成为附加加分项。
安全合规：等保 2.0、个人信息保护法落地，带动安全测试、DevSecOps、零信任架构招聘量增 19% YoY
信创：国资系招募国产 CPU / OS 适配工程师，优惠补贴年包 +20%。

供需与竞争

北京技术岗位投递量继续领跑一线城市；但 AI、大模型方向平均 每 1 份 JD 仅 7 份简历，反之普通 Web 开发超过 40 份简历/岗，显现结构性紧缺。
北京 2025Q1 IT 岗位平均薪资 2.9 万元，中位值 2.46 万元；同比涨幅 1.1%，明显低于 2021‑22 年两位数增速。

给企业与求职者的建议

企业

拆分 JD：将“平台研发”与“AI 应用落地”拆分，便于精准匹配候选人。
用薪酬+Tech Brand 双重激励：高端人才更看重技术氛围与成长空间，可开放技术博客、OSS 贡献等展示窗口。
培养内部转岗：参考 LinkedIn 数据，内部流动可将员工留存提升 40%

求职者

普通开发/测试应持续补齐 云原生 + 自动化测试 + 基础 AI；
关注国央企“信创”“数据要素”等长期项目，以稳就业与培训机会为优势；
AI & 架构方向建议组合 算法实践 + 高并发系统设计 + 行业领域知识，扩大竞争壁垒。

“

北京 2025 年 IT 技术岗位的主旋律是 “AI 驱动的高端岗位紧缺，传统岗位理性回调”。掌握新技能、拥抱跨领域融合将是穿越周期的关键。

云原生，你真的懂了吗？

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 所说：“技术终将老去，但优秀的架构思想永存。” 在这场变革中，比掌握某个工具更重要的，是建立持续进化的云原生思维体系。

灰度发布、蓝绿部署、金丝雀都是啥？

Tue, 19 Apr 2022 07:13:43 +0000

滚动部署

在滚动部署中，应用的新版本逐步替换旧版本。实际的部署发生在一段时间内。在此期间，新旧版本会共存，而不会影响功能和用户体验。这个过程可以更轻易的回滚和旧组件不兼容的任何新组件。

下图显示了该部署模式：旧版本显示为蓝色，新版本显示为绿色，它们部署在集群中的每一台服务器上。

应用程序套件升级是一个滚动部署的典型例子。如果原始应用部署在容器中，升级可以一次处理一个容器。修改每个容器从应用供应商的站点上下载最新的镜像。如果其中的一个应用存在兼容性问题，旧的镜像可以重新创建这个容器。在这种情况下，套件的新旧版本应用可以共存，直到每个应用都更新完毕。

但是滚动升级有一个问题，在开始滚动升级后，流量会直接流向已经启动起来的新版本，但是这个时候，新版本是不一定可用的，比如需要进一步的测试才能确认。那么在滚动升级期间，整个系统就处于非常不稳定的状态，如果发现了问题，也比较难以确定是新版本还是老版本造成的问题。

为了解决这个问题，我们需要为滚动升级实现流量控制能力。

蓝绿发布

蓝绿发布提供了一种零宕机的部署方式。不停老版本，部署新版本进行测试，确认OK，将流量切到新版本，然后老版本同时也升级到新版本。始终有两个版本同时在线，有问题可以快速切换。

蓝绿发布的特点：

在部署应用的过程中，应用始终在线。并且新版本上线过程中，不会修改老版本的任何内容，在部署期间老版本状态不受影响。只要老版本的资源不被删除，可以在任何时间回滚到老版本。

以下示意图可描述灰度发布的大致流程：先切分20%的流量到新版本，若表现正常，逐步增加流量占比，继续测试新版本表现。若新版本一直很稳定，那么将所有流量都切分到新版本，并下线老版本。

切分20%的流量到新版本后，新版本出现异常，则快速将流量切回老版本。

蓝绿部署要求在升级过程中，同时运行两套程序，对硬件的要求就是日常所需的二倍，比如日常运行时，需要10台服务器支撑业务，那么使用蓝绿部署，你就需要购置二十台服务器。

为什么还需要蓝绿

有了灰度发布之后，为什么还需要蓝绿发布呢？主要有如下几点考虑：

应用在生产环境全量发布后，发现故障时回滚时间慢。当线上核心应用存在几十上百的服务实例时，应用实例分批滚动回滚，部分业务应用启动时间需要几分钟，导致整个回滚过程的时间可能超过十分钟，甚至几十分钟。
灰度发布期间能发现的问题有限。如数据库慢查问题、死锁问题等，10%流量很难发现，可能只会在100%流量中才容易暴露。
灰度发布成功后，仍然需要进行全量发布，在此过程中仍有较多不确定性，如因一些未预料的异常导致发布失败等。

对于上面几个问题，使用蓝绿发布系统都可以较好地解决：

蓝绿发布期间，流量全部切至新集群时，原稳定集群继续保持在线，若新集群有问题，可通过流量控制秒级切回至原稳定集群，没有应用启动以及其他等待时间。
蓝绿发布期间，新集群规模与原稳定集群规模一致，即使是瞬时大流量也没有问题。
蓝绿发布期间，新集群承载全站流量，容易验证各种场景，如数据库死锁等并发问题。
蓝绿发布新集群验证完成后，已经处于正常服务状态，不会再引入不确定性的变更操作。

金丝雀发布（canary）

在生产环境上引一部分实际流量对一个新版本进行测试，测试新版本的性能和表现，在保证系统整体稳定运行的前提下，尽早发现新版本在实际环境上的问题。

“

为什么叫金丝雀发布呢，是因为金丝雀对矿场中的毒气比较敏感，所以在矿场开工前工人们会放一只金丝雀进去，以验证矿场是否存在毒气，这便是金丝雀发布名称的由来。

”

金丝雀发布的特点：

通过在线上运行的服务中，新加入少量的新版本的服务，然后从这少量的新版本中快速获得反馈，根据反馈决定最后的交付形态。

下图为华为云的金丝雀发布界面：

步骤一：将流量从待部署节点移出，更新该节点服务到待发布状态，将该节点称为金丝雀节点；

步骤二：根据不同策略，将流量引入金丝雀节点。策略可以根据情况指定，比如随机样本策略（随机引入）、狗粮策略（就是内部用户或员工先尝鲜）、分区策略（不同区域用户使用不同版本）、用户特征策略（这种比较复杂，需要根据用户个人资料和特征进行分流，类似于千人千面）；

步骤三：金丝雀节点验证通过后，选取更多的节点称为金丝雀节点，重复步骤一和步骤二，直到所有节点全部更新

金丝雀部署和蓝绿有点像，但是它更加规避风险。你可以阶段性的进行，而不用一次性从蓝色版本切换到绿色版本。

采用金丝雀部署，你可以在生产环境的基础设施中小范围的部署新的应用代码。一旦应用签署发布，只有少数用户被路由到它。最大限度的降低影响。如果没有错误发生，新版本可以逐渐推广到整个基础设施。下图示范了金丝雀部署：

金丝雀和蓝绿的对比

名称	特点	优势	劣势
蓝绿部署	同时存在两个集群，两个集群中只有一个集群真正提供服务，另外一个集群测试、验证或待命	服务文档，版本回退简单，适用于各种场景的升级，大版本不兼容升级的或迭代兼容升级	浪费硬件资源，需要同时有两个集群，如果集群比较大，比如有1000个节点，这种方式几乎不可用
金丝雀部署	逐点部署，逐步替换线上服务	小步快跑，快速迭代	只能适用于兼容迭代的方式，如果是大版本不兼容的场景，就没办法使用这种方式了

灰度发布

灰度发布是迭代的软件产品在生产环境安全上线的一种重要手段。

灰度发布，也叫金丝雀发布。是指在黑与白之间，能够平滑过渡的一种发布方式。AB test就是一种灰度发布方式，让一部分用户继续用A，一部分用户开始用B，如果用户对B没有什么反对意见，那么逐步扩大范围，把所有用户都迁移到B上面来。灰度发布可以保证整体系统的稳定，在初始灰度的时候就可以发现、调整问题，以保证其影响度，而我们平常所说的金丝雀部署也就是灰度发布的一种方式。

A/B Test

A/B测试和蓝绿发布、滚动发布以及金丝雀发布，完全是两回事。

蓝绿发布、滚动发布和金丝雀是发布策略，目标是确保新上线的系统稳定，关注的是新系统的BUG、隐患。

A/B测试是效果测试，同一时间有多个版本的服务对外服务，这些服务都是经过足够测试，达到了上线标准的服务，有差异但是没有新旧之分（它们上线时可能采用了蓝绿部署的方式）。

A/B测试关注的是不同版本的服务的实际效果，譬如说转化率、订单情况等。

A/B测试时，线上同时运行多个版本的服务，这些服务通常会有一些体验上的差异，譬如说页面样式、颜色、操作流程不同。相关人员通过分析各个版本服务的实际效果，选出效果最好的版本。

实现

kubernetes

官方的金丝雀发布方式

https://kubernetes.io/zh/docs/concepts/cluster-administration/manage-deployment/#canary-deployments

Deployment滚动更新策略实现金丝雀发布

利用Deployment的滚动更新策略maxSurge和maxUnavailable设置最大可超期望的节点数和最大不可用节点数可实现简单的金丝雀发布。

rollingUpdate.maxSurge最大可超期望的节点数，百分比 10% 或者绝对数值 5

rollingUpdate.maxUnavailable最大不可用节点数，百分比或者绝对数值

 1apiVersion: extensions/v1beta1
 2kind: Deployment
 3metadata:
 4 name: demo-deployment
 5 namespace: default
 6spec:
 7 replicas: 10
 8 selector:
 9 matchLabels:
10 name: hello-deployment
11 strategy:
12 type: RollingUpdate
13 rollingUpdate:
14 maxSurge: 10%
15 maxUnavailable: 0 
16 template:
17 metadata:
18 labels:
19 name: demo-deployment
20 spec:
21 containers:
22 - name: webserver
23 image: nginx:1.14
24 ports:
25 - containerPort:80
26

Ingress-Nginx配置Ingress Annotations实现金丝雀发布

Ingress-Nginx 支持配置 Ingress Annotations 来实现不同场景下的金丝雀发布。Nginx Annotations 支持以下 4 种 Canary 规则：

nginx.ingress.kubernetes.io/canary-by-header：基于 Request Header 的流量切分，适用于灰度发布以及 A/B 测试。当 Request Header 设置为 always时，请求将会被一直发送到 Canary 版本；当 Request Header 设置为 never时，请求不会被发送到 Canary 入口；对于任何其他 Header 值，将忽略 Header，并通过优先级将请求与其他金丝雀规则进行优先级的比较。
nginx.ingress.kubernetes.io/canary-by-header-value：要匹配的 Request Header 的值，用于通知 Ingress 将请求路由到 Canary Ingress 中指定的服务。当 Request Header 设置为此值时，它将被路由到 Canary 入口。该规则允许用户自定义 Request Header 的值，必须与上一个 annotation (即：canary-by-header）一起使用。
nginx.ingress.kubernetes.io/canary-weight：基于服务权重的流量切分，适用于蓝绿部署，权重范围 0 - 100 按百分比将请求路由到 Canary Ingress 中指定的服务。权重为 0 意味着该金丝雀规则不会向 Canary 入口的服务发送任何请求。权重为 100 意味着所有请求都将被发送到 Canary 入口。
nginx.ingress.kubernetes.io/canary-by-cookie：基于 Cookie 的流量切分，适用于灰度发布与 A/B 测试。用于通知 Ingress 将请求路由到 Canary Ingress 中指定的服务的cookie。当 cookie 值设置为 always时，它将被路由到 Canary 入口；当 cookie 值设置为 never时，请求不会被发送到 Canary 入口；对于任何其他值，将忽略 cookie 并将请求与其他金丝雀规则进行优先级的比较。

注意：金丝雀规则按优先顺序进行如下排序：canary-by-header - > canary-by-cookie - > canary-weight很显然

canary-weight是一种随机策略。

canary-by-cookie和canary-by-header-value适合后端金丝雀发布实现

canary-by-cookie适合前端金丝雀发布实现。

 1apiVersion: extensions/v1beta1
 2kind: Ingress
 3metadata:
 4 name: demo-canary
 5 annotations: 
 6 kubernetes.io/ingress.class: nginx
 7 nginx.ingress.kubernetes.io/canary: "true"
 8 nginx.ingress.kubernetes.io/canary-by-header: "canary"
 9 nginx.ingress.kubernetes.io/canary-by-cookie: "canary"
10spec:
11 rules:
12 - host: demo-api.fulu.com
13 http:
14 paths:
15 - backend:
16 serviceName: demo-api-canary
17 servicePort: 80

具体流程

如果是第一次发布，必须是正常版本。
如果发布金丝雀版本，则先检测是否有-canary后缀的ingress、service、deployment，如果有则替换金丝雀版本的镜像，如果没有则创建-canary后缀的ingress、service、deployment。
如果发布正常版本，则先检测是否有-canary后缀的ingress、service、deployment，如果有则先删除它们，再替换正常版本的镜像。

蓝绿部署实现： https://www.cnblogs.com/itzgr/p/14602827.html

以上这些方式只是实现了一种非常简单的金丝雀发布流程，是没有办法做更精细，比如说按用户信息去灰度的规则的。对于同一个用户，也有可能一次请求到了金丝雀中，下一次请求又到了正式环境中。假如需要更加精细的灰度规则，可以考虑采用spring cloud, istio等工具

istio

Kubernetes 中的金丝雀部署

假设我们有一个已部署的 helloworld 服务 v1 版本，我们想要测试（或简单上线）新版本 v2。使用 Kubernetes，您可以通过简单地更新服务的 [Deployment] 中的镜像并自动进行部署来[上线]新版本的 helloworld 服务。如果我们特能够小心保证在启动并且在仅启动一个或两个 v2 副本[暂停]上线时有足够的 v1 副本运行，则能够保持金丝雀发布对系统的影响非常小。后续我们可以观察效果，或在必要时进行[回滚]。最好，我们也能够对 Deployment 设置 [HPA]，在上线过程中减少或增加副本以处理流量负载时，也能够保持副本比例一致。

尽管这种机制能够很好工作，但这种方式只适用于部署的经过适当测试的版本，也就是说，更多的是蓝/绿发布，又称红/黑发布，而不是 “蜻蜓点水“ 式的金丝雀部署。实际上，对于后者（例如，并没有完全准备好或者无意对外暴露的版本），Kubernetes 中的金丝雀部署将使用具有[公共 pod 标签]的两个 Deployment 来完成。在这种情况下，我们不能再使用自动缩放器，因为是有由两个独立的自动缩放器来进行控制，不同负载情况下，副本比例（百分比）可能与所需的比例不同。

无论我们使用一个或者两个部署，使用 Docker，Mesos/Marathon 或 Kubernetes 等容器编排平台进行的金丝雀发布管理都存在一个根本问题：使用实例扩容来管理流量；版本流量分发和副本部署在上述平台中并独立。所有 pod 副本，无论版本如何，在 kube-proxy 循环池中都被一视同仁地对待，因此管理特定版本接收的流量的唯一方法是控制副本比例。以小百分比维持金丝雀流量需要许多副本（例如，1％将需要至少 100 个副本）。即使我们可以忽略这个问题，部署方式功能仍然非常有限，因为它只支持简单（随机百分比）金丝雀部署。如果我们想根据某些特定规则将请求路由到金丝雀版本上，我们仍然需要另一种解决方案。

使用 Istio，流量路由和副本部署是两个完全独立的功能。服务的 pod 数量可以根据流量负载灵活伸缩，与版本流量路由的控制完全正交。这在自动缩放的情况下能够更加简单地管理金丝雀版本。事实上，自动缩放管理器仍然独立运行，其在响应因流量路由导致的负载变化与其他原因导致负载变化的行为上没有区别。

Istio 的[路由规则]也带来了其他的便利；你可以轻松实现细粒度控制流量百分比（例如，路由 1％的流量而不需要 100 个 pod），当然也可以使用其他规则来控制流量（例如，将特定用户的流量路由到金丝雀版本）。作为展示，让我们看一下采用这种方式部署 helloworld 服务的简单便捷。

首先我们定义 helloworld 服务，和普通 Kubernetes 服务一样，如下所示：

 1apiVersion: v1
 2kind: Service
 3metadata:
 4name: helloworld
 5labels:
 6 app: helloworld
 7spec:
 8 selector:
 9 app: helloworld
10 ...
11

然后我们添加 2 个 Deployment，分别为版本 v1 和 v2，这两个版本都包含服务选择标签 app：helloworld

 1kind: Deployment
 2metadata:
 3 name: helloworld-v1
 4spec:
 5 replicas: 1
 6 template:
 7 metadata:
 8 labels:
 9 app: helloworld
10 version: v1
11 spec:
12 containers:
13 - image: helloworld-v1
14 ...
15---
16apiVersion: extensions/v1beta1
17kind: Deployment
18metadata:
19 name: helloworld-v2
20spec:
21 replicas: 1
22 template:
23 metadata:
24 labels:
25 app: helloworld
26 version: v2
27 spec:
28 containers:
29 - image: helloworld-v2
30 ...

需要注意的是，这与使用普通 Kubernetes 进行[金丝雀部署]的方式完全相同，但是在 Kubernetes 方式下控制流量分配需要调整每个 Deployment 的副本数目。例如，将 10％的流量发送到金丝雀版本（v2），v1 和 v2 的副本可以分别设置为 9 和 1。

但是在[启用 Istio] 的集群中，我们可以通过设置路由规则来控制流量分配。如将 10％的流量发送到金丝雀版本本，我们可以使用 kubectl 来设置以下的路由规则：

 1kubectl apply -f - <<EOF
 2apiVersion: networking.istio.io/v1alpha3
 3kind: VirtualService
 4metadata:
 5 name: helloworld
 6spec:
 7 hosts:
 8 - helloworld
 9 http:
10 - route:
11 - destination:
12 host: helloworld
13 subset: v1
14 weight: 90
15 - destination:
16 host: helloworld
17 subset: v2
18 weight: 10
19---
20apiVersion: networking.istio.io/v1alpha3
21kind: DestinationRule
22metadata:
23 name: helloworld
24spec:
25 host: helloworld
26 subsets:
27 - name: v1
28 labels:
29 version: v1
30 - name: v2
31 labels:
32 version: v2
33EOF
34

当规则设置生效后，Istio 将确保只有 10% 的请求发送到金丝雀版本，无论每个版本的运行副本数量是多少。

以上是使用istio 进行的金丝雀部署，当然蓝绿也是类似的。

spring cloud

spring cloud gateway也可以实现灰度发布，另外还有一款 spring cloud 的增强组件，可以实现灰度、蓝绿等功能（Discovery: https://github.com/Nepxion/Discovery）

网关

利用云原生网关比如 APISIX ：

https://apisix.apache.org/zh/docs/apisix/plugins/traffic-split/#蓝绿发布
https://apisix.apache.org/zh/docs/apisix/plugins/traffic-split/#灰度发布

参考

istio 原理简介

Fri, 19 Nov 2021 07:46:22 +0000

前导

由于 istio 自 1.5 版本以后架构上有了较大变化，控制面从多组件变成了单体的 istiod 组件，所以下文会先介绍 1.5 之前的架构，再介绍 1.5 之后的，是一个由繁到简的过程。

istio 1.5 之前架构

Istio 的架构分为控制平面和数据平面

数据平面：由一组智能代理（Envoy）以 sidecar 模式部署，协调和控制所有服务之间的网络通信。
控制平面：负责管理和配置代理路由流量，以及在运行时执行的政策。

可以看到控制面（control plane ）组件众多，下图是 1.1 版本所包含的组件：

istio 工作原理

我们先按照 1.5 版本之前的架构描述

Sidecar 注入 (envoy)

详细的注入过程可以参考：https://blog.yingchi.io/posts/2020/6/istio-sidecar-injection.html

连接（pilot）

控制 && 观测（mixer telemetry、mixer policy）

保护（citadel）

配置

Galley 原来仅负责进行配置验证，1.1 后升级为整个控制面的配置管理中心，除了继续提供配置验证功能外，Galley 还负责配置的管理和分发，Galley 使用网格配置协议 (Mesh Configuration Protocol) 和其他组件进行配置的交互。

提供 istio 中的配置管理服务，验证 Istio 的 CRD 资源的合法性

istio 各组件功能及作用

istio-polit: 服务发现，向数据平面下发规则，包括 VirtualService、DestinationRule、Gateway、ServicEntry 等流量治理规则，也包括认证授权等安全规则。
istio-telemetry: 专门收集遥测数据的 mixer 服务组件。
Istio-policy: 另外一个 mixer 服务，可以对接如配额、授权、黑白名单等不同的控制后端，对服务间的访问进行控制。
Istio-citadel: 核心安全组件，提供了自动生成、分发、轮换与撤销秘钥和证书的功能。
Istio-galley: 配置管理的组件，验证配置信息的格式和内容的正确性，并将这些配置信息提供给管理面的 Pilot 和 Mixer 使用。
Istio-sidecar-injector: 负责自动注入的组件。
Istio-proxy: 数据面的轻量代理。
Istio-ingressgateway: 入口处的 gateway。

istio 1.5 之后架构

之前版本的 istio 对组件进行了很好的解耦，组件们各司其职，当然也带来了组件比较多的问题。可以看到新版本将众多组件包装在了一起叫 istiod

所以新版本 istio 核心组件就只剩下一个：istiod

参考

血泪经验：使用SkyWalking 和 Envoy 访问日志服务对 istio 进行观察（一）

Fri, 25 Jun 2021 11:37:02 +0000

分享一个宝贵的经验

我们想利用 skywalking 收集 istio 的 envoy 日志，进而利用 skywalking 查看 istio 的 trace、log等。

但这里面有个坑，就是 istio 和 skywalking 的版本问题。我们 istio 使用的是1.3版本，skywalking 8.3 。

经过华为和 skywalking 核心开发者的确认，版本对应关系如下：

istio 1.3 不支持生产 skywalking 使用
istio 1.7以上 skywalking 链路拓扑可以商用
istio 1.8 skywalking 日志商用
istio 1.11 trace 商用

所以结论是得升级 istio，然后再去集成 skywalking。

后续随着 istio 的升级将继续结合 skywalking 进行操作，并输出具有更多细节的文章。

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

上了 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/

2020 小盒子的年度总结

Sun, 27 Dec 2020 12:41:24 +0000

这一年过得真快，转眼还有 4 天 2020 年就过去了。

这一年发生了好多事，有好的也有坏的。

昨天看到网友的年度总结，十分感慨，想来今年我们都度过了十分特殊的一年，仅以此文，寥做总结，希望这是未来 10 年中最差的一年。

健康

今年可以说是身体上出状况最多的一年，去年的湿疹刚好，夏天时突然骨折，骨折养到一半又突发肾结石。在吾妻悉心的照顾下，还好并无大碍。

今年应该是我最胖的一年，很多人没见过我大学时清瘦的模样，我想也回不到从前了。上半年还挣扎过，跟体重较了几个月的劲，下半年就放弃了。无它，我认了，健康就好。

感情

吾妻这两年由于各种事情的原因回归家庭，照顾我、照顾猫。其实距离我们婚礼举行也就一年多，婚礼的誓词还时常萦绕在耳边，但总感觉像老夫老妻一样，越来越默契了，也许是一起经历过太多的事情。在生活面前，共同经历多少真刀真枪的兵荒马乱，就有多少难舍难分的情深意重。

工作

岁末年初的时候创业失败，疫情期间离京在家过着与世隔绝的日子，夏初入职履新，后被拖欠工资，再求职，又履新。

新工作老板、同事、业务都算靠谱，从架构师做到技术总监，最近一个月没有一天 9点前下过班。我知道我没有什么天赋，所以勤奋是必备素质。

财务

今年确实没攒什么钱，经济压力比较大，加上不顺的事情太多，有些抑郁。初秋的时候和吾妻谈过一次，感觉这一年没真正开心过，最近一两月好多了。然而也收获到了金钱买不到的东西，我们夫妻的感情更好了，我也更沉着和更有耐心了。今后希望通过努力，将来我和我的家人再不用被金钱所迫。

输出

由于最近确实忙到飞起，公众号和专栏有一个月停更了。后续公司的事情走上正轨，会回归正常输出频率的。(文末有我今年的精选文章列表，欢迎大家查阅) 感谢很多圈内大佬的支持，感谢 APISIX、小林coding和耗子哥的关注。还有那些打赏、点赞的朋友们。

出书的计划确实被搁置了，不过也是好事，我想再储备储备，有些东西还是要深入浅出，有了更多的实践，尽可能不误人子弟。

技术

架构

今年换了两个架构，以 spring cloud 为主的 docker 集群，和 k8s on istio 架构。新公司的 k8s on istio 直到现在我仍然认为是激进的，后期会根据实际情况进行合理调整。

基础

说来奇怪，做技术的时间越长，好奇心越重，从年初读完《上帝掷骰子吗？》开始，对很多东西产生了越发浓厚的兴趣。还记得我入行的前几年，曾一度自我怀疑，我到底适不适合干这行？很多东西真的很难，很枯燥。现在却觉得越来越有意思，也许我没什么天赋，但至少没有放弃。坚持可能才是最难的。

未来

由于缺憾导致人有更强烈的欲望，面对未来我想做一个更加坚毅、果敢、勇往直前的人。

最后

明明自己生活也过得不如人意却还是见不得这人间疾苦。2020 年就要过去了，我一点儿都不怀念它。

2020年度精选文章：

转载）从MySQL InnoDB 物理文件格式深入理解索引

我对 MySQL 锁、事务、MVCC 的一些认识

分布式事务：从理论到实践（三）

分布式事务：从理论到实践（二）

分布式事务：从理论到实践（一）

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

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

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

持续演进的Cloud Native (读书笔记05)

Tue, 10 Mar 2020 16:00:00 +0000

未来值得关注的方向

Serverless
无服务器架构是基于互联网的系统，它的应用开发不使用常规的服务进程。相反，它仅依赖于第三方服务（例如 AWS Lambda 服务），是客户端逻辑和服务托管远程过程调用的组合
什么是Serverless
Service Mesh
Service Mesh是用于处理服务到服务通信的专用基础架构层。Cloud Native有着复杂的服务拓扑，它负责可靠地传递请求。实际上，Service Mesh 通常作为一组轻量级网络代理实现，这些代理与应用程序代码部署在一起，应用程序无感知。随着Cloud Native的崛起，Service Mesh逐步发展为一个独立的基础设施层。在Cloud Native架构下，单个应用程序可能由数百个服务组成；每个服务可能有数千个实例；并且这些实例中的每一个实例都可能处于不断变化的状态，因为它们是由诸如Kubernetes之类的资源调度系统动态调度的。这个世界中的服务通信不仅非常复杂，而且是运行时行为的普遍和基本部分，管理它对于确保端到端的性能和可靠性至关重要。
什么是Service Mesh

研发流程

十二因子
基准代码
一份基准代码，多份部署
使用 GIT 或者 SVN 管理代码，并且有明确的版本信息
依赖
显式声明依赖关系。
如Java中我们可以使用Maven或者Gradle管理依赖包
配置
在环境中存储配置
第一，可以将应用的配置存储于环境变量中；第二，可以将应用的配置存储于分布式配置中心。
后端服务
把后端服务当作附加资源
构建、发布、运行
严格分离构建和运行
十二因子强调通过CI/CD（持续集成/持续布置）工具实现整个过程，例如使用Jenkins。
进程
以一个或多个无状态进程运行应用
端口绑定
通过端口绑定提供服务
并发
通过进程模型进行扩展
易处理
快速启动和优雅终止可最大化健壮性
开发环境与线上环境等价
尽可能保持开发、预发布、线上环境相同
日志
把日志当作事件流
管理进程
把后台管理任务当作一次性进程运行
Code Review的意义
Code Review，顾名思义，就是针对一名开发人员完成的代码，让团队其他开发人员检查的过程。很多公司都在开展 Code Review，但是绝大多数公司只是流于形式，并没有形成一种文化。Code Review更多依靠的是小团队的工匠精神和程序员个人的主观能动性
Code Review的原则
以发现问题为目标
不设置惩罚而应该采用正向激励的做法
不论资历
Code Review的过程
利用工具线上+线下结合
代码即设计
架构设计包含两方面，一是架构，二是设计。在敏捷开发中，架构并没有被抛弃，架构的思考可能发生在你理解需求的过程中，也可能来自你的经验；架构的结果可能是一个白板上简单的图，也可能需要详细调研，这与架构师的能力有关。设计需要耗费大量的时间和精力去做，设计会转移、分配到整个研发流程。
整个进化设计需要简单的架构+持续集成+重构+整个研发流程的设计来保证。
敏捷研发流程模糊阶段性的理由是：业务需求太多和技术变化速度太快。
这种设计上的转变实际上非常适合小规模、有强大战斗力的团队

团队文化

高效的会议
缩小会议范围
常规会议不应该超过45分钟
限制“意见领袖”的发言时长
提供平等的会议氛围
会议中的分歧不应该延伸到会议之外
如何留下你想要的人
充分沟通
给予尊重
肯定工作成绩
设定合适的岗位
设定更大的挑战

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

Istio on 小盒子的技术分享

拒绝内卷！为什么我们应该抵制用 LeetCode 考查真实的工程师？

拒绝内卷！为什么我们应该抵制用 LeetCode 考查真实的工程师？

一、 真实的工程世界，从来不是一道“闭卷考试”

二、 刷题面试，正在惩罚真正有经验的“老兵”

三、 算法题面试的本质：一场低效的“智商服从性测试”

四、 如何打破僵局：回归工程本质的面试方法

五、 结语：放过工程师，也放过企业自己

2025北京 IT技术岗位市场趋势分析

宏观驱动与整体需求

细分岗位趋势

前端开发

后端／全栈开发

运维 / SRE

测试 / QA

架构 / AI 大模型

薪酬对比（中位值，税前 / 月）

🔥 技能热点与企业偏好

供需与竞争

给企业与求职者的建议

企业

求职者

云原生，你真的懂了吗？

啥是云？

“云” 可以有多种形态

资源有啥？

云原生

本质

什么是不可替代的？

云原生的 “复杂性悖论”

结论

云原生应用

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

最后

灰度发布、蓝绿部署、金丝雀都是啥？

目录

滚动部署

蓝绿发布

为什么还需要蓝绿

金丝雀发布（canary）

金丝雀和蓝绿的对比

灰度发布

A/B Test

实现

kubernetes

istio

spring cloud

网关

参考

istio 原理简介

前导

istio 1.5 之前架构

Istio 的架构分为控制平面和数据平面

istio 工作原理

Sidecar 注入 (envoy)

连接 （pilot）

控制 && 观测 （mixer telemetry、mixer policy）

保护（citadel）

配置

istio 各组件功能及作用

istio 1.5 之后架构

参考

血泪经验：使用SkyWalking 和 Envoy 访问日志服务对 istio 进行观察（一）

分享一个宝贵的经验

上了 istio 的贼船之 API Gateway

上了 istio 的贼船之 API Gateway

现状

上了贼船

API Gateway

未来

还有没有问题？

性能如何？

参考资料

2020 小盒子的年度总结

健康

感情

工作

财务

输出

技术

一、真实的工程世界，从来不是一道“闭卷考试”

二、刷题面试，正在惩罚真正有经验的“老兵”

三、算法题面试的本质：一场低效的“智商服从性测试”

四、如何打破僵局：回归工程本质的面试方法

五、结语：放过工程师，也放过企业自己

连接（pilot）

控制 && 观测（mixer telemetry、mixer policy）