电商互联网如何做微服务治理(SOA governance)?(上)

本文涉及的产品
服务治理 MSE Sentinel/OpenSergo,Agent数量 不受限
任务调度 XXL-JOB 版免费试用,400 元额度,开发版规格
注册配置 MSE Nacos/ZooKeeper,182元/月
简介: 电商互联网如何做微服务治理(SOA governance)?(上)

1 服务治理是什么

1.1 定义

按Anne Thomas Manes的定义是:企业为了确保事情顺利完成而实施的过程,包括最佳实践、架构原则、治理规程、规律以及其他决定性的因素。服务治理指的是用来管理SOA的采用和实现的过程。

1.2 服务治理针对的问题

服务治理中一些典型的问题是:

  1. 交付价值到利益相关者,这是投入与回报的问题
  2. 对标准和规则的遵从(这是和审计相关的)
  3. 变更管理:变更一个服务通常会引起不可预见的后果,因为服务的消费者对服务的提供者来说是不可知的。
  4. 服务质量的保证:弹性添加新服务需要对这些服务给予额外的关注。

1.3 服务治理包括的行为

服务治理的一些关键活动包括:

  1. 对开发新服务和升级现有服务的计划
  2. 管理服务的生命周期:确保升级服务不会影响目前的服务消费者
  3. 制定方针来限制服务行为:制定所有服务都要遵从的规则,确保服务的一致性
  4. 监控服务的性能:由于服务组合,服务停机和性能低下的后果是严重的。通过监控服务的性能和可用性,当问题出现的时候能马上采取应对措施。
  5. 管理由谁来调用服务、怎样调用服务

接下来看具体服务治理手段。

2 节点管理

2.1 服务调用失败原因

  • 服务提供者故障
    e.g. 服务器宕机、进程意外退出
  • 网络故障
    e.g. 服务提供者/注册中心/服务消费者中任意两者间网络故障

2.2 解决方案

2.2.1 注册中心主动摘除机制

要求服务提供者定时主动向注册中心汇报心跳,注册中心根据服务提供者节点最近一次汇报心跳的时间与上一次汇报心跳时间做比较。

如果超出一定时间,就认为服务提供者出现问题,继而把节点从服务列表中摘除,并把最近的可用服务节点列表推送给服务消费者。

2.2.2 服务消费者摘除机制

虽然上面方案可解决服务提供者节点故障,但若因注册中心与服务提供者间网络异常,最坏情况注册中心会把服务节点全部摘除,导致服务消费者没有可用服务节点调用,但服务提供者其实正常。

所以,将存活探测机制用在服务消费者这一端更合理,如果服务消费者调用服务提供者节点失败,就将该节点从内存中保存的可用服务提供者节点列表移除。

3 负载均衡

服务提供者节点一般以集群形式存在。对于服务消费者,在从服务列表中选取可用节点时,如果能让配置较高机器多承担一些流量,就能充分利用机器性能。

3.1 常用的负载均衡算法

3.1.1 随机

从可用的服务节点中随机选取一个节点。后端服务节点无论配置好坏,最终得到的调用量都差不多。

3.1.2 轮询

按固定权重,对可用服务节点进行轮询。如果所有服务节点的权重都是相同的,则每个节点的调用量也是差不多的。但可以给某些硬件配置较好的节点的权重调大些,这样的话就会得到更大的调用量,从而充分发挥其性能优势,提高整体调用的平均性能。

3.1.3 最少活跃调用

在服务消费者端内存动态维护同每个服务节点之间的连接数,当调用某个服务节点时,就给与这个服务节点之间的连接数加1,调用返回后,就给连接数减1。然后每次在选择服务节点时,根据内存里维护的连接数倒序排列,选择连接数最小的节点发起调用,也就是选择了调用量最小的服务节点,性能理论上也是最优的。


3.1.4 一致性Hash

相同参数的请求总是发到同一服务节点。当某一个服务节点出现故障时,原本发往该节点的请求,基于虚拟节点机制,平摊到其他节点上,不会引起剧烈变动。

这几种算法的实现难度也是逐步提升的,所以选择哪种节点选取的负载均衡算法要根据实际场景。如果后端服务节点的配置没有差异,同等调用量下性能也没有差异的话,选择随机或者轮询算法比较合适;如果后端服务节点存在比较明显的配置和性能差异,选择最少活跃调用算法比较合适。

