架构

简单介绍 10 个常见的软件架构

有没有想过如何设计大型企业及系统?在开发之前,我们必须要选择一个合适的架构,以保证我们软件的功能和质量。今天就简单介绍一下常用的 10 个架构。

什么是架构?

一直以来,在软件行业,对于什么是架构,都有很多的争论,每个人都有自己的理解。甚至于很多架构师一说架构,就开始谈论什么应用架构、硬件架构、数据架构等等。我曾经也到处寻找过架构的定义,请教过很多人,结果发现,没有大家都认可的定义。套用一句关于 big data 流行的笑话,放在架构上也适用:

Architecture is like teenage sex,everybody talks about it,nobody really knows what is it。

事实上,架构在软件发明时的 N 多年以前,就已经存在了,这个词最早是跟随着建筑出现的。在软件工程中,架构以理解为:

  1. 根据要解决的问题,对目标系统的边界进行界定。
  2. 并对目标系统按某个原则的进行切分。切分的原则,要便于不同的角色,对切分出来的部分,并行或串行开展工作,一般并行才能减少时间。
  3. 并对这些切分出来的部分,设立沟通机制。
  4. 根据 3,使得这些部分之间能够进行有机的联系,合并组装成为一个整体,完成目标系统的所有工作。

软件架构入门

软件架构(software architecture)就是软件的基本结构。

合适的架构是软件成功的最重要因素之一。大型软件公司通常有专门的架构师职位(architect),只有资深程序员才可以担任。

O'Reilly 出版过一本免费的小册子《Software Architecture Patterns》PDF), 介绍了五种最常见的软件架构,是非常好的入门读物。我读后受益匪浅,下面就是我的笔记。…

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编程为例讲解。

一、串行化

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