• 关于

    非交互控制出问题什么情况

    的搜索结果

问题

百问百答 《Java开发手册(嵩山版)》

从java命名标准来讲,代码中的命名需要注意什么? java中类名命名是用什么规则,有什么情形是例外的? POJO类中的布尔类型变量要不要加is前缀,为什么ÿ...
不语奈何 2021-03-25 13:30:32 28 浏览量 回答数 0

问题

【百问百答】《2021前端热门技术解读》

1、前端安全生产水位远远满足不了当前的诉求,发展上颇显迟钝,这背后这背后反应了哪3个问题? 2、前端可用性的困局有哪些? 3、什么是混沌工程? 4、混沌工程强调了哪五大要素࿱...
6rmarpmlfunbi 2021-03-25 20:32:34 37 浏览量 回答数 0

回答

DMS for linux 6月23日更新预告,敬请期待 更新啦!更新啦!更新啦!本周(6月28号)dms for linux 将发布新版本,内容如下,尽情期待         1、命令终端支持rz文件上传命令,只要能ssh登陆,无论跳几级,都可以上传。支持目录哦,真心赞!具体包括: 文件/目录点击上传; 文件/目录拖动上传; 命令行文件上传进度;                       2、服务管理兼容centos7+的systemd协议的管理,提供更高效地服务管理模式                    3、右上角开放更直接的问题反馈入口,链接可以直达本帖,如果您在使用过程中遇到什么问题,或者对我们产品有什么诉求,欢迎轰炸我们程序员GG哦,我们会第一时间内反馈。 ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- 如果您第一次点入本帖,欢迎使用阿里云数据管理产品: https://dms.console.aliyun.com/#/dms/rsList 阿里云数据管理旨在一站式管理您所有云上资源 ------------------------- 回 2楼(龙吟风) 的帖子 数据管理DMS支持数据库管理、Linux管理,无需安装,易用专业,目前在云上已经有30W用户,你可以试下 https://www.aliyun.com/product/dms ------------------------- 回 6楼(大一中) 的帖子 谢谢支持,O(∩_∩)O哈哈~ ------------------------- 各位在使用dms的过程中遇到什么问题,或者有什么建议,直接在这个帖子下面提问喔 ------------------------- 回 9楼(付一二) 的帖子 您好,谢谢反馈,您说的这种是不是针对类似于apache的应用配置管理?我们目前已经正在计划深挖常用应用的管理功能包括apache,mysql等,包括配置管理,服务性能监控等,这个的确对服务的运维很有用处。我们会在后续版本加入此功能,敬请期待哦,O(∩_∩)O~。 ------------------------- 回 11楼(cokll) 的帖子        抱歉给您工作带来不便,请问这个问题只是出现在实时监控模块吗?其他模块没有报这个错么?        这个问题主要原因是您当前主机的sshd服务对单个session上的channel数量作了限制导致的。dms for linux 的实时监控模块在加载页面时需要建立多个channel执行命令,如果当前保持的channel的数量超出您主机的限制,继续建立channel就会抛出channel未打开的错误,这个配置项是/etc/ssh/sshd_config 里面的MaxSessions的配置。        我刚刚检查了一下我们的代码,发现代码中存在长时间保持单个channel的情况,导致新建channel不成功。我们代码中的bug将在下一个版本修复(约7月13号(周三))。届时请如果还有问题,请及时联系我们喔。       再次感谢您的反馈。    ------------------------- 回 11楼(cokll) 的帖子 您好,麻烦检查下您机器上的/etc/ssh/sshd_config 中是否有配置过MaxSessions这个参数,如果最大的session数被限制为1,您主机只能支持终端登陆,就用不了dms for linux的其他的功能了。 我们经过测试,能支持dms的最小的session数量为3,也就是MaxSession的值应当不小于3(默认值为10)。如果可以的话,您可以修正下这个配置然后重启下sshd服务。 如果还有问题,烦请及时反馈,谢谢亲 ------------------------- 回 15楼(山水佳) 的帖子 您好, 抱歉回复晚了,请问您是使用实时监控的查看线程栈的功能遇到这个错误的吗?实时监控模块一般不会抛出这个错,可否截一下图看看? ------------------------- 回 18楼(caesar.w.h) 的帖子 您好, 感谢您的反馈,请问您当前用的是什么浏览器?有没有在浏览器上做过某些安全性的限制? 这个问题一般是浏览器禁用了跨域请求导致我们dms控制台的登陆请求没法到达dms应用的服务器。 我们建议一般使用chrome或者火狐浏览器访问dms,如果可以的话可以换一下浏览器重新尝试下。。 如果还有问题请保持沟通过哦O(∩_∩)O~ ------------------------- 回 22楼(caesar.w.h) 的帖子 您好,抱歉回复晚了,请问是所有数据库实例都添加不了还是仅一个实例是这样? 如果仅一个实例,那么这个实例是什么类型的数据库? 如果所有实例都添加不了,有没有尝试过把浏览器卸载重装后结果还是一样?或者是,用一台新机器上的浏览器试试是否是相同的情况? 这个问题我们之前是遇到过的,主要原因是添加数据库的请求没有发送出去,还没到连接数据库那一步呢,可能是浏览器阻拦的原因,上次我们也是通过更换浏览器解决的。麻烦您按照上面的步骤再尝试下,如果还不行的话,还请保持联系噢。 感谢您对dms的支持O(∩_∩)O~ ------------------------- 回 24楼(無名塵客) 的帖子 您好,这个问题您是否已经通过工单和我们客服团队反馈过? 抱歉给您带来不便,这个问题具体原因是这样的: 您这个实例是mysql5.1版本,不支持INNODB_BUFFER_POOL_READ_REQUESTS,INNODB_BUFFER_POOL_READS这两个参数导致我们dms首页会出现500错误。目前dms支持的mysql版本是5.4之后的版本。 这个问题涉及到对老版本mysql的兼容,具体怎么改得和我们负责这一块的开发人员沟通下 ------------------------- 回 26楼(caesar.w.h) 的帖子 您好,请问用谷歌浏览器具体是什么情况?登陆会报什么错? 目前我们后台统计,使用dms的大部分是chrome用户,没有遇到类似的问题,可能是浏览器中存在某些插件原因吧。 ------------------------- 回 30楼(斯斯) 的帖子 谢谢反馈,这个问题我们已经在看,主要原因是我们现在的监控模块对部分主机的性能数据兼容性不够强,也说明我们的代码健壮性不够强。 目前我们正在查看日志寻找错误原因,预计下个发布可以修复(约下周二之前),届时麻烦线上验证下。谢谢 ------------------------- 引用第32楼ivmmff于2016-07-27 14:31发表的  : 命令终端不能粘贴命令太蛋疼 [url=https://bbs.aliyun.com/job.php?action=topost&tid=286015&pid=807524][/url] 您好,目前我们没有支持右键粘贴的功能。 您可以使用Ctrl + V、Shift + Insert 等方式进行粘贴。 后续我们会支持右键粘贴的功能,感谢您的关注。 ------------------------- 回 31楼(galphy) 的帖子 你好,目前我们没有对命令终端的操作超时做控制,正常情况下没有操作,至少6分钟之后才会断开,如果少于6分钟,可能是您主机设置了空闲超时时间。 请参考一下: http://blog.chinaunix.net/uid-8473611-id-3069386.html 后续我们会加上链接超时控制,届时您可以自己设置超时时间,敬请期待。 ------------------------- 回 29楼(胡胡abc) 的帖子 您好,请问这台主机是linux是什么发行版本,是ECS么? ------------------------- 回 30楼(斯斯) 的帖子 不好意思哦,刚刚我们翻了下日志,并没能找到有记录ArrayIndexOutOfBound的错误。为了节省沟通成本,能否提供一下您当前主机的ip,和权限比较低的账号,密码供我们测试下? 如果可以的话能否提供下旺旺账号,我们可以去加你下。或者可以加我的账号,旺旺搜索"帅博"。 希望能高效地解决您的问题,感谢支持。 ------------------------- 回 43楼(不羁的行者) 的帖子 你好,目前文件管理模块还不支持上传文件夹。 建议打开dms的命令终端,直接输入rz命令上传噢。支持文件,文件夹,批量上传,拖动上传,功能很好用噢,O(∩_∩)O~ ------------------------- 回 48楼(fightgod) 的帖子 您好,我们以后会加入设置终端声音的功能,下个版本我们会暂时先去掉终端声音,等设置功能上线后再加上。O(∩_∩)O~ ------------------------- 回 50楼(fightgod) 的帖子 您好,windows系统和linux相比其内部机制和实现方式要复杂很多,目前我们的技术宅们正努力探索中。。。。 一旦技术方案定下来我们就会开展实施支持windows系统,敬请期待哦O(∩_∩)O~ ------------------------- 回 63楼(woaj01) 的帖子 您好,请问您的那台主机在ECS上已被删除多久了?我们这边也是通过api从ECS那边取的主机列表,api返回的数据会有一定的延迟,但也不会很久。 如果您的主机已经删除很久了,麻烦请告诉我们,我们会去和ECS方面沟通,解决这一问题 ------------------------- 回 66楼(fightgod) 的帖子 您好,您提的批量操作命令的界面,我们会认真考虑,如何去优化在主机较多的时候用户对终端返回的信息的同步。 您说的批量文件上传方面,我们恰巧将近期上线批量rz的功能,敬请期待哦O(∩_∩)O~ ------------------------- 回 69楼(初一) 的帖子 你好,能否详述一下你遇到的问题,是什么功能授权失败? ------------------------- 回 72楼(汇爱家) 的帖子 您好,您的建议我们会记录,并选择合适的配色方案,改进我们的用户体验,感谢反馈 ------------------------- 回 75楼(初一) 的帖子 您好,目前dms for linux的文件管理是支持更改文件所有者的。您可以右键->授权,弹出的授权框中可以更改所有者和用户组的信息。                                                                                      ------------------------- 回 76楼(meenet) 的帖子 您好,您是指怎么在线编辑文件? 我们的文件管理的功能可以直接编辑和保存文件的,如果是二进制文件还可以直接用二进制的方式打开,类似于UE的功能。 ------------------------- 回 79楼(啊彬彬) 的帖子 你好,请问你重启的是什么服务?一些系统服务是不能关闭的,关闭会导致系统不稳定甚至崩溃,重启下主机就可以恢复了。 ------------------------- 回 85楼(koder) 的帖子 您好,如果使用证书登录后目前仅可以查看非sudo权限的服务状态,需要sudo权限的服务,暂时是获取不到信息,通过控制台的系统管理-->服务管理可以进入相应页面。如果您想看所有服务的状态请先到控制台切换密码登陆。您的密码在我们后台都是经过严格加密处理的,所以您不用担心安全问题。 后续我们会针对证书登录用户,提供临时输入密码的交互。敬请继续关注我们dms产品 ------------------------- 回 86楼(樱花雾翔eva) 的帖子 您好,抱歉,我们dms控制台目前不支持删除数据库和ecs资源,资源列表是从ecs和rds控制台同步过来的,如果有资源过期被释放,dms控制台上相应也会释放。 我们后续控制台会加入资源隐藏的选项,可以暂时隐藏暂时不用的资源。感谢关注dms产品 ------------------------- 回 92楼(jasonyao525) 的帖子 您好,ssh服务关闭后就不能使用dms了,命令终端也不可以使用,您可以通过ecs控制台或者联系客服来重新开启该服务。 ------------------------- 回 90楼(jrl_limeng) 的帖子 您好,终端的颜色我们之前已经调整过,能否截个图看看?
数据管理dms 2019-12-02 02:01:24 0 浏览量 回答数 0

问题

为什么很多程序员和IT公司讨厌敏捷开发?

你有没有遇到过这些言论——大多是抱怨,当涉及到应用敏捷的时候? 敏捷不注重正确的文档 敏捷无视流程和规定 敏捷无视公司计划和目的 敏捷不注重法律程序,并且对客户不承担责任。 等等&#...
技术小菜鸟 2019-12-01 21:19:53 3132 浏览量 回答数 2

问题

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

Maven本地仓库配置报错:配置报错  GO语言配置什么的都没问题,但就是LiteIDE配置不好。。。:配置报错  Maven 配置nexus仓库 POM文件报错:配置报错  10个你可能从未用过的PHP函数:配置报错  QT...
问问小秘 2020-06-11 13:18:25 6 浏览量 回答数 1

问题

HBase查询优化

转载自:http://www.hbase.group/article/38 1.概述 HBase是一个实时的非关系型数据库,用来存储海量数据。但是,在实际使用场景中,在使用HBas...
pandacats 2019-12-20 21:09:28 0 浏览量 回答数 0

问题

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

为了方便python开发者快速找到相关技术问题和答案,开发者社区策划了python技术1000问内容,包含最基础的如何学python、实践中遇到的技术问题、python面试等维度内容。 我们会以每天至少50条的...
问问小秘 2019-12-01 21:57:48 456417 浏览量 回答数 22

回答

