日10亿级处理,基于云的微服务架构(2)

本文涉及的产品
服务治理 MSE Sentinel/OpenSergo,Agent数量 不受限
云原生网关 MSE Higress,422元/月
注册配置 MSE Nacos/ZooKeeper,118元/月
简介: 日10亿级处理,基于云的微服务架构(2)

10.4     API 网关

 

API 网关是微服务架构中不可或缺的部分。API 网关是对外提供的服务,是系统的入口,所有的外部系统都需要通过 API 网关来接入。Dgateway 提供安全认证、流控、路由、 API 版本管理等功能。流控维度分为用户类型、用户来源、IP、业务 API 等,保护服务或资源不被滥用或攻击。DGateway 基于开源软件 Tyk 做了二次开发。

 

 

10.5     服务框架

 

服务框架分两部分,高可用的 RPCDerbySoft-RPC)和服务依赖管理,如图 10.4 所示。



image.png


10.5.1    高可用 RPC

 

RPC 是微服务架构中最重要的基础组件,一个健壮的 RPC 能有效降低实施微服务架构的成本。RPC 封装了远程调用的复杂细节,让服务使用方感觉像调用本地方法一样调用远程方法,服务提供方感觉像实现本地接口一样来实现服务。DerbySoft-RPC 分为 Client Server 两部分。Client 主要有以下功能。

 


客户端故障检测,识别并标示太慢或崩溃了的服务器。

 

熔断机制,如果发现服务超时比例过限,则启动熔断,客户端会快速返回失败,以减轻服务端的压力,定时允许部分请求通过,根据请求返回的健康程度来决定是否恢复熔断。

 

负载均衡策略,通过记录到每个节点的未完成请求数来决定下一个请求发到哪里。容错机制,对某些错误自动重试,比如连接的服务节点不可用时可以自动将请求再次发送到其他节点,可定义重试次数。

 

序列化和反序列化,选择序列化工具最重要的考量点有性能高低、是否多语言支持、序列化后的消息大小、是否向前兼容等。我们尝试过各种序列化工具,而 Protocol Buffer 在性能和空间占用上都表现优异,是我们使用最频繁的序列化工具。对敏感数据加密,比如信用卡等敏感信息,需要在 Client 端加密传输。

 

超时管理,可设定每个请求的超时时间。


Server 部分相对简单,主要提供超时管理、序列化和反序列化、敏感信息解密、队列管理、线程管理等功能。


刚才提到选择序列化工具时需要考虑是否支持多语言,这一点很重要,RPC 最好能在多语言环境下实现,这样能让技术团队突破编程语言限制,使技术栈更丰富灵活。我们在这方面是有过教训的。


在公司早期,大概是 2009 年,当时的业务量不大,在语言上主要使 Java,为了方便我们在第一个 RPC 版本上采用了 Java 序列化机制,却导致后面想要更换编程语言时大受限制。因此我们做了第二版 RPC,将序列化机制换掉,采用 Java 的字节序以兼容第一个版本。DerbySoft-RPC 是第三版 RPC,实现了对 GoScala Java 三种语言的兼容。原则上我们不限制服务的实现语言,只要能按要求实现服务接口并满足性能要求即可。微服务化后的一个好处就是根本不用担心使用小众的编程语言,如果每个服务的粒度足够小,那么最坏的情况就是在没人能维护这个小众语言的服务时,需要花点时间用熟悉的语言来重写。

 

 

10.5.2    服务依赖管理

 

 

微服务化之后,系统面临的一个突出问题是服务虽小,但是数量极多。如果这些服务全部在一个可用区内,那么服务之间的依赖还比较好管理,可以做服务自动注册和发现来实现依赖管理,但是如果服务分布在很多可用区中,尤其是分布在跨国跨地区的可用区之间,则其依赖和调用的管理就会比较麻烦。

 

另外,跨可用区服务之间的调用还需要考虑通信安全的问题,对每个服务设置不同的特殊端口,如果需要跨区域调用服务,那么配置访问权限也是一件麻烦的事情。

 

众多服务的依赖示例如图 10.5 所示。

 



image.png



10.5 所示的服务依赖是不是很乱?我们的服务节点分布在全球 14 个可用区,大部分在亚马逊云上,小部分在自建的私有云里,可用区之间的服务有复杂的依赖关系。为了解决这种情况下服务之间的依赖调用问题、API 安全问题和服务的高可用问题,我们设计开发了路由服务,以解耦服务的调用者和提供者,简化网络拓扑及服务器的安全配置。引入路由之后,简化后的服务之间的依赖关系如图 10.6 所示。


 


image.png


所有的服务只和路由通信,服务之间不再相互依赖,每个服务只需要依赖并维护自己所在的可用区路由节点,路由会找到调用的服务目的地。绝大部分情况下,它在本区域内就能找到相应的服务,不需要跨区,这取决于服务的部署情况。为了提高响应速度,每个可用区都需要部署关键的服务,除非本可用区的服务崩溃了,否则在这种情况下不会出现跨区访问。有些服务不是那么重要,可能只会在某个或某几个可用区中部署,这时也可能会出现服务跨可用区调用的情况。


