微服务作为目前业界主流的设计架构,已经使用的很广泛了,但是实际并没有很明确的划分原则,这里主要总结一下常用的设计、划分原则。

微服务设计的四个原则

  • AKF拆分原则

AKF扩展立方体,是由一个叫AKF公司总结的,按照三个维度,将一个单体系统进行无限扩展。
X轴:水平复制,就是将单体系统多运行几个实例,做个集群加负载均衡的模式;
Y轴:这个就是我们通常所说的微服务拆分,基于不同的业务拆分;
Z轴:基于类似的数据分区比如一个互联网打车应用,用户量激增,集群撑不住了,就可以按照用户的地区进行数据分区,比如北京,上海,杭州等建多个集群

  • 前后端分离

前端和后端的代码在技术上做分离,后端不直接渲染前端页面

  • 无状态服务

状态:如果一个数据需要被多个服务共享,才能完成一次交易,那么这个数据就被成为状态。依赖这个状态的服务就被成为有状态的服务,反之就是无状态服务。

无状态服务不是不允许存在状态,而是把有状态的服务转为无状态的计算类服务,然后把状态数据相应的迁移到有状态的数据服务中。

场景说明:例如我们在有状态的服务里建立的数据缓存,session缓存,到微服务架构中,就需要将数据迁移到分布式缓存中,让业务服务变成一个无状态的计算节点,这样的话,微服务在运行时,就可以动态增删节点,无需考虑服务间缓存数据如何同步

  • Restful通信风格

1.资源以json为载体;2.统一接口(get获取资源,post新建资源,put完全替换资源,patch部分替换资源,delete删除资源);3.URL的设计(API尽量部署在专用域名/主域名下,api中放入版本号,并且只能有名词,复数形式,不能有动词,可以考虑提供参数);4.返回规定的状态码;5.统一的错误处理(例如以error为键名)

微服务设计目标

  • 架构必须稳定
  • 服务必须高内聚 — 每个服务应该实现的是强相关的功能
  • 服务必须松耦合 — 每个服务都可以在不影响客户端的情况下更改实现
  • 服务必须服务开闭原则 — 开:服务功能的扩展是开放的;闭:服务源代码的修改是闭合的
  • 服务是可以单独测试
  • 每项服务的都小到可以由几个人的团队完成开发
  • 负责每个服务的团队必须是自治的,尽量减少团队间的协作,来开发部署他们的服务

微服务划分方法

通过领域驱动设计,Domain Driven Design,简称DDD,设计与子域相对应的服务。DDD通过分析问题空间和业务逻辑,将应用程序定义为域。域由不同的子域组成,每个子域对于业务的不同部分。

子域可以分为以下几类:

  • 核心类:业务的关键差异化因素和应用程序中最有价值的部分
  • 支持类:与业务有关,但是与差异化无关
  • 通用类:与业务无关,理想情况下可以使用现有的软件实现