如何构建普适的企业级微服务架构(上)——阿里云 MVP孙玄

本文涉及的产品
任务调度 XXL-JOB 版免费试用,400 元额度,开发版规格
注册配置 MSE Nacos/ZooKeeper,182元/月
MSE Nacos/ZooKeeper 企业版试用,1600元额度,限量50份
简介: 阿里云MVP、奈学教育CEO孙玄结合自己的架构师经验,在直播中给大家介绍如何构建普适的微服务架构。

快速成为顶级架构师的内功修炼

查看直播——如何构建普适的企业级微服务架构

查看下篇文章

孙玄在2010年从浙江大学毕业后,就加入了百度,之后又加入过58集团、转转担任最高级别架构师,最后选择了自己创业,成立了新的IT在线教育平台——奈学教育,致力于IT教育事业,在架构领域有着丰富的经历和独到的见解。

image.png

一、微服务架构下服务设计实践

既然我们要构建一个普适的微服务架构,那么如何去体现其“普适性”呢?有没有一些比较通用的微服务架构来帮助我们完成这项任务呢?

首先我们要了解什么是微服务架构,其最经典的定义如下图所示。从定义上我们可以看出,微服务架构是一种将单体架构拆分成一系列小服务组合的方法。那么,我们要如何去定义这个“小服务”呢?也就是说从一个单体变成很多小服务,我们要如何进行拆分呢?实际上,作为一个架构师,主要任务就是“拆”与“合”,如果做好了这两点,就是一名优秀的架构师。

image.png

(一)如何“拆”?

有些公司的架构师会进行“甩锅式”的拆分——定量拆分,比如说每一千行代码进行一次拆分,但是会遇到一些问题,比如代码行数不太“完美”,可能刚好在拆分后多了一行。虽然定量拆分是一种可行的拆分方式,但是可以说一定不是一种很好的拆分方式,或者说不是一种“优雅”的拆分方式。

无论何种事物,在底层的设计和“道”上都是相通的,唯一不同的在于“术”,只要我们把其中的一个方面吃透,再迁移到其他方面也是没有问题的

在讲MS之前,我们先讲讲DB。假设你在负责一个电商的DB建设:你的数据有商品相关的、用户相关的、交易相关的,一开始业务量比较小的时候,可以用一个单独的数据库,其中包括一个商品相关的表、一个用户相关的表、一个交易相关的表。但是随着业务量的增加,请求数也急剧增加,这时候你自然会想到将商品相关的数据、用户相关的数据、交易相关的数据分别存入一个单独的数据库,就有了DB1、DB2和DB3,这种方法叫“分库”。然而,随着用户数的进一步增加,DB2(用户相关的DB)中的数据量过大,都放在一个表中会严重影响数据库性能,这时你发现每一个用户都有一个唯一的User ID,于是按照一定数目将用户信息放在不同的表中,完成了拆分,这种方法叫“分表”。

上面的“分库”方法是对数据库的垂直拆分,“分表”是对数据库的水平拆分。大家类比一下,既然数据库可以进行垂直的拆分和水平的拆分,那么微服务架构是否也可以进行“垂直”和“水平”的拆分呢?答案是肯定的,前面我们说过,他们在“道”上是相通的,区别在于“术”。

假设我们在负责一个电商业务架构,其中包括与用户相关的功能、与商品相关的功能和与交易相关的功能。刚开始所有的请求都依靠一个单体来完成,随着请求数的增加,我们要进行架构的拆分。正如上面讲的,这时候我们至少要进行“垂直”和“水平”的拆分。

(1)垂直拆分

根据具体情况,这时候我们的垂直拆分要按照业务来进行拆分。我们知道,用户和商品之间是逻辑关系,商品和交易之间也是逻辑关系,因此我们可以对其进行拆分,如下图所示,对单体进行简单的垂直拆分
image.png
正如上图我们将单体垂直拆分为用户服务、商品服务和交易服务三部分,但是拆分的粒度比较粗,我们需要更细粒度的拆分。

比如用户服务部分,主要包括用户注册、用户登录、用户查询等服务,其中用户注册是属于“写”的服务,用户登录和用户查询是属于“读”的服务,而一般情况下用户注册是比较重要的,也就是“写”服务的重要性要大于“读”服务;但是如果是一个互联网业务,一般来讲“读”服务的数据量要远远大于“写”服务的数据量,这时候如果用户服务中同时包含了注册和登录服务,那么当登录服务的请求量足够大的时候,一定会影响到注册服务,因此我们可以按照功能对用户服务模块进一步的拆分,比如拆分成用户注册的微服务和用户登录/用户查询的微服务,实际上就是按照API的粒度进行拆分。

那么是不是所有的服务都要按照API的粒度进行拆分呢?当然不是,我们要根据场景来进行拆分,比如业务量比较小的时候,即便用户注册和用户登录在同一个微服务下也不会影响,就不需要进行更细粒度的拆分。

如下图所示,我们对用户服务进行了更细粒度的拆分,但是也许商品的发布量和交易量没有达到一定数量级,就不需要进行更新粒度的拆分。

image.png

(2)水平拆分

我们仔细思考上面的例子,如果仅仅做一个垂直拆分,无非是将一个单体变成了多个单体,粒度仍然是比较粗的。这个时候,我们可以从整个请求的生命周期来看看,到底经历了哪几个过程,然后进行拆分,也就是做水平拆分。

我们把商品中的一件衣服拿出来作为例子,假设我们要发布一个商品,它的整个生命周期是怎么样的呢?

如下图所示,我们在APP上发布商品,然后借助通讯协议、传输协议与网关层进行消息传递,网关层完成鉴权、请求参数检查等服务之后与业务逻辑层进行消息传递,业务逻辑层主要负责业务编排等服务,之后再发送请求给数据访问层,数据访问层完成CRUD、sharding、屏蔽底层数据差异性等功能,并从数据层获取数据,数据来源可以是DB、Cache等等。