在开始谈我对架构本质的理解之前,先谈谈对今天技术沙龙主题的个人见解,千万级规模的网站感觉数量级是非常大的,对这个数量级我们战略上 要重 视 它 , 战术上又 要 藐 视 它。先举个例子感受一下千万级到底是什么数量级?现在很流行的优步(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

回答

从业余程序员到职业程序员 程序员刚入行时,我觉得最重要的是把自己培养成职业的程序员。 我的程序员起步比同龄人都晚了很多,更不用说现在的年轻人了。我大学读的是生物专业,在上大学前基本算是完全没接触过计算机。军训的时候因为很无聊,我和室友每天跑去学校的机房玩,我现在还印象很深刻,我第一次走进机房的时候,别人问,你是要玩windows,还是dos,我那是完全的一抹黑。后来就只记得在机房一堆人都是在练习盲打,军训完,盲打倒是练的差不多了,对计算机就这么产生了浓厚的兴趣,大一的时候都是玩组装机,捣鼓了一些,对计算机的硬件有了那么一些了解。 到大二后,买了一些书开始学习当时最火的网页三剑客,学会了手写HTML、PS的基本玩法之类的,课余、暑假也能开始给人做做网站什么的(那个时候做网站真的好赚钱),可能那样过了个一年左右,做静态的网页就不好赚钱了,也不好找实习工作,于是就开始学asp,写些简单的CRUD,做做留言板、论坛这些动态程序,应该算是在这个阶段接触编程了。 毕业后加入了深圳的一家做政府行业软件的公司,一个非常靠谱和给我空间的Leader,使得自己在那几年有了不错的成长,终于成了一个职业的程序员。 通常来说,业余或半职业的程序员,多数是1个人,或者很小的一个团队一起开发,使得在开发流程、协作工具(例如jira、cvs/svn/git等)、测试上通常会有很大的欠缺,而职业的程序员在这方面则会专业很多。另外,通常职业的程序员做的系统都要运行较长的时间,所以在可维护性上会特别注意,这点我是在加入阿里后理解更深的。一个运行10年的系统,和一个写来玩玩的系统显然是有非常大差别的。 这块自己感觉也很难讲清楚,只能说模模糊糊有个这样的概念。通常在有兴趣的基础上,从业余程序员跨越到成为职业程序员我觉得不会太难。 编程能力的成长 作为程序员,最重要的能力始终是编程能力,就我自己的感受而言,我觉得编程能力的成长主要有这么几个部分: 1、编程能力初级:会用 编程,首先都是从学习编程语言的基本知识学起的,不论是什么编程语言,有很多共同的基本知识,例如怎么写第一个Hello World、if/while/for、变量等,因此我比较建议在刚刚开始学一门编程语言的时候,看看编程语言自己的一些文档就好,不要上来就去看一些高阶的书。我当年学Java的时候上来就看Think in Java、Effective Java之类的,真心好难懂。 除了看文档以外,编程是个超级实践的活,所以一定要多写代码,只有这样才能真正熟练起来。这也是为什么我还是觉得在面试的时候让面试者手写代码是很重要的,这个过程是非常容易判断写代码的熟悉程度的。很多人会说由于写代码都是高度依赖IDE的,导致手写很难,但我绝对相信写代码写了很多的人,手写一段不太复杂的、可运行的代码是不难的。即使像我这种三年多没写过代码的人,让我现在手写一段不太复杂的可运行的Java程序,还是没问题的,前面N年的写代码生涯使得很多东西已经深入骨髓了。 我觉得编程能力初级这个阶段对于大部分程序员来说都不会是问题,勤学苦练,是这个阶段的核心。 2、编程能力中级:会查和避免问题 除了初级要掌握的会熟练的使用编程语言去解决问题外,中级我觉得首先是提升查问题的能力。 在写代码的过程中,出问题是非常正常的,怎么去有效且高效的排查问题,是程序员群体中通常能感受到的大家在编程能力上最大的差距。 解决问题能力强的基本很容易在程序员群体里得到很高的认可。在查问题的能力上,首先要掌握的是一些基本的调试技巧,好用的调试工具,在Java里有JDK自带的jstat、jmap、jinfo,不在JDK里的有mat、gperf、btrace等。工欲善其事必先利其器,在查问题上是非常典型的,有些时候大家在查问题时的能力差距,有可能仅仅是因为别人比你多知道一个工具而已。 除了调试技巧和工具外,查问题的更高境界就是懂原理。一个懂原理的程序员在查问题的水平上和其他程序员是有明显差距的。我想很多的同学应该能感受到,有些时候查出问题的原因仅仅是因为有效的工具,知其然不知其所以然。 我给很多阿里的同学培训过Java排查问题的方法,在这个培训里,我经常也会讲到查问题的能力的培养最主要的也是熟练,多尝试给自己写一些会出问题的程序,多积极的看别人是怎么查问题的,多积极的去参与排查问题,很多最后查问题能力强的人多数仅仅是因为“无他,但手熟尔”。 我自己排查问题能力的提升主要是在2009年和2010年。那两年作为淘宝消防队(处理各种问题和故障的虚拟团队)的成员,处理了很多的故障和问题。当时消防队还有阿里最公认的技术大神——多隆,我向他学习到了很多排查问题的技巧。和他比,我排查问题的能力就是初级的那种。 印象最深刻的是一次我们一起查一个应用cpu us高的问题,我们两定位到是一段代码在某种输入参数的时候会造成cpu us高的原因后,我能想到的继续查的方法是去生产环境抓输入参数,然后再用参数来本地debug看是什么原因。但多隆在看了一会那段代码后,给了我一个输入参数,我拿这个参数一运行,果然cpu us很高!这种case不是一次两次。所以我经常和别人说,我是需要有问题场景才能排查出问题的,但多隆是完全有可能直接看代码就能看出问题的,这是本质的差距。 除了查问题外,更厉害的程序员是在写代码的过程就会很好的去避免问题。大家最容易理解的就是在写代码时处理各种异常情况,这里通常也是造成程序员们之间很大的差距的地方。 写一段正向逻辑的代码,大部分情况下即使有差距,也不会太大,但在怎么很好的处理这个过程中有可能出现的异常上,这个时候的功力差距会非常明显。很多时候一段代码里处理异常逻辑的部分都会超过正常逻辑的代码量。 我经常说,一个优秀程序员和普通程序员的差距,很多时候压根就不需要看什么满天飞的架构图,而只用show一小段的代码就可以。 举一个小case大家感受下。当年有一个严重故障,最后查出的原因是输入的参数里有一个是数组,把这个数组里的值作为参数去查数据库,结果前面输入了一个很大的数组,导致从数据库查了大量的数据,内存溢出了,很多程序员现在看都会明白对入参、出参的保护check,但类似这样的case我真的碰到了很多。 在中级这个阶段,我会推荐大家尽可能的多刻意的去培养下自己这两个方面的能力,成为一个能写出高质量代码、有效排查问题的优秀程序员。 3、编程能力高级:懂高级API和原理 就我自己的经历而言,我是在写了多年的Java代码后,才开始真正更细致的学习和掌握Java的一些更高级的API,我相信多数Java程序员也是如此。 我算是从2003年开始用Java写商业系统的代码,但直到在2007年加入淘宝后,才开始非常认真地学习Java的IO通信、并发这些部分的API。尽管以前也学过也写过一些这样的代码,但完全就是皮毛。当然,这些通常来说有很大部分的原因会是工作的相关性,多数的写业务系统的程序员可能基本就不需要用到这些,所以导致会很难懂这些相对高级一些的API,但这些API对真正的理解一门编程语言,我觉得至关重要。 在之前的程序员成长路线的文章里我也讲到了这个部分,在没有场景的情况下,只能靠自己去创造场景来学习好。我觉得只要有足够的兴趣,这个问题还是不大的,毕竟现在有各种开源,这些是可以非常好的帮助自己创造机会学习的,例如学Java NIO,可以自己基于NIO包一个框架,然后对比Netty,看看哪些写的是不如Netty的,这样会非常有助于真正的理解。 在学习高级API的过程中,以及排查问题的过程中,我自己越来越明白懂编程语言的运行原理是非常重要的,因此我到了后面的阶段开始学习Java的编译机制、内存管理、线程机制等。对于我这种非科班出身的而言,学这些会因为缺乏基础更难很多,但这些更原理性的东西学会了后,对自己的编程能力会有质的提升,包括以后学习其他编程语言的能力,学这些原理最好的方法我觉得是先看看一些讲相关知识的书,然后去翻看源码,这样才能真正的更好的掌握,最后是在以后写代码的过程中、查问题的过程中多结合掌握的原理,才能做到即使在N年后也不会忘。 在编程能力的成长上,我觉得没什么捷径。我非常赞同1万小时理论,在中级、高级阶段,如果有人指点或和优秀的程序员们共事,会好非常多。不过我觉得这个和读书也有点像,到了一定阶段后(例如高中),天分会成为最重要的分水岭,不过就和大部分行业一样,大部分的情况下都还没到拼天分的时候,只需要拼勤奋就好。 系统设计能力的成长 除了少数程序员会进入专深的领域,例如Linux Kernel、JVM,其他多数的程序员除了编程能力的成长外,也会越来越需要在系统设计能力上成长。 通常一个编程能力不错的程序员,在一定阶段后就会开始承担一个模块的工作,进而承担一个子系统、系统、跨多领域的更大系统等。 我自己在工作的第三年开始承担一个流程引擎的设计和实现工作,一个不算小的系统,并且也是当时那个项目里的核心部分。那个阶段我学会了一些系统设计的基本知识,例如需要想清楚整个系统的目标、模块的划分和职责、关键的对象设计等,而不是上来就开始写代码。但那个时候由于我是一个人写整个系统,所以其实对设计的感觉并还没有那么强力的感觉。 在那之后的几年也负责过一些系统,但总体感觉好像在系统设计上的成长没那么多,直到在阿里的经历,在系统设计上才有了越来越多的体会。(点击文末阅读原文,查看:我在系统设计上犯过的14个错,可以看到我走的一堆的弯路)。 在阿里有一次做分享,讲到我在系统设计能力方面的成长,主要是因为三段经历,负责专业领域系统的设计 -> 负责跨专业领域的专业系统的设计 -> 负责阿里电商系统架构级改造的设计。 第一段经历,是我负责HSF。HSF是一个从0开始打造的系统,它主要是作为支撑服务化的框架,是个非常专业领域的系统,放在整个淘宝电商的大系统来看,其实它就是一个很小的子系统,这段经历里让我最深刻的有三点: 1).要设计好这种非常专业领域的系统,专业的知识深度是非常重要的。我在最早设计HSF的几个框的时候,是没有设计好服务消费者/提供者要怎么和现有框架结合的,在设计负载均衡这个部分也反复了几次,这个主要是因为自己当时对这个领域掌握不深的原因造成的; 2). 太技术化。在HSF的阶段,出于情怀,在有一个版本里投入了非常大的精力去引进OSGi以及去做动态化,这个后来事实证明是个非常非常错误的决定,从这个点我才真正明白在设计系统时一定要想清楚目标,而目标很重要的是和公司发展阶段结合; 3). 可持续性。作为一个要在生产环境持续运行很多年的系统而言,怎么样让其在未来更可持续的发展,这个对设计阶段来说至关重要。这里最low的例子是最早设计HSF协议的时候,协议头里竟然没有版本号,导致后来升级都特别复杂;最典型的例子是HSF在早期缺乏了缺乏了服务Tracing这方面的设计,导致后面发现了这个地方非常重要后,全部落地花了长达几年的时间;又例如HSF早期缺乏Filter Chain的设计,导致很多扩展、定制化做起来非常不方便。 第二段经历,是做T4。T4是基于LXC的阿里的容器,它和HSF的不同是,它其实是一个跨多领域的系统,包括了单机上的容器引擎,容器管理系统,容器管理系统对外提供API,其他系统或用户通过这个来管理容器。这个系统发展过程也是各种犯错,犯错的主要原因也是因为领域掌握不深。在做T4的日子里,学会到的最重要的是怎么去设计这种跨多个专业领域的系统,怎么更好的划分模块的职责,设计交互逻辑,这段经历对我自己更为重要的意义是我有了做更大一些系统的架构的信心。 第三段经历,是做阿里电商的异地多活。这对我来说是真正的去做一个巨大系统的架构师,尽管我以前做HSF的时候参与了淘宝电商2.0-3.0的重大技术改造,但参与和自己主导是有很大区别的,这个架构改造涉及到了阿里电商众多不同专业领域的技术团队。在这个阶段,我学会的最主要的: 1). 子系统职责划分。在这种超大的技术方案中,很容易出现某些部分的职责重叠和冲突,这个时候怎么去划分子系统,就非常重要了。作为大架构师,这个时候要从团队的职责、团队的可持续性上去选择团队; 2). 大架构师最主要的职责是控制系统风险。对于这种超大系统,一定是多个专业领域的架构师和大架构师共同设计,怎么确保在执行的过程中对于系统而言最重要的风险能够被控制住,这是我真正的理解什么叫系统设计文档里设计原则的部分。 设计原则我自己觉得就是用来确保各个子系统在设计时都会遵循和考虑的,一定不能是虚的东西,例如在异地多活架构里,最重要的是如何控制数据风险,这个需要在原则里写上,最基本的原则是可接受系统不可用,但也要保障数据一致,而我看过更多的系统设计里设计原则只是写写的,或者千篇一律的,设计原则切实的体现了架构师对目标的理解(例如当时异地多活这个其实开始只是个概念,但做到什么程度才叫做到异地多活,这是需要解读的,也要确保在技术层面的设计上是达到了目标的),技术方案层面上的选择原则,并确保在细节的设计方案里有对于设计原则的承接以及执行; 3). 考虑问题的全面性。像异地多活这种大架构改造,涉及业务层面、各种基础技术层面、基础设施层面,对于执行节奏的决定要综合考虑人力投入、机器成本、基础设施布局诉求、稳定性控制等,这会比只是做一个小的系统的设计复杂非常多。 系统设计能力的成长,我自己觉得最重要的一是先在一两个技术领域做到专业,然后尽量扩大自己的知识广度。例如除了自己的代码部分外,还应该知道具体是怎么部署的,部署到哪去了,部署的环境具体是怎么样的,和整个系统的关系是什么样的。 像我自己,是在加入基础设施团队后才更加明白有些时候软件上做的一个决策,会导致基础设施上巨大的硬件、网络或机房的投入,但其实有可能只需要在软件上做些调整就可以避免,做做研发、做做运维可能是比较好的把知识广度扩大的方法。 第二点是练习自己做tradeoff的能力,这个比较难,做tradeoff这事需要综合各种因素做选择,但这也是所有的架构师最关键的,可以回头反思下自己在做各种系统设计时做出的tradeoff是什么。这个最好是亲身经历,听一些有经验的架构师分享他们选择背后的逻辑也会很有帮助,尤其是如果恰好你也在同样的挑战阶段,光听最终的架构结果其实大多数时候帮助有限。 技术Leader我觉得最好是能在架构师的基础上,后续注重成长的方面还是有挺大差别,就不在这篇里写了,后面再专门来写一篇。 程序员金字塔 我认为程序员的价值关键体现在作品上,被打上作品标签是一种很大的荣幸,作品影响程度的大小我觉得决定了金字塔的层次,所以我会这么去理解程序员的金字塔。 当然,要打造一款作品,仅有上面的两点能力是不够的,作品里很重要的一点是对业务、技术趋势的判断。 希望作为程序员的大伙,都能有机会打造一款世界级的作品,去为技术圈的发展做出贡献。 由于目前IT技术更新速度还是很快的,程序员这个行当是特别需要学习能力的。我一直认为,只有对程序员这个职业真正的充满兴趣,保持自驱,才有可能在这个职业上做好,否则的话是很容易淘汰的。 作者简介: 毕玄,2007年加入阿里,十多年来主要从事在软件基础设施领域,先后负责阿里的服务框架、Hbase、Sigma、异地多活等重大的基础技术产品和整体架构改造。
茶什i 2020-01-10 15:19:35 0 浏览量 回答数 0

回答

按量付费计费规则说明一、“按量付费”介绍 阿里云全新推出的付费模式,按实际使用量后付费开通,可随时开启随时释放。 按需取用,按需付费,无需购买大量设备,相比于传统主机投入成本降低30%-80%;支持多种主流操作系统,让您以服务的方式使用计算及存储资源。 目前阿里云云服务器有两种付费模式:包年包月、按量付费。 二、“按量付费“计费说明 1、云服务器按量付费收费方式 1.1 采用阿里云账户先充值,后按实际用量结算方式进行结算。以小时为单位,按实际消费金额对账户余额进行扣费。 1.2 “按量付费”云服务器计费项包括:CPU、内存、数据盘、公网带宽(按固定带宽、按使用流量两种可选)。 2、开通说明 2.1 开通按量付费的云服务器,现金账户余额不得少于100.00元,如账户金额少于100.00元,需充值后方可开通。 3、计费说明 3.1 每小时计费总费用=CPU费用+内存费用+数据盘费用+公网带宽费用。 3.2 CPU、内存、数据盘:按固定费用每小时扣费; 3.3 公网带宽:固定带宽,按固定费用每小时扣费; 3.4 公网带宽:按使用流量,仅单向收取流出流量费用(0.8 元/GB),流入流量免费,按实际使用金额每小时扣费。例如您在1小时内公网流出流量为2.5GB,收取费用为2.5GB*0.8元/小时=2.0元。 4、结算说明 4.1 结算周期。以小时为单位整点结算(均以北京时间为准)。 开通时间建议: 整点开通才划算,非整点开通,按整点算钱!提前释放按整点周期算钱! 比如:您在1点20分开通,那么时间到2点的时候就算做1小时。所以尽量在整点后几分钟内开通,在整点前几分钟释放。 4.2 结算范围 实际开通时长(即云服务器从“开通”开启计费到“释放“结束计费,以小时为单位整点结算)因账户欠费而产生的账单,账户一旦充值系统将会自动结算。 若账号下有欠费账单,可能会导致无法结算其他订单或结算其他订单时系统会自动优先扣除欠费账单金额。 4.3 结算时间 以系统自动结算时间为准 。 温馨提醒:避免超出预期开通时长,请设置自动释放服务时间!(可进入”用户中心“-”控制台“设置) 。 5、释放规则 5.1 按小时扣费后,“阿里云现金账户”出现欠费。 即在整点扣费时,(现金账户余额-账单中当周期整点结算的费用)<0时,按量付费的ECS将会欠费停机,从停机时刻起数据保留7天(即168小时,自行设置释放的除外),7天后实例以及实例相关数据(包括临时磁盘,云磁盘、随ECS实例释放的独立云磁盘,快照)均处于不可用状态,系统会回收相关欠费资源,数据无法找回。 欠费后,按量付费的云磁盘会被限制使用,无法实现正常的IO读写访问,会影响挂载该欠费磁盘的ECS实例正常运行,包括但不限于,应用程度读写性能低下,部分操作提示严重超时,某些操作系统版本下关机或重启失败等情况。 5.2 已设置自动释放时间的云服务器,会按照设置时间系统自动释放(按量付费服务器实例可能存在释放延迟,如果您设置释放时间点由于释放延迟进入下一计费周期,不会收取下一计费周期费用,只会针对您设置的释放时间点前的时间进行计费) 若按小时扣费后,“阿里云现金账户”余额为0元,”按量付费“的云服务器不遵循设置的系统释放时间,自账号为0元时起7天后实例以及实例相关数据(包括临时磁盘,云磁盘、随ECS实例释放的独立云磁盘,快照)都将被永久删除,数据无法找回。 5.3 提醒规则 余额不足提醒:以小时为单位整点结算后,若下一计费周期内账户可用余额小于上一周期账单金额,则发短信和邮件提醒; 释放通知:因到期/欠费释放,系统会短信和邮件通知。 6、举例 6.1 1:00整开通云服务器,1:00~2:00为第一个结算周期,实际开通时长60分钟算作1小时计费结算。 6.2 1:59分开通云服务器,1:00~2:00为第一个结算周期,实际开通时长1分钟算作1小时计费结算;2:01分释放云服务器,2:00~3:00为第二个结算周期,实际开通时长1分钟算作1小时计费结算,此用户需要支付2小时费用。 说明:此“ 释放 ”包括用户通过控制台自行操作释放、以小时为单位整点结算后现金账户欠费由系统触发的释放。请设置”自动释放服务时间“避免系统触发的释放导致超出预期的开通时长。 三、按量付费开通须知 1、”按量付费“均暂不支持更换配置 1.1 暂不支持配置变更功能(包括带宽升级、CPU和内存升级)。 若选择0M固定带宽:不分配外网IP,不支持0M带宽升级,请谨慎选择。 2、计费模式不支持更换 2.1 “包年包月“和”按量付费“不支持相互更换:1台云服务器只能选择1种,无法同时选择; 2.2 公网带宽:按固定带宽/按使用流量计费模式不支持相互更换,1台云服务器只能选择1种,无法同时选择。 3、金牌服务不支持 3.1 不提供备案服务。如果您的网站需要备案,请您包年包月购买,价更优! 3.2 不支持5天无理由退款 3.3 不支持免费数据迁移 4、代金券使用限制 仅支持有效期内通用券。 5、免费使用云盾、云监控、负载均衡 “按量付费”和“包年包月”仅计费模式不同,可同样免费使用云盾、云监控、负载均衡等阿里云产品。 四、常见问题 FAQ Q:按量付费我不能购买是什么原因? A: 请检查您是否已经通过实名认证,如果没有实名认证,建议您前往用户中心做实名认证。 目前按量付费是每个账号50台购买限制,如果您有超过50台的需求,可以根据提交工单申请按量高配。 由于管控限制,当某个地域售卖量达到限制的时候该地域会暂时关闭,建议您稍后再来尝试购买 Q:“固定带宽”和带宽“按使用流量”有什么区别? A: 固定带宽:买多少是多少; 带宽按使用流量:评估使用峰值,对带宽进行选择,按使用流量扣费。 Q:公网带宽“按使用流量”我应该选多少M才合适? A: 根据应用及实际使用情况进行选择。 Q:没有通过支付宝实名认证就不能购买“按量付费”云服务器吗? A: 是的,下单购买前,必须进行实名认证。Q:“按量付费”代金券能用吗? A:目前代金券账户仅限有效期内的通用券可用,请及时关注代金券的有效期 。 Q:如果金额不足,会提示么?什么时候提示?云服务器会直接停掉么? A:扣费后,若阿里云现金账户(代金券账户仅限有效期内的通用券可用)余额为0元,云服务器上的数据会保留7天后自动释放!详情查看《按量付费云服务器开通释放规则》 提醒规则: 余额不足提醒:每小时整点结算后仍有未释放的云服务器,若下一计费周期内账户可用余额小于上一周期账单金额,则发短信和邮件提醒;释放通知:因到期/欠费释放,系统会短信和邮件通知。 Q:账户余额不足,服务器数据会受影响吗? A:按小时扣费后,当“阿里云账户”出现欠费,即现金账户(代金券账户仅限有效期内的通用券可用)余额”为0元,“按量付费”的云服务器将不可用,如7天内没有续费,服务器将自动释放,数据不可恢复。 Q:一次性可以购买多少台云服务器?一个云帐号可以买几台云服务器? A:一次性最多可购买50台云服务器,一个云帐号下最多可以购买50台(包含50台)。 Q:结算时间怎么算?例如我1点30分钟开通,到2点,算半小时还是一小时? A:整点结算,以系统自动结算时间为准。算1小时。建议整点开通。 Q: 云服务器的地域是怎么选择的? A:地域可以自行选择。 Q:如果设置了带宽峰值,后期可以再进行调整吗? A:带宽峰值设置之后,就无法进行调整。 Q:我的服务器被攻击了,流量给我计费了?跟我自己检测流量差距很大,是什么原因? A:流量计费仅对出网带宽进行收费,网络攻击如属于入网带宽,则不会进行计费,如产生了出网带宽,会进行计费。推荐使用云盾进行攻击防护。 Q:能否自行关闭服务器? A:可以自行设置自动释放服务时间。 Q:“按量付费”,发票怎么开? A:可以开发票,申请发票时将基于月结算单开具发票,月结算单不可拆分开票,请您登录阿里云用户中心进行申请发票 。 Q:“按量付费”,能备案吗? A: 不提供备案服务,如果您的网站需要备案,请您包年包月购买,价更优! Q:能否支持5天内无理由退款? A:不支持 Q:是否支持百倍赔偿? A:支持。 Q:“按量计费”的云服务器(ECS)停机和关机后,还会产生费用吗? A:停机不产生费用,而关机将按正常计费规则收取费用。关机状态的按量付费ECS因服务时间到期或欠费时,将会变为“停机”状态。“停机”是指按量付费ECS到期或因欠费而自动停止服务的状态;而“关机”是指按量付费ECS在正常运行期间(账号余额>0元),用户在管理控制台中点击“停止”后,服务器即进入关机状态。 说明:按量付费的ECS停机后,数据保留7天后会自动释放;如需快速释放,您也可以登录ECS控制台->管理->释放,届时您ECS上的数据将立即被全部清除。 Q:“按量付费”的云服务器对内、对外产生的流量怎么收费的? A:同一局域网内的云服务器之间交互产生的流量全部免费,云服务器与公网交互产生的流量说明如下: 带宽按使用流量计费:互联网流入云服务器的流量是免费的,例如您通过云服务器从互联网上下载文件,阿里云不会收取任何费用,只有云服务器向互联网流出的流量才会产生费用。按固定带宽计费:在以单位价格购买的固定带宽上限之内,云服务器向互联网流出的流量都不会再另收取任何费用。
元芳啊 2019-12-01 23:23:10 0 浏览量 回答数 0