这样不仅更好地管理了依赖,解决了服务器可用区调用问题,还解决了 API 访问安全问题:每个可用区建立一个 VPC(虚拟私有云),所有的服务都在 VPC 内,VPC 内的 API 调用可忽略安全验证,跨 VPC 路由节点之间用安全组来限 IP 白名单访问,只允许路由节点可以跨可用区访问其他 VPC 内的路由节点,服务访问路由或者路由访问服务都必须在同一个 VPC 内使用内网地址访问。

相关文章
|
29天前
|
弹性计算 API 持续交付
后端服务架构的微服务化转型
本文旨在探讨后端服务从单体架构向微服务架构转型的过程,分析微服务架构的优势和面临的挑战。文章首先介绍单体架构的局限性,然后详细阐述微服务架构的核心概念及其在现代软件开发中的应用。通过对比两种架构,指出微服务化转型的必要性和实施策略。最后,讨论了微服务架构实施过程中可能遇到的问题及解决方案。
|
2月前
|
Cloud Native Devops 云计算
云计算的未来:云原生架构与微服务的革命####
【10月更文挑战第21天】 随着企业数字化转型的加速,云原生技术正迅速成为IT行业的新宠。本文深入探讨了云原生架构的核心理念、关键技术如容器化和微服务的优势,以及如何通过这些技术实现高效、灵活且可扩展的现代应用开发。我们将揭示云原生如何重塑软件开发流程,提升业务敏捷性,并探索其对企业IT架构的深远影响。 ####
47 3
|
2月前
|
Cloud Native 安全 数据安全/隐私保护
云原生架构下的微服务治理与挑战####
随着云计算技术的飞速发展,云原生架构以其高效、灵活、可扩展的特性成为现代企业IT架构的首选。本文聚焦于云原生环境下的微服务治理问题,探讨其在促进业务敏捷性的同时所面临的挑战及应对策略。通过分析微服务拆分、服务间通信、故障隔离与恢复等关键环节,本文旨在为读者提供一个关于如何在云原生环境中有效实施微服务治理的全面视角,助力企业在数字化转型的道路上稳健前行。 ####
|
28天前
|
Java 开发者 微服务
从单体到微服务:如何借助 Spring Cloud 实现架构转型
**Spring Cloud** 是一套基于 Spring 框架的**微服务架构解决方案**,它提供了一系列的工具和组件,帮助开发者快速构建分布式系统,尤其是微服务架构。
154 69
从单体到微服务:如何借助 Spring Cloud 实现架构转型
|
27天前
|
运维 监控 持续交付
微服务架构解析:跨越传统架构的技术革命
微服务架构(Microservices Architecture)是一种软件架构风格,它将一个大型的单体应用拆分为多个小而独立的服务,每个服务都可以独立开发、部署和扩展。
167 36
微服务架构解析:跨越传统架构的技术革命
|
30天前
|
设计模式 负载均衡 监控
探索微服务架构下的API网关设计
在微服务的大潮中,API网关如同一座桥梁,连接着服务的提供者与消费者。本文将深入探讨API网关的核心功能、设计原则及实现策略,旨在为读者揭示如何构建一个高效、可靠的API网关。通过分析API网关在微服务架构中的作用和挑战,我们将了解到,一个优秀的API网关不仅要处理服务路由、负载均衡、认证授权等基础问题,还需考虑如何提升系统的可扩展性、安全性和可维护性。文章最后将提供实用的代码示例,帮助读者更好地理解和应用API网关的设计概念。
64 8
|
2月前
|
Dubbo Java 应用服务中间件
服务架构的演进:从单体到微服务的探索之旅
随着企业业务的不断拓展和复杂度的提升,对软件系统架构的要求也日益严苛。传统的架构模式在应对现代业务场景时逐渐暴露出诸多局限性,于是服务架构开启了持续演变之路。从单体架构的简易便捷,到分布式架构的模块化解耦,再到微服务架构的精细化管理,企业对技术的选择变得至关重要,尤其是 Spring Cloud 和 Dubbo 等微服务技术的对比和应用,直接影响着项目的成败。 本篇文章会从服务架构的演进开始分析,探索从单体项目到微服务项目的演变过程。然后也会对目前常见的微服务技术进行对比,找到目前市面上所常用的技术给大家进行讲解。
60 1
服务架构的演进:从单体到微服务的探索之旅
|
2月前
|
负载均衡 Java 持续交付
深入解析微服务架构中的服务发现与负载均衡
深入解析微服务架构中的服务发现与负载均衡
79 7
|
2月前
|
消息中间件 运维 Kubernetes
后端架构演进:从单体到微服务####
本文将探讨后端架构的演变过程,重点分析从传统的单体架构向现代微服务架构的转变。通过实际案例和理论解析,揭示这一转变背后的技术驱动力、挑战及最佳实践。文章还将讨论在采用微服务架构时需考虑的关键因素,包括服务划分、通信机制、数据管理以及部署策略,旨在为读者提供一个全面的架构转型视角。 ####
39 1
|
2月前
|
弹性计算 运维 开发者
后端架构优化:微服务与容器化的协同进化
在现代软件开发中,后端架构的优化是提高系统性能和可维护性的关键。本文探讨了微服务架构与容器化技术如何相辅相成,共同推动后端系统的高效运行。通过分析两者的优势和挑战,我们提出了一系列最佳实践策略,旨在帮助开发者构建更加灵活、可扩展的后端服务。