微服务设计的四个原则

本文涉及的产品
注册配置 MSE Nacos/ZooKeeper,118元/月
云原生网关 MSE Higress,422元/月
服务治理 MSE Sentinel/OpenSergo,Agent数量 不受限
简介: 本文记录下微服务设计的四个原则

本文记录下微服务设计的四个原则

微服务的设计原则

AKF原则

业界对于可扩展的系统架构设计有一个朴素的理念,就是:通过加机器就可以解决容量和可用性问题。(如果一台不行那就两台)。(世界上没有什么事是一顿烧烤不能解决的。如果有,那就两顿。)

 这一理念在“云计算”概念疯狂流行的今天,得到了广泛的认可!于一个规模迅速增长的系统而言,容量和性能问题当然是首当其冲的。但是随着时间的向前,系统规模的增长,除了面对性能与容量的问题外,还需要面对功能与模块数量上的增长带来的系统复杂性问题以及业务的变化带来的提供差异化服务问题。而许多系统,在架构设计时并未充分考虑到这些问题,导致系统的重构成为常态,从而影响业务交付能力,还浪费人力财力!对此,《可扩展的艺术》一书提出了一个更加系统的可扩展模型—— AKF 可扩展立方 (Scalability Cube)。这个立方体中沿着三个坐标轴设置分别为:X、Y、Z。

20190214230644215.png

Y 轴(功能) —— 关注应用中功能划分,基于不同的业务拆分

X 轴(水平扩展) —— 关注水平扩展,也就是”加机器解决问题”

Z 轴(数据分区) —— 关注服务和数据的优先级划分,如按地域划分

Y轴(功能)

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

20190214231040753.png

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

20190214231108726.png

X轴(水平扩展)

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

20190214231238557.png

Z轴数据分区


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


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

单元化架构


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

20190214231517666.png

数据分区


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

包括以下几种数据划分的方式


数据类型(如:业务类型)

数据范围(如:时间段,用户 ID)

数据热度(如:用户活跃度,商品热度)

按读写分(如:商品描述,商品库存)

前后端分离

2019021423182340.png

何为前后端分离?前后端本来不就分离么?这要从尴尬的 jsp 讲起。分工精细化从来都是蛋糕做大的原则,多个领域工程师最好在不需要接触其他领域知识的情况下合作,才可能使效率越来越高,维护也会变得简单。jsp 的模板技术融合了 html 和 java 代码,使得传统MVC 开发中的前后端在这里如胶似漆,前端做好页面,后端转成模板,发现问题再找前端,前端又看不懂 java 代码…前后端分离的目的就是将这尴尬局面打破。前后端分离原则,简单来讲就是前端和后端的代码分离,我们推荐的模式是最好采用物理分离的方式部署,进一步促使更彻底的分离。如果继续直接使用服务端模板技术,如:jsp,把 java、js、html、css 都堆到一个页面里,稍微复杂一点的页面就无法维护了。

2019021423175781.png

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


前后端技术分离,可以由各自的专家来对各自的领域进行优化,这样前段的用户体验优化效果更好。

分离模式下,前后端交互界面更清晰,就剩下了接口模型,后端的接口简洁明了,更容易维护。

前端多渠道集成场景更容易实现,后端服务无需变更,采用统一的数据和模型,可以支持多个前端:例如:微信 h5 前端、PC 前端、安卓前端、IOS 前端。

无状态服务

20190214232308833.png

对于无状态服务,首先说一下什么是状态:如果一个数据需要被多个服务共享,才能完成一笔交易,那么这个数据被称为状态。进而依赖这个“状态”数据的服务被称为有状态服务,反之称为无状态服务。那么这个无状态服务原则并不是说在微服务架构里就不允许存在状态,表达的真实意思是要把有状态的业务服务改变为无状态的计算类服务,那么状态数据也就相应的迁移到对应的“有状态数据服务”中。场景说明:例如我们以前在本地内存中建立的数据缓存、Session 缓存,到现在的微服务架构中就应该把这些数据迁移到分布式缓存中存储,让业务服务变成一个无状态的计算节点。迁移后,就可以做到按需动态伸缩,微服务应用在运行时动态增删节点,就不再需要考虑缓存数据如何同步的问题。

