• 关于

    系统响应时间是啥

    的搜索结果

回答

这个问题虽然只有两个2个动作:输入URL和呈现页面,但这背后发生了很多"有趣"的事情,这个过程也涉及到很多方面的技术,包括像浏览器、DNS、http、html、服务器等。如果让我来回答,它大致的过程应该是这样的:DNS解析-->建立连接,发送数据包 -->服务器响应请求,返回给浏览器-->浏览器渲染程序页面。 1.DNS解析 当我搜索这个问题的时候,首先在浏览器输入了一个URL地址,但URL中服务器地址是一个域名而不是一个指定的IP地址,路由器并不知道你想要查找的地址,那么DNS域名解析系统会将该域名解析成ip,而IP地址是唯一的, 每一个ip地址对应网络上的一台计算机 2.建立网络连接,发送数据包 由于1的努力,已经能够根据ip和端口号与网络上对应的服务器建立连接,浏览器这边会向服务器发送一个数据包,里面包含了大量的信息,但这个数据包有一定的格式。就像我给你邮个快递,也得遵循邮递公司的一些规则吧!我得写上我的身份信息、寄的物品、标明邮递地址....道理是一样的,到了网络中这些规则就是“Http协议(网络协议)”。 3.服务器响应请求,返回给浏览器 服务器会分解你的数据包,例如你查找的是一个文档,那么服务器可能会返回一个doc文档或者zip压缩资源给你;如果你访问的是一个链接页面,那么服务器相应的返回一个包含HTML/CSS标记文档,这些请求和响应都有一个通用的写法,这些规则也就是前面提到的"http协议"。客户端向服务器请求资源时,除了告诉服务器要请求的资源,同时还会附带一些其他的信息,这部分信息放在"header"部分(服务器响应请求也一样!),主要有请求头(略)和响应头, http响应头详解: Request URL:https://static.zhihu.com/static/revved/-/css/m.652b53b3.css Request Method:GET Status Code:200 OK (from cache) Remote Address:123.125.110.16:443 Response Headers accept-ranges:bytes //在整个返回体中本部分的字节位置 access-control-allow-origin://跨域请求,则允许所有域名的脚本访问该资源。 cache-control:max-age=600 //指定请求和响应遵循的缓存机制,当你请求头里设置no-cache时,是告诉服务器我这里没有缓存。响应头里这里设置的时间是600,意思浏览器600秒之内别来找我,自己去缓存找吧! content-encoding:gzip // web服务器支持的返回内容压缩编码类型为gzip,web服务器表明自己使用了什么压缩方法。 content-length:49207 //资源长度 content-type:text/css //告诉客户端,资源文件的类型,一般还有字符编码,例如charset=UTF-8,客户端将通过utf-8对资源进行解码,然后对资源进行html解析。 date:Mon, 07 Mar 2016 12:23:37 GMT//记录时间 expires:Mon, 07 Mar 2016 12:33:37 GMT //表明该实体将于什么时候过期 last-modified:Mon, 07 Mar 2016 07:19:19 GMT//请求资源的最后修改时间 server:nnws/1.7.3.6 //服务器信息,by the way!这是啥服务器? status:200 OK //状态码 version:HTTP/1.1 //http协议版本1.1 x-cache-lookup:Hit From MemCache Gz //查看服务器中是否有某个网页缓存,有则返回Hit,没有返回Miss看到http响应状态码我突然想到了404,= =!顺便带几个常见的: 100 Continue 继续,一般在发送post请求时,已发送了http、header之后服务端将返回此信息,表示确认,之后发送具体参数信息 200 OK 正常返回信息 201 Created 请求成功并且服务器创建了新的资源 301 Moved Permanently 请求的网页已永久移动到新位置。 400 Bad Request 服务器无法理解请求的格式,客户端不应当尝试再次使用相同的内容发起请求。 404 Not Found 找不到如何与 URI 相匹配的资源。 500 Internal Server Error 最常见的服务器端错误。4.浏览器渲染呈现 浏览器拿到响应的页面代码,将其解析呈现在用户面前,至于为什么会是看到的这个样子,有时又是另外的一些页面效果,这里就涉及到web标准了,也就是我们经常提到的w3c标准。根据资源的类型,在网页上呈现给用户,这个过程叫网页渲染。解析和呈现的过程主要由浏览器的渲染引擎实现,浏览器的渲染引擎质量就决定了浏览器的好坏(引擎这一块已经超出了我的理解范围了)。

a123456678 2019-12-02 02:08:40 0 浏览量 回答数 0

问题

如何优化网站的访问速度

cnsjw 2019-12-01 21:00:50 29372 浏览量 回答数 35

问题

关于工单,真是感慨万千啊。

小小的菜鸟 2019-12-01 21:45:20 3703 浏览量 回答数 4

阿里云试用中心,为您提供0门槛上云实践机会!

0元试用32+款产品,最高免费12个月!拨打95187-1,咨询专业上云建议!

问题

运维人员处理云服务器故障方法七七云转载

杨经理 2019-12-01 22:03:10 9677 浏览量 回答数 2

问题

如何快速定位云主机的故障

firstsko 2019-12-01 21:43:10 10637 浏览量 回答数 1

问题

如何彻底消灭Bug?

问问小秘 2020-06-29 11:07:58 13 浏览量 回答数 2

回答

