电商平台备战促销季的运维秘诀——高可用服务层 推荐 原创 曹林华 2018-05-09 18:14:02 ©著作权 文章标签 高可用 架构 文章分类 软件研发 ©著作权归作者所有:来自51CTO博客作者曹林华的原创作品,请联系作者获取转载授权,否则将追究法律责任 高可用设计是互联网系统架构的基础之一,以天猫双十二交易数据为例,支付宝峰值支付次数超过 8 万笔。大家设想一下,如果这个时候系统出现不可用的情况,那后果将不可想象。 而解决这个问题的根本就是服务层的高可用。 什么是服务层 众所周知,服务层主要用来处理网站业务逻辑的,是大型业务网站的核心。比如下面三个业务系统就是典型的服务层,提供基础服务功能的聚合 用户中心:主要负责用户注册、登录、获取用户用户信息功能 交易中心:主要包括正向订单生成、逆向订单、查询、金额计算等功能 支付中心:主要包括订单支付、收银台、对账等功能 整体架构 业务发展初期主要以业务为导向,一般采用 「ALL IN ONE」的架构方式来开发产品,这个阶段用一句话概括就是 「糙猛快」。当发展起来之后就会遇到下面这些问题 文件大:一个代码文件出现超过 2000 行以上 耦合性严重:不相关业务都直接堆积在 Serivce 层中 维护代价高:人员离职后,根本没有人了解里面的业务逻辑 牵一发动全身:改动少量业务逻辑,需要重新把所有依赖包打包并发布 遇到这些问题,主要还是通过「拆」来解决 具体拆的方式,主要根据业务领域划分单元,进行垂直拆分。拆分开来的好处很明显,主要有以下这些: 每个业务一个独立的业务模块 业务间完全解耦 业务间互不影响 业务模块独立 单独开发、上线、运维 效率高 无状态设计 对于业务逻辑服务层,一般会设计成无状态化的服务,无状态化也就是服务模块只处理业务逻辑,而无需关心业务请求的上下文信息。所以无状态化的服务器之间是相互平等且独立的。 只有服务变为无状态的时候,故障转移才会变的很轻松。通常故障转移就是在某一个应用服务器不能服务用户请求的时候,通过负责均衡的方式,转移用户请求到其他应用服务器上来进行业务逻辑处理 超时设置 一般网站服务都会有主调服务和被调服务之分。超时设置就是主调服务在调用被调服务的时候,设置一个超时等待时间 Timeout。主调服务发现超时后,就进入超时处理流程。 主调服务 A 调用被调服务 B 时,设置超时等待时间为 3 秒,可能由于 B 服务宕机、网络情况不好或程序 BUG 之类,导致 B 服务不能及时响应 A 服务的调用。 此时 A 服务在等待 3 秒后,将触发超时逻辑而不再关心 B 服务的回复情况。 A 服务的超时逻辑可以依据情况而定,比如可以采取重试,对另一个对等的 B 服务去请求,或直接放弃结束这个请求调用。 超时设置的好处在于当某个服务不可用时,不至于整个系统发生雪崩反应。 异步调用 一般请求调用分为同步与异步两种。同步请求就像打电话,需要实时响应,而异步请求就像发送邮件一样,不需要马上回复。 这两种调用各有优劣,主要看面对哪种业务场景。比如在面对并发性能要求比较高的场景,异步调用就比同步调用有比较大的优势,这就好比一个人不能同时打多个电话,但是可以发送很多邮件。 那我们什么时候该采用异步调用? 其实主要看业务场景,如果业务允许延迟处理,那就采用异步的方式处理 那我们该怎么实现异步调用呢? 通常采用队列的方式来实现业务上的延迟处理,比如像订单中心调用配送中心,这种场景下面,业务是能接受延迟处理的。 那消息队列主要有哪些功能呢? 异步处理 - 增加吞吐量 削峰填谷 - 提高系统稳定性 系统解耦 - 业务边界隔离 数据同步 - 最终一致性保证 那到底有多少种队列呢?其实主要看处理业务的范围大小 应用内部 - 采用线程池,比如 Java ThreadPool 中 BlockingQueue 来做任务级别的缓冲与处理 应用外部 - 比如 RabbitMQ 、ActiveMQ 就是做应用级别的队列,方便进行业务边界隔离与提高吞吐量 同时,技术上来讲,消息队列一般分为两种模型:Pull VS Push Pull 模型:消费者主动请求消息队列,获取队列中的消息。 Push 模型:消息队列主动推送消息到消费者 其中 Pull 模式可以控制消费速度,不必担心自己处理不了消息,只需要维护队列中偏移量 Offset。所以对于消费量有限并且推送到队列的生产者不均匀的情况下,采用 Pull 模式比较合适。 Push 比较适合实时性要求比较高的情况,只要生产者消息发送到消息队列中,队列就会主动 Push 消息到消费者,不过这种模式对消费者的能力要求就提高很多,如果出现队列给消费者推送一些不能处理的消息,消费者出现 Exception 情况下,就会再次入队列,造成消费堵塞的情况。 不过互联网业界比较成熟的队列主要以采用 Pull 模式为主,像 Kafka、RabbitMQ(两种方式都支持)、RocketMQ 等 幂等 什么是幂等设计呢? 其实很简单,就是一次请求和多个请求的作用是一样的。用数学上的术语,即是 f(x) = f(f(x))。 那我们为什么要做幂等性的设计呢?主要是因为现在的系统都是采用分布式的方式设计系统,在分布式系统中调用一般分为 3 个状态:成功、失败、超时。 如果调用是成功或者失败都不要紧,因为状态是明确和清晰,但是如果出现超时的情况,就不知道请求是成功还是失败的。 如果出现这种情况,我们该怎么办呢?一般采取重试的操作,重新请求对应接口。如果请求接口是 Get 操作的话,那到还好,因为请求多次的效果是一样的。但是如果是 Post 、Put 操作的话,就会造成数据不一致,甚至数据覆盖等问题。 举个例子:在支付收银台页面进行支付的时候,因为网络超时的问题导致支付失败,这个时候我们都会再进行一次支付操作,但是当支付成功后,发现你的账户余额被减了 2 次,这个时候心里肯定很不爽,心里都要开始骂娘了... 造成这个问题的关键是:网络超时后,不知道支付是什么状态?成功还是失败呢?所以说幂等性设计是必须的,尤其在电商、金融、银行等对数据要求比较高的行业中。 一般在这种场景下我们该怎么解决呢? 请求方一般会生产一个唯一性 ID 标识,这个标识可以具有业务一样,比如订单号或者支付流水号,在发起请求时候带上唯一性 ID。 接收者在收到请求后,第一步通过获取唯一性 ID 来查询接收端是否有对应的记录,如果有的话,就直接将上次请求的结果返回,如果没有的话,就进行操作,并在操作完成后记录到对应的表里 服务降级 服务降级主要解决资源不足和访问量过大的问题,比如电商平台在双十一、618 等高峰时候采用部分服务不提供访问,减少对系统的影响。 那降级的方式有哪些呢? 延迟服务:比如春晚,微信发红包就出现抢到红包,但是账号余额并没有增加,要过几天才能加上去。其实这是微信内部采用延迟服务的方式来保证服务的稳定,通过队列实现记录流水账单 功能降级:停止不重要的功能是非常有用的方式,把相对不重要的功能暂停掉,让系统释放更多的资源。比如关闭相关文章的推荐、用户的评论功能等等,等高峰过去之后,在把服务恢复回来。 降低数据一致性:在大促的时候,我们发现页面上不显示真实库存的数据,只显示到底有还是没有库存这两种状态。 刚刚说了降级的方式,那我们操作降级的时候有哪些注意点呢? 清晰定义降级级别: 比如出现吞吐量超过 X,单位时间内响应时间超过 Y 秒、失败次数超过 Z 次等,这些阈值需要在准备的时候,通过压测的方式来确定。 梳理业务级别:降级之前,首先需要确定哪些业务是必须有,哪些业务是可以有的,哪些业务是可有可无的。 降级开关:可以通过接入配置中心(比如携程 Apollo、百度 Disconf )的方式直接后台降级。但是如果公司没有配置中心的话,可以封装一个 API 接口来切分,不过该 API 接口要做成幂等的方式,同时需要做一些简单的签名,来保证其一定的安全性。 总结 总结一下今天分享的主要内容 整体架构:根据业务属性进行垂直拆分,减少项目依赖,单独开发、上线、运维 无状态设计:应用服务中不能保存用户状态数据,如果有状态就会出现难以扩容、单点等问题 超时设置:当某个服务不可用时,不至于整个系统发生连锁反应 异步调用:同步调用改成异步调用,解决远程调用故障或调用超时对系统的影响 服务降级:牺牲非核心业务,保证核心业务的高可用 所有好的架构设计首要的原则并不是追求先进,而是合理性,要与公司的业务规模和发展趋势相匹配,任何一个公司,哪怕是现在看来规模非常大的公司,比如 BAT 之类,在一开始,其系统架构也应简单和清晰的。 但随着业务范围不断扩充,业务规模不断扩大,系统渐进复杂和庞大,让所有系统都遇到高可用的问题。那我们该如何避免类似的问题,构建高可用系统呢? 为此我特意写了一个专栏《带你玩转高可用》,将多年来在百度和沪江的架构设计实战经验,集结成这个专栏。 本专栏总共包含 15 篇文章,分成三大模块详细解释高可用架构的相关知识: 概念篇:介绍高可用架构理论与演进,这块比较偏理论。不过对于我们理解整套体系还是有必须的。 工程篇:介绍常见互联网分层中每一层高可用是怎么做的,包含 DNS、服务层、缓存层、数据层等 问题篇:介绍怎么排查线上常用的故障,包括机器、应用层等维度故障定位 专栏每周都会更新,持续 64 天。在这将近 2 个月内,我会带着大家去全面了解高可用架构的方方面面,同时会将遇到的这些问题和对应的解决方案抛出来,希望大家不要重复我遇到过的坑。同时也期待大家提出有意思的问题。 专栏地址:带你玩转高可用 赞 收藏 评论 分享 举报 上一篇:关于我 下一篇:亿级 ELK 日志平台构建实践 提问和评论都可以,用心的回复会被更多人看到 评论 发布评论 全部评论 () 最热 最新 相关文章 关于电商API接口|Vue电商后端管理API接口测试 这个项目的后端接口完全可以满足你们日常练手,一般而言,公司里项目中的接口足够你测不过来的(笔者)。当然你还可以自己开发一个项目后台api,比如我之前写的Django API开发案例。 还有一点需要说明,上面只是接口已经调通,具体接口如何校验的,你如何写demo去测试这个项目的api逻辑,还需要继续进行,这个执行的过程也就是练手的过程。 API mysql 数据 高可用keeplived、HAproxy HAproxy与Keepalived VRRP一、简介1.1 HAproxy HAProxy(High Availability Proxy)是一个高性能的开源负载均衡器和代理服务器,用于分发网络流量。它是一个免费的、快速的、可靠的解决方案,常用于提供高可用性、负载均衡和代理服务。HAProxy最初是为Linux系统设计的,但现在已经在多个平台上可用,包括各种Unix系统和Windows 服务器 Redis高可用哨兵 Redis sentinel实现redis高可用方案 redis Redis sentinel 电商平台备战促销季的运维秘诀——高可用服务层 高可用设计是互联网系统架构的基础之一,以天猫双十二交易数据为例,支付宝峰值支付次数超过 8 万笔。大家设想一下,如果这个时候系统出现不可用的情况,那后果将不可想象。 高可用 运维 电商平台 异步调用 数据 Java电商促销 # Java电商促销## 引言电子商务已经成为现代商业中的重要组成部分,而促销活动是电商平台提高销售额的重要手段之一。在电商促销活动中,Java作为一种强大的编程语言,可以被广泛应用于促销策划、数据分析和系统开发等方面。本文将介绍Java电商促销的基本概念和常见的促销策略,并提供相应的代码示例。## 电商促销概述电商促销是为了增加产品或服务销售而采取的一系列市场推广活动。在传统的实 java Java 定时任务 构建高并发高可用的电商平台架构 了解高并发电商平台需要的关键技术,如何在各种决策中进行平衡 架构 高并发 电商 构建高并发高可用的电商平台架构实践 构建高并发高可用的电商平台架构实践 一、 设计理念 1. 空间换时间 1) 多级缓存,静态化客户端页面缓存(http header中包含Expires/Cache of Control,last modified(304,server不返回body,客户端可以继续用cache,减少流量),ETag)反向代理缓存应用端的缓存(memcache)内存数据库Bu server 数据库 客户端 中间件 电商 部署一个高可用高并发的电商平台 电商平台 电商促销后台逻辑方案 电商所谓营销,归根结底都是订单金额的变化;如果我们清楚的知道订单金额的计算流程是怎样的,那么我们只需要顺着系统的计算流程做促销,就不用担心各种促销类型之间产生重叠或者冲突的情况了。 html 代码实现 增删查改 代码片段 订单系统 案例 | 某电商如何构建Zabbix高可用监控平台? 编者荐语: 作者所在电商平台通过Centos7.7+Keepalive+Zabbix+DRBD+Heartbeat+MySQL+ES-Cluster方案,构建了Zabbix的高可用集群环境。本文作者也在“Zabbix技术交流群”,欢迎加入交流。 【背景】由于公司业务环境Zabbix监控平台架构,无论在性能、稳定性还是版本升级方面都存在很大困难。本文将介绍通过Centos7.7+ zabbix “女人节”的威力:电商掀起促销狂潮 “女人节”的威力 春季,电商掀起促销狂潮,但很明显,这跟手机类没什么关系了。3月份,京东商城启动“春雷行动”,3C品类大打折。 而其他两家电商:苏宁易购、国美在线,前一个推出了“化妆品联合行动”,后一个开启了“花样女人节”,主推品类都是化妆品。 电商 促销 构建高并发高可用的电商平台架构大纲 一、 设计理念 1. 空间换时间1) 多级缓存,静态化客户端页面缓存(http header中包含Expires/Cache of Control,last modified(304,server不返回body,客户端可以继续用cache,减少流量),ETag)反向代理缓存应用端的缓存(memcache)内存数据库Buffer、cache机制(数据库,中间件等)回到顶部 Architecture 数据 数据库 负载均衡 zookeeper 电商系统促销活动-计算可用的优惠券 背景: 一、电商促销方案: 1、满减-指定专区商品 例如:300元减30元,500元减60元 2、X件Y元-指定专区商品 例如:A区2件398元,B区2件199元 3、直降-指定商品 4、限时特卖 二、优惠券: 1、全场卷 2、专场卷 3、指定商品卷 4、秒杀卷 分析: 假设:一个商品只可以属于一个 用户授权 权限系统 转: 构建高并发高可用的电商平台架构实践 转自:http://blog.csdn.net/yangbutao/article/details/12242441 从各个角度总结了电商平台中的架构实践,由于时间仓促,定了个初稿,待补充完善,欢迎大家一起交流。 转载请声明出处:http://blog.csdn.net/yangbutao/arti 数据 数据库 负载均衡 zookeeper 客户端 运维 高可用架构 运维框架 为什么要做标准化?标准化的过程实际上就是对运维对象的识别和建模过程。形成统一的对象模型后,各方在统一的认识下展开有效协作,然后针对不同的运维对象,再抽取出它们所对应的运维场景,接下来才是运维场景的自动化实现。 这有点像我们学的面向对象编程的思想,其实我们就是需要遵循这样一个思路,我们面对的就是一个个实体和逻辑运维对象。 在标准化的过程中,先识别出各个运维对象,然后我们日常做的所有运维工作,都应该 运维 高可用架构 标准化 运维 模型 架构 java 电商促销 电商java项目步骤详解 在之前的工作都很好完成的情况下,可以开始搭建电商框架了。 1. 首先,新建一个maven项目。 这里maven项目其实等于maven + Java Web项目。新建的过程中选择的archetype决定Java项目的类型,比如选择webapp 就是Java Web项目,选择quickstart 就 java 电商促销 java 测试 web.xml spring 电商云平台服务商 电商服务平台是做什么 首先说一下什么是电子商务平台:电子商务平台即是一个为企业或个人提供网上交易洽谈的平台。企业电子商务平台是建立在Internet网上进行商务活动的虚拟网络空间和保障商务顺利运营的管理环境;是协调、整合信息流、物质流、资金流有序、关联、高效流动的重要场所。企业、商家可充分利用电子商务平台提供的网络基础设施、支付平台、安全平台、管理平台等共享资源有效地、低成本地开展自己的商业活动。 电子商 电商云平台服务商 电子商务平台 Business 支付平台 电商平台服务器架构 电商平台服务模式 目前市面上常见的电商模式有5种:B2B、B2C、C2B、C2C、O2O;1、B2B模式: business to business,是指商家与商家建立的商业关系。如阿里巴巴。2、B2C模式: business to consumer,商对客模式。即通常说的商业零售,供应商直接把商品卖给用户。如:苏宁易购、京东、天猫、小米商城。3、C2B模式: customer to business,即消费者对企 电商平台服务器架构 其他 商业 电商平台功能架构 电商平台的构建 前言如今比较火的电商平台有很多,大家应该知道的有很多,比如说:淘宝、京东、拼多多、苏宁...当然除了这些还有紧跟其后的平台 唯品会、蘑菇街、聚美等一系列电商。那你知道怎么打造一个自己的电商平台吗? 怎样进行核心模块的设计与实现,为大家提供安全、可靠、易维护、高性能的电商平台方案吗?本文教你如何来打造,其实也不是那么难!只要你用心学、用心做就可以!!互联网特别是电子商务的发展,让我们的生活有了太多的 电商平台功能架构 开发平台 电子商务 架构 设计 高可用运维架构 高可用架构图 本章主要介绍通过saltstack构建系统高可用架构,以满足业务需求。通过Haproxy实现负载均衡调度后端Nginx+PHP服务器,Keepalived实现系统高可用功能,Memcached存储session会话,后端数据库采用Mysql并且实现主从复制以及读写分离。一、拓扑图一、系统架构图二、saltstack分层管理图我们通过saltstack实现的整个系统环境可以分为三部分:系统初始化: 高可用运维架构 运维 php 开发工具 centos