回答

工作流:   根据 WfMC 的定义,工作流(Workflow)就是自动运作的业务过程部分或整体,表现为参与者对文件、信息或任务按照规程采取行动,并令其在参与者之间传递。简单地说,工作流就是一系列相互衔接、自动进行的业务活动或任务。   工作流是针对工作中具有固定程序的常规活动而提出的一个概念。通过将工作活动分解成定义良好的任务、角色、规则和过程来进行执行和监控,达到提高生产组织水平和工作效率的目的。工作流技术为企业更好地实现经营目标提供了先进的手段。   1993年,国际工作流管理联盟(Workflow Management Coalition,WfMC)的成立标志着工作流技术开始进入相对成熟的阶段。为了实现不同工作流产品之间的互操作,WfMC在工作流管理系统的相关术语、体系结构及应用编程接口等方面制定了一系列标准。工作流管理联盟给出的工作流定义是:工作流是指整个或部分经营过程在计算机支持下的全自动或半自动化。在实际情况中可以更广泛地把凡是由计算机软件系统(工作流管理系统)控制其执行的过程都称为工作流。   一个工作流包括一组活动及它们的相互顺序关系,还包括过程及活动的启动和终止条件,以及对每个活动的描述。工作流管理系统指运行在一个或多个工作流引擎上用于定义、实现和管理工作流运行的一套软件系统,它与工作流执行者(人、应用)交互,推进工作流实例的执行,并监控工作流的运行状态。   一、工作流管理:   通常,工作流管理系统指运行在一个或多个称为工作流机的软件上的用于定义、实现和管理工作流运行的一套软件系统,它和工作流执行者(人、应用)交互,推进工作流实例的执行,并监控工作流的运行状态。在这里需要强调指出的是工作流管理系统不是企业的业务系统。在很大程度上,工作流管理系统为企业的业务系统运行提供一个软件支撑环境,非常类似于在单个计算机上的操作系统。只不过工作流管理系统支撑的范围比较大、环境比较复杂而已,所以也有人称工作流管理系统是业务操作系统(BOS - Business Operating System)。在工作流管理系统的支撑下,通过集成具体的业务应用软件和操作人员的界面操作,才能够良好地完成对企业经营过程运行的支持。所以,工作流管理系统在一个企业或部门的经营过程中的应用过程是一个业务应用软件系统的集成与实施过程。   二、工作流管理系统:   工作流管理系统可以用来定义与执行不同覆盖范围(单个工作者、部门、全企业、企业间)、不同时间跨度(分钟、小时、天、月)的经营过程。这完全取决于实际应用背景的需求。按照经营过程以及组成活动的复杂程度的不同,工作流管理系统可以采取许多种实施方式,在不同的实施方式中,所应用的信息技术、通信技术和支撑系统结构会有很大的差别。工作流管理系统的实际运行环境可以是在一个工作组内部或者在全企业的所有业务部门。   三、业务过程:   业务过程(business process)就是活动的集合,这些活动均关联于特定的托付事项(commitment),为过程的产出增值。相对于“工作流”,业务过程是一个更一般化的统称,而工作流这个词,则已经不能仅从字面含义或原理上去理解,它已经被赋予了更深一层的特定含义——专指基于信息技术规划、运作、管理的业务过程。   四、自动与协调:   “自动”(automate)是工作流的一个特征,但这主要是指它自动进行的特征,而不是说没有人的参与。工作流实际上是一个人-电脑协调的混合过程,在一个实际的工作流中,通常总有些步骤是人完成的。协调是工作流管理的一个目标或者特征,这包括了人与人、人与电脑,电脑(软件)之间等多种层面的含义。   五、监察与控制:   监察(Monitoring)与控制(Contorl)是工作流系统的重要功能与特征。这不仅包括对正在发生的业务过程(工作流),还包括它的定义或改变(比如BPR的过程)。这是工作流系统带给我们的明显好处之一。   六、标准化:   作流的概念被明确提出并得到重视的同时,人们就认识到了“标准化”在其中的重要性,有关工作流的标准开发和推广,基本是与“工作流”的开发和推广同步进行的。在这方面目前的权威性机构,是“工作流管理联盟”(Workflow Management Coalition, WfMC)。它成立于1993年8月,目前已拥有 130 余个成员,成员包括工作流产品的供应者、应用者,有关大学和研究机构和个人,是一个国际性的非赢利组织。在最近的投资成员(Funding members)清单中,可以看到诸如 Baan, HP, IBM, Microsoft, Oracle, Peplesoft, SAP AG, Xerox 等机构。   七、工作流与重规划:   从逻辑上,对工作流的关注和研究可以看作是对业务过程重规划(BPR)的一种深化。BPR的观点,要求我们将眼光投向实际业务进行的过程,但这个过程应当是什么样的,怎样分析、构造?工作流就是一个具体的、操作性的答案,它可以令我们从神秘的、难以预测和控制的“头脑风暴式”的“艺术的”业务过程创造,变成解析的、技术的、可控制和预测的工程化过程,如此,才真正体现出 re-engineering 中 engineering 的意义。   工作流与 BPR 的概念,已经被几乎所有的研究者联系在一起研究和应用。在这个领域有一个非常活跃的组织,即国际工作流与重规划协会( Workflow And Reengineering International Association, WARIA)。   八、工作流与企业工程:   无论从理论、方法上,还是对象、内容上,我们都有理由将“工作流”看作是企业工程的一部分。实际上,已有的关于工作流体系的描述,本身就是一个通用的业务模型框架。仅仅囿于工作流是不够的,必须对整个体系的目标及所有相关要素综合考虑——这正是企业工程。   九、工作流与IT应用体系:   与以往已经被采用的企业 IT 应用体系,例如 MRPII 或 ERP 相比,WFMS是一个相当重要的里程碑。(ERP的概念并不确定,我这里仅指其基本或较早期的含义而言)。从用户的角度,WFMS带来(或将要带来)的变化是极其强烈的,甚至可以形容为一种用户“梦想”的实现。   在一些老的“模块化”的产品中,系统的设计是通常是基于任务分割的,作业项目之间是分裂的。面向对象的技术,并不能直接解决这个的问题,相反,往往使系统变得更加混乱和琐碎。从操作上,典型地,我们必须不断地在层次结构的功能表(比如下拉菜单)或对象之间“进进退退”,或者在“神出鬼没”的对象以及相关菜单中捉迷藏。   工作流管理系统是一个真正的“人-机”系统,用户是系统中的基本角色,是直接的任务分派对象,他或她可以直接看到电脑针对自己列出的“任务清单”,跟踪每一项任务的状态,或继续一项任务,而不必从一个模块退出,进入另一个模块,搜索相应任务的线索。前者是面向功能或对象的,而后者是直接面向用户的。这样,用户的任务分派和任务的完成状态,可以被最大程度地电脑化和受到控制。   现在的典型工作流产品是客户-服务软件。而日益增长的重要途径是通过万维网界面,它可以令客户或远程的职员更好地参与。工作流的定义经常是借助于图形化工具,依照业务过程实例的情况定义相应工作的安排   OA(办公自动化): 引自肖淑男 2001-2-20   通常,OA 就是办公自动化,英文Office Automation的缩写。通过流程或特定环节与日常事务联系在一起,使公文在流转、审批、发布等方面提高效率,实现办公管理规范化和信息规范化,降低企业运行成本的一套系统的统称。   多年来,OA尚无一个确切的定义,人们对OA的看法和理解各有不同。笔者认为:OA本身就不是一个有确定界定的概念,它是一个过程、一种境界。它随技术的发展而发展,随人们办公方式和习惯以及管理思想的变化而变化。在技术发展过程中的每一个阶段,人们给OA赋予了不同的内容和新的想象,技术与管理的进步给OA打下了每一步发展的历史烙印。同时,不同行业、不同层次的人对OA的看法和理解也各有不同。也许正是OA这种变化和发展的特点使之成为30多年来常新不衰的话题。   现在有一种较普遍的偏见:认为OA仅仅是诸如公文流转、收发文管理、档案管理、会议安排、文献检索、电子表格、电子邮件等等这些非结构化数据的处理和交换过程,面向的用户群也只是机关办公室或企业的职能部门、文秘部门。其实,今天看来,OA应有更丰富的内容和层面,更广泛的用户群。以下是笔者对OA在功能上以及所涉及的技术范畴的肤浅理解,愿与同行商榷。   功能方面:广义面言,OA应该是一个企业除了生产控制之外的一切信息处理与管理的集合。它面向不同层次的使用者,便有不同的功能表现:   对于企业高层领导而言,OA是决策支持系统(DSS)。OA运用科学的数学模型,结合企业内部/外部的信息为条件,为企业领导提供决策参考和依据;   对于中层管理者而言:OA是信息管理系统(IMS),OA利用业务各环节提供的基础“数据”,提炼出有用的管理“信息”,把握业务进程,降低经营风险,提高经营效率;   对于普通员工而言:OA是事务/业务处理系统。OA为办公室人员提供良好的办公手段和环境,使之准确、高效,愉快地工作。   技术范畴:OA是计算机技术在办公业务中的合理应用。计算机技术是OA的前提。如果脱离计算机技术面阔谈OA,无异于痴人说梦。没有计算机技术,OA便成无源之水、无本之木。计算机对信息的存储与处理能力极大地改变了人们的办公方式,提高了工作效率。如:要建立决策支持系统,则需要数据仓库 、OLAP等技术;要建立信息管理系统,则要有数据库、程序设计语言等技术;要建立事务/业务处理系统,则离不开数据库、设计良好的人机界面和工作流控制、OLTP等技术。   OA是利用通信技术来实现人与机器、机器与机器及人与人的交流。通信技术是OA的基础。现代办公室不再是孤军奋战,而是一个团队的协同工作,团队中成员之间的协调、合作离不开通信技术;现代办公室也不再是闭门造车,企业需要与外界广泛的信息交流,这更离不开通信技术。没有通信技术的支持,OA便成空中楼阁。   OA是科学的管理思想在先进的技术手段下的物化。科学的管理思想是实现OA的核心。计算机技术和通信技术仅仅是为实现OA打下了基础,提供了可能。要真正实现OA,还需物化人类思维中科学管理的内容。正如仅有优质的画笔、画板、颜料而没有达.芬奇,就不会有蒙娜尼莎的微笑一样。不体现人类管理智慧,就不会有真正的OA,如果有,也只是技术的堆砌和摆设。   由此而知,OA是计算机技术、通信技术与科学的管理思想完美结合的一种境界和理想。我们一直在为实现OA而努力,但我们的成果仅仅是在某些环节、某些方面、部分地实现了OA的功能,与真正的OA尚有差距,差距的根本在于应用系统对管理思想的实现方面。 答案来源于网络
养狐狸的猫 2019-12-02 03:00:25 0 浏览量 回答数 0

问题

盘点年度 Python 类库 Top 10

盘点年度 Python 类库 Top 10 1. HTTPX 如果你是一名经常与 api 交互的 Python 死忠粉,可能会很熟悉 requests 类库。然而,异步范式在高性能现代应用程序中越来越常见&#...
珍宝珠 2020-01-09 13:39:35 77 浏览量 回答数 1

回答

