Kafka on 小盒子的技术分享

云原生，你真的懂了吗？

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

自顶向下学习 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 查看消息的接收状态。

参考

滴滴一面（高级java）面试题分享

Mon, 11 May 2020 07:25:08 +0000

1 说下对 volatile关键字的理解

volatile可以禁止指令重排序优化
保证可见性、不保证原子性(也就是说多个线程并发修改某个变量时，依旧会产生多线程问题，但适合使用一个线程写，多个线程读的场合。)

以下场景可以使用volatile
运算结果并不依赖变量的当前值，或者能够确保只有单一的线程修改变量的值
变量不需要与其他的状态变量共同参与不变约束

原理：volatile语义中的内存屏障volatile的内存屏障策略非常严格保守，非常悲观且毫无安全感的心态：在每个volatile写操作前插入StoreStore屏障，在写操作后插入StoreLoad屏障；在每个volatile读操作前插入LoadLoad屏障，在读操作后插入LoadStore屏障；由于内存屏障的作用，避免了volatile变量和其它指令重排序、线程之间实现了通信，使得volatile表现出了锁的特性。

2 jvm调过优没有，是怎么做的？排查问题时一般会用哪些命令？

 jps(JVM Process Status):虚拟机进程状况工具 显示虚拟机进程 jps -l

 jstat(JVM Statistics Monitoring Tool):监控虚拟机各种运行状态

 jinfo(Configuration Info for Java):java配置信息工具

 jmap(Memory Map for Java) 堆转储快照

 jstack(Stack Trace for Java) java堆栈跟踪工具

3 AQS 原理大概说一下

