Browsed by
标签:Redis

图文:千万级高性能长连接网关是如何搭建的?

图文:千万级高性能长连接网关是如何搭建的?

閱讀本文約花費: 17 (分鐘)实时的响应总是让人兴奋的,就如你在微信里看到对方正在输入,如你在王者峡谷里一呼百应,如你们在直播弹幕里不约而同的 666,它们的背后都离不开长连接技术的加持。 每个互联网公司里几乎都有一套长连接系统 ,它们被应用在消息提醒、即时通讯、推送、直播弹幕、游戏、共享定位、股票行情等等场景。而当公司发展到一定规模,业务场景变得更复杂后,更有可能是多个业务都需要同时使用长连接系统。 业务间分开设计长连接会导致研发和维护成本陡增、浪费基础设施、增加客户端耗电、无法复用已有经验等等问题。共享长连接系统又需要协调好不同系统间的认证、鉴权、数据隔离、协议拓展、消息送达保证 等等需求,迭代过程中协议需要向前兼容,同时因为不同业务的长连接汇聚到一个系统导致容量管理的难度也会增大。 经过了一年多的开发和演进,经过我们服务面向内和外的数个 App、接入十几个需求和形态各异的长连接业务、数百万设备同时在线、突发大规模消息发送等等场景的锤炼,我们提炼出一个长连接系统网关的通用解决方案,解决了多业务共用长连接时遇到的种种问题。 知乎长连接网关致力于业务数据解耦、消息高效分发、解决容量问题,同时提供一定程度的消息可靠性保证。 我们怎么设计通讯协议? 业务解耦 支撑多业务的长连接网关实际上是同时对接多客户端和多业务后端的,是多对多的关系,他们之间只使用一条长连接通讯。 这种多对多的系统…

Read More Read More

微服务架构下的分布式限流方案全解析

微服务架构下的分布式限流方案全解析

