2025-5-19

物联网

物联网是实现物物相连的互联网络，其内涵包括两个方面：第一，物联网的核心和基础仍是互联网，是在互联网基础上延伸和扩展的网络；第二，其用户端延伸和扩展到了任何物体与物体之间，使其进行信息交换和通信。

物联网分为三层。

（1）感知层

识别物体，采集信息。如：二维码，RFID，摄像头，传感器

（2）网络层

传递信息和处理信息。通信网与互联网的融合网络，网络管理中心，信息中心和智能处理中心等。

（3）应用层

解决信息处理和人机交互的问题

物联网关键技术——RFID

射频识别技术（RFID）又称电子标签，是一种通信技术，可通过无线电讯号识别特定目标并读写相关数据，而无需识别系统与特定目标之间建立机械或光学接触。该技术是物联网的一项核心技术，很多物联网应用都离不开他

RFID的基本组成部分通常包括：标签，阅读器，天线。

物联网关键技术——二维码

二维码是用某种特定的几何图形按一定规律在平面分布的黑白相间的图形记录数据符号信息的。

原文链接：https://blog.csdn.net/gaoqiandr/article/details/137186478

云计算

云计算是一种基于互联网的计算方式，通过该方式，共享的软硬件资源和信息可以按需提供给计算机和其他设备。

特点：

（1）集合了大量计算机，规模达到成千上万

（2）多种软硬件技术相结合

（3）对客户端设备的要求低

（4）规模化效应

三种服务：软件即服务，平台即服务，基础设施即服务

基于构件的软件开发

CBSE体现了“购买而不是重新构造”的哲学，将软件开发的重点从程序编写转移到了基于已有构件的组装，以更快地构造系统，减轻用来支持和升级大型系统所需要的维护负担，从而降低软件开发的费用。 用于CBSE的构件应该具备以下特征。 （1）可组装型：对于可组装的构件，所有外部交互必须通过公开定义的接口进行。同时它还必须对自身信息的外部访问。 （2）可部署性：软件必须是自包含的，必须能作为一个独立实体在提供其构件模型实现的构件平台上运行。构件总是二进制形式，无须在部署前编译。 （3）文档化：构件必须是完全文档化的，用户根据文档来判断构件是否满足需求。 （4）独立性：构件应该是独立的，应该可以在无其他特殊构件的情况下进行组装和部署，如确实需要其他构件提供服务，则应显示声明。 （5）标准化：构件标准化意味着在CBSE过程中使用的构件必须符合某种标准化的构件模型。 CBSE过程是支持基于构件组装的软件开发过程，需要考虑构件复用的可能性，以及在开发和使用可复用的构件中所涉及的不同过程活动，成功的构件复用需要一个经过裁剪、适配的开发过程，以便在软件开发过程中包含可复用的构件。 CBSE过程中的主要活动包括：（1）系统需求概览；（2）识别候选构件；（3）根据发现的构件修改需求；（4）体系结构设计；（5）构件定制与适配；（6）组装构件，创建系统。 构件组装是指构件相互直接集成或是用专门编写的“胶水代码”将它们整合在一起来创造一个系统或另一个构件的过程。常见的组装构件有以下3种组装方式。 1、顺序组装 通过按顺序调用已经存在的构件，可以用两个已经存在的构件来创造一个新的构件。顺序组装的类型可能适用于作为程序元素的构件或是作为服务的构件。需要特定的胶水代码，来保证两个构件的组装：上一个构件的输出，与下一个构件的输入相兼容。 2、层次组装 这种情况发生在一个构件直接调用由另一个构件所提供的服务时。被调用的构件为调用的构件提供所需的服务。因此，被调用构件的“提供”接口必须和调用构件的“请求”接口兼容，如果接口相匹配，则调用构件可以直接调用被调用构件，否则就需要编写专门的胶水代码来实现转换。 3.叠加组装 这种情况发生在两个或两个以上构件放在一起来创建一个新构件的时候。这个新构件合并了原构件的功能，从而对外提供了新的接口。外部应用可以通过新接口来调用原有构件的接口而原有构件不互相依赖，也不互相调用。这种组装类型适合于构件是程序单元或者构件是服务的情况。 当创建一个系统时，可能会用到所有的构件组装方式，对所有情况都必须编写胶水代码来连接构件。 而当编写构件尤其是为了组装来写构件时，经常可能会面临接口不兼容的问题，即所要组装的构件的接口不一致。一般会出现3种不兼容情况。 （1）参数不兼容。接口每一侧的操作有相同的名字，但参数类型或参数个数不相同。 （2）操作不兼容。提供接口和请求接口的操作名不同。 （3）操作不完备。一个构件的提供接口是另一个构件请求接口的一个子集，或者相反。 针对上述不兼容情况，必须通过编写适配器构件来解决不兼容的问题，适配器构件使两个可复用构件的接口相一致；适配器构件将一个接口转换为另外一个接口。 当用户选择组装方式时，必须考虑系统所需要的功能性需求、非功能性需求，以及当系统发生改变时，一个构件能被另一个构件替代的难易程度。

