下一代软件架构,如何构建微服务核心能力

本文涉及的产品
云原生网关 MSE Higress,422元/月
服务治理 MSE Sentinel/OpenSergo,Agent数量 不受限
任务调度 XXL-JOB 版免费试用,400 元额度,开发版规格
简介: 下一代软件架构,如何构建微服务核心能力

作者:李艳林

本文整理自阿里云微服务负责人李艳林在 2023 云栖《下一代软件架构,如何构建微服务核心能力》的分享。


随着数字化进程的加速,各种架构设计思想风起云涌,进入百家争鸣时代,微服务架构,云原生架构,Serverless 架构,事件驱动架构,中台架构,容灾架构,到底哪种思潮代表未来呢?



架构趋势


未来的架构趋势是什么呢?为什么说微服务架构是下一代软件架构呢?


主流架构趋势

每一种架构都有时代的挑战和选择,没有最好的架构,只有更适合的架构。


WEB 1.0 时代,更多的是信息的呈现,系统相对简单,早期一般购买物理机,采用经典的 LAMP 单体架构快速构建一个网站,业务复杂可以采用 MVP 思想进行分层化解。


WEB 2.0 时代,交互复杂,互联网/移动互联网蓬勃发展,互联网充斥着快鱼吃慢鱼的故事,因此化解复杂系统的快速迭代的架构就是下一代架构。在基础设施这层采用云计算底座能够快速交付资源,采用微服务架构充分提升研发效率,解决复杂系统的研发效率问题;采用中台架构,解决复杂系统重复建设和基础服务能力沉淀问题。


随着线上、线下的加速融合,稳定性要求越来越高,因此高可用成为每家企业必须重视的话题。如果在云上,云厂商会解决容灾问题,如果自建 IDC,可以采用混合云架构解决基础设施容灾问题;在应用架构层面,同城多活是解决应用容灾的通用方案;在业务架构层面,异地多活是解决业务容灾的最佳实践。


随着数字化加深,整个时代架构会逐渐右移动,可见微服务会是下一代软件架构,会逐渐成为时代的主角。



云原生微服务

微服务架构在释放研发效率同时导致运维成本上升,但是 K8s 彻底解决了运维问题,让微服务迈过技术成熟度拐点,并且随着云原生架构加速演进,充分释放云的红利。



微服务价值凸显

下图是展示单体和微服务架构选型的图,横坐标代表系统复杂度,纵坐标代表效率,绿色曲线代表单体应用,蓝色曲线代表微服务;当系统复杂度(超过 10 个子系统或者人员)上升,采用微服务架构会比单体架构效率更高。


随着 WEB 2.0 加速渗透,系统能力和复杂度逐渐上升,越来越多的企业达到这个拐点;再伴随着开源和云计算的推进,微服务成本从百万级下降到千级,使用门槛大幅降低,导致拐点左移,目前市场上能看到,3 个子系统就开始采用微服务架构;随着算力成本的不断下降,人力成本的不断上升,采用微服务架构的公司投入产出比会越来越高,加速企业创新和迭代速度。



微服务行业趋势

微服务市场每年保持 18% 以上增长,可见其爆发力之强;Gartner 报告显示,微服务进入稳步爬升初期,这意味着技术成熟、标准,加速渗透各行各业;CSDN 开发者报告则显示,58% 用户关注微服务架构,可见开发者将大规模越迁到微服务时代。



微服务挑战 & 解法


虽然大家都知道微服务是下一代架构,但是对微服务的实施难点有所忌惮,对解法是否优雅有所怀疑,下面我将详细介绍一下我们的思考。


微服务主要挑战

从单体演进到微服务后,会大幅提升业务研发效率,但是也会带来架构的复杂性,开发需要先解决 RPC 调用复杂问题,发布解决变更有损可用性问题,出故障需要解决登陆很多机器解决才可定位的问题,面对黑客需要解决安全问题。这就是微服务核心的四个挑战,下面我们将逐步分享我们的解法。



微服务框架挑战

微服务框架核心要解决的是,如何像单体一样开发微服务应用,屏蔽分布式系统复杂度和多语言差异。2011 年阿里开源 Dubbo 框架,由于简单易用的优势快速成为国内首选,但是存在着序列化协议语言相关性高,多语言发展缓慢,重 SDK 模式、升级困难等问题。


为了解决重 SDK 问题,我们引入了 Agent 的技术(Java 字节码增强),尽可能把复杂的治理功能下沉到 Agent 中,大幅缓解 SDK 生命周期管理问题,但是依然没有解决多语言问题。


为了解决多语言问题,有两个基本思路,一个是通过 Sidecar 技术,在网络层通用解决一些流量治理问题,但这个思路会引入一个新的依赖,增加复杂度;另外一个思路是发展利于多语言实现的序列化协议,目前主要有 Http + Json 和 gRPC(基于 HTTP2.0)+ PB 两个路径。


