架构

架构师于小波:魅族实时消息推送架构

【编者按】此文是根据魅族架构师于小波在msup和魅族联合举办的#魅族技术开放日#的演讲中的分享内容整理而成,于小波分享了魅族实时消息推送架构的其中遇到的坑和一些心得体会。

系统介绍

这个系统数据情况是这样的,实时在线的用户是2500万左右,下面有一个趋势图,从今年1到10月份的都列出来了,这个系统一天PV量是50亿左右,这个系统推送速度可以达到600万条/分钟。…

构架稳定与可扩展的优惠券系统

每次打完滴滴, 我们都可以分享领券页面到朋友圈, 让大家一起来领券. 而领完券后, 一大堆5折券到账的感觉一定很爽(可惜现在的折扣越来越少了). 想必大家都对滴滴的优惠券影响深刻. 滴滴的用户规模如此之大, 送券力度如此之高, 如果由我们来做,该如何构架这样一个稳定且有扩展性的系统呢?

可扩展的定义

我们这里主要考虑这两个方面的扩展:

  1. 业务扩展
    变更或新增业务逻辑时, 尽量对已有的核心模块影响最小,保证系统整体的稳定性.
  2. 性能扩展
    保证系统是可以水平扩展的, 从而具有应对更高的负载能力.

一个系统的稳定性,除了需要由健壮的代码来保证外, 架构上的拆分,也会有相当大的影响.
比如:我们将易变的模块(需求变化频繁)和稳定的模块糅合在一起部署的话, 易变模块的变化造成整个系统频繁的部署,就会对整个系统带来极大的风险.
所以扩展性在系统设计之初就需要着重考虑.

功能和性能需求:

抛开具体业务的架构都是耍流氓, 那我们先从功能和性能需求上对要做的优惠券系统有个整体上的认识, 来看看哪些需求是易变的,哪些需求是稳定的.

优惠券的生命周期

优惠券作为在线交易系统(电商,O2O)的一种重要营销手段, 每张优惠券的生命周期都由两个阶段组成:

  • 发券

大型网站架构系列:分布式消息队列

以下是消息队列以下的大纲,本文主要介绍消息队列概述,消息队列应用场景和消息中间件示例(电商,日志系统)。

