架构 on 冯威的博客

云原生：一文读懂核心技术栈与演进路径

Tue, 24 Jun 2025 14:36:00 +0800

最近，听老板说只要碰到一些大型项目，客户都要求使用云原生技术，让我们在技术储备上也要能跟得上。本文简单讲讲云原生的技术栈以及如何学习。

云原生（Cloud Native）近些年一直都是软件开发领域的热门话题之一。

什么是云原生？

云原生是一种设计和运行软件的方法论，核心思想是充分利用云平台提供的弹性、自动化和按需付费等特性，让应用更易于开发、部署和运维。关于云原生的概念，可以看看《简单聊聊云原生》。

很多人会问：我单体应用用得好好的，为什么要转向云原生这么复杂的架构呢？实际上，每一种新技术的出现都是为了解决已有问题，但同时也会引入新的挑战，权衡之下，如果利大于弊，就会采用。

下面我们来一步步分析，看看云原生技术是如何演变而来的。

云原生包含哪些技术栈？

目前主流的云原生技术栈（以 Pivotal 和 CNCF 技术栈为基础）包括：

微服务（Microservices）
容器（Containers，如 Docker）
容器编排（Container Orchestration，如 Kubernetes）
服务网格（Service Mesh）
声明式 API（Declarative API）
不可变基础设施（Immutable Infrastructure）
持续集成和持续交付（CI/CD）
DevOps
无服务器架构（Serverless）

企业为什么需要云原生？

对企业来说，降本增效非常重要，面对复杂的系统，使用云原生技术可以达到这个目的。

降低成本：通过容器技术，能提高资源利用率，降低整体成本。
提升效率：云原生架构下的部署更快速、更灵活，明显提升开发和交付效率。
提高业务承载力：云原生能快速扩容，应对高并发业务需求。
提升稳定性：健康检查和不可变基础设施让系统更稳定、更可靠。

云原生技术栈是如何演变的？

1、微服务

1967 年，计算机科学家梅尔文·康威（Melvin Conway）提出过一个观点：

组织的设计（包括其沟通结构和团队划分）会影响其生产的系统架构。具体来说，软件的架构往往反映了组织的沟通结构。

这就是著名的康威定律。

最初，软件往往是以单体应用的方式存在。当系统规模和业务复杂度增加时，组织就可能进行拆分，每一个小团队负责一个模块，这些团队甚至可能是分布式的。

组织的变化必然会让单体应用慢慢向微服务进行转变。不变不行啊，不然沟通成本太高了。

如果组织没有发生变化，强行去进行微服务拆分，会发现代码的管理、维护会变得复杂（即便是用上自动化工具），所以说有什么样的组织就有什么样的架构。

微服务将应用拆分成多个小而独立的服务，每个服务可以独立开发、部署、扩展，从而大大提高了灵活性和可维护性。但随之也出现了服务间通信复杂、部署管理困难等问题。

之前写的几篇微服务相关的文章：

《微服务：我们需要从单体转到微服务吗？》
《微服务：事务管理》
《微服务：如何拆分服务》
《微服务：服务间通信概述》

2、容器化（Docker）

微服务早在 2011 年就被提出，但近些年才火起来，靠的就是容器技术的普及。

微服务越来越多，手动部署变得异常复杂。Docker 这类容器技术的出现，使发布的程序和依赖的中间件能被封装到容器中，极大地简化了部署过程。

开发人员无需关注底层环境，容器的运行环境高度一致。在这之前，经常会有一些莫名其妙的问题，最后的原因就是各种环境配置的不一致。

然而，随着系统变得复杂，服务拆分的多，还要上各种中间件，容器数量就会越来越多，就会带来容器管理的问题，单靠 Docker 已经无法应对。

3、容器编排（Kubernetes）

容器编排技术随着容器化应用规模的扩大而诞生，主要是为了解决容器在生产环境中批量运行和管理的复杂性问题。最初，Docker 可以很好地处理单个或少量服务，但随着企业应用转向微服务架构，管理大量容器变得困难，仅仅靠人工的方式肯定会错漏百出。

为了解决这些问题，出现了容器编排技术，简单的有 docker compose ，测试环境和要求不高的生产环境中经常会用到。功能强大的有 Kubernetes ，提供自动部署、服务发现、负载均衡、健康检查、自动扩缩容等功能。

不过，容器编排技术的引入也会带来新的问题，包括系统复杂性提升、配置管理繁琐和安全性挑战。为应对这些问题，逐渐发展出了新工具，如 Helm、Rancher、OpenShift、Istio、Prometheus、Grafana 等。