分布式事务的解决方案有如下几种: 全局消息基于可靠消息服务的分布式事务TCC最大努力通知方案1:全局事务(DTP模型)全局事务基于DTP模型实现。DTP是由X/Open组织提出的一种分布式事务模型——X/Open Distributed Transaction Processing Reference Model。它规定了要实现分布式事务,需要三种角色: AP:Application 应用系统 它就是我们开发的业务系统,在我们开发的过程中,可以使用资源管理器提供的事务接口来实现分布式事务。 TM:Transaction Manager 事务管理器 分布式事务的实现由事务管理器来完成,它会提供分布式事务的操作接口供我们的业务系统调用。这些接口称为TX接口。事务管理器还管理着所有的资源管理器,通过它们提供的XA接口来同一调度这些资源管理器,以实现分布式事务。DTP只是一套实现分布式事务的规范,并没有定义具体如何实现分布式事务,TM可以采用2PC、3PC、Paxos等协议实现分布式事务。RM:Resource Manager 资源管理器 能够提供数据服务的对象都可以是资源管理器,比如:数据库、消息中间件、缓存等。大部分场景下,数据库即为分布式事务中的资源管理器。资源管理器能够提供单数据库的事务能力,它们通过XA接口,将本数据库的提交、回滚等能力提供给事务管理器调用,以帮助事务管理器实现分布式的事务管理。XA是DTP模型定义的接口,用于向事务管理器提供该资源管理器(该数据库)的提交、回滚等能力。DTP只是一套实现分布式事务的规范,RM具体的实现是由数据库厂商来完成的。有没有基于DTP模型的分布式事务中间件?DTP模型有啥优缺点?方案2:基于可靠消息服务的分布式事务这种实现分布式事务的方式需要通过消息中间件来实现。假设有A和B两个系统,分别可以处理任务A和任务B。此时系统A中存在一个业务流程,需要将任务A和任务B在同一个事务中处理。下面来介绍基于消息中间件来实现这种分布式事务。 title 在系统A处理任务A前,首先向消息中间件发送一条消息消息中间件收到后将该条消息持久化,但并不投递。此时下游系统B仍然不知道该条消息的存在。消息中间件持久化成功后,便向系统A返回一个确认应答;系统A收到确认应答后,则可以开始处理任务A;任务A处理完成后,向消息中间件发送Commit请求。该请求发送完成后,对系统A而言,该事务的处理过程就结束了,此时它可以处理别的任务了。 但commit消息可能会在传输途中丢失,从而消息中间件并不会向系统B投递这条消息,从而系统就会出现不一致性。这个问题由消息中间件的事务回查机制完成,下文会介绍。消息中间件收到Commit指令后,便向系统B投递该消息,从而触发任务B的执行;当任务B执行完成后,系统B向消息中间件返回一个确认应答,告诉消息中间件该消息已经成功消费,此时,这个分布式事务完成。上述过程可以得出如下几个结论: 消息中间件扮演者分布式事务协调者的角色。 系统A完成任务A后,到任务B执行完成之间,会存在一定的时间差。在这个时间差内,整个系统处于数据不一致的状态,但这短暂的不一致性是可以接受的,因为经过短暂的时间后,系统又可以保持数据一致性,满足BASE理论。 上述过程中,如果任务A处理失败,那么需要进入回滚流程,如下图所示: title 若系统A在处理任务A时失败,那么就会向消息中间件发送Rollback请求。和发送Commit请求一样,系统A发完之后便可以认为回滚已经完成,它便可以去做其他的事情。消息中间件收到回滚请求后,直接将该消息丢弃,而不投递给系统B,从而不会触发系统B的任务B。此时系统又处于一致性状态,因为任务A和任务B都没有执行。 上面所介绍的Commit和Rollback都属于理想情况,但在实际系统中,Commit和Rollback指令都有可能在传输途中丢失。那么当出现这种情况的时候,消息中间件是如何保证数据一致性呢?——答案就是超时询问机制。 title 系统A除了实现正常的业务流程外,还需提供一个事务询问的接口,供消息中间件调用。当消息中间件收到一条事务型消息后便开始计时,如果到了超时时间也没收到系统A发来的Commit或Rollback指令的话,就会主动调用系统A提供的事务询问接口询问该系统目前的状态。该接口会返回三种结果: 提交 若获得的状态是“提交”,则将该消息投递给系统B。回滚 若获得的状态是“回滚”,则直接将条消息丢弃。处理中 若获得的状态是“处理中”,则继续等待。消息中间件的超时询问机制能够防止上游系统因在传输过程中丢失Commit/Rollback指令而导致的系统不一致情况,而且能降低上游系统的阻塞时间,上游系统只要发出Commit/Rollback指令后便可以处理其他任务,无需等待确认应答。而Commit/Rollback指令丢失的情况通过超时询问机制来弥补,这样大大降低上游系统的阻塞时间,提升系统的并发度。 下面来说一说消息投递过程的可靠性保证。 当上游系统执行完任务并向消息中间件提交了Commit指令后,便可以处理其他任务了,此时它可以认为事务已经完成,接下来消息中间件一定会保证消息被下游系统成功消费掉!那么这是怎么做到的呢?这由消息中间件的投递流程来保证。 消息中间件向下游系统投递完消息后便进入阻塞等待状态,下游系统便立即进行任务的处理,任务处理完成后便向消息中间件返回应答。消息中间件收到确认应答后便认为该事务处理完毕! 如果消息在投递过程中丢失,或消息的确认应答在返回途中丢失,那么消息中间件在等待确认应答超时之后就会重新投递,直到下游消费者返回消费成功响应为止。当然,一般消息中间件可以设置消息重试的次数和时间间隔,比如:当第一次投递失败后,每隔五分钟重试一次,一共重试3次。如果重试3次之后仍然投递失败,那么这条消息就需要人工干预。 title title 有的同学可能要问:消息投递失败后为什么不回滚消息,而是不断尝试重新投递? 这就涉及到整套分布式事务系统的实现成本问题。 我们知道,当系统A将向消息中间件发送Commit指令后,它便去做别的事情了。如果此时消息投递失败,需要回滚的话,就需要让系统A事先提供回滚接口,这无疑增加了额外的开发成本,业务系统的复杂度也将提高。对于一个业务系统的设计目标是,在保证性能的前提下,最大限度地降低系统复杂度,从而能够降低系统的运维成本。 不知大家是否发现,上游系统A向消息中间件提交Commit/Rollback消息采用的是异步方式,也就是当上游系统提交完消息后便可以去做别的事情,接下来提交、回滚就完全交给消息中间件来完成,并且完全信任消息中间件,认为它一定能正确地完成事务的提交或回滚。然而,消息中间件向下游系统投递消息的过程是同步的。也就是消息中间件将消息投递给下游系统后,它会阻塞等待,等下游系统成功处理完任务返回确认应答后才取消阻塞等待。为什么这两者在设计上是不一致的呢? 首先,上游系统和消息中间件之间采用异步通信是为了提高系统并发度。业务系统直接和用户打交道,用户体验尤为重要,因此这种异步通信方式能够极大程度地降低用户等待时间。此外,异步通信相对于同步通信而言,没有了长时间的阻塞等待,因此系统的并发性也大大增加。但异步通信可能会引起Commit/Rollback指令丢失的问题,这就由消息中间件的超时询问机制来弥补。 那么,消息中间件和下游系统之间为什么要采用同步通信呢? 异步能提升系统性能,但随之会增加系统复杂度;而同步虽然降低系统并发度,但实现成本较低。因此,在对并发度要求不是很高的情况下,或者服务器资源较为充裕的情况下,我们可以选择同步来降低系统的复杂度。 我们知道,消息中间件是一个独立于业务系统的第三方中间件,它不和任何业务系统产生直接的耦合,它也不和用户产生直接的关联,它一般部署在独立的服务器集群上,具有良好的可扩展性,所以不必太过于担心它的性能,如果处理速度无法满足我们的要求,可以增加机器来解决。而且,即使消息中间件处理速度有一定的延迟那也是可以接受的,因为前面所介绍的BASE理论就告诉我们了,我们追求的是最终一致性,而非实时一致性,因此消息中间件产生的时延导致事务短暂的不一致是可以接受的。 方案3:最大努力通知(定期校对)最大努力通知也被称为定期校对,其实在方案二中已经包含,这里再单独介绍,主要是为了知识体系的完整性。这种方案也需要消息中间件的参与,其过程如下: title 上游系统在完成任务后,向消息中间件同步地发送一条消息,确保消息中间件成功持久化这条消息,然后上游系统可以去做别的事情了;消息中间件收到消息后负责将该消息同步投递给相应的下游系统,并触发下游系统的任务执行;当下游系统处理成功后,向消息中间件反馈确认应答,消息中间件便可以将该条消息删除,从而该事务完成。上面是一个理想化的过程,但在实际场景中,往往会出现如下几种意外情况: 消息中间件向下游系统投递消息失败上游系统向消息中间件发送消息失败对于第一种情况,消息中间件具有重试机制,我们可以在消息中间件中设置消息的重试次数和重试时间间隔,对于网络不稳定导致的消息投递失败的情况,往往重试几次后消息便可以成功投递,如果超过了重试的上限仍然投递失败,那么消息中间件不再投递该消息,而是记录在失败消息表中,消息中间件需要提供失败消息的查询接口,下游系统会定期查询失败消息,并将其消费,这就是所谓的“定期校对”。 如果重复投递和定期校对都不能解决问题,往往是因为下游系统出现了严重的错误,此时就需要人工干预。 对于第二种情况,需要在上游系统中建立消息重发机制。可以在上游系统建立一张本地消息表,并将 任务处理过程 和 向本地消息表中插入消息 这两个步骤放在一个本地事务中完成。如果向本地消息表插入消息失败,那么就会触发回滚,之前的任务处理结果就会被取消。如果这量步都执行成功,那么该本地事务就完成了。接下来会有一个专门的消息发送者不断地发送本地消息表中的消息,如果发送失败它会返回重试。当然,也要给消息发送者设置重试的上限,一般而言,达到重试上限仍然发送失败,那就意味着消息中间件出现严重的问题,此时也只有人工干预才能解决问题。 对于不支持事务型消息的消息中间件,如果要实现分布式事务的话,就可以采用这种方式。它能够通过重试机制+定期校对实现分布式事务,但相比于第二种方案,它达到数据一致性的周期较长,而且还需要在上游系统中实现消息重试发布机制,以确保消息成功发布给消息中间件,这无疑增加了业务系统的开发成本,使得业务系统不够纯粹,并且这些额外的业务逻辑无疑会占用业务系统的硬件资源,从而影响性能。 因此,尽量选择支持事务型消息的消息中间件来实现分布式事务,如RocketMQ。 方案4:TCC(两阶段型、补偿型)TCC即为Try Confirm Cancel,它属于补偿型分布式事务。顾名思义,TCC实现分布式事务一共有三个步骤: Try:尝试待执行的业务 这个过程并未执行业务,只是完成所有业务的一致性检查,并预留好执行所需的全部资源Confirm:执行业务 这个过程真正开始执行业务,由于Try阶段已经完成了一致性检查,因此本过程直接执行,而不做任何检查。并且在执行的过程中,会使用到Try阶段预留的业务资源。Cancel:取消执行的业务 若业务执行失败,则进入Cancel阶段,它会释放所有占用的业务资源,并回滚Confirm阶段执行的操作。下面以一个转账的例子来解释下TCC实现分布式事务的过程。 假设用户A用他的账户余额给用户B发一个100元的红包,并且余额系统和红包系统是两个独立的系统。 Try 创建一条转账流水,并将流水的状态设为交易中将用户A的账户中扣除100元(预留业务资源)Try成功之后,便进入Confirm阶段Try过程发生任何异常,均进入Cancel阶段Confirm 向B用户的红包账户中增加100元将流水的状态设为交易已完成Confirm过程发生任何异常,均进入Cancel阶段Confirm过程执行成功,则该事务结束Cancel 将用户A的账户增加100元将流水的状态设为交易失败在传统事务机制中,业务逻辑的执行和事务的处理,是在不同的阶段由不同的部件来完成的:业务逻辑部分访问资源实现数据存储,其处理是由业务系统负责;事务处理部分通过协调资源管理器以实现事务管理,其处理由事务管理器来负责。二者没有太多交互的地方,所以,传统事务管理器的事务处理逻辑,仅需要着眼于事务完成(commit/rollback)阶段,而不必关注业务执行阶段。 TCC全局事务必须基于RM本地事务来实现全局事务TCC服务是由Try/Confirm/Cancel业务构成的, 其Try/Confirm/Cancel业务在执行时,会访问资源管理器(Resource Manager,下文简称RM)来存取数据。这些存取操作,必须要参与RM本地事务,以使其更改的数据要么都commit,要么都rollback。 这一点不难理解,考虑一下如下场景: title 假设图中的服务B没有基于RM本地事务(以RDBS为例,可通过设置auto-commit为true来模拟),那么一旦[B:Try]操作中途执行失败,TCC事务框架后续决定回滚全局事务时,该[B:Cancel]则需要判断[B:Try]中哪些操作已经写到DB、哪些操作还没有写到DB:假设[B:Try]业务有5个写库操作,[B:Cancel]业务则需要逐个判断这5个操作是否生效,并将生效的操作执行反向操作。 不幸的是,由于[B:Cancel]业务也有n(0<=n<=5)个反向的写库操作,此时一旦[B:Cancel]也中途出错,则后续的[B:Cancel]执行任务更加繁重。因为,相比第一次[B:Cancel]操作,后续的[B:Cancel]操作还需要判断先前的[B:Cancel]操作的n(0<=n<=5)个写库中哪几个已经执行、哪几个还没有执行,这就涉及到了幂等性问题。而对幂等性的保障,又很可能还需要涉及额外的写库操作,该写库操作又会因为没有RM本地事务的支持而存在类似问题。。。可想而知,如果不基于RM本地事务,TCC事务框架是无法有效的管理TCC全局事务的。 反之,基于RM本地事务的TCC事务,这种情况则会很容易处理:[B:Try]操作中途执行失败,TCC事务框架将其参与RM本地事务直接rollback即可。后续TCC事务框架决定回滚全局事务时,在知道“[B:Try]操作涉及的RM本地事务已经rollback”的情况下,根本无需执行[B:Cancel]操作。 换句话说,基于RM本地事务实现TCC事务框架时,一个TCC型服务的cancel业务要么执行,要么不执行,不需要考虑部分执行的情况。 TCC事务框架应该提供Confirm/Cancel服务的幂等性保障一般认为,服务的幂等性,是指针对同一个服务的多次(n>1)请求和对它的单次(n=1)请求,二者具有相同的副作用。 在TCC事务模型中,Confirm/Cancel业务可能会被重复调用,其原因很多。比如,全局事务在提交/回滚时会调用各TCC服务的Confirm/Cancel业务逻辑。执行这些Confirm/Cancel业务时,可能会出现如网络中断的故障而使得全局事务不能完成。因此,故障恢复机制后续仍然会重新提交/回滚这些未完成的全局事务,这样就会再次调用参与该全局事务的各TCC服务的Confirm/Cancel业务逻辑。 既然Confirm/Cancel业务可能会被多次调用,就需要保障其幂等性。 那么,应该由TCC事务框架来提供幂等性保障?还是应该由业务系统自行来保障幂等性呢? 个人认为,应该是由TCC事务框架来提供幂等性保障。如果仅仅只是极个别服务存在这个问题的话,那么由业务系统来负责也是可以的;然而,这是一类公共问题,毫无疑问,所有TCC服务的Confirm/Cancel业务存在幂等性问题。TCC服务的公共问题应该由TCC事务框架来解决;而且,考虑一下由业务系统来负责幂等性需要考虑的问题,就会发现,这无疑增大了业务系统的复杂度。