我们先从整体上看一下Kubernetes的一些理念和基本架构,然后从网络、资源管理、存储、服务发现、负载均衡、高可用、rollingupgrade、安全、监控等方面向大家简单介绍Kubernetes的这些主要特性。  当然也会包括一些需要注意的问题。主要目的是帮助大家快速理解Kubernetes的主要功能,今后在研究和使用这个具的时候有所参考和帮助。  1.Kubernetes的一些理念:  用户不需要关心需要多少台机器,只需要关心软件(服务)运行所需的环境。以服务为中心,你需要关心的是api,如何把大服务拆分成小服务,如何使用api去整合它们。  保证系统总是按照用户指定的状态去运行。  不仅仅提给你供容器服务,同样提供一种软件系统升级的方式;在保持HA的前提下去升级系统是很多用户最想要的功能,也是最难实现的。  那些需要担心和不需要担心的事情。  更好的支持微服务理念,划分、细分服务之间的边界,比如lablel、pod等概念的引入。  对于Kubernetes的架构,可以参考官方文档。  大致由一些主要组件构成,包括Master节点上的kube-apiserver、kube-scheduler、kube-controller-manager、控制组件kubectl、状态存储etcd、Slave节点上的kubelet、kube-proxy,以及底层的网络支持(可以用Flannel、OpenVSwitch、Weave等)。  看上去也是微服务的架构设计,不过目前还不能很好支持单个服务的横向伸缩,但这个会在Kubernetes的未来版本中解决。  2.Kubernetes的主要特性  会从网络、服务发现、负载均衡、资源管理、高可用、存储、安全、监控等方面向大家简单介绍Kubernetes的这些主要特性->由于时间有限,只能简单一些了。  另外,对于服务发现、高可用和监控的一些更详细的介绍,感兴趣的朋友可以通过这篇文章了解。  1)网络  Kubernetes的网络方式主要解决以下几个问题:  a.紧耦合的容器之间通信,通过Pod和localhost访问解决。  b.Pod之间通信,建立通信子网,比如隧道、路由,Flannel、OpenvSwitch、Weave。  c.Pod和Service,以及外部系统和Service的通信,引入Service解决。  Kubernetes的网络会给每个Pod分配一个IP地址,不需要在Pod之间建立链接,也基本不需要去处理容器和主机之间的端口映射。  注意:Pod重建后,IP会被重新分配,所以内网通信不要依赖PodIP;通过Service环境变量或者DNS解决。  2)服务发现及负载均衡  kube-proxy和DNS,在v1之前,Service含有字段portalip和publicIPs,分别指定了服务的虚拟ip和服务的出口机ip,publicIPs可任意指定成集群中任意包含kube-proxy的节点,可多个。portalIp通过NAT的方式跳转到container的内网地址。在v1版本中,publicIPS被约定废除,标记为deprecatedPublicIPs,仅用作向后兼容,portalIp也改为ClusterIp,而在serviceport定义列表里,增加了nodePort项,即对应node上映射的服务端口。  DNS服务以addon的方式,需要安装skydns和kube2dns。kube2dns会通过读取KubernetesAPI获取服务的clusterIP和port信息,同时以watch的方式检查service的变动,及时收集变动信息,并将对于的ip信息提交给etcd存档,而skydns通过etcd内的DNS记录信息,开启53端口对外提供服务。大概的DNS的域名记录是servicename.namespace.tenx.domain,“tenx.domain”是提前设置的主域名。  注意:kube-proxy在集群规模较大以后,可能会有访问的性能问题,可以考虑用其他方式替换,比如HAProxy,直接导流到Service的endpints或者Pods上。Kubernetes官方也在修复这个问题。  3)资源管理  有3个层次的资源限制方式,分别在Container、Pod、Namespace层次。Container层次主要利用容器本身的支持,比如Docker对CPU、内存、磁盘、网络等的支持;Pod方面可以限制系统内创建Pod的资源范围,比如最大或者最小的CPU、memory需求;Namespace层次就是对用户级别的资源限额了,包括CPU、内存,还可以限定Pod、rc、service的数量。  资源管理模型-》简单、通用、准确,并可扩展  目前的资源分配计算也相对简单,没有什么资源抢占之类的强大功能,通过每个节点上的资源总量、以及已经使用的各种资源加权和,来计算某个Pod优先非配到哪些节点,还没有加入对节点实际可用资源的评估,需要自己的schedulerplugin来支持。其实kubelet已经可以拿到节点的资源,只要进行收集计算即可,相信Kubernetes的后续版本会有支持。  4)高可用  主要是指Master节点的HA方式官方推荐利用etcd实现master选举,从多个Master中得到一个kube-apiserver保证至少有一个master可用,实现highavailability。对外以loadbalancer的方式提供入口。这种方式可以用作ha,但仍未成熟,据了解,未来会更新升级ha的功能。  一张图帮助大家理解:  也就是在etcd集群背景下,存在多个kube-apiserver,并用pod-master保证仅是主master可用。同时kube-sheduller和kube-controller-manager也存在多个,而且伴随着kube-apiserver同一时间只能有一套运行。  5)rollingupgrade  RC在开始的设计就是让rollingupgrade变的更容易,通过一个一个替换Pod来更新service,实现服务中断时间的最小化。基本思路是创建一个复本为1的新的rc,并逐步减少老的rc的复本、增加新的rc的复本,在老的rc数量为0时将其删除。  通过kubectl提供,可以指定更新的镜像、替换pod的时间间隔,也可以rollback当前正在执行的upgrade操作。  同样,Kuberntes也支持多版本同时部署,并通过lable来进行区分,在service不变的情况下,调整支撑服务的Pod,测试、监控新Pod的工作情况。  6)存储  大家都知道容器本身一般不会对数据进行持久化处理,在Kubernetes中,容器异常退出,kubelet也只是简单的基于原有镜像重启一个新的容器。另外,如果我们在同一个Pod中运行多个容器,经常会需要在这些容器之间进行共享一些数据。Kuberenetes的Volume就是主要来解决上面两个基础问题的。  Docker也有Volume的概念,但是相对简单,而且目前的支持很有限,Kubernetes对Volume则有着清晰定义和广泛的支持。其中最核心的理念:Volume只是一个目录,并可以被在同一个Pod中的所有容器访问。而这个目录会是什么样,后端用什么介质和里面的内容则由使用的特定Volume类型决定。  创建一个带Volume的Pod:  spec.volumes指定这个Pod需要的volume信息spec.containers.volumeMounts指定哪些container需要用到这个VolumeKubernetes对Volume的支持非常广泛,有很多贡献者为其添加不同的存储支持,也反映出Kubernetes社区的活跃程度。  emptyDir随Pod删除,适用于临时存储、灾难恢复、共享运行时数据,支持RAM-backedfilesystemhostPath类似于Docker的本地Volume用于访问一些本地资源(比如本地Docker)。  gcePersistentDiskGCEdisk-只有在GoogleCloudEngine平台上可用。  awsElasticBlockStore类似于GCEdisk节点必须是AWSEC2的实例nfs-支持网络文件系统。  rbd-RadosBlockDevice-Ceph  secret用来通过KubernetesAPI向Pod传递敏感信息,使用tmpfs(aRAM-backedfilesystem)  persistentVolumeClaim-从抽象的PV中申请资源,而无需关心存储的提供方  glusterfs  iscsi  gitRepo  根据自己的需求选择合适的存储类型,反正支持的够多,总用一款适合的:)  7)安全  一些主要原则:  基础设施模块应该通过APIserver交换数据、修改系统状态,而且只有APIserver可以访问后端存储(etcd)。  把用户分为不同的角色:Developers/ProjectAdmins/Administrators。  允许Developers定义secrets对象,并在pod启动时关联到相关容器。  以secret为例,如果kubelet要去pull私有镜像,那么Kubernetes支持以下方式:  通过dockerlogin生成.dockercfg文件,进行全局授权。  通过在每个namespace上创建用户的secret对象,在创建Pod时指定imagePullSecrets属性(也可以统一设置在serviceAcouunt上),进行授权。  认证(Authentication)  APIserver支持证书、token、和基本信息三种认证方式。  授权(Authorization)  通过apiserver的安全端口,authorization会应用到所有http的请求上  AlwaysDeny、AlwaysAllow、ABAC三种模式,其他需求可以自己实现Authorizer接口。  8)监控  比较老的版本Kubernetes需要外接cadvisor主要功能是将node主机的containermetrics抓取出来。在较新的版本里,cadvior功能被集成到了kubelet组件中,kubelet在与docker交互的同时,对外提供监控服务。  Kubernetes集群范围内的监控主要由kubelet、heapster和storagebackend(如influxdb)构建。Heapster可以在集群范围获取metrics和事件数据。它可以以pod的方式运行在k8s平台里,也可以单独运行以standalone的方式。  注意:heapster目前未到1.0版本,对于小规模的集群监控比较方便。但对于较大规模的集群,heapster目前的cache方式会吃掉大量内存。因为要定时获取整个集群的容器信息,信息在内存的临时存储成为问题,再加上heaspter要支持api获取临时metrics,如果将heapster以pod方式运行,很容易出现OOM。所以目前建议关掉cache并以standalone的方式独立出k8s平台。 答案来源网络,供您参考
问问小秘 2019-12-02 02:13:31 0 浏览量 回答数 0

回答

我们先从整体上看一下Kubernetes的一些理念和基本架构,然后从网络、资源管理、存储、服务发现、负载均衡、高可用、rollingupgrade、安全、监控等方面向大家简单介绍Kubernetes的这些主要特性。  当然也会包括一些需要注意的问题。主要目的是帮助大家快速理解Kubernetes的主要功能,今后在研究和使用这个具的时候有所参考和帮助。  1.Kubernetes的一些理念:  用户不需要关心需要多少台机器,只需要关心软件(服务)运行所需的环境。以服务为中心,你需要关心的是api,如何把大服务拆分成小服务,如何使用api去整合它们。  保证系统总是按照用户指定的状态去运行。  不仅仅提给你供容器服务,同样提供一种软件系统升级的方式;在保持HA的前提下去升级系统是很多用户最想要的功能,也是最难实现的。  那些需要担心和不需要担心的事情。  更好的支持微服务理念,划分、细分服务之间的边界,比如lablel、pod等概念的引入。  对于Kubernetes的架构,可以参考官方文档。  大致由一些主要组件构成,包括Master节点上的kube-apiserver、kube-scheduler、kube-controller-manager、控制组件kubectl、状态存储etcd、Slave节点上的kubelet、kube-proxy,以及底层的网络支持(可以用Flannel、OpenVSwitch、Weave等)。  看上去也是微服务的架构设计,不过目前还不能很好支持单个服务的横向伸缩,但这个会在Kubernetes的未来版本中解决。  2.Kubernetes的主要特性  会从网络、服务发现、负载均衡、资源管理、高可用、存储、安全、监控等方面向大家简单介绍Kubernetes的这些主要特性->由于时间有限,只能简单一些了。  另外,对于服务发现、高可用和监控的一些更详细的介绍,感兴趣的朋友可以通过这篇文章了解。  1)网络  Kubernetes的网络方式主要解决以下几个问题:  a.紧耦合的容器之间通信,通过Pod和localhost访问解决。  b.Pod之间通信,建立通信子网,比如隧道、路由,Flannel、OpenvSwitch、Weave。  c.Pod和Service,以及外部系统和Service的通信,引入Service解决。  Kubernetes的网络会给每个Pod分配一个IP地址,不需要在Pod之间建立链接,也基本不需要去处理容器和主机之间的端口映射。  注意:Pod重建后,IP会被重新分配,所以内网通信不要依赖PodIP;通过Service环境变量或者DNS解决。  2)服务发现及负载均衡  kube-proxy和DNS,在v1之前,Service含有字段portalip和publicIPs,分别指定了服务的虚拟ip和服务的出口机ip,publicIPs可任意指定成集群中任意包含kube-proxy的节点,可多个。portalIp通过NAT的方式跳转到container的内网地址。在v1版本中,publicIPS被约定废除,标记为deprecatedPublicIPs,仅用作向后兼容,portalIp也改为ClusterIp,而在serviceport定义列表里,增加了nodePort项,即对应node上映射的服务端口。  DNS服务以addon的方式,需要安装skydns和kube2dns。kube2dns会通过读取KubernetesAPI获取服务的clusterIP和port信息,同时以watch的方式检查service的变动,及时收集变动信息,并将对于的ip信息提交给etcd存档,而skydns通过etcd内的DNS记录信息,开启53端口对外提供服务。大概的DNS的域名记录是servicename.namespace.tenx.domain,“tenx.domain”是提前设置的主域名。  注意:kube-proxy在集群规模较大以后,可能会有访问的性能问题,可以考虑用其他方式替换,比如HAProxy,直接导流到Service的endpints或者Pods上。Kubernetes官方也在修复这个问题。  3)资源管理  有3个层次的资源限制方式,分别在Container、Pod、Namespace层次。Container层次主要利用容器本身的支持,比如Docker对CPU、内存、磁盘、网络等的支持;Pod方面可以限制系统内创建Pod的资源范围,比如最大或者最小的CPU、memory需求;Namespace层次就是对用户级别的资源限额了,包括CPU、内存,还可以限定Pod、rc、service的数量。  资源管理模型-》简单、通用、准确,并可扩展  目前的资源分配计算也相对简单,没有什么资源抢占之类的强大功能,通过每个节点上的资源总量、以及已经使用的各种资源加权和,来计算某个Pod优先非配到哪些节点,还没有加入对节点实际可用资源的评估,需要自己的schedulerplugin来支持。其实kubelet已经可以拿到节点的资源,只要进行收集计算即可,相信Kubernetes的后续版本会有支持。  4)高可用  主要是指Master节点的HA方式官方推荐利用etcd实现master选举,从多个Master中得到一个kube-apiserver保证至少有一个master可用,实现highavailability。对外以loadbalancer的方式提供入口。这种方式可以用作ha,但仍未成熟,据了解,未来会更新升级ha的功能。  一张图帮助大家理解:  也就是在etcd集群背景下,存在多个kube-apiserver,并用pod-master保证仅是主master可用。同时kube-sheduller和kube-controller-manager也存在多个,而且伴随着kube-apiserver同一时间只能有一套运行。  5)rollingupgrade  RC在开始的设计就是让rollingupgrade变的更容易,通过一个一个替换Pod来更新service,实现服务中断时间的最小化。基本思路是创建一个复本为1的新的rc,并逐步减少老的rc的复本、增加新的rc的复本,在老的rc数量为0时将其删除。  通过kubectl提供,可以指定更新的镜像、替换pod的时间间隔,也可以rollback当前正在执行的upgrade操作。  同样,Kuberntes也支持多版本同时部署,并通过lable来进行区分,在service不变的情况下,调整支撑服务的Pod,测试、监控新Pod的工作情况。  6)存储  大家都知道容器本身一般不会对数据进行持久化处理,在Kubernetes中,容器异常退出,kubelet也只是简单的基于原有镜像重启一个新的容器。另外,如果我们在同一个Pod中运行多个容器,经常会需要在这些容器之间进行共享一些数据。Kuberenetes的Volume就是主要来解决上面两个基础问题的。  Docker也有Volume的概念,但是相对简单,而且目前的支持很有限,Kubernetes对Volume则有着清晰定义和广泛的支持。其中最核心的理念:Volume只是一个目录,并可以被在同一个Pod中的所有容器访问。而这个目录会是什么样,后端用什么介质和里面的内容则由使用的特定Volume类型决定。  创建一个带Volume的Pod:  spec.volumes指定这个Pod需要的volume信息spec.containers.volumeMounts指定哪些container需要用到这个VolumeKubernetes对Volume的支持非常广泛,有很多贡献者为其添加不同的存储支持,也反映出Kubernetes社区的活跃程度。  emptyDir随Pod删除,适用于临时存储、灾难恢复、共享运行时数据,支持RAM-backedfilesystemhostPath类似于Docker的本地Volume用于访问一些本地资源(比如本地Docker)。  gcePersistentDiskGCEdisk-只有在GoogleCloudEngine平台上可用。  awsElasticBlockStore类似于GCEdisk节点必须是AWSEC2的实例nfs-支持网络文件系统。  rbd-RadosBlockDevice-Ceph  secret用来通过KubernetesAPI向Pod传递敏感信息,使用tmpfs(aRAM-backedfilesystem)  persistentVolumeClaim-从抽象的PV中申请资源,而无需关心存储的提供方  glusterfs  iscsi  gitRepo  根据自己的需求选择合适的存储类型,反正支持的够多,总用一款适合的:)  7)安全  一些主要原则:  基础设施模块应该通过APIserver交换数据、修改系统状态,而且只有APIserver可以访问后端存储(etcd)。  把用户分为不同的角色:Developers/ProjectAdmins/Administrators。  允许Developers定义secrets对象,并在pod启动时关联到相关容器。  以secret为例,如果kubelet要去pull私有镜像,那么Kubernetes支持以下方式:  通过dockerlogin生成.dockercfg文件,进行全局授权。  通过在每个namespace上创建用户的secret对象,在创建Pod时指定imagePullSecrets属性(也可以统一设置在serviceAcouunt上),进行授权。  认证(Authentication)  APIserver支持证书、token、和基本信息三种认证方式。  授权(Authorization)  通过apiserver的安全端口,authorization会应用到所有http的请求上  AlwaysDeny、AlwaysAllow、ABAC三种模式,其他需求可以自己实现Authorizer接口。  8)监控  比较老的版本Kubernetes需要外接cadvisor主要功能是将node主机的containermetrics抓取出来。在较新的版本里,cadvior功能被集成到了kubelet组件中,kubelet在与docker交互的同时,对外提供监控服务。  Kubernetes集群范围内的监控主要由kubelet、heapster和storagebackend(如influxdb)构建。Heapster可以在集群范围获取metrics和事件数据。它可以以pod的方式运行在k8s平台里,也可以单独运行以standalone的方式。  注意:heapster目前未到1.0版本,对于小规模的集群监控比较方便。但对于较大规模的集群,heapster目前的cache方式会吃掉大量内存。因为要定时获取整个集群的容器信息,信息在内存的临时存储成为问题,再加上heaspter要支持api获取临时metrics,如果将heapster以pod方式运行,很容易出现OOM。所以目前建议关掉cache并以standalone的方式独立出k8s平台。 “答案来源于网络,供您参考” 希望以上信息可以帮到您!
牧明 2019-12-02 02:16:53 0 浏览量 回答数 0

回答

