微服务模块分层 微服务架构如何拆分

目录

• 一、单体架构分析

• 1 - 单体应用部署
• 2 - 单体应用开发痛点
• 3 - 单体应用架构演变

• 二、微服务架构

• 1 - 服务拆分变动
• 2 - 微服务基本拆分
• 3 - 分层微服务架构
• 4 - 微服务需要解决的问题

一、单体架构分析

1 - 单体应用部署

2 - 单体应用开发痛点

3 - 单体应用架构演变

---

二、微服务架构

1 - 服务拆分变动

• 服务拆分变动：解决问题代码复用问题

• 以代码模块化方式进行管理（这个仍然有问题，还是单体架构）
• 以服务方式管理（微服务的方式）

2 - 微服务基本拆分

• 分析服务拆分变动依然存在的问题：即使以服务方式管理在数据库层面依然存在问题

• 比如我要改商品的表结构，但是对商品服务其实是没有影响的，由于使用的是同一个数据库，商品服务依然会受到影响
• 解决方案：服务独立 -> 代码独立 -> 数据库独立 -> redis独立

3 - 分层微服务架构

• 在2-微服务基本拆分中存在的问题：

• 对外提供http请求，对内应该使用什么协议效率才比较高呢？
• 各个服务之间不应该使用http请求（纯文本的请求，效率比较低）
• 解决方案：内部的各个服务之间使用rpc/grpc，这样就可以像调用本地方法一样调用

• 分层的微服务设计：web层和src层的服务数量是可以不一样的，并不要求相等

• web层：根据自己的业务整合各个服务的业务，对外提供http接口
• server层（srv层）：将自己的服务以rpc/grpc的方式向web层提供接口

• 分层微服务设计的好处

• 服务之间语言可以不同
• 服务之间组件可以不同（比如不同的mysql版本）

4 - 微服务需要解决的问题

• 注册中心

• 问题：当服务很多的时候，每个服务都需要提供ip、端口号、服务是否健康
• 注册中心可以定期的检查注册到注册中心的服务是否健康

• 服务发现

• 当web层需要调用订单服务的时候，因为订单服务可能是集群，所以web层到服务发现中查询可用服务的ip和端口号

• 配置中心

• 问题：比如mysql连接用户名、端口号等配置信息；redis的配置；各个服务的配置；当配置非常多的时候，又需要修改某个配置；这个配置对应的服务就需要重启
• 解决方案：有一个配置中心，统一的管理所有的配置；这样修改配置的时候，配置中心会主动通知对应的服务，服务也不需要重启

• 链路追踪：可以查看到各个服务的调用过程，快速分析到哪个服务的接口比较耗时
• 微服务网关：

• web层的服务也可能比较多，web层的服务也应该注册到注册中心，如果让APP或小程序自己去记录这些web层服务的ip和端口，这是不现实的
• nginx是可以使用的，但是如果web层的服务也是集群的方式，nginx实现起来就比较麻烦；这时候就考虑应该使用服务网关
• 服务网关也是到注册中心查询web层服务的ip和端口号

• 微服务网关的作用

• 路由
• 服务发现
• 鉴权（是否登录）
• 熔断（服务可能比较卡，不一定是断开，这时候就可以熔断请求）
• IP黑白名单
• 负载均衡