RestFul通讯风格

20190214232336885.png

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


无状态协议HTTP,具备先天优势,扩展能力很强。例如需要安全加密是,有现成的成熟方案HTTPS可用。


JSON 报文序列化,轻量简单,人与机器均可读,学习成本低,搜索引擎友好。


语言无关,各大热门语言都提供成熟的Restful API框架,相对其他的一些RPC框架生态更完善。


当然在有些特殊业务场景下,也需要采用其他的RPC框架,如thrift、avro-rpc、grpc。但绝大多数情况下Restful就足够用了。


~将这几个原则多加理解有助于我们后面对项目的分析与理解


相关文章
|
3月前
|
消息中间件 监控 Java
解锁Spring Cloud微服务架构的奥秘:深度剖析拆分原则,打造高内聚低耦合的业务创新引擎!
【8月更文挑战第3天】踏入微服务领域,Spring Cloud以丰富组件助力高效系统构建。微服务拆分需遵循原则确保系统高内聚低耦合且能适应变化。首要原则为单一职责,每个服务专注一个业务功能,降低复杂度并提高可维护性。其次,追求高内聚低耦合以减少服务间影响。围绕业务域拆分有助于保持逻辑清晰及团队协作。处理数据一致性问题时,考虑采用最终一致性模型。Spring Cloud提供Eureka、Zuul/Gateway、Sleuth和Config等工具支持服务发现、路由、跟踪及配置管理,共同构建灵活健壮的微服务架构。
69 2
|
3月前
|
敏捷开发 数据库 微服务
SpringCloud微服务拆分原则
SpringCloud微服务拆分原则
56 2
|
4月前
|
监控 Java API
Java面试题:解释微服务架构的概念及其优缺点,讨论微服务拆分的原则。
Java面试题:解释微服务架构的概念及其优缺点,讨论微服务拆分的原则。
71 0
|
6月前
|
运维 监控 负载均衡
Go语言中微服务架构设计与原则
【2月更文挑战第14天】本文将深入探讨在Go语言环境下,微服务架构的设计原则和实践。我们将讨论如何根据微服务架构的核心概念,如服务拆分、独立部署、容错处理、服务治理等,来构建一个稳定、可扩展、可维护的Go语言微服务系统。
|
6月前
|
Java 调度 开发工具
SpringCloud【微服务架构进化论、微服务的拆分规范和原则、为什么选择Spring Cloud、什么是服务治理 】(一)-全面详解(学习总结---从入门到深化)
SpringCloud【微服务架构进化论、微服务的拆分规范和原则、为什么选择Spring Cloud、什么是服务治理 】(一)-全面详解(学习总结---从入门到深化)
448 0
|
存储 缓存 监控
架构师进阶,微服务设计与治理的16条常用原则
架构师进阶,微服务设计与治理的16条常用原则
318 0
|
设计模式 监控 安全
基于DDD的微服务设计和拆分要坚持哪些原则
基于DDD的微服务设计和拆分要坚持哪些原则
|
新零售 安全 微服务
微服务的拆分规范和原则
微服务的拆分规范和原则
402 0
|
缓存 监控 Cloud Native
设计稳定的微服务系统时不得不考虑的场景
我们的生产环境经常会出现一些不稳定的情况,如: 1、大促时瞬间洪峰流量导致系统超出最大负载,load 飙高,系统崩溃导致用户无法下单 2、“黑马”热点商品击穿缓存,DB 被打垮,挤占正常流量 3、调用端被不稳定服务拖垮,线程池被占满,导致整个调用链路卡死 这些不稳定的场景可能会导致严重后果。大家可能想问:如何做到均匀平滑的用户访问?如何预防流量过大或服务不稳定带来的影响?
设计稳定的微服务系统时不得不考虑的场景
|
设计模式 Docker 微服务
「第二部:容器和微服务架构」(1) 基于容器应用架构设计原则
「第二部:容器和微服务架构」(1) 基于容器应用架构设计原则