我们先从整体上看一下Kubernetes的一些理念和基本架构, 然后从网络、 资源管理、存储、服务发现、负载均衡、高可用、rolling upgrade、安全、监控等方面向大家简单介绍Kubernetes的这些主要特性。 当然也会包括一些需要注意的问题。主要目的是帮助大家快速理解 Kubernetes的主要功能,今后在研究和使用这个具的时候有所参考和帮助。 1.Kubernetes的一些理念: 用户不需要关心需要多少台机器,只需要关心软件(服务)运行所需的环境。以服务为中心,你需要关心的是api,如何把大服务拆分成小服务,如何使用api去整合它们。 保证系统总是按照用户指定的状态去运行。 不仅仅提给你供容器服务,同样提供一种软件系统升级的方式;在保持HA的前提下去升级系统是很多用户最想要的功能,也是最难实现的。 那些需要担心和不需要担心的事情。 更好的支持微服务理念,划分、细分服务之间的边界,比如lablel、pod等概念的引入。 对于Kubernetes的架构,可以参考官方文档。 大致由一些主要组件构成,包括Master节点上的kube-apiserver、kube-scheduler、kube-controller-manager、控制组件kubectl、状态存储etcd、Slave节点上的kubelet、kube-proxy,以及底层的网络支持(可以用Flannel、OpenVSwitch、Weave等)。 看上去也是微服务的架构设计,不过目前还不能很好支持单个服务的横向伸缩,但这个会在 Kubernetes 的未来版本中解决。 2.Kubernetes的主要特性 会从网络、服务发现、负载均衡、资源管理、高可用、存储、安全、监控等方面向大家简单介绍Kubernetes的这些主要特性 -> 由于时间有限,只能简单一些了。 另外,对于服务发现、高可用和监控的一些更详细的介绍,感兴趣的朋友可以通过这篇文章了解。 1)网络 Kubernetes的网络方式主要解决以下几个问题: a. 紧耦合的容器之间通信,通过 Pod 和 localhost 访问解决。 b. Pod之间通信,建立通信子网,比如隧道、路由,Flannel、Open vSwitch、Weave。 c. Pod和Service,以及外部系统和Service的通信,引入Service解决。 Kubernetes的网络会给每个Pod分配一个IP地址,不需要在Pod之间建立链接,也基本不需要去处理容器和主机之间的端口映射。 注意:Pod重建后,IP会被重新分配,所以内网通信不要依赖Pod IP;通过Service环境变量或者DNS解决。 2) 服务发现及负载均衡 kube-proxy和DNS, 在v1之前,Service含有字段portalip 和publicIPs, 分别指定了服务的虚拟ip和服务的出口机ip,publicIPs可任意指定成集群中任意包含kube-proxy的节点,可多个。portalIp 通过NAT的方式跳转到container的内网地址。在v1版本中,publicIPS被约定废除,标记为deprecatedPublicIPs,仅用作向后兼容,portalIp也改为ClusterIp, 而在service port 定义列表里,增加了nodePort项,即对应node上映射的服务端口。 DNS服务以addon的方式,需要安装skydns和kube2dns。kube2dns会通过读取Kubernetes API获取服务的clusterIP和port信息,同时以watch的方式检查service的变动,及时收集变动信息,并将对于的ip信息提交给etcd存档,而skydns通过etcd内的DNS记录信息,开启53端口对外提供服务。大概的DNS的域名记录是servicename.namespace.tenx.domain, "tenx.domain"是提前设置的主域名。 注意:kube-proxy 在集群规模较大以后,可能会有访问的性能问题,可以考虑用其他方式替换,比如HAProxy,直接导流到Service 的endpints 或者 Pods上。Kubernetes官方也在修复这个问题。 3)资源管理 有3 个层次的资源限制方式,分别在Container、Pod、Namespace 层次。Container层次主要利用容器本身的支持,比如Docker 对CPU、内存、磁盘、网络等的支持;Pod方面可以限制系统内创建Pod的资源范围,比如最大或者最小的CPU、memory需求;Namespace层次就是对用户级别的资源限额了,包括CPU、内存,还可以限定Pod、rc、service的数量。 资源管理模型 -》 简单、通用、准确,并可扩展 目前的资源分配计算也相对简单,没有什么资源抢占之类的强大功能,通过每个节点上的资源总量、以及已经使用的各种资源加权和,来计算某个Pod优先非配到哪些节点,还没有加入对节点实际可用资源的评估,需要自己的scheduler plugin来支持。其实kubelet已经可以拿到节点的资源,只要进行收集计算即可,相信Kubernetes的后续版本会有支持。 4)高可用 主要是指Master节点的 HA方式 官方推荐 利用etcd实现master 选举,从多个Master中得到一个kube-apiserver 保证至少有一个master可用,实现high availability。对外以loadbalancer的方式提供入口。这种方式可以用作ha,但仍未成熟,据了解,未来会更新升级ha的功能。 一张图帮助大家理解: 也就是在etcd集群背景下,存在多个kube-apiserver,并用pod-master保证仅是主master可用。同时kube-sheduller和kube-controller-manager也存在多个,而且伴随着kube-apiserver 同一时间只能有一套运行。 5) rolling upgrade RC 在开始的设计就是让rolling upgrade变的更容易,通过一个一个替换Pod来更新service,实现服务中断时间的最小化。基本思路是创建一个复本为1的新的rc,并逐步减少老的rc的复本、增加新的rc的复本,在老的rc数量为0时将其删除。 通过kubectl提供,可以指定更新的镜像、替换pod的时间间隔,也可以rollback 当前正在执行的upgrade操作。 同样, Kuberntes也支持多版本同时部署,并通过lable来进行区分,在service不变的情况下,调整支撑服务的Pod,测试、监控新Pod的工作情况。 6)存储 大家都知道容器本身一般不会对数据进行持久化处理,在Kubernetes中,容器异常退出,kubelet也只是简单的基于原有镜像重启一个新的容器。另外,如果我们在同一个Pod中运行多个容器,经常会需要在这些容器之间进行共享一些数据。Kuberenetes 的 Volume就是主要来解决上面两个基础问题的。 Docker 也有Volume的概念,但是相对简单,而且目前的支持很有限,Kubernetes对Volume则有着清晰定义和广泛的支持。其中最核心的理念:Volume只是一个目录,并可以被在同一个Pod中的所有容器访问。而这个目录会是什么样,后端用什么介质和里面的内容则由使用的特定Volume类型决定。 创建一个带Volume的Pod: spec.volumes 指定这个Pod需要的volume信息 spec.containers.volumeMounts 指定哪些container需要用到这个Volume Kubernetes对Volume的支持非常广泛,有很多贡献者为其添加不同的存储支持,也反映出Kubernetes社区的活跃程度。 emptyDir 随Pod删除,适用于临时存储、灾难恢复、共享运行时数据,支持 RAM-backed filesystemhostPath 类似于Docker的本地Volume 用于访问一些本地资源(比如本地Docker)。 gcePersistentDisk GCE disk - 只有在 Google Cloud Engine 平台上可用。 awsElasticBlockStore 类似于GCE disk 节点必须是 AWS EC2的实例 nfs - 支持网络文件系统。 rbd - Rados Block Device - Ceph secret 用来通过Kubernetes API 向Pod 传递敏感信息,使用 tmpfs (a RAM-backed filesystem) persistentVolumeClaim - 从抽象的PV中申请资源,而无需关心存储的提供方 glusterfs iscsi gitRepo 根据自己的需求选择合适的存储类型,反正支持的够多,总用一款适合的 :) 7)安全 一些主要原则: 基础设施模块应该通过API server交换数据、修改系统状态,而且只有API server可以访问后端存储(etcd)。 把用户分为不同的角色:Developers/Project Admins/Administrators。 允许Developers定义secrets 对象,并在pod启动时关联到相关容器。 以secret 为例,如果kubelet要去pull 私有镜像,那么Kubernetes支持以下方式: 通过docker login 生成 .dockercfg 文件,进行全局授权。 通过在每个namespace上创建用户的secret对象,在创建Pod时指定 imagePullSecrets 属性(也可以统一设置在serviceAcouunt 上),进行授权。 认证 (Authentication) API server 支持证书、token、和基本信息三种认证方式。 授权 (Authorization) 通过apiserver的安全端口,authorization会应用到所有http的请求上 AlwaysDeny、AlwaysAllow、ABAC三种模式,其他需求可以自己实现Authorizer接口。 8)监控 比较老的版本Kubernetes需要外接cadvisor主要功能是将node主机的container metrics抓取出来。在较新的版本里,cadvior功能被集成到了kubelet组件中,kubelet在与docker交互的同时,对外提供监控服务。 Kubernetes集群范围内的监控主要由kubelet、heapster和storage backend(如influxdb)构建。Heapster可以在集群范围获取metrics和事件数据。它可以以pod的方式运行在k8s平台里,也可以单独运行以standalone的方式。 注意: heapster目前未到1.0版本,对于小规模的集群监控比较方便。但对于较大规模的集群,heapster目前的cache方式会吃掉大量内存。因为要定时获取整个集群的容器信息,信息在内存的临时存储成为问题,再加上heaspter要支持api获取临时metrics,如果将heapster以pod方式运行,很容易出现OOM。所以目前建议关掉cache并以standalone的方式独立出k8s平台。 此答案来源于网络,希望对你有所帮助。
养狐狸的猫 2019-12-02 02:13:33 0 浏览量 回答数 0

回答

