微服务介绍

lianchun_

已于 2024-09-23 09:24:33 修改

阅读量1.3k

点赞数 22

文章标签：微服务架构云原生

于 2024-09-05 16:03:56 首次发布

本文链接：https://blog.csdn.net/lianchun_/article/details/141933305

版权

环境介绍：

微服务架构是一种设计方法，它将应用程序划分为一组独立的、可互相调用的服务。这些服务可以独立部署、扩展和更新。微服务的环境通常可以分为以下几种：

开发环境（Development Environment）：DEV

开发者在这个环境中编写和测试代码。

通常会有多个开发环境，每个开发者可能都有自己的开发环境。

环境配置可能与生产环境有所不同，但应尽量保持一致。

测试环境（Testing Environment）：UAT
- 测试环境用于自动化测试和手动测试，以确保代码的更改不会破坏现有功能。
- 可能分为单元测试环境、集成测试环境、性能测试环境等。
- 环境应尽量模拟生产环境。
预生产环境（Staging Environment）：QA
- 也称为暂存环境或过渡环境，是生产环境的镜像。
- 用于进行最终测试，如用户验收测试（UAT）。
- 在部署到生产环境之前，确保所有服务协同工作。
生产环境（Production Environment）：prod
- 客户使用的实际环境。
- 需要高度可用、可靠，并且能够处理实际的用户流量。
- 通常有严格的安全和监控措施。
持续集成/持续部署环境（CI/CD Environment）：
- 用于自动化代码的集成、测试和部署。
- 环境可能包括构建服务器、代码仓库、测试自动化工具等。
灾难恢复环境（Disaster Recovery Environment）：
- 用于在发生灾难时接管生产环境，以保持业务的连续性。
- 通常与生产环境保持同步，但平时不承载实际流量。

每种环境都有其特定的配置和目的，而微服务的部署策略需要确保在不同环境之间可以平滑过渡，同时保持服务之间的协调和一致性。

Redis

调用服务器的redis(reids存放的是缓存数据) 一般都在XXXSDKConfig里面

@Bean
public StringRedisTemplate stringRedisTemplate(AmazonElastiCache elastiCache) {
    DescribeReplicationGroupsResult result = elastiCache.describeReplicationGroups(
            new DescribeReplicationGroupsRequest().withReplicationGroupId(datalakeCache));
    Endpoint en = result.getReplicationGroups().get(0).getConfigurationEndpoint();
    log.info("redis cluster config {} - {}", en.getAddress(), en.getPort());
    Config config = new Config();
    config.useClusterServers().setTimeout(redissonTimeout).setConnectTimeout(redissonConnectionTimeout)
            .addNodeAddress(String.format("redis://%s:%s", en.getAddress(),
                    en.getPort()));
    return new StringRedisTemplate(new RedissonConnectionFactory(Redisson.create(config)));
}

当本地启动的时候需要将redis换成本地的

@Bean

public StringRedisTemplate redisTemplate() {

    Config config = new Config();

    config.useSingleServer().setAddress(String.format("redis://%s:%s", "localhost", "6379"));

    return new StringRedisTemplate(new RedissonConnectionFactory(Redisson.create(config)));

}

UAT环境

本地启动UAT环境

需要将resources包下的properties添加下面配置，不同环境下的id一样所以不需要单独写

# uat setting
# 定义平台应用的密钥，用于身份验证和授权

platform.application.secret=eZQX9KU9mrb7ksm14Tu1

# 设置平台服务器的URL，用于外部访问

platform.server.url=https://platform-uat.envision-io.com

# 定义平台服务器的内部URL，用于服务之间的通信

platform.server.internal-url=http://internal-ecs-uat-1335479059.ap-northeast-1.elb.amazonaws.com

# 设置AWS DynamoDB的前缀，用于标识属于该平台环境的数据表

platform.aws.ddb.prefix=it-datalake-metric-uat-

将redis换成本地的

Lombok

判断两个对象是否相等（相同）

@EqualsAndHashCode注解用于简化实体类子类的equals方法实现，callSuper属性控制是否考虑父类属性。当callSuper为true时，只有包括父类属性在内的所有属性都相等时，对象才被认为是相等的；若为false，则只比较当前类的属性。

@EqualsAndHashCode原文中提到的大致有以下几点：

此注解会生成equals(Objectother)和hashCode()方法。
它默认使用非静态，非瞬态的属性
可通过参数exclude排除一些属性
可通过参数of指定仅使用哪些属性
它默认仅使用该类中定义的属性且不调用父类的方法
可通过callSuper=true解决上一点问题。让其生成的equals方法和hashcode方法包含父类属性

另外：@Data相当于@Getter @Setter @RequiredArgsConstructor @ToString @EqualsAndHashCode这5个注解的合集。

