架构

TCP接入层的负载均衡、高可用、扩展性架构

一、web-server的负载均衡

互联网架构中,web-server接入一般使用nginx来做反向代理,实施负载均衡。整个架构分三层:

  • 上游调用层,一般是browser或者APP
  • 中间反向代理层,nginx
  • 下游真实接入集群,web-server,常见web-server的有tomcat,apache

 

整个访问过程为:

  • browser向daojia.com发起请求
  • DNS服务器将daojia.com解析为外网IP(1.2.3.4)
  • browser通过外网IP(1.2.3.4)访问nginx
  • nginx实施负载均衡策略,常见策略有轮询,随机,IP-hash等
  • nginx将请求转发给内网IP(192.168.0.1)的web-server

 

由于http短连接,以及web应用无状态的特性,理论上任何一个http请求落在任意一台web-server都应该得到正常处理(如果必须落在一台,说明架构不合理,不能水平扩展)。

 

问题来了,tcp是有状态的连接,客户端和服务端一旦建立连接,一个client发起的请求必须落在同一台tcp-server上,此时如何做负载均衡,如何保证水平扩展呢?

 

二、单机法tcp-server

单个tcp-server显然是可以保证请求一致性:

  • client向tcp.daojia.com发起tcp请求
  • DNS服务器将tcp.daojia.com解析为外网IP(1.2.3.4)
  • client通过外网IP(1.2.3.4)向tcp-server发起请求

 

方案的缺点?

无法保证高可用。

 

三、集群法tcp-server

通过搭建tcp-server集群来保证高可用,客户端来实现负载均衡

  • client内配置有tcp1/tcp2/tcp3.daojia.com三个tcp-server的外网IP
  • 客户端通过“随机”的方式选择tcp-server,假设选择到的是tcp1.daojia.com
  • 通过DNS解析tcp1.daojia.com

实时系统架构与实践

实时系统架构与实践

概要
分享基于 MQTT 协议的、面向移动互联网的 实时消息、实时统计、实时在线系统的架构设计;团队在云主机、部署自动化、监控自动化实践;团队在高性能分布式 Key/Value 存储的实践。 听众受益: 了解 MQTT 协议在移动互联网、智能设备上使用的优势, 了解大型实时系统的基本架构设计原理, 小团队如何利用云端资源快速实现、运营产品, 自动化 部署、监控 系统及实践方法, 高性能 Key/Value 系统的新设计理念

http://www.infoq.com/cn/presentations/framework-and-implementation-of-real-time-system

消息总线真的能保证幂等?

一、缘起

如《消息总线消息必达》所述,MQ消息必达,架构上有两个核心设计点:

(1)消息落地

(2)消息超时、重传、确认

再次回顾消息总线核心架构,它由发送端、服务端、固化存储、接收端四大部分组成。

为保证消息的可达性,超时、重传、确认机制可能导致消息总线、或者业务方收到重复的消息,从而对业务产生影响。

举个栗子:

购买会员卡,上游支付系统负责给用户扣款,下游系统负责给用户发卡,通过MQ异步通知。不管是上半场的ACK丢失,导致MQ收到重复的消息,还是下半场ACK丢失,导致购卡系统收到重复的购卡通知,都可能出现,上游扣了一次钱,下游发了多张卡。

消息总线的幂等性设计至关重要,是本文将要讨论的重点。

二、上半场的幂等性设计

MQ消息发送上半场,即上图中的1-3

1,发送端MQ-client将消息发给服务端MQ-server

2,服务端MQ-server将消息落地

3,服务端MQ-server回ACK给发送端MQ-client

如果3丢失,发送端MQ-client超时后会重发消息,可能导致服务端MQ-server收到重复消息。

此时重发是MQ-client发起的,消息的处理是MQ-server,为了避免步骤2落地重复的消息,对每条消息,MQ系统内部必须生成一个inner-msg-id,作为去重和幂等的依据,这个内部消息ID的特性是:

(1)全局唯一

(2)MQ生成,具备业务无关性,对消息发送方和消息接收方屏蔽

有了这个inner-msg-id,就能保证上半场重发,也只有1条消息落到MQ-server的DB中,实现上半场幂等。

三、下半场的幂等性设计

MQ消息发送下半场,即上图中的4-6

4,服务端MQ-server将消息发给接收端MQ-client

5,接收端MQ-client回ACK给服务端

6,服务端MQ-server将落地消息删除

需要强调的是,接收端MQ-client回ACK给服务端MQ-server,是消息消费业务方的主动调用行为,不能由MQ-client自动发起,因为MQ系统不知道消费方什么时候真正消费成功。

如果5丢失,服务端MQ-server超时后会重发消息,可能导致MQ-client收到重复的消息。

此时重发是MQ-server发起的,消息的处理是消息消费业务方,消息重发势必导致业务方重复消费(上例中的一次付款,重复发卡),为了保证业务幂等性,业务消息体中,必须有一个biz-id,作为去重和幂等的依据,这个业务ID的特性是:

(1)对于同一个业务场景,全局唯一

(2)由业务消息发送方生成,业务相关,对MQ透明

六种网络应用架构模式

六种网络应用架构模式

六种网络应用架构模式,以socket编程为例讲解。

一、串行化

处理请求的串行化模型。
在串行化架构中,所有的客户端连接是依次进行处理的,因为不涉及并发,多个客户端不会同时接受服务。
串行化架构最大的优势在于它的简单性。没有锁,没有共享状态,处理完一个连接之后才能处理另一个。在资源使用方面亦是如此:一个实例处理一个连接,一个萝卜一个坑,绝不多消耗资源。
串行化架构明显的劣势是不能并发操作。即便是当前连接处于空闲,也不能处理等待的连接。…