2014年12月第2周 1)SLB植入cookie和SLB重写cookie有什么区别? cookie植入,表示直接由SLB系统来分配和管理对客户端进行的cookie植入操作,用户在进行配置时 需要指定会话保持的超时时间; cookie重写,表示SLB系统会根据用户自定义cookie名称来分配和管理对客户端进行的cookie植入操 作,便于用户识别和区分自定义的cookie名称 http://help.aliyun.com/doc/view/13510025.html?spm=0.0.0.0.vwbsGF 2)SLB有没有对外提供API接口,因为我想做到用程序自动去控制SLB的操作? SLB api您可以参考http://help.aliyun.com/view/13621674.html? spm=5176.7114037.1996646101.1.9RoTFM&pos=1 3)使用slb怎么实现数据的单向同步和双向同步? 单向同步可以使用rsync,双向同步的话rsync需要借用别的服务来实现,如unison+inotify。 4)slb的vip是否可以实现远程登录? slb 的vip无法实现远程登录。 5)slb的带宽是所有后端ECS服务器的带宽总和吗? 不是,使您购买的slb实例带宽。 6)slb健康检查机制是什么? 用户开启健康检查功能后,当后端某个ECS健康检查出现问题时会将请求转发到其他健康检查正常的 ECS上,而当该ECS恢复正常运行时,SLB会将其自动恢复到对外或对内的服务中。 针对7层(HTTP协议)服务,SLB系统的健康检查机制为:默认通过SLB的后端系统来向该ECS应用服务 器配置的缺省首页发起http head请求(缺省通过在服务监听配置中指定的后端ECS端口进行访问), 返回200 OK后将视为后端ECS运行正常,否则视为后端ECS运行异常。如果用户用来进行健康检查的页 面并不是应用服务器的缺省首页,那么需要用户指定相应的URI。如果用户对http head请求限定了 host字段的参数,那么需要用户指定相应的URL。用户也可以通过设定健康检查的频率、健康阈值和 不健康阈值来更好的控制健康检查功能。 针对4层(TCP协议)服务,SLB系统的健康检查机制为:默认通过在服务监听配置中指定的后端ECS端 口发起访问请求,如果端口访问正常则视为后端ECS运行正常,否则视为后端ECS运行异常。 当用户后端ECS健康检查异常后,SLB系统会将该ECS的转发权重设置为0,从而确保新的连接不会再被 转发到该ECS上,而已经建立的连接的请求却不会被直接断掉。 针对可能引起健康检查异常的排查思路点击这里查看。 关于健康检查的参数配置,提供如下参考建议: 响应超时时间:5秒 健康检查间隔:2秒 不健康阈值:3 健康阈值:3 7)权重设置为0怎么办? 权重为0的服务器将无法提供服务。 8)健康检查异常的排查思路? 参考http://help.aliyun.com/doc/view/13510029.html?spm=0.0.0.0.Oa9Ezv ------------------------- 12月份第3周1)轮询与最小连接数方式的区别是什么?当前SLB支持轮询和最小连接数2种模式的转发规则。“轮询模式”会将外部和内部的访问请求依序分发给后端ECS进行处理,而“最小连接数模式”会将外部和内部的访问请求分发给当前连接数最小的一台后端ECS进行处理。2)SLB支持redis的主备?目前我们的SLB不支持主备模式(冷备),只支持"轮询"和"最小连接数"两种负载模式。关于SLB的原理您可以参阅如下博文:http://blog.aliyun.com/149 基于ECS的redis搭建,您可以参阅论坛中其它用户的分享案例:http://bbs.aliyun.com/read/161389.html3)负载均衡的多台服务器之间文件会不会自动同步?slb是不会自动同步的,需要您自行配置。4)四层和七层检查的区别是什么?如果是4层(TCP)配置,健康检查只是简单的TCP握手,不会真正去访问您的业务。但对于7层(HTTP)配置,会发HTTP请求(类似于正常访问),并根据返回状态码判断服务状态(2XX表示服务正常)。5)我有多个slb,之前一个slb由于被攻击被黑洞给屏蔽了外部请求,是否可以在slb 并屏蔽后 能够自动将请求分发到另外的slb?由于攻击导致屏蔽外部请求的话,slb没有自动切换的方法的。6)目前slb是否可以设置黑名单?暂不支持。7)我的slb实例控制台显示是停止,为什么?需要给监听的端口设置带宽才能正常。  8)我使用了 SLB那么ESC 需要购买带宽吗?不需要的。但如需要管理ECS,则可购买少些的带宽如1M来管理。9)slb变更计费方式需要多久才能生效?变更和计费将在第二日零点后生效。10)私网SLB的使用,是如何收费的呢?私网slb是不收取费用的。 ------------------------- 12月第4周1)最近用slb后打开网页老出现503 和504错误?一般都是从ECS获取站点信息等异常导致的。您首先先确保源站都可以正常的访问。2)slb检查时突然发现SLB监听错误,怎么回事?配置的健康检查的域名为空,检查的路径是/index.html,目前查看服务器中只有站点c绑定了空主机头,且站点目录下有index.html,而此站点是停止状态,现已帮您启用,查看服务器的健康检查状态已经正常。3)我想使用slb搭建一个负载均衡,后端使用windows服务器,想咨询一下后端服务器是否需要进行什么特别配置呢?另外使用了slb后,后端还能否得到用户的真实IP地址呢,要不要进行什么特殊配置才可以得到后端用户的真实IP。后端服务器的操作系统和web环境最好保持一致,硬件配置上没有什么特别的,4层tcp是可以直接获得前端用户访问的真实地址的,7层http需要在后端web服务端设置一下,参考http://help.aliyun.com/view/13502961.html?spm=5176.7114037.1996646101.1.oRpnOM&pos=14)slb支持https吗?slb您可以通过TCP协议配置443端口的方式来实现,但是安全证书需要保存在您的后端ECS上。5)健康检查后续是否提供多个域名?健康检查只支持一个域名。6)我想关闭负载均衡的健康检查,请问如何配置?4层tcp是无法关闭健康检查的,7层http可以在控制台关闭。健康检查是不会消耗您服务器的资源的,因为slb都是通过内网ip来进行健康检查。7)如何在BLS上 限制单个IP 禁止访问 我的网站呢?SLB暂时不支持设置屏蔽用户端IP。 ------------------------- Re:Re负载均衡SLB常见咨询问题(持续连载) 引用第2楼517449116于2014-12-17 15:54发表的 Re负载均衡SLB常见咨询问题(持续连载) : 如果开启健康检查,健康检查异常的话,是不是就不会给这个异常的ECS分发? [url=http://bbs.aliyun.com/job.php?action=topost&tid=188736&pid=596806][/url] 异常的话不会在分发。 ------------------------- 2015年1月第1周1)有2台ECS起名叫A和B做SLB,A权重设的100 B权重设的0.请问.当A死机时,SLB是否会转到权重是0的B上?如果有一台设置为0,永远都不会有请求转发到此服务器上,即使权重100的宕机也不会转发到0权重的。2)会话保持的选择?开启会话保持功能后,SLB会把来自同一客户端的访问请求分发到同一台后端ECS上进行处理。针对7层(HTTP协议)服务,SLB系统是基于cookie的会话保持。针对4层(TCP协议)服务,SLB系统是基于IP地址的会话保持。3)用nagios或zabbix监控网络带宽,是否可以监控 slb的流量?nagios或zabbix,cacti是要要被监控端安装snmp或者相关agent ,slb不支持安装这些,所以无法通过这条监控软件进行监控。您可以在slb的控制台里面进行查看流量等相关信息。4)用了负载均衡后升级带宽,是不是只用在负载上面升级就可以了,ECS是不是不用在升级了?SLB与后端服务器是经过内网通信,所以如果业务量增加,您对SLB的带宽调整就行,不需要对服务器ECS进行带宽的升级。 ------------------------- 2015年1月第2周 1)SLB到期之后,会对SLB有关联的云主机怎么处理?云主机还没到期的前提下  我想把网站域名解析到SLB上 如果SLB到期了 会影响到我的网站服务么? 云服务器是不会有什么影响的,会自动又变成单独的云服务器可以供您使用的。但是如果您的域名是解析到SLB上,那么会影响到您的站点访问的。服务器上不会有其他的问题感谢您的支持。 2)当SLB 状态为停止的时候 还计算费用吗?停止后公网slb会收取实例费用。SLB价格总览参考:http://help.aliyun.com/view/11108234_13502923.html?spm=0.0.0.0.kBLsVA 3)做了SLB负载均衡,四层和7层负载均衡是否都走slb带宽? 都走slb带宽。 4)我想 移除 slb下的ecs(用作其他用途),请问在移除的时候是否会影响被负载到这台 ecs上的服务的使用 ,也是说slb这是是怎么处理的? 您可以将要移除的主机的权重更改为0 ,这样默认就不会在分发到权重为0的主机上,这个时候您可以移除该主机。但要确保您的另外一台服务器可以承受所有的访问。 5)SLB实例如何释放? 您需要登录管理控制台点击负载均衡。查询您之前创建的实例在哪个节点下,然后释放您的实例。 6)SLB按照小时的带宽计费, 是否需要每小时调整?比如我可否按照一个比较高的上限, 比如3G,然后每个小时按照该小时的峰值进行独立计费呢?   在一个自然日内,限制用户变更计费方式的次数为1次,变更计费方式将在第二日零点后生效;比如用户在今天5月5日的10:00提交了变更计费方式,那么该变配申请将在明天5月6日00:00后生效。http://help.aliyun.com/view/13502923.html?spm=5176.7114037.1996646101.3.67L5dm&pos=2;SLB目前最大带宽是1000Mbps 7)SLB可以限制每个ip的访问频率吗?(工单1F684MN)slb不支持这样配置的。 8)为什么我设置SLB健康检查间隔为5S,但却每秒都有很多请求?因为用于健康检查的服务ip不止一个,每秒中都会有不同的内网ip进行健康检查,健康检查是通过内网方式,不会消耗您后端服务器的资源,您可以将健康检查间隔阈值跳大些,这样监测频率会降低很多。 ------------------------- Re:负载均衡SLB常见咨询问题(持续连载至2015年1月第3周) 2015年1月第3周 1.发现很多100.97.0.0/16 的ip段扫描,给我服务器带来很大压力,怎么办? 100.97.0.0/16 是我们slb的健康检查服务ip段,如果给服务器带来较大压力,请调整健康检查的设置;健康检查的话 1)调低检查频率 2)设置检查静态文件,而不是默认首页或者动态文件 3)设置一个不记录日志的virtualhost,专门用于健康检查。 2)SLB里的带宽 和后面对应服务器的带宽有什么关联关系?比如SLB我设置了带宽为10M, 但是我后 面2台服务器购买的带宽都只有2M, 这种情况带宽以哪个为准? 如果您设置的是常规7层slb负载均衡,那么网站访问所使用的带宽,都将通过slb而不需要消耗云服 务器的带宽,但是云服务器本身的系统更新,以及您更新网站等等也是需要带宽的,因此您保留2M 即可。 3)采用流量计费方式的话带宽是否没有限制? SLB按流量计费最大的带宽是1G。 4)请问我如何获得一个外网SLB期所对应的内网IP呢?比如现在我有一个外网SLB下挂了一个ECS, 而ECS的iptables里我想做一些配置,针对来自于这个SLB的请求做一个判断,我需要知道这个外网 SLB的内网IP。 目前SLB与后端通过如下地址段进行交互: 10.158.0.0/16 10.159.0.0/16 100.97.0.0/16 您可以针对上述地址段做相关配置。 5)如何确保SLB后端的多台ECS之间的数据同步呢? 目前,有很多类似的工具可以实现服务器之间的数据同步,比如:rsync。具体使用及选择,还请通 过其他途径获得更多的介绍资料及指导信息。您也可以将您的ECS配置成无状态的应用服务器,而数 据和文件统一存放在RDS和OSS服务上。 ------------------------- 2015年1月第4周1.为什么我的SLB实例突然消失了?请检查您的SLB服务是否设置了自动释放时间导致。2.我想关掉负载均衡,怎么操作?您直接登录到阿里云管理控制台——slb负载均衡——实例中查询创建的slb服务,后方有“释放”的按钮,您直接释放即可。3. 我现在有两个阿里账号里面都有ECS,我能不能在一个slb里面配置不同阿里云账户下的ECS?目前只能将同一账户下的服务器添加到SLB中,无法跨账户添加。4.ECS做负载均衡需要用户做额外的配置吗?可以参考http://help.aliyun.com/knowledge_detail.htm?knowledgeId=5973987。5. 云服务器上做数据库负载均衡如何实现,需要购买什么产品 ?文件服务器能否做负载均衡,比如10台文件服务器,包括读写这种的  ?1)数据库集群,用slb理论上是可以做的,但是如果您需要集群级别的数据库,建议使用我们的RDS。2)文件服务器也可以负载均衡,使用slb在均衡,保持会话,但是有一个问题是后端文件同步的,需要您自行同步,如 rsync。6.看SLB的说明是支持ddos的防护的,请问下,SLB的防护的峰值是多少,超过峰值黑洞时间是多少?这个与slb所在地区有关,和ecs的防御阀值是一样的,黑洞时间也是2.5小时。7. slb第七层是基于haproxy还是nginx还是tengine实现的?使用tengine实现的。8.7层和4层 SLB的超时时间是多少?7层超时时间是60s,4层超时时间是900s。9.负载均衡健康检查请求数量太多,怎么回事?因为slb前端机器是一组机器,所以健康检查请求较多,请您不要担心,集群内的每台服务都会对您的健康按照您设定的频率去做健康检查:您可以按照上述方法去优化您的健康检查项,看似请求量很大,但是对您资源消耗很少的,有2个建议给您:1)扩大健康检查的频率2)将检查页面配置为静态页面。这样请求消耗的资源会节省。10. SLB配置中的最小连接数是基于什么样判断?SLB会自动判断 当前ECS 的established 来判断是否转发。 ------------------------- 2015年2月第1周1)我想了解下SLB按流量计费是不是每小时需要扣0.02元?按量付费,国内节点配置费用是按照0.02/小时。流量单独计费。按带宽计费:采取按小时计费,以日结算(运行未满一日,按照当日实际使用小时数*当日开通的最高带宽的天价格/24)。如果您使用SLB实例的时间不足一小时,按一小时收费。2)请问健康检查发的什么请求? head 还是 get?head请求。3)SLB最大连接数如何来设置?目前暂不支持设置最大连接数限制。4)SLB 后端有两个服务器HA1和HA2,为什么我将HA1的权重设置成0,SLB的健康检查就有告警呢?slb四层的话,只要权重设置为0,那么健康检查就是显示异常。 ------------------------- 2015年2月第3周1)负载均衡SLB的实例防攻击防御是多少?我们有云盾的防御黑洞策略,比如以杭州节点的slb,其最高防御的流量阈值为5G,当最大流量超过5G,您的slb vip则会被加入到黑洞中,触发黑洞会使ecs或者slb正常使用中断2.5小时,这个您可以通过云盾管理控制台查看到这个说明。2) 我其他机房的服务器能添加到你们的负载均衡SLB中吗?不可以的,slb使用的是内网和后端的ECS互联,无法直接添加非阿里云主机的服务器,且slb后端的ecs需要使用同一节点的主机。3)负载均衡服务支持的最大负载均衡实例数目多少?总体峰值可支持每秒新建链接数大约多少?SLB对于后端服务器的数目是没有限制的。对于总体峰值每秒新建连接数是没有限制的。但是因为SLB前端是云盾服务,所以最大值取决于云盾中您配置的请求数。您可以查看云盾看到具体的值。4)SLB按量计费为什么需要设置带宽峰值?如果不设置带宽峰值,遇到攻击等情况,可能流量打的非常高的,带宽流量峰值您可以在slb控制台设置。5)在SLB控制面板看到的流入流量,要比后端服务器的eth0的income流量小很多, 请问slb的流入流量是否应该等于后端服务器的内网网卡入流量吗?不等于的,后端的eth0包括了slb的流量,还有其他的流量,包括ecs直接的内网通信等。slb只做转发,不处理请求的,slb通过内网转发到ecs。6)SLB中的月账单 是指我们拥有所有的 SLB 实例的计费呢,还是单独的某个 SLB 的计费?月账单是指您不同类型产品,截止当前日期内月内消费计费额度的,是所有SLB产品的。您也可以通过账单明细进行查询具体信息的。 ------------------------- 2014年2月第4周1)10.159.63.55,这个内网ip,总是恶意访问我们网站?SLB系统除了会通过系统服务器的内网IP将来自外部的访问请求转到后端ECS上之外,还会对ECS进行健康检查(前提是您已经开启了这一功能)和对您的SLB服务进行可用性监控,这些访问的来源都是由SLB系统发起的,具体包含的IP地址段是:杭州、青岛、北京、深圳节点SLB系统IP地址段:10.159.0.0/16,10.158.0.0/16和100.97.0.0/16,为了确保您对外服务的可用性,请确保对上述地址的访问配置放行规则。2)slb计费方式变更需要多久,业务会受到影响么?变更计费方式与变更配置说明1、支持用户在按使用流量和按公网带宽2种计费方式间切换;2、支持按固定带宽方式计费的用户灵活变更带宽配置;3、在一个自然日内,限制用户变更计费方式的次数为1次,变更计费方式将在第二日零点后生效;比如:用户在今天5月5日的10:00提交了变更计费方式,那么该变配申请将在明天5月6日00:00后生效。4、按固定带宽方式计费变更带宽配置即时生效,带宽计费取自然日内用户开通的最高带宽。5、对客户业务不会造成影响;3)负载均衡能将我的外部非阿里云服务器和ECS服务器放到一块?目前负载均衡SLB仅支持阿里云ECS,无法支持外部非阿里云服务器。4)slb是否有连接数限制,需要大量终端一直与平台保持长连接,阿里云能提多少长连接?SLB没有并发连接数限制的,slb是转发请求不做处理,实际连接数还要跟您后端的处理能力有关。 ------------------------- 2015年3月第1周1)调整权重会对SLB已经有的正常连接有影响吗?目前调整权重会对调整权重的这台主机已有的连接产生影响,会有连接卡主,卡住时间由健康检查配置的时间决定。2)slb是否支持UDP协议?目前SLB暂不支持UDP协议。3)现在TCP四层负载均衡的出口带宽受ECS机器的出口带宽限制吗?slb和ECS之间走的是内网流量,带宽是不受限制的。4)如果没有外网ip, 是否可以用slb的4层转发 ?没有带宽4层SLB也是可以使用的。 ------------------------- Re:负载均衡SLB常见咨询问题(持续连载至2015年3月第1周) 2015年3月第2周 1)SLB变更计费方式并支付成功后无法添加配置? SLB在一个自然日内,限制用户变更计费方式的次数为1次,变更计费方式将在第二日零点后生效查看您今天变更过一 次计费方式,开始时间:2015-03-09 00:00:00。原按使用流量计费,在2015-03-09 00:00:00后变更为按固定带宽计 费,带宽峰值: 2Mbps。同时在您新的计费方式生效之前,您是无法对该SLB进行修改配置的。 2)我的账户怎么欠费¥7.88,这是怎么回事? 查看您有使用负载均衡slb业务,在slb产品的账单欠费,请您登陆用户中心-消费记录-账单明细中查看 记录。 3)如何屏蔽健康检查探测的日志记录? 关闭或者屏蔽对test.php访问日志的方式: 在站点配置文件中添加内容: location ~ /test.php { access_log off; fastcgi_pass 127.0.0.1:9000; fastcgi_index index.php; include fastcgi.conf; } 注: 1、对test.php的location必须要放置在对php|php5处理前,否则会因为先被进行全局匹配导致无法生效。 2、还可以用另一种方案实现: a、在后端服务器中单独为用于健康检查的页面建立一个站点; b、关闭这个站点的日志记录: location ~ .*\.(php|php5)?$ { access_log off; fastcgi_pass 127.0.0.1:9000; fastcgi_index index.php; include fastcgi.conf; } 3、如果检查页面是其他格式,比如test.html,可以采用如下方式进行屏蔽: location ~ /test.html { access_log off; } 4.我想问下SLB的固定带宽,10M是不是上行和下行最大都能达到10M? 固定带宽指的是下行带宽最大达到10M,上行带宽没有限制。上行带宽指的是SLB的入流量(上行),就是进入SLB的 流量。带宽指的是SLB的出流量(下行),就是SLB对外发生给客户端的流量。 5.一般配置SLB的时候有个权重0到100,是如何选择数值的? 权重需要您根据后端机器的配置进行选择比如AB两台机器性能一致就分别设置50,这样请求就会在这两台机器上轮询 ,不同权重决定请求分发的分配。 ------------------------- 2015年3月第3周1)公网的SLB和ECS之间的流量是否收费?不收费。2) 想做SLB+两台ECS,附件OSS,程序Discuz。但是不知道如何实现?slb要求后端的两台ecs数据是一致的,为了保持数据的一致性,建议共享存数和数据,静态文件放置到oss里,数据库文件走自己搭建的主从或者,连接同一台rds。3)按流量计算是否需要设置峰值?按流量计费不需要设置峰值的。4)如何建一个子帐号来管理负载均衡SLB?子账户无法管理负载均衡服务。
qilu 2019-12-02 01:15:34 0 浏览量 回答数 0

问题

最大限度利用 JavaScript 和 Ajax 性能:报错

简介 在 web 早期,优化 web 页面的性能通常意味着避免了使用不必要的 HTML 标记,将 JavaScript 代码量控制到最小,并尽量减小所有图片文件大小,否则上网冲浪者会...
kun坤 2020-06-05 22:56:50 0 浏览量 回答数 1

问题

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

为了方便python开发者快速找到相关技术问题和答案,开发者社区策划了python技术1000问内容,包含最基础的如何学python、实践中遇到的技术问题、python面试等维度内容。 我们会以每天至少50条的...
问问小秘 2019-12-01 22:03:02 3129 浏览量 回答数 1

问题

关于多线程编程您不知道的 5 件事:报错

虽然很少有 Java™ 开发人员能够忽视多线程编程和支持它的 Java 平台库,更少有人有时间深入研究线程。相反地,我们临时学习线程,在需要时向我们的工具箱添加新的技巧和技术。以这种方式构建和运行适...
kun坤 2020-06-07 21:21:26 0 浏览量 回答数 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

回答