4、服务网格（Service Mesh）

随着微服务规模扩大，服务间通信的管理要求变得更高，仅依靠 Kubernetes 等容器编排平台难以全面、高效地实现服务通信治理功能，就需要服务网格出场了。

服务网格（Service Mesh）是服务间通信的基础设施层。

它通过在微服务之间注入轻量级网络代理，统一处理服务发现、负载均衡、安全认证、流量控制、故障恢复等功能，非侵入式地解耦服务治理与业务逻辑。

到这可以发现，技术的演进都有相似性，本质上都是为了将通用能力从核心业务中剥离出来，通过更抽象、更统一的方式进行管理与复用。这种思路在软件开发的多个阶段中屡见不鲜。比如：

在架构阶段，API 网关将认证、限流、协议转换等边缘治理能力集中处理、配置中心实现了配置的集中化、动态化管理。
在编码阶段，我们引入了 AOP（面向切面编程）来将日志、事务、安全等横切关注点独立出来，实现与业务逻辑的解耦、通过工具类或SDK封装公共逻辑，提高复用性。

Istio 是目前比较火的一个开源服务网格，大概逻辑就是每个服务会被注入一个 Sidecar 组件，服务之间的通信会先经过 Sidecar，然后 Sidecar 再将请求转发给另一个服务。因为请求都经过Sidecar，所以可以通过 Sidecar 实现很多通用功能。

5、持续集成与持续交付（CI/CD）

服务变多，引入了更多的技术，系统变得更复杂了，就需要更多的手段来进行效率和稳定性的提升。

CI/CD 技术通过自动化的方式完成代码检查、测试、构建、部署任务。自动化不仅减少了人工操作带来的失误，也提升了迭代速度与产品质量。

CI 是持续集成，CD 有两层含义（持续交付和持续部署）。

持续集成：代码合并到特定分支的过程，这中间有静态扫描、单元测试等。
持续交付：将构建后的产物发布到测试环境，预生产环境。
持续部署：将经过充分测试的代码自动部署到生产环境。

CI/CD 可以让我们避免重复操作，提前发现问题，减少人工错误，让系统更加稳定。

从程序员到架构师，需要做些什么？

Thu, 14 Nov 2024 22:06:00 +0800

最近又面试了不少人，在谈及未来职业规划时，他们大多表示希望走技术路线，并期望未来能成为架构师。在软件开发领域，架构师是许多程序员梦寐以求的职位。它代表着技术能力的巅峰，也意味着更大的责任和挑战。

然而，从一名普通程序员成长为优秀的架构师，绝非一蹴而就。这是一个需要持续学习、实践和思考的漫长过程。

本文想以架构师的职责、误区和程序员怎么做转变，谈谈我的看法。

架构师的职责

在不同规模的公司中，架构师的职责存在差异。尽管一些小公司可能没有设立专门的架构师岗位，但架构相关的工作仍由技术经理或高级程序员等人员兼顾执行。

架构师负责系统的整体设计和技术决策，确保系统在满足业务需求的同时具备高性能、高可用性、高扩展性，也就是俗称的「三高」。架构师需要关注系统的功能性需求，但更重要的是非功能性需求。

架构师需要负责评估和选型适合项目的技术栈、开发工具、基础设施，进行技术调研，分析不同技术方案的优缺点，做出合理的技术决策，选择合适的设计模式和架构模式，以确保系统能够应对复杂的业务场景。

架构师需要制定并推广开发规范和编码标准，确保代码质量的一致性。确立系统设计和代码实现的最佳实践，如代码风格、命名规范、模块划分等，确保团队在项目中遵循相关标准和规范，降低代码复杂度，提高系统的可维护性。

另外，架构师还需要进行技术风险的评估和控制、团队内技术难点的攻克、团队内部的代码评审、培养团队的技术能力、组织知识分享和培训，持续关注技术趋势和行业防战，不断学习和研究新的技术等等。

对架构师的一些误区

1、从零开始设计一个系统

从零开始设计一个系统，还能全程参与，这是可遇不可求的机会。更多的情况是公司都有现成的架构体系。所以以架构师身份入职一个新公司，不太可能一开始就给你一个全新系统进行架构设计，更多的是做一些辅助性的工作。但只有做好每一件小事，当机会来了的时候，才会轮的上你。

2、只跟电脑打交道

估计有些程序员想成为架构师，或许是认为架构师的工作比较单纯，只用跟电脑打交道。但其实架构师作为技术和业务的桥梁，需要与产品经理、业务团队、开发团队和运维团队进行沟通。

沟通能力也是架构师一个非常重要的技能。