通过官方文档，可以得知，当使用@Data注解时，则有了@EqualsAndHashCode注解，那么就会在此类中存在equals(Object other) 和 hashCode()方法，且不会使用父类的属性，这就导致了可能的问题。
比如，有多个类有相同的部分属性，把它们定义到父类中，恰好id（数据库主键）也在父类中，那么就会存在部分对象在比较时，它们并不相等，却因为lombok自动生成的equals(Object other) 和 hashCode()方法判定为相等，从而导致出错。

修复此问题的方法很简单：

使用@Getter @Setter @ToString代替@Data并且自定义equals(Object other) 和 hashCode()方法，比如有些类只需要判断主键id是否相等即足矣。
或者使用在使用@Data时同时加上@EqualsAndHashCode(callSuper=true)注解。

服务之间的调用

微服务架构中的服务通常会对外暴露接口供其他服务或客户端调用。这些接口主要有以下几种类型：

RESTful API：
- 这是最常见的接口类型，使用HTTP/HTTPS协议。
- 支持GET, POST, PUT, DELETE等标准的HTTP方法。
- 通常返回JSON或XML格式的数据。
RPC（远程过程调用）：
- 包括传统的RPC如XML-RPC和SOAP，以及更现代的RPC协议如gRPC。
- gRPC使用Protocol Buffers作为接口定义语言，支持多种编程语言，并且性能通常优于基于HTTP的RESTful API。
消息队列接口：
- 微服务可以通过消息队列（如RabbitMQ, Apache Kafka）来接收和发送消息。
- 消息队列接口通常用于异步通信，支持发布/订阅和点对点消息传递模式。
事件总线接口：
- 微服务可以发布事件到事件总线（如Apache Kafka，Amazon SNS）上，其他服务可以订阅这些事件并进行相应的处理。
- 这种接口类型也是用于异步通信。
WebSocket：
- 用于需要实时双向通信的场景，例如实时聊天、游戏、实时交易系统等。
- WebSocket提供了一个全双工通信通道，允许服务器主动发送信息给客户端。
GraphQL：
- 一种用于API的查询语言和一个满足这些查询的服务运行时。
- 它允许客户端根据需要请求数据，而不是由服务器决定返回哪些数据。
文件传输接口：
- 微服务可能需要对外提供文件上传或下载的功能。
- 这通常通过HTTP协议的multipart/form-data类型来实现。

每种接口类型都有其特定的用途和优势，微服务的接口设计会根据具体的应用场景、性能要求和开发团队的偏好来决定。在实际应用中，一个微服务可能会同时暴露多种类型的接口。

---------------------------------------------------------------------------------------------------------------------------------

因为本人只对RESTful API有一定的了解，就浅谈一下理解：

设计RESTful API是一个涉及多个方面的过程，需要考虑可用性、可维护性、安全性等因素。以下是一些设计RESTful API的步骤和最佳实践：

1. 理解资源和操作

定义资源：确定你的API将暴露哪些资源。资源通常是名词，如users, orders, products。
定义操作：确定可以对资源执行哪些操作。标准的HTTP方法（GET, POST, PUT, DELETE, PATCH）通常映射到CRUD（创建、读取、更新、删除）操作。

2. 使用名词而非动词

URL应该使用名词来表示资源，而不是动词来表示动作。

3. 考虑版本控制

在API路径中包含版本号，例如/api/v1/users，以便将来能够轻松地进行版本迭代。

4. 使用正确的HTTP方法

GET：用于检索资源。
POST：用于创建新的资源。
PUT：用于更新现有资源。
DELETE：用于删除资源。
PATCH：用于部分更新资源。

5. 路径和参数设计

保持路径简单、直观。
使用查询参数进行过滤、排序和分页。
避免在路径中使用文件扩展名，如.json。

6. 响应状态码

使用适当的HTTP状态码来表示不同的响应状态，如200（OK），201（Created），404（Not Found），500（Internal Server Error）。

7. 数据格式

使用JSON作为数据交换格式。
保证响应数据的结构一致性。

8. 安全性

使用HTTPS来保证数据传输的安全性。
对敏感数据进行加密。
实现认证和授权机制，如OAuth 2.0。

9. 文档

提供完整的API文档，包括每个端点的描述、参数、请求和响应示例。
使用Swagger或OpenAPI规范来编写和展示文档。

10. 错误处理

提供有用的错误消息。
错误响应应该包含错误代码和描述。

11. 限流和缓存

实现限流来防止服务被过度使用。
使用缓存来提高性能，减少服务器负载。

12. 测试

对API进行单元测试和集成测试。
使用工具如Postman或JMeter进行端到端测试。

13. 跟踪和监控

实施日志记录和监控来跟踪API的使用情况和性能。

以下是一个简单的RESTful API设计示例：

GET /api/v1/users              # 检索用户列表
POST /api/v1/users             # 创建新用户
GET /api/v1/users/{userId}     # 检索单个用户
PUT /api/v1/users/{userId}     # 更新用户信息
DELETE /api/v1/users/{userId}  # 删除用户