1210119897362579 2019-12-02 00:14:25 0 浏览量 回答数 0

问题

【阿里云产品评测】个人WP站的云体验

cnsjw 2019-12-01 20:54:27 22207 浏览量 回答数 25

问题

Node.js 应该处于技术架构中的哪个位置?

李博 bluemind 2019-12-01 21:47:42 2961 浏览量 回答数 0

回答

1.产品2.UI3.CSS4.JS5.后端(Java/php/python)6.DBA(mysql/oracle)7.运维(OP) 8.测试(QA)9.算法(分类/聚类/关系抽取/实体识别)10.搜索(Lucene/Solr/elasticSearch)11.大数据工程师(Hadoop)12.Android13.IOS14.运营 一.产品1 工作内容:了解用户需求,做竞品调研,画产品原型,写产品文档,讲解产品需求,测试产品Bug,收集用户反馈,苦练金刚罩以防止程序员拿刀砍。2 需要技能:PPT,Word, Axure,XP,MVP,行业知识,沟通。 二. UI1 工作内容:收到产品原型,给原型上色,偶尔会自作主张调整下原型的位置,出不同的风格给老板和客户选,然后听他们的意见给出一个自己极不喜欢的风格,最好给Android,IOS或者是CSS做好标注,还有的需要直接帮他们切好图,最后要练出来象素眼,看看这些不靠谱的程序员们有没有上错色或者是有偏差。2 需要技能:PS,Illustrator,Sketch,耐性,找素材。 三. CSS1 工作内容:产品设计好原型,UI做出来了效果图,剩下的就是CSS工程师用代码把静态文件写出来的。 2 需要技能:环境【IDE(WEBStorm,Sublime,EditPlus),源码管理(SVN/Git) ,WEB服务器(nginx)】基础【PS,域名,Html,Html5,CSS,CSS3】扩展【自适应,响应式,Bootstrap,Less,Flex】 四 .JS 1 工作内容:JS工程师其实分成两类,在之前讲CSS的时候已经提到过,一个是套页面的,一个是前后端分离的。对这两个概念还是分不太清的,可以回过头去看CSS的部分。 2 需要技能:环境【IDE(WEBStorm,Sublime,EditPlus),源码管理(SVN/Git) ,WEB服务器(nginx)】基础【Http,REST,跨域,语法,组件,F12,Json,Websocket】框架【JQuery,AngularJS,Bower,RequireJS,GruntJS,ReactJS,PhoneGap】业务【金融,教育,医疗,汽车,房产等等等等各种行业】 五 .后端(Java/python/go) 1 工作内容:大部分的后端工程师都停留在功能实现的层面上。这是现在国内二流或者是三流的公司的现状,甚至是在某些一流的公司。很多时候都是架构师出了架构设计,更多的外包公司根本就是有DBA来做设计,然后后端程序员从JS到CSS到Java全写,完全就是一个通道,所有的复杂逻辑全部交给DB来做,这也是几年前DBA很受重视的原因。 2 需要技能:环境【IDE(Idea/Eclipse,Maven,jenkins,Nexus,Jetty,Shell,Host),源码管理(SVN/Git) ,WEB服务器(nginx,tomcat,Resin)】基础【Http,REST,跨域,语法,Websocket,数据库,计算机网络,操作系统,算法,数据结构】框架【Spring,AOP,Quartz,Json TagLib,tiles,activeMQ,memcache,redis,mybatis,log4j,junit等等等等等】业务【金融,教育,医疗,汽车,房产等等等等各种行业】。 六 .DBA  1 工作内容:如果你做了一个DBA,基本上会遇到两种情况。一种是你的后端工程师懂架构,知道怎么合便使用DB,知道如何防止穿透DB,那么恭喜你,你只是需要当一个DB技术兜底的顾问就好,基本上没什么活可以做,做个监控,写个统计就好了。你可以花时间在MongoDB了,Hadoop了这些,随便玩玩儿。再按照我之前说的,做好数据备份。如果需求变动比较大,往往会牵涉到一些线上数据的更改,那么就在发布的时候安静的等着,等着他们出问题。。。。如果不出问题就可以回家睡觉了。 2 需要技能:环境【Linux,Mysql,Oracle,MongoDB,Hadoop】工具【各种DB的版本,工具,备份,日志等】。 七. 运维  1 工作内容:运维的工作大概分成几个部分,我对于修真院学习运维的少年们都这么说,大概是:A。基础环境的搭建和常用软件的安装和配置(兼网管的还有各种程控机),常用软件指的是SVN,Git,邮箱这种,更细节的内容请参考修真院对于运维职业的介绍。B。日常的发布和维护,如刚刚讲到的一样,测试环境和线上环境的发布和记录,原则上,对线上所有的变更都应该有记录。C。数据的备份和服务的监控&安全配置。各种数据,都要做好备份和回滚的手段,提前准备好各种紧急预案,服务的监制要做好。安全始终都是不怎么被重点考虑的问题,因为这个东西无底洞,你永远不知道做到什么程度算是比较安全了,所以大多数都是看着情况来。D。运维工具的编写。这一点在大的云服务器商里格外常见,大公司也是一样的。E。Hadoop相关的大数据体系架构的运维,确实有公司在用几百台机器做Hadoop,所以虽然不常见,我还是列出来吧。 2 需要技能:环境【Linux,Mysql,Oracle,MongoDB,Hadoop,nginx,apache,F5,lvs,vpn,iptable,svn,git,memcache,redis】工具【linux 常用工具,Mysql常用工具,Jenkins,zabbix,nagios】自动化运维【openstack,docker,ansible】语言【shell,python】 八 .QA  1 工作内容:QA需要了解需求,很多公司会要求QA写测试用例,我觉得是扯淡。完全是在浪费时间。通常开发三周,QA测试的时间只有一周到一周半。还有关于提前写测试用例的,都不靠谱。 2 需要技能:流程【Bug修复流程,版本发布流程】工具【禅道,BugZilla,Jira,Excel表格来统计Bug数,自动化测试】性格【严谨,耐心】 九. 算法工程师  1 工作内容:算法工程师的工作内容,大部分时间都是在调优。就是调各种参数和语料,寻找特征,验证结果,排除噪音。也会和Hadoop神马的打一些交道,mahout神马的,我那个时候还在用JavaML。现在并不知道有没有什么更好用的工具了。有的时候还要自己去标注语料---当然大部分人都不爱做这个事儿,会找漂亮的小编辑去做。2 需要技能:基础【机器学习,数据挖掘】工具【Mahout,JavaML等其他的算法工具集】 十. 搜索工程师  1 工作内容: 所以搜索现在其实分成两种。一种是传统的搜索。包括:A。抓取 B。解析C。去重D。处理E。索引F。查询另一种是做为架构的搜索。并不包括之前的抓取解析去重,只有索引和查询。A。索引B。查询 2 需要技能:环境【Linux】框架【Luence,Slor,ElasticSearch,Cassandra,MongoDB】算法【倒排索引,权重计算公式,去重算法,Facet搜索的原理,高亮算法,实时索引】 十一. 大数据工程师  1 工作内容:工作内容在前期会比较多一些,基础搭建还是一个挺讲究的事儿。系统搭建好之后呢,大概是两种,一种是向大数据部门提交任务,跑一圈给你。一种是持续的文本信息处理中增加新的处理模块,像我之前说的增加个分类啦,实体识别神马的。好吧第一种其实我也不记得是从哪得来的印象了,我是没有见到过的。架构稳定了之后,大数据部门的工作并不太多,常常会和算法工程师混到一起来。其他的应该就是大数据周边产品的开发工作了。再去解决一些Bug什么的。2 需要技能:环境【Linux】框架【Hadoo,spark,storm,pig,hive,mahout,zookeeper 】算法【mapreduce,hdfs,zookeeper】。 十二. Android工程师  1 工作内容:Android工程师的日常就是听产品经理讲需求,跟后端定接口,听QA反馈哪款机器不兼容,闹着申请各种测试机,以及悲催的用Android做IOS的控件。 2 需要技能:环境【Android Studio,Maven,Gradle】基础【数据结构,Java,计算机网络】组件【IM,地图,支付,拍照,视频,音频,统计,分享,手势密码】 十三. IOS工程师  1 工作内容:IOS工程师的工作内容真的挺简单的,听需求,定接口。做个适配,抛弃一下iphone4。还有啥。。马丹,以我为数不多的IOS知识来讲,真的不知道还有啥了。我知道的比较复杂的系统也是各种背景高斯模糊,各种渐变,各种图片滤镜处理,其他并没有什么。支付,地图,统计这些东西。 嗯。2 需要技能:环境【Xcode】基础【数据结构,Object,计算机网络】组件【IM,地图,支付,拍照,视频,音频,统计,分享,手势密码】