使用LVS实现负载均衡原理及安装配置详解

负载均衡集群是 load balance 集群的简写,翻译成中文就是负载均衡集群。常用的负载均衡开源软件有nginx、lvs、haproxy,商业的硬件负载均衡设备F5、Netscale。这里主要是学习 LVS 并对其进行了详细的总结记录。

一、负载均衡LVS基本介绍

LB集群的架构和原理很简单,就是当用户的请求过来时,会直接分发到Director Server上,然后它把用户的请求根据设置好的调度算法,智能均衡地分发到后端真正服务器(real server)上。为了避免不同机器上用户请求得到的数据不一样,需要用到了共享存储,这样保证所有用户请求的数据是一样的。

LVS是 Linux Virtual Server 的简称,也就是Linux虚拟服务器。这是一个由章文嵩博士发起的一个开源项目,它的官方网站是 http://www.linuxvirtualserver.org 现在 LVS 已经是 Linux 内核标准的一部分。使用 LVS 可以达到的技术目标是:通过 LVS 达到的负载均衡技术和 Linux 操作系统实现一个高性能高可用的 Linux 服务器集群,它具有良好的可靠性、可扩展性和可操作性。从而以低廉的成本实现最优的性能。LVS 是一个实现负载均衡集群的开源软件项目,LVS架构从逻辑上可分为调度层、Server集群层和共享存储。

 

二、LVS的基本工作原理

1. 当用户向负载均衡调度器(Director Server)发起请求,调度器将请求发往至内核空间
2. PREROUTING链首先会接收到用户请求,判断目标IP确定是本机IP,将数据包发往INPUT链
3. IPVS是工作在INPUT链上的,当用户请求到达INPUT时,IPVS会将用户请求和自己已定义好的集群服务进行比对,如果用户请求的就是定义的集群服务,那么此时IPVS会强行修改数据包里的目标IP地址及端口,并将新的数据包发往POSTROUTING链
4.

微服务(Microservice)那点事

WHAT – 什么是微服务

微服务简介

这次参加JavaOne2015最大的困难就是听Microservice相关的session,无论内容多么水,只要题目带microservice,必定报不上名,可见Microservice有多火。最喜欢其中一页。关于这个典故,可以参考this,此图适用于一切高大上的名字——技术有SOA,Agile,CLOUD,DevOps等等,古代有道,气,八卦等等。此类名词的最大特点就是 一解释就懂,一问就不知,一讨论就打架。
screenshot

微服务的流行,Martin功不可没,这老头也是个奇人,特别擅长抽象归纳和制造概念,我觉的这就是最牛逼的markting啊,感觉这也是目前国人欠缺的能力。

Martin Fowler是国际著名的OO专家,敏捷开发方法的创始人之一,现为ThoughtWorks公司的首席科学家.福勒(Martin Fowler),在面向对象分析设计、UML、模式、软件开发方法学、XP、重构等方面,都是世界顶级的专家,现为Thought Works公司的首席科学家。Thought Works是一家从事企业应用开发和集成的公司。早在20世纪80年代,Fowler就是使用对象技术构建多层企业应用的倡导者,他著有几本经典书籍: 《企业应用架构模式》、《UML精粹》和《重构》等。—— 百度百科

先来看看传统的web开发方式,通过对比比较容易理解什么是Microservice Architecture。和Microservice相对应的,这种方式一般被称为Monolithic(比较难传神的翻译)。所有的功能打包在一个 WAR包里,基本没有外部依赖(除了容器),部署在一个JEE容器(Tomcat,JBoss,WebLogic)里,包含了 DO/DAO,Service,UI等所有逻辑。
screenshot

Monolithic比较适合小项目,优点是:

  • 开发简单直接,集中式管理
  • 基本不会重复开发
  • 功能都在本地,没有分布式的管理开销和调用开销

它的缺点也非常明显,特别对于互联网公司来说(不一一列举了):

  • 开发效率低:所有的开发在一个项目改代码,递交代码相互等待,代码冲突不断
  • 代码维护难:代码功能耦合在一起,新人不知道何从下手
  • 部署不灵活:构建时间长,任何小修改必须重新构建整个项目,这个过程往往很长
  • 稳定性不高:一个微不足道的小问题,可以导致整个应用挂掉
  • 扩展性不够:无法满足高并发情况下的业务需求

所以,现在主流的设计一般会采用Microservice Architecture,就是基于微服务的架构。简单来说, 微服务的目的是有效的拆分应用,实现敏捷开发和部署
screenshot

用《The art of scalability》一书里提到的scale cube比较容易理解如何拆分。你看,我们叫分库分表,别人总结成了scale cube,这就是抽象的能力啊,把复杂的东西用最简单的概念解释和总结。X轴代表运行多个负载均衡器之后运行的实例,Y轴代表将应用进一步分解为微服务

微信为什么不丢消息?

上一章和大家分享了《 http如何像tcp一样实时的收消息? 》 , 本章来聊一聊即时通讯(Instant Messaging,后简称im) 消息的可靠投递

一、报文类型 im的客户端与服务器通过发送报文(也就是网络包)来完成消息的传递,报文分为三种

请求报文 (request,后简称为为R)

应答报文 (acknowledge,后简称为A)…

Page 1 of 912345...Last »