目录
相关文章
|
7月前
|
人工智能 Java 数据库
飞算 JavaAI:革新电商订单系统 Spring Boot 微服务开发
在电商订单系统开发中,传统方式耗时约30天,需应对复杂代码、调试与测试。飞算JavaAI作为一款AI代码生成工具,专注于简化Spring Boot微服务开发。它能根据业务需求自动生成RESTful API、数据库交互及事务管理代码,将开发时间缩短至1小时,效率提升80%。通过减少样板代码编写,提供规范且准确的代码,飞算JavaAI显著降低了开发成本,为软件开发带来革新动力。
|
5月前
|
缓存 负载均衡 监控
微服务架构下的电商API接口设计:策略、方法与实战案例
本文探讨了微服务架构下的电商API接口设计,旨在打造高效、灵活与可扩展的电商系统。通过服务拆分(如商品、订单、支付等模块)和标准化设计(RESTful或GraphQL风格),确保接口一致性与易用性。同时,采用缓存策略、负载均衡及限流技术优化性能,并借助Prometheus等工具实现监控与日志管理。微服务架构的优势在于支持敏捷开发、高并发处理和独立部署,满足电商业务快速迭代需求。未来,电商API设计将向智能化与安全化方向发展。
|
4月前
|
缓存 监控 API
电商API的微服务架构优化策略
随着电商快速发展,API成为连接用户、商家与系统的核心。本文探讨微服务架构下电商API的优化策略,分析高并发、低延迟与数据一致性等挑战,并提供服务拆分、缓存异步、监控容器化等实践方案,助力构建高性能、高可用的电商系统,提升用户体验与业务效率。
116 0
|
12月前
|
架构师 中间件 API
微服务和 SOA 的 6 大核心区别,你都知道吗?
本文详解SOA与微服务的六大区别,帮助更好地理解和应用这两种架构,建议收藏。关注【mikechen的互联网架构】,10年+BAT架构经验倾囊相授。
微服务和 SOA 的 6 大核心区别,你都知道吗?
|
12月前
|
微服务
微服务与SOA区别
微服务与SOA区别
110 0
微服务与SOA区别
|
消息中间件 缓存 Java
亿级流量电商平台微服务架构详解
【10月更文挑战第2天】构建一个能够处理亿级流量的电商平台微服务架构是一个庞大且复杂的任务,这通常涉及到多个微服务、数据库分库分表、缓存策略、消息队列、负载均衡、熔断降级、分布式事务等一系列高级技术和架构模式。
293 3
|
Cloud Native 云计算 微服务
云原生时代:企业分布式应用架构的惊人蜕变,从SOA到微服务的大逃亡!
【8月更文挑战第8天】在云计算与容器技术推动下,企业分布式应用架构正经历从SOA到微服务再到云原生的深刻变革。SOA强调服务重用与组合,通过标准化接口实现服务解耦;微服务以细粒度划分服务,增强系统灵活性;云原生架构借助容器化与自动化技术简化部署与管理。每一步演进都为企业带来新的技术挑战与机遇。
351 6
|
Java 微服务 Spring
SpringBoot+Vue+Spring Cloud Alibaba 实现大型电商系统【分布式微服务实现】
文章介绍了如何利用Spring Cloud Alibaba快速构建大型电商系统的分布式微服务,包括服务限流降级等主要功能的实现,并通过注解和配置简化了Spring Cloud应用的接入和搭建过程。
SpringBoot+Vue+Spring Cloud Alibaba 实现大型电商系统【分布式微服务实现】
|
监控 Kubernetes Cloud Native
云原生架构下的微服务治理之道
【7月更文挑战第30天】在数字化转型的浪潮中,企业级应用正迅速向云原生架构迁移。本文将深入探讨云原生环境下微服务治理的最佳实践,包括服务发现、配置管理、流量控制等关键策略,并结合实例分析如何在保障系统弹性、可维护性的同时,优化资源利用效率和加快业务创新速度。
136 2
|
消息中间件 负载均衡 数据管理
微服务架构在电商平台中的应用与实践
在现代电商平台的开发和运维中,微服务架构成为了提升系统灵活性和可扩展性的关键技术。本篇文章从实践出发,深入探讨了微服务架构在电商平台中的具体应用,包括服务拆分策略、通信机制、数据管理、以及常见的挑战和解决方案。通过真实的案例分析和代码示例,帮助读者全面了解微服务架构的优势和实施方法,提供在实际项目中的实践指导。

热门文章

最新文章