不为有趣之事,何遣有涯之生
不失其所者久,死而不亡者寿

AMQ简明教程(12)

hzqiuxm阅读(2354)评论(49)

AMQ集群

Queue consumer clusters

ActiveMQ支持Consumer对消息高可靠性的负载平衡消费,如果一个Consumer死掉,该消息会转发到其它的Consumer消费的Queue上。
如果一个Consumer获得消息比其它Consumer快,那么他将获得更多的消息。
因此推荐ActiveMQ的Broker和Client使用failover://transport的方式来配置链接

Broker clusters

大部情况下是使用一系列的Broker和Client链接到一起。如果一个Broker死掉了,Client可以自动链接到其它Broker上。实现以上行为需要用failover协议作为Client。

如果启动了多个Broker,Client可以使用static discover或者 Dynamic discovery容易的从一个broker到另一个broker直接链接。

这样当一个broker上没有Consumer的话,那么它的消息不会被消费的,然而该broker会通过存储和转发的策略来把该消息发到其它broker上。

特别注意:ActiveMQ默认的两个broker,static链接后是单方向的,broker-A可以访问消费broker-B的消息,如果要支持双向通信,需要在netWorkConnector配置的时候,设置duplex=true 就可以了。

消息会较为平均的分配给2个集群,而不是每个消费者。即使某个消费者集群的消费者比其他集群中多,它获得的消息总数仍然差不多。不适合机器性能不均等的架构。

原因:networkConnector配置的可用属性conduitSubscriptions :默认true,标示是否把同一个broker的多个consumer当做一个来处理

负载均衡的时候一般设置为false, 设置为false后,会按照消费者个数来分配。

Master Slave

在5.9的版本里面,废除了Pure Master Slave的方式,目前支持:

1:Shared File System Master Slave:基于共享储存的Master-Slave:多个broker实例使用一个存储文件,谁拿到文件锁就是master,其他处于待启动状态,如果master挂掉了,某个抢到文件锁的slave变成master

2:JDBC Master Slave:基于JDBC的Master-Slave:使用同一个数据库,拿到LOCK表的写锁的broker成为master

3:Replicated LevelDB Store:基于ZooKeeper复制LevelDB存储的Master-Slave机制,这个是5.9新加的
具体的可以到官方察看: http://activemq.apache.org/masterslave.html

JDBC Master Slave的方式

利用数据库作为数据源,采用Master/Slave模式,其中在启动的时候Master首先获
得独有锁,其它Slaves Broker则等待获取独有锁。
推荐客户端使用Failover来链接Brokers。
具体如下图所示:

Master失败
如果Master失败,则它释放独有锁,其他Slaver则获取独有锁,其它Slaver立即获得独有锁后此时它将变成Master,并且启动所有的传输链接。同时,Client将停止链接之
前的Master和将会轮询链接到其他可以利用的Broker即新Master。如上中图所示

Master重启
任何时候去启动新的Broker,即作为新的Slave来加入集群,如上右图所示

JDBC Master Slave的配置

使用来配置消息的持久化,自动就会使用JDBC MasterSlave的方式。

AMQ简明教程(11)

hzqiuxm阅读(579)评论(0)

AMQ动态网络链接

多播协议multicast

ActiveMQ使用Multicast 协议将一个Service和其他的Broker的Service连接起来。IPmulticast是一个被用于网络中传输数据到其它一组接收者的技术。

Ip multicast传统的概念称为组地址。组地址是ip地址在224.0.0.0到239.255.255.255之间的ip地址。

ActiveMQ broker使用multicast协议去建立服务与远程的broker的服务的网络链接。

基本的格式配置

multicast://ipadaddress:port?transportOptions

transportOptions如下:
1:group:表示唯一的组名称,缺省值default
2:minmumWireFormatVersion:被允许的最小的wireformat版本,缺省为0
3:trace:是否追踪记录日志,默认false
4:useLocalHost:表示本地机器的名称是否为localhost,默认true
5:datagramSize:特定的数据大小,默认值4 * 1024
6:timeToLive:消息的生命周期,默认值-1
7:loopBackMode:是否启用loopback模式,默认false
8:wireFormat:默认用wireFormat命名
9:wireFormat.*:前缀是wireFormat

配置示例

1:默认配置,请注意,默认情况下是不可靠的多播,数据包可能会丢失
multicast://default
2:特定的ip和端口
multicast://224.1.2.3:6255
3:特定的ip和端口以及组名
multicast://224.1.2.3:6255?group=mygroupname

Activemq使用multicast协议的配置格式如下

<broker xmlns="http://activemq.apache.org/schema/core" brokerName="multicast" dataDirectory="${activemq.base}/data">
<networkConnectors>
<networkConnector name="default-nc" uri="multicast://default"/>
</networkConnectors>
<transportConnectors>
<transportConnector name="openwire" uri="tcp://localhost:61616" discoveryUri="multicast://default"/>
</transportConnectors>
</broker>

上面的配置说明
1:uri=“multicast://default”中的default是activemq默认的ip,默认动态的寻找地址
2:“discoveryUri”是指在transport中用multicast的default的地址传递
3:“uri”指动态寻找可利用的地址
4:如何防止自动的寻找地址?
(1)名称为openwire的transport,移除discoveryUri=”multicast://default”即可。传输链接用
默认的名称openwire来配置broker的tcp多点链接,这将允许其它broker能够自动发现和链接到可用的broker中。
(2)名称为“default-nc”的networkConnector,注释掉或者删除即可。ActiveMQ默认的networkConnector基于multicast协议的链接的默认名称是default-nc,
而且自动的去发现其他broker。去停止这种行为,只需要注销或者删除掉default-nc网络链接。
(3)使brokerName的名字唯一,可以唯一识别Broker的实例,默认是localhost

Multicast 协议和普通的tcp协议
它们是差不多的,不同的是Multicast能够自动的发现其他broker,从而替代了使用static功能列表brokers。

用multicast协议可以在网络中频繁的添加和删除ip不会有影响。
multicast协议的好处是:能够适应动态变化的地址。缺点:自动的链接地址和过度的销耗网络资源。

Discovery协议

Discovery是在multicast协议的功能上定义的。功能类似与failover功能。它将动态的发现multicast 协议的broker的链接并且随机的链接其中一个broker。