论数据分片技术及其应用

数据分片就是按照一定的规则，将数据集划分成相互独立正交的数据子集。然后将数据子集分布到不同的节点上，通过设计合理的数据分片规则，可将系统中的数据分布在不同的物理数据库中，达到提升应用系统数据处理速度的目的。

请围绕“论数据分片技术及其应用”论题，依次从以下三个方面进行论述。

1.概要叙述你参与管理和开发软件的项目以及承担的工作

1. Hash分片，一致性Hash分片和按照数据范围分片是三种常用的数据分片方式

3.具体阐述你参与管理和开发的项目，且采用了哪些分片方式，并且具体说明其实现过程和应用效果。

数据分片（Sharding）是通过特定规则将数据集水平划分为逻辑上独立的数据子集，并分布到不同物理节点的技术。其核心价值在于：

• 突破单机容量限制：通过多节点分布式存储支持海量数据

• 提升并行处理能力：多个分片可同时处理不同数据请求

• 提高系统可用性：单点故障不影响整体服务

2.2 典型分片方式对比

2.2.1 Hash分片

原理：对分片键应用Hash函数，将结果与分片数量取模确定数据位置

pythonCopyDownload

shard_id = hash(shard_key) % shard_num

优点：

• 数据分布均匀

• 实现简单高效 缺点：

• 增减节点需大规模数据迁移

• 不支持范围查询路由

2.2.2 一致性Hash分片

原理：构建哈希环，数据与节点在环上定位，数据归属顺时针方向最近的节点

优化点：

• 引入虚拟节点解决数据倾斜

• 节点变化仅影响相邻区域数据 应用场景：

• 动态伸缩集群环境

• 缓存系统（如Redis Cluster）

2.2.3 按数据范围分片

原理：按分片键的值范围划分数据，如时间范围、ID区间等

CopyDownload

shard_1: order_id 1-1000万
shard_2: order_id 1001-2000万
...

优点：

• 支持高效的范围查询

• 便于冷热数据分离 缺点：

• 容易产生数据热点

• 需要预判数据增长趋势

分片方式对比表

比较维度	Hash分片	一致性Hash	范围分片
数据均衡性	优	良	中
扩缩容便利性	差	优	中
范围查询支持	不支持	不支持	支持
实现复杂度	简单	中等	简单

电商平台分片实践

基础架构

• 数据库中间件：ShardingSphere-Proxy 5.1.2

• 存储节点：Percona MySQL 8.0（1主2从×16分片）

• 监控体系：Prometheus + Grafana

3.1 分片方案设计

3.1.1 业务特征分析

订单系统具有以下特点：

• 读写比例约7:3

• 80%访问集中在最近3个月的订单

• 订单ID采用雪花算法生成，包含时间信息

• 需要支持用户ID和订单ID双维度查询

3.1.2 混合分片策略

采用两级分片架构：

1. 一级分片（用户维度）：一致性Hash分片（16个物理分片）

   • 解决用户订单聚集查询需求

   • 每个用户的所有订单存储在同一分片

   • 使用ShardingSphere的Hint强制路由

2. 二级分片（时间维度）：按季度范围分片

   • 当前季度分片使用SSD存储

   • 历史数据自动归档到HDD存储

   • 支持按时间范围快速检索

3.1.3 分片键设计

• 主分片键：user_id（一致性Hash）

• 辅助分片键：order_date（范围分片）

3.3 数据迁移方案

采用双写+增量同步的平滑迁移方案：

1. 初期：旧库双写，验证数据一致性

2. 过渡期：读请求逐步切流（10%→50%→100%）

3. 完成期：旧库转为备份，启用分片集群独立运行

3.4 应用效果

3.4.1 性能指标对比

指标	分片前	分片后	提升幅度
平均查询延迟	320ms	85ms	73%↓
峰值TPS	2,150	9,800	355%↑
备份耗时	6小时	45分钟	87%↓
存储成本	￥280万/年	￥150万/年	46%↓

3.4.2 业务收益

1. 支持"双11"期间日均800万订单平稳处理

2. 历史订单查询响应时间从秒级降至毫秒级

3. 集群扩容时间从周级缩短到小时级

4. 为后续引入HTAP架构奠定基础

4. 经验总结

4.1 关键成功因素

1. 分片键选择：结合业务查询模式设计复合分片策略