我们基于第一性原理判断,最终 RPC 调用类似 HTTP 调用,不应该引入一个 Sidecar 的复杂度,应该按照标准化和轻量化方向演进,因此我们 Dubbo 3.0 推出了 Triple 协议(基于 HTTP / gRPC),解决多语言问题,数据面控制面分离,客户端轻量化。



微服务框架解法

微服务框架主要由三个部分组成,API 层,协议层,治理层;API 层主要解决简单好用问题,Dubbo 的 API 非常适合 Java 开发者,但是早期参照 Java 写的 Golang 版本不适合 Golang 开发者习惯,因此我们推出更适合 Golang 语言的微服务编程 API,并配套升级了官网、文档、示例、脚手架,不断降低复杂度;协议层推出 Triple 协议,解决跨语言调用问题,支持 OT 利于多语言链路追踪;服务治理代码占 Dubbo 一半左右代码,多语言实现难度大,因此我们做了数据面和控制面抽象,将 SDK 轻量化,支持部分治理下沉 Sidecar,方便多语言实现。



微服务可用性挑战

实践数据表明,系统变更会引入 70% 风险。如采用微服务后第一个遇到的是发布流量损失,核心原因是节点下线通过注册中心通知下游有延迟,上有系统不能及时摘除下线节点,导致调用异常;由于应用多,变更时间不同,依赖复杂,会导致变更产生的风险变多。


运行态会引入 10% 左右风险,比例虽小但是风险极大,这类风险主要有三类,一类是被上游系统突发流量和攻击压死,一类是被下游不靠谱依赖拖垮,一类是被运行机器抖动拖死;


因此微服务的可用性挑战,主要解决这些问题。



微服务可用性解法

面对变更态最多的风险,我们核心的思路是可灰度、可观测、可回滚;通过灰度缩小爆炸半径,观测快速识别问题,回滚来快速解决问题;其中灰度技术要求最高,主要是因为两个原因,一个涉及全链路应用多、规则复杂。阿里内部全产品改造(Dubbo+Nacos/ RocketMQ / 任务调度 / 可观测)所有核心业务升级,消耗大、时间久,不通用,因此我们后来推出 Agent 解决方案,无侵入解决服务治理的问题。


Dubbo 早期预置了一些治理规则 + Groovy 扩展机制,治理规则变化多总得升级,Groovy 不利于多语言实现且不好管控。因此需要在灵活性和复杂性之间做一个平衡,最后我们根据主流流量控制场景将配置模版化,数据面和控制面分离,来解决该问题。



微服务观测挑战

由于微服务系统业务复杂,依赖复杂,链路复杂,导致排查问题增大,尤其涉及多层调用问题排查。如果登陆到一台台机器查日志,这个简直是一个噩梦。



微服务观测解法

微服务观测目前方法论比较充分,通过 Metrics 定性大概是业务问题还是中间件问题,通过 Tracing 定量分析是哪个应用问题,通过 Logging 定位具体根因。OT 标准的出现,加速了技术迭代,解决复杂链路问题,大幅提升分析诊断效率。



微服务安全挑战

为了快速落地微服务,很多公司一个应用挂一个公网 SLB 来发布服务,这样安全攻击面非常大,也增加了管理证书负担,应用内部都有自己的敏感数据,一不小心可能造成致命损失。



微服务安全解法

安全最好的做法就是统一入口,在入口建立安全防线,把风险拒之门外,把敏感数据存放到配置中心加密存储,代码、密文和密钥分别存储,杜绝核心数据泄漏。



微服务演进 & 实践


上面详细介绍了微服务当前的挑战和解法,那面对未来微服务将如何演进,有哪些实践呢?

微服务演进

未来微服务会沿着易用、标准化、语言无关、可扩展、可持续架构演进;微服务框架解决易用性和多语言问题,控制面解决标准化和可扩展问题,可持续架构是从小到大可以持续演进,而不是第一天就搞一个巨复杂架构。小的时候可以 Dubbo+Nacos 快速开始,遇到安全问题上云原生网关 Higress,遇到稳定性问题上服务治理,遇到一致性问题引入 Seata(启动贡献 Apache 社区),一步步持续生长。



微服务框架演进

对于 OPS 同学,掌握 K8s + Terraform 就可以高效的运维;面对开发者,我们通过 Spring-Cloud-Alibaba 帮助开发者解决微服务开发效率问题。未来,我们将扩大范围,做开发者和阿里云的链接,通过 Spring 注解快速使用阿里云主流云产品,大幅提升开发者效率。



服务治理演进