基本配置格式如下:

discovery:(discoveryAgentURI)?transportOptions

transportOptions如下:
1:reconnectDelay:再次寻址等待时间,缺省值10
2:initialReconnectDelay:初始化设定再次寻址等待时间,缺省值10
3:maxReconnectDelay:最大寻址等待时间, 缺省值30000
4:useExponentialBackOff:是否尝试BackOff重链接,默认是true
5:backOffMultiplier:尝试Backoff的次数,默认是2
6:maxReconnectAttempts:如果异常,最大的重新链接个数,默认是0
7:group:组唯一的地址,默认是default

示例:

discovery:(multicast://default)?initialReconnectDelay=100

Discovery协议的配置示例

<broker name="foo">
<transportConnectors>
<transportConnector uri="tcp://localhost:0"
discoveryUri="multicast://default"/>
</transportConnectors>
</broker>

Peer协议(适用内嵌的方式)
ActiveMQ提出了peer transport connector 以让你更加容易的去嵌入broker中网络中。
它将创建一个优于vm链接的p2p网络链接。
默认格式如下:peer://peergroup/brokerName?key=value

Peer协议基本使用
当我们启动了用peer协议时,应用将自动的启动内嵌broker,也将会自动的去配置
其它broker来建立链接,当然了,前提是必须属于一个组。 配置如下:

peer://groupa/broker1?persistent=false

另外,生产者和消费者都各自链接到嵌入到自己应用的broker,并且在在本地的同一个组名中相互访问数据。

Peer协议的基本原理示意图

在本地机器断网的情况下,本地的client访问本地brokerA将任然正常。
在断网的情况下发送消息到本地brokerA,然后网路链接正常后,所有的消息将重新发送并链接到brokerB

Fanout协议

Fanout协议是同时链接多个broker,默认的格式如下:

fanout:(fanoutURI)?key=value
示例:fanout:(static:(tcp://host1:61616,tcp://host2:61616,tcp://host3:61616))

表示client将试图链接到三个static列表中定义的三个URI

Fanout协议的配置方式如下:
fanout:(discoveryURI)?transportOptions
transportOptions如下:
1:initialReconnectDelay:重新链接的等待时间,默认是10
2:maxReconnectDelay:最大重新链接的等待时间,默认是30000
3:useExponentialBackOff:是否尝试BackOff重链接,默认是true
4:backOffMultiplier:尝试Backoff的次数,默认是2
5:maxReconnectAttempts:如果异常,最大的重新链接个数,默认是0
6:fanOutQueues:是否将topic消息转换queue消息,默认false
7:minAckCount:Broker链接的最小数,默认是2

配置示例:

fanout:(static:(tcp://localhost:61616,tcp://remotehost:61616))?initialReconnectDelay=100

特别提醒
Activemq不推荐使Consumer使用fanout协议。当Provider发送消息到多个broker中,测试Consumer可能收到重复的消息

AMQ简明教程(10)

hzqiuxm阅读(1043)评论(4)

AMQ的静态网络链接与容错链接

一台机器上启动多个broker步骤如下:

1:把整个conf文件夹复制一份,比如叫做conf2
2:修改里面的activemq.xml文件
(1)里面的brokerName 不能跟原来的重复
(2)数据存放的文件名称不能重复,比如:

<kahaDB directory="${activemq.data}/kahadb_2"/>

(3)所有涉及的transportConnectors 的端口,都要跟前面的不一样
3:修改jetty.xml,主要就是修改端口,比如:

<property name=“port” value=“8181”/> 端口必须和前面的不一样

4:到bin下面,复制一个activemq,比如叫做activemq2:
(1)修改程序的id,不能和前面的重复ACTIVEMQ_PIDFILE="$ACTIVEMQ_DATA/activemq2-hostname.pid"
(2)修改配置文件路径ACTIVEMQ_CONF="$ACTIVEMQ_BASE/conf2"
(3)修改端口,里面有个tcp的61616的端口,要改成不一样的,最好跟activemq.xml里面的tcp的端口一致
(4)然后就可以执行了,如果执行没有权限的话,就授权:chmod 751 activemq2

ActiveMQ的networkConnector是什么

在某些场景下,需要多个ActiveMQ的Broker做集群,那么就涉及到Broker到Broker的通信,这个
被称为ActiveMQ的networkConnector。
ActiveMQ的networkConnector默认是单向的,一个Broker在一端发送消息,另一Broker在另一
端接收消息。这就是所谓的“桥接”。 ActiveMQ也支持双向链接,创建一个双向的通道对于两个
Broker,不仅发送消息而且也能从相同的通道来接收消息,通常作为duplex connector来映射,如下:

“discovery“的概念
一般情况下,discovery是被用来发现远程的服务,客户端通常想去发现所有可利用的brokers;另一层意思,它是基于现有的网络Broker去发现其他可用的Brokers。

有两种配置Client到Broker的链接方式,一种方式:Client通过Statically配置的方式去连接Broker,一种方式:Client通过discovery agents来dynamically的发现Brokers

Static networks

Static networkConnector是用于创建一个静态的配置对于网络中的多个Broker。这
种协议用于复合url,一个复合url包括多个url地址。格式如下:
static:(uri1,uri2,uri3,...)?key=value
1:配置示例如下:

<networkConnectors>
<networkConnector name="local network" uri="static://(tcp://remotehost1:61616,tcp://remotehost2:61616)"/>
</networkConnectors>

Static networkConnector的基本原理示意图:

上图中,两个Brokers是通过一个static的协议来网络链接的。一个Consumer链接到brokerB的一个地址上 ,当Producer在brokerA上以相同的地址
发送消息时,此时它将被转移到brokerB上。也就是,BrokerA会转发消息到BrokerB上。

networkConnector配置的可用属性:
1:name:默认是bridge
2:dynamicOnly:默认是false,如果为true, 持久订时才创建对应的网路持久订阅。默认是启动时激活
3:decreaseNetworkConsumerPriority:默认是false。设定消费者优先权,如果为true,网络的消费者优先级降低为-5。如果为false,则默认跟本地消费者一样为0

一般的静态桥接的消费者消费的比本地消费者来的更快(桥接方的消费者被偏爱了),这一点要注意

4:networkTTL :默认是1 ,网络中用于消息和订阅消费的broker数量
5:messageTTL :默认是1 ,网络中用于消息的broker数量
6:consumerTTL:默认是1 ,网络中用于消费的broker数量
7:conduitSubscriptions :默认true,是否把同一个broker的多个consumer当做一个来处理

负载均衡的时候一般设置为false,否则负载均衡可能失效,因为所有的消费者被看成一个后,可能所有消息都给某一个消费者处理了

8:dynamicallyIncludedDestinations :默认为空,要包括的动态消息地址,类似于excludedDestinations,过滤一部分消息转发给桥接的broker
过滤要转移的消息如:

<dynamicallyIncludedDestinations>
<queue physicalName="include.test.foo"/>
<topic physicalName="include.test.bar"/>
</dynamicallyIncludedDestinations>

9:staticallyIncludedDestinations :默认为空,要包括的静态消息地址。类似于excludedDestinations,如:

<staticallyIncludedDestinations>
<queue physicalName="always.include.queue"/>
</staticallyIncludedDestinations>

10:excludedDestinations :默认为空,指定排除的地址,示例如下:

<networkConnectors>
<networkConnector uri="static://(tcp://localhost:61617)"
name="bridge" dynamicOnly="false" conduitSubscriptions="true"
decreaseNetworkConsumerPriority="false">
<excludedDestinations>
<queue physicalName="exclude.test.foo"/>
<topic physicalName="exclude.test.bar"/>
</excludedDestinations>
<dynamicallyIncludedDestinations>
<queue physicalName="include.test.foo"/>
<topic physicalName="include.test.bar"/>
</dynamicallyIncludedDestinations>
<staticallyIncludedDestinations>
<queue physicalName="always.include.queue"/>
<topic physicalName="always.include.topic"/>
</staticallyIncludedDestinations>
</networkConnector>
</networkConnectors>

11:duplex :默认false,设置是否能双向通信

两个broker消息互通

12:prefetchSize :默认是1000,持有的未确认的最大消息数量,必须大于0,因为网络消费者不能自己轮询消息
13:suppressDuplicateQueueSubscriptions:默认false,如果为true, 重复的订阅关系一产生即被阻止
14:bridgeTempDestinations :默认true,是否广播advisory messages来创建临时destination
15:alwaysSyncSend :默认false,如果为true,非持久化消息也将使用request/reply方式代替oneway方式发送到远程broker。
16:staticBridge :默认false,如果为true,只有staticallyIncludedDestinations中配置的destination可以被处理。

多线程consumer访问集群

static静态桥接的consumer具有的优先更高, 例子:A--->B 消息发送到A上,A上的消费者与B上的消费者相比,B上的优先级更高

集群下的消息回流功能

“丢失”的消息
有这样的场景,broker1和broker2通过networkConnector连接,一些consumers连接到broker1,
消费broker2上的消息。消息先被broker1从broker2上消费掉,然后转发给这些consumers。不幸的是转
发部分消息的时候broker1重启了,这些consumers发现broker1连接失败,通过failover连接到broker2
上去了,但是有一部分他们还没有消费的消息被broker2已经分发到了broker1上去了。这些消息,就好
像是消失了,除非有消费者重新连接到broker1上来消费。(即时配置成双向连接,也是取不到的)

怎么办呢?
从5.6版起,在destinationPolicy上新增的选项replayWhenNoConsumers。这个选项使得broker1
上有需要转发的消息但是没有消费者时,把消息回流到它原始的broker。同时把enableAudit设置为
false,为了防止消息回流后被当做重复消息而不被分发,示例如下:

<destinationPolicy>
<policyMap>
<policyEntries>
<policyEntry queue=">" enableAudit="false">
<networkBridgeFilterFactory>
<conditionalNetworkBridgeFilterFactory replayWhenNoConsumers="true"/>
</networkBridgeFilterFactory>
</policyEntry>
</policyEntries>
</policyMap>
</destinationPolicy>

注意:需要回流的broker中双方都要配置

容错的连接Failover Protocol

前面讲述的都是Client配置链接到指定的broker上。但是,如果Broker的链接失败怎么办呢?此时,Client有两个选项:要么立刻死掉,要么去连接到其它的broker上。

Failover协议实现了自动重新链接的逻辑。
这里有两种方式提供了稳定的brokers列表对于Client链接。
第一种方式:提供一个static的可用的Brokers列表。第二种方式:提供一个dynamic 发现的可用Brokers。
Failover Protocol 的配置方式

failover:(uri1,...,uriN)?key=value 或者 failover:uri1,...,uriN

Failover Protocol 的默认配置
默认情况下,这种协议用于随机的去选择一个链接去链接,如果链接失败了,那么会链接到其他的Broker上。

默认的配置定义了延迟重新链接,意味着传输将会在10秒后自动的去重新链接可用的broker。当然所有的重新链接参数都可以根据应用的需要而配置。

Failover Protocol 的使用示例,在客户端程序里面:

ConnectionFactory connectionFactory = newActiveMQConnectionFactory("failover:(tcp://192.168.1.106:61679,tcp://192.168.1.106:61819)?randomize=false");

如果randomize = true 比较平均的交给可以用的broker,但是在false的情况下,只要第一个broker有效,就会一直往第一个发

Failover Protocol 可用的配置参数

1:initialReconnectDelay:在第一次尝试重连之前等待的时间长度(毫秒),默认10
2:maxReconnectDelay:最长重连的时间间隔(毫秒),默认30000
3:useExponentialBackOff:重连时间间隔是否以指数形式增长,默认true
4:backOffMultiplier:递增倍数,默认2.0
5:maxReconnectAttempts: 默认-1|0,自版本5.6起:-1为默认值,代表不限重试次数;0代表从不重试
(只尝试连接一次,并不重连),5.6以前的版本:0为默认值,代表不限重试次数所有版本:如果设置为大于0的数,代表最大重试次数
6:startupMaxReconnectAttempts:初始化时的最大重连次数。一旦连接上,将使用maxReconnectAttempts的配置,默认0
7:randomize:使用随机链接,以达到负载均衡的目的,默认true
8:backup:提前初始化一个未使用连接,以便进行快速失败转移,默认false
9:timeout:设置发送操作的超时时间(毫秒),默认-1
10:trackMessages:设置是否缓存[故障发生时]尚未传送完成的消息,当broker一旦重新连接成功,便将这些缓存中的消息刷新到新连接的代理中,使得消息可以在broker切换前后顺利传送,默认false
11:maxCacheSize:当trackMessages启用时,缓存的最大字节,默认为128*1024bytes
12:updateURIsSupported:设定是否可以动态修改broker uri(自版本5.4起),默认true

技术架构指导原则

hzqiuxm阅读(566)评论(0)

技术架构设计原则

1 大道至简

避免过度设计

  • 努力把代码写得通俗易懂
  • 一个工程师好不好就看他能多快简化一个复杂问题,并构建易于理解的解决方案
  • 方案好不好的一个检验标准就是看其他人理解的快不快

DID设计方法

  • Design设计20倍的容量
  • Implement 实施3倍的容量
  • Deploy部署1.5倍的容量

三步简化方案 how to DiD?

  • 采用帕累托原则(2-8)简化范围(如何简化方案)

    先做那能产生80%效益的20%产品功能

  • 结合成本与可扩展性简化设计(如何简化设计)

    例如不需要的数据列就不要查询出来

  • 依靠专家经验简化部署(如何简化部署)

    使用成熟的开源解决方案

减少域名解析

  • 网站域名资源不要太多,合理利用各级缓存

减少页面目标

  • 合并CSS JS 图片
  • 压缩各种资源
  • 不同资源分配在不同的域名上

采用同构网络

  • 确保交换机和路由器源于同一供应商

2 分轴扩展

三维坐标扩展法,X,Y,X轴

X轴扩展

X轴:水平扩展:WEB集群,读写分离

实施速度快,研发成本低,事务处理扩展效果好,运营成本高

Y轴拆分

Y轴:垂直扩展:模块化,分库

从两个维度去分析扩展:功能或资源,一般团队逐渐变大后,业务比重增加,技术比重下降,生产力下降,所以采用专人负责专门模块可以减少业务比重投入,提升生产力

Z轴拆分

Z轴:又称分片:分表,SOA,微服务

一般根据一些独特属性:ID,位置,基础服务等进行拆分

水平扩展(向外扩展)

  • 拆分或复制服务与数据库来扩展系统,而不是向上扩展(利用更好的服务器性能)
  • 摩尔定律VS安迪比尔定律
  • 利用三维坐标扩展法为指导

金鱼而非汗血宝马

  • 使用普通PC服务器即可,不要使用性能成本很高的商业服务器
  • 金鱼便宜,可以轻易丢弃不用修复;宝马太贵维护成本过高

托管方案扩展

  • 系统部署到三个或更多的数据中心
  • 三个数据中心是最成本最优的方案
  • 避免拥有自己的数据中心,直到公司的规模大到可以通过建设和运行自己的数据中心来节省成本变为可能

利用云服务

  • 有效利用云服务,提升系统可伸缩性,节省成本

3 先对其器

不要陷入马斯洛锤子陷阱中:当你只有一个锤子时,任何东西看起来都像是钉子

适当使用数据库

  • 当需要ACID属性来保持数据之间的关系和一致性时才选择关系型数据库
  • 不要用关系数据库存储所有数据,利用不同NoSql综合存储

慎重使用防火墙

  • 不要让防火墙成为系统瓶颈
  • 对值得使用防火墙的内容上使用

积极使用日志文件

  • 打造完善的日志系统(比如ELK),使其成为追踪,预防,监控,自动化修复重要工具
  • 一个好的日志体系,生产环境问题将会越来越少,且越快解决

4 奥卡姆剃刀

避免画蛇添足

  • 不要在无需同步的地方一定采用同步
  • 利用好缓存技术,不要去查询刚刚入库的数据

停止重定向

  • 尽量避免重定向
  • 使用服务器配置来实现正确的重定向

放宽时间约束

  • 不要过分考虑响应及时性,系统无法扩展而停止服务比让用户有些失望相比更严重

5 缓存为王

利用CDN缓存

  • 利用CDN缓存解决区域化响应速度问题
  • 注意成本与效率之间的平衡

正确管理缓存

  • 正确使用HTTP头来管理缓存(什么头在什么场景下适用,不要生搬硬套)
  • 使用HTTP响应头确保Ajax请求响应可缓存

静态资源缓存

  • 利用nginx,varnish组合对静态资源,甚至某些动态内容进行缓存

应用数据缓存

  • 对热点业务数据采用memcached,redis等技术进行缓存,其可扩展性也可以参考三维坐标法
  • 如果是和用户有关的数据,注意分布式缓存扩展性问题(通过哈希一致性算法或数据预热方式来防止雪崩或穿透)

DAO缓存

  • 利用数据库持久化工具(如:mybatis)或本地缓存工具(Ecached)做数据持久层的一级缓存和二级缓存

6 前车之鉴

组织必须在深度和广度上学习
有些知识可以培训获得,有些知识必须从外部获得

失败乃成功之母

  • 拥有学习文化的组织更易于实现病毒式增长
  • 从客户中学习(出的问题,解决的需求)
  • 从业务技术的运营中学习
  • 关注失败,拒绝简化,牛人心态,谦卑态度

不要依赖QA发现错误

  • 做好自动化测试
  • 当测试活动获得超过一个工程师的价值时,应该招聘一个QA人员

不能回滚注定失败

  • 让每一次上线都具备快速的回滚能力

7 重中之重

从事务处理中清除商务智能

  • 尽早使用Nosql
  • 不要在关系数据库中使用存储过程,触发器,外键等约束与业务逻辑绑定

设计之初就考虑扩展性

  • 特别是关系性数据库结构的设计,提前考虑到其扩展性
  • 不要局限于数据库范式设计

正确使用数据库锁

  • 注意暗锁 、明锁、行锁、页锁、区间锁、表锁、数据库锁使用正确姿势

禁用分阶段提交

  • 最好的方式就是不要使用

慎用Select for Update

  • 避免在业务中使用

避免选择所有列

  • 遵循用到什么拿什么的原则

8 有备无患

用分布式(泳道)来隔离故障

  • 道理就和不要把鸡蛋放在一个篮子里一样
  • 不同的服务不要互相影响

拒绝单点故障

  • 在分布式系统的各层都要考虑单点故障问题

避免系统串联

  • 不要因为某个模块或服务问题,影响整个系统的运行

启用和禁用功能

  • 通过缓存刷新,可配置化等方式启用和禁用产品功能

9 超然物外

力求无状态

  • 无状态是一些系统可扩展性的基石

在浏览器中保存会话

  • 使用H5本地存储,JWT,cookie技术

用分布式缓存处理状态

  • 用集中的分布式缓存来保存,使得应用和web服务无状态化

10 意犹未尽

警惕第三方方案

  • 不要依赖供应商解决方案来实现可扩展性
  • 自己的命运自己来掌控

梯级存储策略

  • 做到存储成本与数据价值相匹配

异步通信

  • 非实时性响应需求建议采用异步通信方式

分类处理不同负载

  • 确保解决方案支持四种基本类型工作负载:归纳(数据形成),演绎(数据使用),批处理,用户交互
  • 彼此隔离
  • 不要因为非关键性业务影响到关键性业务

保持竞争力

  • 保持公司所有岗位人员的竞争力,不仅仅某一个

注:(本文根据《架构真经》内容结合作者本身经验整理修改而得)更加详细的解释会在本人《架构之道》课程里讲述

Gradle简明教程(5)

hzqiuxm阅读(673)评论(0)

模块化项目构建

规划好自己项目的模块
  • 根据高内聚低耦合的设计思想,设计符合自己项目的模块
  • 一般会有web层,控制层,服务层,数据层
  • 每个层下面的路径可以自定义,只后在构建文件build.gradle中说明就行

    建议采用默认的就行

大概的结构图如下:
项目结构示意图
每个模块下都有一个build.gradle文件,项目根目录下有一个 setting.gradle文件

理解setting文件
  • 对项目根目录下的setting.gradle文件进行配置多模块项目
rootProject.name = 'ziniuxiaozhu'
include 'common'
include 'service'
include 'webapp'
  • setting文件的执行是在初始化阶段
    回顾下gradle的三个生命周期
    构建生命周期

  • 初始化的时候先从本模块下的setting文件中寻找,再到根目录下去寻找

    也可以通过命令行参数控制setting搜索行为

  • 支持分层布局和扁平布局,当然个人推荐分层的,能够更细粒度控制组件的建模
配置build文件
  • build文件中包含了项目的插件配置,版本控制,依赖管理等
    一个根目录下build.gradle文件例子:
plugins{
    id 'org.springframework.boot' version '1.5.9.RELEASE'
}

allprojects{
    group = 'com.znxz'
    version = '1.0'

    apply plugin: 'org.springframework.boot'
}

subprojects{
    apply plugin: 'java'
    apply plugin: 'idea'

    // JVM 版本号要求
    sourceCompatibility = 1.8
    targetCompatibility = 1.8

    ext {
        springBootVersion = '1.5.10.RELEASE'
        springloadedVersion = '1.2.8.RELEASE'
    }

    idea {
        module {
            inheritOutputDirs = false
            outputDir = file("$buildDir/classes/main/")
            testOutputDir = file("$buildDir/classes/test/")
        }
    }


    [compileJava, compileTestJava, javadoc]*.options*.encoding = 'UTF-8'

    repositories {
        mavenLocal()
        maven{ url 'http://maven.aliyun.com/nexus/content/groups/public' }
        maven{ url 'http://www.ziniuxiaozhu.com:8081/nexus/content/groups/public' }
        mavenCentral()
        jcenter()
    }
    dependencies{
        compile ("org.hibernate.validator:hibernate-validator:6.0.7.Final")
        compile group: 'javax.validation', name: 'validation-api', version: '2.0.1.Final'

    }

}
  • 子模块的build.gradle文件一般是指名该模块的名称以及依赖的其他模块或第三方jar包
    例子如下:
project(':control'){

    dependencies{
        compile project(':service')
        //WEB服务
        compile("org.springframework.boot:spring-boot-starter-data-rest"){
            exclude group : 'org.hibernate', module :'hibernate-validator'
            exclude group : 'javax.validation', module :'validation-api'
        }
        //JWT
        compile("io.jsonwebtoken:jjwt:0.9.0")
        //SpringSecurity
        compile("org.springframework.boot:spring-boot-starter-security")
    }
}

Gradle简明教程(4)

hzqiuxm阅读(519)评论(0)

依赖管理概述

Gradle摒弃了Ivy和Maven依赖管理工具的一切缺点,更注重性能、构建可靠性以及可重复性

  • 通常开发都需要依赖一些流行的开源框架包,避免自己重复发明轮子
  • 随着项目的增大,依赖的模块和第三方类库会越来越多,如何组织与管理就显得尤为重要
  • 自动化依赖管理可以解决传递性依赖,版本管理等问题
  • 搭建内部仓库解决中央仓库的单点依赖 Sonatype Nexus, JFrog, Artifactory
  • Gradle提供了很有价值的依赖报告

一个自动化依赖结构图
自动化依赖管理

依赖配置

  • 通过project实例添加和访问配置
  • 每个项目都有一个ConfigurationContainer类的容器来管理相应的配置
  • 定义一个Cargio类配置的例子
configurations{
        cagro {
            description = 'classpath for cargo Ant tasks'
            visible = false
        }
    }

声明依赖

  • 外部模块依赖
  • 项目依赖
  • 文件依赖
  • 客户端模块依赖
  • Gradle运行时依赖

每个Gradle项目都有依赖处理器实例,由DependencyHandler接口来表示

外部依赖
依赖属性
  • group 通常用来标示一个组织,公司或者项目
  • name 唯一标识
  • version 版本号 一般都包含主版本和次版本
  • classifier 用来区分相同group,name,version工件,但使用环境上有所区别

例子:
依赖属性例子

依赖标记

有两种标识方式
- 使用map结构形式,显示标记出group,name,version

cargo group: cargoGroup,name:' cargo-core-uberjar', vewrsion: cargoVersion
  • 使用字符串简写形式,类似上一节Hibernate的例子

使用gradle dependencise 命令来查看详细依赖报告

排除传递依赖

由于Gradle会自动管理传递依赖,如果你需要可以主动排除一些自动的依赖

  • 排除一个传递依赖
dependencies{
    cargo('org.codehaus.cargo:cargo-ant:1.3.1'){
        exclude(group:'xml-apis', module:'xml-apis')
    }
    cargo 'xml-apis:xml-apis:2.0.2'
}
  • 排除所有传递依赖
dependencies{
    cargo('org.codehaus.cargo:cargo-ant:1.3.1'){
        transitive = false
    }
}

Gradle还支持最新版本依赖,又叫动态版本依赖,当然正式环境下还是不要用这个功能了

文件依赖

适用于从现有Ant或者Maven管理方式转变到Gradle时,或者本地稳定的开发包依赖

dependencies{
    cargo fileTree(dir: "lib路径" ,include: ' *.jar ')
}

使用和配置仓库

  • 定义仓库的接口类 RepositoryHandler
  • 支持Maven仓库,Ivy仓库,扁平的目录仓库
Maven仓库
  • 中央仓库 mavenCentral()
  • 本地仓库 mavenLocal() 慎用
  • 自定义仓库 maven() 和mavenRepo()
dependencies{
    mavenCentral()
    maven{
        name  'Custom Maven Repository'
        url 'http://ziniuxiaozhu.com/nexus/public'
    }
}
Ivy仓库
  • 相对Maven来说可以自定义布局
  • 仓库依赖元数据存储在ivy.xml中

具体语法可参考官方文档

扁平目录仓库
  • 只有JAR文件,没有元数据
  • 适合经常手动维护项目中的类库,或者项目迁移的时候
  • 声明依赖智能使用name和version这两个属性

一个从falt目录仓库取Cargo依赖声明例子:


repositories{ flatDir(dir: " ${System.properties['user.home']}/libs/cargo", name: 'Local libs directory') } dependencies{ cargo name : 'activetion', version:'1.1' catgo name: 'ant', version:'1.7.1' cargo ':xml-apis:1.3.1', ' : jaxen:1.0-FCS' }

本地依赖缓存

  • Gradle会缓存从仓库下载的二进制文件,该目录根据不同的版本,路径可能不同
  • 存储依赖来源,当来源发生变化,能够保证构建的可靠
  • 减少到远程仓库的传输
  • 比较本地仓库和远程仓库,减少工件的下载
  • 支持离线模式,在你无法联网时采用本地缓存来构建

常见依赖问题

如果你项目有很多依赖,而且你选择自动解决传递性依赖,那么版本冲突几乎是不可避免的
- 应对版本冲突
设置当遇到版本冲突时,构建失败

 configuration.cargo.resolutionStrategy{
    failOnVersionConfilct()
}
  • 强制制定一个版本
 configuration.cargo.resolutionStrategy{
   force ' org.codehaus.cargo:cargo:cargo-ant:1.3.0'
}
  • 使用依赖观察报告
  • 刷新缓存

可以手动刷新,可以不缓存快照版本的依赖包

Gradle简明教程(3)

hzqiuxm阅读(489)评论(0)

快速牵手JAVA

  • Gradle将把你从传统的构建流程中解放出来,针对不同的语言它有着各种不同的插件,通过插件封装了基本流程

  • 如何使用JAVA插件?只要一行代码

apply plugin: 'java'

这就定义了一个java项目的全部,自动添加很多task
Gradle 会在 src/main/java 目录下寻找产品代码,在 src/test/java 寻找测试代码 。

另外在 src/main/resources 包含了资源的 JAR 文件, src/test/resources 包含了运行测试。
所有的输出都在 build 目录下,JAR 在 build/libs 目录下

  • 外部依赖
    和Maven一样,我们也可以使用maven repository
apply plugin: 'java'

repositories {
    mavenCentral()
}

dependencies {
        compile group: 'org.springframework', name: 'spring-core', version: '4.2.5.RELEASE'
        compile group: 'org.hibernate', name: 'hibernate-core', version: '3.6.7.Final'
        testCompile group: 'junit', name: 'junit', version: '4.+'
    }

Maven respository网站上已经提供了各种工具包的依赖,稍微改变下格式描述就可以了
(下面将会介绍到Groovy插件,它更强大是java插件的扩展)

获取依赖

执行 gradle build

bulid结果

  • 需要注意的是一个groovy项目也是一个java项目
apply plugin: 'groovy'

repositories {
    mavenCentral()
}

dependencies {
        compile 'org.codehaus.groovy:groovy-all:2.3.6'
        compile 'commons-logging:commons-logging:1.2'
        compile 'org.springframework:spring-core:4.2.5.RELEASE'
        testCompile 'junit:junit:4.11'
    }

比之前的java插件更强大哦, 而且依赖的描述也更简单了,从respository中直接copy就行了

快速开始Web应用

构建WAR文件
  • 使用war插件来构建war文件
apply plugin: 'war'

当运行 gradle build时就会编译、测试、打包工程一个war文件

  • 运行应用插件
apply plugin: 'jetty'

当你运行 gradle jettyRun 的时候,应用将会运行在一个内嵌的jetty web容器中

gradle的Task执行规则
  • 同个构建可以执行多个task,但每个task只能被执行一次,不管它是在哪个阶段被执行
    task compile << {
        println 'compiling source'
    }

    task compileTest(dependsOn: compile) << {
        println 'compiling unit tests'
    }

    task test(dependsOn: [compile, compileTest]) << {
        println 'running unit tests'
    }

    task dist(dependsOn: [compile, test]) << {
        println 'building the distribution'
    }

执行 gradle dist结果如下

任务执行规则

Gradle简明教程(2)

hzqiuxm阅读(596)评论(1)

下载与安装

  • 官方下载地址: https://gradle.org/gradle-download/
  • 安装就是配置环境变量,增加GRADLE_HOME环境变量,值为gradle-2.12\bin所在目录

    windows下直接在环境变量对话框中定义,类linux系统
    export GRADE_HOME = xxxx/xxxx
    export PATH=$PATH:$GRADLE_HOME/bin

  • 验证是否安装成功

check install
- 来一个gradle的hello world

新建一个文件 build.gradle

task helloWorld{

    task startSession << {
        println 'Welcome to gradle world!'
    }

    3.times {
        task "genGradle$it" << {
            println 'genGradle rocks'
        }
    }

    genGradle0.dependsOn startSession
    genGradle2.dependsOn genGradle1, genGradle0

    task groupGradles(dependsOn: genGradle2)

}
  • 执行:gradle -q groupGradles

run helloworld

程序简单说明

  • 这里的task和Ant的targets是对等的
  • << 符号是doLast的alias,doFirst 和 doLast 可以多次执行调用。他们在开始或结束的 task 动作清单中添加动作。task 执行时,按动作列表的顺序执行的动作。操作符 << 仅仅是 doLast 的别名。
  • -q是代表quiet模式,不生成构建编译过程的日志信息

其他技巧

  • 列出项目中所有的task
gradle -q tasks --all
  • 在执行时排除一个任务
gradle groupGradles -x genGradle0
  • 任务名字采用缩写
gradle groupHello 等价于  gradle gH
gradle groupGradle0 等价于 gradle gG0
  • 常用的命令行选项
-b 指定构建脚本名字,某人build.gradle
-i 执行时候输出详细日志信息
-q 减少构建出错时打印的日志信息
--help 打印出所有可用的命令行选项
  • 以后台守护进行方式运行gradle
gradle groupGradles --daemon

看看灵活的Groovy例子

  • 编写脚本build.gradle
task upper << {
    println '---- Begin in upper ----'
    String strSome = 'my_nAme'
    println 'Original: ' + strSome
    println 'Upper: ' + strSome.toUpperCase()
    println '---- End in upper ----'
}   

task hello(dependsOn: upper) << {
    println " I'm dependsOn upper"
}

执行下 gradle -q hello

执行结果

defaultTasks 'clean', 'run'

task upper << {
    println '---- Begin in upper ----'
    String strSome = 'my_nAme'
    println 'Original: ' + strSome
    println 'Upper: ' + strSome.toUpperCase()
    println '---- End in upper ----'
}   

task hello(dependsOn: upper) << {
    println " I'm dependsOn upper"
}

task clean << {
    println 'This is a default task clean '
}

task run << {
    println 'This is a default task run '
}

执行 gradle -q 结果
执行结果

  • DAG配置
task destribution <<{
    println "We build the zip with version = $version "
}

task release(dependsOn:'destribution') << {
    println 'We release now ......'
}

gradle.taskGraph.whenReady{
    taskGraph -> 
    if (taskGraph.hasTask(release)) {
        version = '1.0'
    }else{
        version = '1.0-SNAPSHOT'
    }
}

注意执行不同的TASK,输出结果是不一样的
执行结果

Gradle简明教程(1)

hzqiuxm阅读(529)评论(1)

构建工具剖析

四大组成部分
  • 构建文件

    使用脚本语言来表达构建逻辑 最常见的是xml、json格式

  • 构建输入输出

    输入是指构建任务需要的任务或数据,输出是指构建任务的产出结果

  • 构建引擎

    用来解析执行构建文件指令或规则的工具用来解析执行构建文件指令或规则的工具

  • 依赖管理器

    管理构建任务所要依赖的第三方或公共类库

蚂蚁式构建 Ant

发音: [ænt] 蚂蚁的意思

  • Apache Ant是一个用Java编写的开源构建工具
  • 构建文件使用XML来表示的,可以在任何环境下使用
  • 不提供依赖管理器,自行管理
  • 结合Ivy可以实现依赖管理器
  • Ant构建术语

    project、target、task

  • 没有对如何定义构建的结构强加任何限制,对源码、输出目录、target拥有完全灵活的选择

  • 缺点

XML本身较为臃肿与啰嗦
没有建设项目标准,build文件常常会随着项目开发而变得繁杂重复
无法量化被编译的类或执行的TASK
没有Ivy情况下,Ant很难管理依赖

专家构建 Maven

发音:['mevn] 内行,专家的意思(我接触的人中大部分都读错了)
- 使用约定优于配置的思想,规定了标准的目录布局
- 基于生命周期的思想,通过三套生命周期来管理构建过程
- 构建文件也是使用XML来表示的,可以在任何环境下使用
- 核心功能可以通过开发定制的插件来扩展,社区插件很丰富
- 脚本中可以定义外部依赖库,一般会搭建Nexus结合maven中心仓库来管理
- 缺点

默认的结构和生命周期可能会不适合你的项目
自己定制扩展比较复杂,需要了解Mojos(内部扩展API)

我们想要的构建
  • 具有表达式、声明式、可维护的构建语言
  • 标准化的项目布局和生命周期,但是具有完全的灵活性和对默认值的完全可配置性
  • 定制逻辑灵活易用
  • 支持构建多个项目组成的项目结构
  • 支持依赖管理
  • 可以很好的和Ant、Maven集成
  • 高效且有良好的扩展性

是的它就是Gradle,下一代的构建工具

AMQ简明教程(9)

hzqiuxm阅读(493)评论(0)

AMQ消息存储持久化

概述

ActiveMQ不仅支持persistent和non-persistent两种方式,还支持消息的恢复( recovery )方式。

PTP

Queue的存储是很简单的,就是一个FIFO的Queue

PUB/SUB

对于持久化订阅主题,每一个消费者将获得一个消息的复制。

ActiveMQ提供了一个插件式的消息存储,类似于消息的多点传播,主要实现了如下几种:
1:AMQ消息存储-基于文件的存储方式,是以前的默认消息存储
2:KahaDB消息存储-提供了容量的提升和恢复能力,是现在的默认存储方式
3:JDBC消息存储-消息基于JDBC存储的
4:Memory 消息存储-基于内存的消息存储

KahaDB Message Store概述

KahaDB是目前默认的存储方式,可用于任何场景,提高了性能和恢复能力。消息存储使用一个事务日志和仅仅用一个索引文件来存储它所有的地址。

KahaDB是一个专门针对消息持久化的解决方案,它对典型的消息使用模式进行了优化。

在Kaha中,数据被追加到data logs中。当不再需要log文件中的数据的时候,log文件会被丢弃。

KahaDB基本配置例子

<persistenceAdapter>
<kahaDB directory="${activemq.data}/kahadb"/>
</persistenceAdapter>

可用的属性有:
1:director:KahaDB存放的路径,默认值activemq-data
2:indexWriteBatchSize: 批量写入磁盘的索引page数量,默认值1000
3:indexCacheSize:内存中缓存索引page的数量,默认值10000
4:enableIndexWriteAsync:是否异步写出索引,默认false
5:journalMaxFileLength:设置每个消息data log的大小,默认是32MB
6:enableJournalDiskSyncs:设置是否保证每个没有事务的内容,被同步写入磁盘,JMS持久化的时候需要,默认为true
7:cleanupInterval:在检查到不再使用的消息后,在具体删除消息前的时间,默认30000
8:checkpointInterval:checkpoint的间隔时间,默认5000
9:ignoreMissingJournalfiles:是否忽略丢失的消息日志文件,默认false
10:checkForCorruptJournalFiles:在启动的时候,将会验证消息文件是否损坏,默认false
11:checksumJournalFiles:是否为每个消息日志文件提供checksum,默认false
12:archiveDataLogs: 是否移动文件到特定的路径,而不是删除它们,默认false
13:directoryArchive:定义消息已经被消费过后,移动data log到的路径,默认null
14:databaseLockedWaitDelay:获得数据库锁的等待时间(used by shared master/slave),默认10000
15:maxAsyncJobs:设置最大的可以存储的异步消息队列,默认值10000,可以和concurrentMessageProducers 设置成一样的值
16:concurrentStoreAndDispatchTransactions:是否分发消息到客户端,同时事务存储消息,默认true
17:concurrentStoreAndDispatchTopics:是否分发Topic消息到客户端,同时进行存储,默认true
18:concurrentStoreAndDispatchQueues:是否分发queue消息到客户端,同时进行存储,默认true

在Java中内嵌使用Broker,使用KahaDB的例子

public class EmbeddedBrokerUsingKahaDBStoreExample {
BrokerService createEmbeddedBroker() throws Exception {
BrokerService broker = new BrokerService();
File dataFileDir = new File("target/amq-in-action/kahadb");
KahaDBStore kaha = new KahaDBStore();
kaha.setDirectory(dataFileDir);
// Using a bigger journal file
kaha.setJournalMaxFileLength(1024*100);
// small batch means more frequent and smaller writes
kaha.setIndexWriteBatchSize(100);
// do the index write in a separate thread
kaha.setEnableIndexWriteAsync(true);
broker.setPersistenceAdapter(kaha);
//create a transport connector
broker.addConnector("tcp://localhost:61616");
//start the broker
broker.start();
return broker;
}
}

AMQ Message Store概述

AMQ Message Store是ActiveMQ5.0缺省的持久化存储,它是一个基于文件、事务存储设计为快速消息存储的一个结构,该结构是以流的形式来进行消息交互的。

这种方式中,Messages被保存到data logs中,同时被reference store进行索引以提高存取速度。

Date logs由一些单独的data log文件组成,缺省的文件大小是32M,如果某个消息的大小超过了data log文件的大小,那么可以修改配置以增加
data log文件的大小。如果某个data log文件中所有的消息都被成功消费了,那么这个data log文件将会被标记,以便在下一轮的清理中被删除或者归档。

AMQ Message Store配置示例:

<broker brokerName="broker" persistent="true" useShutdownHook="false">
<persistenceAdapter>
<amqPersistenceAdapter directory="${activemq.base}/data"
maxFileLength="32mb"/>
</persistenceAdapter>
</broker>

使用JDBC来持久化消息

ActiveMQ支持使用JDBC来持久化消息,预定义的表如下:
1:消息表,缺省表名为ACTIVEMQ_MSGS,queue和topic都存在里面,结构如下:

2:ACTIVEMQ_ACKS表存储持久订阅的信息和最后一个持久订阅接收的消息ID,结构如下:

3:锁定表,缺省表名为ACTIVEMQ_LOCK,用来确保在某一时刻,只能有一个
ActiveMQ broker实例来访问数据库,结构如下:

使用JDBC来持久化消息的配置示例:

<beans>
<broker brokerName="test-broker" persistent=true
xmlns="http://activemq.apache.org/schema/core">
<persistenceAdapter>
<jdbcPersistenceAdapter dataSource=“#mysql-ds"/>
</persistenceAdapter>
</broker>
<bean name="mysql-ds" class="org.apache.commons.dbcp.BasicDataSource" destroy-method="close">
<property name="driverClassName"><value>org.gjt.mm.mysql.Driver</value></property>
<property
name="url"><value>jdbc:mysql://192.168.1.100:3306/test?useUnicode=true&characterEncodi
ng=UTF-8</value></property>
<property name="username"> <value>root</value> </property>
<property name="password" value="cc"/>
</bean>

JDBC Message Store with ActiveMQ Journal

这种方式克服了JDBC Store的不足,使用快速的缓存写入技术,大大提高了性能。配置示例如下:
<beans>
<broker brokerName="test-broker" xmlns="http://activemq.apache.org/schema/core">
<persistenceFactory>
<journalPersistenceAdapterFactory
journalLogFiles="4"
journalLogFileSize="32768"
useJournal="true"
useQuickJournal="true"
dataSource="#derby-ds"
dataDirectory="activemq-data" />
</persistenceFactory>
</broker>
</beans>

JDBC Store和JDBC Message Store with ActiveMQ Journal的区别
1:Jdbc with journal的性能优于jdbc
2:Jdbc用于master/slave模式的数据库分享
3:Jdbc with journal不能用于master/slave模式
4:一般情况下,推荐使用jdbc with journal

Memory Message Store

内存消息存储主要是存储所有的持久化的消息在内存中。这里没有动态的缓存存在,所以
你必须注意设置你的broker所在的JVM和内存限制

Memory Message Store配置示例:

<beans>
<broker brokerName="test-broker" persistent="false"
xmlns="http://activemq.apache.org/schema/core">
<transportConnectors>
<transportConnector uri="tcp://localhost:61635"/>
</transportConnectors>
</broker>
</beans>

在Java中内嵌使用Broker,使用Memory的例子:

public void createEmbeddedBroker() throws Exception {
BrokerService broker = new BrokerService();
broker.setPersistent(false);
broker.addConnector("tcp://localhost:61616");
broker.start();
}

欢迎加入紫牛小筑

进入小筑关于作者