2. 渐进式迁移：通过双写保证业务连续性

3. 监控全覆盖：建立分片维度性能指标监控

4. 应急预案：准备分片故障自动隔离方案

4.2 改进方向

1. 探索AI驱动的动态分片调整机制

2. 测试基于Vitess的自动resharding方案

3. 优化跨分片事务处理（引入Saga模式

论云原生架构及其应用论题，依次从以下三个方面进行论述：

1.概要叙述你参与管理和开发的软件项目以及承担的主要工作。

2.服务化，强性，可观测性和自动化是云原生架构重复的四类设计原则，请简要对这四类设计原则的内涵进行阐述。

3.具体阐述你参与管理和开发的项目是如何向采用云原生架构的，并且围绕上述四类设计原则详细论述在项目设计与实现过程中遇到了哪些实际问题，是如何解决的。

1. 项目背景与工作职责

1.1 项目概况

2021-2023年，我作为技术负责人主导了XX证券公司核心交易系统的云原生重构项目。该系统日均交易额超过300亿元，原有架构面临以下挑战：

• 单体架构导致功能迭代缓慢（平均发布周期2周）

• 峰值交易时段系统响应延迟显著上升

• 故障排查平均耗时超过4小时

• 基础设施利用率不足30%

1.2 承担工作

在本项目中，我主要负责：

1. 云原生技术栈选型与架构设计

2. 微服务拆分与治理方案制定

3. 云原生PaaS平台建设

4. 研发效能提升体系构建

5. 技术团队能力转型培训

2. 云原生架构设计原则

2.1 服务化（Microservices）

核心内涵：

• 业务能力解耦：按领域模型将应用拆分为松耦合的微服务

• 独立演进：每个服务可独立开发、部署和扩展

• 明确契约：通过API和事件定义服务边界

技术体现：

• 服务网格（如Istio）

• gRPC/RESTful API

• 领域驱动设计（DDD）

2.2 弹性（Resilience）

核心内涵：

• 容错设计：避免单点故障导致级联失效

• 自适应能力：根据负载动态调整资源

• 优雅降级：核心功能在极端情况下保持可用

技术体现：

• 熔断模式（Hystrix/Sentinel）

• 弹性伸缩（K8s HPA）

• 混沌工程（Chaos Mesh）

2.3 可观测性（Observability）

核心内涵：

• 多维监控：指标（Metrics）、日志（Logs）、追踪（Traces）三位一体

• 上下文关联：跨服务请求链路的端到端可视化

• 主动预警：异常检测与根因分析

技术体现：

• Prometheus+Grafana监控栈

• OpenTelemetry标准

• ELK日志系统

2.4 自动化（Automation）

核心内涵：

• 基础设施即代码（IaC）：环境定义版本化管理

• 持续交付：自动化构建、测试、部署流水线

• 自愈系统：异常检测与自动恢复

技术体现：

• Terraform/Ansible

• GitOps（Argo CD）

• K8s Operator模式

3. 云原生转型实践

3.1 整体架构演进

转型前架构：

• 单体Java应用（Spring MVC）

• Oracle RAC数据库

• 物理服务器部署

3.2 关键问题与解决方案

3.2.1 服务化实施挑战

问题1：服务粒度难以确定

• 初期拆分过细导致分布式事务激增

• 服务间调用关系复杂（出现循环依赖）

解决方案：

1. 采用领域驱动设计的限界上下文划分原则

问题2：服务通信性能瓶颈

• REST over HTTP/1.1在高频调用场景出现延迟

解决方案：

1. 关键路径改用gRPC（性能提升40%）

2. 引入消息队列异步化非核心流程

3.2.2 弹性设计挑战

问题1：交易高峰时段服务过载

• 传统扩容机制响应滞后（需人工干预）

解决方案：

1. 基于自定义指标的HPA策略

3.2.3 可观测性挑战

问题1：跨服务追踪信息断裂

• 异步消息处理导致调用链丢失上下文

解决方案：

1. 在消息头注入W3C Trace Context

3.3.2 业务价值

1. 新产品上线周期从3个月缩短至2周

2. 系统可用性从99.5%提升到99.99%

3. 基础设施成本降低40%

4. 支持业务量年增长300%

4. 经验总结

4.1 关键成功要素

1. 渐进式演进：采用Strangler Fig模式逐步迁移

2. 文化转型：建立SRE团队推动DevOps实践

3. 平台思维：构建内部开发者平台(IDP)降低使用门槛

4. 安全左移：在CI流水线集成安全扫描

4.2 改进方向

1. 探索服务网格的深度特性（如故障注入）

2. 实现基于AI的异常检测

3. 完善多云管理能力

4. 深化FinOps实践