3、技术全能

很多人认为架构师是技术全能者，必须精通所有技术栈和工具。然而，架构师并非精通每一项技术细节，而是具备足够的广度来理解系统的整体架构和技术选型，能够做出权衡和取舍。架构师需要深入理解核心技术，并且知道在什么场景下应用合适的技术，而不是精通每一个细节。

4、只专注技术，不管业务

认为架构师只需要关注技术而不用理解业务。事实上，架构师不仅要关注技术，还要深入理解业务需求和业务流程，因为只有这样，才能设计出真正适配业务发展的系统架构。毕竟技术是为业务服务的，缺乏业务理解的架构往往难以支持公司长期战略。

什么是架构？

在说程序员到架构师转变之前，先说说什么是架构。

架构的本质

架构的本质在于为复杂系统提供一种结构化的设计方法，通过明确系统的核心组件、它们之间的关系以及交互方式，来确保系统能够满足功能需求、性能要求和可维护性标准。

架构的本质是抽象和简化，它将复杂的系统分解为可管理的部分，使得开发、维护和扩展变得更加可行和高效。同时，架构还承载着系统的愿景和战略方向，确保技术决策与业务目标保持一致。

架构的分类

按照不同的角度，架构可以有很多分类，但一般来说，主要分为业务架构、应用架构和技术架构。

业务架构描述了组织如何运作以实现其战略目标。包括业务功能、业务流程、组织结构、业务能力等。就是企业要发展，需要哪些业务能力来进行支撑。需要梳理核心业务的处理过程，定义各个业务模块的相互关系。比如：一个零售企业的业务架构可能包括：商品采购、库存管理、在线销售、客户支持等核心功能。

应用架构描述了企业的系统和应用如何支持业务需求，定义了应用的组织方式、交互方式以及应用与数据之间的关系。首先要确定需要哪些应用系统来支持业务，这些应用之间怎么做集成和交互。

技术架构架构描述了支撑应用系统的技术和基础设施，关注硬件、网络、数据库、编程语言、中间件等技术选型和部署。比如：使用什么技术实现应用？部署在什么环境？如何保证高并发、高可用性？如何确保数据的安全性等。

从程序员到架构师的成长阶段

从程序员到架构师的成长可以大致分为以下几个阶段：

1、初级程序员：这是最基础的技能积累阶段，主要学习编程语言、工具使用及完成基本任务。

2、中级程序员：在这个阶段，能够独立完成开发任务，包括需求分析、简单的方案设计。

3、高级程序员：开始指导其他工程师，并关注整体技术体系的建设，形成技术深度和广度。

4、架构师：能够独立完成系统的架构设计，考虑技术选型、系统的可扩展性与稳定性、关注不同模块间结构合理性的问题、关注技术架构的长期正确性。

在小公司可能不会严格按照级别去分，但我们还是需要沿着这个路径去学习和成长。

架构师需要具备的能力

首先一名优秀的架构师一定是一个出色的程序员，能写的一手好的代码。

在此基础上，架构师要有技术的广度和深度。广度尤为重要，程序员在熟悉的领域会钻研的很深，但没有广度，在一些跨系统的沟通场景下很难插上话，甚至连别人说的都听不懂。

能落地的架构才是好架构，所以架构师还需要具备良好的沟通能力，首先是能倾听各种不同的意见和建议，最后确保各方对架构达成共识，愿意采取一致的行动。

资源、时间永远都是紧张的，架构师还需要有良好的平衡和取舍能力，可以确保架构在现有资源约束下是最合理的，优先做最重要的事情，毕竟架构是不断进行迭代，慢慢进化的。

要成为一名优秀的架构师，需要具备以下几个关键能力：

1、技术深度与广度：架构师需要有扎实的技术功底和广泛的技术视野。这包括编程语言、框架、工具、系统设计、性能优化、安全等方面的知识，掌握技术细节是基础，尤其是在不同场景下如何取舍和优化。

2、业务理解能力：架构师不仅要懂技术，还要深入理解业务需求。只有充分理解业务，才能设计出真正符合需求的系统架构。

3、系统思维：架构师需要具备抽象思维、分治思维、复用思维和迭代思维。这些思维方式帮助架构师设计出灵活、可扩展的系统，减少后期维护的复杂度。

4、沟通能力：架构师需要与产品经理、开发人员、测试人员等多个角色沟通。除了架构设计本身，还需要通过文档和会议将设计理念传达给团队，让每个人都理解和使用好架构。

如何培养架构师能力？