可参考 ： [彻底搞懂AQS](http://mp.weixin.qq.com/s?__biz=MzI3Njk5ODg4OQ==&mid=2247484343&idx=1&sn=0c0ac16161f09cadd00483addbf6e598&chksm=eb6dbc31dc1a35278931f76fce310d6ead4aba125fc2370aeb52a03b2dc4a78c0d4d95fae420&scene=21#wechat_redirect)

4 Redis 高可用实现方式

redis cluster 或哨兵机制

5 Kafka 或 RocketMq 实现原理

问的太广了，自己知道什么有逻辑的表达一下吧

6 spring cloud 和 dubbo区别

 主要是RPC和生态上的区别

7 spring cloud 用过哪些组件？

可参考：spring及spring cloud框架主要组件介绍

8 Hystrix 熔断器有哪些模式

closed：请求正常时，不使用熔断器；
open：统计请求的失败比例，达到阀值时，打开熔断器，请求被降级处理；延时一段时候后（默认休眠时间是5S）会进入halfopen状态；默认失败比例阀值是50%，请求次数最少不低于20次；
halfopen：在进入该状态后会放入部分请求；判断请求是否成功，不成功，进入open状态，重新计时，进入halfopen状态；成功，进入closed状态，

9 介绍下项目

10 有什么问题问我的？

spring及spring cloud框架主要组件介绍

Thu, 23 Apr 2020 02:01:05 +0000

spring 顶级项目

Spring IO platform:用于系统部署，是可集成的，构建现代化应用的版本平台，具体来说当你使用maven dependency引入spring jar包时它就在工作了。
Spring Boot:旨在简化创建产品级的 Spring 应用和服务，简化了配置文件，使用嵌入式web服务器，含有诸多开箱即用微服务功能，可以和spring cloud联合部署。
Spring Framework:即通常所说的spring 框架，是一个开源的Java/Java EE全功能栈应用程序框架，其它spring项目如spring boot也依赖于此框架。
Spring Cloud：微服务工具包，为开发者提供了在分布式系统的配置管理、服务发现、断路器、智能路由、微代理、控制总线等开发工具包。
Spring XD：是一种运行时环境（服务器软件，非开发框架），组合spring技术，如spring batch、spring boot、spring data，采集大数据并处理。
Spring Data：是一个数据访问及操作的工具包，封装了很多种数据及数据库的访问相关技术，包括：jdbc、Redis、MongoDB、Neo4j等。
Spring Batch：批处理框架，或说是批量任务执行管理器，功能包括任务调度、日志记录/跟踪等。
Spring Security：是一个能够为基于Spring的企业应用系统提供声明式的安全访问控制解决方案的安全框架。
Spring Integration：面向企业应用集成（EAI/ESB）的编程框架，支持的通信方式包括HTTP、FTP、TCP/UDP、JMS、RabbitMQ、Email等。
Spring Social：一组工具包，一组连接社交服务API，如Twitter、Facebook、LinkedIn、GitHub等，有几十个。
Spring AMQP：消息队列操作的工具包，主要是封装了RabbitMQ的操作。
Spring HATEOAS：是一个用于支持实现超文本驱动的 REST Web 服务的开发库。
Spring Mobile：是Spring MVC的扩展，用来简化手机上的Web应用开发。
Spring for Android：是Spring框架的一个扩展，其主要目的在乎简化Android本地应用的开发，提供RestTemplate来访问Rest服务。
Spring Web Flow：目标是成为管理Web应用页面流程的最佳方案，将页面跳转流程单独管理，并可配置。
Spring LDAP：是一个用于操作LDAP的Java工具包，基于Spring的JdbcTemplate模式，简化LDAP访问。
Spring Session：session管理的开发工具包，让你可以把session保存到redis等，进行集群化session管理。
Spring Web Services：是基于Spring的Web服务框架，提供SOAP服务开发，允许通过多种方式创建Web服务。
Spring Shell：提供交互式的Shell可让你使用简单的基于Spring的编程模型来开发命令，比如Spring Roo命令。
Spring Roo：是一种Spring开发的辅助工具，使用命令行操作来生成自动化项目，操作非常类似于Rails。
Spring Scala：为Scala语言编程提供的spring框架的封装（新的编程语言，Java平台的Scala于2003年底/2004年初发布）。
Spring BlazeDS Integration：一个开发RIA工具包，可以集成Adobe Flex、BlazeDS、Spring以及Java技术创建RIA。
Spring Loaded：用于实现java程序和web应用的热部署的开源工具。
Spring REST Shell：可以调用Rest服务的命令行工具，敲命令行操作Rest服务。

spring cloud子项目包括

Spring Cloud Config：配置管理开发工具包，可以让你把配置放到远程服务器，目前支持本地存储、Git以及Subversion。
Spring Cloud Bus：事件、消息总线，用于在集群（例如，配置变化事件）中传播状态变化，可与Spring Cloud Config联合实现热部署。
Spring Cloud Netflix：针对多种Netflix组件提供的开发工具包，其中包括Eureka、Hystrix、Zuul、Archaius等。
Netflix Eureka：云端负载均衡，一个基于 REST 的服务，用于定位服务，以实现云端的负载均衡和中间层服务器的故障转移。
Netflix Hystrix：容错管理工具，旨在通过控制服务和第三方库的节点,从而对延迟和故障提供更强大的容错能力。
Netflix Zuul：边缘服务工具，是提供动态路由，监控，弹性，安全等的边缘服务。
Netflix Archaius：配置管理API，包含一系列配置管理API，提供动态类型化属性、线程安全配置操作、轮询框架、回调机制等功能。
Spring Cloud for Cloud Foundry：通过Oauth2协议绑定服务到CloudFoundry，CloudFoundry是VMware推出的开源PaaS云平台。
Spring Cloud Sleuth：日志收集工具包，封装了Dapper,Zipkin和HTrace操作。
**Spring Cloud Data Flow：**大数据操作工具，通过命令行方式操作数据流。
Spring Cloud Security：安全工具包，为你的应用程序添加安全控制，主要是指OAuth2。
Spring Cloud Consul：封装了Consul操作，consul是一个服务发现与配置工具，与Docker容器可以无缝集成。
Spring Cloud Zookeeper：操作Zookeeper的工具包，用于使用zookeeper方式的服务注册和发现。
Spring Cloud Stream：数据流操作开发包，封装了与Redis,Rabbit、Kafka等发送接收消息。
Spring Cloud CLI：基于 Spring Boot CLI，可以让你以命令行方式快速建立云组件。

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

什么是零拷贝

Thu, 05 Mar 2020 10:58:37 +0000

预计阅读时间6分钟

学习Netty时看到Netty高性能的原因之一是使用零拷贝技术

学习Kafka时看到其高性能的原因之一也使用了零拷贝技术

那么到底什么是零拷贝？本文简单做个描述。

先解释几个概念

用户态：只能受限地访问内存，不允许访问外围设备。占用 CPU 的能力被剥夺，CPU资源可以被其他程序获取。
内核态：CPU可以访问内存中所有的数据，包括外围设备，例如硬盘、网卡，CPU也可以将自己从一个程序切换到另一个程序。
DMA (direct memory access):直接内存访问，是一种不经过CPU而直接从内存存取数据的数据交换模式。在DMA模式下，CPU只须向DMA控制器下达指令，让DMA控制器来处理数据的传送，数据传送完毕再把信息反馈给CPU，这样就很大程度上减轻了CPU资源占有率，可以大大节省系统资源

传统的数据拷贝方法

 下图为传统的数据拷贝方法：

 上图分别对应传统 I/O 操作的数据读写流程，整个过程涉及 4 次 拷贝，

1 .数据从磁盘读取到内核的read buffer
2. 数据从内核缓冲区拷贝到用户缓冲区
3. 数据从用户缓冲区拷贝到内核的socket buffer

4. 数据从内核的socket buffer拷贝到网卡接口的缓冲区

并且在用户态和内核态中间进行了2次切换，无疑也加重了CPU负担。

在此过程中，我们没有对文件内容做任何修改，那么在内核空间和用户空间来回拷贝数据无疑就是一种浪费，而零拷贝主要就是为了解决这种低效性。

解决方案

 **一个很明显的着力点就是减少数据在内核空间和用户空间来回拷贝。**

 **Linux能够做到在数据传输的过程中，避免数据在操作系统内核态buffer和用户态buffer之间进行复制。****Linux中提供类似的系统调用函数主要有mmap()、sendfile()及splice()。下面介绍其中两种。**

**mmap **

 我们减少拷贝次数的一种方法是调用mmap()来代替read调用：

1write(sockfd, buf, len);

 应用程序调用mmap()，磁盘上的数据会通过DMA被拷贝的内核缓冲区，接着操作系统会把这段内核缓冲区与应用程序共享，这样就不需要把内核缓冲区的内容往用户空间拷贝。应用程序再调用write(),操作系统直接将内核缓冲区的内容拷贝到socket缓冲区中，这一切都发生在内核态，最后，socket缓冲区再把数据发到网卡去。

使用mmap替代read很明显减少了一次拷贝，当拷贝数据量很大时，无疑提升了效率。

sendfile

从2.1版内核开始，Linux引入了sendfile来简化操作。

1#include<sys/sendfile.h>
2ssize_t sendfile(int out_fd, int in_fd, off_t *offset, size_t count);

系统调用sendfile()在代表输入文件的描述符in\_fd和代表输出文件的描述符out\_fd之间传送文件内容（字节）。描述符out\_fd必须指向一个套接字，而in\_fd指向的文件必须是可以mmap的。这些局限限制了sendfile的使用，使sendfile只能将数据从文件传递到套接字上，反之则不行。
使用sendfile不仅减少了数据拷贝的次数，还减少了上下文切换，数据传送始终只发生在kernel space。

方案对比

 限于篇幅原因并没有把所有的零拷贝方式都介绍完整，以下是Linux中各方式的对比

拷贝方式	CPU拷贝	DMA拷贝	系统调用	上下文切换
传统方式（read + write）	2	2	read / write	4
内存映射（mmap + write）	1	2	mmap / write	4
sendfile	1	2	sendfile	2
sendfile + DMA gather copy	0	2	sendfile	2
splice	0	2	splice	2

Kafka采用的是Linux系统的函数sendfile()，允许操作系统将数据从Page Cache直接发送到网络，以此来避免数据复制。

 **Netty** 中的零拷贝和上面提到的操作系统层面上的零拷贝不太一样, 我们所说的 Netty 零拷贝完全是基于（Java 层面）用户态的，它的更多的是偏向于数据操作优化这样的概念，具体表现在以下几个方面：

Netty 通过 DefaultFileRegion 类对 java.nio.channels.FileChannel 的 tranferTo() 方法进行包装，在文件传输时可以将文件缓冲区的数据直接发送到目的通道（Channel）
ByteBuf 可以通过 wrap 操作把字节数组、ByteBuf、ByteBuffer 包装成一个 ByteBuf 对象, 进而避免了拷贝操作
ByteBuf 支持 slice 操作, 因此可以将 ByteBuf 分解为多个共享同一个存储区域的 ByteBuf，避免了内存的拷贝
Netty 提供了 CompositeByteBuf 类，它可以将多个 ByteBuf 合并为一个逻辑上的 ByteBuf，避免了各个 ByteBuf 之间的拷贝

参考 :