Istio 体系主要解决流量治理问题,抽象度高但是复杂,然而对于微服务,我们更多需要的是服务治理,因此我们会通过 OpenSerGo 来推动服务治理的规范和标准制定,简化服务治理使用门槛。



网关演进

WEB 1.0 主要采用 SLB / ALB + ECS + 单体架构,支撑简单的信息系统。


WEB 2.0 主要采用云原生网关 + 容器 + 微服务架构,支撑复杂交互系统;从单体到微服务,SLB / 微服务网关彼此不能互通,从微服务到 ACK,微服务网关和 Ingress 网关彼此不能互通,导致在架构演进中会出现流量网关、微服务网关、安全网关多层叠罗汉现象,带来运维和部署复杂度提升。因此,我们推出云原生网关 Higress,将三层网关合一,基于 Ingress 标准整合微服务和安全网关能力,提供服务治理差异化竞争力,相比 Nginx 生态网关,Higress 采用 Envoy 内核,从规则、路由、证书、插件实现全部热更新,避免链接抖动带来的用户中断和体验下降。


未来云计算发展有两个主导力量,一个是 Serverless,把算力发挥到极致;一个是 AI,把数据挖掘到极致。


面对 Serverless 时代,网关需要突破自适应能力(流量来后端服务没有拉起 Hold 流量,后端服务拉齐转发下去),目前 MSE Higress  +  ASK / SAE 已经全部跑通,阿里云 FC / SAE 会内置 Higress。


面对 AI 时代,网关需要双向流传输性能和链接稳定性有很高要求,协议上需要支持 SSE/WebSocket 等双向流协议,需要热更新能力保证链接稳定,目前通义系列和 PAI 等开始集成 Higress。



微服务企业级实践

阿里微服务体系通过 10+ 年的双十一洪峰考验,以及云上成千上万家企业的打磨,构建了默认安全、默认高可用的差异化竞争力。今年 MSE 4.0 全面 Serverless 化,推出了行业首个云原生网关/注册配置中心 Serverless 版本,从低运维到免运维,无需关心容量,无需关心版本升级,按量付费低于自建成本,真正做到像水电一样使用微服务。



微服务高可用实践

我们根据双十一压测场景,简单介绍一下微服务高可用体系。首先,我们通过 PTS 模拟客户压测,在 MSE 云原生网关入口做路由级流量防护,在应用侧通过服务治理做服务级流量防护,通过 ARMS 做全链路观测,通过指标驱动容器弹性伸缩,从而轻松应对流量洪峰。



微服务容灾实践

解决完单集群高可用问题,我们需要解决多 AZ 容灾问题,进一步提升微服务高可用体系。下面有两个可用区,每个可用区有一个 K8s 集群,通过 ACK One 轻松管理两个集群。面对入口流量我们有两个选择,一个选择是一个网关集群,聚合两个 K8s 服务,可以通过网关灵活切换不同可用区容量;一个是选择两个网关集群,通过上层 DNS 切换流量,这样架构简单,但是切流实时性无法保障。



微服务 Serverless 实践

如果我们真的想像用水电一样使用云服务,未来 Serverless 一定是关键方向,让用户能够聚焦业务开发,让云逐渐带大家走到自动挡,自动驾驶时代。目前在云上可以通过 SAE + MSE 体验 Serverless 的优势,加速推进 Serverless 进程,进一步释放云计算红利。



在“阿里巴巴中间件”公众号后台,回复关键词:微服务,即可下载本次大会分享材料。