1、积累经验：参与不同类型和规模的项目，尤其是复杂系统的设计和开发经验，对成长为架构师至关重要。在程序员阶段需要多进行换位思考，如果是自己来设计会怎么进行，和实际落地的进行比较，分析优缺点。

2、拓宽视野：学习各种技术和架构模式，了解它们的优缺点和适用场景。参与开源项目、阅读优秀的开源代码、参加技术交流活动，都是很好的方式。

3、深度思考：不断反思和总结，将经验转化为自己的知识体系，思考每个技术选择背后的原因及可能带来的影响。

4、保持编码实践：即使成为架构师，也要保持一定的编码实践。这有助于理解开发中的实际问题，验证架构设计的可行性。好的架构师一定是从一线程序员成长起来的，保持与代码的接触，才能设计出切实可行的架构。

5、关注业务发展：深入理解行业和公司业务，预测未来的发展趋势，帮助架构设计更具前瞻性。比如：你的公司如果是做 ToB 业务，又不分行业，那就需要了解多种行业的业务、用户使用习惯，这些都和架构设计息息相关。

6、培养领导力：架构师不仅仅只是在电脑上画画架构图，还需要带领团队将设计落地，因此培养领导力和团队管理能力也是重要的。

结语

从程序员成长为架构师是一个充满挑战和机遇的过程，需要持续学习、深度思考和实践积累。在不断适应新技术与新趋势的同时，程序员需要通过实际项目理解架构设计的原则、掌握架构设计的相关知识点。

只有先具备了扎实的架构设计能力，程序员才有可能在未来抓住机遇，成功转型为架构师。

聊聊六边形架构

Tue, 24 Oct 2023 08:27:49 +0800

指导我们写出漂亮代码有一种方式是学习设计模式，自从 Gof 四人组的《设计模式》出版后，各类设计模式的书层出不穷。熟读这类书籍，对面试肯定是有帮助的，但代码能力是否有大的长进就不一定了，如果没能理解背后的思想，去生搬硬套，只会起反作用。

如何设计 API？

Tue, 17 Oct 2023 09:42:48 +0800

在前后端分离的设计中，不管使用什么语言，后端都需要提供 WebAPI 给前端使用。如果是一个平台级的产品，还有可能需要将平台的公共 API 提供给第三方系统使用，这些都要考虑到 API 的设计。

读《持续架构实践》

Wed, 26 Apr 2023 11:56:13 +0800

之前看到过一种言论，说相比互联网产品，做 ToB 产品没有那么大的业务量，也没有那么多的用户量，所以非功能性的需求没那么重要，重要的还是业务。

微服务：事务管理

Mon, 01 Aug 2022 08:20:20 +0800

几乎所有的信息管理系统都会涉及到事务，事务的目的是为了保证数据的一致性，这里说的一致性是数据库状态的一致性。

说到数据库状态的一致性，相信大家都会想到 ACID ：

原子性（Atomic）：在一个事件的多个数据库操作中，要么同时成功，要么同时失败，例如：转账业务；
隔离性（Isolation）：不同的业务之间处理数据相互独立，互不影响
持久性（Durability）：正常提交的数据能够被持久化，不丢失数据，比如 mysql 天然就能持久化，redis 、 rabbitmq 也能通过设置进行持久化；
一致性（Consistency）：最终的数据正确，所以说是通过 AID 这些手段来保证了 C 。

微服务：服务间如何通信？

Mon, 16 May 2022 08:10:55 +0800

在微服务架构中，会将一个完整的应用程序拆分成一组服务。这些服务之间需要经过协作，通过接口调用，才能组成一个完整的应用。

不同的服务部署在不同的机器上，或者同一个机器的多个容器中，进程间的通信就不可避免了，也变得非常重要。

从一个简单 API 的发布到组件化的架构思考

Mon, 18 Apr 2022 09:53:44 +0800

在 SaaS 版本的零代码平台中，高级用户希望能上传自己编写的 WebAPI ，来实现一些复杂场景下的业务。就需要添加可以通过上传程序包进行发布部署的功能。

微服务：如何拆分服务？

Mon, 28 Mar 2022 08:26:00 +0800

在微服务的落地中，第一步就需要进行微服务的拆分，服务的拆分很困难也很重要，本文就讲讲怎么进行服务的拆分。

技术发展到现在，还没有一个具体的，设计完善的标准方法来完成服务的拆分，服务的拆分是一门技术更是一门艺术。

微服务：我们需要从单体转到微服务吗？

Mon, 07 Mar 2022 08:26:00 +0800

微服务或许你没有真正实践过，但一定听说过，虽然已经到了 2022 年，这个词依然很热，可以通过搜索 google 指数看得到。