微服务架构设计与实践

微服务架构设计与实践

业务垂直拆分

功能水平拆分

二个维度

业务架构

微服务架构本质

按照业务垂直拆分和按照功能水平拆分，业务拆分比较难，需要熟悉整块业务。比如：用户模块，包括边界的梳理，哪些表要放在哪个库中等抽象设计。

所以本质上讲微服务架构就是业务架构

APP -->网关层 --> 用户业务逻辑层-->用户数据访问层---> DB

业务垂直

APP -->网关层 -- > 业务逻辑层(用户业务逻辑、商品业务逻辑、交易业务逻辑层) -->数据访问层（用户数据访问、商品数据访问层、交易数据访问） -->DB

拆分方式

串联模式

服务分支模式

服务共享数据模式

服务异步消息模式

聚合模式

拆分组合模型

服务拆分

一个开发人员维护最多不超过5个数据库

每个服务独立数据库

数据解耦，避免性SQL 相互影响

避免添加、修改字段等影响到服务运行

数据库不能直接查询其它数据库，通过其它服务暴露出来接口访问

数据库之间不能共享

数据库

独立的git仓库

独立的集成测试机器

独立QA测试机器

独立staging测试机器

独立prod生产机器

独立的数据库

工程拆分

COPY 老服务修改配置

通过maven做一个骨架

微服务脚手架

将微服务的工程，就是完全标准化的，可以做一个骨架出来，每个人要新建一个服务工程，就用骨架来创建就可以了。

微服务架构实践

在微服务架构里，我们比较强调的一点是整体的自治，每个服务都可以自己管理自己，跟其他的服务是没有关系

只有通过这两种方式拆分够不够？这主要取决于业务功能，考虑一下某个功能的读写频率，如，用户注册(写)和登录查询(读)，在互联网项目中通常是读多写少，很显然写更加重要，为了服务不相互影 响，可进行API的粒度拆分，将写和读拆成各自不同的服务

服务分层

服务鉴权

自动化故障诊断

容量预估以及扩容告警

可用性监测

QPS、请求量、响应时间的监测

性能瓶颈定位

调用链跟踪

接口版本管理

服务上下线审批

流量控制

其它

微服务治理平台

代码重复性问题

多人协作问题

多人协作效率问题

扩容问题

可用性问题

微服务解决问题

每个服务 -> 工程 -> 数据库 -> 代码仓库，完全独立自治