我们是否还需要另外一个新的数据处理引擎?当我第一次听到flink的时候这是我是非常怀疑的。在大数据领域,现在已经不缺少数据处理框架了,但是没有一个框架能够完全满足不同的处理需求。自从Apache spark出现后,貌似已经成为当今把大部分的问题解决得最好的框架了,所以我对另外一款解决类似问题的框架持有很强烈的怀疑态度。 不过因为好奇,我花费了数个星期在尝试了解flink。一开始仔细看了flink的几个例子,感觉和spark非常类似,心理就倾向于认为flink又是一个模仿spark的框架。但是随着了解的深入,这些API体现了一些flink的新奇的思路,这些思路还是和spark有着比较明显的区别的。我对这些思路有些着迷了,所以花费了更多的时间在这上面。 flink中的很多思路,例如内存管理,dataset API都已经出现在spark中并且已经证明 这些思路是非常靠谱的。所以,深入了解flink也许可以帮助我们分布式数据处理的未来之路是怎样的 在后面的文章里,我会把自己作为一个spark开发者对flink的第一感受写出来。因为我已经在spark上干了2年多了,但是只在flink上接触了2到3周,所以必然存在一些bias,所以大家也带着怀疑和批判的角度来看这篇文章吧。 Apache Flink是什么 flink是一款新的大数据处理引擎,目标是统一不同来源的数据处理。这个目标看起来和spark和类似。没错,flink也在尝试解决spark在解决的问题。这两套系统都在尝试建立一个统一的平台可以运行批量,流式,交互式,图处理,机器学习等应用。所以,flink和spark的目标差别并不大,他们最主要的区别在于实现的细节。 后面我会重点从不同的角度对比这两者。 Apache Spark vs Apache Flink 1.抽象 Abstraction spark中,对于批处理我们有RDD,对于流式,我们有DStream,不过内部实际还是RDD.所以所有的数据表示本质上还是RDD抽象。 后面我会重点从不同的角度对比这两者。在flink中,对于批处理有DataSet,对于流式我们有DataStreams。看起来和spark类似,他们的不同点在于: 一)DataSet在运行时是表现为运行计划(runtime plans)的 在spark中,RDD在运行时是表现为java objects的。通过引入Tungsten,这块有了些许的改变。但是在flink中是被表现为logical plan(逻辑计划)的,听起来很熟悉?没错,就是类似于spark中的dataframes。所以在flink中你使用的类Dataframe api是被作为第一优先级来优化的。但是相对来说在spark RDD中就没有了这块的优化了。 flink中的Dataset,对标spark中的Dataframe,在运行前会经过优化。 在spark 1.6,dataset API已经被引入spark了,也许最终会取代RDD 抽象。 二)Dataset和DataStream是独立的API 在spark中,所有不同的API,例如DStream,Dataframe都是基于RDD抽象的。但是在flink中,Dataset和DataStream是同一个公用的引擎之上两个独立的抽象。所以你不能把这两者的行为合并在一起操作,当然,flink社区目前在朝这个方向努力( https://issues.apache.org/jira/browse/FLINK-2320),但是目前还不能轻易断言最后的结果。 2.内存管理 一直到1.5版本,spark都是试用java的内存管理来做数据缓存,明显很容易导致OOM或者gc。所以从1.5开始,spark开始转向精确的控制内存的使用,这就是tungsten项目了 flink从第一天开始就坚持自己控制内存试用。这个也是启发了spark走这条路的原因之一。flink除了把数据存在自己管理的内存以外,还直接操作二进制数据。在spark中,从1.5开始,所有的dataframe操作都是直接作用在tungsten的二进制数据上。 3.语言实现 spark是用scala来实现的,它提供了Java,Python和R的编程接口。 flink是java实现的,当然同样提供了Scala API 所以从语言的角度来看,spark要更丰富一些。因为我已经转移到scala很久了,所以不太清楚这两者的java api实现情况。 4.API spark和flink都在模仿scala的collection API.所以从表面看起来,两者都很类似。下面是分别用RDD和DataSet API实现的word count // Spark wordcount object WordCount { def main(args: Array[String]) { val env = new SparkContext("local","wordCount") val data = List("hi","how are you","hi") val dataSet = env.parallelize(data) val words = dataSet.flatMap(value => value.split("\\s+")) val mappedWords = words.map(value => (value,1)) val sum = mappedWords.reduceByKey(_+_) println(sum.collect()) } } // Flink wordcount object WordCount { def main(args: Array[String]) { val env = ExecutionEnvironment.getExecutionEnvironment val data = List("hi","how are you","hi") val dataSet = env.fromCollection(data) val words = dataSet.flatMap(value => value.split("\\s+")) val mappedWords = words.map(value => (value,1)) val grouped = mappedWords.groupBy(0) val sum = grouped.sum(1) println(sum.collect()) } } 不知道是偶然还是故意的,API都长得很像,这样很方便开发者从一个引擎切换到另外一个引擎。我感觉以后这种Collection API会成为写data pipeline的标配。 Steaming spark把streaming看成是更快的批处理,而flink把批处理看成streaming的special case。这里面的思路决定了各自的方向,其中两者的差异点有如下这些: 实时 vs 近实时的角度 flink提供了基于每个事件的流式处理机制,所以可以被认为是一个真正的流式计算。它非常像storm的model。 而spark,不是基于事件的粒度,而是用小批量来模拟流式,也就是多个事件的集合。所以spark被认为是近实时的处理系统。 Spark streaming 是更快的批处理,而Flink Batch是有限数据的流式计算。 虽然大部分应用对准实时是可以接受的,但是也还是有很多应用需要event level的流式计算。这些应用更愿意选择storm而非spark streaming,现在,flink也许是一个更好的选择。 流式计算和批处理计算的表示 spark对于批处理和流式计算,都是用的相同的抽象:RDD,这样很方便这两种计算合并起来表示。而flink这两者分为了DataSet和DataStream,相比spark,这个设计算是一个糟糕的设计。 对 windowing 的支持 因为spark的小批量机制,spark对于windowing的支持非常有限。只能基于process time,且只能对batches来做window。 而Flink对window的支持非常到位,且Flink对windowing API的支持是相当给力的,允许基于process time,data time,record 来做windowing。 我不太确定spark是否能引入这些API,不过到目前为止,Flink的windowing支持是要比spark好的。 Steaming这部分flink胜 SQL interface 目前spark-sql是spark里面最活跃的组件之一,Spark提供了类似Hive的sql和Dataframe这种DSL来查询结构化数据,API很成熟,在流式计算中使用很广,预计在流式计算中也会发展得很快。 至于flink,到目前为止,Flink Table API只支持类似DataFrame这种DSL,并且还是处于beta状态,社区有计划增加SQL 的interface,但是目前还不确定什么时候才能在框架中用上。 所以这个部分,spark胜出。 Data source Integration Spark的数据源 API是整个框架中最好的,支持的数据源包括NoSql db,parquet,ORC等,并且支持一些高级的操作,例如predicate push down Flink目前还依赖map/reduce InputFormat来做数据源聚合。 这一场spark胜 Iterative processing spark对机器学习的支持较好,因为可以在spark中利用内存cache来加速机器学习算法。 但是大部分机器学习算法其实是一个有环的数据流,但是在spark中,实际是用无环图来表示的,一般的分布式处理引擎都是不鼓励试用有环图的。 但是flink这里又有点不一样,flink支持在runtime中的有环数据流,这样表示机器学习算法更有效而且更有效率。 这一点flink胜出。 Stream as platform vs Batch as Platform Spark诞生在Map/Reduce的时代,数据都是以文件的形式保存在磁盘中,这样非常方便做容错处理。 Flink把纯流式数据计算引入大数据时代,无疑给业界带来了一股清新的空气。这个idea非常类似akka-streams这种。 成熟度 目前的确有一部分吃螃蟹的用户已经在生产环境中使用flink了,不过从我的眼光来看,Flink还在发展中,还需要时间来成熟。 结论 目前Spark相比Flink是一个更为成熟的计算框架,但是Flink的很多思路很不错,Spark社区也意识到了这一点,并且逐渐在采用Flink中的好的设计思路,所以学习一下Flink能让你了解一下Streaming这方面的更迷人的思路。 答案来源网络,供参考,希望对您有帮助
问问小秘 2019-12-02 02:19:11 0 浏览量 回答数 0

问题

Nginx性能为什么如此吊

Nginx性能为什么如此吊,Nginx性能为什么如此吊,Nginx性能为什么如此吊 (重要的事情说三遍)的性能为什么如此吊!!!         最近几年,web架构拥抱解耦的...
小柒2012 2019-12-01 21:20:47 15038 浏览量 回答数 3

回答

毫无疑问,Java 8是Java自Java 5(发布于2004年)之后的最重要的版本。这个版本包含语言、编译器、库、工具和JVM等方面的十多个新特性。在本文中我们将学习这些新特性,并用实际的例子说明在什么场景下适合使用。 这个教程包含Java开发者经常面对的几类问题: 语言 编译器 库 工具 运行时(JVM) 2. Java语言的新特性 Java 8是Java的一个重大版本,有人认为,虽然这些新特性领Java开发人员十分期待,但同时也需要花不少精力去学习。在这一小节中,我们将介绍Java 8的大部分新特性。 2.1 Lambda表达式和函数式接口 Lambda表达式(也称为闭包)是Java 8中最大和最令人期待的语言改变。它允许我们将函数当成参数传递给某个方法,或者把代码本身当作数据处理:函数式开发者非常熟悉这些概念。很多JVM平台上的语言(Groovy、Scala等)从诞生之日就支持Lambda表达式,但是Java开发者没有选择,只能使用匿名内部类代替Lambda表达式。 Lambda的设计耗费了很多时间和很大的社区力量,最终找到一种折中的实现方案,可以实现简洁而紧凑的语言结构。最简单的Lambda表达式可由逗号分隔的参数列表、->符号和语句块组成,例如: Arrays.asList( "a", "b", "d" ).forEach( e -> System.out.println( e ) ); 在上面这个代码中的参数e的类型是由编译器推理得出的,你也可以显式指定该参数的类型,例如: Arrays.asList( "a", "b", "d" ).forEach( ( String e ) -> System.out.println( e ) ); 如果Lambda表达式需要更复杂的语句块,则可以使用花括号将该语句块括起来,类似于Java中的函数体,例如: Arrays.asList( "a", "b", "d" ).forEach( e -> { System.out.print( e ); System.out.print( e ); } ); Lambda表达式可以引用类成员和局部变量(会将这些变量隐式得转换成final的),例如下列两个代码块的效果完全相同: String separator = ","; Arrays.asList( "a", "b", "d" ).forEach( ( String e ) -> System.out.print( e + separator ) ); 和 final String separator = ","; Arrays.asList( "a", "b", "d" ).forEach( ( String e ) -> System.out.print( e + separator ) ); Lambda表达式有返回值,返回值的类型也由编译器推理得出。如果Lambda表达式中的语句块只有一行,则可以不用使用return语句,下列两个代码片段效果相同: Arrays.asList( "a", "b", "d" ).sort( ( e1, e2 ) -> e1.compareTo( e2 ) ); 和 Arrays.asList( "a", "b", "d" ).sort( ( e1, e2 ) -> { int result = e1.compareTo( e2 ); return result; } ); Lambda的设计者们为了让现有的功能与Lambda表达式良好兼容,考虑了很多方法,于是产生了函数接口这个概念。函数接口指的是只有一个函数的接口,这样的接口可以隐式转换为Lambda表达式。java.lang.Runnable和java.util.concurrent.Callable是函数式接口的最佳例子。在实践中,函数式接口非常脆弱:只要某个开发者在该接口中添加一个函数,则该接口就不再是函数式接口进而导致编译失败。为了克服这种代码层面的脆弱性,并显式说明某个接口是函数式接口,Java 8 提供了一个特殊的注解@FunctionalInterface(Java 库中的所有相关接口都已经带有这个注解了),举个简单的函数式接口的定义: @FunctionalInterface public interface Functional { void method(); } 不过有一点需要注意,默认方法和静态方法不会破坏函数式接口的定义,因此如下的代码是合法的。 @FunctionalInterface public interface FunctionalDefaultMethods { void method(); default void defaultMethod() { } } Lambda表达式作为Java 8的最大卖点,它有潜力吸引更多的开发者加入到JVM平台,并在纯Java编程中使用函数式编程的概念。如果你需要了解更多Lambda表达式的细节,可以参考官方文档。 2.2 接口的默认方法和静态方法 Java 8使用两个新概念扩展了接口的含义:默认方法和静态方法。默认方法使得接口有点类似traits,不过要实现的目标不一样。默认方法使得开发者可以在 不破坏二进制兼容性的前提下,往现存接口中添加新的方法,即不强制那些实现了该接口的类也同时实现这个新加的方法。 默认方法和抽象方法之间的区别在于抽象方法需要实现,而默认方法不需要。接口提供的默认方法会被接口的实现类继承或者覆写,例子代码如下: private interface Defaulable { // Interfaces now allow default methods, the implementer may or // may not implement (override) them. default String notRequired() { return "Default implementation"; } } private static class DefaultableImpl implements Defaulable { } private static class OverridableImpl implements Defaulable { @Override public String notRequired() { return "Overridden implementation"; } } Defaulable接口使用关键字default定义了一个默认方法notRequired()。DefaultableImpl类实现了这个接口,同时默认继承了这个接口中的默认方法;OverridableImpl类也实现了这个接口,但覆写了该接口的默认方法,并提供了一个不同的实现。 Java 8带来的另一个有趣的特性是在接口中可以定义静态方法,例子代码如下: private interface DefaulableFactory { // Interfaces now allow static methods static Defaulable create( Supplier< Defaulable > supplier ) { return supplier.get(); } } 下面的代码片段整合了默认方法和静态方法的使用场景: public static void main( String[] args ) { Defaulable defaulable = DefaulableFactory.create( DefaultableImpl::new ); System.out.println( defaulable.notRequired() ); defaulable = DefaulableFactory.create( OverridableImpl::new ); System.out.println( defaulable.notRequired() ); } 这段代码的输出结果如下: Default implementation Overridden implementation 由于JVM上的默认方法的实现在字节码层面提供了支持,因此效率非常高。默认方法允许在不打破现有继承体系的基础上改进接口。该特性在官方库中的应用是:给java.util.Collection接口添加新方法,如stream()、parallelStream()、forEach()和removeIf()等等。 尽管默认方法有这么多好处,但在实际开发中应该谨慎使用:在复杂的继承体系中,默认方法可能引起歧义和编译错误。如果你想了解更多细节,可以参考官方文档。 2.3 方法引用 方法引用使得开发者可以直接引用现存的方法、Java类的构造方法或者实例对象。方法引用和Lambda表达式配合使用,使得java类的构造方法看起来紧凑而简洁,没有很多复杂的模板代码。 西门的例子中,Car类是不同方法引用的例子,可以帮助读者区分四种类型的方法引用。 public static class Car { public static Car create( final Supplier< Car > supplier ) { return supplier.get(); } public static void collide( final Car car ) { System.out.println( "Collided " + car.toString() ); } public void follow( final Car another ) { System.out.println( "Following the " + another.toString() ); } public void repair() { System.out.println( "Repaired " + this.toString() ); } } 第一种方法引用的类型是构造器引用,语法是Class::new,或者更一般的形式:Class ::new。注意:这个构造器没有参数。 final Car car = Car.create( Car::new ); final List< Car > cars = Arrays.asList( car ); 第二种方法引用的类型是静态方法引用,语法是Class::static_method。注意:这个方法接受一个Car类型的参数。 cars.forEach( Car::collide ); 第三种方法引用的类型是某个类的成员方法的引用,语法是Class::method,注意,这个方法没有定义入参: cars.forEach( Car::repair ); 第四种方法引用的类型是某个实例对象的成员方法的引用,语法是instance::method。注意:这个方法接受一个Car类型的参数: final Car police = Car.create( Car::new ); cars.forEach( police::follow ); 运行上述例子,可以在控制台看到如下输出(Car实例可能不同): Collided com.javacodegeeks.java8.method.references.MethodReferences$Car@7a81197d Repaired com.javacodegeeks.java8.method.references.MethodReferences$Car@7a81197d Following the com.javacodegeeks.java8.method.references.MethodReferences$Car@7a81197d 如果想了解和学习更详细的内容,可以参考官方文档 2.4 重复注解 自从Java 5中引入注解以来,这个特性开始变得非常流行,并在各个框架和项目中被广泛使用。不过,注解有一个很大的限制是:在同一个地方不能多次使用同一个注解。Java 8打破了这个限制,引入了重复注解的概念,允许在同一个地方多次使用同一个注解。 在Java 8中使用@Repeatable注解定义重复注解,实际上,这并不是语言层面的改进,而是编译器做的一个trick,底层的技术仍然相同。可以利用下面的代码说明: package com.javacodegeeks.java8.repeatable.annotations; import java.lang.annotation.ElementType; import java.lang.annotation.Repeatable; import java.lang.annotation.Retention; import java.lang.annotation.RetentionPolicy; import java.lang.annotation.Target; public class RepeatingAnnotations { @Target( ElementType.TYPE ) @Retention( RetentionPolicy.RUNTIME ) public @interface Filters { Filter[] value(); } @Target( ElementType.TYPE ) @Retention( RetentionPolicy.RUNTIME ) @Repeatable( Filters.class ) public @interface Filter { String value(); }; @Filter( "filter1" ) @Filter( "filter2" ) public interface Filterable { } public static void main(String[] args) { for( Filter filter: Filterable.class.getAnnotationsByType( Filter.class ) ) { System.out.println( filter.value() ); } } } 正如我们所见,这里的Filter类使用@Repeatable(Filters.class)注解修饰,而Filters是存放Filter注解的容器,编译器尽量对开发者屏蔽这些细节。这样,Filterable接口可以用两个Filter注解注释(这里并没有提到任何关于Filters的信息)。 另外,反射API提供了一个新的方法:getAnnotationsByType(),可以返回某个类型的重复注解,例如Filterable.class.getAnnoation(Filters.class)将返回两个Filter实例,输出到控制台的内容如下所示: filter1 filter2 如果你希望了解更多内容,可以参考官方文档。 2.5 更好的类型推断 Java 8编译器在类型推断方面有很大的提升,在很多场景下编译器可以推导出某个参数的数据类型,从而使得代码更为简洁。例子代码如下: package com.javacodegeeks.java8.type.inference; public class Value< T > { public static< T > T defaultValue() { return null; } public T getOrDefault( T value, T defaultValue ) { return ( value != null ) ? value : defaultValue; } } 下列代码是Value 类型的应用: package com.javacodegeeks.java8.type.inference; public class TypeInference { public static void main(String[] args) { final Value< String > value = new Value<>(); value.getOrDefault( "22", Value.defaultValue() ); } } 参数Value.defaultValue()的类型由编译器推导得出,不需要显式指明。在Java 7中这段代码会有编译错误,除非使用Value. defaultValue()。 2.6 拓宽注解的应用场景 Java 8拓宽了注解的应用场景。现在,注解几乎可以使用在任何元素上:局部变量、接口类型、超类和接口实现类,甚至可以用在函数的异常定义上。下面是一些例子: package com.javacodegeeks.java8.annotations; import java.lang.annotation.ElementType; import java.lang.annotation.Retention; import java.lang.annotation.RetentionPolicy; import java.lang.annotation.Target; import java.util.ArrayList; import java.util.Collection; public class Annotations { @Retention( RetentionPolicy.RUNTIME ) @Target( { ElementType.TYPE_USE, ElementType.TYPE_PARAMETER } ) public @interface NonEmpty { } public static class Holder< @NonEmpty T > extends @NonEmpty Object { public void method() throws @NonEmpty Exception { } } @SuppressWarnings( "unused" ) public static void main(String[] args) { final Holder< String > holder = new @NonEmpty Holder< String >(); @NonEmpty Collection< @NonEmpty String > strings = new ArrayList<>(); } } ElementType.TYPE_USER和ElementType.TYPE_PARAMETER是Java 8新增的两个注解,用于描述注解的使用场景。Java 语言也做了对应的改变,以识别这些新增的注解。 Java编译器的新特性 3.1 参数名称 为了在运行时获得Java程序中方法的参数名称,老一辈的Java程序员必须使用不同方法,例如Paranamer liberary。Java 8终于将这个特性规范化,在语言层面(使用反射API和Parameter.getName()方法)和字节码层面(使用新的javac编译器以及-parameters参数)提供支持。 package com.javacodegeeks.java8.parameter.names; import java.lang.reflect.Method; import java.lang.reflect.Parameter; public class ParameterNames { public static void main(String[] args) throws Exception { Method method = ParameterNames.class.getMethod( "main", String[].class ); for( final Parameter parameter: method.getParameters() ) { System.out.println( "Parameter: " + parameter.getName() ); } } } 在Java 8中这个特性是默认关闭的,因此如果不带-parameters参数编译上述代码并运行,则会输出如下结果: Parameter: arg0 如果带-parameters参数,则会输出如下结果(正确的结果): Parameter: args 如果你使用Maven进行项目管理,则可以在maven-compiler-plugin编译器的配置项中配置-parameters参数: org.apache.maven.plugins maven-compiler-plugin 3.1 -parameters 1.8 1.8 4. Java官方库的新特性 Java 8增加了很多新的工具类(date/time类),并扩展了现存的工具类,以支持现代的并发编程、函数式编程等。 4.1 Optional Java应用中最常见的bug就是空值异常。在Java 8之前,Google Guava引入了Optionals类来解决NullPointerException,从而避免源码被各种null检查污染,以便开发者写出更加整洁的代码。Java 8也将Optional加入了官方库。 Optional仅仅是一个容易:存放T类型的值或者null。它提供了一些有用的接口来避免显式的null检查,可以参考Java 8官方文档了解更多细节。 接下来看一点使用Optional的例子:可能为空的值或者某个类型的值: Optional< String > fullName = Optional.ofNullable( null ); System.out.println( "Full Name is set? " + fullName.isPresent() ); System.out.println( "Full Name: " + fullName.orElseGet( () -> "[none]" ) ); System.out.println( fullName.map( s -> "Hey " + s + "!" ).orElse( "Hey Stranger!" ) ); 如果Optional实例持有一个非空值,则isPresent()方法返回true,否则返回false;orElseGet()方法,Optional实例持有null,则可以接受一个lambda表达式生成的默认值;map()方法可以将现有的Opetional实例的值转换成新的值;orElse()方法与orElseGet()方法类似,但是在持有null的时候返回传入的默认值。 上述代码的输出结果如下: Full Name is set? false Full Name: [none] Hey Stranger! 再看下另一个简单的例子: Optional< String > firstName = Optional.of( "Tom" ); System.out.println( "First Name is set? " + firstName.isPresent() ); System.out.println( "First Name: " + firstName.orElseGet( () -> "[none]" ) ); System.out.println( firstName.map( s -> "Hey " + s + "!" ).orElse( "Hey Stranger!" ) ); System.out.println(); 这个例子的输出是: First Name is set? true First Name: Tom Hey Tom! 如果想了解更多的细节,请参考官方文档。 4.2 Streams 新增的Stream API(java.util.stream)将生成环境的函数式编程引入了Java库中。这是目前为止最大的一次对Java库的完善,以便开发者能够写出更加有效、更加简洁和紧凑的代码。 Steam API极大得简化了集合操作(后面我们会看到不止是集合),首先看下这个叫Task的类: public class Streams { private enum Status { OPEN, CLOSED }; private static final class Task { private final Status status; private final Integer points; Task( final Status status, final Integer points ) { this.status = status; this.points = points; } public Integer getPoints() { return points; } public Status getStatus() { return status; } @Override public String toString() { return String.format( "[%s, %d]", status, points ); } } } Task类有一个分数(或伪复杂度)的概念,另外还有两种状态:OPEN或者CLOSED。现在假设有一个task集合: final Collection< Task > tasks = Arrays.asList( new Task( Status.OPEN, 5 ), new Task( Status.OPEN, 13 ), new Task( Status.CLOSED, 8 ) ); 首先看一个问题:在这个task集合中一共有多少个OPEN状态的点?在Java 8之前,要解决这个问题,则需要使用foreach循环遍历task集合;但是在Java 8中可以利用steams解决:包括一系列元素的列表,并且支持顺序和并行处理。 // Calculate total points of all active tasks using sum() final long totalPointsOfOpenTasks = tasks .stream() .filter( task -> task.getStatus() == Status.OPEN ) .mapToInt( Task::getPoints ) .sum(); System.out.println( "Total points: " + totalPointsOfOpenTasks ); 运行这个方法的控制台输出是: Total points: 18 这里有很多知识点值得说。首先,tasks集合被转换成steam表示;其次,在steam上的filter操作会过滤掉所有CLOSED的task;第三,mapToInt操作基于每个task实例的Task::getPoints方法将task流转换成Integer集合;最后,通过sum方法计算总和,得出最后的结果。 在学习下一个例子之前,还需要记住一些steams(点此更多细节)的知识点。Steam之上的操作可分为中间操作和晚期操作。 中间操作会返回一个新的steam——执行一个中间操作(例如filter)并不会执行实际的过滤操作,而是创建一个新的steam,并将原steam中符合条件的元素放入新创建的steam。 晚期操作(例如forEach或者sum),会遍历steam并得出结果或者附带结果;在执行晚期操作之后,steam处理线已经处理完毕,就不能使用了。在几乎所有情况下,晚期操作都是立刻对steam进行遍历。 steam的另一个价值是创造性地支持并行处理(parallel processing)。对于上述的tasks集合,我们可以用下面的代码计算所有任务的点数之和: // Calculate total points of all tasks final double totalPoints = tasks .stream() .parallel() .map( task -> task.getPoints() ) // or map( Task::getPoints ) .reduce( 0, Integer::sum ); System.out.println( "Total points (all tasks): " + totalPoints ); 这里我们使用parallel方法并行处理所有的task,并使用reduce方法计算最终的结果。控制台输出如下: Total points(all tasks): 26.0 对于一个集合,经常需要根据某些条件对其中的元素分组。利用steam提供的API可以很快完成这类任务,代码如下: // Group tasks by their status final Map< Status, List< Task > > map = tasks .stream() .collect( Collectors.groupingBy( Task::getStatus ) ); System.out.println( map ); 控制台的输出如下: {CLOSED=[[CLOSED, 8]], OPEN=[[OPEN, 5], [OPEN, 13]]} 最后一个关于tasks集合的例子问题是:如何计算集合中每个任务的点数在集合中所占的比重,具体处理的代码如下: // Calculate the weight of each tasks (as percent of total points) final Collection< String > result = tasks .stream() // Stream< String > .mapToInt( Task::getPoints ) // IntStream .asLongStream() // LongStream .mapToDouble( points -> points / totalPoints ) // DoubleStream .boxed() // Stream< Double > .mapToLong( weigth -> ( long )( weigth * 100 ) ) // LongStream .mapToObj( percentage -> percentage + "%" ) // Stream< String> .collect( Collectors.toList() ); // List< String > System.out.println( result ); 控制台输出结果如下: [19%, 50%, 30%] 最后,正如之前所说,Steam API不仅可以作用于Java集合,传统的IO操作(从文件或者网络一行一行得读取数据)可以受益于steam处理,这里有一个小例子: final Path path = new File( filename ).toPath(); try( Stream< String > lines = Files.lines( path, StandardCharsets.UTF_8 ) ) { lines.onClose( () -> System.out.println("Done!") ).forEach( System.out::println ); } Stream的方法onClose 返回一个等价的有额外句柄的Stream,当Stream的close()方法被调用的时候这个句柄会被执行。Stream API、Lambda表达式还有接口默认方法和静态方法支持的方法引用,是Java 8对软件开发的现代范式的响应。 4.3 Date/Time API(JSR 310) Java 8引入了新的Date-Time API(JSR 310)来改进时间、日期的处理。时间和日期的管理一直是最令Java开发者痛苦的问题。java.util.Date和后来的java.util.Calendar一直没有解决这个问题(甚至令开发者更加迷茫)。 因为上面这些原因,诞生了第三方库Joda-Time,可以替代Java的时间管理API。Java 8中新的时间和日期管理API深受Joda-Time影响,并吸收了很多Joda-Time的精华。新的java.time包包含了所有关于日期、时间、时区、Instant(跟日期类似但是精确到纳秒)、duration(持续时间)和时钟操作的类。新设计的API认真考虑了这些类的不变性(从java.util.Calendar吸取的教训),如果某个实例需要修改,则返回一个新的对象。 我们接下来看看java.time包中的关键类和各自的使用例子。首先,Clock类使用时区来返回当前的纳秒时间和日期。Clock可以替代System.currentTimeMillis()和TimeZone.getDefault()。 // Get the system clock as UTC offset final Clock clock = Clock.systemUTC(); System.out.println( clock.instant() ); System.out.println( clock.millis() ); 这个例子的输出结果是: 2014-04-12T15:19:29.282Z 1397315969360 第二,关注下LocalDate和LocalTime类。LocalDate仅仅包含ISO-8601日历系统中的日期部分;LocalTime则仅仅包含该日历系统中的时间部分。这两个类的对象都可以使用Clock对象构建得到。 // Get the local date and local time final LocalDate date = LocalDate.now(); final LocalDate dateFromClock = LocalDate.now( clock ); System.out.println( date ); System.out.println( dateFromClock ); // Get the local date and local time final LocalTime time = LocalTime.now(); final LocalTime timeFromClock = LocalTime.now( clock ); System.out.println( time ); System.out.println( timeFromClock ); 上述例子的输出结果如下: 2014-04-12 2014-04-12 11:25:54.568 15:25:54.568 LocalDateTime类包含了LocalDate和LocalTime的信息,但是不包含ISO-8601日历系统中的时区信息。这里有一些关于LocalDate和LocalTime的例子: // Get the local date/time final LocalDateTime datetime = LocalDateTime.now(); final LocalDateTime datetimeFromClock = LocalDateTime.now( clock ); System.out.println( datetime ); System.out.println( datetimeFromClock ); 上述这个例子的输出结果如下: 2014-04-12T11:37:52.309 2014-04-12T15:37:52.309 如果你需要特定时区的data/time信息,则可以使用ZoneDateTime,它保存有ISO-8601日期系统的日期和时间,而且有时区信息。下面是一些使用不同时区的例子: // Get the zoned date/time final ZonedDateTime zonedDatetime = ZonedDateTime.now(); final ZonedDateTime zonedDatetimeFromClock = ZonedDateTime.now( clock ); final ZonedDateTime zonedDatetimeFromZone = ZonedDateTime.now( ZoneId.of( "America/Los_Angeles" ) ); System.out.println( zonedDatetime ); System.out.println( zonedDatetimeFromClock ); System.out.println( zonedDatetimeFromZone ); 这个例子的输出结果是: 2014-04-12T11:47:01.017-04:00[America/New_York] 2014-04-12T15:47:01.017Z 2014-04-12T08:47:01.017-07:00[America/Los_Angeles] 最后看下Duration类,它持有的时间精确到秒和纳秒。这使得我们可以很容易得计算两个日期之间的不同,例子代码如下: // Get duration between two dates final LocalDateTime from = LocalDateTime.of( 2014, Month.APRIL, 16, 0, 0, 0 ); final LocalDateTime to = LocalDateTime.of( 2015, Month.APRIL, 16, 23, 59, 59 ); final Duration duration = Duration.between( from, to ); System.out.println( "Duration in days: " + duration.toDays() ); System.out.println( "Duration in hours: " + duration.toHours() ); 这个例子用于计算2014年4月16日和2015年4月16日之间的天数和小时数,输出结果如下: Duration in days: 365 Duration in hours: 8783 对于Java 8的新日期时间的总体印象还是比较积极的,一部分是因为Joda-Time的积极影响,另一部分是因为官方终于听取了开发人员的需求。如果希望了解更多细节,可以参考官方文档。 4.4 Nashorn JavaScript引擎 Java 8提供了新的Nashorn JavaScript引擎,使得我们可以在JVM上开发和运行JS应用。Nashorn JavaScript引擎是javax.script.ScriptEngine的另一个实现版本,这类Script引擎遵循相同的规则,允许Java和JavaScript交互使用,例子代码如下: ScriptEngineManager manager = new ScriptEngineManager(); ScriptEngine engine = manager.getEngineByName( "JavaScript" ); System.out.println( engine.getClass().getName() ); System.out.println( "Result:" + engine.eval( "function f() { return 1; }; f() + 1;" ) ); 这个代码的输出结果如下: jdk.nashorn.api.scripting.NashornScriptEngine Result: 2 4.5 Base64 对Base64编码的支持已经被加入到Java 8官方库中,这样不需要使用第三方库就可以进行Base64编码,例子代码如下: package com.javacodegeeks.java8.base64; import java.nio.charset.StandardCharsets; import java.util.Base64; public class Base64s { public static void main(String[] args) { final String text = "Base64 finally in Java 8!"; final String encoded = Base64 .getEncoder() .encodeToString( text.getBytes( StandardCharsets.UTF_8 ) ); System.out.println( encoded ); final String decoded = new String( Base64.getDecoder().decode( encoded ), StandardCharsets.UTF_8 ); System.out.println( decoded ); } } 这个例子的输出结果如下: QmFzZTY0IGZpbmFsbHkgaW4gSmF2YSA4IQ== Base64 finally in Java 8! 新的Base64API也支持URL和MINE的编码解码。 (Base64.getUrlEncoder() / Base64.getUrlDecoder(), Base64.getMimeEncoder() / Base64.getMimeDecoder())。 4.6 并行数组 Java8版本新增了很多新的方法,用于支持并行数组处理。最重要的方法是parallelSort(),可以显著加快多核机器上的数组排序。下面的例子论证了parallexXxx系列的方法: package com.javacodegeeks.java8.parallel.arrays; import java.util.Arrays; import java.util.concurrent.ThreadLocalRandom; public class ParallelArrays { public static void main( String[] args ) { long[] arrayOfLong = new long [ 20000 ]; Arrays.parallelSetAll( arrayOfLong, index -> ThreadLocalRandom.current().nextInt( 1000000 ) ); Arrays.stream( arrayOfLong ).limit( 10 ).forEach( i -> System.out.print( i + " " ) ); System.out.println(); Arrays.parallelSort( arrayOfLong ); Arrays.stream( arrayOfLong ).limit( 10 ).forEach( i -> System.out.print( i + " " ) ); System.out.println(); } } 上述这些代码使用parallelSetAll()方法生成20000个随机数,然后使用parallelSort()方法进行排序。这个程序会输出乱序数组和排序数组的前10个元素。上述例子的代码输出的结果是: Unsorted: 591217 891976 443951 424479 766825 351964 242997 642839 119108 552378 Sorted: 39 220 263 268 325 607 655 678 723 793 4.7 并发性 基于新增的lambda表达式和steam特性,为Java 8中为java.util.concurrent.ConcurrentHashMap类添加了新的方法来支持聚焦操作;另外,也为java.util.concurrentForkJoinPool类添加了新的方法来支持通用线程池操作(更多内容可以参考我们的并发编程课程)。 Java 8还添加了新的java.util.concurrent.locks.StampedLock类,用于支持基于容量的锁——该锁有三个模型用于支持读写操作(可以把这个锁当做是java.util.concurrent.locks.ReadWriteLock的替代者)。 在java.util.concurrent.atomic包中也新增了不少工具类,列举如下: DoubleAccumulator DoubleAdder LongAccumulator LongAdder 5. 新的Java工具 Java 8提供了一些新的命令行工具,这部分会讲解一些对开发者最有用的工具。 5.1 Nashorn引擎:jjs jjs是一个基于标准Nashorn引擎的命令行工具,可以接受js源码并执行。例如,我们写一个func.js文件,内容如下: function f() { return 1; }; print( f() + 1 ); 可以在命令行中执行这个命令:jjs func.js,控制台输出结果是: 2 如果需要了解细节,可以参考官方文档。 5.2 类依赖分析器:jdeps jdeps是一个相当棒的命令行工具,它可以展示包层级和类层级的Java类依赖关系,它以.class文件、目录或者Jar文件为输入,然后会把依赖关系输出到控制台。 我们可以利用jedps分析下Spring Framework库,为了让结果少一点,仅仅分析一个JAR文件:org.springframework.core-3.0.5.RELEASE.jar。 jdeps org.springframework.core-3.0.5.RELEASE.jar 这个命令会输出很多结果,我们仅看下其中的一部分:依赖关系按照包分组,如果在classpath上找不到依赖,则显示"not found". org.springframework.core-3.0.5.RELEASE.jar -> C:\Program Files\Java\jdk1.8.0\jre\lib\rt.jar org.springframework.core (org.springframework.core-3.0.5.RELEASE.jar) -> java.io -> java.lang -> java.lang.annotation -> java.lang.ref -> java.lang.reflect -> java.util -> java.util.concurrent -> org.apache.commons.logging not found -> org.springframework.asm not found -> org.springframework.asm.commons not found org.springframework.core.annotation (org.springframework.core-3.0.5.RELEASE.jar) -> java.lang -> java.lang.annotation -> java.lang.reflect -> java.util 更多的细节可以参考官方文档。 JVM的新特性 使用Metaspace(JEP 122)代替持久代(PermGen space)。在JVM参数方面,使用-XX:MetaSpaceSize和-XX:MaxMetaspaceSize代替原来的-XX:PermSize和-XX:MaxPermSize。 结论 通过为开发者提供很多能够提高生产力的特性,Java 8使得Java平台前进了一大步。现在还不太适合将Java 8应用在生产系统中,但是在之后的几个月中Java 8的应用率一定会逐步提高(PS:原文时间是2014年5月9日,现在在很多公司Java 8已经成为主流,我司由于体量太大,现在也在一点点上Java 8,虽然慢但是好歹在升级了)。作为开发者,现在应该学习一些Java 8的知识,为升级做好准备。 关于Spring:对于企业级开发,我们也应该关注Spring社区对Java 8的支持,可以参考这篇文章——Spring 4支持的Java 8新特性一览 参考资料 What’s New in JDK 8 The Java Tutorials WildFly 8, JDK 8, NetBeans 8, Java EE Java 8 Tutorial JDK 8 Command-line Static Dependency Checker The Illuminating Javadoc of JDK The Dark Side of Java 8 Installing Java™ 8 Support in Eclipse Kepler SR2 Java 8 Oracle Nashorn. A Next-Generation JavaScript Engine for the JVM 举报
游客2q7uranxketok 2021-02-08 10:54:06 0 浏览量 回答数 0

云产品推荐

上海奇点人才服务相关的云产品 小程序定制 上海微企信息技术相关的云产品 国内短信套餐包 ECS云服务器安全配置相关的云产品 开发者问答 阿里云建站 自然场景识别相关的云产品 万网 小程序开发制作 视频内容分析 视频集锦 代理记账服务 阿里云AIoT