微服务架构设计与实践
2024-02-19 16:55:37 0 举报AI智能生成
微服务架构设计与实践
作者其他创作
大纲/内容
微服务架构设计与实践
业务垂直拆分
功能水平拆分
二个维度
业务架构
微服务架构本质
按照业务垂直拆分和按照功能水平拆分，业务拆分比较难，需要熟悉整块业务。比如：用户模块，包括边界的梳理，哪些表要放在哪个库中等抽象设计。
所以本质上讲微服务架构就是业务架构
APP -->网关层 --> 用户业务逻辑层-->用户数据访问层---> DB
业务垂直
APP -->网关层 -- > 业务逻辑层(用户业务逻辑、商品业务逻辑、交易业务逻辑层) -->数据访问层（用户数据访问、商品数据访问层、交易数据访问） -->DB
拆分方式
串联模式
服务分支模式
服务共享数据模式
服务异步消息模式
聚合模式
拆分组合模型
服务拆分
一个开发人员维护最多不超过5个数据库
每个服务独立数据库
数据解耦，避免性SQL 相互影响
避免添加、修改字段等影响到服务运行
数据库不能直接查询其它数据库，通过其它服务暴露出来接口访问
数据库之间不能共享
数据库
独立的git仓库
独立的集成测试机器
独立QA测试机器
独立staging测试机器
独立prod生产机器
独立的数据库
工程拆分
COPY 老服务修改配置
通过maven做一个骨架
微服务脚手架
将微服务的工程，就是完全标准化的，可以做一个骨架出来，每个人要新建一个服务工程，就用骨架来创建就可以了。
微服务架构实践
在微服务架构里，我们比较强调的一点是整体的自治，每个服务都可以自己管理自己，跟其他的服务是没有关系
只有通过这两种方式拆分够不够？这主要取决于业务功能，考虑一下某个功能的读写频率，如，用户注册(写)和登录查询(读)，在互联网项目中通常是读多写少，很显然写更加重要，为了服务不相互影 响，可进行API的粒度拆分，将写和读拆成各自不同的服务
服务分层
服务鉴权
自动化故障诊断
容量预估以及扩容告警
可用性监测
QPS、请求量、响应时间的监测
性能瓶颈定位
调用链跟踪
接口版本管理
服务上下线审批
流量控制
其它
微服务治理平台
代码重复性问题
多人协作问题
多人协作效率问题
扩容问题
可用性问题
微服务解决问题
每个服务 -> 工程 -> 数据库 -> 代码仓库，完全独立自治
0 条评论
下一页