根据商品发布服务的整个生命周期,我们在架构侧完成了如下图所示的水平拆分。那么类似的,我们的用户相关服务、交易相关服务也可以按照网关层、业务逻辑层、数据访问层等进行相应的水平拆分。其中,网关层在商品相关服务和用户相关服务、交易相关服务是相同的,我们可以将其部署成一个SaaS层,降低架构的工作量。

image.png

快速成为顶级架构师的内功修炼

查看直播——如何构建普适的企业级微服务架构

查看下篇文章

目录
相关文章
|
1月前
|
数据采集 运维 监控
构建企业级Selenium爬虫:基于隧道代理的IP管理架构
构建企业级Selenium爬虫:基于隧道代理的IP管理架构
|
17天前
|
人工智能 监控 测试技术
告别只会写提示词:构建生产级LLM系统的完整架构图​
本文系统梳理了从提示词到生产级LLM产品的八大核心能力:提示词工程、上下文工程、微调、RAG、智能体开发、部署、优化与可观测性,助你构建可落地、可迭代的AI产品体系。
267 51
|
13天前
|
Cloud Native Serverless API
微服务架构实战指南:从单体应用到云原生的蜕变之路
🌟蒋星熠Jaxonic,代码为舟的星际旅人。深耕微服务架构,擅以DDD拆分服务、构建高可用通信与治理体系。分享从单体到云原生的实战经验,探索技术演进的无限可能。
微服务架构实战指南:从单体应用到云原生的蜕变之路
|
15天前
|
机器学习/深度学习 人工智能 搜索推荐
从零构建短视频推荐系统:双塔算法架构解析与代码实现
短视频推荐看似“读心”,实则依赖双塔推荐系统:用户塔与物品塔分别将行为与内容编码为向量,通过相似度匹配实现精准推送。本文解析其架构原理、技术实现与工程挑战,揭秘抖音等平台如何用AI抓住你的注意力。
245 7
从零构建短视频推荐系统:双塔算法架构解析与代码实现
|
16天前
|
人工智能 Cloud Native 安全
解读阿里云刚发布的《AI 原生应用架构白皮书》
阿里云在云栖大会重磅发布了《AI 原生应用架构白皮书》,该白皮书覆盖 AI 原生应用的 11 大关键要素,获得业界 15 位专家联名推荐,来自 40 多位一线工程师实践心得,全书合计超 20w 字,分为 11 章,全面、系统地解构 AI 原生应用架构,包含了 AI 原生应用的 11 大关键要素,模型、框架、提示词、RAG、记忆、工具、网关、运行时、可观测、评估和安全。本文整理自阿里云智能技术专家李艳林在云栖大会现场的解读。
509 14
|
15天前
|
人工智能 缓存 安全
阿里云发布《AI 原生应用架构白皮书》
阿里云联合阿里巴巴爱橙科技,共同发布《AI 原生应用架构白皮书》,围绕 AI 原生应用的 DevOps 全生命周期,从架构设计、技术选型、工程实践到运维优化,对概念和重难点进行系统的拆解,并尝试提供一些解题思路。白皮书覆盖 AI 原生应用的 11 大关键要素,获得 15 位业界专家联名推荐,来自 40 多位一线工程师实践心的,全书合计超 20w 字,分为 11 章。
633 11
|
27天前
|
消息中间件 缓存 监控
中间件架构设计与实践:构建高性能分布式系统的核心基石
摘要 本文系统探讨了中间件技术及其在分布式系统中的核心价值。作者首先定义了中间件作为连接系统组件的"神经网络",强调其在数据传输、系统稳定性和扩展性中的关键作用。随后详细分类了中间件体系,包括通信中间件(如RabbitMQ/Kafka)、数据中间件(如Redis/MyCAT)等类型。文章重点剖析了消息中间件的实现机制,通过Spring Boot代码示例展示了消息生产者的完整实现,涵盖消息ID生成、持久化、批量发送及重试机制等关键技术点。最后,作者指出中间件架构设计对系统性能的决定性影响,
|
26天前
|
存储 消息中间件 安全
企业级实时消息推送系统的架构设计,一文即懂!
如果你是技术负责人,该如何搭建一套能解决这些问题的企业级统一消息推送平台?今天我们就从核心挑战出发,拆解一套可落地的统一推送服务架构方案。
168 0
|
27天前
|
存储 人工智能 关系型数据库
阿里云AnalyticDB for PostgreSQL 入选VLDB 2025:统一架构破局HTAP,Beam+Laser引擎赋能Data+AI融合新范式
在数据驱动与人工智能深度融合的时代,企业对数据仓库的需求早已超越“查得快”这一基础能力。面对传统数仓挑战,阿里云瑶池数据库AnalyticDB for PostgreSQL(简称ADB-PG)创新性地构建了统一架构下的Shared-Nothing与Shared-Storage双模融合体系,并自主研发Beam混合存储引擎与Laser向量化执行引擎,全面解决HTAP场景下性能、弹性、成本与实时性的矛盾。 近日,相关研究成果发表于在英国伦敦召开的数据库领域顶级会议 VLDB 2025,标志着中国自研云数仓技术再次登上国际舞台。
185 0
|
27天前
|
SQL 弹性计算 关系型数据库
如何用读写分离构建高效稳定的数据库架构?
在少写多读业务场景中,主实例读请求压力大,影响性能。通过创建只读实例并使用数据库代理实现读写分离,可有效降低主实例负载,提升系统性能与可用性。本文详解配置步骤,助你构建高效稳定的数据库架构。

热门文章

最新文章