一、微服务架构的六种常用设计模式
在使用微服务架构设计模式中,通常情况下是混合使用的。这里列举的是单一的模式。商业开发中,大多数都是混合使用的
- 代理设计模式
- 聚合设计模式
保证多个服务配合执行的时候,可以由一个严格的逻辑顺序 - 链条设计模式
是多个服务通过链条式调用,得到最终结果的设计方式。类似责任链。链条长度不超过5。2~4之间。链条太长会导致网络通讯次数增多,降低效率。如果链条长度超过5,建议使用异步通讯 - 聚合链条设计模式
就是聚合设计模式+链条设计模式。是一个常见的组合设计模式。
在聚合设计模式的开发过程中,某一个被聚合子服务,有链条调用的时候,使用的设计模式。链条长度不超过5 - 数据共享设计模式
是多服务配合的一种常用设计模式。一般用于前后台数据交互使用。
这里的前后台,是针对业务上的前后台,不是代码逻辑上的前后台系统。
如:电商(JD),业务上的前台就是客户可使用的平台(www.jd.com)。业务上的后台就是JD工作人员使用的平台。
如:后台人员增加新的商品数据,需要通过中间服务实现数据的存储。因为前台客户也需要看到新的商品数据。如果后台人员做商品数据的查看统计,可以不通过中间服务,直接访问数据库,实现数据的读取统计。
数据共享设计模式,在现在的互联网行业应用较少。毕竟互联网行业效率优先,所以缓存设备几乎无处不在。 - 异步消息设计模式
就是集合MQ实现异步处理的设计模式。通常使用在即时性要求不高的业务中
二、微服务拆分
在拆分上没有固定的逻辑套用方式。主要是根据经验来实现拆分。
常见经验:
- 业务拆分。每个业务一个独立的服务。如:登录、注册、用户管理(修改密码、修改个人信息),分别是一个业务。需要拆分。
- 数据拆分。当业务逻辑过于复杂的时候,可以配合数据实现更明确的拆分。如:用户表操作、订单表操作、商品表操作等。如果数据关联度太高,容易有服务耦合的情况。如:订单和商品有关联、用户和地址有关联、用户和订单有关联。
- 读写拆分。建议为读写操作拆分服务。读写操作与幂等性相关,与数据安全性相关。建议读写分离。
一般来说,大型项目都是根据业务拆分,保证读写分离。中小型项目一般是根据数据拆分,保证读写分离(通常会为了业务的实现简易性,增加数据的冗余)