閱讀本文約花費: 9 (分鐘)1.微服务限流 随着微服务的流行,服务和服务之间的稳定性变得越来越重要。缓存、降级和限流是保护微服务系统运行稳定性的三大利器。 缓存的目的是提升系统访问速度和增大系统能处理的容量,而降级是当服务出问题或者影响到核心流程的性能则需要暂时屏蔽掉,待高峰或者问题解决后再打开,而有些场景并不能用缓存和降级来解决,比如稀缺资源、数据库的写操作、频繁的复杂查询,因此需有一种手段来限制这些场景的请求量,即限流。 比如当我们设计了一个函数,准备上线,这时候这个函数会消耗一些资源,处理上限是1秒服务3000个QPS,但如果实际情况遇到高于3000的QPS该如何解决呢? 所以限流的目的应当是通过对并发访问/请求进行限速或者一个时间窗口内的的请求进行限速来保护系统,一旦达到限制速率就可以拒绝服务、等待、降级。 学习如何去实现一个分布式限流框架,首先,我们需要去了解最基本的两种限流算法。 2.限流算法 2.1漏桶算法 漏桶算法思路很简单,水(也就是请求)先进入到漏桶里,漏桶以一定的速度出水,当水流入速度过大会直接溢出,然后就拒绝请求,可以看出漏桶算法能强行限制数据的传输速率。示意图(来源网络)如下: 2.2令牌桶算法 令牌桶算法和漏桶算法效果一样但方向相反的算法,更加容易理解。随着时间流逝,系统会按恒定1/QPS时间间隔(如果QPS=100,则间隔是10ms)往桶里加入令牌(…

Read More Read More

Service Mesh Is Still Hard

Service Mesh Is Still Hard

閱讀本文約花費: 5 (分鐘)KubeCon + CloudNativeCon NA Virtual sponsor guest post from Lin Sun, Senior Technical Staff Member at IBM At ServiceMeshCon EU this August, William Morgan from Linkerd and I gave a joint talk entitled service mesh is still hard.  William detailed the improvements to Linkerd, while I covered the improvements to Istio.  It’s clear both projects are working hard to make it easier for users to adopt service mesh. Service mesh is more mature than it was one or two years ago, however, it’s still hard for users.  There are two types of …

Read More Read More

千万级用户的大型网站,应该如何设计其高并发架构?

千万级用户的大型网站,应该如何设计其高并发架构?

閱讀本文約花費: 10 (分鐘)目录 (1)单块架构 (2)初步的高可用架构 (3)千万级用户量的压力预估 (4)服务器压力预估 (5)业务垂直拆分 (6)用分布式缓存抗下读请求 (7)基于数据库主从架构做读写分离 (8)总结 (1)单块架构 一般一个网站刚开始建立的时候,用户量是很少的,大概可能就几万或者几十万的用户量,每天活跃的用户可能就几百或者几千个。 这个时候一般网站架构都是采用单体架构来设计的,总共就部署3台服务器,1台应用服务器,1台数据库服务器,1台图片服务器。 研发团队通常都在10人以内,就是在一个单块应用里写代码,然后写好之后合并代码,接着就是直接在线上的应用服务器上发布。 很可能就是手动把应用服务器上的Tomcat给关掉,然后替换系统的代码war包,接着重新启动Tomcat。 数据库一般就部署在一台独立的服务器上,存放网站的全部核心数据。 然后在另外一台独立的服务器上部署NFS作为图片服务器,存放网站的全部图片。应用服务器上的代码会连接以及操作数据库以及图片服务器。如下图所示: (2)初步的高可用架构 但是这种纯单块系统架构下,有高可用问题存在,最大的问题就是应用服务器可能会故障,或者是数据库可能会故障 所以在这个时期,一般稍微预算充足一点的公司,都会做一个初步的高可用架构出来。 对于应用服务器而言,一般会集群化部署。当然所谓的集群化部署,在初期用户量很少的情况…

Read More Read More

用户画像基础

用户画像基础

閱讀本文約花費: 31 (分鐘)导读:在互联网步入大数据时代后,用户行为给企业的产品和服务带来了一系列的改变和重塑,其中最大的变化在于,用户的一切行为在企业面前是可“追溯”“分析”的。企业内保存了大量的原始数据和各种业务数据,这是企业经营活动的真实记录,如何更加有效地利用这些数据进行分析和评估,成为企业基于更大数据量背景的问题所在。随着大数据技术的深入研究与应用,企业的关注点日益聚焦在如何利用大数据来为精细化运营和精准营销服务,而要做精细化运营,首先要建立本企业的用户画像。 01 画像简介 用户画像,即用户信息标签化,通过收集用户的社会属性、消费习惯、偏好特征等各个维度的数据,进而对用户或者产品特征属性进行刻画,并对这些特征进行分析、统计,挖掘潜在价值信息,从而抽象出用户的信息全貌,如图1-1所示。用户画像可看作企业应用大数据的根基,是定向广告投放与个性化推荐的前置条件,为数据驱动运营奠定了基础。由此看来,如何从海量数据中挖掘出有价值的信息越发重要。 大数据已经兴起多年,其对于互联网公司的应用来说已经如水、电、空气对于人们的生活一样,成为不可或缺的重要组成部分。从基础设施建设到应用层面,主要有数据平台搭建及运维管理、数据仓库开发、上层应用的统计分析、报表生成及可视化、用户画像建模、个性化推荐与精准营销等应用方向。 很多公司在大数据基础建设上投入很多,也做了不少报表,但业务部门觉得大…

Read More Read More

一个可供参考的Java高并发异步应用案例

一个可供参考的Java高并发异步应用案例

閱讀本文約花費: 11 (分鐘) 泰康在线微信公众号系泰康在线财产保险股份有限公司旗下平台,希望可以通过持续不断的创新,提升客户对于保险的认知及体验,通过对大数据技术的应用,精准的为客户设计产品以及提供服务。泰康在线微信公众号,现有1000多万粉丝。在日常的运营中,借助于红包奖励、卡券分享、消息通知、微信分享等手段,通过好的内容,好的活动、好的产品以及相应的精准营销来增强用户的粘性和活跃度。在日常运营中,公众号会通过给用户下发营销或者科普类的消息来通知客户。 根据经验,微信消息下发后10分钟后流量会逐步上升,30分钟左右到达峰值,1个小时后会显著下降。在这个时间段内,系统的压力会很大。在系统设计和改进中,系统的很多场景使用异步进行实现,一方面能缩短主流程的时间处理,另一方面能够通过异步队列进行一定程度的削峰。今天重点介绍单个JVM内的异步优化实践,不涉及分布式时的异步优化实践。在异步执行时,可以调用远程的服务集群来实现一定的任务分解。部署示意图整个系统都部署在公有云上,虚拟机上有部署1个Nginx,4个Tomcat,Nginx使用随机的方式负载均衡到Tomcat上面。虚机之间通过LB将客户请求转发到Nginx上面负载均衡,Nginx再将请求分配到tomcat应用服务器上。由多台应用服务器,对外服务提供Rest服务,在每个Tomcat内部使用异步队列。同时由一台控制服务器,进行异步任…

Read More Read More

微信、陌陌等著名IM软件设计架构详解

微信、陌陌等著名IM软件设计架构详解

閱讀本文約花費: 13 (分鐘)对微信、陌陌等进行了分析,发出来分享一下(时间有些久了) 电量:对于移动设备最大的瓶颈就是电量了。因为用户不可能随时携带电源,充电宝。所以必须考虑到电量问题。那就要检查我们工程是不是有后台运行,心跳包发送时间是不是合理。 流量:对于好多国内大部分屌丝用户来说可能还是包月30M,那么我们必须站在广大用户角度来考虑问题了。一个包可以解决的就一个包。 网络: 这个也是IM最核心的内容了,我们要做到在任何网络下等顺畅聊天那就不容易了,好多公司都用的xmpp框架,如果在强网络环境下,xmpp完全没有问题。但是那种弱网络环境下xmpp就束手无策啦,用户体验就很垃圾了。 个人觉得xmpp 可以玩玩(参考看这个RFC3920和RFC3921), 但是用来真正的产品就差远了。如果遇到一个做IM 的朋友张口闭口都说xmpp 的话,那么不用沟通了,肯定不是什么好产品。微信、QQ以前也曾用过xmpp,但是最后也放弃了xmpp,就知道xmpp有很多弊端了,还有就是报文太大,好臃肿,浪费流量。为了保证稳定,微信用了长链接和短链接相结合,例如: 1 、两个域名 微信划分了http模式(short链接)和 tcp 模式(long 链接),分别应对状态协议和数据传输协议 long.weixin.qq.com  dns che…

Read More Read More

最常用的Java框架或者开源项目有哪些?

最常用的Java框架或者开源项目有哪些?

閱讀本文約花費: 19 (分鐘)系统设计 微服务/分布式 基础框架 Spring Boot [1] :Spring Boot 可以轻松创建独立的生产级基于 Spring 的应用程序,内置 web 服务器让你可以像运行普通 Java 程序一样运行项目。另外,大部分 Spring Boot 项目只需要少量的配置即可,这有别于 Spring 的重配置。 spring-cloud-alibaba[2] : Spring Cloud Alibaba 致力于提供微服务开发的一站式解决方案。此项目包含开发分布式应用微服务的必需组件,方便开发者通过 Spring Cloud 编程模型轻松使用这些组件来开发分布式应用服务。 Spring Cloud Alibaba Sentinel[3] :A lightweight powerful flow control component enabling reliability and monitoring for microservices. (轻量级的流量控制、熔断降级 Java 库)。 Dubbo[4] :Apache Dubbo 是一个基于 Java 的高性能开源 RPC 框架。 Nacos[5] :Nacos 致力于帮助您发现、配置和管理微服务。Nacos 提供了一组简单易用的特性集,帮…

Read More Read More

软件架构万字漫谈:业务架构、应用架构与云基础架构

软件架构万字漫谈:业务架构、应用架构与云基础架构

閱讀本文約花費: 34 (分鐘) 本文首先介绍了架构的分类以及架构模式与架构风格其次介绍了DDD 领域驱动设计和微服务与云原生架构,最后介绍 Kuberentes 应用,了解详情请阅读下文。本文来自于知乎,由火龙果软件Alice编辑、推荐。 软件开发就是把一个复杂的问题分解为一系列简单的问题,再把一系列简单的解决方案组合成一个复杂的解决方案。而软件开发中最大的挑战,就是即能够快速高效地针对需求、环境的变化做出改变,也能够持续提供稳定、高可用的服务。而软件架构,就是软件系统的骨骼与框架。 所谓架构,见仁见智,很难有一个明确或标准的定义;但架构并非镜花水月或阳春白雪,有系统的地方就需要架构,大到航空飞机,小到一个电商系统里面的一个功能组件,都需要设计和架构。抽象而言,架构就是对系统中的实体以及实体之间的关系所进行的抽象描述,是对物/信息的功能与形式元素之间的对应情况所做的分配,是对元素之间的关系以及元素同周边环境之间的关系所做的定义。架构能将目标系统按某个原则进行切分,切分的原则,是要便于不同的角色进行并行工作,结构良好的创造活动要优于毫无结构的创造活动。 软件架构的核心价值,即是控制系统的复杂性,将核心业务逻辑和技术细节的分离与解耦。软件架构是系统的草图,它描述的对象是直接构成系统的抽象组件;各个组件之间的连接则明确和相对细致地描述组件之间的通信。在实现阶段,这些抽象组件被细化为实际…

Read More Read More

聊聊ServiceMesh 数据面板 Envoy

聊聊ServiceMesh 数据面板 Envoy

閱讀本文約花費: 27 (分鐘)Envoy 简介 在 Service Mesh 模式中,每个服务都配备了一个代理“sidecar”,用于服务之间的通信。这些代理通常与应用程序代码一起部署,并且它不会被应用程序所感知。Service Mesh 将这些代理组织起来形成了一个轻量级网络代理矩阵,也就是服务网格。这些代理不再是孤立的组件,它们本身是一个有价值的网络。其部署模式如图所示: 绿色部分代表应用程序 蓝色部分则是sidecar 服务网格是用于处理服务到服务通信的“专用基础设施层”。它通过这些代理来管理复杂的服务拓扑,可靠地传递服务之间的请求。 从某种程度上说,这些代理接管了应用程序的网络通信层。 Envoy是 Service Mesh 中一个非常优秀的 sidecar 的开源实现。我们就来看看 Envoy 都是做些什么工作。 Envoy 用到的几个术语 Host: 通常我们将 Host 看做是一个具备网络通信功能的实体(可以是一台物理机,也可以是一台移动设备等等) 。在 Envoy 中,host 是一个逻辑网络中的应用. 可能运行在由有多个主机组成的底层硬件,只要它们各自独立寻址。 Downstream: 请求发起者(服务请求方)。 Upstream: 请求接收者(服务提供方)。 Listener: 服务(程序)监听者。就是真正干活的。 envoy 会暴露一个或者多个listene…

Read More Read More

我是Redis,MySQL大哥被我害惨了

我是Redis,MySQL大哥被我害惨了

閱讀本文約花費: 10 (分鐘)我是Redis 你好,我是Redis,一个叫Antirez的男人把我带到了这个世界上。 说起我的诞生,跟关系数据库MySQL还挺有渊源的。 在我还没来到这个世界上的时候,MySQL过的很辛苦,互联网发展的越来越快,它容纳的数据也越来越多,用户请求也随之暴涨,而每一个用户请求都变成了对它的一个又一个读写操作,MySQL是苦不堪言。尤其是到“双11”、“618“这种全民购物狂欢的日子,都是MySQL受苦受难的日子。 据后来MySQL告诉我说,其实有一大半的用户请求都是读操作,而且经常都是重复查询一个东西,浪费它很多时间去进行磁盘I/O。 后来有人就琢磨,是不是可以学学CPU,给数据库也加一个缓存呢?于是我就诞生了! 出生不久,我就和MySQL成为了好朋友,我们俩常常携手出现在后端服务器中。 应用程序们从MySQL查询到的数据,在我这里登记一下,后面再需要用到的时候,就先找我要,我这里没有再找MySQL要。 为了方便使用,我支持好几种数据结构的存储: String Hash List Set SortedSet Bitmap ······ 因为我把登记的数据都记录在内存中,不用去执行慢如蜗牛的I/O操作,所以找我要比找MySQL要省去了不少的时间呢。 可别小瞧这简单的一个改变,我可为MySQL减轻了不小的负担!随着程序的运行,我缓存的数据越来越多,有相当部…

Read More Read More

浅谈服务治理、微服务与Service Mesh

浅谈服务治理、微服务与Service Mesh

閱讀本文約花費: 48 (分鐘)SOA与服务治理 SOA(面向服务的体系结构)概念由来已久,在10多年前便开始进入到我们广大软件开发者的视线中。SOA是一种粗粒度、松耦合服务架构,服务之间通过简单、精确定义接口进行通讯,不涉及底层编程接口和通讯模型。SOA可以看作是B/S模型、Web Service技术之后的自然延伸。 服务治理,也称为SOA治理,是指用来管理SOA的采用和实现的过程。以下是在2006年时IBM对于服务治理要点的总结: l 服务定义(服务的范围、接口和边界) l 服务部署生命周期(各个生命周期阶段) l 服务版本治理(包括兼容性) l 服务迁移(启用和退役) l 服务注册中心(依赖关系) l 服务消息模型(规范数据模型) l 服务监视(进行问题确定) l 服务所有权(企业组织) l 服务测试(重复测试) l 服务安全(包括可接受的保护范围) 限于当时的技术发展水平,广大软件设计与开发人员对于SOA和服务治理的技术认知还主要停留在Web Service和ESB总线等技术和规范上,并没有真正在软件开发中得以充分落地。 Dubbo开源 直到2011年10月27日,阿里巴巴开源了自己的SOA服务化治理方案的核心框架Dubbo,服务治理和SOA的设计理念开始逐渐在国内软件行业中落地,并被广泛应用。 Dubbo作为阿里巴巴内部的SOA服务化治理方案的核心框架,在2012年时已经…

Read More Read More

苏宁高时效、高并发秒杀业务中台的设计与实现

苏宁高时效、高并发秒杀业务中台的设计与实现

閱讀本文約花費: 20 (分鐘) 文章主要介绍了苏宁架构设计背景,苏宁的架构设计以及系统多活部署与单机房宕机场景下的降级方案 设计背景 对于苏宁易购主站而言,正常的用户购物流程囊括选品、下单、库存扣减、付款、订单状态更新、物流履约等。但是在电商业务中往往会涉及到对某些热点商品的秒杀场景。相比于正常购物流程,秒杀场景具有时效性高、并发量大、瞬时业务量极高的业务特性,往往会出现显著的分布式一致性问题。正常的业务系统不能很好地应对瞬时高并发的业务需求,因此就需要针对于秒杀场景进行相应的架构优化,抑或是设计专门用于秒杀的中台业务系统。 就秒杀业务而言,系统在瞬时会达到极高的并发量,如果与其它业务耦合,那么势必会对其它业务造成风险,因此基于安全性考虑和业务隔离原则,秒杀系统在设计上应该与其它系统充分解耦,单独部署。本文将讨论在苏宁现有的技术架构和中台组件的基础上,如何去实现一个通用型秒杀业务中台。 架构设计 1. 系统前端与负载层设计 图一:前端与负载层设计 鉴于秒杀业务本身的高并发特性,对用户请求进行前端分流是必不可少的一步。在系统上游就对部分用户请求进行处理,可以避免海量请求对后端服务器产生过大压力。因为用户往往在秒杀前几分钟就开始点击下单按钮,因此在秒杀开始前可以使用静态资源页面,用户请求由 CDN 直接响应,不必到达后端服务器。 此外,由于秒杀业务的高时效性特征,下单窗口基本集中在秒…

Read More Read More

Medium开发团队谈架构设计

Medium开发团队谈架构设计

閱讀本文約花費: 16 (分鐘) 背景   说到底,Medium是个社交网络,人们可以在这里分享有意思的故事和想法。据统计,目前累积的用户阅读时间已经超过14亿分钟,合两千六百年。   我们支持着每个月两千五百万的读者以及每周数以万计的文章发布。我们不想Medium的文章以阅读量为成功的依据,而是观点取胜。在Medium,文章的观点比作者的名头更重要。在这里,对话促进想法,并且很看重文字的力量。   我是Medium开发团队的负责人,此前在Google工作,负责开发Google+和Gmail,还创立了Closure项目。业余时间我喜欢滑雪跳伞和丛林冒险。   团队介绍   说起团队我非常自豪,这是一群富有好奇心而且想法丰富的天才,大家凑到一块是想做大事的。   团队以跨功能的任务驱动,这样每个人既可以专攻,又可以毫无压力的对整个架构有所贡献。我们的理念就是接触的方面越多,对团队的锻炼越大。更多关于团队的理念见此。   在工作组织方面,我们有着很大的自由度,当然作为一个公司组成,我们还是有季度目标的,并且鼓励敏捷开发模式。我们使用GitHub进行code review和问题跟踪,用Google Apps作为邮件、文档和表单系统。跟很多团队习惯使用Trello不同,我们是Slack和slack机器人的重度用户。   原始架构   最开始的时候,Medium部署在EC2上,用Node.j…

Read More Read More

HAProxy Nginx LVS Apache总结篇

HAProxy Nginx LVS Apache总结篇

閱讀本文約花費: 8 (分鐘)一、今天花点时间总结分享一下HAProxy、Nginx、LVS、Apache: 比较 HAProxy Nginx LVS Apache   简介 高可用、负载均衡且基于TCP和HTTP应用的代理,支持高并发,多集群反代。 高性能http和反向代理服务器、邮件代理服务器,支持高并发,轻量级Web,低系统资源消耗。 Linux虚拟服务器,常用VS/NAT、VS/TUN和VS/DR,三种模式负载均衡。 高性能Web服务器,支持代理,市场份额很高。   优点缺点 1、抗负载能力强,负载均衡速度高。2、支持session保持,Cookie引导,可通过url检测后端服务器健康状态。3、也可做MySQL、Email等负载均衡。4、一般不做Web服务器的Cache。 1、抗负载能力强。2、http、https、Emai协议功能较好,处理相应请求快。3、Web能力强,配置简单,支持缓存功能、适用动静分离,低内存消耗。4、不支持session直接保持,但可通过ip_hash解决,通过端口对后端服务器健康检查。 1、抗负载能力强。2、通过vrrp转发(仅分发)效率高,流量通过内核处理,没有流量产生。(理论)3、相当稳定可靠。4、不支持正则,不能做动静分离,配置略复杂,需要IP略多。 1、Web处理能力强,市场份额很高。(不过后期Ngi…

Read More Read More

如何构建以应用为中心的“Kubernetes”?

如何构建以应用为中心的“Kubernetes”?

閱讀本文約花費: 23 (分鐘)在上篇文章《上 Kubernetes 到底有什么业务价值?》,主要和大家介绍了上 Kubernetes 有什么业务价值,以及什么是“以应用为中心”的 Kubernetes。本文将跟大家具体分享如何构建“以应用为中心”的 Kubernetes。 如何构建“以应用为中心”的 Kubernetes? 构建这么一个以用户为中心的 Kubernetes,需要做几个层级的事情。 1. 应用层驱动 首先来看最核心的部分,上图中蓝色部分,也就是 Kubernetes。可以在 Kubernetes 之上定义一组 CRD 和 Controller。可以在 CRD 来做用户这一侧的 API,比如说 pipeline 就是一个 API,应用也是一个 API。像运维侧的扩容策略这些都是可以通过 CRD 的方式安装起来。 2. 应用层抽象 所以我们的需要解决第一个问题是应用抽象。如果在 Kubernetes 去做应用层抽象,就等同于定义 CRD 和 Controller,所以 Controller 可以叫做应用层的抽象。本身可以是社区里的,比如 Tekton,istio 这些,可以作为你的应用驱动层。这是第一个问题,解决的是抽象的问题。不是特别难。 3. 插件能力管理 很多功能不是 K8s 提供的,内置的 Controller 还是有限的,大部分能力来自于社区或者是自己开发的 …

Read More Read More

Scroll Up