精华内容
下载资源
问答
  • MQ消息队列详解、四大MQ的优缺点分析

    万次阅读 多人点赞 2020-03-07 16:05:28
    MQ消息队列详解 近期有了想跳槽的打算,所以自己想巩固一下自己的技术,想了解一些面试比较容易加分的项,近期准备深入研究一下redis和mq这两样,这总体上...消息队列有什么优点和缺点 kafka、ActiveMQ、RabbitMQ、R...

    前言

    近期有了想跳槽的打算,所以自己想巩固一下自己的技术,想了解一些面试比较容易加分的项,近期准备深入研究一下Redis和MQ这两样,这总体上都是为了解决服务器并发的原因,刚翻到了一篇有关于MQ的,觉得写得特别好,特此记录一下,也算是为了加深自己的印象。

    面试题切入

    • 为什么要使用MQ
    • 消息队列有什么优点和缺点
    • kafka、ActiveMQ、RabbitMQ、RocketMQ有什么区别

    面试官心理分析

    • 首先,你们系统里面为什么要用MQ
      不少去面试的人,都知道自己以前项目里面用过MQ、Redis,但是为什么用这个,却不知道,这种人说白了就是为了用而用,又或者这个框架就是别人设计的,他自己都没了解过里面的东西,自然也不知道为什么要用。如果面试的时候面试官问你这种问题你答不上来,可能已经被pass百分之三十了,面试官通常对这种人印象很不好,他怕你进了公司只会埋头苦干,不懂得自己思考。
    • 第二,你既然用了MQ,那你知不知道MQ有什么好处和坏处
      如果没考虑过这个问题一定要慎重回答,因为你没考虑过这个,盲目的弄个MQ进系统,当下的问题可能是解决了,但万一后面出了问题不是给公司留坑吗,面试官就怕这样的人,招进来干了一年,自己跳槽了,给系统挖一堆坑,留下无穷祸患。
    • 第三,既然你用了MQ,比如其中一种MQ,那你当时做没做过调研
      别看别人用了MQ,咦,感觉挺好的,就自己瞎弄了一个,根本没考虑过MQ的选型,比如kafka,每个MQ并没有绝对的好处和坏处,现在业界流行的MQ各有各的好处,各有各的坏处,你要做的就是扬长避短,挑选最适合自己系统的MQ。

    面试题剖析

    ①为什么要使用MQ

    其实面试官问你这个问题就是想知道,你们公司有个什么样的业务场景,这个业务场景有个什么技术挑战,如果不用MQ可能会比较麻烦,包括现在用了MQ以后有哪些好处等等。先说一下MQ常见的使用场景吧,MQ的使用场景有很多,但是比较核心的就是:解耦、异步、削锋。

    系统解耦

    首先举例下面这个场景,现有ABCDE五个系统,最初的时候BCD三个系统都要调用A系统的接口获取数据,一切都很正常,但是突然,D系统说:我不要了,你不用给我传数据了,A系统无奈,只能修改代码,将调用D系统的代码删除,这时候还没删除呢,E系统发送了请求,但是A系统这时候还没处理完D系统的请求,A系统卒!!!彻底崩溃。看下图↓↓↓↓↓↓↓↓↓↓↓
    在这里插入图片描述

    • 上述场景中,BCDE都需要用到A系统提供的数据,A系统跟其他四个系统严重耦合,需要时时刻刻考虑其他四个系统要是挂了怎么办,需不需要重新发送数据给他们,这个时候的A系统内心是崩溃的。
    • 但是如果使用了MQ之后 ,A系统的数据只需要放到MQ里面,其他的系统想请求获取数据只需要去MQ里面消费即可,如果突然不想请求了,就取消对MQ的消费就行了,A系统根本不需要考虑给谁去响应这个数据,也不需要去维护代码,也不用考虑其他系统是否调用成功,失败超时等情况。详细看下图↓↓↓↓↓↓↓↓
      在这里插入图片描述
      总结:通过MQ发布订阅消息的模型,A系统就成功的跟其他系统解耦了。
      面试技巧:你需要思考一下,在你自己的系统里面有没有类似的情况,一个系统或者模块,调用了多个系统或者模块,它们互相之间的调用非常复杂,并且维护起来很麻烦,但其实这个调用是不需要直接同步调用接口的,如果用MQ给它异步化解耦也是可以的,你就需要思考在你的项目里,是不是可以用MQ给它进行系统的解耦,可以自己组织一下语言回答。

    异步调用

    场景二,还是ABCD四个系统,A系统收到一个请求,需要在自己本地写库,还需要往BCD三个系统写库,A系统自己写本地库需要3ms,往其他系统写库相对较慢,B系统200ms ,C系统350ms,D系统400ms,这样算起来,整个功能从请求到响应的时间为3ms+200ms+350ms+400ms=953ms,接近一秒,对于用户来说,点个按钮要等这么长时间,基本是无法接受的,侧面也反映出这家研发人员技术不咋地。详情如下图↓↓↓↓↓↓
    在这里插入图片描述
    一般的互联网企业,对于用户请求响应的时间要求在100ms-200ms之间,这样,用户的眼睛存在视觉暂停现象,用户响应时间在此范围内就可以了,所以上面的现象是不可取的。
    如果用了MQ,用户发送请求到A系统耗时3ms,A系统发送三条消息到MQ,假如耗时5ms,用户从发送请求到相应3ms+5ms=8ms,仅用了8ms,用户的体验非常好。
    在这里插入图片描述

    流量削峰

    场景三,这次举个实例吧,也是近期发生的,我们都知道 ,2020年爆发的这场新冠病毒,导致各大线上商城APP里面的口罩被抢购一空,在这种情况下,JD商城开启了一场每晚八点的抢购3Q口罩的活动,每天下午三点进行预约,晚上八点抢购,从JD商城刚上线这个活动,我连续抢了近一个周,也算是见证了一个百万并发量系统从出现问题到完善的一个过程,最初第一天,我抢购的时候,一百多万预约,到八点抢购估计也能有百万的并发量,可是第一天,到八点我抢的时候,由于并发量太高,直接把JD服务器弄崩了,直接报了异常,可能JD在上线这个活动的时候也没能够想到会有那么高的并发,打了一个猝不及防,但是这只是在前一两天出现报异常的情况,后面却没有再出现异常信息,到后来再抢购只是响应的时间变得很慢,但是JD系统并没有崩溃,这种情况下一般就是用了MQ(或者之前用了MQ,这次换了个吞吐量级别更高的MQ),也正是利用了MQ的三大好处之一——削峰。
    JD系统每天0—19点,系统风平浪静,结果一到八点抢购的时候,每秒并发达到百万,
    假设JD数据库没秒能处理1.5w条并发请求(并非实际数据,主要为了举例),到八点抢购的时候,每秒并发百万,这直接导致系统异常,但是八点一过,可能也就几万用户在线操作,每秒的请求可能也就几百条,对整个系统毫无压力。

    在这里插入图片描述
    如果使用了MQ,每秒百万个请求写入MQ,因为JD系统每秒能处理1W+的请求,JD系统处理完然后再去MQ里面,再拉取1W+的请求处理,每次不要超过自己能处理的最大请求量就ok,这样下来,等到八点高峰期的时候,系统也不会挂掉,但是近一个小时内,系统处理请求的速度是肯定赶不上用户的并发请求的,所以都会积压在MQ中,甚至可能积压千万条,但是高峰期过后,每秒只会有一千多的并发请求进入MQ,但是JD系统还是会以每秒1W+的速度处理请求,所以高峰期一过,JD系统会很快消化掉积压在MQ的请求,在用户那边可能也就是等的时间长一点,但是绝对不会让系统挂掉。
    在这里插入图片描述

    消息队列的优缺点

    • 优点
      上面已经说过了,系统解耦,异步调用,流量削峰。
    • 缺点
      系统可用性降低:系统引入的外部依赖越多,系统要面对的风险越高,拿场景一来说,本来ABCD四个系统配合的好好的,没啥问题,但是你偏要弄个MQ进来插一脚,虽然好处挺多,但是万一MQ挂掉了呢,那样你系统不也就挂掉了。
      系统复杂程度提高:非要加个MQ进来,如何保证没有重复消费呢?如何处理消息丢失的情况?怎么保证消息传递的顺序?问题太多。
      一致性的问题:A系统处理完再传递给MQ就直接返回成功了,用户以为你这个请求成功了,但是,如果在BCD的系统里,BC两个系统写库成功,D系统写库失败了怎么办,这样就导致数据不一致了。
      所以。消息队列其实是一套非常复杂的架构,你在享受MQ带来的好处的同时,也要做各种技术方案把MQ带来的一系列的问题解决掉,等一切都做好之后,系统的复杂程度硬生生提高了一个等级。

    四大主流MQ(kafka、ActiveMQ、RabbitMQ、RocketMQ)各自的优缺点

    目前业界四大主流的MQ有kafka、ActiveMQ、RabbitMQ、RocketMQ。其他的MQ也有,不过比较冷门。就不用多说了,画个表就明白了。↓↓↓↓↓↓↓↓

    特性 ActiveMQ RabbitMQ RocketMQ kafka
    单机吞吐量 万级,吞吐量比RocketMQ和Kafka要低了一个数量级 万级,吞吐量比RocketMQ和Kafka要低了一个数量级 10万级,RocketMQ也是可以支撑高吞吐的一种MQ 10万级别,这是kafka最大的优点,就是吞吐量高。一般配合大数据类的系统来进行实时数据计算、日志采集等场景
    topic数量对吞吐量的影响 topic可以达到几百,几千个的级别,吞吐量会有较小幅度的下降这是RocketMQ的一大优势,在同等机器下,可以支撑大量的topic topic从几十个到几百个的时候,吞吐量会大幅度下降所以在同等机器下,kafka尽量保证topic数量不要过多。如果要支撑大规模topic,需要增加更多的机器资源
    时效性 ms级 微秒级,这是rabbitmq的一大特点,延迟是最低的 ms级 延迟在ms级以内
    可用性 高,基于主从架构实现高可用性 高,基于主从架构实现高可用性 非常高,分布式架构 非常高,kafka是分布式的,一个数据多个副本,少数机器宕机,不会丢失数据,不会导致不可用
    消息可靠性 有较低的概率丢失数据 经过参数优化配置,可以做到0丢失 经过参数优化配置,消息可以做到0丢失
    功能支持 MQ领域的功能极其完备 基于erlang开发,所以并发能力很强,性能极其好,延时很低 MQ功能较为完善,还是分布式的,扩展性好 功能较为简单,主要支持简单的MQ功能,在大数据领域的实时计算以及日志采集被大规模使用,是事实上的标准
    优劣势总结 非常成熟,功能强大,在业内大量的公司以及项目中都有应用偶尔会有较低概率丢失消息而且现在社区以及国内应用都越来越少,官方社区现在对ActiveMQ 5.x维护越来越少几个月才发布一个版本而且确实主要是基于解耦和异步来用的,较少在大规模吞吐的场景中使用 erlang语言开发,性能极其好,延时很低;吞吐量到万级,MQ功能比较完备而且开源提供的管理界面非常棒,用起来很好用社区相对比较活跃,几乎每个月都发布几个版本分在国内一些互联网公司近几年用rabbitmq也比较多一些但是问题也是显而易见的,RabbitMQ确实吞吐量会低一些,这是因为他做的实现机制比较重。而且erlang开发,国内有几个公司有实力做erlang源码级别的研究和定制?如果说你没这个实力的话,确实偶尔会有一些问题,你很难去看懂源码,你公司对这个东西的掌控很弱,基本职能依赖于开源社区的快速维护和修复bug。而且rabbitmq集群动态扩展会很麻烦,不过这个我觉得还好。其实主要是erlang语言本身带来的问题。很难读源码,很难定制和掌控。 接口简单易用,而且毕竟在阿里大规模应用过,有阿里品牌保障日处理消息上百亿之多,可以做到大规模吞吐,性能也非常好,分布式扩展也很方便,社区维护还可以,可靠性和可用性都是ok的,还可以支撑大规模的topic数量,支持复杂MQ业务场景而且一个很大的优势在于,阿里出品都是java系的,我们可以自己阅读源码,定制自己公司的MQ,可以掌控社区活跃度相对较为一般,不过也还可以,文档相对来说简单一些,然后接口这块不是按照标准JMS规范走的有些系统要迁移需要修改大量代码还有就是阿里出台的技术,你得做好这个技术万一被抛弃,社区黄掉的风险,那如果你们公司有技术实力我觉得用RocketMQ挺好的 kafka的特点其实很明显,就是仅仅提供较少的核心功能,但是提供超高的吞吐量,ms级的延迟,极高的可用性以及可靠性,而且分布式可以任意扩展同时kafka最好是支撑较少的topic数量即可,保证其超高吞吐量而且kafka唯一的一点劣势是有可能消息重复消费,那么对数据准确性会造成极其轻微的影响,在大数据领域中以及日志采集中,这点轻微影响可以忽略这个特性天然适合大数据实时计算以及日志收集

    综上所述,各种对比之后,我个人倾向于是:

    一般的业务系统要引入MQ,最早大家都用ActiveMQ,但是现在确实大家用的不多了,没经过大规模吞吐量场景的验证,社区也不是很活跃,所以大家还是算了吧,我个人不推荐用这个了;

    后来大家开始用RabbitMQ,但是确实erlang语言阻止了大量的java工程师去深入研究和掌控他,对公司而言,几乎处于不可控的状态,但是确实人是开源的,比较稳定的支持,活跃度也高;

    不过现在确实越来越多的公司,会去用RocketMQ,确实很不错,但是我提醒一下自己想好社区万一突然黄掉的风险,对自己公司技术实力有绝对自信的,我推荐用RocketMQ,否则回去老老实实用RabbitMQ吧,人是活跃开源社区,绝对不会黄

    所以中小型公司,技术实力较为一般,技术挑战不是特别高,用RabbitMQ是不错的选择;大型公司,基础架构研发实力较强,用RocketMQ是很好的选择

    如果是大数据领域的实时计算、日志采集等场景,用Kafka是业内标准的,绝对没问题,社区活跃度很高,绝对不会黄,何况几乎是全世界这个领域的事实性规范
    ok,消息队列写到这里就结束了!!!!!

    展开全文
  • 双活数据中心架构分析优缺点

    万次阅读 2016-09-13 13:18:48
    传统主备模式的缺点 出于灾备(Disaster Recovery)的目的,一般都会建设2个(或多个)数据中心。一个是主数据中心用于承担用户的业务,一个是备份数据中心用于备份主数据中心的数据、配置、业务等。 主备数据中心...

    什么是双活数据中心 ?

    首先我们要知道双活就是Active-Active,故名思义就是两边都是活动在线提供服务的,是相对于传统的主备模式Active-Standby模式的。一个真正的双活方案是应该涵盖基础设施、中间件、应用程序各个层次的。

    双数据中心同时对外提供业务生产服务的双活模式,两个数据中心是对等的、不分主从、并可同时部署业务,可极大的提高资源的利用率和系统的工作效率、性能,让客户从容灾系统的**中获得最大的价值。

    • a.两个生产中心部署相同的业务系统,结合网络层、主机层或应用的负载均衡技术,实现业务系统在两个数据中心并行工作和负载分担。
    • b.两个生产中心部署不同的业务系统,互相实时灾备接管。

    数据中心双活又分为:同城双活、异地双活。

    双活数据中心架构分析及优缺点

    传统主备模式的缺点

    出于灾备(Disaster Recovery)的目的,一般都会建设2个(或多个)数据中心。一个是主数据中心用于承担用户的业务,一个是备份数据中心用于备份主数据中心的数据、配置、业务等。

    主备数据中心之间一般有热备、冷备、双活三种备份方式。

    热备的情况下,只有主数据中心承担用户的业务,此时备数据中心对主数据中心进行实时的备份,当主数据中心挂掉以后,备数据中心可以自动接管主数据中心的业务,用户的业务不会中断,所以也感觉不到数据中心的切换。

    冷备的情况下,也是只有主数据中心承担业务,但是备用数据中心不会对主数据中心进行实时备份,这时可能是周期性的进行备份或者干脆不进行备份,如果主数据中心挂掉了,用户的业务就会中断。

    双活是觉得备用数据中心只做备份太浪费了,所以让主备两个数据中心都同时承担用户的业务,此时,主备两个数据中心互为备份,并且进行实时备份。一般来说,主数据中心的负载可能会多一些,比如分担60~70%的业务,备数据中心只分担40%~30%的业务。

    传统主备模式是一个业务只在一个数据中心运行,企业结合灾备等级需求和业务需求,在备份中心部署了大量的备份服务器,但备份中心仅为该业务提供灾备服务,只有当灾难发生、生产数据中心瘫痪时,灾备中心的业务系统才启动这些服务器,造成备份中心服务器资源浪费,广域网链路也无法得到充分的利用。

    双活数据中心优点

    • 充分利用资源,避免了一个数据中心常年处于闲置状态而造成浪费。通过资源整合,“双活”数据中心的服务能力是双倍的。
    • 双活数据中心如果断了一个数据中心,另外一个数据中心还在运行,对用户来说是不可感知的。

    而一个灾备中心的模式,如果生产数据中心瘫痪,需要半个小时、甚至两个小时、甚至更长时间才能启动灾备中心,在启动灾备中心的时间里,用户交易会严重受损。

    双活数据中心的最大优势是有效利用资源。灾备中心建设的投资巨大及每年运维成本极高,如果资源处于闲置状态,资源是相当浪费的,有了虚拟化,能够把闲置的资源整合,服务能力会提高一倍。银行系统中很多资源都是弹性需求,如基金、贵金属交易、电子支付、和网银交易,在交易火爆时一天交易量可能达到全年交易量总和。故银行系统容量规划时是充分考虑到交易峰值的,但这样在正常时间就有很大的交易浪费,以淘宝“双十一”活动为例,交易量在几分钟内就可能达到全年交易量的总和,需要系统服务能力提高十倍,这时双活数据中心和灵活快速的资源调度就充分发挥出了作用。云计算技术,让IT系统有了资源整合的能力,让系统有了充分的弹性,随时可以调度十台机器来提高服务能力,来保证交易的突发需求,以及各种突发因素造成的交易量猛增。

    有了云计算技术,不代表投入会更少,但是资源利用率会更高,系统但抗冲击能力会更强,自由调度能力会更强。

    自动化是“双活”与“云计算”必不可少的前提条件

    云计算需要自动化手段来帮助系统维护人员进行自动的资源调配。比如,通过虚拟化技术虚拟出了上万台虚拟机器,白天需要50台机器给网银系统提供web服务,晚上网银交易少了,贵金属交易多了,这50台机器要调配到另一个系统上。这五十台不可能一个人一台台调配,那可能配一晚上都配不完,就需要自动化的软件来自动调整资源分配。

    双活数据中心架构分析及优缺点

     

    异地“双活”难度大

    当然,部署“双活”数据中心的难度也非常大,尤其是异地“双活”,涉及到数据同步效率问题。如果数据同步效率达不到要求,在灾难发生时就会造成一段时间的交易丢失。在异地“双活”的模式中,两地数据中心同时接纳交易,技术难度很大,需要更改众多底层程序。

    双活数据中心的建设三个条件

    双活数据中心的建设首先要满足三个条件,第一个是应用双活,也就是说数据库一定要实现双活,第二个是网络要双活,业务网络要保证能够同时联通两个数据中心,第三个是数据要双活,两边的数据要能够实现被独立使用。

    双活数据中心解决方案缺点

    虽然双活容灾解决方案对于集中式管理的数据中心更大限度的保证了业务生产的在线性及有效的防御了灾难性事件恢复业务生产的能力。但是双活数据中心的容灾方案还是存在一定的不足之处,理想与现实总存在一定的距离。

    1.脑裂现象

    双活数据中心方案实现了站点级的冗余的容灾解决方案,但是受限于当前的技术等因素,在建设过程中解决了企业当前面临的业务连续性问题,同时也产生了新的问题,就是双活解决方案普遍存在的脑裂现象,在意外事件发生时,若监测技术不到位、系统平台不健康、两数据中网络波动性中断等因素的发生,使得两个数据中心一体化的业务系统会分裂成两个独立的数据中心。使用户很难取舍那一个是唯一的生产数据,那一个是将要废掉的非生产数据。这就是早年veritas VVR解决方案退出灾备舞台的原因之一。

    2.非“零丢失”,不具备软错误的保障

    双活容灾解决方案的优势强调在健康的运行平台下,大型灾难事件发生是的“零”数据丢失,但是若双活平台本身不健康或者遭遇逻辑故障时,并不能保障数据零丢失。这种故障发生的数据恢复或渐变式灾难发生的情况下,还需借助备份系统的数据恢复手段或方法。因此,双活容灾方案大多数情况下不具备解决软错误的保障,而恰恰这种事件发生的概率远远超过站点级的灾难及硬件故障事件。在2012年时,某省政府部门的业务系统已建设容灾系统,但是在业务系统进行升级时出错,导致业务宕机一周多时间,而这期间的大部分时间是查找依据恢复数据。

    3.需容忍高可靠性及性能的下降

    双活容灾解决方案虽然提升了站点级的冗余保护,但是,在实际中确除低了整体业务平台的可靠性及性能。在可靠性方案,双活容灾解决方案就是把本地的双机双柜的硬件冗余方案跨站点建设,无论是传统的集群系统、虚拟化主机平台Vmware,还是Oracle RAC等,跨站点建设都会无形中在业务平台中增添几分不稳定的因素,我想从现在流行的一体机解决方案更能说明这方面的问题,即系统越简单越稳定。在性能方案,站点间的监测、业务会话的同步确认等的网络延迟数,加上数据同步双写的光纤延迟,都或多或少的影响了整体业务处理的性能。距离越远影响越明显,如果距离较近,也会失去建设双活容灾数据中心的意义。

    4.运营维护并不简单

    双活容灾解决方案灾难切换方面变的较为简单,但在实际的维护方面并不简单,除了要求企业用户提升自己的维护能力,还需双活容灾解决方案提供商的售后服务能力。

    a.企业自身人员的维护能力必须加强,才具备能力维护跨站点的双活系统,也就是需企业用户自身人维护人员必须从维护设备的能力转变为具备维护双活系统架构的能力,才能维稳系统的正常运行,让双活系统实现该有的效果。

    b.提供商的服务能力也直接影响双活容灾系统部署后的效果,在已有的案例中,我们经常看到提供商的800电话,除了收集日志还是收集日志,除了正在后台诊断还是后台诊断,经常让一个小小问题需有好多层、次的沟通才能解决,这样的方式如何保障双活容灾系统的稳定?如保达到用户对双活系统在线性要求的期望?

    5.性价比并不会太高

    我们经常会听到双活容灾方案可以让生产中心和容灾中心都“活”起来,有效的利用资源,面临灾难性事件时,最大化业务系统的在线性,解除原有灾备系统有灾无备等等的不足之处。但是,当我们认真考虑建设双活容灾系统时发现,如果自身IT人员的维护能力不足,很难达到我们期望的效果。在现实案例中,很多用户一次性的费用建设的系统,后续的维保经费很难申请,这种情况很难有效的保障我们的信息系统的健康运行。宁夏银行就是在没有后续维保经费支撑的情况下,硬件出故障,自身IT人员修复过程中出现人为错误而引起的重大事故。因此,建设双活容灾系统的同时,必须要保障后续的维护经费。使得双活容灾系统向高大上偏移。

    更多双活数据中心相关内容:

    双活容灾系统建设 有利有弊客观看

    分布式双活数据中心部署模式

    为什么采用两地三中心GDPS 双活解决方案

    使用 Q 复制实现 DB2 数据库系统的高可用性和双活

    民生银行采用IBM GDPC做同城异地双活灾备

    思科两地三中心双活解决方案详解及下载

    展开全文
  • 从不同的角度分析Flex的优缺点

    千次阅读 2014-07-20 14:29:40
    从不同的角度分析Flex的优缺点

    从不同的角度分析Flex的优缺点


    技术角度:

    (1)具备了RIA时代富客户端的优点(C/S+B/S)

    (2)支持多种服务器语言(JAVA、.NET、PHP)及主流框架(Spring、Hibernate)

    (3)与Java结合后相当强大,能充分利用Java的资源背景

    (4)拥有丰富的组件和第三方组件,对企业级的数据汇总和业务流程展现力较强悍

    (5)借助开源的力量,拥有众多民间组织和牛人支持

    (6)Adobe公司(还有MM多年积累)的强大背景

    (7)源于Flash的天生丽质,轻松使用多媒体资源,动态交互性强

    (8)借助FlashPlayer的安装普及度,轻松实现跨浏览器跨平台

    (9)良好的架构设计和制作精良的文档示例(明年FLEX4同步推出中文版)

    (10)借助于插件丰富的Eclipse开发平台并拥有独立的IDE

    (11)框架设计重用性高,有利于模块化设计

    (12)近几年发展态势良好,获得了广泛认可,产品和技术也越发成熟

     

    开发者角度:

    (1)开源,透明

    (2)基于Eclipse开发平台,易上手,且插件丰富

    (3)基于Eclipse平台,开发调试方便(FB4中的条件断点)

    (4)ActionScript语言与Java的融合度和相似度较高,易学易用

    (5)MXML标签与XML相似,逻辑清晰可读性强

    (6)架构设计良好,耦合度低,有利于组件重用

    (7)无需针对不同浏览器编写代码,摆脱编写和调试的噩梦(针对JS说的)

    (8)类似VB的可视化拖拽组件,快速创建界面

    (9)方便定制及使用第三方的皮肤和样式,无需美工也有好效果

    (10)支持多媒体资源,轻易开发动态交互性强的界面

    (11)众多的RPC组件保障对后台数据访问的安全性和效率

    (12)文档示例丰富,通过网络可以获取大量的学习资源

    (13)近两年发展态势良好,前景光明

     

    企业角度:

    (1)开源,免费

    (2)具备了RIA时代富客户端的优点(C/S+B/S)

    (3)项目和组件的重用性高,易于资源积累和快速构建

    (4)Flex提供了与其他语言的结合,能广泛利用已有的资源

    (5)界面华丽,客户认可度高

    (6)学习曲线一般,培训成本低

     

    用户角度:

    (1)部署和更新方便

    (2)界面漂亮,交互性强

    (3)安全

     

    缺点:

    (1)不擅长处理复杂的业务流程,主要还是适合展现(Flex不是万能的)

    (2)继承了Flash的诸多优点,却唯独丢掉了Flash的小巧轻盈(减肥是永恒的话题)

    (3)目前尚没有比较好的减肥策略,带宽较好时这不是问题(不是一般的卡。。。)

    (4)对服务器和客户端的硬件设备都有一定要求(CPU和内存占用很生猛。。。)

    (5)运行期内存泄露状况严重,尽管可以通过一定手段改善(这个很崩溃)

    (6)对一些较专业的领域涉及较少,需要第三方组件支持(比如地质方面的)

    (7)Adobe公司对中国分部的支持不够(感觉宣讲和文档都做得不够)

    (8)搜索引擎对swf文件的支持不够(Adobe一直在努力)

    (9)与以往浏览习惯不同,比如右键被屏蔽,图片无法保存(可以改善)

     

    鉴于Flex生成的swf文件太肥是其主要缺点(加载慢,运行慢,内存占用多),我就主要从减肥和优化的角度来说一下使用心得。

    使用心得:

    (1)Flex只是前台展现,需要搭配强大的后台(注意前后台的均衡和优化)

    (2)考虑异步加载(比如分步加载外部资源)

    (3)界面推荐使用相对布局,合理组合,避免多余嵌套

    (4)界面加载图片推荐使用外部加载方式,尽可能多使用矢量图形

    (5)规范CSS样式表,尤其注意使用的外部字体大小

    (6)使用额外的皮肤和特效时需要综合考虑生成的文件大小和执行效率

    (7)适当地考虑延时加载策略,主界面只显示必要的内容

    (8)规范编码,提高执行效率,避免内存泄露

    (9)使用RSL和Module和其他有效方式努力减肥

    (10)尽可能重写一些继承底层类的组件,执行效率更好

    (11)慎重使用重量级组件(比如DataGrid,AdvancedDataGrid)


    本文出处:http://smartblack.iteye.com/blog/556202

    展开全文
  • Mock测试-优缺点分析

    万次阅读 2018-06-04 10:57:20
    3、Mock的优缺点分析 4、具体如何使用mock 1、什么是Mock ? 用一句通俗的语言来说: mock测试就是在测试过程中,对于某些不容易构造或者不容易获取的对象,用一个虚拟的对象来创建以便测试的测试方法。  Mock ...

    目录

    1、什么是Mock ?

    2、为什么要做Mock ? 

    3、Mock的优缺点分析

    4、具体如何使用mock


    1、什么是Mock ?

    用一句通俗的语言来说: mock测试就是在测试过程中,对于某些不容易构造或者不容易获取的对象,用一个虚拟的对象来创建以便测试的测试方法。 

    Mock 方法是单元测试中常见的一种技术,它的主要作用是模拟一些在应用中不容易构造或者比较复杂的对象,从而把测试与测试边界以外的对象隔离开。mock 对象有助于从测试中消除依赖项,使测试更单元化。

    2、为什么要做Mock ? 

    现在我们大互联网时代分布式服务应用广泛,日常服务的粒度细,业务复杂。

    任何一个业务线,或者在业务上提供一个完整功能的系统都有非常多的,独立部署的接口和服务,如何保证研发、测试时自己依赖的服务随时都是可用,特别是测试环境,是一个很难,很心酸的问题,尤其是在系统体量很大的公司,这个问题的难度就被无限放大。

     

    Mock 技术在很大程度上解决了我们日常测试中碰到的如下问题:

    2.1 对象信息难构建(比如HttpservletRequet、JDBC对象等)

    mock对象就是真实对象在调试期间的代替品。

    在测试时使用Mock,可以自由方便的构建配置接口对象的信息参数;

    在测试过程中,需要第三方接口返回特定的数据以符合特定的测试场景,这种情况往往需要跨条线的沟通协调测试数据,成本高,效率低;利用Mock可以自定义返回测试结果,支持手动构造依赖接口的返回值。

    2.2 依赖的接口尚未开发完成

    在系统交互双方定义好接口之后,我们可以提前进行开发和测试,并不依赖上游系统的开发实现,

    2.3 异常场景(连接异常、超时异常等)

    我们拿测试环境不稳定来说,大体量级别的公司,系统错综复杂,依赖性极强,更不用说测试环境了,使用Mock技术,相当于在开发、测试过程中降级了对外部服务接口的依赖,可以不受限制的提前进行我们的工作;

    2.4 自动化测试

    在自动化测试概念和发展要求下,自动化测试的规模也逐渐增大到一定程度;

    大型业务系统下测试接口多,测试用例也日益增多,依赖环境的稳定就成为了自动化测试执行的关键所在;

    自动化测试过程中,经常会因为依赖的第三方环境不稳定,导致测试执行失败,长期以往的出现问题,导致测试人员对自动化的稳定运行失去维护的信心;

    利用Mock技术,在测试过程中,只关注被测业务逻辑,mock掉依赖不相关的系统,这种情况下自动化测试运行失败,就一定是被测系统本身的业务逻辑问题,而不是第三方系统、数据的问题;

    在自动化测试框架的设计也可以考虑以下逻辑: 依赖接口好用的情况下就调用依赖接口,依赖接口不能提供服务,自动切换至Mock状态。

    2.5 更多场景…..

    其他一些场景~

     

    3、Mock的优缺点分析

    3.1 Mock的好处

    一、由于其他系统模块出错引起本模块的测试错误,我们可以采用mock隔离,避免干预

    二、开发过程中,只要交互双方定义好接口,团队之间可以并行工作,进程互不影响

    三、依赖系统无法响应,或者响应异常时,可以用mock Object代替,快速反应,不会影响测试进度;

    四、提前接入测试,提供测试效率,当接口定义好后,测试人员就可以创建Mock,把接口添加到自动化测试环境,提前开始测试,起到测试驱动开发效果;

    五、可以有效的增加覆盖,接口涉及入参,或者业务逻辑复杂的情况,某些场景无法通过正常手段进行操作,可以通过mock虚拟模拟;

     

    3.2 使用Mock 可能存在的风险

    Mock也不是silver bullet,所以根据项目实际情况和具体需要来确定是否选用Mock

    测试过程中如果大量使用Mock,mock测试的场景失去了真是性,可能会导致在后续的系统性测试时才发现bug,使得缺陷发现的较晚,可能会造成后续修复成本更大;

     

    4、具体如何使用mock

    4.1 手动构造mock对象

    可以自己写某个接口方法的实现,根据需要编写返回值,测试代码中使用该实现类对象;
    缺点:会增加代码量,在写mock对象代码时,有可能引入错误;

    4.2 开源项目构造mock方法

    有许多开源项目对动态构建 Mock 对象提供了支持,这些项目能够根据现有的接口或类动态生成;      
    优点:这样不仅能避免额外的编码工作,同时也降低了引入错误的可能;

     

    写在最后:

    使用Mock有如下建议

    1、多团队进度不一致

    2、复杂依赖环境不稳定

    3、项目工期紧张情况下

    注意事项:

    使用mock测试,后续一定要进行系统联通,或系统性测试,mock也不是神器;

    推荐工具:

    Java语言的:主要的Mock测试工具有JMock,MockCreator,Mockrunner,EasyMock,MockMaker等;

    微软的.Net语言:主要有Nmock,.NetMock;

     

    展开全文
  • Beanstalkd架构设计优缺点分析

    千次阅读 2018-09-02 14:16:01
    本文从系统设计角度分析beanstalkd的优缺点,对beanstalkd的设计进行总结。 优点的总结 beanstalkd是基于内存的任务队列,性能较高。每个job有多种状态,状态之间可以相互转换。这些状态为job的使用者提供了...
  • 单体应用优缺点分析

    2020-07-06 21:59:39
    如题,我们先来分析单体应用的优缺点,后续文章会陆续介绍微服务和SOA架构等。 单体应用时代: 大家可以回想下以前做单体应用时涉及的项目情况,包含:用户群体、用户规模、项目阶段、团队人数、团队分组情况、项目...
  • SpringBoot优缺点分析

    千次阅读 2020-02-13 14:46:59
    Spring的优点分析 Spring是Java企业版(Java Enterprise Edition,JEE,也称J2EE)的轻量级代替品。无需开发重量级的Enterprise JavaBean(EJB),Spring为企业级Java开发提供了一种相对简单的方法,通过依赖注入和...
  • Docker价值分析优缺点和谁在使用?) 摘要: Docker,一个新的容器技术,它能够在相同的旧服务器上运行的更多的应用程序,这也使得它很容易打包和发布程序。 它可以得到相同的硬件上比其他技术运行更多的应用(小...
  • css的三种样式分析优缺点

    千次阅读 2019-06-08 17:12:44
    css的写法: 行内样式:—直接将样式属性写在开始标签style属性中 <div style="属性名称:属性值;... 缺点:1.结构样式没有分离 不利于后期维护 2.样式不能重复使用(推荐不使用) </div> 内嵌样式–在...
  • 分析各种分布式事物优缺点

    千次阅读 2018-07-26 17:20:14
    使用JTA处理分布式事务 Spring Boot通过Atomkos或Bitronix的内嵌事务管理器支持跨多个XA资源的分布式JTA事务,当部署到恰当的J2EE应用服务器时也会支持JTA事务。 当发现JTA环境时,Spring Boot将使用Spring的 ...
  • 文献管理软件Mendeley优缺点分析

    万次阅读 多人点赞 2016-10-14 21:08:42
    从阅读Mendeley手册,到实际使用文献导入、文献组织和参考文献整理,已达半年之久,可以说是重度用户。总体而言,Mendeley像是一个初看惊艳但脾气也大的...根据实际使用体验,我大致总结了一下Mendeley的优点和缺点
  • LR逻辑斯回归分析优缺点

    万次阅读 2018-02-25 20:58:03
    本文是在学习完李航老师的《统计学习方法》后,在网上又学习了几篇关于LR... 在分析LR原理之前,先分析一下线性回归。线性回归能将输入数据通过对各个维度的特征分配不同的权重来进行表征,使得所有特征协同作出最...
  • 微信优缺点分析

    万次阅读 2016-08-16 11:22:07
    缺点: 1.删除聊天记录后无法找回  一次偶然的机会在最近联系人中删除了与朋友的聊天记录,找了半天也没发现找回聊天记录的入口,当时是否不解,感觉这是一个 十分严重的bug,为什么换一台手机所有聊天记录都没了,...
  • 多线程开发优缺点及应用场景分析

    千次阅读 2019-03-10 11:07:02
    多线程技术是一把双刃剑,在使用时需要充分考虑它的优缺点。 多线程应用场景: 是否需要创建多个线程取决于各种因素。在以下情况下,最适合采用多线程处理: (1)耗时或大量占用处理器的任务阻塞用户界面操作; (2)...
  • 聚类算法优缺点分析

    2020-12-11 10:03:46
    分析 算法 定义 优点 缺点 Kmeans 简单、高效、快速收敛、当簇接近高斯分布式,聚类效果好 必须定义平均值,K事先给定,K的值影响聚类效果,对异常值影响大 DBSCAN 可以对任意形状进行聚类,对异常值不敏感 对簇密度...
  • 网络拓扑结构的优缺点分析

    万次阅读 2019-01-16 20:40:50
    缺点:由于结点也多个结点连接,故结点的路由选择由选择和流量控制难度大,管理软件复杂,硬件成本高。   拓展:广域网与局域网所使用的网络拓扑结构有所不同。 广域网 多采用分布式或树型结构, 局域网 ...
  • 云服务器优缺点分析

    千次阅读 2019-03-11 17:05:06
    云服务器缺点:有些客户担心云服务器的安全问题,这是因为他们缺乏对云服务器的控制。用所周知云服务器只是提供借口,所有的客户的数据都会暴露在云服务器公司的面前,相当于没有隐私可言。而有些数据对客户而言非常...
  • spark mllib的优缺点分析

    千次阅读 2016-06-25 19:56:00
    spark机器学习的有点和缺点
  • 最近开始接触Linux运维,安装了Nagios,zabbix和ganglia三种监控工具并使用了一周后总结出一些优缺点,这里贴出来以供参考 Nagios是一款开源的企业级监控系统,能够实现对系统CPU、磁盘、网络等方面参数的基本系统...
  • 逻辑回归优缺点简单分析

    万次阅读 2018-03-03 21:27:19
    优点:1)预测结果是界于0和1之间的概率;...​需要利用因子分析或者变量聚类分析等手段来选择代表性的自变量,以减少候选变量之间的相关性;2)预测结果呈“S”型,因此从log(odds)向概率转化的过程是非线性的,...
  • 前端埋点方法解析及优缺点分析

    千次阅读 2019-05-30 06:31:40
    1.文档说明本文档是对前端埋点方案的梳理,整个文档会对现在主流方向的前端埋点方案进行分析整理。意在帮助产品经理和开发人员了解用户现实使用需求,为...2.1代码埋点优缺点分析代码埋点就是开发人员在指定的位置通...
  • 1.synchronized 加同步格式: synchronized(需要一个任意的对象(锁)){  代码块中放操作共享数据的代码。 } ...synchromized缺陷 ...synchronized是java中的一个关键字,也就是说是java语言的内置的特性。...
  • 缺点:每次输出均与过去的状态有关,计算时要对e(k)进行累加,计算机运算工作量大。 (2)数字PID增量型控制算法: 执行机构需要的是控制量的增量(例如驱动步进电机)时,数字控制器的输出只是控制量的增量,该...
  • 轮询和长轮询优缺点分析 轮询:客户端定时向服务器发送Ajax请求,服务器接到请求后马上返回响应信息并关闭连接。 优点:后端程序编写比较容易。 缺点:请求中有大半是无用,浪费带宽和服务器资源。 实例:适于...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 164,797
精华内容 65,918
关键字:

如何分析产品的优缺点