微服务设计、拆分原则

>>强大,10k+点赞的 SpringBoot 后台管理系统竟然出了详细教程!

点击关注公众号,利用碎片时间学习微服务设计、拆分原则

一 前言

微服务是一种架构风格。一个大型的复杂软件应用,由一个或多个微服务组成。系统中的各个微服务可被独立部署,各个微服务之间是松耦合的。每个微服务仅关注于完成一件任务并很好的完成该任务。那么关于微服务的设计原则有哪些呢?如下:

  • AKF 拆分原则
  • 前后端分离原则
  • 无状态服务
  • RestFul 的通信风格

二 AKF 拆分原则

有句挺流行的话:没有什么事是一顿烧烤解决不了的,如果有,那就两顿....。这跟我们之前设计可扩展的系统架构的理念很相像,通过加机器就可以解决容量和可用性问题 。( 如果一台不行那就两台) 。这个理念在当前也得到了广泛的认可!对于一个规模迅速增长的系统而言,容量和性能问题当然是首当其冲的。

但是随着现在业务的更迭不穷以及功能模块的不断拓展,许多系统在设计的时候并没有充分考虑到这一点,所以如果架构重设,必然会导致财力跟人力的浪费。对此,《可扩展的艺术》一书提出了一个更加系统的可扩展模型—— AKF  可扩展立方(Scalability Cube)。这个立方体中沿着三个坐标轴设置分别为:X、Y、Z。

微服务设计、拆分原则
  • Y 轴(功能) —— 关注应用中功能划分,基于不同的业务拆分
  • X 轴(水平扩展) —— 关注水平扩展,也就是”加机器解决问题”
  • Z 轴(数据分区) —— 关注服务和数据的优先级划分,如按地域划分

2.1  Y  轴(功能)

Y 轴扩展会将庞大的整体应用拆分为多个服务。每个服务实现一组相关的功能,如订单管理、客户管理等。在工程上常见的方案是  服务化架构(SOA) 。比如对于一个电子商务平台,我们可以拆分成不同的服务,组成下面这样的架构:

微服务设计、拆分原则

但通过观察上图容易发现,当服务数量增多时,服务调用关系变得复杂。为系统添加一个新功能,要调用的服务数也变得不可控,由此引发了服务管理上的混乱。所以,一般情况下,需要采用服务注册的机制形成服务网关来进行服务治理。系统的架构将变成下图所示:

微服务设计、拆分原则

2.2 X 轴(水平扩展)

X 轴扩展与我们前面朴素理念是一致的,通过绝对平等地复制服务与数据,以解决容量和可用性的问题。其实就是将微服务运行多个实例,做集群加负载均衡的模式。为了提升单个服务的可用性和容量,  对每一个服务进行 X  轴扩展划分

微服务设计、拆分原则

2.3  Z  轴( 数据分区)

Z 轴扩展通常是指基于请求者或用户独特的需求,进行系统划分,并使得划分出来的子系统是相互隔离但又是完整的。以生产汽车的工厂来举例:福特公司为了发展在中国的业务,或者利用中国的廉价劳动力,在中国建立一个完整的子工厂,与美国工厂一样,负责完整的汽车生产。这就是一种 Z 轴扩展。

工程领域常见的 Z  轴扩展有以下两种方案:

1.单元化架构

在分布式服务设计领域,一个单元(Cell)就是满足某个分区所有业务操作的自包含闭环。如上面我们说到的 Y 轴扩展的 SOA 架构,客户端对服务端节点的选择一般是随机的,但是,如果在此加上 Z 轴扩展,那服务节点的选择将不再是随机的了,而是每个单元自成一体。如下图:

微服务设计、拆分原则

2.数据分区

为了性能数据安全上的考虑,我们将一个完整的数据集按一定的维度划分出不同的子集。一个分区(Shard),就是是整体数据集的一个子集。比如用尾号来划分用户,那同样尾号的那部分用户就可以认为是一个分区。数据分区为一般包括以下几种数据划分的方式:

  • 数据类型(如:业务类型)
  • 数据范围(如:时间段,用户 ID)
  • 数据热度(如:用户活跃度,商品热度)
  • 按读写分(如:商品描述,商品库存)

举个例子:比如美团,滴滴遍布全国,各个城市的业务进展不太一样,所以可以根据城市来进行数据分区。

三 前后端分离原则

这个我们应该很常见,前端做前端的事情,后端做后端的业务模块,分工更加明确。

微服务设计、拆分原则
微服务设计、拆分原则

那么前后段分离有什么好处呢?

这种分离方式有几个好处:

  • 前后端技术分离,可以由各自的专家来对各自的领域进行优化,这样前段的用户体验优化效果更好。
  • 分离模式下,前后端交互界面更清晰,就剩下了接口模型,后端的接口简洁明了,更容易维护。
  • 前端多渠道集成场景更容易实现,后端服务无需变更,采用统一的数据和模型,可以支持多个前端:例如:微信 h5 前端、PC 前端、安卓前端、IOS 前端。

四 无状态服务

什么是状态?

如果一个数据需要被多个服务共享,才能完成一笔交易,那么这个数据被称为状态。进而依赖这个“状态”数据的服务被称为有状态服务,反之称为无状态服务。更好的说明见下图:

微服务设计、拆分原则

场景说明:例如我们以前在本地内存中建立的数据缓存、Session 缓存,到现在的微服务架构中就应该把这些数据迁移到分布式缓存中存储,让业务服务变成一个无状态的计算节点

迁移后,就可以做到按需动态伸缩,微服务应用在运行时动态增删节点,就不再需要考虑缓存数据如何同步的问题。这样对于业务的拓展起到了至关重要的作用

五 RestFul通讯风格

作为一个原则来讲本来应该是个“无状态通信原则”,在这里我们直接推荐一个实践优选的 Restful 通信风格 ,因为他有很多好处:

  • 无状态协议 HTTP,具备先天优势,扩展能力很强。例如需要安全加密,有现成的成熟方案 HTTPS 即可。
  • JSON 报文序列化,轻量简单,人与机器均可读,学习成本低,搜索引擎友好。
  • 语言无关,各大热门语言都提供成熟的 Restful API 框架,相对其他的一些RPC 框架生态更完善。
(感谢阅读,希望对你所有帮助)
来源:blog.csdn.net/qq_33223299/
article/details/90703822

推荐好文

强大,10k+点赞的 SpringBoot 后台管理系统竟然出了详细教程!

分享一套基于SpringBoot和Vue的企业级中后台开源项目,代码很规范!

能挣钱的,开源 SpringBoot 商城系统,功能超全,超漂亮微服务设计、拆分原则

原文始发于微信公众号(Java笔记虾):微服务设计、拆分原则