本次分享大纲

  1. 消息队列概述
  2. 消息队列应用场景
  3. 消息中间件示例
  4. JMS消息服务(见第二篇:大型网站架构系列:分布式消息队列(二)
  5. 常用消息队列(见第二篇:大型网站架构系列:分布式消息队列(二)
  6. 参考(推荐)资料(见第二篇:大型网站架构系列:分布式消息队列(二)
  7. 本次分享总结(见第二篇:大型网站架构系列:分布式消息队列(二)

一、消息队列概述

消息队列中间件是分布式系统中重要的组件,主要解决应用耦合,异步消息,流量削锋等问题。实现高性能,高可用,可伸缩和最终一致性架构。是大型分布式系统不可缺少的中间件。

目前在生产环境,使用较多的消息队列有ActiveMQ,RabbitMQ,ZeroMQ,Kafka,MetaMQ,RocketMQ等。

二、消息队列应用场景

以下介绍消息队列在实际应用中常用的使用场景。异步处理,应用解耦,流量削锋和消息通讯四个场景。

2.1异步处理

场景说明:用户注册后,需要发注册邮件和注册短信。传统的做法有两种1.串行的方式;2.并行方式。

(1)串行方式:将注册信息写入数据库成功后,发送注册邮件,再发送注册短信。以上三个任务全部完成后,返回给客户端。(架构KKQ:466097527,欢迎加入)

(2)并行方式:将注册信息写入数据库成功后,发送注册邮件的同时,发送注册短信。以上三个任务完成后,返回给客户端。与串行的差别是,并行的方式可以提高处理的时间。

假设三个业务节点每个使用50毫秒钟,不考虑网络等其他开销,则串行方式的时间是150毫秒,并行的时间可能是100毫秒。

因为CPU在单位时间内处理的请求数是一定的,假设CPU1秒内吞吐量是100次。则串行方式1秒内CPU可处理的请求量是7次(1000/150)。并行方式处理的请求量是10次(1000/100)。

 

小结:如以上案例描述,传统的方式系统的性能(并发量,吞吐量,响应时间)会有瓶颈。如何解决这个问题呢?

引入消息队列,将不是必须的业务逻辑,异步处理。改造后的架构如下:

按照以上约定,用户的响应时间相当于是注册信息写入数据库的时间,也就是50毫秒。注册邮件,发送短信写入消息队列后,直接返回,因此写入消息队列的速度很快,基本可以忽略,因此用户的响应时间可能是50毫秒。因此架构改变后,系统的吞吐量提高到每秒20 QPS。比串行提高了3倍,比并行提高了两倍。

2.2应用解耦

场景说明:用户下单后,订单系统需要通知库存系统。传统的做法是,订单系统调用库存系统的接口。如下图:(架构KKQ:466097527,欢迎加入)

传统模式的缺点:

1)  假如库存系统无法访问,则订单减库存将失败,从而导致订单失败;

2)  订单系统与库存系统耦合;

REST真的完全适合微服务架构吗?

【编者的话】作者根据自己的微服务经验,提出REST并不是微服务的唯一通信机制,从而介绍了微服务的几种通信机制,包括REST、管道以及基于异步消息传递。同时,作者提出了在不同的场景下可以使用不同的通信机制。

在我接触微服务的这段时间,大部分关于如何安装部署微服务的线上样例或文章都一致认为REST是微服务之间通信的唯一方式。因此,你可能理所当然地认为REST就是微服务的一种标准,并且是设计与实现微服务系统一种方式。然而,并非如此。…

Nginx+Keepalived实现站点高可用

公司内部 OA 系统要做线上高可用,避免单点故障,所以计划使用2台虚拟机通过 Keepalived 工具来实现 nginx 的高可用(High Avaiability),达到一台nginx入口服务器宕机,另一台备机自动接管服务的效果。(nginx做反向代理,实现后端应用服务器的负载均衡)快速搭建请直接跳至 第2节。…

TCP与HTTP连接管理

一. HTTP事务时延原因(HTTP权威指南 P86)

1.客户端首先需要根据URI确定WEB服务器的IP和端口号, 那么DNS解析上花的时间会很多(大多数HTTP客户端会有一个小的DNS缓存)

2. 客户端会向服务器发送建立TCP连接请求, 每个请求建立会耗时间, 如果HTTP事务多的话, 这个时间会明显提高…

消息队列设计精要

消息队列已经逐渐成为企业IT系统内部通信的核心手段。它具有低耦合、可靠投递、广播、流量控制、最终一致性等一系列功能,成为异步RPC的主要手段之一。
当今市面上有很多主流的消息中间件,如老牌的ActiveMQ、RabbitMQ,炙手可热的Kafka,阿里巴巴自主开发的Notify、MetaQ、RocketMQ等。…

深入浅出LVS:企业集群平台负载均衡的三种模式和算法实现

一、LVS集群常见架构图

Load Balancer层:位于整个集群系统的最前端,由一台或多台负载调度器(Director Server)组成。LVS核心模板IPVS就安装在Director Server上,而Director的主要作用类似于一个路由器,它含有为完成LVS功能所设定的路由表,通过这些路由表把用户的请求分发给Server Array层的应用服务器(Real Server)。…

分布式系统里session同步的那些事儿

几周前,有个盆友问老王,说现在有多台服务器,怎么样来解决这些服务器间的session 同步问题?老王一下就来精神了,因为在 n 年以前,老王还在学校和几个同学一起所谓创业的时候,也遇到了类似的问题。当时查了很多资料,没有解决,于是后来投身百度,终于学到了“葵花宝典”,方才大彻大悟。所以,今天想跟大家分享一下关于 session 同步的那些事儿。

秉着问题驱动的原则,老王先提几个问题:

1 、什么是 session ?什么又是 cookie ?他俩有啥联系和区别?

2 、为什么要在多台服务器间进行 session 的共享同步?

3 、以及有哪些方法来实现这个同步?

大家快搬板凳,老王开始扯淡咯 ~…

第 3 页,共 9 页12345...最旧 »