• 关于 线上算法问题怎么解决 的搜索结果

问题

《公交线路客流预测》攻略-附平台mr示例代码

楠兮 2019-12-01 21:31:10 16683 浏览量 回答数 5

问题

【精品问答】大数据计算技术1000问

问问小秘 2019-12-01 21:57:13 3431 浏览量 回答数 1

回答

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

问题

比赛_快速入门_4_19_update_仅供参考,思维不要受局限

小斯never 2019-12-01 21:43:08 30563 浏览量 回答数 24

问题

2018python技术问答集锦,希望能给喜欢python的同学一些帮助

技术小能手 2019-12-01 19:31:10 2040 浏览量 回答数 2

回答

Re【马甲问题】马甲账号清除公告 以前某社交公司查mj,就是用登陆浏览器比对。比对下登陆提交的浏览器地址,就全查出来了。 对于文本内容的比对感觉作用不大,我想过和别的组的尝试合并提交,只多出来200个提交。 ------------------------- Re【马甲问题】马甲账号清除公告 不过说句实在话,参加这么多竞赛过来,我还是第一次看到竞赛主办方用查mj的方式来抑制选手调参数过拟合训练数据集的。在最后一周更改测试集才是通用的做法吧。 我个人来说,同一策略线下验证集调好参数后,线上不会改参数超过两次,也是担心太过拟合,第二赛季就傻了。 ------------------------- Re【马甲问题】马甲账号清除公告 恩,看到规则了,话说第一季我觉得这样做可能比较好:训练集不变,然后测试集800个人随机抽样400个人作为平时的leadership排名,最后评测的时候用剩下400个人。这样刷小号也没意义了。 (突然想到回去后要跟我实验室的其他队伍说一声。。。以后LR调好W后别用我那个python脚本生成提交数据了。。。免得被当小号处理了omg ------------------------- 回22楼jiajiadidi的帖子 你不是改个参数几个队一起刷的话应该还好吧 我当初就觉得这样不好,后面多半要出乱子。浙大宣讲问主办方,现在这种情况,几条简单规则就能刷到6,我要是把这几条简单的规则告诉别人,那别人不都挤到前面,那赛季1不就没意义了?然后还有mj的问题。 宣讲的老师说,那你觉得现在极限是多少呢?是7么。mj这种问题都是小问题 后来算者说得好,规则确实能做得比较好,怎么结合规则做出更好的模型才是王道,模型不如规则只能说模型做的不够好。这个对我影响还蛮大的,也让我好好反思了一下。 我现在靠LR做到6.8,基本也没做规则了,而是想如何用以前淘宝有个做CTR预估的MLR的思路结合商品类目和用户定向做更好的结合规则的LR。 我把我python工程环境也发给同实验室的其他组了,在我基础上也有比我做的更高的,具体来说也没太问。 今天回贴,也是看到这种情况有所感想。 大家去刷规则,把推荐大赛做成overfitting大赛,这样对于自己的提高,或是解决这个实际问题,这样有意义么?我是觉得没有意义的。 跟我用同一体系方法的几个队,现在基本都做到6.9 6.8了,大家还是把精力更多放在了如何做更好的模型上。 想想最初学的PAC,一个模型如何叫好,train error低,并且train error近似于test error。这样我们才能声称自己的模型学习到了真正的target function f。而目前大家凭着test 来不断调整参数,就算把f1做到天上去,自己的模型只能说train error低了,大赛后也是毫无意义的。算法学到的那个function,也最多只能当作笑谈 看到有置顶,真是受宠若惊了。帖子里面说的MLR,是盖坤/靖世在阿里技术沙龙中分享的《海量数据下的非线性模型探索 》http://club.alibabatech.org/resource_detail.htm?topicId=106 。这个ppt非常好,我也学到不少。 顺便说说的是,在这个比赛中,我也确实学到不少。 以前我在做项目的时候,基本是对算法非常迷信的,关系好的豆瓣算法组的一个人批我机器学习理解不成熟,太喜欢炫技,我也左耳朵进右耳朵出。最近做某公司的推荐项目,我基本想都不想,就要上time SVD++做baseline,对数据也基本不做太多分析,对业务也是不屑一顾的,非常依赖feature selection算法以及高维非线性模型。 在以前kdd cup或者recsys等比赛中,也是直接上定制化的SVD,把所有数据建模在一个式子里跑SGD草草完事。 做阿里比赛最开始我也是没做太多数据分析,直接上的implicit feedback,sigmoid处理正负反馈,time SVD++以及各种复杂的处理方式。与其说是解决问题,不如是说炫技。当然结果也非常惨,只有4%。 后来才开始认真思考这个比赛的问题。品牌推荐和普通推荐到底有什么区别?打个比方,用户在一个月后会看自己以前有交互的电影的只有1%。而用户在一个月后会买自己以前有交互的品牌的却有20%。CF着力的是那没有交互行为的80%的品牌。除此外800用户,对用户的factor的估计,还是加入temporal dynamic稀释的,又能有多准呢? 所以除了算者说的那些点外,光就这一点基本就可以判定CF在赛季1的不适合了。 这样的问题,只要好好想想就能想通的,可笑的是我第一二周还在所谓的“巧妙模型”上花费了大量的力气。这个让我反思了很久。 用我室友说我的,便是我太迷信算法了,瞧不起用excel写统计的,也瞧不起做简单数据分析然后跑简单模型的人。 这便是我在比赛中获得的教训,也是我和我同实验室的朋友在回家路上所总结的。 说实在,这个比赛我也没有太多精力参加,赛季二估计也只能每周花1天来做,毕竟实验室项目太多。所以估计最后也拿不到特别好的名次。但我觉得,这次比赛前几周给我带来的教训,便已经让我非常有收获了,至少我现在对于机器学习算法以及业务关系的理解,和比赛前已经有了很大的不同。 我现在是单挑,考虑到赛季2最近也找了一个队友,他貌似有两个小号。我也给他发短信让他回学校后赶快发邮件把这些号注销了并入我的队,毕竟也算占着前500的坑,注销了也让更多的队能进入前500。也希望其他队的朋友也再接再厉,在比赛中真正得到一些领悟和经验。愿大家都能做出更好的推荐,进一步加深对机器学习的理解 ^_^ 顺便给大家讲个竞赛的小段子开心开心=w= “阿里的比赛,有个学弟找我合了下数据,做到38名。他觉得很开心,就跟他导师说了。他导师说,才38名啊,做不到前3名就别参加竞赛丢他脸。听到这事我当时就呵呵了,you can you up,no can no bb。我导师就好多了,他要是知道我在做竞赛而不干活,不管几名肯定把我剁了。”

懒惰啊我 2019-12-02 02:59:50 0 浏览量 回答数 0

问题

【精品问答】大数据技术问题之Flink百问

问问小秘 2019-12-01 21:59:43 7280 浏览量 回答数 1

回答

在开始谈我对架构本质的理解之前,先谈谈对今天技术沙龙主题的个人见解,千万级规模的网站感觉数量级是非常大的,对这个数量级我们战略上 要重 视 它 , 战术上又 要 藐 视 它。先举个例子感受一下千万级到底是什么数量级?现在很流行的优步(Uber),从媒体公布的信息看,它每天接单量平均在百万左右, 假如每天有10个小时的服务时间,平均QPS只有30左右。对于一个后台服务器,单机的平均QPS可以到达800-1000,单独看写的业务量很简单 。为什么我们又不能说轻视它?第一,我们看它的数据存储,每天一百万的话,一年数据量的规模是多少?其次,刚才说的订单量,每一个订单要推送给附近的司机、司机要并发抢单,后面业务场景的访问量往往是前者的上百倍,轻松就超过上亿级别了。 今天我想从架构的本质谈起之后,希望大家理解在做一些建构设计的时候,它的出发点以及它解决的问题是什么。 架构,刚开始的解释是我从知乎上看到的。什么是架构?有人讲, 说架构并不是一 个很 悬 乎的 东西 , 实际 上就是一个架子 , 放一些 业务 和算法,跟我们的生活中的晾衣架很像。更抽象一点,说架构其 实 是 对 我 们 重复性业务 的抽象和我 们 未来 业务 拓展的前瞻,强调过去的经验和你对整个行业的预见。 我们要想做一个架构的话需要哪些能力?我觉得最重要的是架构师一个最重要的能力就是你要有 战 略分解能力。这个怎么来看呢: 第一,你必须要有抽象的能力,抽象的能力最基本就是去重,去重在整个架构中体现在方方面面,从定义一个函数,到定义一个类,到提供的一个服务,以及模板,背后都是要去重提高可复用率。 第二, 分类能力。做软件需要做对象的解耦,要定义对象的属性和方法,做分布式系统的时候要做服务的拆分和模块化,要定义服务的接口和规范。 第三, 算法(性能),它的价值体现在提升系统的性能,所有性能的提升,最终都会落到CPU,内存,IO和网络这4大块上。 这一页PPT举了一些例子来更深入的理解常见技术背后的架构理念。 第一个例子,在分布式系统我们会做 MySQL分 库 分表,我们要从不同的库和表中读取数据,这样的抽象最直观就是使用模板,因为绝大多数SQL语义是相同的,除了路由到哪个库哪个表,如果不使用Proxy中间件,模板就是性价比最高的方法。 第二看一下加速网络的CDN,它是做速度方面的性能提升,刚才我们也提到从CPU、内存、IO、网络四个方面来考虑,CDN本质上一个是做网络智能调度优化,另一个是多级缓存优化。 第三个看一下服务化,刚才已经提到了,各个大网站转型过程中一定会做服务化,其实它就是做抽象和做服务的拆分。第四个看一下消息队列,本质上还是做分类,只不过不是两个边际清晰的类,而是把两个边际不清晰的子系统通过队列解构并且异步化。新浪微博整体架构是什么样的 接下我们看一下微博整体架构,到一定量级的系统整个架构都会变成三层,客户端包括WEB、安卓和IOS,这里就不说了。接着还都会有一个接口层, 有三个主要作用: 第一个作用,要做 安全隔离,因为前端节点都是直接和用户交互,需要防范各种恶意攻击; 第二个还充当着一个 流量控制的作用,大家知道,在2014年春节的时候,微信红包,每分钟8亿多次的请求,其实真正到它后台的请求量,只有十万左右的数量级(这里的数据可能不准),剩余的流量在接口层就被挡住了; 第三,我们看对 PC 端和移 动 端的需求不一样的,所以我们可以进行拆分。接口层之后是后台,可以看到微博后台有三大块: 一个是 平台服 务, 第二, 搜索, 第三, 大数据。到了后台的各种服务其实都是处理的数据。 像平台的业务部门,做的就是 数据存储和读 取,对搜索来说做的是 数据的 检 索,对大数据来说是做的数据的 挖掘。微博其实和淘宝是很类似 微博其实和淘宝是很类似的。一般来说,第一代架构,基本上能支撑到用户到 百万 级别,到第二代架构基本能支撑到 千万 级别都没什么问题,当业务规模到 亿级别时,需要第三代的架构。 从 LAMP 的架构到面向服 务 的架构,有几个地方是非常难的,首先不可能在第一代基础上通过简单的修修补补满足用户量快速增长的,同时线上业务又不能停, 这是我们常说的 在 飞 机上 换 引擎的 问题。前两天我有一个朋友问我,说他在内部推行服务化的时候,把一个模块服务化做完了,其他部门就是不接。我建议在做服务化的时候,首先更多是偏向业务的梳理,同时要找准一个很好的切入点,既有架构和服务化上的提升,业务方也要有收益,比如提升性能或者降低维护成本同时升级过程要平滑,建议开始从原子化服务切入,比如基础的用户服务, 基础的短消息服务,基础的推送服务。 第二,就是可 以做无状 态 服 务,后面会详细讲,还有数据量大了后需要做数据Sharding,后面会将。 第三代 架构 要解决的 问题,就是用户量和业务趋于稳步增加(相对爆发期的指数级增长),更多考虑技术框架的稳定性, 提升系统整体的性能,降低成本,还有对整个系统监控的完善和升级。 大型网站的系统架构是如何演变的 我们通过通过数据看一下它的挑战,PV是在10亿级别,QPS在百万,数据量在千亿级别。我们可用性,就是SLA要求4个9,接口响应最多不能超过150毫秒,线上所有的故障必须得在5分钟内解决完。如果说5分钟没处理呢?那会影响你年终的绩效考核。2015年微博DAU已经过亿。我们系统有上百个微服务,每周会有两次的常规上线和不限次数的紧急上线。我们的挑战都一样,就是数据量,bigger and bigger,用户体验是faster and faster,业务是more and more。互联网业务更多是产品体验驱动, 技 术 在 产 品 体验上最有效的贡献 , 就是你的性能 越来越好 。 每次降低加载一个页面的时间,都可以间接的降低这个页面上用户的流失率。微博的技术挑战和正交分解法解析架构 下面看一下 第三代的 架构 图 以及 我 们 怎么用正交分解法 阐 述。 我们可以看到我们从两个维度,横轴和纵轴可以看到。 一个 维 度 是 水平的 分层 拆分,第二从垂直的维度会做拆分。水平的维度从接口层、到服务层到数据存储层。垂直怎么拆分,会用业务架构、技术架构、监控平台、服务治理等等来处理。我相信到第二代的时候很多架构已经有了业务架构和技术架构的拆分。我们看一下, 接口层有feed、用户关系、通讯接口;服务层,SOA里有基层服务、原子服务和组合服务,在微博我们只有原子服务和组合服务。原子服务不依赖于任何其他服务,组合服务由几个原子服务和自己的业务逻辑构建而成 ,资源层负责海量数据的存储(后面例子会详细讲)。技 术框架解决 独立于 业务 的海量高并发场景下的技术难题,由众多的技术组件共同构建而成 。在接口层,微博使用JERSY框架,帮助你做参数的解析,参数的验证,序列化和反序列化;资源层,主要是缓存、DB相关的各类组件,比如Cache组件和对象库组件。监 控平台和服 务 治理 , 完成系统服务的像素级监控,对分布式系统做提前诊断、预警以及治理。包含了SLA规则的制定、服务监控、服务调用链监控、流量监控、错误异常监控、线上灰度发布上线系统、线上扩容缩容调度系统等。 下面我们讲一下常见的设计原则。 第一个,首先是系统架构三个利器: 一个, 我 们 RPC 服 务组 件 (这里不讲了), 第二个,我们 消息中 间 件 。消息中间件起的作用:可以把两个模块之间的交互异步化,其次可以把不均匀请求流量输出为匀速的输出流量,所以说消息中间件 异步化 解耦 和流量削峰的利器。 第三个是配置管理,它是 代码级灰度发布以及 保障系统降级的利器。 第二个 , 无状态 , 接口 层 最重要的就是无状 态。我们在电商网站购物,在这个过程中很多情况下是有状态的,比如我浏览了哪些商品,为什么大家又常说接口层是无状态的,其实我们把状态从接口层剥离到了数据层。像用户在电商网站购物,选了几件商品,到了哪一步,接口无状态后,状态要么放在缓存中,要么放在数据库中, 其 实 它并不是没有状 态 , 只是在 这 个 过 程中我 们 要把一些有状 态 的 东 西抽离出来 到了数据层。 第三个, 数据 层 比服 务层 更需要 设计,这是一条非常重要的经验。对于服务层来说,可以拿PHP写,明天你可以拿JAVA来写,但是如果你的数据结构开始设计不合理,将来数据结构的改变会花费你数倍的代价,老的数据格式向新的数据格式迁移会让你痛不欲生,既有工作量上的,又有数据迁移跨越的时间周期,有一些甚至需要半年以上。 第四,物理结构与逻辑结构的映射,上一张图看到两个维度切成十二个区间,每个区间代表一个技术领域,这个可以看做我们的逻辑结构。另外,不论后台还是应用层的开发团队,一般都会分几个垂直的业务组加上一个基础技术架构组,这就是从物理组织架构到逻辑的技术架构的完美的映射,精细化团队分工,有利于提高沟通协作的效率 。 第五, www .sanhao.com 的访问过程,我们这个架构图里没有涉及到的,举个例子,比如当你在浏览器输入www.sanhao网址的时候,这个请求在接口层之前发生了什么?首先会查看你本机DNS以及DNS服务,查找域名对应的IP地址,然后发送HTTP请求过去。这个请求首先会到前端的VIP地址(公网服务IP地址),VIP之后还要经过负载均衡器(Nginx服务器),之后才到你的应用接口层。在接口层之前发生了这么多事,可能有用户报一个问题的时候,你通过在接口层查日志根本发现不了问题,原因就是问题可能发生在到达接口层之前了。 第六,我们说分布式系统,它最终的瓶颈会落在哪里呢?前端时间有一个网友跟我讨论的时候,说他们的系统遇到了一个瓶颈, 查遍了CPU,内存,网络,存储,都没有问题。我说你再查一遍,因为最终你不论用上千台服务器还是上万台服务器,最终系统出瓶颈的一定会落在某一台机(可能是叶子节点也可能是核心的节点),一定落在CPU、内存、存储和网络上,最后查出来问题出在一台服务器的网卡带宽上。微博多级双机房缓存架构 接下来我们看一下微博的Feed多级缓存。我们做业务的时候,经常很少做业务分析,技术大会上的分享又都偏向技术架构。其实大家更多的日常工作是需要花费更多时间在业务优化上。这张图是统计微博的信息流前几页的访问比例,像前三页占了97%,在做缓存设计的时候,我们最多只存最近的M条数据。 这里强调的就是做系统设计 要基于用 户 的 场 景 , 越细致越好 。举了一个例子,大家都会用电商,电商在双十一会做全国范围内的活动,他们做设计的时候也会考虑场景的,一个就是购物车,我曾经跟相关开发讨论过,购物车是在双十一之前用户的访问量非常大,就是不停地往里加商品。在真正到双十一那天他不会往购物车加东西了,但是他会频繁的浏览购物车。针对这个场景,活动之前重点设计优化购物车的写场景, 活动开始后优化购物车的读场景。 你看到的微博是由哪些部分聚合而成的呢?最右边的是Feed,就是微博所有关注的人,他们的微博所组成的。微博我们会按照时间顺序把所有关注人的顺序做一个排序。随着业务的发展,除了跟时间序相关的微博还有非时间序的微博,就是会有广告的要求,增加一些广告,还有粉丝头条,就是拿钱买的,热门微博,都会插在其中。分发控制,就是说和一些推荐相关的,我推荐一些相关的好友的微博,我推荐一些你可能没有读过的微博,我推荐一些其他类型的微博。 当然对非时序的微博和分发控制微博,实际会起多个并行的程序来读取,最后同步做统一的聚合。这里稍微分享一下, 从SNS社交领域来看,国内现在做的比较好的三个信息流: 微博 是 基于弱关系的媒体信息流 ; 朋友圈是基于 强 关系的信息流 ; 另外一个做的比 较 好的就是今日 头 条 , 它并不是基于关系来构建信息流 , 而是基于 兴趣和相关性的个性化推荐 信息流 。 信息流的聚合,体现在很多很多的产品之中,除了SNS,电商里也有信息流的聚合的影子。比如搜索一个商品后出来的列表页,它的信息流基本由几部分组成:第一,打广告的;第二个,做一些推荐,热门的商品,其次,才是关键字相关的搜索结果。 信息流 开始的时候 很 简单 , 但是到后期会 发现 , 你的 这 个流 如何做控制分发 , 非常复杂, 微博在最近一两年一直在做 这样 的工作。刚才我们是从业务上分析,那么技术上怎么解决高并发,高性能的问题?微博访问量很大的时候,底层存储是用MySQL数据库,当然也会有其他的。对于查询请求量大的时候,大家知道一定有缓存,可以复用可重用的计算结果。可以看到,发一条微博,我有很多粉丝,他们都会来看我发的内容,所以 微博是最适合使用 缓 存 的系统,微博的读写比例基本在几十比一。微博使用了 双 层缓 存,上面是L1,每个L1上都是一组(包含4-6台机器),左边的框相当于一个机房,右边又是一个机房。在这个系统中L1缓存所起的作用是什么? 首先,L1 缓 存增加整个系 统 的 QPS, 其次 以低成本灵活扩容的方式 增加 系统 的 带宽 。想象一个极端场景,只有一篇博文,但是它的访问量无限增长,其实我们不需要影响L2缓存,因为它的内容存储的量小,但它就是访问量大。这种场景下,你就需要使用L1来扩容提升QPS和带宽瓶颈。另外一个场景,就是L2级缓存发生作用,比如我有一千万个用户,去访问的是一百万个用户的微博 ,这个时候,他不只是说你的吞吐量和访问带宽,就是你要缓存的博文的内容也很多了,这个时候你要考虑缓存的容量, 第二 级缓 存更多的是从容量上来 规划,保证请求以较小的比例 穿透到 后端的 数据 库 中 ,根据你的用户模型你可以估出来,到底有百分之多少的请求不能穿透到DB, 评估这个容量之后,才能更好的评估DB需要多少库,需要承担多大的访问的压力。另外,我们看双机房的话,左边一个,右边一个。 两个机房是互 为 主 备 , 或者互 为热备 。如果两个用户在不同地域,他们访问两个不同机房的时候,假设用户从IDC1过来,因为就近原理,他会访问L1,没有的话才会跑到Master,当在IDC1没找到的时候才会跑到IDC2来找。同时有用户从IDC2访问,也会有请求从L1和Master返回或者到IDC1去查找。 IDC1 和 IDC2 ,两个机房都有全量的用户数据,同时在线提供服务,但是缓存查询又遵循最近访问原理。还有哪些多级缓存的例子呢?CDN是典型的多级缓存。CDN在国内各个地区做了很多节点,比如在杭州市部署一个节点时,在机房里肯定不止一台机器,那么对于一个地区来说,只有几台服务器到源站回源,其他节点都到这几台服务器回源即可,这么看CDN至少也有两级。Local Cache+ 分布式 缓 存,这也是常见的一种策略。有一种场景,分布式缓存并不适用, 比如 单 点 资 源 的爆发性峰值流量,这个时候使用Local Cache + 分布式缓存,Local Cache 在 应用 服 务 器 上用很小的 内存资源 挡住少量的 极端峰值流量,长尾的流量仍然访问分布式缓存,这样的Hybrid缓存架构通过复用众多的应用服务器节点,降低了系统的整体成本。 我们来看一下 Feed 的存 储 架构,微博的博文主要存在MySQL中。首先来看内容表,这个比较简单,每条内容一个索引,每天建一张表,其次看索引表,一共建了两级索引。首先想象一下用户场景,大部分用户刷微博的时候,看的是他关注所有人的微博,然后按时间来排序。仔细分析发现在这个场景下, 跟一个用户的自己的相关性很小了。所以在一级索引的时候会先根据关注的用户,取他们的前条微博ID,然后聚合排序。我们在做哈希(分库分表)的时候,同时考虑了按照UID哈希和按照时间维度。很业务和时间相关性很高的,今天的热点新闻,明天就没热度了,数据的冷热非常明显,这种场景就需要按照时间维度做分表,首先冷热数据做了分离(可以对冷热数据采用不同的存储方案来降低成本),其次, 很容止控制我数据库表的爆炸。像微博如果只按照用户维度区分,那么这个用户所有数据都在一张表里,这张表就是无限增长的,时间长了查询会越来越慢。二级索引,是我们里面一个比较特殊的场景,就是我要快速找到这个人所要发布的某一时段的微博时,通过二级索引快速定位。 分布式服务追踪系统 分布式追踪服务系统,当系统到千万级以后的时候,越来越庞杂,所解决的问题更偏向稳定性,性能和监控。刚才说用户只要有一个请求过来,你可以依赖你的服务RPC1、RPC2,你会发现RPC2又依赖RPC3、RPC4。分布式服务的时候一个痛点,就是说一个请求从用户过来之后,在后台不同的机器之间不停的调用并返回。 当你发现一个问题的时候,这些日志落在不同的机器上,你也不知道问题到底出在哪儿,各个服务之间互相隔离,互相之间没有建立关联。所以导致排查问题基本没有任何手段,就是出了问题没法儿解决。 我们要解决的问题,我们刚才说日志互相隔离,我们就要把它建立联系。建立联系我们就有一个请求ID,然后结合RPC框架, 服务治理功能。假设请求从客户端过来,其中包含一个ID 101,到服务A时仍然带有ID 101,然后调用RPC1的时候也会标识这是101 ,所以需要 一个唯一的 请求 ID 标识 递归迭代的传递到每一个 相关 节点。第二个,你做的时候,你不能说每个地方都加,对业务系统来说需要一个框架来完成这个工作, 这 个框架要 对业务 系 统 是最低侵入原 则 , 用 JAVA 的 话 就可以用 AOP,要做到零侵入的原则,就是对所有相关的中间件打点,从接口层组件(HTTP Client、HTTP Server)至到服务层组件(RPC Client、RPC Server),还有数据访问中间件的,这样业务系统只需要少量的配置信息就可以实现全链路监控 。为什么要用日志?服务化以后,每个服务可以用不同的开发语言, 考虑多种开发语言的兼容性 , 内部定 义标 准化的日志 是唯一且有效的办法。最后,如何构建基于GPS导航的路况监控?我们刚才讲分布式服务追踪。分布式服务追踪能解决的问题, 如果 单一用 户发现问题 后 , 可以通 过请 求 ID 快速找到 发 生 问题 的 节 点在什么,但是并没有解决如何发现问题。我们看现实中比较容易理解的道路监控,每辆车有GPS定位,我想看北京哪儿拥堵的时候,怎么做? 第一个 , 你肯定要知道每个 车 在什么位置,它走到哪儿了。其实可以说每个车上只要有一个标识,加上每一次流动的信息,就可以看到每个车流的位置和方向。 其次如何做 监 控和 报 警,我们怎么能了解道路的流量状况和负载,并及时报警。我们要定义这条街道多宽多高,单位时间可以通行多少辆车,这就是道路的容量。有了道路容量,再有道路的实时流量,我们就可以基于实习路况做预警? 对应于 分布式系 统 的话如何构建? 第一 , 你要 定义 每个服 务节 点它的 SLA A 是多少 ?SLA可以从系统的CPU占用率、内存占用率、磁盘占用率、QPS请求数等来定义,相当于定义系统的容量。 第二个 , 统计 线 上 动态 的流量,你要知道服务的平均QPS、最低QPS和最大QPS,有了流量和容量,就可以对系统做全面的监控和报警。 刚才讲的是理论,实际情况肯定比这个复杂。微博在春节的时候做许多活动,必须保障系统稳定,理论上你只要定义容量和流量就可以。但实际远远不行,为什么?有技术的因素,有人为的因素,因为不同的开发定义的流量和容量指标有主观性,很难全局量化标准,所以真正流量来了以后,你预先评估的系统瓶颈往往不正确。实际中我们在春节前主要采取了三个措施:第一,最简单的就是有降 级 的 预 案,流量超过系统容量后,先把哪些功能砍掉,需要有明确的优先级 。第二个, 线上全链路压测,就是把现在的流量放大到我们平常流量的五倍甚至十倍(比如下线一半的服务器,缩容而不是扩容),看看系统瓶颈最先发生在哪里。我们之前有一些例子,推测系统数据库会先出现瓶颈,但是实测发现是前端的程序先遇到瓶颈。第三,搭建在线 Docker 集群 , 所有业务共享备用的 Docker集群资源,这样可以极大的避免每个业务都预留资源,但是实际上流量没有增长造成的浪费。 总结 接下来说的是如何不停的学习和提升,这里以Java语言为例,首先, 一定要 理解 JAVA;第二步,JAVA完了以后,一定要 理 解 JVM;其次,还要 理解 操作系统;再次还是要了解一下 Design Pattern,这将告诉你怎么把过去的经验抽象沉淀供将来借鉴;还要学习 TCP/IP、 分布式系 统、数据结构和算法。

hiekay 2019-12-02 01:39:25 0 浏览量 回答数 0

问题

程序员报错行为大赏-配置报错

问问小秘 2020-06-11 13:18:25 6 浏览量 回答数 1

问题

荆门开诊断证明-scc

游客5k2abgdj3m2ti 2019-12-01 22:09:00 1 浏览量 回答数 0

问题

详解递归 6月18日【今日算法】

游客ih62co2qqq5ww 2020-06-20 12:04:38 2 浏览量 回答数 0

问题

MaxCompute百问集锦

yq传送门 2019-12-01 20:16:47 2404 浏览量 回答数 1

问题

Apache Flink常见问题汇总【精品问答】

黄一刀 2020-05-19 17:51:47 28 浏览量 回答数 1

问题

【精品问答】Java技术1000问(1)

问问小秘 2019-12-01 21:57:43 24636 浏览量 回答数 7

问题

小白PythonPandasTensorflow实现

jady3356 2019-12-01 22:06:51 2072 浏览量 回答数 1

问题

【算法】五分钟算法小知识:王垠的面试 和 P 与 NP

游客ih62co2qqq5ww 2020-04-13 13:27:31 13 浏览量 回答数 1

问题

MaxCompute百问集锦(持续更新20171011)

隐林 2019-12-01 20:19:23 38430 浏览量 回答数 18

问题

【精品问答】前端开发必懂之CSS技术八十问

茶什i 2019-12-01 22:00:52 1642 浏览量 回答数 1

回答

前言 这期我想写很久了,但是因为时间的原因一直拖到了现在,我以为一两天就写完了,结果从构思到整理资料,再到写出来用了差不多一周的时间吧。 你们也知道丙丙一直都是创作鬼才来的,所以我肯定不会一本正经的写,我想了好几个切入点,最后决定用一个完整的电商系统作为切入点,带着大家看看,我们需要学些啥,我甚至还收集配套视频和资料,暖男石锤啊,这期是呕心沥血之作,不要白嫖了。 正文 在写这个文章之前,我花了点时间,自己臆想了一个电商系统,基本上算是麻雀虽小五脏俱全,我今天就用它开刀,一步步剖析,我会讲一下我们可能会接触的技术栈可能不全,但是够用,最后给个学习路线。 Tip:请多欣赏一会,每个点看一下,看看什么地方是你接触过的,什么技术栈是你不太熟悉的,我觉得还算是比较全的,有什么建议也可以留言给我。 不知道大家都看了一下没,现在我们就要庖丁解牛了,我从上到下依次分析。 前端 你可能会会好奇,你不是讲后端学习路线嘛,为啥还有前端的部分,我只能告诉你,傻瓜,肤浅。 我们可不能闭门造车,谁告诉你后端就不学点前端了? 前端现在很多也了解后端的技术栈的,你想我们去一个网站,最先接触的,最先看到的是啥? 没错就是前端,在大学你要是找不到专门的前端同学,去做系统肯定也要自己顶一下前端的,那我觉得最基本的技术栈得熟悉和了解吧,丙丙现在也是偶尔会开发一下我们的管理系统主要是VUE和React。 在这里我列举了我目前觉得比较简单和我们后端可以了解的技术栈,都是比较基础的。 作为一名后端了解部分前端知识还是很有必要的,在以后开发的时候,公司有前端那能帮助你前后端联调更顺畅,如果没前端你自己也能顶一下简单的页面。 HTML、CSS、JS、Ajax我觉得是必须掌握的点,看着简单其实深究或者去操作的话还是有很多东西的,其他作为扩展有兴趣可以了解,反正入门简单,只是精通很难很难。 在这一层不光有这些还有Http协议和Servlet,request、response、cookie、session这些也会伴随你整个技术生涯,理解他们对后面的你肯定有不少好处。 Tip:我这里最后删除了JSP相关的技术,我个人觉得没必要学了,很多公司除了老项目之外,新项目都不会使用那些技术了。 前端在我看来比后端难,技术迭代比较快,知识好像也没特定的体系,所以面试大厂的前端很多朋友都说难,不是技术多难,而是知识多且复杂,找不到一个完整的体系,相比之下后端明朗很多,我后面就开始讲后端了。 网关层: 互联网发展到现在,涌现了很多互联网公司,技术更新迭代了很多个版本,从早期的单机时代,到现在超大规模的互联网时代,几亿人参与的春运,几千亿成交规模的双十一,无数互联网前辈的造就了现在互联网的辉煌。 微服务,分布式,负载均衡等我们经常提到的这些名词都是这些技术在场景背后支撑。 单机顶不住,我们就多找点服务器,但是怎么将流量均匀的打到这些服务器上呢? 负载均衡,LVS 我们机器都是IP访问的,那怎么通过我们申请的域名去请求到服务器呢? DNS 大家刷的抖音,B站,快手等等视频服务商,是怎么保证同时为全国的用户提供快速的体验? CDN 我们这么多系统和服务,还有这么多中间件的调度怎么去管理调度等等? zk 这么多的服务器,怎么对外统一访问呢,就可能需要知道反向代理的服务器。 Nginx 这一层做了反向负载、服务路由、服务治理、流量管理、安全隔离、服务容错等等都做了,大家公司的内外网隔离也是这一层做的。 我之前还接触过一些比较有意思的项目,所有对外的接口都是加密的,几十个服务会经过网关解密,找到真的路由再去请求。 这一层的知识点其实也不少,你往后面学会发现分布式事务,分布式锁,还有很多中间件都离不开zk这一层,我们继续往下看。 服务层: 这一层有点东西了,算是整个框架的核心,如果你跟我帅丙一样以后都是从事后端开发的话,我们基本上整个技术生涯,大部分时间都在跟这一层的技术栈打交道了,各种琳琅满目的中间件,计算机基础知识,Linux操作,算法数据结构,架构框架,研发工具等等。 我想在看这个文章的各位,计算机基础肯定都是学过的吧,如果大学的时候没好好学,我觉得还是有必要再看看的。 为什么我们网页能保证安全可靠的传输,你可能会了解到HTTP,TCP协议,什么三次握手,四次挥手。 还有进程、线程、协程,什么内存屏障,指令乱序,分支预测,CPU亲和性等等,在之后的编程生涯,如果你能掌握这些东西,会让你在遇到很多问题的时候瞬间get到点,而不是像个无头苍蝇一样乱撞(然而丙丙还做得不够)。 了解这些计算机知识后,你就需要接触编程语言了,大学的C语言基础会让你学什么语言入门都会快点,我选择了面向对象的JAVA,但是也不知道为啥现在还没对象。 JAVA的基础也一样重要,面向对象(包括类、对象、方法、继承、封装、抽象、 多态、消息解析等),常见API,数据结构,集合框架,设计模式(包括创建型、结构型、行为型),多线程和并发,I/O流,Stream,网络编程你都需要了解。 代码会写了,你就要开始学习一些能帮助你把系统变得更加规范的框架,SSM可以会让你的开发更加便捷,结构层次更加分明。 写代码的时候你会发现你大学用的Eclipse在公司看不到了,你跟大家一样去用了IDEA,第一天这是什么玩意,一周后,真香,但是这玩意收费有点贵,那免费的VSCode真的就是不错的选择了。 代码写的时候你会接触代码的仓库管理工具maven、Gradle,提交代码的时候会去写项目版本管理工具Git。 代码提交之后,发布之后你会发现很多东西需要自己去服务器亲自排查,那Linux的知识点就可以在里面灵活运用了,查看进程,查看文件,各种Vim操作等等。 系统的优化很多地方没优化的空间了,你可能会尝试从算法,或者优化数据结构去优化,你看到了HashMap的源码,想去了解红黑树,然后在算法网上看到了二叉树搜索树和各种常见的算法问题,刷多了,你也能总结出精华所在,什么贪心,分治,动态规划等。 这么多个服务,你发现HTTP请求已经开始有点不满足你的需求了,你想开发更便捷,像访问本地服务一样访问远程服务,所以我们去了解了Dubbo,Spring cloud。 了解Dubbo的过程中,你发现了RPC的精华所在,所以你去接触到了高性能的NIO框架,Netty。 代码写好了,服务也能通信了,但是你发现你的代码链路好长,都耦合在一起了,所以你接触了消息队列,这种异步的处理方式,真香。 他还可以帮你在突发流量的时候用队列做缓冲,但是你发现分布式的情况,事务就不好管理了,你就了解到了分布式事务,什么两段式,三段式,TCC,XA,阿里云的全局事务服务GTS等等。 分布式事务的时候你会想去了解RocketMQ,因为他自带了分布式事务的解决方案,大数据的场景你又看到了Kafka。 我上面提到过zk,像Dubbo、Kafka等中间件都是用它做注册中心的,所以很多技术栈最后都组成了一个知识体系,你先了解了体系中的每一员,你才能把它们联系起来。 服务的交互都从进程内通信变成了远程通信,所以性能必然会受到一些影响。 此外由于很多不确定性的因素,例如网络拥塞、Server 端服务器宕机、挖掘机铲断机房光纤等等,需要许多额外的功能和措施才能保证微服务流畅稳定的工作。 **Spring Cloud **中就有 Hystrix 熔断器、Ribbon客户端负载均衡器、Eureka注册中心等等都是用来解决这些问题的微服务组件。 你感觉学习得差不多了,你发现各大论坛博客出现了一些前沿技术,比如容器化,你可能就会去了解容器化的知识,像**Docker,Kubernetes(K8s)**等。 微服务之所以能够快速发展,很重要的一个原因就是:容器化技术的发展和容器管理系统的成熟。 这一层的东西呢其实远远不止这些的,我不过多赘述,写多了像个劝退师一样,但是大家也不用慌,大部分的技术都是慢慢接触了,工作中慢慢去了解,去深入的。 好啦我们继续沿着图往下看,那再往下是啥呢? 数据层: 数据库可能是整个系统中最值钱的部分了,在我码文字的前一天,刚好发生了微盟程序员删库跑路的操作,删库跑路其实是我们在网上最常用的笑话,没想到还是照进了现实。 这里也提一点点吧,36小时的故障,其实在互联网公司应该是个笑话了吧,权限控制没做好类似rm -rf 、fdisk、drop等等这样的高危命令是可以实时拦截掉的,备份,全量备份,增量备份,延迟备份,异地容灾全部都考虑一下应该也不至于这样,一家上市公司还是有点点不应该。 数据库基本的事务隔离级别,索引,SQL,主被同步,读写分离等都可能是你学的时候要了解到的。 上面我们提到了安全,不要把鸡蛋放一个篮子的道理大家应该都知道,那分库的意义就很明显了,然后你会发现时间久了表的数据大了,就会想到去接触分表,什么TDDL、Sharding-JDBC、DRDS这些插件都会接触到。 你发现流量大的时候,或者热点数据打到数据库还是有点顶不住,压力太大了,那非关系型数据库就进场了,Redis当然是首选,但是MongoDB、memcache也有各自的应用场景。 Redis使用后,真香,真快,但是你会开始担心最开始提到的安全问题,这玩意快是因为在内存中操作,那断点了数据丢了怎么办?你就开始阅读官方文档,了解RDB,AOF这些持久化机制,线上用的时候还会遇到缓存雪崩击穿、穿透等等问题。 单机不满足你就用了,他的集群模式,用了集群可能也担心集群的健康状态,所以就得去了解哨兵,他的主从同步,时间久了Key多了,就得了解内存淘汰机制…… 他的大容量存储有问题,你可能需要去了解Pika…. 其实远远没完,每个的点我都点到为止,但是其实要深究每个点都要学很久,我们接着往下看。 实时/离线/大数据 等你把几种关系型非关系型数据库的知识点,整理清楚后,你会发现数据还是大啊,而且数据的场景越来越多多样化了,那大数据的各种中间件你就得了解了。 你会发现很多场景,不需要实时的数据,比如你查你的支付宝去年的,上个月的账单,这些都是不会变化的数据,没必要实时,那你可能会接触像ODPS这样的中间件去做数据的离线分析。 然后你可能会接触Hadoop系列相关的东西,比如于Hadoop(HDFS)的一个数据仓库工具Hive,是建立在 Hadoop 文件系统之上的分布式面向列的数据库HBase 。 写多的场景,适合做一些简单查询,用他们又有点大材小用,那Cassandra就再合适不过了。 离线的数据分析没办法满足一些实时的常见,类似风控,那Flink你也得略知一二,他的窗口思想还是很有意思。 数据接触完了,计算引擎Spark你是不是也不能放过…… 搜索引擎: 传统关系型数据库和NoSQL非关系型数据都没办法解决一些问题,比如我们在百度,淘宝搜索东西的时候,往往都是几个关键字在一起一起搜索东西的,在数据库除非把几次的结果做交集,不然很难去实现。 那全文检索引擎就诞生了,解决了搜索的问题,你得思考怎么把数据库的东西实时同步到ES中去,那你可能会思考到logstash去定时跑脚本同步,又或者去接触伪装成一台MySQL从服务的Canal,他会去订阅MySQL主服务的binlog,然后自己解析了去操作Es中的数据。 这些都搞定了,那可视化的后台查询又怎么解决呢?Kibana,他他是一个可视化的平台,甚至对Es集群的健康管理都做了可视化,很多公司的日志查询系统都是用它做的。 学习路线 看了这么久你是不是发现,帅丙只是一直在介绍每个层级的技术栈,并没说到具体的一个路线,那是因为我想让大家先有个认知或者说是扫盲吧,我一样用脑图的方式汇总一下吧,如果图片被平台二压了。 资料/学习网站 Tip:本来这一栏有很多我准备的资料的,但是都是外链,或者不合适的分享方式,博客的运营小姐姐提醒了我,所以大家去公众号回复【路线】好了。 絮叨 如果你想去一家不错的公司,但是目前的硬实力又不到,我觉得还是有必要去努力一下的,技术能力的高低能决定你走多远,平台的高低,能决定你的高度。 如果你通过努力成功进入到了心仪的公司,一定不要懈怠放松,职场成长和新技术学习一样,不进则退。 丙丙发现在工作中发现我身边的人真的就是实力越强的越努力,最高级的自律,享受孤独(周末的歪哥)。 总结 我提到的技术栈你想全部了解,我觉得初步了解可能几个月就够了,这里的了解仅限于你知道它,知道他是干嘛的,知道怎么去使用它,并不是说深入了解他的底层原理,了解他的常见问题,熟悉问题的解决方案等等。 你想做到后者,基本上只能靠时间上的日积月累,或者不断的去尝试积累经验,也没什么速成的东西,欲速则不达大家也是知道的。 技术这条路,说实话很枯燥,很辛苦,但是待遇也会高于其他一些基础岗位。 所实话我大学学这个就是为了兴趣,我从小对电子,对计算机都比较热爱,但是现在打磨得,现在就是为了钱吧,是不是很现实?若家境殷实,谁愿颠沛流离。 但是至少丙丙因为做软件,改变了家庭的窘境,自己日子也向小康一步步迈过去。 说做程序员改变了我和我家人的一生可能夸张了,但是我总有一种下班辈子会因为我选择走这条路而改变的错觉。 我是敖丙,一个在互联网苟且偷生的工具人。 创作不易,本期硬核,不想被白嫖,各位的「三连」就是丙丙创作的最大动力,我们下次见! 本文 GitHub https://github.com/JavaFamily 已经收录,有大厂面试完整考点,欢迎Star。 该回答来自:敖丙

剑曼红尘 2020-03-06 11:35:37 0 浏览量 回答数 0

问题

Redis 过期策略都有哪些?内存淘汰机制都有哪些?手写下 LRU 代码实现?【Java问答】33期

剑曼红尘 2020-06-10 21:02:18 20 浏览量 回答数 1

问题

【精品问答】python技术1000问(1)

问问小秘 2019-12-01 21:57:48 445437 浏览量 回答数 8

问题

支付宝的性能测试

云效平台 2019-12-01 21:47:13 5472 浏览量 回答数 1

回答

虽然我不是Python高手,但我是零基础,之前会的都是软件PS,PPT之类。点击链接加入群【我爱python大神】:https://jq.qq.com/?_wv=1027&k=47zuLPd 如果目的是想成为程序员,参考教学大纲。 如果只是学程序,理解科技,解决工作问题,我的方式可以参考使用: 1,找到合适的入门书籍,大致读一次,循环啊判断啊,常用类啊,搞懂(太难的跳过) 2,做些简单习题,字符串比较,读取日期之类PythonCookbook不错(太难太无趣的,再次跳过,保持兴趣是最重要的,不会的以后可以再学) 3,加入Python讨论群,态度友好笑眯眯(很重要,这样高手才会耐心纠正你错误常识)。很多小问题,纠结许久,对方一句话点播思路,真的节约你很多时间。耐心指教我的好人,超级超级多谢。 4,解决自己电脑问题。比如下载美剧,零散下载了2,4,5,8集,而美剧共12集,怎样找出漏下的那几集?然后问题分解,1读取全部下载文件名,2提取集的数字,3数字排序和(1--12)对比,找出漏下的。点击链接加入群【我爱python大神】:https://jq.qq.com/?_wv=1027&k=47zuLPd 5,时刻记住目的,不是为了当程序员,是为了解决问题。比如,想偷懒抓网页内容,用urllib不行,用request也不行,才发现抓取内容涉及那么多方面(cookie,header,SSL,url,javascript等等),当然可以听人家劝,回去好好读书,从头读。 或者,不求效率,只求解决,用ie打开网页再另存为行不行?ie已经渲染过全部结果了。 问题变成:1--打开指定的10个网页(一行代码就行)。更复杂的想保存呢?利用已经存在的包,比如PAM30(我的是Python3),直接打开ie,用函数outHTML另存为文本,再用搜索函数(str搜索也行,re正则也行)找到数据。简单吧?而且代码超级短。 6,保持兴趣,用最简单的方式解决问题,什么底层驱动,各种交换,留给大牛去写吧。我们利用已经有的包完成。 7,耐心读文档,并且练习快速读文档。拿到新包,找到自己所需要的函数,是需要快速读一次的。这个不难,读函数名,大概能猜到是干嘛的,然后看看返回值,能判断是不是自己需要的。 8,写帮助文件和学习笔记,并发布共享。教别人的时候,其实你已经自己再次思考一次了。 我觉得学程序就像学英文,把高频率的词(循环,判断,常用包,常用函数)搞懂,就能拼装成自己想要的软件。 然后点点击链接加入群【我爱python大神】:https://jq.qq.com/?_wv=1027&k=47zuLPd是很好用的。 然后,坚持下去~ 6月10日补充------------------------------ 一定要保持兴趣,太复杂的跳过,就像小学数学,小学英语,都是由简入深。 网络很平面,无数国际大牛著作好书,关于Python,算法,电脑,网络,或者程序员思路,或者商业思维(浪潮之巅是本好书)等等,还有国际名校的网络公开课(中英文字幕翻译完毕,观看不是难事),讲计算机,网络,安全,或者安卓系统,什么都有,只要能持续保持兴趣,一点点学习下去,不是难事。 所有天才程序员,都曾是儿童,回到儿童思维来理解和学习。觉得什么有趣,先学,不懂的,先放着,遇到问题再来学,效果更好。 唯一建议是,不要太贪心,耐心学好一门优雅的语言,再学其它。虽然Javascript做特效很炫,或提某问题时,有大牛建议,用Ruby来写更好之类,不要改方向。就像老笑话:“要学习递归,必须首先理解递归。”然后死循环一直下去。坚持学好一门语言,再研究其他。 即使一门语言,跟网络,数据库等等相关的部分,若都能学好,再学其他语言,是很快的事情。 另外就是,用学英文的耐心来学计算机,英文遇到不懂的词,抄下,查询。 python里,看到Http,查查定义,看到outHtml,查查定义,跟初学英语时候一样,不要直接猜意思,因为精确描述性定义,跟含糊自然语有区别的。而新人瞎猜,很容易错误理解,wiki,google很有用。 我还在使劲啃Python的路上~~一起加油:) 2012年8月26日补充线------------------------------------------------------------------ QQ群:22507237陆续有些高手走了,也有新人加入。 另外10月20日,上海有Python开发者大会, 给出2个截图吧,我最近做的,真的很烂,但是能用:) 这个是上次Python测试题目“从电商网站的搜索页中抓取制作商品图片墙”。我选了最最容易的静态网站。当然京东的抓取,比这种难。 这个很方便我自己每天查询,用Python3+PyQt4,用“公司名字”关键词,在各个论坛,图片,视频,商场查询。每天看一次,很方便快速了解信息。 1.如果是因为兴趣,想做些比较漂亮的网页或者做些特别的、能帮到自己的小程序,可以直接买市面上的大部分Python教材,直接从Python学起,学实际的编程。Python并不难学,最初设计的时候就力图规避一些C、C++等等程序让入门者头大的内容,而且库函数也比较丰富,语法相对清晰直白,不会故意做一些高效率但是难弄懂的东西。而且相对语法要求(尤其是缩进==)比较严比较死,虽然你会觉得麻烦,不过确实易读而且省的粗心犯错。 2.如果是想从事编程的职业,建议还是循序渐进的来,单纯只学语言比较浅,还是从数据结构、离散数学、算法一步一步来比较好。这样学确实很枯燥,但是基础比较好,可塑性强些,再学其他算法和语言都方便不少,而且读好的源码理解的更透更深。真正专业性的学习和兴趣式的尝试差别还是很大的,要真的非常感兴趣肯吃苦才行,虽然经常看到有很多人在报考或者转入这方面的专业,不过说实话急着跳出去的一样不少。 实际上,要把一段代码编程直观的产品、工具,远远没有你想像的那么难,与其他东西的学习一样都是模仿加重复性练习,不过是非专业的人接触的少所以觉得编程特别难。现在编程语言和工具越来越多,发展很快,编程的门槛已经降低了很多了。只是相对来说,精通很难,非常难。。。 我的朋友问我怎么能快速地掌握Python。我想Python包含的内容很多,加上各种标准库,拓展库,乱花渐欲迷人眼,就想写一个快速的,类似于w3cschool风格的Python教程,一方面保持言语的简洁,另一方面循序渐进,尽量让没有背景的读者也可以从基础开始学习。另外,我在每一篇中专注于一个小的概念,希望可以让人在闲暇时很快读完。?  学好python你需要一个良好的环境,一个优质的开发交流群,群里都是那种相互帮助的人才是可以的,我有建立一个python学习交流群,在群里我们相互帮助,相互关心,相互分享内容,这样出问题帮助你的人就比较多,群号是304加上050最後799,这样就可以找到大神聚合的群,如果你只愿意别人帮助你,不愿意分享或者帮助别人,那就请不要加了,你把你会的告诉别人这是一种分享。 感觉写的好,对你有帮助,就点个赞呗,别光只收藏哈.~( ̄▽ ̄)~ ?

爱吃鱼的程序员 2020-06-08 17:59:21 0 浏览量 回答数 0

问题

经典动态规划:高楼扔鸡蛋(进阶篇) 6月3日【今日算法】

游客ih62co2qqq5ww 2020-06-03 15:10:38 7 浏览量 回答数 1

回答

2020,程序员找工作会更难吗 打开各大招聘网站,明显感受到今年招聘信息少了很多,而且企业对面试者的技能要求更高,技术覆盖面也更全。在2019年,互联网寒冬本就是比较火的一个词,现在加上疫情的冲击,更是雪上加霜,公司关门的新闻也有很多,看来程序员不是失业了,就是在失业的路上。 今年想要轻轻松松跳槽,确实不太容易。因为现在行业出现一个现象叫做-“从业者饱和,而人才匮乏”,不仅招聘信息少了,条件也越发的严苛。这个时候,技术能力过硬的人才不愁不好找工作,但对一些没有核心竞争力,不上不下的从业者来说,工作形势会比较严峻。所以我们更应该沉下心来,好好梳理自己的技术,加强提升自己的技能。 就拿我身边的事情来说说,像我本人是做java开发的,身边接触的不外乎是web相关的人员,有的是java,也有的是做前端。我现在这家公司是小的创业公司,在年前前端由于一些原因离职了,到现在公司还缺着前端的职位,在复工之后呢,也陆续面试了一些人,我个人的感觉就是不仅仅是简历变少了、有实力的人不太会选择小的创业公司,而一些普通的前端自己的技能也并不是很扎实,所以现在就有一种假象,企业会招不到人,求职者也难找到合适的职位。所以最根本的问题还是需要将自己的技术变得更扎实。 提到技术,那我们应该怎么样巩固提升呢?首先要明确自己的方向,保持自己的专业性。工业化的特征之一就是分工与合作,工程的复杂程度与人员的相互协作必然是成正比的,作为职场中的一员,程序员也必须保持自己的专业性,这无疑是在职场安身立命的定海神针。在下面我列举一些提升自己技术的方法: 善于利用学习资料。 学习资料有非常多-书籍、论坛、视频、博客等等。面对现在互联网那么多资料我们唾手可得,我们该如何选择呢。我认为有些要找到适合自己的,而不是一味的死记硬背,这样会造成了解几个概念意外对自己的技术毫无提升。 练习 比如说一些算法题,可以使用现在的一些在线刷题,来提升自己。 阅读源码 阅读一些开源代码不仅可以学到自己没有的知识,还可以学习他人的写法,有助于自己代码质量的提高。吸收别人的思想,避免闭门造车。 擅长使用工具 俗话说工欲善其事必先利其器,熟练使用各种工具可以提升自己的工作效率,以及工作质量,剩下多出来的时间可以用来学习 除了提升自己的技术外,与人沟通也是非常重要的。在求职过程中面试是最重要的一个环节,而在疫情这个大背景下,大多数招聘主阵地从线下搬到了线上。形式的改变其实对招聘方也是一种挑战。那么我们要更注意在面试中的几个问题: 工具选择 无论音频还是视频,都会因为信号的干扰而导致各种障碍,所以一个稳定流畅的通讯工具就显得格外重要,现在来说,首选的还是电话、其次再是一些软件的语音。 面试环境 面试最好要选择一个安静的环境,这样不仅会使自己可以保持头脑清醒的状态,这有很大的程度会影响到自己的发挥。 顺便说一句,如果在家的话最好还是不要穿着太随便。 自我介绍 一般面试官首先就会让求职者自我介绍,我们要先做好准备,自己可以写个草稿记熟。要将自己的工作经历、项目经历等说的简洁明了不要拖泥带水。 回顾和总结 要懂得在一次面试中总结经验,获取长进,有助于下一次面试的到来。比如说上一次面试有哪些问题自己并不是记得非常清楚,或者说自己的哪些话会让面试官感觉不是特别好。这些也可以在面试结束时向面试官获取到反馈。 说到最后,不得不说一些程序员的软技能也就是说在写代码之外的求生之道。 自我营销 现在很多的人都在做相同的事,那就是写个人博客。这不仅仅是体现自我技术的很好方法,也是一个自我营销的基本机制。这很可能会给你的面试加分。 参与开源 如果你有非常感兴趣的开源代码或者其他的小工具,你可以参与他们的开源工作,一起探索,开源会让技术得到更多人的认可,在一次次交流过程中,你的编码也会变得更加优秀。 好的身体 在现在互联网公司普遍996的背景下,又有着疫情的冲击,我认为一个好的身体比任何技术还要重要。我们要懂得平衡工作与生活,更要懂得调理自己的身体。 建立关系 在公司内外能够结识很多的人,说不定就会给自己的职业生涯带来意想不到的好处。比如会有更好的工作机会,或者是不经意间解决你的一个难题等。 开放思想 虚心 在任何时候都要怀着敬畏的心来做事情,要懂得包容和开放。

kun坤 2020-03-19 11:17:00 0 浏览量 回答数 0

问题

用位运算来解下八皇后问题 6月11日 【今日算法】

游客ih62co2qqq5ww 2020-06-15 16:24:16 2 浏览量 回答数 1

回答

你这个是window下的?如果是我早忘光了。哈。基本上几年前,我就把“线程”这个概念扔掉了。用进程的构造方式,我们可以讨论讨论中间的逻辑问题。问我线程的任何问题,可权当我不会,因为线程的事情,进程都可以做。所谓线程省资源,更高效,那是基于没有考虑线程额外带来的逻辑的空谈。###### 引用来自“中山野鬼”的答案 你这个是window下的?如果是我早忘光了。哈。基本上几年前,我就把“线程”这个概念扔掉了。用进程的构造方式,我们可以讨论讨论中间的逻辑问题。问我线程的任何问题,可权当我不会,因为线程的事情,进程都可以做。所谓线程省资源,更高效,那是基于没有考虑线程额外带来的逻辑的空谈。 不懂就说你不懂又不会死,别在这里误导新手。线程当然比进程轻量,线程能做的事当然很多进程都做不了,而且楼主发的代码是关于互斥体的与多线程没多大关系,互斥体是跨进程的,你即然这么熟悉多进程,看到一个互斥体的代码却扯了一堆不相关的东西? 而且异常退出关线程、进程啥事?调试方法的问题,你告诉楼主调试中断、捕获异常就行了。 ###### 引用来自“ssn6”的答案 引用来自“中山野鬼”的答案 你这个是window下的?如果是我早忘光了。哈。基本上几年前,我就把“线程”这个概念扔掉了。用进程的构造方式,我们可以讨论讨论中间的逻辑问题。问我线程的任何问题,可权当我不会,因为线程的事情,进程都可以做。所谓线程省资源,更高效,那是基于没有考虑线程额外带来的逻辑的空谈。 不懂就说你不懂又不会死,别在这里误导新手。线程当然比进程轻量,线程能做的事当然很多进程都做不了,而且楼主发的代码是关于互斥体的与多线程没多大关系,互斥体是跨进程的,你即然这么熟悉多进程,看到一个互斥体的代码却扯了一堆不相关的东西? 而且异常退出关线程、进程啥事?调试方法的问题,你告诉楼主调试中断、捕获异常就行了。 哈,随便你说懂不懂,“线程比进程轻,”,我倒想问问,这个“轻”是怎么定义的?系统自定义的(当然不是说你本人),还是针对应用效果定义的?或是开发复杂度定义的? “楼主发的代码是关于互斥体的与多线程没多大关系,互斥体是跨进程的,”为了忙个同步问题,扯出“线程”,结果又扯出“进程”你觉得这样的设计思维没有问题,我就没有办法咯。 哈。工程设计,谁对谁错,需要实际做出来给客户检验,当然也包括不停的维护和改良这个系统的程序员来评判。落到我的个人看法上,会让思维和逻辑变的更复杂的系统,我是不参合讨论的。你说我不懂,那我就不懂吧,而且我真心的说我不懂。因为我根本没必要去懂那些把逻辑搞的更杂而会形成更加混乱局面的东西。包括思维方法,和设计工具以及一堆堆没有价值的概念名词,(有么有价值不是我说的哦。是系统的可延展设计和用户感受说的)哈。 ###### 引用来自“中山野鬼”的答案 引用来自“ssn6”的答案 引用来自“中山野鬼”的答案 你这个是window下的?如果是我早忘光了。哈。基本上几年前,我就把“线程”这个概念扔掉了。用进程的构造方式,我们可以讨论讨论中间的逻辑问题。问我线程的任何问题,可权当我不会,因为线程的事情,进程都可以做。所谓线程省资源,更高效,那是基于没有考虑线程额外带来的逻辑的空谈。 不懂就说你不懂又不会死,别在这里误导新手。线程当然比进程轻量,线程能做的事当然很多进程都做不了,而且楼主发的代码是关于互斥体的与多线程没多大关系,互斥体是跨进程的,你即然这么熟悉多进程,看到一个互斥体的代码却扯了一堆不相关的东西? 而且异常退出关线程、进程啥事?调试方法的问题,你告诉楼主调试中断、捕获异常就行了。 哈,随便你说懂不懂,“线程比进程轻,”,我倒想问问,这个“轻”是怎么定义的?系统自定义的(当然不是说你本人),还是针对应用效果定义的?或是开发复杂度定义的? “楼主发的代码是关于互斥体的与多线程没多大关系,互斥体是跨进程的,”为了忙个同步问题,扯出“线程”,结果又扯出“进程”你觉得这样的设计思维没有问题,我就没有办法咯。 哈。工程设计,谁对谁错,需要实际做出来给客户检验,当然也包括不停的维护和改良这个系统的程序员来评判。落到我的个人看法上,会让思维和逻辑变的更复杂的系统,我是不参合讨论的。你说我不懂,那我就不懂吧,而且我真心的说我不懂。因为我根本没必要去懂那些把逻辑搞的更杂而会形成更加混乱局面的东西。包括思维方法,和设计工具以及一堆堆没有价值的概念名词,(有么有价值不是我说的哦。是系统的可延展设计和用户感受说的)哈。 你不是忘光了,你是根本没用过多线程,更不知道多线程是什么东西,你不是不懂你是不懂到令人震惊的地步,可是你又喜欢喷,线程为什么比线程轻量要问我干什么,不懂自已去学习,什么是线程能做的进程不能做的自己去搞清楚,互斥体是跨进程的不是说楼主的代码里扯到了跨进程,他也可以当线程互斥体来用,你说你根本就一个外行,你还死要面子,动不动就写万言书装逼你累不? ######楼主的意思应该是在主线程里面开一个新的线程去完成一个任务,但是任务还没有完成主线程就退出了。如果这这样的话,上面的代码可以完成楼主的需求,可是感觉你这样做没有什么意义啊。######就是在主进程中,每次过来一个连接就创建一个线程执行A函数,第一个线程的A函数执行没问题,第二个线程执行的时候程序就退出了,这个咋看啥原因。###### 引用来自“ssn6”的答案 引用来自“中山野鬼”的答案 引用来自“ssn6”的答案 引用来自“中山野鬼”的答案 你这个是window下的?如果是我早忘光了。哈。基本上几年前,我就把“线程”这个概念扔掉了。用进程的构造方式,我们可以讨论讨论中间的逻辑问题。问我线程的任何问题,可权当我不会,因为线程的事情,进程都可以做。所谓线程省资源,更高效,那是基于没有考虑线程额外带来的逻辑的空谈。 不懂就说你不懂又不会死,别在这里误导新手。线程当然比进程轻量,线程能做的事当然很多进程都做不了,而且楼主发的代码是关于互斥体的与多线程没多大关系,互斥体是跨进程的,你即然这么熟悉多进程,看到一个互斥体的代码却扯了一堆不相关的东西? 而且异常退出关线程、进程啥事?调试方法的问题,你告诉楼主调试中断、捕获异常就行了。 哈,随便你说懂不懂,“线程比进程轻,”,我倒想问问,这个“轻”是怎么定义的?系统自定义的(当然不是说你本人),还是针对应用效果定义的?或是开发复杂度定义的? “楼主发的代码是关于互斥体的与多线程没多大关系,互斥体是跨进程的,”为了忙个同步问题,扯出“线程”,结果又扯出“进程”你觉得这样的设计思维没有问题,我就没有办法咯。 哈。工程设计,谁对谁错,需要实际做出来给客户检验,当然也包括不停的维护和改良这个系统的程序员来评判。落到我的个人看法上,会让思维和逻辑变的更复杂的系统,我是不参合讨论的。你说我不懂,那我就不懂吧,而且我真心的说我不懂。因为我根本没必要去懂那些把逻辑搞的更杂而会形成更加混乱局面的东西。包括思维方法,和设计工具以及一堆堆没有价值的概念名词,(有么有价值不是我说的哦。是系统的可延展设计和用户感受说的)哈。 你不是忘光了,你是根本没用过多线程,更不知道多线程是什么东西,你不是不懂你是不懂到令人震惊的地步,可是你又喜欢喷,线程为什么比线程轻量要问我干什么,不懂自已去学习,什么是线程能做的进程不能做的自己去搞清楚,互斥体是跨进程的不是说楼主的代码里扯到了跨进程,他也可以当线程互斥体来用,你说你根本就一个外行,你还死要面子,动不动就写万言书装逼你累不? 哈。window的线程,10年前就写过。arm的里面的解码算法程序本身也包括三个线程,用于解决arm和dsp处理速度不匹配的问题。你说我不懂线程,我可以去“承认”,你说我没做过线程设计,哈,这个就不行了。我经历的事实是摆在那的,不是你所能否定的。 另外说一句,你仅能肯定而不能否定一个事物,只能证明你并没有完全了解这个事物。等你啥时懂我在说什么了,在和我讨论“线程”的优势吧。 与其我参与楼主的问题,倒不如给楼主额外的建议和思考问题的方法,也即,是否真的要去学习“线程”的设计方法。我建议你,要么直接回复楼主的答案,要么也就设计方法的好坏给楼主建议,与我争懂不懂,哈,很无聊,不和你争,你说什么都是“对的”。 ###### 引用来自“狼来了而已”的答案 楼主的意思应该是在主线程里面开一个新的线程去完成一个任务,但是任务还没有完成主线程就退出了。如果这这样的话,上面的代码可以完成楼主的需求,可是感觉你这样做没有什么意义啊。 加些日志看看,是不是在执行过程中有什么原因或者异常导致程序退出了。

爱吃鱼的程序员 2020-06-05 13:15:23 0 浏览量 回答数 0

回答

先说结论: 不要对接!不要对接!不要对接! 开个玩笑,以上仅代表个人观点,大家也知道这种“三体式警告”根本没有用的,我自己也研究如何对接,说不定做完后就觉得“真香”了。 为什么要对接? 首先讨论一下为什么要把 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

回答

01. 前言 关于程序员接私活,社会各界说法不一。按照作者的观点来说如果你确实急用钱,价格又合适,那就去做。如果不怎么缺钱,那就接私活之前要好好考虑。私活的钱不好挣是一个方面,更重要的是如果你把做私活的时间花在提升自己上,产生的价值就要大得多。等你提升了自己,提升了固定薪水,远比拿的这点私活的钱划算。千万不要“捡了芝麻丢了西瓜”。 如果你主业上遇到了瓶颈,平时的时间比较充分,想有一些额外的收入,同时为了保持技术的熟练度,这种情况下,是可以考虑接一些私活的。对于那种投入时间巨大,回报很可怜的项目,千万不要接。 下面介绍一些常用的平台可以接私活。 02. 程序员客栈 程序员客栈中国非常领先的自由工作平台,为中高端程序员、产品经理和设计师等等互联网相关人员提供稳定的线上工作机会,包括自由工作、远程工作和兼职工作,还支持按需雇佣,工作模式非常多,感兴趣的推荐大家尝试一下。虽然名称叫程序员客栈,但是除了程序员,像产品经理,设计师等等互联网相关人员,都能在上面找到适合自己的项目。感兴趣的可以体验一下。 程序员客栈官网:https://www.proginn.com/ 03. 码市 码市是 Coding 推出的互联网软件外包服务平台,意在连接需求方与广大开发者。让项目的需求方快速的找到合适的开发者,完成项目开发工作。 码市官方网站:https://codemart.com/ 04. 猪八戒网 猪八戒网创建于2006年,是服务中小微企业的人才共享平台。开创式地为人才与雇主搭建起双边市场,通过线上线下资源整合与大数据服务,实现人才与雇主精准无缝对接。找兼职的地方,主要是入门级项目,不适合专业程序员,只适合新手。 猪八戒官网:https://luoyang.zbj.com/ 05. 开源众包 开源众包–专业的软件众包平台,350万+ 优质开发者为您提供网站、APP、微信/小程序、企业应用等软件开发服务,有效降低企业 IT 软件开发成本、解决技术资源不足等问题。 开源中国的众包平台,主要是以众包为主。 开源众包官网:https://zb.oschina.net/ 06. 智城外包网 智城外包网,聚合全国软件团队资源,官方认证,1小时响应,零交易佣金,托管安全保障。十年口碑运营,万家靠谱团队。免费比价,免费一站式外包项目管理工具。平台汇集软件咨询专家,软件技术专家,软件开发专家,软件开发公司,软件外包公司,软件外派公司。在线竞标模式,让IT外包项目和短期IT招聘、人力派遣需求可以获得高性价比的候选。海量资源池包括:网站设计、网站开发、手机应用开发、移动应用开发、安卓应用开发、苹果应用开发、微信应用开发、Java技术、C#技术、Web前端开发、IT人力外包、IT人力外派、IT人力短期招聘、技术合伙人、通用软件开发,SaaS软件实施,软件运维等服务门类。 网官方网站:http://www.taskcity.com/ 07. 实现网 北京实现与爱科技有限公司是一个互联网工程师兼职平台。解决创业公司招人难、成本高的问题。 创业公司通过实现网可以快速预约知名互联网企业的工程师、设计师到自己的团队工作。上午预约工程师,最快晚上即可到班兼职。 互联网工程师可以在实现网注册成为技术顾问,利用业余时间助力创业公司,并且获得以时薪为单位的报酬。 目前已有9000+工程师或设计师可在线预约和支付,支付后工程师会到团队里坐班沟通,快速推进创业者的产品开发进度。 实现网为企业提供BAT等名企背景的、靠谱的开发设计兼职人才和自由职业者,满足企业项目外包、驻场开发、远程兼职、技术咨询等短期人力需求。已服务2000多家企业,包括好未来、方正、人人贷、秒拍等知名企业。 官方网站:https://shixian.com/ 08. 猿急送 猿急送,一个高级技术共享平台,这里汇聚知名互联网公司的技术、设计、产品大牛,通过实际坐班、远程等方式,一对一为创业公司解决问题,提高创业效率。 猿急送为您提供兼职程序员,兼职工程师信息,猿急送是一个高级技术共享平台,是优质的程序员兼职网站,这里汇聚BAT等知名互联网公司的技术开发、产品、设计大牛,通过实际坐班等方式,一对一为创业公司解决程序员、工程师等开发、产品设计人力问题。 官方网站:https://www.yuanjisong.com/ 09. 人人开发 人人开发基于可视化快速开发平台 - 捷得(Joget)/捷得云(Joget Cloud)(PaaS),集众多开发者资源,为企业提供企业管理软件服务。应用市场提供应用产品、插件的在线试用和销售,服务市场以威客众包模式提供管理软件定制开发服务,各类企业级应用开发服务,例如:协同OA产品,ERP,CRM,人事管理,项目管理,资产管理,设备管理等。 官方网站:http://rrkf.com/ 10. 开发邦 公司位于北京中关村科技园区核心区海淀园,成立于2010年,专注于为客户提供互联网软件技术开发与咨询服务,致力于利用互联网软件技术为客户提高效率、降低成本、提升效能、优化管理。 团队核心成员均具有十年以上软件互联网技术开发经验,毕业于工科名校。至今,已成功执行近百个项目,涵盖管理软件、互联网系统、移动APP、前端互动开发等。 先后为华为公司、商汤科技、工信部中国软件评测中心、神州数码、深鉴科技、中软集团、中国万网、中石油吐哈气举中心、华北电力大学、中科院科技政策与管理研究所、浪潮集团、ADI、世界五百强伊顿中国、北京外国语大学、51talk、勤邦生物、安龙基因等知名企业及机构提供过互联网软件技术开发与技术咨询服务。 开发邦致力于成为企业业务互联网软件服务与咨询的定制方案提供商。 官方网站:https://www.kaifabang.com/ 11. 电鸭社区 电鸭社区旨在帮助更多人走上「只工作,不上班」的自由工作之路,我们是一个「分布式组织」,通过分享及行动带来积极的影响,相信点滴的力量能改变潮水的方向。 官方网站:https://eleduck.com/ 12. 快码 深圳快码科技成立于2014年11月,是一家创新型的互联网公司,致力于通过创新的开发方式,为软件技术开发行业带来改变,提供更快速、更高性价比的软件定制服务。 “快码”的意思是“快速编写代码”。公司采用“专属项目经理 + 自有开发团队 + 平台程序员”的创新开发方式,严格按照互联网公司的标准来管理开发团队,确保每个项目都有充足的人员投入,确保项目的进度和开发质量。2015年,我们和全球最大的手游、APP云测试平台Testin达成战略合作协议,并获得Testin数百万的战略投资。 目前平台已注册的开发者达到3万多人,涵盖各种开发语言与类型,可以提供开发的项目有iOS APP、安卓APP、微信公众号、PC网站、手机网站、微信小程序、桌面软件、智能硬件APP等。上线以来,我们已经完成了数千项目&任务的开发。 创业灵感来自于快码团队的从业经验。在近十年的互联网技术经历中,对由于创业公司、外包公司人员不稳定,招聘困难、人手有限等问题而导致现有团队开发任务过重,开发进度缓慢等问题有着切身之痛,将在P2P旅游行业2年多的共享经济经验,和自身最熟悉的“软件开发”结合,创立了“快码”。 快码将立足于代码开发,深耕行业,面向未来,通过持续的产品创新,为广大项目方、开发者提供专业的服务,为软件技术开发行业带来改变。 快码是一个创新的软件开发平台。项目方可以更省钱、高效地完成项目的开发;开发者可以充分利用闲置时间,实现更高的商业价值! 官方网站:https://www.kuai.ma/ 13. 英选 英选,可信赖的软件外包服务。用优秀的人,做漂亮的产品,写干净的代码。平台以定制开发外包服务为主,也是外包项目平台。 官方网站:https://www.yingxuan.io/ 14. Upwork Upwork 是全球最大的、最优秀的、最规范的综合类人力外包服务平台,由著名的 Elance 和 oDesk 合并。这里聚集 900 万来自全球各地的自由工作者,你肯定可以在找到适合你的职位。 官方网站:https://www.upwork.com/ 15. Freelancer Freelancer 的工作类型覆盖了很多不同的领域,由程序开发到市场营销、广告、会计、法务等一系列的可以远程的工作。 官方网站:https://www.freelance.com/ 16. Dribbble Dribbble 不只是全球最受欢迎的设计师社区,同样是设计师寻找远程工作的好出处。自从被 Tiny 收购后,Dribbble 的招聘属性正在慢慢增强,试着持续 PO 出自己的好作品,等待你的伯乐,同样你可以关注 Jobs 页面,给心仪的 Team 提交简历。 官方网站:https://dribbble.com/jobs 17. Remoteok Remoteok 不仅提供最初的兼职类远程工作,还有全职类,签署合同类和实习类的工作。网站创始人 Pieter Levels 本身就是一名数字游民,他同样是 Nomadlist 的创始人。 官方网站:https://remoteok.io/ 18. Toptal Toptal 是一个高端一些的自由职业者平台,适合比较有经验和工作尽力的远程工作者。它将企业与全球的软件工程师,设计师和业务顾问联系起来。 官方网站:https://www.toptal.com/ 19. AngelList AngelList 主要是服务于初创公司和天使投资人的平台,这里还有初创公司提供的远程工作的机会,如果对远程加入初创公司感兴趣的,可以尝试一下。 官方网站:https://angel.co/remote 20. Topcoder Topcoder 通过算法比赛吸引世界顶级的程序员,他会将一下大型项目分割成很多小模块,通过竞赛的模式交给用户来做,优胜者可以拿到制定模块的奖金。 官方网站:https://www.topcoder.com/

茶什i 2020-01-15 11:55:41 0 浏览量 回答数 0

回答

转自:阿飞的博客 一、数据库技术选型的思考维度 我们做选型的时候首先要问: 谁选型?是负责采购的同学、 DBA 还是业务研发? 如果选型的是采购的同学,他们更注重成本,包括存储方式、网络需求等。 如果选型的是 DBA 同学,他们关心的: ① 运维成本 首先是运维成本,包括监控告警是否完善、是否有备份恢复机制、升级和迁移的成本是否高、社区是否稳定、是否方便调优、排障是否简易等; ② 稳定性 其次,DBA会关注稳定性,包括是否支持数据多副本、服务高可用、多写多活等; ③ 性能 第三是性能,包括延迟、QPS 以及是否支持更高级的分级存储功能等; ④ 拓展性 第四是扩展性,如果业务的需求不确定,是否容易横向扩展和纵向扩容; ⑤ 安全 最后是安全,需要符合审计要求,不容易出现 SQL 注入或拖库情况。 ⑥ 其他 除了采购和 DBA之外,后台应用研发的同学同样会关注稳定性、性能、扩展性等问题,同时也非常关注数据库接口是否便于开发,是否便于修改数据库 schema 等问题。 接下来我们来看一下爱奇艺使用的数据库类型: MySQL,互联网业务必备系统; TiDB,爱奇艺的 TiDB 实践会有另外的具体介绍; Redis,KV 数据库,互联网公司标配; Couchbase,这个在爱奇艺用得比较多,但国内互联网公司用得比较少,接下来的部分会详细说明; 其他,比如 MongoDB、图数据库、自研 KV 数据库 HiKV 等; 大数据分析相关系统,比如 Hive、Impala 等等。 可以看到爱奇艺的数据库种类还是很多的,这会造成业务开发的同学可能不太清楚在他的业务场景下应该选用哪种数据库系统。 那么,我们先对这些数据库按照接口(SQL、NoSQL)和面向的业务场景(OLTP、OLAP)这两位维度进行一个简单非严谨的分类。 下图中,左上角是面向 OLTP、支持 SQL 的这样一类系统,例如 MySQL,一般支持事务不同的隔离级别, QPS 要求比较高,延时比较低,主要用于交易信息和关键数据的存储,比如订单、VIP 信息等。 左下角是 NoSQL 数据库,是一类针对特殊场景做优化的系统,schema 一般比较简单,吞吐量较高、延迟较低,一般用作缓存或者 KV 数据库。 整个右侧都是 OLAP 的大数据分析系统,包括 Clickhouse、Impala等,一般支持SQL、不支持事务,扩展性比较好,可以通过加机器增加数据的存储量,响应延迟较长。 还有一类数据库是比较中立的,在数据量比较小的时候性能比较好,在数据量较大或复杂查询的时候性能也不差,一般通过不同的存储引擎和查询引擎来满足不同的业务需求,我们把它叫做 HTAP,TiDB 就是这样一种数据库。 二、iQIYI对数据库的优化与完善 前面我们提到了很多种的数据库,那么接下来就和大家介绍一下在爱奇艺我们是怎么使用这些数据库的。 1、MySQL在爱奇艺的使用 ① MySQL 首先是 MySQL。MySQL 基本使用方式是 master-slave + 半同步,支持每周全备+每日增量备份。我们做了一些基本功能的增强,首先是增强了数据恢复工具 Xtrabackup 的性能。 之前遇到一个情况,我们有一个全量库是 300G 数据,增量库每天 70G 数据,总数据量 700G 左右。我们当时只需要恢复一个表的数据,但该工具不支持单表恢复,且整库恢复需要 5 个小时。 针对这个情况我们具体排查了原因,发现在数据恢复的过程中需要进行多次写盘的 IO 操作并且有很多串行操作,所以我们做了一些优化。例如删减过程中的一些写盘操作,减少落盘并将数据处理并行化,优化后整库恢复耗时减少到 100 分钟,而且可以直接恢复单表数据。 然后是适配 DDL 和 DML 工具到内部系统,gh-ostt 和 oak-online-alter-table 在数据量大的时候会造成 master-slave 延时,所以我们在使用工具的时候也增加了延时上的考虑,实时探测Master-Slave 库之间延时的情况,如果延时较大会暂停工具的使用,恢复到正常水平再继续。 ② MySQL高可用 第二是 MySQL 高可用。Master-slave 加上半同步这种高可用方式不太完善,所以我们参照了 MHA 并进行了改动,采用 master + agent 的方式。Agent 在每一个物理机上部署,可以监控这个物理机上的所有实例的状态,周期性地向 master 发送心跳,Master 会实时监测各个Agent的状态。 如果 MySQL故障,会启动 Binlog 补偿机制,并切换访问域名完成 failover。考虑到数据库跨机房跨地区部署的情况,MHA 的 master 我们也做了高可用设计,众多 master 会通过 raft 组成一个 raft group,类似 TiDB 的 PD 模块。目前 MySQL failover 策略支持三种方式:同机房、同地域跨机房以及跨地域。 ③ MySQL拓展能力 第三是提高MySQL扩展能力,以提供更大容量的数据存储。扩展方式有 SDK,例如开源的 ShardingSphere,在爱奇艺的使用也比较广泛。另外就是 Proxy,开源的就更多了。但是 SDK 和 Proxy 使用的问题是支持的 SQL 语句简单,扩容难度大,依赖较多且运维复杂,所以部分业务已经迁移至 TiDB。 ④ 审计 第四是审计。我们在 MySQL 上做了一个插件获取全量 SQL 操作,后端打到 Kafka,下游再接入包括 Clickhouse 等目标端进行 SQL 统计分析。除此之外还有安全策略,包括主动探索是否有 SQL 注入及是否存在拖库情况等,并触发对应的告警。 MySQL 审计插件最大的问题是如何降低对 MySQL 性能的影响,对此我们进行了一些测试,发现使用 General Log 对性能损耗较大,有 10%~20% 的降低。 于是我们通过接口来获取 MySQL 插件里的监控项,再把监控项放到 buffer 里边,用两级的 RingBuffer 来保证数据的写入不会有锁资源竞争。在这个插件里再启动一个线程,从 RingBuffer 里读取数据并把数据打包写到 FIFO 管道里。 我们在每台 MySQL 的物理机里再启动一个 Agent,从管道里阻塞地读取数据发至 Kafka。优化后我们再次进行压测,在每台机器上有 15 万的更新、删除或插入操作下不会丢失数据,性能损耗一般情况下小于 2%。 目前已经在公司内部的集群上线了一年时间,运行比较稳定,上线和下线对业务没有影响。 ⑤ 分级存储 第五是分级存储。MySQL 里会存一些过程性的数据,即只需要读写最近一段时间存入的数据,过段时间这些数据就不需要了,需要进行定时清理。 分级存储就是在 MySQL 之上又用了其他存储方式,例如 TiDB 或其他 TokuDB,两者之间可以进行数据自动搬迁和自动归档,同时前端通过 SDK + Proxy 来做统一的访问入口。这样一来,业务的开发同学只需要将数据存入 MySQL 里,读取时可能从后端接入的任意数据库读出。这种方式目前只是过渡使用,之后会根据 TiDB 的特性进行逐步迁移。 Redis在爱奇艺的使用 接下来是 Redis。Redis 也是使用 master - slave 这种方式,由于网络的复杂性我们对 Sentinel 的部署进行了一些特殊配置,在多机房的情况下每个机房配置一定数量 Sentinel 来避免脑裂。 备份恢复方面介绍一个我们的特殊场景,虽然 Redis 是一个缓存,但我们发现不少的业务同学会把它当做一个 KVDB 来使用,在某些情况下会造成数据的丢失。 所以我们做了一个 Redis 实时备份功能,启动一个进程伪装成 Redis 的 Slave 实时获取数据,再放到后端的 KV 存储里,例如 ScyllaDB,如果要恢复就可以从 ScyllaDB 里把数据拉出来。 我们在用 Redis 时最大的痛点就是它对网络的延迟或抖动非常敏感。如有抖动造成 Redis Master 超时,会由 Sentinel 重新选出一个新的节点成为 Master,再把该节点上的数据同步到所有 Slave 上,此过程中数据会放在 Master 节点的 Buffer 里,如果写入的 QPS 很高会造成 Buffer 满溢。如果 Buffer 满后 RDB 文件还没有拷贝过去,重建过程就会失败。 基于这种情况,我们对 Redis 告警做了自动化优化,如有大量 master - slave 重建失败,我们会动态调整一些参数,例如把 Buffer 临时调大等, 此外我们还做了 Redis 集群的自动扩缩容功能。 我们在做 Redis 开发时如果是 Java 语言都会用到 Jedis。用 Jedis 访问客户端分片的 Redis 集群,如果某个分片发生了故障或者 failover,Jedis 就会对所有后端的分片重建连接。如果某一分片发生问题,整个 Redis 的访问性能和 QPS 会大幅降低。针对这个情况我们优化了 Jedis,如果某个分片发生故障,就只针对这个分片进行重建。 在业务访问 Redis 时我们会对 Master 绑定一个读写域名,多个从库绑定读域名。但如果我们进行 Master failover,会将读写域名从某旧 Master 解绑,再绑定到新 Master 节点上。 DNS 本身有一个超时时间,所以数据库做完 failover 后业务程序里没有立刻获取到新的 Master 节点的 IP的话,有可能还会连到原来的机器上,造成访问失败。 我们的解决方法是把 DNS 的 TTL 缩短,但对 DNS 服务又会造成很大的压力,所以我们在 SDK 上提供 Redis 的名字服务 RNS,RNS 从 Sentinel 里获取集群的拓扑和拓扑的变化情况,如果集群 failover,Sentinel 会接到通知,客户端就可以通过 RNS 来获取新的 Master 节点的 IP 地址。我们去掉域名,通过 IP 地址来访问整个集群,屏蔽了 DNS 的超时,缩短了故障的恢复时间。 SDK 上还做了一些功能,例如 Load Balance 以及故障检测,比如某个节点延时较高的话会被临时熔断等。 客户端分片的方式会造成 Redis 的扩容非常痛苦,如果客户端已经进行了一定量的分片,之后再增加就会非常艰难。 Redis 在 3.0 版本后会提供 Redis Cluster,因为功能受限在爱奇艺应用的不是很多,例如不支持显示跨 DC 部署和访问,读写只在主库上等。 我们某些业务场景下会使用 Redis 集群,例如数据库访问只发生在本 DC,我们会在 DC 内部进行 Cluster 部署。 但有些业务在使用的过程中还是想做 failover,如果集群故障可以切换到其他集群。根据这种情况我们做了一个 Proxy,读写都通过它来进行。写入数据时 Proxy 会做一个旁路,把新增的数据写在 Kafka 里,后台启用同步程序再把 Kafka 里的数据同步到其他集群,但存在一些限制,比如我们没有做冲突检测,所以集群间数据需要业务的同学做单元化。线上环境的Redis Cluster 集群间场景跨 DC 同步 需要 50 毫秒左右的时间。 2、Couchbase在爱奇艺的使用 Redis 虽然提供 Cluster 这种部署方式,但存在一些问题。所以数据量较大的时候(经验是 160G),就不推荐 Redis 了,而是采用另一种存储方式 Couchbase。 Couchbase 在国内互联网公司用的比较少,一开始我们是把他当做一个 Memcached 来使用的,即纯粹的缓存系统。 但其实它性能还是比较强大的,是一个分布式高性能的 KV 系统,支持多种存储引擎 (bucket)。第一种是 Memcached bucket,使用方式和 Memcached 一样为 KV 存储,不支持数据持久化也没有数据副本,如果节点故障会丢失数据; 第二种是 Couchbase bucket,支持数据持久化,使用 Json 写入,有副本,我们一般会在线上配置两个副本,如果新加节点会对数据进行 rebalance,爱奇艺使用的一般是 Couchbase bucket 这种配置。 Couchbase 数据的分布如下图,数据写入时在客户端上会先进行一次哈希运算,运算完后会定位 Key 在哪一个 vBucket (相当于数据库里的某个分片)。之后客户端会根据 Cluster Map 发送信息至对应的服务端,客户端的 Cluster Map 保存的是 vBucket 和服务器的映射关系,在服务端数据迁移的过程中客户端的 Cluster Map 映射关系会动态更新,因此客户端对于服务端的 failover 操作不需要做特殊处理,但可能在 rebalance 过程中会有短暂的超时,导致的告警对业务影响不大。 Couchbase 在爱奇艺应用比较早,2012 年还没有 Redis Cluster 的时候就开始使用了。集群管理使用 erlang 语言开发,最大功能是进行集群间的复制,提供多种复制方式:单向、双向、星型、环式、链式等。 爱奇艺从最初的 1.8 版本使用到如今的 5.0 版本,正在调研的 6.0,中间也遇到了很多坑,例如 NTP 时间配置出错会导致崩溃,如果每个集群对外 XDCR 并发过高导致不稳定,同步方向变更会导致数据丢失等等,我们通过运维和一些外部工具来进行规避。 Couchbase 的集群是独立集群,集群间的数据同步通过 XDCR,我们一般配置为双向同步。对于业务来说,如果 Cluster 1 写入, Cluster 2 不写入,正常情况下客户端会写 Cluster 1。如果 Cluster 1 有故障,我们提供了一个 Java SDK,可以在配置中心把写入更改到 Cluster 2,把原来到 Cluster 1 的连接逐步断掉再与Cluster 2 新建连接。这种集群 failover 的过程对于客户端来说是相对透明和无感的。 3、爱奇艺自研数据库HiKV的使用 Couchbase 虽然性能非常高,并且数据的存储可以超过内存。但是,如果数据量超过内存 75% 这个阈值,性能就会下降地特别快。在爱奇艺,我们会把数据量控制在可用内存的范围之内,当做内存数据库使用。但是它的成本非常高,所以我们后面又开发了一个新的数据库—— HiKV。 开发 HiKV 的目的是为了把一些对性能要求没那么高的 Couchbase 应用迁移到 HiKV 上。HiKV 基于开源系统 ScyllaDB,主要使用了其分布式数据库的管理功能,增加了单机存储引擎 HiKV。 ScyllaDB 比较吸引人的是它宣称性能高于 Cassandra 十倍,又完全兼容 Cassandra 接口,设计基本一致,可以视为 C++ 版 Cassandra 系统。 ScyllaDB 性能的提升主要是使用了一些新的技术框架,例如 C++ 异步框架 seastar,主要原理是在j每台物理机的核上会 attach 一个应用线程,每个核上有自己独立的内存、网络、IO 资源,核与核之间没有数据共享但可以通信,其最大的好处是内存访问无锁,没有冲突过程。 当一个数据读或写到达 ScyllaDB 的 server 时,会按照哈希算法来判断请求的 Key 是否是该线程需要处理的,如果是则本线程处理,否则会转发到对应线程上去。 除此之外,它还支持多副本、多数据中心、多写多活,功能比较强大。 在爱奇艺,我们基于 SSD 做了一个 KV 存储引擎。Key 放在内存里,Value 放在盘上的文件里,我们在读和写文件时,只需要在内存索引里定位,再进行一次盘的 IO 开销就可以把数据读出来,相比 ScyllaDB 原本基于 LSM Tree 的存储引擎方式对 IO 的开销较少。 索引数据全部放在内存中,如果索引长度较长会限制单机可存储的数据量,于是我们通过开发定长的内存分布器,对于比较长的 Key 做摘要缩短长度至 20 字节,采用红黑树索引,限制每条记录在内存里的索引长度至为 64 字节。内存数据要定期做 checkpoint,客户端要做限流、熔断等。 HiKV 目前在爱奇艺应用范围比较大,截至目前已经替换了 30% 的 Couchbase,有效地降低了存储成本。 4、爱奇艺的数据库运维管理 爱奇艺数据库种类较多,如何高效地运维和管理这些数据库也是经历了不同的阶段。 最初我们通过 DBA 写脚本的方式管理,如果脚本出问题就找 DBA,导致了 DBA 特别忙碌。 第二个阶段我们考虑让大家自己去查问题的答案,于是在内部构建了一个私有云,通过 Web 的方式展示数据库运行状态,让业务的同学可以自己去申请集群,一些简单的操作也可以通过自服务平台实现,解放了 DBA。一些需要人工处理的大型运维操作经常会造成一些人为故障,敲错参数造成数据丢失等。 于是在第三个阶段我们把运维操作 Web 化,通过网页点击可以进行 90% 的操作。 第四个阶段让经验丰富的 DBA 把自身经验变成一些工具,比如有业务同学说 MySQL master-slave 延时了,DBA 会通过一系列操作排查问题。现在我们把这些操作串起来形成一套工具,出问题时业务的同学可以自己通过网页上的一键诊断工具去排查,自助进行处理。 除此之外我们还会定期做预警检查,对业务集群里潜在的问题进行预警报告;开发智能客服,回答问题;通过监控的数据对实例打标签,进行削峰填谷地智能调度,提高资源利用率。 三、不同场景下数据库选型建议 1、实用数据库选型树 最后来说一些具体数据库选型建议。这是 DBA 和业务一起,通过经验得出来的一些结论。 对于关系型数据库的选型来说,可以从数据量和扩展性两个维度考虑,再根据数据库有没有冷备、要不要使用 Toku 存储引擎,要不要使用 Proxy 等等进行抉择。 NoSQL 也是什么情况下使用 master-slave,什么情况下使用客户端分片、集群、Couchbase、HiKV 等,我们内部自服务平台上都有这个选型树信息。 2、一些思考 ① 需求 我们在选型时先思考需求,判断需求是否真实。 你可以从数据量、QPS、延时等方面考虑需求,但这些都是真实需求吗?是否可以通过其他方式把这个需求消耗掉,例如在数据量大的情况下可以先做数据编码或者压缩,数据量可能就降下来了。 不要把所有需求都推到数据库层面,它其实是一个兜底的系统。 ② 选择 第二个思考的点是对于某个数据库系统或是某个技术选型我们应该考虑什么?是因为热门吗?还是因为技术上比较先进?但是不是能真正地解决你的问题?如果你数据量不是很大的话就不需要选择可以存储大数据量的系统。 ③ 放弃 第三是放弃,当你放弃一个系统时真的是因为不好用吗?还是没有用好?放弃一个东西很难,但在放弃时最好有一个充分的理由,包括实测的结果。 ④ 自研 第四是自研,在需要自己开发数据库时可以参考和使用一些成熟的产品,但不要盲目自研。 ⑤ 开源 最后是开源,要有拥抱开源的态度。

茶什i 2019-12-27 14:17:56 0 浏览量 回答数 0
阿里云大学 云服务器ECS com域名 网站域名whois查询 开发者平台 小程序定制 小程序开发 国内短信套餐包 开发者技术与产品 云数据库 图像识别 开发者问答 阿里云建站 阿里云备案 云市场 万网 阿里云帮助文档 免费套餐 开发者工具 SSL证书 小程序开发制作 视频内容分析 企业网站制作 视频集锦 代理记账服务 2020阿里巴巴研发效能峰会 企业建站模板 云效成长地图 高端建站 2020中国云原生 阿里云云栖号