相关实践学习
深入解析Docker容器化技术
Docker是一个开源的应用容器引擎,让开发者可以打包他们的应用以及依赖包到一个可移植的容器中,然后发布到任何流行的Linux机器上,也可以实现虚拟化,容器是完全使用沙箱机制,相互之间不会有任何接口。Docker是世界领先的软件容器平台。开发人员利用Docker可以消除协作编码时“在我的机器上可正常工作”的问题。运维人员利用Docker可以在隔离容器中并行运行和管理应用,获得更好的计算密度。企业利用Docker可以构建敏捷的软件交付管道,以更快的速度、更高的安全性和可靠的信誉为Linux和Windows Server应用发布新功能。 在本套课程中,我们将全面的讲解Docker技术栈,从环境安装到容器、镜像操作以及生产环境如何部署开发的微服务应用。本课程由黑马程序员提供。     相关的阿里云产品:容器服务 ACK 容器服务 Kubernetes 版(简称 ACK)提供高性能可伸缩的容器应用管理能力,支持企业级容器化应用的全生命周期管理。整合阿里云虚拟化、存储、网络和安全能力,打造云端最佳容器化应用运行环境。 了解产品详情: https://www.aliyun.com/product/kubernetes
相关文章
|
23天前
|
SQL 监控 关系型数据库
MySQL主从复制:构建高可用架构
本文深入解析MySQL主从复制原理与实战配置,涵盖复制架构、监控管理、高可用设计及性能优化,助你构建企业级数据库高可用方案。
|
17天前
|
数据采集 运维 监控
构建企业级Selenium爬虫:基于隧道代理的IP管理架构
构建企业级Selenium爬虫:基于隧道代理的IP管理架构
|
1月前
|
监控 Java API
Spring Boot 3.2 结合 Spring Cloud 微服务架构实操指南 现代分布式应用系统构建实战教程
Spring Boot 3.2 + Spring Cloud 2023.0 微服务架构实践摘要 本文基于Spring Boot 3.2.5和Spring Cloud 2023.0.1最新稳定版本,演示现代微服务架构的构建过程。主要内容包括: 技术栈选择:采用Spring Cloud Netflix Eureka 4.1.0作为服务注册中心,Resilience4j 2.1.0替代Hystrix实现熔断机制,配合OpenFeign和Gateway等组件。 核心实操步骤: 搭建Eureka注册中心服务 构建商品
350 3
|
2月前
|
消息中间件 负载均衡 中间件
⚡ 构建真正的高性能即时通讯服务:基于 Netty 集群的架构设计与实现
本文介绍了如何基于 Netty 构建分布式即时通讯集群。随着用户量增长,单体架构面临性能瓶颈,文章对比了三种集群方案:Nginx 负载均衡、注册中心服务发现与基于 ZooKeeper 的消息路由架构。最终选择第三种方案,通过 ZooKeeper 实现服务注册发现与消息路由,并结合 RabbitMQ 支持跨服务器消息广播。文中还详细讲解了 ZooKeeper 搭建、Netty 集群改造、动态端口分配、服务注册、负载均衡及消息广播的实现,构建了一个高可用、可水平扩展的即时通讯系统。
240 0
|
3月前
|
存储 SQL 分布式计算
19章构建企业级大数据平台:从架构设计到数据治理的完整链路
开源社区: 贡献者路径:从提交Issue到成为Committer 会议演讲:通过DataWorks Summit提升影响力 标准制定: 白皮书撰写:通过DAMA数据治理框架认证 专利布局:通过架构设计专利构建技术壁垒
|
9天前
|
消息中间件 缓存 监控
中间件架构设计与实践:构建高性能分布式系统的核心基石
摘要 本文系统探讨了中间件技术及其在分布式系统中的核心价值。作者首先定义了中间件作为连接系统组件的"神经网络",强调其在数据传输、系统稳定性和扩展性中的关键作用。随后详细分类了中间件体系,包括通信中间件(如RabbitMQ/Kafka)、数据中间件(如Redis/MyCAT)等类型。文章重点剖析了消息中间件的实现机制,通过Spring Boot代码示例展示了消息生产者的完整实现,涵盖消息ID生成、持久化、批量发送及重试机制等关键技术点。最后,作者指出中间件架构设计对系统性能的决定性影响,
38 1
|
18天前
|
传感器 人工智能 算法
分层架构解耦——如何构建不依赖硬件的具身智能系统
硬件与软件的彻底解耦,并通过模块化、分层的架构进行重构,是突破这一瓶颈、构建通用型具身智能系统的核心基石。这种架构将具身智能系统解耦为三个核心层级:HAL、感知决策层和任务执行层。这一模式使得企业能够利用预置的技能库和低代码工具快速配置新任务,在不更换昂贵硬件的前提下,实现从清洁机器人到物流机器人的快速功能切换。本文将通过对HAL技术原理、VLA大模型和行为树等核心技术的深度剖析,并结合Google RT-X、RobotecAI RAI和NVIDIA Isaac Sim等主流框架的案例,论证这一新范式的可行性与巨大潜力,探讨硬件解耦如何将机器人从一个“工具”升级为“软件定义”的“多面手”,从而
169 3
|
5月前
|
人工智能 算法 网络安全
基于PAI+专属网关+私网连接:构建全链路Deepseek云上私有化部署与模型调用架构
本文介绍了阿里云通过PAI+专属网关+私网连接方案,帮助企业实现DeepSeek-R1模型的私有化部署。方案解决了算力成本高、资源紧张、部署复杂和数据安全等问题,支持全链路零公网暴露及全球低延迟算力网络,最终实现技术可控、成本优化与安全可靠的AI部署路径,满足企业全球化业务需求。
|
28天前
|
存储 自然语言处理 前端开发
百亿级知识库解决方案:从零带你构建高并发RAG架构(附实践代码)
本文详解构建高效RAG系统的关键技术,涵盖基础架构、高级查询转换、智能路由、索引优化、噪声控制与端到端评估,助你打造稳定、精准的检索增强生成系统。
241 1

热门文章

最新文章