行者武松 2019-12-02 01:21:45 0 浏览量 回答数 0

问题

dubbo 的工作原理?注册中心挂了的问题?说说一次 rpc 请求的流程?【Java问答】47期

剑曼红尘 2020-06-30 09:02:47 8 浏览量 回答数 1

回答

以下是我列出的2020年Java开发者应该学习的技术: 1、DevOps (Docker and Jenkins) 过去的一年,越来越多的公司正在转型DevOps,DevOps非常庞大,需要学习很多工具和原理,但你不需要担心。有大神已经分享了DevOps路线图(https://github.com/kamranahmedse/developer-roadmap,可以按照这个路线图以自己的速度学习和掌握DevOps。 如果你是一个有经验的Java程序员,愿意学习环境管理、自动化和整体改进,你也可以成为DevOps工程师。 2、Java 9 - Java 15 相信现在很多Java开发人员主要使用的Java版本还是以Java 8为主,虽然Java 9 - Java 13已经推出了有一段时间。 但是作为Java程序员,我们可能因为某些原因没办法在线上环境真正的进行JDK的升级,但是花一些时间学习Java 9、Java 10、Java 11、Java 12和 Java 13的新特性还是有必要的。 另外,大家可以重点关注一些关键特性,如GC相关的特性、对编码风格有改变的特性等。还有就是Java的LTS版本(Java 8、Java 11)要重点学习。 还要提醒大家一点,在2020年,Oracle还会推出Java 14 和 Java 15!!!如果你在使用Java 7的话,马上就要被"套圈"了! 3、Spring Framework 5 2017年我们见证了Spring和Java生态系统的许多重大升级,Spring 5.0就是其中之一。Spring 5 的新反应式编程模型、HTTP/2 支持,以及 Spring 通过 Kotlin 对函数式编程的全面支持这些都值得我们好好了解一下。 4、Spring Security 5.0 Spring Security 5.0 提供了许多新功能,并支持 Spring Framework 5.0,总共有 400 多个增强功能和 bug 修复。在Spring Security 5.0.0之前,密码是明文保存,十分不安全。因为这一次发布的是大版本,所以我们决定使用更安全的密码存储方式。Spring Security 5.0.0的主要亮点在于它只需要最小化的JDK 8、反应式安全特性、OAuth 2.0(OIDC)和现代密码存储。 5、Spring Boot 2 Spring Boot 2.0 基于 Spring 5 Framework ,提供了 异步非阻塞 IO 的响应式 Stream 、非堵塞的函数式 Reactive Web 框架 Spring WebFlux等特性。很多使用过SpringBoot的人都知道,使用SpringBoot搭建Web应用真的是又快又好,相信Spring Boot 2会带来更多惊喜。 6、Hadoop、Spark 和 Kafka 另外在2020年Java程序员需要学习的是大数据相关的知识。特别是Apache Spark 和 Kafka两个框架。 如果你也想在2020年学习大数据,也一定绕不开Hadoop生态。 7、Elasticsearch 全文搜索属于最常见的需求,开源的 Elasticsearch (以下简称 Elastic)是目前全文搜索引擎的首选。维基百科、Stack Overflow、Github 都在使用它。 Elasticsearch是一个基于Lucene库的搜索引擎。它提供了一个分布式、支持多租户的全文搜索引擎,具有HTTP Web接口和无模式JSON文档。Elasticsearch是用Java开发的,并在Apache许可证下作为开源软件发布。 8、ServiceMesh 这两年很火,火的一塌糊涂。在2019年,但凡是程序员相关的大会,如果没有讲ServiceMest的专题,那都不好意思开。 所有人都在说 ServiceMesh; 几乎没人知道怎么落地 ServiceMesh; 但是大家都觉得其他人在大力做 ServiceMesh; 所以大家都宣称自己在做 ServiceMesh; 这个号称下一代微服务架构的概念,现在对于大多数人来说根本不知道是啥。只知道很多大厂宣称自己在做,很多大牛在布道。 9、Serverless 无服务器运算(英语:Serverless computing),又被称为功能即服务(Function-as-a-Service,缩写为 FaaS),是云计算的一种模型。以平台即服务(PaaS)为基础,无服务器运算提供一个微型的架构,终端客户不需要部署、配置或管理服务器服务,代码运行所需要的服务器服务皆由云平台来提供。这东西,听上去就很高大上。 2019年,和ServiceMesh一样,所有人都宣称自己在做。但是又很很多人不知道他到底是什么。 10、Kotlin 如果大家有关注Java 13的新特性的话,一定知道推出了字符串文本块的功能,这个功能其实是借鉴的Kotlin,除此之外,最近几年,Java有很多特性都在借鉴Kotlin,相比较于Java,Kotlin更加简洁,而且Kotlin编出来的代码也可以直接通过JVM运行。 Kotlin是一种在Java虚拟机上运行的静态类型编程语言,它也可以被编译成为JavaScript源代码。Kotlin的设计初衷就是用来生产高性能要求的程序的,所以运行起来和Java也是不相上下。Kotlin可以从 JetBrains InteilliJ Idea IDE这个开发工具以插件形式使用。 总结 以上,就是作者总结的建议Java程序员在2020年学习的一些技术,其中有一些是一定要学习的,还有一些是看大家的精力情况酌情考虑。

剑曼红尘 2020-04-07 20:42:52 0 浏览量 回答数 0

回答

adb介绍: Android Debug Bridge(安卓调试桥) tools。它就是一个命令行窗口,用于通过电脑端与模拟器或者是设备之间的交互。 ADB是一个C/S架构的应用程序,由三部分组成: 运行在pc端的adb client: 命令行程序”adb”用于从shell或脚本中运行adb命令。首先,“adb”程序尝试定位主机上的ADB服务器,如果找不到ADB服务器,“adb”程序自动启动一个ADB服务器。接下来,当设备的adbd和pc端的adb server建立连接后,adb client就可以向ADB servcer发送服务请求; 运行在pc端的adb server: ADB Server是运行在主机上的一个后台进程。它的作用在于检测USB端口感知设备的连接和拔除,以及模拟器实例的启动或停止,ADB Server还需要将adb client的请求通过usb或者tcp的方式发送到对应的adbd上; 运行在设备端的常驻进程adb demon (adbd): 程序“adbd”作为一个后台进程在Android设备或模拟器系统中运行。它的作用是连接ADB服务器,并且为运行在主机上的客户端提供一些服务。 adb下载及安装: 一共有两种方法: 首先第一种就是最简单的方法,只下载adb压缩包去解压即可:链接:https://pan.baidu.com/s/1SKu24yyShwg16lyIupO5VA 提取码:ih0i (备注:如果下载放入到D盘去解压,打开dos窗口那么就要进入到D盘,然后再去执行adb命令,输入adb查看它是否安装成功) 第二种方法前提是已安装了Android Studio,它本身带有adb命令,如果配置好的Android Studio 一般都是可以直接调用adb命令的;如果不行,找到adb在SDK里的绝对路径,放入环境变量path中(绝对路径不带入adb.exe) 然后输入adb version 查看版本 可以看出是否安装成功,如下就已经成功了。 启动 adb server 命令:adb start-server 停止 adb server 命令:adb kill-server 查询已连接设备/模拟器:adb devices 该命令经常出现以下问题: offline —— 表示设备未连接成功或无响应; device —— 设备已连接; no device —— 没有设备/模拟器连接; List of devices attached 设备/模拟器未连接到 adb 或无响应 USB连接: 在手机“设置”-“关于手机”连续点击“版本号”7 次,可以进入到开发者模式;然后可以到“设置”-“开发者选项”-“调试”里打开USB调试以及允许ADB的一些权限;连接时手机会弹出“允许HiSuite通过HDB连接设备”点击允许/接受即可; 驱动也是必须安装的,可以用豌豆荚,或者是手机商家提供的手机助手,点进去驱动器安装即可(部分电脑双击无法直接进入到驱动器里,可以使用右键找到进入点击即可) 再次输入adb devices验证是否连接成功,连接成功即如下图: 也可以进行无线连接,其中非root权限也需借助USB线进行操作,完成后即可断开USB线;root用户可以进行无线连接,具体步骤可以参考网上资源。 **查看是否有root权限:**输入adb shell,然后输入su KaTeX parse error: Expected 'EOF', got '#' at position 5: 如果变为#̲则成功,如果仍为则未有root权限;恢复命令:adb unroot 查看应用列表: 查看所有应用列表:adb shell pm list packages 查看系统应用列表:adb shell pm list packages -s 查看第三方应用列表:adb shell pm list packages -3: 安装apk:adb install “-lrtsdg” “path_to_apk” “-lrtsdg”: -l:将应用安装到保护目录 /mnt/asec; -r:允许覆盖安装; -t:允许安装 AndroidManifest.xml 里 application 指定 android:testOnly=“true” 的应用; -s:将应用安装到 sdcard; -d:允许降级覆盖安装; -g:授予所有运行时权限; path_to_apk:apk的绝对路径。 示例安装淘宝apk:adb install -l /data/local/tmp/taobao.apk 卸载apk:adb uninstall -k “packagename” “packagename”:表示应用的包名,以下相同; -k 参数可选,表示卸载应用但保留数据和缓存目录。 示例卸载 手机淘宝:adb uninstall com.taobao.taobao 清除应用数据与缓存命令:adb shell pm clear “packagename” 相当于在设置里的应用信息界面点击「清除缓存」和「清除数据」。 示例:adb shell pm clear com.taobao.taobao 表示清除 手机淘宝数据和缓存。 Android四大组件有Activity,Service服务,Content Provider内容提供,BroadcastReceiver广播接收器,具体不做多讲,常用的有以下: 查看前台 Activity命令:adb shell dumpsys activity activities | grep mFocusedActivity 查看正在运行的 Services命令:adb shell dumpsys activity services “packagename” 其中参数不是必须的,指定 “packagename” 表示查看与某个包名相关的 Services,不指定表示查看所有 Services。 查看应用详细信息命令:adb shell dumpsys package “packagename” 调起 Activity命令格式:adb shell am start [options] 例如:adb shell am start -n com.tencent.mm/.ui.LauncherUI表示调起微信主界面 调起 Service命令格式:adb shell am startservice [options] 例如:adb shell am startservice -n com.tencent.mm/.plugin.accountsync.model.AccountAuthenticatorService 表示调起微信的某 Service。 强制停止应用命令:adb shell am force-stop “packagename” 例如强制停止淘宝:adb shell am force-stop com.taobao.taobao 模拟按键/输入:adb shell input keyevent keycode 不同的 keycode有不同的功能: keycode 含义 3 HOME 键 4 返回键 5 打开拨号应用 6 挂断电话 26 电源键 27 拍照(需要在相机应用里) 61 Tab键 64 打开浏览器 67 退格键 80 拍照对焦键 82 菜单键 85 播放/暂停 86 停止播放 92 向上翻页键 93 向下翻页键 111 ESC键 112 删除键 122 移动光标到行首或列表顶部 123 移动光标到行末或列表底部 124 插入键 164 静音 176 打开系统设置 207 打开联系人 208 打开日历 209 打开音乐 220 降低屏幕亮度 221 提高屏幕亮度 223 系统休眠 224 点亮屏幕 224 点亮屏幕 224 点亮屏幕 231 打开语音助手 276 如果没有 wakelock 则让系统休眠 滑动解锁:如果锁屏没有密码,是通过滑动手势解锁,那么可以通过 input swipe 来解锁。 命令:adb shell input swipe 300 1000 300 500 (其中参数 300 1000 300 500 分别表示起始点x坐标 起始点y坐标 结束点x坐标 结束点y坐标。) 输入文本:在焦点处于某文本框时,可以通过 input 命令来输入文本。 命令:adb shell input text *** (***即为输入内容) 打印日志: Android 的日志分为如下几个优先级(priority): V —— Verbose(最低,输出得最多) D —— Debug I —— Info W —— Warning E —— Error F—— Fatal S —— Silent(最高,啥也不输出) 按某级别过滤日志则会将该级别及以上的日志输出。 比如,命令:adb logcat *:W 会将 Warning、Error、Fatal 和 Silent 日志输出。 (注: 在 macOS 下需要给 :W 这样以 作为 tag 的参数加双引号,如 adb logcat “:W”,不然会报错 no matches found: :W。) adb logcat 打印当前设备上所有日志 adb logcat :W 过滤打印严重级别W及以上的日志 adb logcat l findstr ***> F:\log.txt 把仅含的日志保存到F盘的log.txt文件中 adb logcat -c 清除屏幕上的日志记录 adb logcat -c && adb logcat -s ActivityManager l grep "Displayed” 客户端程序启动时间获取日志 adb logcat > F:\log.txt 打印当前设备上所有日志保存到F盘的log.txt文件中 adb logcat l findstr *** 打印过滤仅含的日志 adb logcat l findstr ***> F:\log.txt 把仅含**的日志保存到F盘的log.txt文件中 按 tag 和级别过滤日志:命令:adb logcat ActivityManager:I MyApp:D *:S 表示输出 tag ActivityManager 的 Info 以上级别日志,输出 tag MyApp 的 Debug 以上级别日志,及其它 tag 的 Silent 级别日志(即屏蔽其它 tag 日志)。 日志格式可以用:adb logcat -v 选项指定日志输出格式。 日志支持按以下几种 :默认格式brief、process、tag、raw、time、long 指定格式可与上面的过滤同时使用。比如:adb logcat -v long ActivityManager:I *:S 清空日志:adb logcat -c 内核日志:adb shell dmesg 查看设备情况: 查看设备信息型号命令:adb shell getprop ro.product.model 电池状况命令:adb shell dumpsys battery 屏幕分辨率命令:adb shell wm size 如果使用命令修改过,那输出可能是: Physical size: 1080x1920 Override size: 480x1024 表明设备的屏幕分辨率原本是 1080px * 1920px,当前被修改为 480px * 1024px。 屏幕密度命令:adb shell wm density 如果使用命令修改过,那输出可能是: Physical density: 480 Override density: 160 表明设备的屏幕密度原来是 480dpi,当前被修改为 160dpi。 显示屏参数:adb shell dumpsys window displays 输出示例: WINDOW MANAGER DISPLAY CONTENTS (dumpsys window displays) Display: mDisplayId=0 init=1080x1920 420dpi cur=1080x1920 app=1080x1794 rng=1080x1017-1810x1731 deferred=false layoutNeeded=false 其中 mDisplayId 为 显示屏编号,init 是初始分辨率和屏幕密度,app 的高度比 init 里的要小,表示屏幕底部有虚拟按键,高度为 1920 - 1794 = 126px 合 42dp。 android_id查看命令:adb shell settings get secure android_id 查看Android 系统版本:adb shell getprop ro.build.version.release 查看设备ip地址:adb shell ifconfig | grep Mask或者adb shell netcfg 查看CPU 信息命令:adb shell cat /proc/cpuinfo 查看内存信息命令:adb shell cat /proc/meminfo 更多硬件与系统属性: 设备的更多硬件与系统属性可以通过如下命令查看:adb shell cat /system/build.prop 单独查看某一硬件或系统属性:adb shell getprop <属性名> 属性名 含义 ro.build.version.sdk SDK 版本 ro.build.version.release Android 系统版本 ro.product.model 型号 ro.product.brand 品牌 ro.product.name 设备名 ro.product.board 处理器型号 persist.sys.isUsbOtgEnabled 是否支持 OTG dalvik.vm.heapsize 每个应用程序的内存上限 ro.sf.lcd_density 屏幕密度 rro.build.version.security_patch Android 安全补丁程序级别 修改设置: 修改设置之后,运行恢复命令有可能显示仍然不太正常,可以运行 adb reboot 重启设备,或手动重启。 修改设置的原理主要是通过 settings 命令修改 /data/data/com.android.providers.settings/databases/settings.db 里存放的设置值。 修改分辨率命令:adb shell wm size 480x1024 恢复原分辨率命令:adb shell wm size reset 修改屏幕密度命令:adb shell wm density 160 表示将屏幕密度修改为 160dpi;恢复原屏幕密度命令:adb shell wm density reset 修改显示区域命令:adb shell wm overscan 0,0,0,200 四个数字分别表示距离左、上、右、下边缘的留白像素,以上命令表示将屏幕底部 200px 留白。恢复原显示区域命令:adb shell wm overscan reset 关闭 USB 调试模式命令:adb shell settings put global adb_enabled 0 需要手动恢复:「设置」-「开发者选项」-「Android 调试」 状态栏和导航栏的显示隐藏:adb shell settings put global policy_control 可由如下几种键及其对应的值组成,格式为 =:=。 key 含义 immersive.full 同时隐藏 immersive.status 隐藏状态栏 immersive.navigation 隐藏导航栏 immersive.preconfirms ? 这些键对应的值可则如下值用逗号组合: value 含义 apps 所有应用 * 所有界面 packagename 指定应用 -packagename 排除指定应用 举例:adb shell settings put global policy_control immersive.full=* 表示设置在所有界面下都同时隐藏状态栏和导航栏。 举例:adb shell settings put global policy_control immersive.status=com.package1,com.package2:immersive.navigation=apps,-com.package3 表示设置在包名为 com.package1 和 com.package2 的应用里隐藏状态栏,在除了包名为 com.package3 的所有应用里隐藏导航栏。 恢复正常模式:adb shell settings put global policy_control null 实用功能: 截图保存到电脑:adb exec-out screencap -p > sc.png 然后将 png 文件导出到电脑:adb pull /sdcard/sc.png 录制屏幕:录制屏幕以 mp4 格式保存到 /sdcard:adb shell screenrecord /sdcard/filename.mp4 需要停止时按 Ctrl-C,默认录制时间和最长录制时间都是 180 秒。 如果需要导出到电脑:adb pull /sdcard/filename.mp4 挂载、查看连接过的 WiFi 密码、开启/关闭 WiFi、设置系统日期和时间都需要root权限,不做多说。 使用 Monkey 进行压力测试:Monkey 可以生成伪随机用户事件来模拟单击、触摸、手势等操作,可以对正在开发中的程序进行随机压力测试。 简单用法:adb shell monkey -p < packagename > -v 500 表示向 指定的应用程序发送 500 个伪随机事件。 查看进程:adb shell ps 查看实时资源占用情况:adb shell top 查看进程 UID:adb shell dumpsys package | grep userId=

问问小秘 2020-04-29 15:55:55 0 浏览量 回答数 0

问题

服务器急救

fuwuqi1 2019-12-01 21:29:02 1556 浏览量 回答数 1

问题

【Java问答学堂】9期 es 写入数据的工作原理是什么啊?es 查询数据的工作原理是什么啊?

剑曼红尘 2020-04-27 14:35:38 0 浏览量 回答数 1

问题

在服务器上排除问题的头五分钟

五弊三缺 2019-12-01 21:41:11 9114 浏览量 回答数 1

问题

ES 写入数据的工作原理是什么啊?ES 查询数据的工作原理是什么啊?【Java问答学堂】27期

剑曼红尘 2020-05-27 20:28:45 22 浏览量 回答数 1

回答

先说结论: 不要对接!不要对接!不要对接! 开个玩笑,以上仅代表个人观点,大家也知道这种“三体式警告”根本没有用的,我自己也研究如何对接,说不定做完后就觉得“真香”了。 为什么要对接? 首先讨论一下为什么要把 Flutter 对接到 Web 生态。 Flutter 现在是一个炙手可热的跨平台技术,能够一套代码运行在 Android、iOS、PC、IoT 以及浏览器上,被认为是下一代跨平台技术。相比于 Weex 和 React Native 可以很好地解决多平台一致性问题,原生渲染性能相近,上层没有 JS 那么厚的封装层次,整体性能会略好一些。 但是大部分兴冲冲去学 Flutter 的人疑惑的第一个问题就是:为什么 Flutter 要用 Dart?一个全新的语言意味着新的学习成本,难道 JS 不香吗?JS 不香不是还有 TypeScript 吗!事实上 Flutter 抛弃的岂止是 JS 这门语言,也抛弃了 HTML 和 CSS,设计了一套解耦得更好的 Widget 体系,Flutter 抛弃的是整个 Web,致力于打造一个新的生态,但是这个生态无法复用 Web 生态的代码和解决方案。尤其是之前所有跨平台方案 Hybrid、React Native、Weex 都是对接 Web 生态的,这让 Flutter 显得有些格格不入,也让大部分前端开发者望而却步。 下面是我整理出来的,前端开发者使用 Flutter 的各方面成本: 因为 Flutter 的开发模式和前端框架比较像(可以说就是抄的 React),所以框架的学习成本并不高,稍微高一些的是 Dart 语言的学习成本,另外还要学习如何用 Widget 组装 UI,虽然很多布局 Widget 设计得和 CSS 很像,灵活度还是差了很多。要想在真实项目中用起来,还要改造整个工具链,以“Native First”的视角做开发,开发 Flutter 和开发原生应用的链路是比较像的,和开发前端页面有较大差异。最高的还是生态成本,前端生态的积累无论是代码还是技术方案都很难复用,这是最痛的一点,生态也是 Flutter 最弱的一环。 无论是为了先进的技术理念还是出于商业私心,先不管 Flutter 为什么抛弃 Web 生态,现实问题是最大的 UI 开发者群体是前端,最丰富的生态是 Web 生态,我觉得 Web 技术也是开发 UI 最高效的方式。如果能在上层使用 Web 技术栈开发,在底层使用 Flutter 实现跨平台渲染,不是可以很好的兼顾开发效率、性能和跨平台一致性吗?还能复用 Web 技术栈大量的技术积累。 可能这些理由也不够充分,暂且先照着这个假设继续分析,最后再重新讨论到底该不该对接。 关于 Flutter 和 Web 生态的对接涉及两个方面: 从 Web 到 Flutter。就是使用 Web 技术栈来开发,然后对接到 Flutter 上实现跨平台渲染。对 Web 来说是解决性能和跨平台一致性问题,对 Flutter 来说是解决生态复用问题。从 Flutter 到 Web。就是官方已经实现的 Web support for Flutter,把已经用 Dart 开发好的 App 编译成 HTML/JS/CSS 然后运行在浏览器上,可以用于降级和外投场景。 如何实现“从 Web 到 Flutter”? 首先分析一下 Flutter 的架构图,看看可以从哪里下手。 Flutter 可以分为 Framework 和 Engine 两部分,Engine 部分比较底层也比较稳定了,最好不要动,需要改的是用 Dart 实现的 Framework。要想对接 Web 生态的话,JS 引擎肯定是要引入的,至于是否保留 Dart VM 有待讨论。图中最上面 Material 和 Cupertino 两个 UI 库前端是不需要的,前端有自己的。关键是 Widget 这部分,是替换成 HTML/CSS 的方式写 UI,还是继续保留 Widget 但是把语言换成 JS,不同方案给出的解法也不一样。 有不少方案可以实现对接,业界有挺多尝试的,我总结了下面三种方式: - TS 魔改:用 JS 引擎替换掉 Dart VM,用 JS/TS 重新实现 Flutter Framework(或者直接 dart2js 编译过来)。 - JS 对接:引入 JS 引擎同时保留 Dart VM,用前端框架对接 Flutter Framework。 - C++ 魔改:用 JS 引擎替换掉 Dart VM,用 C++ 重新实现 Flutter Framework。 TS 魔改 TS 魔改就是完全抛弃掉 Dart VM,用 TypeScript 重新实现一遍用 Dart 写的 Flutter Framework。 为啥是 TS 而不是 JS?这不是因为 TS 是个大热门嘛,而且向下兼容 JS,现在几乎所有时髦的框架都要用 TS 重写了。 这种方案的出发点是“如果能把 Flutter 的 Dart 换成 JS 就好了”,最容易想到的路就是把 Dart 翻译成 TS,或者直接用 dart2js 把代码编译成 js,但是编译出来的代码包含很多 dart:ui 之类的库的封装,生成的包也挺大的,也比较难定制需要导出的接口,不如干脆用 TS 重写一遍,工具链更熟悉一些,还可以加一些定制。 理论上讲翻译之后 Flutter 绝大部分功能都依然支持,可以复用各种 npm 包,还可以动态化,但是丧失了 AOT 能力,JS 语言的执行性能应该是不如 Dart 的。而且所有节点的布局运算都发生在 JS,底层只需要提供基础的图形能力就好了,就好像是基于 Canvas API 写了一套 UI 框架,性能未必有现存前端框架的性能高。 此外最大的问题是如何与官方 Flutter 保持一致,假如现在是从 v1.13 版本翻译过来的,以后官方升级到了 v1.15 要不要同步更新?这个过程没啥技术含量,而且需要持续投入,做起来比较恶心。 另外还需要考虑上层是用 Widget 的方式写 UI,还是用前端熟悉的 HTML+CSS。如果依然用 Widget 的话,那大部分前端组件还是用不了的,UI 还是得重写一遍。反正要重写的话,成本也没降下来,那就用 Dart 重写呗…… 直接用官方原版 Flutter 也避免每次更新都要翻译一遍 Dart 代码。所以既然选择了对接前端生态,那就要对接 CSS,不然就没有足够的价值。然而 CSS 和 Widget 的对接也是很繁琐的过程,而且存在完备性问题。 JS 对接 翻译代码的方式不够优雅,那就保留 Dart,把 JS/CSS 对接到 Widget 上面不就好了? 当然可以,这种方式是仅把 Flutter 当做了底层的渲染引擎,上层保持前端框架的写法,仅把渲染部分对接到 Flutter。现存的很多前端框架都把底层渲染能力做了抽象,可以对接到不同渲染引擎上,如 Vue/Rax 同时支持浏览器和 Weex,用同样的方式,可以再支持一个 Flutter。 这种方式对前端框架的兼容性比较好,但是链路太长了,业务代码调用前端框架接口做渲染,一顿操作之后发出了渲染指令,这个渲染指令要基于通信的方式传给 Flutter Framework,这中间涉及一次 JS 到 C++ 再到 Dart 的跨语言转换,然后再接收到渲染指令之后还要转成相应的 Widget 树,从 CSS 到 Widget 的转换依然很繁琐。而且 Widget 本身是可以带有状态的,本身就是响应式更新的,在更新时会重新生成 widget 并 diff,如果在前端更新 UI 的话,前端框架在 js 里 diff 一次 vdom,传到 Flutter 之后又 diff 一次 widget。 如果要绕过 Widget 直接对接图中的 Rendering 这一层,可以绕过 widget diff 但是得改 Flutter Framework 的渲染链路,既然要改 Flutter Framework 那为什么不直接用 TS 魔改呢,还绕过了 JS 到 Dart 的通信,又回到了第一种方案。 总结来说,这个方案的优点是:实现简单、能最大化保留前端开发体验,缺点是:渲染链路长、通信成本高、响应式逻辑冲突、CSS 转 Widget 不完备等。 C++ 魔改 想要干掉 Dart VM,就需要用其他语言重新实现用 Dart 开发的 Framework,用 JS/TS 可以,用 C++ 当然可以,最硬核的方式就是用 C++ 重新实现 Flutter 的 Framework,然后接入 JS 引擎,通过 binding 把 C++ 接口透出到 JS 环境,上层应用还是用 JS 做开发。 把 Framework 层下沉到 C++ 之后,不仅会有更好的性能,也能支持更多语言。原本 Flutter Framework 是在 Dart VM 之上的,必须依赖 Dart VM 才能运行,所以对 Dart 有强依赖;用 C++ 重新实现之后,JS 引擎是在 C++ 版 Framework 之上的,框架本身并不依赖 JS 引擎,还可以对接其他各种语言,如对接了 JVM 之后可以支持 Java 和 Kotlin,对接回 Dart VM 可以继续支持 Dart。 这个方案可以增强性能,也能保持和 Flutter 的一致性,但是改造成本和维护成本都相当高。C++ 的开发效率肯定不如 Dart,当 Flutter 快速迭代之后如何跟进是很大的问题,如果跟进不及时或者实现不一致那很可能就分化了。从 CSS 到 Widget 的转换也是不得不面对的问题。 几种方案对比 把上面几种方案画在同一张图里是这个样子的: 图中实线部分表示了跨语言的通信,太过频繁会影响性能,虚线部分表示了其他对接可能性。 从下到上,Flutter Engine 是不需要动的,这一层是跨平台的关键。Framework 则有三种语言版本,JS/TS、Dart、C++,性能是 C++ 版本最好,成本是 Dart 版本最低。然后还需要向上处理 HTML/CSS 和 Widget 的问题,可以直接对接一个前端框架,也可以直接在 C++ 层实现(不然需要透出的 binding 接口就太多了,用通信的方式也太过频繁了)。 如何实现“从 Flutter 到 Web”? 这个功能官方已经实现了,可以把使用 Dart 开发的 App 编译成 Web App 运行在浏览器上,官方文档以介绍用法和 API 为主,我这里简单分析一下内部具体的实现方案。 实现原理 结合 Flutter 的架构图来看,要实现 Web 到 Flutter 需要改造的是上层 Framework,要实现 Flutter 到 Web 需要改造的则是底层 Engine。 Framework 对 Engine 的核心依赖是 dart:ui,这是库是在 Engine 里实现的,抽象出了绘制 UI 图层的接口,底层对接 skia 的实现,向上透出 Dart 语言的接口。这样来看,对接方式就比较简单了: 使用 dart2js 把 Framework 编译成 JS 代码。基于浏览器的 API 重新实现 dart:ui,即 dart:web_ui。 把 Dart 编译成 JS 没什么问题,性能可能会有一点影响,功能都是可以完全保留的,关键是 dart:web_ui 的实现。在原生 Engine 中,dart:ui 依赖 skia 透出的 SkCanvas 实现绘制,这是一套很底层的图形接口,只定义了画线、画多边形、贴图之类的底层能力,用浏览器接口实现这一套接口还是很有挑战的。上图可以看到 Web 版 Engine 是基于 DOM 和 Canvas 实现的,底层定义了 DomCanvas 和 BitmapCanvas 两种图形接口,会把传来的 layer tree 渲染成浏览器的 Element tree,但是节点上仅包含了 position, transform, opacity 之类的样式,只用到 CSS 很小的一个子集,一些更复杂的绘制直接用 2D canvas 实现。 存在的问题 我编译了一个还算复杂的 demo 试了一下,性能很不理想,滑动不流畅,有时候图片还会闪动。生成出来的 js 代码有 1.1MB (minify 之后,未 gzip),节点层次也比较深,我评估这个页面用前端写不会超过 300KB,节点数可以少一半以上。 另外再看一下 Flutter 仓库的 issue,过滤出 platfrom-web 相关的,可以看到大量:文字编辑失效、找不到光标、ListView 在 ios 上不可滚动、checkbox/button 行为不正常、安卓滚动卡顿图片闪烁、字体失效、某些机型视频无法播放、文字选中后无法复制、无法调试…… 感觉 flutter for web 已经陷入泥潭,让人回想起前端当年处理各种浏览器兼容性的噩梦。 这些性能和兼容性问题,核心原因是浏览器未暴露足够的底层能力,以及浏览器处理手势、用户输入和方式和 Flutter 差异巨大。 实现 Flutter Engine 需要的是底层的图形接口和系统能力,虽然canvas 提供了相似的图形接口,如果全部用 canvas 实现的话很难处理可访问性、文本选择、手势、表单等问题,也会存在很多兼容性问题。所以真实方案里用的是 Canvas + DOM 混合的方式,封装层次太高了,渲染链路太长。就好像 Flutter Framework 里进行了一顿猛如虎的操作之后,节点生成好了、布局算好了、绘制属性也处理好了,就差一个画布画出来了,然后交到浏览器手里,又生成一遍 Element,再算一遍布局,在处理一遍绘制,最终才交给了底层的图形库画出来。 再比如长页面的滚动,浏览器里只要一条 CSS (overflow:scroll) 就可以让元素可滚动,手势的监听以及页面的滚动以及滚动动画都是浏览器原生实现的,不需要与 JS 交互,甚至不需要重新 layout 和 paint,只需要 compositing。如上图所示,在 Flutter 中 Animation 和 Gesture 是用 Dart 实现的,编译过来就是 JS 实现的,浏览器本身并不知道这个元素是否可滚,只是不断派发 touchmove 事件,JS 根据事件属性计算节点偏移,然后运算动画,然后把 transform 或者新的 position 作用到节点上,然后浏览器再来一遍完整的渲染流程…… 优化方案 性能和兼容性的问题还是要解决的,短期内先把 issue 解掉,长线的优化方案,官方有两种尝试: 使用 CSS Painting API 做绘制。 a, 这是还处于提案状态的新标准,可以用 JS 实现一些绘制功能,自定义 CSS 属性。 b. 目前还未实现,需要等浏览器先把 CSS Houdini 支持好。 使用 WebAssembly 版本的 Skia 做绘制 https://skia.org/user/modules/canvaskit a, 这样可以发挥 wasm 的性能优势,并且保持 skia 功能的一致。但是目前 wasm 在浏览器环境里未必有性能优势,这里不展开讨论了。 b. 已经部分实现,参考这里的配置启用功能: https://github.com/flutter/flutter/issues/41062#issuecomment-533952994 这两个方案都是想更多的利用到浏览器的底层能力,只有浏览器暴露了更多底层能力,才能更好的实现 Flutter 的 Web Engine。不过这个要等挺久的时间,我们也参与不了,现阶段想要使用 flutter for web,还是得保持现有架构,一起参与进去把 issue 解决掉,优先保障功能,其次优化性能。 一种适应性更好的架构 如果理想化一点,能不能从架构角度让 Flutter 和 Web 生态融合的更好一些呢? 回顾文章最开始的官方架构图,上面是 Framework(Dart),下面是 Engine(C++),切分在 Foundation 这一层,双方之间的交互是几何图形信息。如果还保持这个架构,把切分层次划分的更靠上一些,如下图所示,划分在 Widgets 和 Rendering 这一层,理论上讲对 Flutter 的开发者来说是无感知的,因为上层的开发语言和 Widget 接口都是不变的。 切分在这一层,Framework 和 Engine 之间的交互就不再是几何图形而是节点信息,Widget 的组合、setState 响应式更新、Widget diff 都还在 Dart 中,展开后的 RenderObject 的布局、绘制、裁剪、动画全都在 C++ 中,不仅有更好的性能,还可以与 Engine 有更好的结合。 或者说,还原本保留 Engine 的设计,把下沉的这部分逻辑上划分成 Renderer,就有了如下三层的结构: 这样划分出来的每一层都有明确的定位: Framework: 开发框架。为开发者提供可编程 API,实现响应式的开发模式,提供细粒度 Widget 供开发者自由封装和组合。Renderer: 渲染引擎。专门实现布局、绘制、动画、手势的的处理,这部分功能相对独立,是可以与开发框架解耦的,也不必与特定语言绑定。Engine: 图形引擎。实现跨平台一致的图形接口,合成输入的层并绘制到屏幕上,处理好平台力的接入和适配。 这样切分除了有性能优势以外,也使得渲染引擎摆脱了对 Dart 的依赖,能够支持多种语言,也能支持多种开发模式。对接到 Dart VM 就可以用 Dart 写代码,对接到 JS 引擎就可以用 JS 写代码,对接到 JVM 还可以写 Java,但是无论怎么写,底层的渲染能力是一样的,一套统一的布局算法,动画和手势的处理行为也是一致的。 在这样的架构下,对接 Web 生态就更容易了。Dart 和 Widget 是前端不想要的,希望能换成 JS 和 CSS,但是又想要底层的跨平台一致渲染引擎,那从 Renderer 层开始对接就好了,绕过了所有不想要的,也保留了所有想要的。 要实现 Flutter for Web 也更简单了一些。在 Engine 层做对接,一直苦于浏览器透出的底层能力不够,如果是在 Renderer 之上做对接就更容易一些,基于 JS/CSS/DOM/Canvas 的能力封装出一套 Rendering 接口,供 Widget 调用就好了,这样可以使渲染链路更短一些,但是依然要处理 Widget 和 DOM/CSS 之间的兼容性问题。 再讨论一遍:为什么要对接? 技术上已经分析完了,要想搞定 Flutter 生态和 Web 生态的对接,需要投入很大的成本,所以真正决定做之前,要先讨论清楚为什么要做对接?到底要不要做对接? 首先 Google 官方对 Flutter 的定位就是个问题。Flutter 设计之初就是不考虑 Web 生态的,甚至在刻意回避,倡导的是更贴近原生的开发方式。我之所以在开头说不要对接,原因也很简单:两种技术设计理念不同,不是朝着一个方向发展的,生态不通,技术方案不通,强行融合很可能让彼此都丧失了优势。但是业界又有很多团队在做这种尝试,说明需求是存在的,如果 Google 抵制这个方向,那就不好做了。不过现在官方已经支持了 Flutter for Web,已经向 Web 生态迈了一步,未来是否进一步与 Web 融合,也是有可能的。 另外就是跨平台技术本身的问题,浏览器发展了二三十年,已经是个很强大的跨平台产品了,几乎是 Web 的代名词了,这一点无人能敌。但是也臃肿不堪,有大量历史包袱,性能和体验不够好,和 Native 的结合度差,尤其在移动和 IoT 平台。虽然硬件性能在不断提升,但这是所有软件共享的,浏览器的性能和体验总会比 Native 差一些,差的这一些很可能就是新业务和新场景的发挥空间。观察一下近几年新诞生的业务场景,很多都是利用到了 Native 新提供的能力才火爆起来的,如 AI/AR/ 视频 / 直播 等,有因为新的 Web API 而孵化生出来的商业模式吗? 原文链接: https://mp.weixin.qq.com/s?__biz=MzAxNDEwNjk5OQ==&mid=2650405725&idx=1&sn=0b7476f7c7c01df7fdafda578f9ceb98&chksm=83953345b4e2ba53917ac30b709c07be15bd1c2fd5ae2a8ecfbb129b3813f771621b8fac95ca&scene=27#wechat_redirect

剑曼红尘 2020-03-10 09:54:40 0 浏览量 回答数 0

问题

SSH面试题

琴瑟 2019-12-01 21:46:22 3489 浏览量 回答数 0

问题

【CSS学习全家桶】416道CSS热门问题,阿里百位技术专家答疑解惑

管理贝贝 2019-12-01 20:07:24 8458 浏览量 回答数 1
阿里云大学 云服务器ECS com域名 网站域名whois查询 开发者平台 小程序定制 小程序开发 国内短信套餐包 开发者技术与产品 云数据库 图像识别 开发者问答 阿里云建站 阿里云备案 云市场 万网 阿里云帮助文档 免费套餐 开发者工具 企业信息查询 小程序开发制作 视频内容分析 企业网站制作 视频集锦 代理记账服务 企业建站模板