简单聊一下什么是微服务

什么是微服务

微服务架构是一种将单一应用程序分解为一组较小、独立服务的方法，每个服务运行在其独立的进程中，并通常围绕业务功能组织，服务之间通过轻量级的通信机制（通常是HTTP RESTful API）进行交互。每个服务都是自包含的，并应该实现一个特定的业务功能。我举一个例子哈，比如说做一个商场系统，都有什么功能？登陆注册，商家出售，买家购买等有很多功能和模块，我把每一个模块拆开当成一个服务，这个时候是不是变成很小的服务了。

后端服务结构(商场为例)

一个商城项目可拆分用户服务（登陆注册），订单服务（CRUD），库存服务（CRUD）等。每个服务都可以再分为 api 服务和 rpc 服务。api 服务对外，可提供给前端调用。rpc 服务是对内的，可提供给内部 api 服务或者其他 rpc 服务调用。

重点问题

服务通信

假设你有两个服务：订单服务和库存服务。当用户下单时，订单服务需要与库存服务通信来检查商品是否有足够的库存。

使用HTTP REST进行同步通信：

1. 订单服务（Order Service）接收到用户的下单请求。
2. 订单服务向库存服务（Inventory Service）发送HTTP GET请求，例如：GET /inventory/{productId}，以查询指定产品的库存数量。
3. 库存服务响应库存数量。
4. 订单服务根据库存数量决定是否继续处理订单（例如，如果库存足够，则继续处理；如果不足，则返回错误响应给用户）。

共享会话状态

1. Redis存储：使用Redis或其他类型的缓存数据库来存储会话信息是常见的做法，这可以实现会话的共享和状态的全局管理。
2. (JSON Web Tokens)：JWT是一种无状态的认证机制，服务之间可以通过JWT来验证用户的身份，而不需要每次都查询数据库或缓存。
3. 第三方服务验证：如OAuth、OpenID Connect等，这些都是通过第三方服务来管理和验证用户身份的方式。

服务间通信语言识别

不同服务可能使用不同的编程语言编写，因此需要一种通用的数据交换格式。JSON、XML和Protobuf都是常见的选择：

1. JSON：易于阅读和编写，被广泛支持，但相对于Protobuf来说效率较低。
2. XML：虽然可扩展性好，但比JSON更繁琐，解析效率也较低。
3. Protobuf：由Google开发，是一种轻量级的、高效的结构化数据交换格式，特别适合于服务间通信。

服务发现机制

为了使用户服务能够找到并调用订单服务，我们需要一个服务发现机制。常见的服务发现解决方案包括Consul, Etcd, ZooKeeper等。这些工具可以帮助服务注册自己的位置（IP地址和端口），并允许其他服务查询这些信息。

1. 服务注册：订单服务启动时，将自己的IP地址和gRPC端口注册到Etcd。
2. 服务查询：用户服务需要调用订单服务时，首先从Etcd查询订单服务的当前可用实例。

服务发现

在微服务架构中，由于服务实例可能会在不同的服务器上动态创建和销毁，因此需要一种机制来自动地注册和发现服务实例，这就是服务发现的作用。

1. 服务注册：当一个服务实例启动时，它会在服务注册中心注册自己的网络地址和其他元数据信息。
2. 服务发现：当一个服务需要与其他服务通信时，它会查询服务注册中心，以获取其他服务的实时网络地址。