系统设计 - 微服务拆分

单体架构的优点

• 架构单一, 容易维护
• 开发, 测试, 部署都比较便捷

为什么要拆成微服务

单体架构的缺点

• 复杂度高
• 部署慢, 而且体积很大, 不利于发布
• 阻碍新的技术创新

什么是微服务

微服务架构风格是一种将一个单一应用程序开发为一组小型服务的方法, 每个服务运行在自己的进程中, 服务间通信采用轻量级通信机制, 通常用http资源的api来实现, 这些服务围绕业务能力构建并且可通过全自动部署机制独立部署, 这些服务共用一个最小型的集中式的管理, 服务可用不同的语言开发, 使用不同的数据存储技术

微服务架构的特征

• 每个微服务可独立运行在自己的进程里
• 一系列独立运行的微服务共同构建起整个系统
• 每个微服务可用独立的开发, 在开发过程中只关注一个业务模块的特定功能, 比如支付服务, 订单管理, 用户管理等等
• 可使用不同的语言与数据存储技术(契合项目情况和团队实力)
• 微服务器直接通过轻量级的通信机制进行通信 ( 比如Rest API进行调用 )
• 全自动的部署机制

微服务架构的优点

• 单个服务更易于开发, 维护
• 单个服务的启动比较快, 部署也快, 消耗的服务器资源更少
• 技术栈不受限制

微服务架构的缺点

• 运维要求高
• 分布式服务固有的复杂度

微服务适用场景

• 大型项目
• 有快速迭代的要求
• 访问压力过大的网站

微服务不适合的场景

• 业务稳定
• 迭代周期长

微服务拆分方法论

1. 按照DDD领域驱动设计去划分
   从建模开始到数据表设计, 技术栈选择, 开发, 到部署上线应该有明确的规范和设计, 必须要有统一的技术栈, 你用Java, 那所有的微服务都使用Java
2. 面向对象驱动设计
   2.2 按照职责划分 ( 订单模块, 搜索模块)
   2.3 按照通用性划分 ( 把一些通用功能做成微服务: 比如用户中心, 支付中心, 消息中心. 比如阿里流行的: 大中台和小中台的概念, 一个中台其实是由若干个微服务组成的 )

---

横向拆分

比如把商品编辑中的"弹窗引导批量编辑"模块, 拆到了guide服务中
校验规则逻辑, 移到了glue中
商品操作日志服务器, 拆到了grog中

纵向拆分

用户界面层: 前端的微服务
应用层: glide
基础设施层: goalie

根据DDD思想拆分

业务的垂直拆分

粗粒度的拆分:

用户 / 商品 / 搜索 / 推荐 / 交易 / 物流

更进一步的细粒度的拆分:

用户注册 / 用户登录
商品B端 / 商品C端 / 商品活动 / 商品促销

---

请求功能水平拆分

APP 请求 网关层 (网关是一个微服务) 请求鉴权, 路由, 参数检查, 协议转换
网关层 请求 业务逻辑层 商品业务(glide), 订单业务, 用户业务
业务逻辑层, 请求 数据访问层(goalie) CRUD, ORM

微服务的设计的合理性

• 满足业务的后续的扩展和延展
• 满足团队的成员的职业和技术的发展
• 可以稳步的迭代和更新你的业务
• 可以持续的更新或者调整你的技术架构, 以及完全的可靠和抽离

建议: 在实际的开发和生产中, 如果你的项目属于早期或者刚开始, 通过分析以后模块和业务并不复杂, 其实不建议用微服务去架构, 使用为服务一定要按照公司现有的资源, 人员的实际情况触发, 利用小步慢跑快速迭代的思维去架构和演进项目才是王道