游客6ofdw4qlyvf7i
游客6ofdw4qlyvf7i_个人页
游客6ofdw4qlyvf7i
文章
55
问答
0
视频
0
个人介绍
暂无个人介绍
擅长的技术
获得更多能力
通用技术能力：
-
Java
初级
能力说明：
了解变量作用域、Java类的结构，能够创建带main方法可执行的java应用，从命令行运行java程序；能够使用Java基本数据类型、运算符和控制结构、数组、循环结构书写和运行简单的Java程序。
云产品技术能力：
暂时未有相关云产品技术能力~
阿里云技能认证
详细说明-
发表了文章 2020-11-04
如何购买阿里云服务器ECS更便宜实惠？
接触BAT云也有3个月了，从服务器、虚拟主机是什么都不知道，到现在对BAT服务器（海外、国内），虚拟主机（独享IP、共享IP等）均有所了解，其中吃过的苦，走过的弯路只有过来人才知道。 接触BAT云也有3个月了，从服务器、虚拟主机是什么都不知道，到现在对BAT服务器（海外、国内），虚拟主机（独享IP、共享IP等）均有所了解，其中吃过的苦，走过的弯路只有过来人才知道。 为了让新手了解去服务器，本期我们主要介绍如何购买阿里云ECS服务器，希望能通过我的经验，能帮助到大家！ 一：访问阿里云官网 二：注册阿里云账号，或者使用淘宝账号登录激活阿里云账号。个人建议直接单独注册比较好 三：从产品里面选择云服务器ECS 四：进入页面后选择立即购买，针对新用户一般有活动，比如最近可以用￥89.76/年购买1核2G的国内线路 五：选择购买的配置， 主要从以下几个方面考虑： 1.付费方式：按年付费，按使用量付费。建议新人按月或者按年付费，同时建议至少选1年-3年，因为折扣更多。 2.选择服务器所在的地区：如果国内的话，其实访问速度都差不多，建议选择华北区域，是新开的，价格会要比其他地区优惠。 3.选择实列，也就是选择你的服务器配置。这里有很多配置，我就只列举一下新手需要的配置：1VCPU，2Gbit就可以满足需求了更多的实例我抽时间写一个适合不同行业的。 4.镜像，也就是你的系统，如果你喜欢折腾就选择系统镜像，建议用linux，选centos操作系统比较好。这个镜像等你购买好服务器后，大概2-3分钟，你打开你的服务器就是一个崭新的系统，没有任何其他文件。 当然，如果你不想折腾，也可以在镜像市场选择一个，有免费的，也有付费的，马士虽笔记自动帮你安装好你选择的功能，免去了很多配置的要求，对于不会配置服务器的站长来说，不失为一个好的选择。 六：磁盘，默认系统盘是40GB，基本够用了，我们可以单独开一个OSS，用于放图片和文件。价格非常便宜1年也就12元。 七：公网带宽：也就是你的服务器外部访问的带宽，说点心得： 1.简单一点，你就按照1M带宽一天1000个IP来计算，比如你预估你网站一天有2000个IP来访问，你就选择固定的2M带宽。 2.你也可以选择弹性带宽，用多少算多少，不过这个是后付费的，你需要保证你的账号里面一直有余额，不然会停到你的外部访问，好处就是在开始访客较少的时候，你可以少付些带宽费用。 十：安全组，这个你记得勾选一下80端口和443端口，不然你弄了半天发现通过域名就是访问不了你的网站，在服务器打开又是正常的。那是因为你没有打开80端口的访问权限，所有在购买的时候就把端口打开。 到这里就可以直接确认订单，付款购买了。 也可以选择把服务器配置好了之后再付款。但是你配置的信息请一定记住，因为这些配置信息是你访问服务器的密码信息。 配置好了之后，付费完成大概5分钟左右，系统就会把你的系统安装完成。 云服务器ECS地址：阿里云·云小站
-
发表了文章 2020-10-31
阿里云服务器1核2GB5M配置仅需201元/年
阿里云活动出现了一款性价比极高的云服务器，1核2GB 5M只要201元 。明星机型——售价91元的1核2GB 1Mb的T5型云服务器。两款云服务器价格都非常便宜，但我这边强烈推荐大家买5M带宽的云服务器。 众所周知，很多用户购买这两款入门级配置一方面是为了学习，另一方面是为了建站或者运行一些爬虫之类的软件。但现在随便一个张图片，一个CSS，JS文件都在几百K左右，首页大小很少有小于1MB的。这样我们的1Mb小水管就不太够用了，大家都知道1Mb=128KB,以用户打开一个1MB左右的网页为例，1Mb小水管足足要8秒(1024/128=8),而5Mb只要1.6秒即可。 两款云服务器之间，相差4Mb带宽，价格相差只有99元;目前，阿里云服务器的各个组件最贵的就是带宽，每Mb的售价高达50元/月，因为带宽是各大运营商提供的，价格并不是直接受控于阿里云的。如果你想后期升级4Mb，你付出的决定不是99元，而是50412=2400元。 购买地址:阿里云大促活动 云服务器ECS地址：阿里云·云小站
-
发表了文章 2020-10-31
阿里云服务器双十一配置仅需85元/年
阿里云活动出现了一款性价比极高的云服务器，1核2GB 1M只要84.97元 。明星机型——254.92售价元的1核2GB 1Mb的ECS共享型。两款云服务器价格都非常便宜，但我这边强烈推荐大家买5M带宽的云服务器。 众所周知，很多用户购买这两款入门级配置一方面是为了学习，另一方面是为了建站或者运行一些爬虫之类的软件。但现在随便一个张图片，一个CSS，JS文件都在几百K左右，首页大小很少有小于1MB的。这样我们的1Mb小水管就不太够用了，大家都知道1Mb=128KB,以用户打开一个1MB左右的网页为例，1Mb小水管足足要8秒(1024/128=8),而5Mb只要1.6秒即可。 两款云服务器之间，相差4Mb带宽，价格相差只有99元;目前，阿里云服务器的各个组件最贵的就是带宽，每Mb的售价高达50元/月，因为带宽是各大运营商提供的，价格并不是直接受控于阿里云的。如果你想后期升级4Mb，你付出的决定不是99元，而是50412=2400元。 购买地址:阿里云大促活动 云服务器ECS地址：阿里云·云小站
-
发表了文章 2020-10-08
阿里云GPU云服务器抢占式实例大幅度降低GPU云服务器实例成本
深度学习科学计算等应用场景首选GPU云服务器，但是GPU服务器硬件成本高，让很多开发者望而却步，云服务器吧建议大家可以选择阿里云GPU云服务器竞价型实例，现在竞价型实例已经改名为抢占式实例，阿里云推出竞价型GPU云服务器，极大程度的降低成本提高计算能力，使GPU成为强大的技术云助力产品： 阿里云GPU云服务器抢占式实例 科学计算、AI深度学习、视频渲染转码等应用场景适用GPU服务器再合适不过了，阿里云GPU云服务器推出竞价型实例（现更名为抢占式实例），适用成本大幅度降低，云服务器吧以ecs.gn5i-c2g1.large实例为例，来计算不同计费方式下云服务器1小时价格： 购买方式 时间周期（1小时） 按量付费 8.266元 周价格 4.2元 月价 3.35元 竞价实例（抢占式实例） 0.888元 如上表所示，GPU云服务器选择竞价实例（抢占式实例）计费模式，一小时的价格为0.888元，一天21.3元，一周149元。需要注意的是，当市场价格高于用户的出价或者资源供需关系变化时，实例会被自动释放，所以一定要做好备份，可以参考官方文档对于抢占式实例优缺点的介绍：抢占式实例常见问题及解答FAQ - 阿里云 本文指的竞价实例现已更名为抢占式实例，阿里云服务器计费方式分为包年包月、按量付费和抢占式实例，由于GPU云服务器成本较高，可以选择抢占式实例的计费模式来降低使用成本。 云服务器ECS地址：阿里云·云小站
-
发表了文章 2020-10-08
阿里云心选商城—网站建设篇之——云·企业官网定制
使用阿里云建网站的三种方式购买云服务器手动建站、云速成美站模板建站或者选择阿里云定制建站三种方式，站长分享利用阿里云创建网站的三种方式及优势对比： 阿里云建站方法汇总 使用阿里云建站可以有三种方式， 第一种是购买ECS云服务器，然后自行手动搭建网站，需要技术门槛； 第二种方式是购买阿里云官网云速成美站，使用模板建站，阿里云提供上千套模板，模板建站价格便宜，会打字就会建站； 第三种是使用阿里云官方定制建站，需要什么样的网站什么功能，阿里云建站专家提供一对一网站定制。参考下表： 阿里云建站方式 所需产品 优势 适用人群 自助建站 ECS云服务器 自行购买云服务器，手动搭建网站 需要些技术门槛，适用于刚接触云计算或对云服务器和建站不太了解、希望自行设计网站的个人或小企业用户。 模板建站 云·速成美站 使用阿里云提供上千套模板，可视化后台管理，会打字就会建站 适合有一定软件应用能力的个人或小企业用户，模板建站支持Web站点、移动端站点、互动表单以及会员支付多场景。 定制建站 云·企业网站定制和功能定制 由阿里云专业网站设计师完成网站设计及搭建 适合对网站有品质要求或个性化需求、希望节省人力和时间成本的企业用户。 阿里云建站产品如何选择？如果您是站长类的技术人员，当然选择自助建站方式，如果非技术人员，个人或者工作室建议选择云·速成美站，如果是企业用户建站选择阿里云网站定制服务。 阿里云建站不需要用户另外购买云服务器或虚拟主机等产品，阿里云提供香港节点并且提供全球CDN加速，不用备案，拿来即用。阿里云大品牌无隐形消费，我见过太多打着免费建站的幌子，实际价格贵的离谱。举例来说，免费建站，使用的域名是对方的三级域名，域名人家说收回就收回，免费建站，云主机却要收费，而且价格很贵没有质量保障，网站说打不开就打不开。 我从新手过来的，之前使用过免费域名，用了有一段时间了，结果被收回了，使用免费虚拟主机，速度卡不说，结果网站数据丢失了，这不是免费惹的祸，是小编贪图便宜惹的祸，建议选择大品牌，值得信赖。 云服务器ECS地址：阿里云·云小站
-
发表了文章 2020-10-04
阿里云服务器操作系统怎么选择？
阿里云ECS云服务器操作系统分为Windows类和Linux类，下面我们一起探讨下阿里云服务器的windows和linux系统怎么选及操作系统32位和64位的区别： 阿里云服务器操作系统是什么阿里云ECS云服务器操作系统是通过镜像来实现的，云服务器操作系统一般分为两类，即Windows和类Unix/Linux，阿里云提供的Windows系统均为正版，两类操作系统如下：Windows操作系统Windows系统适合运行Windows下开发的程序，如.NET等，Windows支持SQL Server等数据库（需自行安装），另外，512内存不支持选Windows系统，1G以上内存才能很好支持该系统。 Windows操作系统相对于Linux而言，比较占用系统资源，如果云服务器配置较低可以选择Version 1909 数据中心版 64位中文版（不含UI），不含UI版本的镜像保留了最新的Windows server性能，去除了UI减少了资源占用。 如何选择服务器操作系统？只需要根据自己网站的建站程序使用语言选择对应的系统即可，以网站开发为例： ASP、.NET、HTML、数据库ACCESS、SQL Server建议选择Windows；PHP、PERL、CGI、数据库MySQL、SQLite建议选择Linux。 现在阿里云官方推出Aliyun Linux镜像，Aliyun Linux系统镜像是阿里云原生Linux操作系统，Aliyun Linux由阿里云官方提供长期支持和维护(LTS)，针对 ECS 做了大量深度优化，完全兼容 CentOS 生态和操作方式，提供更佳的性能和体验。详细可以参考官方说明：Alibaba Cloud Linux 2 如果不会linux系统环境怎么办？当然，我们也可以通过镜像市场，选择已经配置好的镜像，这样就省去我们装服务器系统环境的时间。尤其对于linux命令不太熟悉的新手站长，用命令配置服务器时会比较吃力，所以强烈推荐大家可以购买时直接在“镜像市场”选择安装宝塔控制面板的云服务器。 镜像选择32位和64位操作系统？32位和64位有什么区别呢？32位系统是指CPU一次性可以处理32位数据，64位是指CPU一次性可处理64位数据，理论上64位更快一些，但是实际速度更多的是依赖内存的大小。那么服务器操作系统是选择32位还是64位呢？这个首先要取决于你的云服务器内存，一般来说，如果内存在4G以上，建议可以考虑选择64位的，如果在4G以下，还是选择32位的比较稳妥。 操作系统可以更换吗？ 镜像操作系统是可以更换的，后续可以通过ECS控制台的更换系统盘功能来更换操作系统，更换操作系统是免费的。注意：如果用户购买的是国内大陆地域（华北1、华北2、华北3、华北5、华东1、华东2及华南1）的云服务器，后续是可以随意更换操作系统的；如果是中国香港、美国等海外地域的云服务器，则无法更换操作系统。 云服务器ECS地址：阿里云·云小站
-
发表了文章 2020-10-04
2020年国内十大云计算商排名榜
云计算在中国经过数年发展后，技术和市场都越发成熟。随着性能和稳定的提高，成本的降低，个人和企业用户都开始逐步接受云服务，但无论在全球范围还是中国范围内，云计算市场还只是起步阶段。 中国云市场来看，表面看似巨头已经瓜分天下，但实际上，出色的新秀在不断涌现，利用自己的特色优势在细分市场中分一杯羹。笔者根据企业实力，产品性能、性价比、服务评价等方面选出了市场认可度高的中国十大公有云计算服务商云计算服务商。 2020年中国十大云计算商排名最新榜单： 1. 阿里云: 在国内互联网企业梯队当中，阿里云的先发优势明显，资金雄厚，并在“人工智能、物联网、边缘计算”等重要新兴技术中处于领先地位。 2. 腾讯云: 腾讯多年对海量互联网服务的经验，不管是社交、游戏还是其他领域，能为开发者及企业提供云服务等整体一站式服务方案。 3. 华为云: 国内大型云服务与解决方案供应商，专注于为企业、事业机构、创业群体提供安全中立的IT基础设施云服务。 4. 金山云：金山云构建了完备的云计算基础架构和运营体系，公有云客户主要来自游戏，视频，电子商务等行业。 5. 百度云：百度云专注于“云计算+大数据+人工智能”的布局，其技术已经在内部众多业务中得到了成熟的应用。 6. ucloud：专注于基础云计算产品研发与运营的综合性云服务商。 7. 京东云：京东云依托京东集团在云计算、大数据、物联网和移动互联网应用等多方面的业务实践和技术积淀，在“电商云”上较具有优势。 8. 亿速云：亿速云主要以游戏云、高防云为突破点，在海外云上表现也非常突出，帮助了大量企业及开发者成功通过云计算进行海外业务拓展，可以说通过了垂直细分领域在云计算红海杀出一条路，并成功攻入国内专业公有云服务商前十名。 9. 青云：企业级全栈云 ICT 服务商和解决方案提供商，基于云模式的综合企业服务平台。 10. 西部数码：中国老牌互联网服务提供商，业务广泛，服务项目包括域名注册、 虚拟主机、VPS、云主机、企业邮箱、主机租用托管等。 注：这里只列出国内专业公有云，不包含国外云、运营商云(电信、移动、联通)和其它集成商云。 其实对于任何服务业来讲，有竞争才有进步，云服务市场也是如此，从以上的“十大云服务器服务商排行榜”就可以看出，不仅仅是一些云巨头可以占领市场，像亿速云这种行业新秀也可以跟BAT等巨头一较高下。究其原因，主要是因为云巨头的产品线广，用户多了，服务水平自然没办法跟上来，也没办法解决得了所有客户问题的。比如很多云巨头取消了在线客服，只能提交工单，很多用户联系售后服务时就连队都排不上，出现大量用户求助无门的场面。这种情况下，市场会有更多个性化需求的出现，就会催生新的市场机会。 笔者认为，大数据支撑之外的云服务公司，必须在细分垂直领域深耕，才可能闯出一片天空。正如畅销书《定位》书中所说的：要在细分品类占领用户的心智，从而建立一个领域的品牌。如果新兴云服务商去学习固定模式去做大而全的产品，可能很快就会给市场淹没! 云服务器ECS地址：阿里云·云小站
-
发表了文章 2020-10-04
阿里云服务器进入黑洞怎么办？如何查看进入黑洞时间与原因
阿里云服务器进入黑洞怎么办？阿里云服务器黑洞如何解封？阿里云黑洞多长时间？什么是黑洞？如何提高防护免遭黑洞？笔者来详细说下阿里云服务器黑洞策略常见问题及解答，以及阿里云黑洞解除方法： 阿里云服务器黑洞问与答 关于阿里云黑洞策略你肯定有很多疑问，啥是黑洞？阿里云服务器进入黑洞怎么办？阿里云黑洞如何解封？ 什么是黑洞？ 黑洞可以理解为将服务器切断外网，当服务器遭受超出防御范围的大流量攻击时，阿里云对其采用黑洞策略（即屏蔽该服务器的外网访问），避免对阿里云网络中其他用户造成影响，保障阿里云网络整体的可用性和稳定性。 阿里云黑洞多少时间？ 阿里云服务器进入黑洞后，多长时间可以解封放出来？默认的黑洞时长是2.5小时，实际黑洞时长视攻击情况而定，从30分钟到24小时不等。黑洞时长主要受以下因素影响： 攻击是否持续。如果攻击一直持续，可能重新触发黑洞机制，黑洞时间将会延长。 攻击是否频繁。如果某用户是首次被攻击，黑洞时间会自动缩短；反之，频繁被攻击的用户被持续攻击的概率较大，黑洞时间会自动延长。 阿里云服务器进入黑洞后怎么办？ 阿里云服务器进入黑洞后怎么办？可以通过购买DDoS原生防护企业版或DDoS高防新BGP产品来解除黑洞，不花钱可以解除黑洞吗？不购买阿里云DDoS防护产品只能等待系统自动解封。 黑洞阈值多少？ 当阿里云服务器遭受多少流量攻击会被丢进黑洞？阿里云黑洞策略阈值是多少？阿里云免费为云服务器等产品提供免费基础防护，云服务器吧以ECS云服务器为例，云服务器地域不同、ECS实例规格不同，黑洞阈值也不同，一般为5G免费防护，可以参考：DDoS基础防护黑洞阈值 云服务器ECS地址：阿里云·云小站
-
发表了文章 2020-10-04
阿里云服务器4核8G支持多少在线用户并发访问？
阿里云服务器4核8G配置可以容纳多少人同时在线访问呢？阿里云10M带宽支持多少并发数？阿里云4核8G服务器配置如何选择？阿里云服务器10M带宽费用多少？笔者来详细说下： 阿里云4核8G服务器10M带宽并发数计算 阿里云服务器4核8G10M带宽要分开来看，首先阿里云4核8G服务器配置可选的ECS实例规格有很多，ECS实例规格不同服务器性能参数也不同，然后笔者再来说说阿里云10M带宽并发数计算： 阿里云4核8G服务器 阿里云服务器4核8G配置可选ECS实例规格有共享型s6实例、计算型c6、突发性能t5等实例规格，计算型c6是企业级独享型云服务器，共享型s6实例是共享型实例，突发性能t5实例是限制CPU性能基线的规格，同样是4核8G的服务器配置，ECS实例规格不同性能也不同，详细可以参考官方文档：ECS实例规格性能详解 - 阿里云 笔者来总结一下，一般不建议选择突发性能t5实例，t5实例不适用于长时间超过性能“基线”或企业稳定计算性能需求场景；共享型s6实例是不限制CPU性能的，但是阿里云共享型云服务器的每个vCPU会被随机分配到任何空闲CPU超线程上，不同实例vCPU会争抢物理CPU资源，并导致高负载时计算性能波动不稳定，有可用性SLA保证，但无性能SLA保证；计算型c6实例属于独享型云服务器，在负载时不会出现资源争夺线现象，计算性能更加稳定。 阿里云服务器共享型和独享型 综上，笔者认为ECS共享标准型s6性价比超高，如果对云服务器计算性能要求较高可以选择计算型c6实例。 阿里云服务器10M带宽并发数计算 阿里云服务器10M公网带宽下载速度不是10M/S，即1280KB/秒。 那么，阿里云10M带宽云服务器支持多少人同时在线访问呢？10M带宽下载速度为1280KB/S，笔者以Web网站应用为例，将设网页优化后的大小为30KB，根据带宽计算1秒钟并发数公式：1秒并发连接数 = 服务器租用带宽下载速度/网页大小，那么10M带宽云服务器支持在1秒内42个人同时打开网页（1280/30大约是42），所以云服务器10M带宽能够支撑42个并发在1秒内同时打开。 注意：本文所计算的并发数是忽略了服务器计算和处理的时间，本文只考虑到网页在10M带宽的下载速度。另外，这种计算并发数的方法是很极端的，别小看42个并发数，实际上能够支撑的人数要比这个多。假设时间延长一下，网页有个8秒原则（网页超过8秒打不开，用户可能会停止访问），8秒钟打开的话可以支持336个并发，当然现在网络速度越来越快，8秒打开真的有些慢了。 最后，笔者告诉大家关于阿里云服务器带宽值选择不必太过纠结，阿里云服务器带宽支持按需升降配，不够用再升级，支付差价即可。 从省钱的来讲，阿里云服务器带宽的选择有个5M分割点，以阿里云华北2（北京）地域为例，阿里云5M及5M以下带宽价格为23元/Mbps/月，当带宽达到6M及6M以上时，带宽价格上涨到80元/Mbps/月，所以笔者一般建议用户在应用允许的情况下选择5M带宽，可以结合阿里云CDN、OSS等低成本存储来均衡带宽成本。 最后，关于阿里云服务器购买，笔者建议用户可以直接购买阿里云服务器秒杀优惠活动上的标配机型，比如：阿里云·云小站服务器秒杀特惠中，云服务器折扣低至1折，选一个相近的服务器配置，然后使用阿里云ECS云服务器控制台的“升降配”功能来调整到实际所需配置，这样购买可以更省钱。 云服务器ECS地址：阿里云·云小站
-
发表了文章 2020-10-04
阿里云/腾讯云/UCloud/华为云服务器主机对比测试报告
在2020年初之际，国内专业的云资源选型服务平台CloudBest旗下监测实验室，针对业界4家主流的云服务提供商，包括阿里云、腾讯云、UCloud与华为云进行了横向评测。本次测试在尽量保证测试环境相同的情况下，提供客观公正的测试数据，从技术层面对云服务提供商提供的云主机产品进行性能(CPU、磁盘、网络等)与性价比评测。以下为CloudBest监测实验室详细测试报告： 测试方法 云主机性能共进行3次测试，其中所有的云主机均为新购主机，每完成一次测试空跑8小时以上再进行下一次测试，最终取3次测试的平均值。 内网网络测试共进行3次测试，通过使用UDP协议+小包，使用6台辅助机和1台测试机，总计发包数3000万，统计测试机每秒收包数量，最终取3次测试的平均值。 CPU、磁盘的测试方式类似，详细方法见具体章节（四、测试报告摘要），此外还做了场景测试如Nginx等。 图1：云主机测试明细 选型说明 本次选型选取的是云主机主流配置中的8核16G，所有云主机都是记录的官网实时购买价格，除腾讯云价格默认是8.7折外，其余厂商没有任何活动和代金券等优惠政策。计费方式均选取按月计费原则，且所有云主机均含1M带宽和存储费用。 图2：云主机配置及价格概况 综合测试结果 综合此次测试结果，四家云厂商在8核16G云主机配置下，在性价比排行上，UCloud占据此次评测第一位。华为云、阿里云和腾讯云差距不大，依次位列第二、第三、第四位。 指标说明： 性价比=性能得分/单价，得出数据越大，性价比越高 图3：云主机性价比排行（由高到低排列） 测试报告摘要 01 性价比测试：性能得分 图4：云主机平均性能得分（由高到低排列） 由上图，在8核16G的配置下，通过Unixbench工具测试得出，UCloud云主机性能得分最高为6529，具有明显优势。华为云紧随其后，得分为6131.7。阿里云和腾讯云相对优势不明显。 02 价格 图5：云主机单价对比（价格由低到高排列） 由上图我们可以看出，UCloud在8核16G配置的云主机下，价格最低，这也与其突出的性价比表现相呼应；阿里云、华为云及腾讯云三家云厂商的云主机单价价格比较接近，但相对来说，阿里云对比华为云和腾讯云，价格略低一些。 03 CPU性能 图6：CPU运算平均耗时（由长到短排列） 由上图我们可以看出，在相同测试场景下，阿里云，华为云，腾讯云，UCloud的CPU运算耗时均在18秒左右，相差不大。UCloud相比于第二位的腾讯云，减少了0.17秒的运算时间。阿里云耗时较长，比第一位的UCloud多了0.8秒的耗时。 指标说明： 使用bc命令进行浮点运算，小数点后的位数为5000，测试耗时越短，表现越好。 04 磁盘性能 图7：队列深度1*1的随机读写 图8：队列深度1*1的平均时延 图9：磁盘随机读写于队列深度1*1详细数据表 图10：队列深度7*16的随机读写 图11：队列深度7*16的平均时延 图12：磁盘随机读写于队列深度7*16详细数据表 由队列深度分别为11和716的两组数据图表，我们可以看出，UCloud在磁盘的随机读写测试中，表现都非常好，数据远超其他3家云厂商。 在队列深度为1*1时，在随机读上，华为云和阿里云的iops和时延差距较小，位列二、三位。在随机写上，华为云和腾讯云的iops和时延数据表现都不理想，都有很大的提升空间。 在队列深度为7*16时，在随机读写上，阿里云和腾讯云的iops和时延都处于劣势，华为云和腾讯云的平均时延相差不大，但总体来说，三家厂商在磁盘随机读写的性能上都有提升空间。 指标说明： 在硬盘上随机位置读写数据，数据记录大小为4KB，在队列深度分别为11和716的条件下，进行IO基准性能测试得出的数据。IOPS越高，性能越好；时延越低，性能越好。 05 内网质量 图13：内网平均每秒收包数（由多到少排列） 在内网的质量测试上，四家厂商差距较大。UCloud每秒接收到小包的数量为接近400万个，位列第一位。阿里云每秒接收到小包的数量仅为80万左右，测试结果相对不理想，与UCloud、腾讯云、华为云对比差距比较大。 指标说明： 使用UDP协议+小包，使用6台辅助机和1台测试机，总计发3000万个包，小包大小为1byte，同等情况下，统计测试机每秒收到包的数量。接收小包的数量越多，内网质量越好。 06 特定场景测试（Nginx测试） 图14：Nginx测试每秒处理请求数（由多到少排列） 图15：Nginx测试详细数据表 Nginx是一个高性能的HTTP和反向代理web服务器，是网站门户用户的首选。Nginx具有并发能力非常强的特点，因此对运营主机的网络能力要求非常高。 由上图我们可以看出，UCloud、华为云以及阿里云的云主机表现都很好，其中UCloud表现最佳。 指标说明： 在虚拟机上安装Nginx 1.16.1版本，使用ab压测工具进行测试。总请求数为200万,一次并发请求个数为500，得出测试结果。每秒请求数越大，表现越好。单请求耗时与测试耗时越少，表现越好。 07 特定场景测试（MySQL测试） 图16：MySQL QPS对比（由多到少排列） 图17：MySQL TPS对比（由多到少排列） 图18：MySQL测试详细数据表 MySQL是一种开放源代码的关系型数据库，因为其速度、可靠性和适应性而被大众所应用于自身业务中。因而对MySQL的支持能力，也是目前云主机表现是否良好的一个重要体现。 由上图我们可以看出，UCloud和阿里云在每秒请求数和每秒事务数的指标上都表现不错，位居第一、第二位。而华为云和腾讯云在此项测试结果中，不占优势。 指标说明： 使用sysbench基准测试工具对数据库进行性能测试。在一个表中存放2000万条数据，同时开启500个线程，时间不限制，得出数据结果。每秒请求数与每秒事务数越大，表现越好。测试耗时与平均时延越小，表现越好。 08 特定场景测试（ClickHouse测试） 图19：ClickHouse测试耗时（由长到短排列） ClickHouse是一个用于联机分析处理（OLAP）的列式数据库管理系统，会使用服务器上一切可用的资源，从而以最自然的方式并行处理大型查询。因此ClickHouse目前已经被很多用户应用于大数据分析处理业务上。因而对ClickHouse的支持能力，同样是云主机表现是否良好的一个重要体现。 由上图我们可以看出，UCloud耗时最短，位居第一。腾讯云比UCloud耗时长，但是却优于华为云和阿里云，因此位居第二位。华为云和阿里云耗时相近，分别位居第三、第四位。 指标说明： 安装单机版本ClickHouse19，在ClickHouse上做数据分组查询，测试数据集：ontime，16G，183.95 million rows，取前10条数据，耗时越短，表现越好。 测试报告小结 本次测试报告主要针对8核16G配置下，阿里云、腾讯云、UCloud以及华为云的对比分析。无论是在性价比，还是在CPU性能、磁盘性能、内网质量上，都各有优劣（详见“四、测试报告摘要”），但是总体来说，UCloud云主机在此次测试中，各项测试结果都表现非常好，用户在选型时，可综合考虑以上测试结果及详细数据，并结合采购需求进行选型决策。 云服务器ECS地址：阿里云·云小站
-
发表了文章 2020-10-04
阿里云服务器租用价格表（2020年最新版）
阿里云服务器价格收费标准是多少？很多企业与站长想一览阿里云服务器价格，便于清晰了解前期项目开支预算，因此，笔者呕心沥血整理出阿里云服务器价格表，因不同地域宽带价格有所差异，所以不同地域节点的云服务器价格也有所不同。具体精准收费标准需参考：阿里云官网价格计算器。附赠：2000元折扣券领取 阿里云服务器配置分为入门级配置和企业级配置，云服务器的配置计费方式可以按量（小时）计费、按月计费或者年付等计费方式，本文中的价格表是以非Windows、专有网络、支持I/O优化为例： 1、入门级规格配置价格表 实例规格 vCPU 内存(GB) 按量(小时) 标准目录月价 优惠月价 年付月价 3年付月价 5年付月价 突发性能型 (t5) ecs.t5-c1m1.large 2 2 0.22 62 58.9 46.5 27.9 18.6 突发性能型 (t5) ecs.t5-c1m1.xlarge 4 4 0.43 125 118.75 93.75 56.25 37.5 突发性能型 (t5) ecs.t5-c1m1.2xlarge 8 8 0.87 250 237.5 187.5 112.5 75 突发性能型 (t5) ecs.t5-c1m1.4xlarge 16 16 1.74 500 475 375 225 150 突发性能型 (t5) ecs.t5-c1m2.large 2 4 0.3 87 82.65 65.25 39.15 26.1 突发性能型 (t5) ecs.t5-c1m2.xlarge 4 8 0.6 173 164.35 129.75 77.85 51.9 突发性能型 (t5) ecs.t5-c1m2.2xlarge 8 16 1.2 347 329.65 260.25 156.15 104.1 突发性能型 (t5) ecs.t5-c1m2.4xlarge 16 32 2.41 693 658.35 519.75 311.85 207.9 突发性能型 (t5) ecs.t5-c1m4.large 2 8 0.47 135 128.25 101.25 60.75 40.5 突发性能型 (t5) ecs.t5-c1m4.xlarge 4 16 0.94 270 256.5 202.5 121.5 81 突发性能型 (t5) ecs.t5-c1m4.2xlarge 8 32 1.88 540 513 405 243 162 突发性能型 (t5) ecs.t5-lc2m1.nano 1 0.5 0.05 14 13.3 10.5 6.3 4.2 突发性能型 (t5) ecs.t5-lc1m1.small 1 1 0.06 18 17.1 13.5 8.1 5.4 突发性能型 (t5) ecs.t5-lc1m2.small 1 2 0.13 36 34.2 27 16.2 10.8 突发性能型 (t5) ecs.t5-lc1m2.large 2 4 0.25 72 68.4 54 32.4 21.6 突发性能型 (t5) ecs.t5-lc1m4.large 2 8 0.41 119 113.05 89.25 53.55 35.7 2、企业级规格配置价格表 实例规格 vCPU 内存(GB) 按量(小时) 标准目录月价 优惠月价 年付月价 3年付月价 5年付月价 通用型 (g5) ecs.g5.large 2 8 0.66 191 181.45 143.25 85.95 57.3 通用型 (g5) ecs.g5.xlarge 4 16 1.33 383 363.85 287.25 172.35 114.9 通用型 (g5) ecs.g5.2xlarge 8 32 2.66 765 726.75 573.75 344.25 229.5 通用型 (g5) ecs.g5.3xlarge 12 48 3.99 1148 1090.6 861 516.6 344.4 通用型 (g5) ecs.g5.4xlarge 16 64 5.31 1530 1453.5 1147.5 688.5 459 通用型 (g5) ecs.g5.6xlarge 24 96 7.97 2295 2180.25 1721.25 1032.75 688.5 通用型 (g5) ecs.g5.8xlarge 32 128 10.63 3060 2907 2295 1377 918 通用型 (g5) ecs.g5.16xlarge 64 256 21.25 6120 5814 4590 2754 1836 密集计算型 (ic5) ecs.ic5.large 2 2 0.44 128 128 108.8 70.4 48.64 密集计算型 (ic5) ecs.ic5.xlarge 4 4 0.89 255 255 216.75 140.25 96.9 密集计算型 (ic5) ecs.ic5.2xlarge 8 8 1.77 510 510 433.5 280.5 193.8 密集计算型 (ic5) ecs.ic5.3xlarge 12 12 2.66 765 765 650.25 420.75 290.7 密集计算型 (ic5) ecs.ic5.4xlarge 16 16 3.54 1020 1020 867 561 387.6 计算型 (c5) ecs.c5.large 2 4 0.47 134 134 113.9 73.7 49.58 计算型 (c5) ecs.c5.xlarge 4 8 0.93 269 269 228.65 147.95 99.53 计算型 (c5) ecs.c5.2xlarge 8 16 1.86 537 537 456.45 295.35 198.69 计算型 (c5) ecs.c5.3xlarge 12 24 2.8 806 806 685.1 443.3 298.22 计算型 (c5) ecs.c5.4xlarge 16 32 3.73 1074 1074 912.9 590.7 397.38 计算型 (c5) ecs.c5.6xlarge 24 48 5.59 1611 1611 1369.35 886.05 596.07 计算型 (c5) ecs.c5.8xlarge 32 64 7.46 2148 2148 1825.8 1181.4 794.76 计算型 (c5) ecs.c5.16xlarge 64 128 14.92 4296 4296 3651.6 2362.8 1589.52 内存型 (r5) ecs.r5.large 2 16 0.85 245 232.75 183.75 110.25 73.5 内存型 (r5) ecs.r5.xlarge 4 32 1.7 489 464.55 366.75 220.05 146.7 内存型 (r5) ecs.r5.2xlarge 8 64 3.4 978 929.1 733.5 440.1 293.4 内存型 (r5) ecs.r5.3xlarge 12 96 5.09 1467 1393.65 1100.25 660.15 440.1 内存型 (r5) ecs.r5.4xlarge 16 128 6.79 1956 1858.2 1467 880.2 586.8 内存型 (r5) ecs.r5.6xlarge 24 192 10.19 2934 2787.3 2200.5 1320.3 880.2 内存型 (r5) ecs.r5.8xlarge 32 256 13.58 3912 3716.4 2934 1760.4 1173.6 内存型 (r5) ecs.r5.16xlarge 64 512 27.17 7824 7432.8 5868 3520.8 2347.2 高主频型超级计算集群 (scch5) ecs.scch5.16xlarge 64 192 31.77 9150 8692.5 6862.5 4117.5 2745 计算网络增强型 (sn1ne) ecs.sn1ne.large 2 4 0.51 148 148 125.8 81.4 56.24 计算网络增强型 (sn1ne) ecs.sn1ne.xlarge 4 8 1.03 296 296 251.6 162.8 112.48 计算网络增强型 (sn1ne) ecs.sn1ne.2xlarge 8 16 2.05 591 591 502.35 325.05 224.58 计算网络增强型 (sn1ne) ecs.sn1ne.3xlarge 12 24 3.08 887 887 753.95 487.85 337.06 计算网络增强型 (sn1ne) ecs.sn1ne.4xlarge 16 32 4.1 1182 1182 1004.7 650.1 449.16 计算网络增强型 (sn1ne) ecs.sn1ne.6xlarge 24 48 6.16 1773 1773 1507.05 975.15 673.74 计算网络增强型 (sn1ne) ecs.sn1ne.8xlarge 32 64 8.21 2364 2364 2009.4 1300.2 898.32 通用网络增强型 (sn2ne) ecs.sn2ne.large 2 8 0.75 215 204.25 161.25 96.75 64.5 通用网络增强型 (sn2ne) ecs.sn2ne.xlarge 4 16 1.49 429 407.55 321.75 193.05 128.7 通用网络增强型 (sn2ne) ecs.sn2ne.2xlarge 8 32 2.98 858 815.1 643.5 386.1 257.4 通用网络增强型 (sn2ne) ecs.sn2ne.3xlarge 12 48 4.47 1287 1222.65 965.25 579.15 386.1 通用网络增强型 (sn2ne) ecs.sn2ne.4xlarge 16 64 5.96 1716 1630.2 1287 772.2 514.8 通用网络增强型 (sn2ne) ecs.sn2ne.6xlarge 24 96 8.94 2574 2445.3 1930.5 1158.3 772.2 通用网络增强型 (sn2ne) ecs.sn2ne.8xlarge 32 128 11.92 3432 3260.4 2574 1544.4 1029.6 通用网络增强型 (sn2ne) ecs.sn2ne.14xlarge 56 224 20.85 6006 5705.7 4504.5 2702.7 1801.8 内存型 (se1) ecs.se1.large 2 16 1.14 329.4 329.4 279.99 164.7 164.7 内存型 (se1) ecs.se1.xlarge 4 32 2.29 658.8 658.8 559.98 329.4 329.4 内存型 (se1) ecs.se1.2xlarge 8 64 4.58 1317.6 1317.6 1119.96 658.8 658.8 内存型 (se1) ecs.se1.4xlarge 16 128 9.15 2635.2 2635.2 2239.92 1317.6 1317.6 本地SSD型 (i1) ecs.i1.xlarge 4 16 2.03 584.1 554.89 438.07 262.85 175.23 本地SSD型 (i1) ecs.i1.2xlarge 8 32 4.06 1168.2 1109.79 876.15 525.69 350.46 本地SSD型 (i1) ecs.i1.3xlarge 12 48 6.76 1947 1849.65 1460.25 876.15 584.1 本地SSD型 (i1) ecs.i1.4xlarge 16 64 8.11 2336.4 2219.58 1752.3 1051.38 700.92 本地SSD型 (i1) ecs.i1-c5d1.4xlarge 16 64 10.52 3028.9 2877.46 2271.67 1363 908.67 本地SSD型 (i1) ecs.i1.8xlarge 32 128 16.23 4672.8 4439.16 3504.6 2102.76 1401.84 本地SSD型 (i1) ecs.i1-c10d1.8xlarge 32 128 17.67 5088.1 4833.7 3816.07 2289.64 1526.43 本地SSD型 (i1) ecs.i1.14xlarge 56 224 28.39 8177.4 7768.53 6133.05 3679.83 2453.22 本地SSD型 (i2) ecs.i2.xlarge 4 32 2.61 753 715.35 564.75 338.85 225.9 本地SSD型 (i2) ecs.i2.2xlarge 8 64 5.23 1506 1430.7 1129.5 677.7 451.8 本地SSD型 (i2) ecs.i2.4xlarge 16 128 10.46 3012 2861.4 2259 1355.4 903.6 本地SSD型 (i2) ecs.i2.8xlarge 32 256 20.92 6024 5722.8 4518 2710.8 1807.2 本地SSD型 (i2) ecs.i2.16xlarge 64 512 41.83 12048 11445.6 9036 5421.6 3614.4 大数据型 (d1) ecs.d1.2xlarge 8 32 5.73 1649.7 1567.21 1237.27 742.37 494.91 大数据型 (d1) ecs.d1.4xlarge 16 64 11.46 3299.4 3134.43 2474.55 1484.73 989.82 大数据型 (d1) ecs.d1.6xlarge 24 96 17.18 4949.1 4701.64 3711.83 2227.09 1484.73 大数据型 (d1) ecs.d1.8xlarge 32 128 22.91 6598.8 6268.86 4949.1 2969.46 1979.64 大数据型 (d1) ecs.d1.14xlarge 56 224 40.1 11547.9 10970.5 8660.93 5196.56 3464.37 大数据网络增强型 (d1ne) ecs.d1ne.2xlarge 8 32 5.01 1444 1371.8 1083 649.8 433.2 大数据网络增强型 (d1ne) ecs.d1ne.4xlarge 16 64 10.03 2888 2743.6 2166 1299.6 866.4 大数据网络增强型 (d1ne) ecs.d1ne.6xlarge 24 96 15.04 4331 4114.45 3248.25 1948.95 1299.3 大数据网络增强型 (d1ne) ecs.d1ne.8xlarge 32 128 20.05 5775 5486.25 4331.25 2598.75 1732.5 大数据网络增强型 (d1ne) ecs.d1ne.14xlarge 56 224 35.09 10106 9600.7 7579.5 4547.7 3031.8 大数据网络增强型 (d1ne) ecs.d1ne-c8d3.8xlarge 32 128 19.25 5543 5265.85 4157.25 2494.35 1662.9 大数据网络增强型 (d1ne) ecs.d1ne-c14d3.14xlarge 56 224 29.19 8407 7986.65 6305.25 3783.15 2522.1 GPU计算型 (gn6v) ecs.gn6v-c8g1.2xlarge 8 32 19.84 5715 5715 4857.75 3143.25 2171.7 GPU计算型 (gn6v) ecs.gn6v-c8g1.8xlarge 32 128 79.36 22860 22860 19431 12573 8686.8 GPU计算型 (gn6v) ecs.gn6v-c8g1.16xlarge 64 256 158.72 45720 45720 38862 25146 17373.6 GPU计算型 (gn6v) ecs.gn6v-c10g1.20xlarge 96 384 197.67 56929.5 56929.5 48390.08 31311.23 21633.21 GPU计算型 (gn5) ecs.gn5-c8g1.2xlarge 8 60 13.85 3989.7 3989.7 3391.25 2074.64 1396.39 GPU计算型 (gn5) ecs.gn5-c8g1.4xlarge 16 120 27.71 7979.4 7979.4 6782.49 4149.29 2792.79 GPU计算型 (gn5) ecs.gn5-c8g1.8xlarge 32 240 55.41 15957.9 15957.9 13564.21 8298.11 5585.27 GPU计算型 (gn5) ecs.gn5-c8g1.14xlarge 54 480 110.82 31915.8 31915.8 27128.43 16596.22 11170.53 GPU计算型 (gn5i) ecs.gn5i-c2g1.large 2 8 6.51 1875 1781.25 1406.25 843.75 562.5 GPU计算型 (gn5i) ecs.gn5i-c4g1.xlarge 4 16 7.27 2093 1988.35 1569.75 941.85 627.9 GPU计算型 (gn5i) ecs.gn5i-c8g1.2xlarge 8 32 8.75 2520 2394 1890 1134 756 GPU计算型 (gn5i) ecs.gn5i-c16g1.4xlarge 16 64 11.72 3375 3206.25 2531.25 1518.75 1012.5 GPU计算型 (gn5i) ecs.gn5i-c28g1.14xlarge 56 224 32.29 9300 8835 6975 4185 2790 FPGA计算型 (f3) ecs.f3-c16f1.4xlarge 16 64 17.5 5040 5040 4284 2772 1915.2 FPGA计算型 (f3) ecs.f3-c16f1.8xlarge 32 128 35 10080 10080 8568 5544 3830.4 FPGA计算型 (f3) ecs.f3-c16f1.16xlarge 64 256 70 20160 20160 17136 11088 7660.8 高主频计算型 (hfc5) ecs.hfc5.large 2 4 0.65 188 188 156.04 94 62.04 高主频计算型 (hfc5) ecs.hfc5.xlarge 4 8 1.31 377 377 312.91 188.5 124.41 高主频计算型 (hfc5) ecs.hfc5.2xlarge 8 16 2.61 753 753 624.99 376.5 248.49 高主频计算型 (hfc5) ecs.hfc5.3xlarge 12 24 3.92 1130 1130 937.9 565 372.9 高主频计算型 (hfc5) ecs.hfc5.4xlarge 16 32 5.23 1506 1506 1249.98 753 496.98 高主频计算型 (hfc5) ecs.hfc5.6xlarge 24 48 7.84 2259 2259 1874.97 1129.5 745.47 高主频计算型 (hfc5) ecs.hfc5.8xlarge 32 64 10.46 3012 3012 2499.96 1506 993.96 高主频通用型 (hfg5) ecs.hfg5.large 2 8 0.86 249 249 201.69 122.01 79.68 高主频通用型 (hfg5) ecs.hfg5.xlarge 4 16 1.73 498 498 403.38 244.02 159.36 高主频通用型 (hfg5) ecs.hfg5.2xlarge 8 32 3.46 996 996 806.76 488.04 318.72 高主频通用型 (hfg5) ecs.hfg5.3xlarge 12 48 5.19 1494 1494 1210.14 732.06 478.08 高主频通用型 (hfg5) ecs.hfg5.4xlarge 16 64 6.92 1992 1992 1613.52 976.08 637.44 高主频通用型 (hfg5) ecs.hfg5.6xlarge 24 96 10.38 2988 2988 2420.28 1464.12 956.16 高主频通用型 (hfg5) ecs.hfg5.8xlarge 32 128 13.83 3984 3984 3227.04 1952.16 1274.88 高主频通用型 (hfg5) ecs.hfg5.14xlarge 56 160 22.94 6606 6606 5350.86 3236.94 2113.92 磁盘价格表 ESSD磁盘价格 云盘规格 性能上限 容量范围 按量价格 包月价格 PL1 Max IOPS=5万; Max Throughput=350MB 20GiB ~ 32768GiB 0.0021 元/1GB/小时 1.0 元/1GB/月 PL2 Max IOPS=10万; Max Throughput=750MB 461GiB ~ 32768GiB 0.0042 元/1GB/小时 2.0 元/1GB/月 PL3 Max IOPS=100万; Max Throughput=4000MB 1261GiB ~ 32768GiB 0.0084 元/1GB/小时 4.0 元/1GB/月 系统盘价格 计费项 类型 规格 按量价格 包月价格 系统盘（40 GB起售价） 普通云盘 40GB 0.014 元/40GB/小时 9.6 元/40GB/月 系统盘（40 GB起售价） 高效云盘 40GB 0.015 元/40GB/小时 11.2 元/40GB/月 系统盘（40 GB起售价） SSD云盘 40GB 0.045 元/40GB/小时 32.0 元/40GB/月 系统盘（40 GB起售价） 本地盘 40GB 0.017 元/40GB/小时 12.0 元/40GB/月 系统盘（40 GB起售价） 本地SSD盘 40GB 0.132 元/40GB/小时 32.0 元/40GB/月 系统盘（线性计费） 普通云盘 1GB 0.00034 元/1GB/小时 0.24 元/1GB/月 系统盘（线性计费） 高效云盘 1GB 0.00038 元/1GB/小时 0.28 元/1GB/月 系统盘（线性计费） SSD云盘 1GB 0.00112 元/1GB/小时 0.8 元/1GB/月 系统盘（线性计费） 本地盘 1GB 0.00042 元/1GB/小时 0.3 元/1GB/月 系统盘（线性计费） 本地SSD盘 1GB 0.0033 元/1GB/小时 0.8 元/1GB/月 数据盘（线性计费） 普通云盘 1GB 0.00034 元/1GB/小时 0.24 元/1GB/月 数据盘（线性计费） 高效云盘 1GB 0.00038 元/1GB/小时 0.28 元/1GB/月 数据盘（线性计费） SSD云盘 1GB 0.00112 元/1GB/小时 0.8 元/1GB/月 数据盘（线性计费） 本地盘 1GB 0.00042 元/1GB/小时 0.3 元/1GB/月 数据盘（线性计费） 本地SSD盘 1GB 0.0033 元/1GB/小时 0.8 元/1GB/月 网络带宽价格表 注意：地域节点不同价格也会有所差异，以下宽带价格是以华北3为例。 计费方式 规格 价格 计费方式 包年包月实例，固定带宽阶梯计费 1Mbps 23.0 元/1Mbps/月 包年包月实例，固定带宽阶梯计费 包年包月实例，固定带宽阶梯计费 2Mbps 46.0 元/2Mbps/月 包年包月实例，固定带宽阶梯计费 包年包月实例，固定带宽阶梯计费 3Mbps 71.0 元/3Mbps/月 包年包月实例，固定带宽阶梯计费 包年包月实例，固定带宽阶梯计费 4Mbps 96.0 元/4Mbps/月 包年包月实例，固定带宽阶梯计费 包年包月实例，固定带宽阶梯计费 5Mbps 125.0 元/5Mbps/月 包年包月实例，固定带宽阶梯计费 包年包月实例，固定带宽阶梯计费 6Mbps及以上, 每Mbps费用 80.0 元/Mbps/月 包年包月实例，固定带宽阶梯计费 按量计费实例，固定带宽阶梯计费 1－5 Mbps 0.062 元/Mbps/小时 按量计费实例，固定带宽阶梯计费 按量计费实例，固定带宽阶梯计费 6Mbps及以上, 每Mbps费用 0.252 元/Mbps/小时 按量计费实例，固定带宽阶梯计费 按使用量线性计费 1GB 0.8 元/GB 按使用量线性计费 云服务器ECS地址：阿里云·云小站
-
发表了文章 2020-10-04
史上最详细阿里云服务器搭建网站流程（图文教程）
新手如何用阿里云服务器Linux系统安装宝塔面板搭建WordPress博客网站呢？WordPress作为全球实用最广泛的CMS系统，以功能强大、扩展性强，插件众多，易扩充功能等特点，受到全球站长开发者青睐。而阿里云作为国内用户量最多的云服务器商，因此，本文以阿里云为例，详细介绍云服务器Linux系统如何安装宝塔面板搭建WordPress博客网站。 一、注册域名 如何注册域名我就不赘述了，直接通过万网选购域名即可。 二、购买云服务器 1、个人云服务器 目前新用户购买阿里云服务器还算便宜，s6实例1核2G1M配置1年69元-3年229元。该实例配置特别适合个人博客网站搭建使用。如下图： 但值得注意的是，阿里云官方向来只对新用户开放优惠特权，所以在续费的时候会特别昂贵，例如：（s6实例1核2G1M配置首购仅69元，但1年后续费需几百块左右）。因此，星速云小编建议大家在购买的时候尽量一次性购买三年，为续费的时候节省开支。 云小站-云服务器1核2G1M配置1年69元 2、企业云服务器 阿里云服务器根据个人与企业用户推出不同应用场景的实例，因此，如是企业用户可以选择对应的企业级实例。具体参考：企业如何选择阿里云服务器配置机型 企业建议选择云服务器ECS计算型c5实例，2核4G3M配置3年仅2287元，4核8G6M配置3年仅3551元，适用于计算密集型等通用场景。 阿里云服务器c5实例2核4G3M配置3年2287元 三、解析域名 1、域名解析 进入阿里云控制台>>域名解析>>域名管理。添加两条记录值，一个是www，一个是@（记录值为云服务器实例IP） 再添加一个@ 2、开放实例端口 ECS 实例常用端口说明： 一般我们需要开通的常用端口：21（FTP端口）、80（HTTP协议端口）、3306（MySQL端口）、8888（宝塔后台端口），如网站要实现HTTPS协议需开放443端口，如下图： 安全组端口配置方法，如下图： 四、搭建环境 1、安装宝塔面板 首先-停止实例>>磁盘和镜像>>更换操作系统 从镜像市场选择宝塔面板。 选择宝塔控制面板。 2、登录宝塔后台 输入网址 http://实例IP:8888，进入宝塔后台，设置登录账号和密码。 3、安装运行环境 使用WordPress建站，一般我们需要安装五个运行环境Nginx+MySQL+PHP+PureFTPd+phpMyAdmin。 MySQL版本建议选择5.5版本以上 PHP版本建议选择7.0左右。 4、添加站点 5、上传WordPress程序 下载WordPress官网程序，并上传到网站根目录。 上传成功后，解压程序包，并将文件下的所有文件复制粘贴至根目录。如下图： 6、登录WordPress后台 输入WordPress后台默认登录地址，http://你的域名/wp-admin 并按照指示正确输入数据库帐号，数据库的数据库名、用户名、密码在宝塔后台查看，完成操作后，即可进入WordPress后台。 7、配置伪静态 部署好网站，要配置伪静态，不然无法访问文章详情页。 进入宝塔后台>>网站>>设置>>伪静态>>选择WordPress>>保存 以上步骤为使用阿里云服务器Linux系统安装宝塔面板搭建WordPress博客网站全流程，不懂的朋友可在评论区留言。 云服务器ECS地址：阿里云·云小站
-
发表了文章 2020-10-03
Linux中如何统计某个字符串个数？
在 Linux 系统下，有时候，我们可能要对一个日志文件进行分析。比如，分析日志文件中某个单词或者某个特殊字符串出现了多少次。 对于匹配统计，一般用到正则方法，下面总结了几个统计字符串个数的方法。 方法一：使用 grep 命令 grep -o '字符串' file |wc -l 方法二：使用awk命令进行统计 awk -v RS="@#$j" '{print gsub(/字符串/,"&")}' file 方法三：另一种使用awk命令进行统计的方法 awk '{s+=gsub(/字符串/,"&")}END{print s}' file 备注：上面的 file 是要统计的文件名。上面的字符串换成你具体要统计的内容。 awk简介 awk是一个强大的文本分析工具，相对于grep的查找，sed的编辑，awk在其对数据分析并生成报告时，显得尤为强大。 简单来说awk就是把文件逐行的读入，以空格为默认分隔符将每行切片，切开的部分再进行各种分析处理。 实例 假设现在一个文件里面的内容如下： [root@ihh logs]# cat test.txt userid:121212userid:232323userid:3434username:3434username:4343 然后我要统计 userid 在 test.txt 文件里出现了多少次，那么根据上面提供的命令，可以这样操作： [root@ihh logs]# grep -o 'userid' test.txt |wc -l3 [root@ihh logs]# awk -v RS="@#$j" '{print gsub(/userid/,"&")}' test.txt 3 [root@ihh logs]# awk '{s+=gsub(/userid/,"&")}END{print s}' test.txt 3 云服务器ECS地址：阿里云·云小站
-
发表了文章 2020-10-03
5G风起，未来数据库将会如何发展？
导语： 在自己工作的领域中，发现快乐是我坚持做技术的动力。而技术域其实就是一个画圆的过程，当你发现你的圈圈画得越大，需要求知的东西也就越多。每天必须保持一种持续学习，和与技术死磕的精神才能促使我们不断前行。我们不断前行，时代也在不断变化和发展。本文由变化看发展，从移动通讯发展的历程同步透视数据库能力的变迁，进而预测5G时代将会给数据库带来的重大变革。 一、1G时代下的数据库：关系型数据库来满足基本需求 首先，从通信时代的总要变化谈起：从1G到5G，手机见证了人类通信的飞速发展。从军用到民用，从大哥大到智能机，总有一款手机能勾往日的回忆。 1938年，美国贝尔实验室为美国军方制成了世界上第一部“移动电话”，即无线便携式报话机，使用时必须有一人背负信号箱，光是信号箱就是二三十斤，1G所通信所使用的正是模拟技术。1973年摩托罗拉公司的马丁·库帕发明了世界上第一部民用手机，1983年正式推向市场。1993年大陆第一部手机摩托罗拉3200，被尊称为“大哥大”，宣告了我国正式进入1G时代，拥有一部“大哥大”是身份的象征，也是那个年代人们的梦想。 关系型数据库起源自1970年代，其最基本的功能无非就两个：一个是先把数据存下来，另外就是满足用户对数据的计算需求。数据是根基，如果连数据都完整的存不下来，或者保存不好，后续任何事情都无法进行展开，所以这点很重要。有了数据，用户就可以进行一些query操作了。 不管是聚合、连表还是分组，在数据库早期发展阶段都能满足需求，当时优秀的商业数据库产品主要是Oracle，DB2。 二、2G时代下的数据库：开源数据库产品初露锋芒 1G有着很多的缺陷，可能经常会出现串号、盗号等现象。1994年，就在我爸吵吵嚷嚷地要买“大哥大”的时候，A网和B网正式关闭，紧接着2G时代来临了。1995年，新的通讯技术成熟，国内也正式进入了2G通信时代，主宰1G时代的摩托罗拉走下神坛，取而代之的是垄断一时的诺基亚。在这之后的那些年，诺基亚带给我们了无数经典手机。我记得我当时用的是诺基亚7610。 当时，Berkeley DB、MySQL、PostgreSQL等数据库陆续发布，开源数据库产品初露锋芒。这些数据库不断提升单机实例性能，可以很好地支撑业务发展，应对各类业务的变化。拿目前独占开源数据库榜首的MySQL举例来说，它的数据库架构就很丰富。有基于主从架构的MHA，双主+Keepalived。 我们先来看下各个数据库的发布时间，然后简单介绍。 1.基于主从架构的MHA MHA的目的在于维持MySQL Replication中master库的高可用性，其最大特点是可以修复多个slave之间的差异日志，最终使所有slave保持数据一致，然后从中选择一个充当新的master，并将其他slave指向它。当master出现故障时，可以通过对比slave之间I/O thread 读取主库binlog的position号，选取最接近的slave作为备选主库（备胎）。其他的从库可以通过与备选主库对比生成差异的中继日志。在备选主库上应用从原来master保存的binlog，同时将备选主库提升为master。最后在其他slave上应用相应的差异中继日志并从新的master开始复制。 2.基于主从架构的双主+Keepalived 中小型规模的时候，采用这种架构是最省事的。 两个节点可以采用简单的一主一从模式，或者双主模式，并且放置于同一个VLAN中，在master节点发生故障后，利用keepalived/heartbeat的高可用机制实现快速切换到slave节点。 3.基于Galera协议的MySQL高可用集群架构 Galera产品是以Galera Cluster方式为MySQL提供高可用集群解决方案的。Galera Cluster就是集成了Galera插件的MySQL集群。Galera replication是Codership提供的MySQL数据同步方案，具有高可用性，方便扩展，并且可以实现多个MySQL节点间的数据同步复制与读写，可保障数据库的服务高可用及数据强一致性。 4.官方大力推进的InnoDB Cluster集群架构 MySQL官方在5.7.17版本正式推出组复制（MySQL Group Replication，简称MGR）。master1，master2，master3，所有成员独立完成各自的事务。当客户端先发起一个更新事务，该事务先在本地执行，执行完成之后就要发起对事务的提交操作了。在还没有真正提交之前需要将产生的复制写集广播出去，复制到其他成员。如果冲突检测成功，组内决定该事务可以提交，其他成员可以应用，否则就回滚。最终，这意味着所有组内成员以相同的顺序接收同一组事务。因此组内成员以相同的顺序应用相同的修改，保证组内数据强一致性。 三、3G时代下的数据库：非关系型数据库应对数据暴增 1.3G时代数据暴增 2G定义为文字通讯，从1G跨入2G则是从模拟调制进入数字调制，相比较而言，2G移动通讯具备高度的保密性，系统的容量也在增加。同时从这一刻的开始，手机也能上网了。虽然当时只能浏览一些文本或者互相传送txt文件等，但我们可以畅快淋漓地随时随地看小说了，带来的满足感还是有的。但日益增长的图片和视频传输的需要，使得人们对于数据传输速度的要求日趋高涨，2G时代的网速显然不能支撑满足这一需求。随之3G图片时代应运而生。互联网超强的热度席卷了全球，触屏手机出现，变得娱乐方式多样化，人们对移动网络的需求也在不断加大。 由于采用更宽的频带，传输的稳定性也大大提高。速度的大幅提升和稳定性的提高，使大数据的传送更为普遍，移动通讯有更多样化的应用。3G可以被视为开启行动通信新纪元的重要关键，于是看新闻、刷微博、下载图片、在线听音乐等等都渐渐成为人们的娱乐日常。 2009年3G时代到来，同年MongoDB发布，NoSQL这个名词也正式出现在我们的视野中。虽然传统的单机关系型数据库底层架构很丰富，但随着移动互联热度的风靡全球，数据量呈现爆发性增长，传统的关系型数据库越来越难以满足用户不同的需求。即便是最基本的数据能存下的问题，当时都不能保证了。 2.NoSQL数据库：应对数据暴增的变革性解决方案 数据暴增，难道就没有解决办法嘛？当然有的！ 针对关系型数据库存不下数据的问题，有两个核心解决点：第一，我们可以沿着单机关系型数据库的基础之上做一些Proxy；第二，把数据存储在多个集群中，然后查询时再把数据汇总在一起。但是我们发现有了Proxy之后，业务要考虑sharding key的使用问题，针对业务扩容上会很受限，跨库跨表的操作很难实现，跨库join和跨库一致性很难得到支持。具体来说就是前端会把所有的应用逻辑，嵌入到中间件中。那么把所有的业务逻辑，全部放到一个中间件里，一定会制约业务的吞吐量和弹性扩张的能力。具体如下图所示。 所以越来越多的企业或者互联网公司，开始采用微服务的技术了。把紧耦合到中间件中的应用，拆散到各个中间里面，来提供分布式的服务。微服务架构的核心都是一个可以弹性扩展不断伸缩的框架。比如业务中有登陆的子系统，财务的子系统。每一组子系统可以做成一组独立的服务。每一组独立的服务，我们上层可以使用容器技术，把应用逻辑写到一个个容器里面。当发现子系统压力过高或者计算能力不够的时候，我们只需要考虑增加容器，来提高应用的扩展能力和吞吐量。具体如下图所示。 我们回归到数据库本身，传统的关系型数据库既然应对数据暴增没有很好的解决办法，那我们就来看看通过底层非关系型的NoSQL。 我们考虑用利用更简单的存储模型，放弃SQL，放弃事务，来获取一个更容易实现的扩展系统。HBase是其中的典型代表。HBase是Hadoop生态中的重要产品，Google BigTable的开源实现。HBase本身并不存储数据，数据还是以文件的形式存储在HDFS上，重度依赖 HDFS，并不支持ACID跨行事务。 3.MongoDB：首个支持跨文档事务的NoSQL数据库 说到这里就不得不好好聊聊MongoDB了。MongoDB4.0开始支持跨文档事务，这就也意味着MongoDB是首个支持跨文档事务的NoSQL数据库，将文档模型的速度，灵活性和功能与ACID保证相结合。现在使用MongoDB解决各种用户案例变得更加容易。更值得一提的是从MongoDB4.2版本开始支持分布式事务了。原来在4.0版本中的事务存在最大修改 16MB、事务执行时间不能过长的限制都已经解决了。分布式事务的支持也意味用户修改分片key的内容成为可能，因为修改分片key的内容，可能会导致key要迁移到其他shard，而在4.2之前，无法保证这个迁移动作的原子性，而借助分布式事务，这个问题也就迎刃而解了。 MongoDB的复制级架构 三副本架构是最基础的复制集的架构，一主两备模式。主节点接受外界的读写请求，向备节点进行数据同步。当主节点宕掉，会自动切换到备节点，不影响线上业务，防止单点故障。 MongoDB的分片架构 分片是一种在多台机器上分配数据的方法。 MongoDB使用分片架构有助于您去管理非常大数量的数据集和高吞吐量操作的集群。 大数据量和高吞吐量的业务情况对单台服务器来讲是具备很大的挑战性的。例如，高查询率可能耗尽服务器的CPU容量。工作集大小超过系统内存，那么压力则会给到磁盘上，这对IO来讲不是我们所希望看到的。MongoDB支持通过分片进行水平缩放。 四、4G时代下的数据库：分布式+关系型的NewSQL 时间一晃到了2013年12月，工信部在其官网上宣布向中国移动、中国电信、中国联通颁发“LTE/第四代数字蜂窝移动通信业务(TD-LTE)”经营许可，也就是4G牌照。至此，移动互联网进入了一个新的时代，即4G视频时代。如今4G已经像 “水电”一样成为我们生活中不可缺少的基本资源。而且4G信号的覆盖范围也非常广泛，并且成为大多数人的标配，微信、微博、小视频等手机应用成为生活中的必须，经常看到很多人刷着抖音，快手。越来越多的人参与到拍小视频，当主播这个行业当中来。有句话“南抖音北快手，智障界的两泰斗”，流传比较广的，可见4G不仅开启了一个全民娱乐的时代，也引来了视频自媒体发展的红利时代。我们现在根本无法想象离开手机的生活会是什么样。 对于数据库的发展来说，我们之前也谈了关系型数据库的代表MySQL，非关系型数据库的代表MongoDB，接下来聊聊在4G时代的这个时间节点，NewSQL这个名词出现在了我们的视野里面。如果说NoSQL是一种变革，那么NewSQL就是进击的巨人。 记得三国演义开篇说到“论天下大势，分久必合合久必分”。我们本文聊聊“分久必合”。 NewSQL应是RDBMS中的数据模型（关系型、符合ACID）和NoSQL中的计算框架、分布式存储、开源特定的结合产物。 2012年底到2013年初，Google 相继发表了Spanner和F1两套系统的论文，让业界第一次看到了关系模型和NoSQL的扩展性在一个大规模生产系统上融合的可能性。 Google 的Spanner + F1，是第一个生产环境中大规模验证的 NewSQL 系统；Spanner 通过使用硬件设备（GPS时钟+原子钟）巧妙地解决时钟同步的问题——在分布式系统里，时钟正是最让人头痛的问题。Spanner的强大之处在于即使两个数据中心隔得非常远，也能保证通过TrueTime API获取的时间误差在一个很小的范围内（10ms），并且不需要通讯。Spanner的底层仍然基于分布式文件系统，不过论文里也说是可以未来优化的点。Google的内部的数据库存储业务，大多是3~5副本，重要的数据需要7副本，且这些副本遍布全球各大洲的数据中心，由于普遍使用了Paxos，延迟是可以缩短到一个可以接受的范围（写入延迟100ms以上），另外由Paxos带来的Auto-Failover能力，更是让整个集群即使数据中心瘫痪，业务层都是透明无感知的。F1是构建在Spanner之上，对外提供了SQL接口，F1是一个分布式MPP SQL层，其本身并不存储数据，而是将客户端的SQL翻译成对KV的操作，调用Spanner来完成请求。 NewSQL中的典型代表就是Google Spanner和国内的TiDB，巨杉等。 结合NewSQL数据库的特点，主要可以总结为新老技术的搭配。新技术中最基本的是扩展能力，包括存储和计算扩展；除了扩展能力，当然还有HTAP这种混合事务和分析场景，适应更多应用数据需求。老技术中主要就是高可用性，在一个比较大的分布式集群中，少量节点失效下，数据库依然能够提供服务，依然能够自我恢复，依然可用；事务ACID的支持，处理OLTP的能力；最后就是SQL完整支持，业务采用SQL来对存储进行交互。其特性如下图所示。 这里我们看看TiDB分布式数据库的样子，如下图所示。 整体架构介绍：TiKV+PD 形成了kv的带事务的存储引擎。 TiKV：主要存储数据，把数据一片一片存储在集群中。 PD：（集群管理者）存储Tikv中的元信息。每片数据所在位置和有哪些副本。PD还要负责对TiKV节点进行负载均衡调度和管理。 TiDB：无状态的计算层（随意扩展），支持MySQL协议和SQL请求和SQL优化。发送计算和获取数据的请求，通过MySQL协议返回给客户端。TiDB是存储引擎和业务端的桥梁枢纽。 六、5G风起，数据库将会如何发展？ 1.数据库发展总结 盘点数据库的发展历程，我们可以通过下面这幅图来完全体现出来（图片来源：https://db-engines.com/en/ranking 从上图中，我们了解到在最开始发展起来的是关系型数据库+SQL（代表数据库产品Oracle，MySQL），然后发展到了非关系型NoSQL（代表数据库产品MongoDB），最后是分布式+关系型的NewSQL（代表数据库产品TiDB）。 2.5G风起，数据库上云是必然趋势 然后再来说说5G，即第五代移动通信技术。国际电联将5G未来的应用场景划分为移动互联网和物联网两大类。凭借低延时、高可靠、低功耗以及飞一般的网速的特点，5G的应用范围更广泛远超4G、将渗透到生产生活的各个领域，不仅能使得超高清视频、浸入式游戏等交互方式实现再升级，还能实现海量的机器通信、支持智能家居、智能设备和智能城市，也将在车联网、移动医疗、工业互联网等垂直行业一展身手。简单来说，5G更快、更安全、信号更强、覆盖面积更广、发展方向更加多维。如果不出意外，5G手机明年将纷纷上市。同时，中国联通和中国电信都将于2020年实现重点城市的5G商用。这些都将带领人类开启一个万物互联、高度便捷化、自动化、智能化的崭新生活方式。 下面聊聊5G来了之后，未来数据库的发展是个什么样子呢？ 根据Gartner预测，到2022或者2023年，将有超过3/4的数据库被部署到或者迁移到云平台，不足5%的数据库会考虑部署到本地，这就意味着云将主导数据库未来的市场。 我们知道云计算是分层次的，即三种服务模式（IaaS，PaaS，SaaS）。数据库是一款服务软件也就是SaaS模式，整个数据的生命周期，数据库起到的作用都是至关重要的。而且还有一点，数据与应用必须紧密配合，而5G时代，大多数应用也要部署在云上，那云数据库这个趋势也就毋庸置疑了。 不过，在上云这个过程中，传统的数据库与云端数据库不一样的产品架构，给上云带来了很高的门槛。还有商业数据库其高成本，难维护的特点，必将接受国产、开源数据库他们其可弹性扩展，易用、开放等特点的各种冲击与挑战。很应景的一句话是”数据信息科技，国产自主可控，开源大势所趋“。 2.5G数据库应该具备能力 我们再来想一想对于5G时代的到来，该如何规划好数据库呢？换句话说，5G数据库应该具备什么样的能力呢？ 首先先从高吞吐量和低延迟的角度入手，5G的ITU IMT-2020 规范要求速度高达每秒 20 千兆位，目标延迟为1ms。这种要求才是打开数据流的金钥匙。其次，5G数据库必须拥有瞬间线性扩展能力，5G网络不仅会从5G启用的应用程序中生成大量的流数据，还会从网络、订阅、企业、网络运营商和呼叫处理中生成大量的流数据。 那么，对于目前传统的OLTP数据库来说，是否机器越多，SQL执行就越快呢？ 答案肯定是否定的。 对于OLTP数据库中的线性扩展，增加机器数，单SQL的响应时间基本不会发生太大变化。随着云计算技术不断成熟，云数据库开始逐渐崛起，企业正将新应用向云转移，对数据存储和计算分析的能力要求不断地加强。由云厂商主导的云原生数据库势必是这波改变的推动者，云原生数据库的优势在于它的成本、灵活度、安全、技术进化层面。5G数据库更需要在云中无缝工作，并且还要在容器化环境中进行操作。而5G必将带来数据的洪流，这也将推动企业数字化的转型。届时，传统数据库将肯定跟不上当前企业发展的脚步。5G将以前所未有的速度生成前所未见的巨大数据。 3.5G+AI助推数据库发展 科技界有两大领域越来越热：一个是5G，一个是AI。两者都是能够改变时代的颠覆性技术。单独看5G或AI技术，它们的发展都面临重重挑战，但是，当5G与AI这两大颠覆性技术深度融合的情况下，去看数据库的发展呢？ 5G、Al通讯与人工智能进入工业物联网、金融、空气预测等数据管理时，由需求推动的时序信息会使数据库变成实时，并且能即时生成预测结果。数据库如果实时可以用Al算法以后，并可生成实时的预报警系统，让大家把损失防范于未然。就如同下图所示，5G和AI共同助推数据库的发展。 市面上也有一些时序数据库，在未来5G时代，比如 RDDTool 和 Graphite 会自动删除高精度的数据，只保留低精度的。而这些“功能”对关系型数据库而言，简直是不可想象的。 4.未来数据库关键词 小结一下，未来数据库的发展，必然离不开下面这些词汇： 上云，数据洪流，开源，国产可控，低延迟，高吞吐，实时…… 而对于我们来说，就要更早地适应未来的变化，提升自己一专多能的技术域，找到做技术那份最简单的快乐足以。 云服务器ECS地址：阿里云·云小站
-
发表了文章 2020-10-03
公有云、私有云及混合云应用场景辨析
近几年我们经常能看到一些研究公司（Gartner朋友Alice Yang语，“我们是研究公司”）、咨询机构发布关于公有云、私有云以及混合云的市场趋势分析，种种“公有云是未来发展趋势”、“混合云是主流”等观点层出不穷。在此，笔者试图抛开趋势，仅从应用场景角度分析，试图阐述当前国内各类云的客户群体、供应商、服务和技术特点。 公有云： 笔者在以前的文章描绘过国内外公有云和私有云的构成比例，美国以公有云为主，国内以私有云为主（一些数字认为国内公有云略大于私有云，见仁见智吧）。观察以国外的AWS、国内的阿里云为代表的公有云，走过的都是一条类似的路——第一步先满足内部需求、第二步将多余的资源（计算能力）向外供应、最后以外部的IT能力供应为主。这种步骤实际上是允许内部试错、用内部需求支撑营收，同时练就相对过硬的技术、业务服务、运营和运维经验，目前比较成功。 从笔者观察到的情况来看，公有云的客户前百分之5-20%的大客户占了80%以上的营收，而群体数量上以中小型企业为主（SMB）。此类中小型企业具有小微、创新等特点，云相关的技术能力相对较弱、对于成本敏感，希望利用云计算快速构建业务的支撑环境，迅速发布和拓展业务。因此，公有云的服务供应相对标准化，通常同时具备IaaS（基本能力）、PaaS（以APaaS为主）和SaaS（基于IaaS封装行业应用、生态合作伙伴提供）各层次的服务。相对于私有云，通常公有云会更强调多租户、SLA、计费等特性，而虚拟化比会在一定程度上限制公有云提供商的成本。 公有云的供应商主要分为几类：三大运营商、ICT巨头、互联网巨头、IDC转型企业、特殊创新企业。 私有云： 目前国内私有云需求主要集中在金融、电信、政府、能源、教育、交通等行业。与公有云不同的是，私有云的客户主要是大中型企业。这些企业具有几大特点：有钱、有资源、有需求。有钱：上述相关行业中的大中型企业，具备充足的IT预算；有资源：此类企业在行业中所处位置使企业相对容易获取资源、人才；有需求：有国家政策推动、有创新扶持、有实际业务复杂度和性能弹性等需求、有安全类需求等。 私有云的服务通常会根据客户的特点体现较多的定制，如组织架构、内部审批流程、定制化的计算服务、统一资源管控、统一监控、自动化部署等。而在技术上，私有云往往会体现异构资源纳管（多种资源类型、多种虚拟化）、对接企业现有的4A、外部监控、ITSM、CMDB等系统。 私有云的供应商主要分为几类：传统ICT厂商、Openstack厂商、公有云厂商转做私有云。 混合云： 混合云目前并不是简单的“私有云+公有云”形态，在目前更多体现为“私有云+”，也即在构建完成私有云的基础上，借助公有云的能力形成混合云。混合云管理平台（CMP）会体现一些与私有云管理平台差异化的特征，如跨云的资源和服务编排、云费用分摊和成本优化等。 在此，插播一下广告，云星数据和RightScale合作为中国客户提供混合云管理平台RightCloud，：）。 如前文所述，混合云客户一般已经具备了私有云，希望通过对接公有云解决几方面的典型需求： 1. 跨国：某大型公司在美国销售电子类产品，需要在美国连接该企业的销售系统，通过本地私有云加AWS公有云实现； 2. 灾备：将一部分系统或者数据定期备份到公有云上； 3. 性能和高可用：利用公有云的CDN、全局负载均衡等能力提供更好可用性和性能； 4. 爆发：客户业务需要短时爆发（bursting），满足业务需求同时节省成本。 混合云供应商主要包含：公有云提供商提供混合云能力、私有云供应商提供混合云能力、混合云创新企业等。 匆匆二小时写就，兼之状态萎靡、才疏学浅，难免贻笑方家，有待能力提升再行完善。 云服务器ECS地址：阿里云·云小站
-
发表了文章 2020-10-03
企业级IaaS架构的深度解析
一、 关于云 1. 云产业分析 根据IDC的分析报告，美国和中国云计算产业发展差异巨大：美国以公有云为主，SaaS最大、IaaS最小；而中国截然相反，以私有云为主，IaaS占了大约50%的份额。 究其原因，跟中美两国云计算产业发展的阶段、成熟度有很大关系。 中国的公有云主要使用者是小微、创新企业等。我认为IaaS公有云已经或者将要巨头化，PaaS还有机会，SaaS会是云计算几大分类中的爆发点，但是要看准行业。 在诸多产业中，中国云计算私有云市场主要的客户来自：通讯、金融、政府。金融行业受安全、政策、法规的约束，几乎不会选择公有云，大型国有银行私有云的建设步骤也很谨慎、渐进式，会首先考虑迁移非核心应用；小金融相对对新技术比较开放，会实验一些开源的技术，如Openstack、ceph等。 政府由于“十二五”、“十三五”政策持续推动、对于政务云建设的现实需求、统一纳管基础设施资源、节省成本等考虑，对云计算的投入较大。 2. 国内有私有云需求的四类企业 a) 政策驱动 因为政策持续推动、创新补助、领导要求（政绩）等原因，需要上云的企事业单位、行政机关。 b) 人云亦云 不解释，：）。 c) 新技术跟进 看见新技术的发展、成熟，希望在其中分一杯羹，也包括IDC之类的转型企业。和上一类的区别一个是模糊的、被动的，一个是有自主想法、主动的。 d) 为业务而云 因为业务发展规模（含弹性）、统一上收资源、成本等考虑云。主要也分两类大型互联网企业和传统大型企业。 前者因为业务发展需要考虑云计算，从成本、技术可控性考虑，会采用大量的开源技术，同时会对硬件、软件提出改造要求，大力发展分布式、集群技术以适应其性能、可靠性等需求。典型的代表是阿里等。 而传统大型企业走的是另一条路，相对稳健，会选用成熟可靠的商业化解决方案为主，如虚拟化选择VMWare。另一方面，这类企业相对比较谨慎，会以规划咨询、POC、招标、建设、交付、运维相对固定的模式去建设云。典型的代表是大型央企。 3. IaaS、PaaS、SaaS分析 我把顺序放过来，先说SaaS，再说PaaS，IaaS。 SaaS我认为主要会在三种情况下出现： a) 行业SaaS 有行业属性的SaaS，如教育、医疗、培训等。 b) 工具化SaaS 比如workday类似的管理工具、office365类似的文档工具等。 c) 大型企业（组织机构）内部SaaS 有些企业内部，各地/部门业务类型相对一致，使用SaaS软件统一上收权限，节省成本等。 如我之前所说，如果找准行业、方向，SaaS可能是创业的大风口。 PaaS的实现我认为有两种： a) 基于商业化自动部署工具的 大型企业考虑人员技能、维护成本、可靠性等要求，较多选择类似方案。HP、IBM、BMC等都有类似的工具。自行实现的话，可以考虑流程引擎加上脚本执行器再加部署包。 b) 基于开源框架和软件的 选择cloudfundry、openshift框架，加docker等技术，目前随着相关技术的成熟，越来越受到关注。上述的几个大外企实际上也有类似的实现。 IaaS的情况比较复杂，我认为难度主要在理清几个头绪： a) 业务对于底层资源的要求、约束 联想的架构师团队正在做一件事情，就是梳理业界存在的十几种主要的企业业务架构（如电商、搜索等等），分析和总结它们对于资源的各方面要求，如计算能力、IO等等。 b) 服务的设计、编排 需要从业务的承载要求、客户消费方式、业务系统架构、部署方式、虚拟化方式、集群、资源类型做统一的规划设计。根据对客户现有情况的分析，尤其是IT系统现状、痛点等，得出客户的期望，进而设计出客户需要的服务。 c) 服务与资源的关系 很多人搞不清楚什么是服务，什么是资源，甚至有个号称云架构师的人跟我说，他实习了对虚拟化的纳管、资源调度，就是完整的云。 资源（resource）：在系统中， 基础设施、network设备，VM、host、OS、CPU、Memory、存储、software等等都被视作可分配资源。 服务是云计算的核心特征，根据业务要求等可以编排服务，使之能让客户消费，通常会绑定价格、SLA等一些附带属性。 d) 租户与组织的关系 要想清楚，根据客户现状，组织与租户怎么对应，是1对1，1对多，还是多对多。 e) 资源调度的原则 要考虑资源调度策略、资源类型、性能要求，同时要考虑弹性的时候如何伸缩。经常会有只能scale out，不能scale in，或者频繁scale out、in的情况出现。那么在考虑弹性判断条件、算法的时候，要综合几种监控告警数据，如业务、资源。 二、 IaaS方案 1. IaaS架构影响因素 如我之前在群里所说的，个人认为很多因素都会影响企业IaaS架构的选择，主要有以下一些： a) 企业IT发展规划 b) 企业组织架构 c) 企业管理制度 d) 业务类型 e) 应用层次 f) 人员技能 g) 技术成熟度 h) 成本 i) 周期 j) 运维体制 k) 。。。 如果不考虑其中的某个因素，都有可能导致项目的失败。我曾经亲身经历过，因为管理和客户组织架构原因导致的云项目失败。客户在实施云计算建设之前，业务部门是强势部门，IT部门是支撑部门，而在规划和建设中忽略了客户组织架构的影响因素。IT部门变成了云平台的管理者，业务部门成为相对弱势的云服务消费者，导致客户内部组织架构重组、项目停滞。 2. 私有云IaaS平台构成 我这里讲的是广义的云平台，我一般认为分成几大部分：门户（管理和自服务）、服务层、统一资源层（含适配器层）、基础设施（含虚拟化），紧密相关的有BSS、OSS子系统；外部可能交互的系统有ITSM、CMDB、外部监控系统、4A系统和通知系统等。我画了一个主要部件的草图，方便大家理解： a) 门户分为管理和自服务，分别给管理员和普通用户提供服务；用于展示基础设施、平台及软件服务，并控制用户接入方式，对用户的访问范围、界面的展示方式做设定等。以便于管理员和普通用户获取服务的信息，申请并使用各类服务。 b) 服务层指服务构建与设计的逻辑组件，它负责定义服务的结构、流程等信息，组装原子服务，生成业务服务，发布到服务目录，监控服务运行状况等，形成完整的服务生命周期管理。业务用户可以通过服务管理层获取云计算服务；管理员可以通过服务管理层监控所有服务实例的整体状况；服务开发人员可以通过服务管理层定义和发布服务。服务管理层将以业务服务的形式对外发布所有的服务操作接口。 c) 资源层指管理和调度软硬件资源的逻辑组件，它负责构建资源池，生成简单资源供应的技术服务（原子服务），定义资源运维的操作流程。为了组成资源池，一般将同质的设备集中安装，相互连接，并通过一定的管理软件来监管和配置。资源池由同质的一组资源组成，用户可以通过资源管理层软件从资源池中申请资源，指定该资源实例的配置，并管理其运行。管理员可以监控每个资源池的资源使用率，健康状况和性能状况。资源管理层将以技术服务的形式对外发布所有的资源操作接口。这一层要屏蔽掉虚拟化等的差异，使得上层无法感知。 d) 基础设施包括计算、存储、网络，其中计算含各种异构虚拟化。 e) BSS和OSS源自电信行业的B和O，BSS负责营销、结算等功能；OSS负责监控、安全等。不展开了。 3. 虚拟化异构 能否支持X86虚拟化异构、异构的支持广度是衡量一个云资源管理平台（区别与云服务管理平台）的一个重要标准。目前主流的虚拟化软件有几种： a) Vmware b) Hyper-v c) Xen d) Kvm e) 在kvm和xen上演化的各种版本 在此不考虑lxc等。 主要的实现思路是在资源层做统一纳管，用一套接口整合，也即适配器模式，每种使用一个适配器。在实际开发中，一般接口做二次抽象。 目前最常见的异构是VMWare和KVM（Openstack纳管），目前有几种途径： a) 自己实现，调用vcenter或vsphere的接口 推荐使用这种方式。 b) 各企业商业发行版 如，mirantis、hp hellion os商业版、racespace等，基本上不尽成熟，或者高级功能有缺陷。 c) VIO（VMWare Intergrated Openstack） 很多人跟我推荐VIO，我反对，理由有几点： 1. 遗产系统接管。如果对于已有的VMWare虚拟化，VIO无法接管 2. 性能。VIO部署在虚拟机上，作为vcenter插件，性能无法保障。 3. VIO本质上还是Openstack的一个实现，没有高级功能。 4. 如果需要SDN，要集成NSX，成本等各方面都需要考虑。 4. 小机与X86异构 除了X86虚拟化异构，还要考虑小机（主要是IBM power）、物理机、虚拟机的供应，这时也要考虑小机的纳管需求。采用的方式也是在资源层统一纳管，但接口会有独特性，一般用流程引擎调HMC解决。 5. Openstack及其应用场景 Openstack现在持续火热，各大厂商都在积极参与，本人也参加过openstack峰会。结合工作中的实际，我认为Openstack长期来讲是个好东西，适合一定场景的应用范围，但并不普适。可以应用在： a) 开发测试环境 b) 非关键业务 c) 科研实验环境 我认为Openstack需要解决的问题有： a) 稳定性 b) 可升级 c) 高级功能，如HA等 d) 遗产接管 此外，我认为Openstack存在贪多求快的问题，面铺的广，不够扎实，主要使用的还是那几个核心模块。 6. SDN不是企业级私有云基本需求 我曾经设计了一个集成SDN和NFV（部分功能，如SLB、VFW等）对的拓扑设计器，但在具体的企业级客户中，并没有太多客户迫切需要SDN。都会提到、以后扩展到SDN的实现，而不是眼前。 我认为SDN主要应用在几个场景： a) 公有云，租户定义私有网络 b) 私有云，需要频繁变更网络拓扑的环境，如开发测试、科研等 c) 电信、IDC等 7. 云管平台部署架构 云管平台的部署和普通的SaaS网站没有什么不同，都是SLB加HA，后端应用集群、数据库集群，一般没有很大的压力。 三、 云不一定节省成本（我知道我说在这个可能很多同行要扔搬砖，可是作为一个驾狗狮，虽千万人吾往矣。。。） 1. 规划、设计和建设周期长。云平台要承载所有准备上云的业务系统，考虑因素较多，如前述。 2. 前期采购成本高，前期资源池建设采购的设备数量较多，占用大量的机房、电源等资源，投资和运维成本均较高，一定时间内会闲置。前期规划能力不足，也会造成资源浪费。 3. 对企业的组织管理制度可能会有调整、单体人员技能会有较高要求，造成行政和人员成本升高。 4. 管理维护成本高、维护力量无法分层：维护人员要分成不同的团队，分别管理云平台和业务，必须熟悉平台所涉及的所有的软硬件资源，维护效率不高 5. 人云亦云，并不少见，尤其是资源池较小的情况下，纯属浪费。 云服务器ECS地址：阿里云·云小站
-
发表了文章 2020-10-03
阿里云服务器的系统盘与数据盘有什么区别？
阿里云ECS云服务器分为系统盘和数据盘，二者有什么区别呢？下面笔者科普ECS云服务器系统盘和数据盘的区别： ECS云服务器系统盘和数据盘的区别 通俗的将，云服务器的系统盘类似于Windows系统的C盘，数据盘相当于其他的盘符，阿里云百科从系统盘和数据盘创建、使用及数据方面来说说二者的区别： 系统盘和数据盘的创建方式区别： 系统盘：随ECS云服务器一起创建，随着ECS云服务器一起释放，生命周期与系统盘所挂载的ECS实例相同。 数据盘：可以和ECS一起创建，也可以单独创建数据盘。 数据盘和系统盘数据保存区别 ECS云服务器更换操作系统是通过更换系统盘来实现的，更换操作系统后系统盘原来的数据丢失。而更换操作系统，数据盘的内容不会丢失。 系统盘和数据盘大小限制 ECS云服务器系统盘容量大小受云服务器操作系统镜像制约，如下所示： Linux（不包括CoreOS）和FreeBSD：20 GiB ~ 500 GiB CoreOS：30 GiB ~ 500 GiB Windows：40 GiB ~ 500 GiB ECS云服务器数据盘： 容量范围：20G ~ 32768G之间。 综上，创建ECS云服务器时，系统盘是必须创建的，系统跟随ECS一起创建，而数据盘可以单独创建，更换服务器操作系统，系统盘内容随即丢失，而数据盘内容不会丢失，但是需要重新挂载数据盘。 注意：更换系统盘是属于是高危操作，建议做好快照再更换。 关于ECS云服务器系统盘和数据盘之间的区别可以参考官方文档：云盘概述 云服务器ECS地址：阿里云·云小站
-
发表了文章 2020-10-03
阿里云突发性能T5实例与全新T6实例和有什么区别？
有细心的小伙伴应该发现了，阿里云最近新推出了全新突发性能实例规格族T6，很多用户都只知道突发性能实例规格族T5，那么T6跟T5有什么区别呢？一起来看看 首先T6在处理器上做了全新升级 T6采用的是Intel(R) Xeon(R) Platinum 8269CY 处理器。 T5采用的是Intel Xeon E5-2682v4 / Intel Xeon(Skylake) Platinum 8163 处理器， 其次，T6实例在vCPU、内存和平均基准CPU计算性能做了调整 T6和T5实例具体实例规格vCPU、内存和平均基准CPU计算性分配如下表： 规格族 实例规格 vCPU 内存 平均基准 CPU 计算性能 处理器型号 内网带宽 内网收发包 突发性能实例 t6 ecs.t6-c4m1.large 2 vCPU 0.5 GiB 5% Intel(R) Xeon(R) Platinum 8269CY 0.1 Gbps 4 万 PPS 突发性能实例 t6 ecs.t6-c2m1.large 2 vCPU 1 GiB 10% Intel(R) Xeon(R) Platinum 8269CY 0.1 Gbps 6 万 PPS 突发性能实例 t6 ecs.t6-c1m1.large 2 vCPU 2 GiB 20% Intel(R) Xeon(R) Platinum 8269CY 0.1 Gbps 10 万 PPS 突发性能实例 t6 ecs.t6-c1m2.large 2 vCPU 4 GiB 20% Intel(R) Xeon(R) Platinum 8269CY 0.5 Gbps 10 万 PPS 突发性能实例 t6 ecs.t6-c1m4.large 2 vCPU 8 GiB 30% Intel(R) Xeon(R) Platinum 8269CY 0.4 Gbps 10 万 PPS 突发性能实例 t6 ecs.t6-c1m4.xlarge 4 vCPU 16 GiB 40% Intel(R) Xeon(R) Platinum 8269CY 0.8 Gbps 20 万 PPS 突发性能实例 t6 ecs.t6-c1m4.2xlarge 8 vCPU 32 GiB 40% Intel(R) Xeon(R) Platinum 8269CY 1.2 Gbps 40 万 PPS 突发性能实例 t5 ecs.t5-lc2m1.nano 1 vCPU 0.5 GiB 10% Intel Xeon CPU 0.1 Gbps 4 万 PPS 突发性能实例 t5 ecs.t5-lc1m1.small 1 vCPU 1 GiB 10% Intel Xeon CPU 0.2 Gbps 6 万 PPS 突发性能实例 t5 ecs.t5-lc1m2.small 1 vCPU 2 GiB 10% Intel Xeon CPU 0.2 Gbps 6 万 PPS 突发性能实例 t5 ecs.t5-c1m1.large 2 vCPU 2 GiB 15% Intel Xeon CPU 0.5 Gbps 10 万 PPS 突发性能实例 t5 ecs.t5-c1m2.large 2 vCPU 4 GiB 15% Intel Xeon CPU 0.5 Gbps 10 万 PPS 突发性能实例 t5 ecs.t5-lc1m2.large 2 vCPU 4 GiB 10% Intel Xeon CPU 0.4 Gbps 10 万 PPS 突发性能实例 t5 ecs.t5-lc1m4.large 2 vCPU 8 GiB 10% Intel Xeon CPU 0.4 Gbps 10 万 PPS 突发性能实例 t5 ecs.t5-c1m4.large 2 vCPU 8 GiB 15% Intel Xeon CPU 0.5 Gbps 10 万 PPS 突发性能实例 t5 ecs.t5-c1m1.xlarge 4 vCPU 4 GiB 15% Intel Xeon CPU 0.8 Gbps 20 万 PPS 突发性能实例 t5 ecs.t5-c1m2.xlarge 4 vCPU 8 GiB 15% Intel Xeon CPU 0.8 Gbps 20 万 PPS 突发性能实例 t5 ecs.t5-c1m4.xlarge 4 vCPU 16 GiB 15% Intel Xeon CPU 0.8 Gbps 20 万 PPS 突发性能实例 t5 ecs.t5-c1m1.2xlarge 8 vCPU 8 GiB 15% Intel Xeon CPU 1.2 Gbps 40 万 PPS 突发性能实例 t5 ecs.t5-c1m2.2xlarge 8 vCPU 16 GiB 15% Intel Xeon CPU 1.2 Gbps 40 万 PPS 突发性能实例 t5 ecs.t5-c1m4.2xlarge 8 vCPU 32 GiB 15% Intel Xeon CPU 1.2 Gbps 40 万 PPS 突发性能实例 t5 ecs.t5-c1m1.4xlarge 16 vCPU 16 GiB 15% Intel Xeon CPU 1.2 Gbps 60 万 PPS 突发性能实例 t5 ecs.t5-c1m2.4xlarge 16 vCPU 32 GiB 15% Intel Xeon CPU 1.2 Gbps 60 万 PPS 通过表格对比我们可以看出，新升级的T6实例在vCPU上最低为2核起，同时在平均基准 CPU 计算性能有了进一步的提升，最高可达40%， 注意：目前全新的突发性能实例规格族T6可选区域仅有华北2(北京)可选，暂时不支持其他地域。 总结：全新的T6实例在处理器、vCPU、平均基准CPU计算性能等方面做了全新的升级，适合对性能需求更高的用户购买。 云服务器ECS地址：阿里云·云小站
-
发表了文章 2020-10-03
学习Linux如何能事半功倍，明确这7点技巧！一位Linux大牛的心得分享
如今有很多关于Linux的书籍，博客。大多数都会比较“粗暴“的将一大堆的命令塞给读者，从而使很多Linux初学者望而却步，未入其门就路过了。 下面笔者给大家找了一下一个资深Linux用户关于学习Linux的一些建议： 随着Linux应用的扩展许多朋友开始接触Linux，根据学习Windwos的经验往往有一些茫然的感觉：不知从何处开始学起。 作为一个 Linux系统管理员，我看了许多有关Linux的文档和书籍，并为学习Linux付出了许多艰苦的努力。当真正获得了一份正式的Linux系统管理工作后，我更加深刻地理解了Linux的灵魂：服务与多用户。 Linux系统知识是非常广博的，但是只要掌握了重点知识，管理它并没有想象中的那么可怕。在下面我会将作为系统管理员的一些工作心得和总结出来的经验系统地介绍给大家。 一、 学习的目的 通过Linux的学习掌握UNIX的目的想必不用多说了，在这个网络人才身价倍增的年代，想靠技术吃饭又不想掌握网络和编程技术是不明智的。当一人第一次听说Linux并跃跃欲试的时候，总会提出几个? 它是什么(What)? 为什么要用它(Why)? 怎样学习它(How)? 做为开放源码运动的主要组成部分，Linux的应用越来越广泛，从我们平时的娱乐、学习，到商业、政府办公，再到大规模计算的应用。为了满足人们的需求，各种各样的、基于Linux的应用软件层出不穷。 只要具备了LinuX的基本功，并具有了自学的能力之后，都可以通过长期的学习将专项内容予以掌握。 二、 从命令开始学习 常常有些朋友一接触Linux 就是希望构架网站，根本没有想到要先了解一下Linux 的基础。这是相当困难的。虽然Linux桌面应用发展很快，但是命令在Linux中依然有很强的生命力。 Linux是一个命令行组成的操作系统,精髓在命令行，无论图形界面发展到什么水平这个原理是不会变的，Linux命令有许多强大的功能：从简单的磁盘操作、文件存取、到进行复杂的多媒体图象和流媒体文件的制作。 这里笔者把它们中比较重要的和使用频率最多的命令，按照它们在系统中的作用分成几个部分介绍给大家，通过这些基础命令的学习我们可以进一步理解 Linux系统： 安装和登录命令：login、 shutdown、 halt、 reboot 、mount、umount 、chsh 文件处理命令：file、 mkdir、 grep、dd、 find、 mv 、ls 、diff、 cat、 ln 系统管理相关命令： df、 top、 free、 quota 、at、 lp、 adduser、 groupadd kill、 crontab、 tar、 unzip、 gunzip 、last 网络操作命令：ifconfig、 ip 、ping 、 netstat 、telnet、 ftp、 route、 rlogin rcp 、finger 、mail 、nslookup 系统安全相关命令： passwd 、su、 umask 、chgrp、 chmod、chown、chattr、sudo、 pswho 三、 选择好的入门Linux书籍和相关视频 在各个Linux论坛中，我们看到最多的问题往往是某个新手，在安装或使用linux的过程中遇到一个具体的问题就开始提问，很多都是重复性的问题，甚至有不少人连基本的问题描述都不是很清楚。 这说明很多初学linux的人还没有掌握基本功。怎样才能快速提高掌握linux的基本功呢? 最有效的方法莫过于学习权威的linux工具书，工具书对于学习者而言是相当重要的。一本错误观念的工具书却会让新手整个误入歧途。编者不再这里做过多推荐，建议入门的童鞋们多在网上搜搜相关书籍的评价以及介绍，切记零基础的童鞋不要选择内容过深的书籍。 目前网络上也有很多免费的相关视频，建议没有接触过或者刚接触运维行业的童鞋先多去看看一些免费的基础视频或者参加一些线下的免费行业介绍讲座，这样才能知道该如何入门，如何着手学习或者选择什么方式学习，这都是很重要的。 四 、养成在命令行下工作的习惯 一定要养成在命令行下工作的习惯，要知道X-window只是运行在命令行模式下的一个应用程序。在命令行下学习虽然一开始进度较慢，但是熟悉后，您未来的学习之路将是以指数增加的方式增长的。 从网管员来说，命令行实际上就是规则，它总是有效的，同时也是灵活的。即使是通过一条缓慢的调制解调器线路，它也能操纵几千公里以外地远程系统。 五、用Unix思维思考Linux 由于Linux是参照Unix的思想来设计的，理解和掌握它就必须以Unix的思维来进行，而不能以Windows思维。不可否认，windows 在市场上的成功很大一部分在于技术思想的独到之处。 可是这个创新是在面对个人用户的前提下进行的，而面对着企业级的服务应用，它还是有些力不从心。多年来在计算机操作系统领域一直是二者独大：unix在服务器领域，Windows在个人用户领域。 由此可见，用户需求决定了所采用的操作系统。不管什么原因，如果要学习Linux，那么首先要将思维从Windows的“这个小河” 中拖出来，放入Unix的海洋。 六 、学习shell和Python 对于Shell(中文名称壳)，习惯Windows的读者肯定是非常陌生的，因为Windows只有一个“Shell”(如果可以说是Shell的话)，那就是Windows自己。用一句话容易理解的解释就是，shell是用户输入命令与系统解释命令之间的中介。 最直观的说法，一种Shell有一套自己的命令。举一个容易理解的例子，Linux的标准Shel是Bash Shel;Solaris的shell是B shell;Linux的Shell是以命令行的方式表现出来的。读者可能会不理解，Windows从命令行“进化”到了图形界面，那么Linux现在还使用命令行岂不是一种倒退? 当初刚刚接触Linux时就曾有过这种想法。可是后来发现，如果使用图形界面，那么分配给应用软件的资源就少了，在价格昂贵的服务器上，能够以较低的硬件配置实现同样的功能是非常重要的。 下面举例说明： 一台服务器有1GB内存，假设其中512MB用于处理图形界面，若要安装一个需要784MB内存的数据库软件，惟一的办法就是扩大内存。但是如果使用命令行，系统可能只需要64MB内存，其它的内存就可以供数据库软件使用了。使用命令行，不仅是内存，而且CPU及硬盘等资源的占用都要节省很多。 所以，作为服务器使用命令行是优点而不是缺点。既然Shell有这么多优点，就必须要学习它。 七、关注行业趋势更新技能 Linux运维的招聘要求感觉与往年同样薪资的招聘要求高了许多,又得会各种开源工具.还得懂K8S和docker。但凡15K以上的工资，都必须要会python，而且是要有一定的pythonweb开发能力，2016年这个时候一般的运维都是要求: shell/python/php，三选一，会点就行，但是2017年不一样了，python要具有一定的web开发能力才可以。如果不要求会python的，也势必要求shell很精通。 这里给出一点小的技能提升的建议: 大致需要学习下这四个部分: 自动化运维(Ansible，Puppet，Saltstack等) Devops(Docker，K8s，Jenkins，Jira等)， 云服务技术(虚拟化、OpenStack、AWS及阿里云各种产品服务架构等) python 云服务器ECS地址：阿里云·云小站
-
发表了文章 2020-10-01
阿里云服务器部署Node.js项目
Node.js是一个基于Chrome V8引擎的JavaScript运行环境，用来方便快速地搭建易于扩展的网络应用。Node.js使用了一个事件驱动、非阻塞式I/O的模型，使其轻量又高效，非常适合运行在分布式设备的数据密集型的实时应用。Node.js的包管理器npm，是全球最大的开源库生态系统。Node.js的典型应用场景包括： 实时应用：如在线聊天，实时通知推送等等（例如socket.io）。 分布式应用：通过高效的并行I/O使用已有的数据。 工具类应用：海量的工具，小到前端压缩部署（例如grunt），大到桌面图形界面应用程序。 游戏类应用：游戏领域对实时和并发有很高的要求（例如网易的pomelo框架）。 利用稳定接口提升Web渲染能力 前后端编程语言环境统一：前端开发人员可以非常快速地切入到服务器端的开发（例如著名的纯Javascript全栈式MEAN架构）。 一、部署Node.js环境 选择以下任意一种方法部署Node.js环境。 1.使用二进制文件安装 该部署过程使用的安装包是已编译好的二进制文件。解压之后，在bin文件夹中就已存在node和npm，无需重复编译。 完成以下操作，使用二进制文件部署Node.js环境： 下载Node.js安装包 wget https://nodejs.org/dist/v6.9.5/node-v6.9.5-linux-x64.tar.xz 解压文件 tar xvf node-v6.9.5-linux-x64.tar.xz 创建软链接，您就可以在任意目录下直接使用node和npm命令 ln -s /root/node-v6.9.5-linux-x64/bin/node /usr/local/bin/nodeln -s /root/node-v6.9.5-linux-x64/bin/npm /usr/local/bin/npm 查看node、npm版本 node -vnpm -v 至此，Node.js环境已安装完毕。软件默认安装在/root/node-v6.9.5-linux-x64/目录下 如果需要将该软件安装到其他目录（例如：/opt/node/）下，请进行如下操作： mkdir -p /opt/node/mv /root/node-v6.9.5-linux-x64/* /opt/node/rm -f /usr/local/bin/noderm -f /usr/local/bin/npmln -s /opt/node/bin/node /usr/local/bin/nodeln -s /opt/node/bin/npm /usr/local/bin/npm 2.使用NVM安装多版本NVM（Node Version Manager）是Node.js的版本管理软件，使您可以轻松在Node.js各个版本间进行切换。适用于长期做node开发的人员或有快速更新node版本、快速切换node版本的场景 完成以下操作，使用NVM安装多个Node.js版本： 使用git将源码克隆到本地的~/.nvm目录下，并检查最新版本 yum install git git clone https://github.com/cnpm/nvm.git ~/.nvm && cd ~/.nvm && git checkout `git describe --abbrev=0 --tags` 激活NVM echo ". ~/.nvm/nvm.sh" >> /etc/profilesource /etc/profile 列出Node.js的所有版本 nvm list-remote 安装多个Node.js版本 nvm install v6.9.5nvm install v7.4.0 运行nvm ls查看已安装的Node.js版本，当前使用的版本为v7.4.0。返回结果如下所示 [root@iZXXXXZ .nvm]# nvm ls v6.9.5 -> v7.4.0 system stable -> 7.4 (-> v7.4.0) (default)unstable -> 6.9 (-> v6.9.5) (default) 运行nvm use v7.4.0切换Node.js版本至v7.4.0。返回结果如下所示。 [root@iZXXXXZ .nvm]# nvm use v7.4.0Now using node v7.4.0 二、部署测试项目 新建项目文件example.js cd ~touch example.js 修改项目文件example.js 打开example.js vim example.js 按i进入编辑模式 将以下项目文件内容粘贴到文件中 const http = require('http');const hostname = '0.0.0.0';const port = 3000;const server = http.createServer((req, res) => { res.statusCode = 200; res.setHeader('Content-Type', 'text/plain'); res.end('Hello World\n'); }); server.listen(port, hostname, () => { console.log(`Server running at http://${hostname}:${port}/`); }); 说明 ：项目配置的端口号为3000。实际应用过程中，xu'yao自行配置端口号 按Esc退出编辑模式，然后输入:wq并回车以保存并关闭文件 运行项目 node ~/example.js & 运行以下命令查看是否在监听项目端口 netstat -tpln 在浏览器中输入http://地址>:端口号访问项目即可 云服务器ECS地址：阿里云·云小站
-
发表了文章 2020-10-01
基于阿里云CDN配置https协议教程
如今，https访问已经是不可置疑的大势所趋，阿里云很多产品都可以配置https访问，如果我们已经购买了阿里云虚拟主机、CDN以及ECS云服务器产品，可以参考以下步骤配置https访问。 申请SSL证书1.找到右上角菜单进入控制台，点击三——产品与服务>——安全——ssl证书，如果加圈星标会在左边栏显示。 2.购买证书，如果你有证书也可以上传。 3.支付确认订单，完成，下一步，点击进入证书控制台 4.申请证书，填写相关验证信息（重要），等待审核。 5.审核成功后，这里是审核成功的图，安装部署，下载所属服务器证书格式文件. 虚拟主机产品安装证书1.进入虚拟云主机，主机管理控制台。 2.域名管理——域名绑定——强制https加密访问，点击 开启， 有三个选择，免费-云盾-自定义(其实跟上面申请一样的)，这里选择刚刚申请的云盾证书。 3.已开启（云盾证书），可关闭。 4.访问效果，http自动跳转https 友情提醒：自动创建的证书http跳转https，在网站根目录.htaccess加入如下代码RewriteCond %{SERVER_PORT} !^443 https://%{SERVER_NAME}/$1 [L,R=301] 配置CDN使用HTTPS1.在阿里云后台进入“产品与服务”->“CDN”->“证书服务”。 2.点击配置证书，选择云盾证书，选择已签发的SSL证书。 3.选择关联的域名。 配置完成后，即可使用开启HTTPS的CDN了。 以上仅是虚拟主机产品和CDN配置https流程，如果我们需要给自己的ecs云服务器配置https可以参考：帮助中心-安装证书指南（Nginx服务器、Apache服务器、Tomcat服务器、IIS服务器和其他服务器类型证书下载并安装到对应的服务器中。） 云服务器ECS地址：阿里云·云小站
-
发表了文章 2020-10-01
阿里云服务器如何选择？ECS云服务器配置规格选择指南及使用体验
阿里云ECS云服务器如何选择？其中云服务器配置CPU、内存及宽带的选择，另外包括ECS云服务器规格的选择，笔者来说说阿里云ECS云服务器配置选择、规格说明及使用体验。 云服务器配置如何选择？ 阿里云ECS云服务器的配置包括CPU、内存、公网宽带及云盘，以下默认为40G高效云盘（如果存储不够，自己加即可） 配置 适用场景 1核CPU/1G内存/1M公网宽带 个人博客或者初期访问量较少的展示类Web应用 2核CPU/4G内存/3M公网宽带 论坛、门户类网站，用户活跃性与访问量较高，选保证足够的资源空间，提升访问速度。 2核CPU/8G内存/5M公网宽带 对官网、品牌较为重视的政府、企业等，网站浏览更加流利顺畅，提升政府、品牌形象。 4核CPU/8G内存/8M公网宽带 视频、购物类网站，包含庞大的数据信息，迅速的信息处理能力保证网站的点播、交易正常进行。 8核CPU/16G内存/10M公网宽带 游戏、软件类网站，对开发、测试、环境要求较高的游戏软件类网站，较高的资源配置带来更强劲的计算性能，保证业务需求。 以上云服务器配置仅供参考，还需要结合用户实际的应用场景来选择。另外，选购阿里云ECS云服务器，不能仅仅局限于CPU内存等配置，笔者提醒大家还需要选择合适的ECS规格，同配置下规格不同，云服务器的实际使用性能也有差异，关于ECS实例规格参考下方： ECS云服务器规格选择 阿里云ECS云服务器规格有很多，如：入门级突发性能T5、T6实例，共享型xn4、n4实例；还包括企业级通用网络增强型sn2ne、se1ne、GPU型、FPGA、计算型C6、内存型M6等，规格如何选择？笔者分享如下： ECS规格选择请参考下表： 应用场景 云服务器实例规格配置 性能均衡 sn2ne/g5/sn2 高网络收发包应用 sn1ne/sn2/ne/se1ne/g6/c6 高性能计算 gn5/cg/sn1/c4/cm4 高性能端游 c4/cm4 手游/网页 c5/sn1 视频转发 c5/sn1 直播弹幕 sn1ne/sn2/ne/g6/c6 关系型数据库 i1/i2/sn2/se1 分布式缓存 r5/se1/sn2ne/g5/sn2 NoSQL数据库 i1/i2/sn2ne/sn2r5/se1 Elastic Search i1/i2/sn2/g5/r5/se1 Hadoop r5/se1/d1n2/d1/g5/sn2/r6 均衡性能 需要相对均衡的处理器与内存资源配比，满足大多数场景下的应用资源需求关系。 高网络收发包应用 需要高网络收发包能力，可以根据应用场景选择更合理的计算与内存的资源配比。 高性能计算 需要消耗高计算资源，GPU并行计算以及高主频是该场景下的典型应用。 高性能端游 用户业务需要高处理器主频来承载更多的用户，需要高主频处理器支持。 手游、页游 需要消耗高计算资源，1:2的处理器与内存配比可以获得最优计算资源性价比。 视频转发 需要消耗高计算资源，1:2的处理器与内存配比可以获得最优计算资源性价比。 直播弹幕 需要高网络收发包能力，可以根据应用场景选择更合理的计算与内存的资源配比。 关系型数据库 需要SSD云盘或更高性能的NVMe SSD本地磁盘提供高存储IOPS且低读写延时，CPU与内存资源配比均衡（1:4）或内存更大（1:8）。 分布式缓存 需要CPU与内存资源配比均衡（1:4）或者内存更大（1:8），稳定的计算性能。 NoSQL数据库 需要SSD云盘或更高性能的NVMe SSD本地磁盘提供高存储IOPS且低读写延时，CPU与内存资源配比均衡（1:4）或内存更大（1:8）。 Elastic Search 需要SSD云盘或更高性能的NVMe SSD本地磁盘提供高存储IOPS且低读写延时，CPU与内存资源配比均衡（1:4）或内存更大（1:8）。 Hadoop 数据节点需要高磁盘吞吐、高网络吞吐、均衡的CPU与内存配比，计算节点则更关注计算性能、网络带宽及CPU与内存资源配。 Spark 数据节点需要高磁盘吞吐、高网络吞吐、均衡的CPU与内存配比，计算节点则更关注计算性能、网络带宽及CPU与内存资源配。 Kafka 数据节点需要高磁盘吞吐、高网络吞吐、均衡的CPU与内存配比，计算节点则更关注计算性能、网络带宽及CPU与内存资源配。 机器学习 需要高性能Nvidia GPU计算卡，内存不小于显存的两倍。 视频编码 需要高性能GPU计算卡或高性能CPU进行编解码。 渲染 需要高性能GPU计算卡进行渲染。 云服务器ECS地址：阿里云·云小站
-
发表了文章 2020-10-01
阿里云IIS服务器SSL证书安装
一、前提条件 申请证书时需要选择 系统自动创建CSR。 申请证书时如果选择手动创建CSR，则不会生成证书文件。您需要选择其他服务器下载.crt证书文件后，使用openssl命令将.crt文件的证书转换成.pfx格式。 二、操作指南 1.登录阿里云SSL证书控制台。 2.在SSL证书页面，点击已签发标签，定位到需要下载的证书并单击证书卡片右下角的下载打开证书下载对话框。 3.在证书下载对话框中定位到IIS服务器，并单击右侧操作栏的下载将IIS版证书压缩包下载到本地。 4.解压IIS证书。您将看到文件中有一个证书文件（以.pfx为后缀或文件类型）和一个秘钥文件（以.txt为后缀或文件类型）。 说明 每次下载证书都会产生新的密码，该密码仅匹配本次下载的证书。如果需要更新证书文件，同时也要更新匹配的密码文件。 5.在控制台操作对话框中导入您下载的IIS证书文件。 a.单击开始 > 运行 > MMC打开控制台。 b.单击文件 > 添加/删除管理单元打开添加/删除管理单元对话框。 c.在可用的管理单元中单击证书 > 添加 > 计算机账户 > 本地计算机（运行此控制台的计算机） > 完成。 d.在控制台左侧导航栏单击控制台根节点下的证书打开证书树形列表。 e.单击个人 > 证书 > > 所有任务 > 导入打开证书导入向导对话框。 f.单击浏览导入下载的PFX格式证书文件。 说明 在导入证书文件时， 文件名右侧文件类型下拉菜单中请选择 所有文件类型。 g.输入证书秘钥文件里的密码。 您可在下载的IIS证书文件中打开pfx-password .txt文件查看证书密码。 h.勾选根据证书类型，自动选择证书存储并单击下一步完成证书的导入。 6.分配服务器证书。 打开IIS8.0 管理器面板，定位到待部署证书的站点，单击绑定。 在网站绑定对话框中单击添加 > 选择https类型 > 端口选择443 > 导入的IIS证书名称 > 确定。 说明 SSL 缺省端口为 443 端口，请不要修改。 如果您使用其他端口如：8443，则访问网站时必须输入https://www.aliyun.com:8443 云服务器ECS地址：阿里云·云小站
-
发表了文章 2020-10-01
编程技巧总结
编译与运行 创建run.bat并输入如下代码： @echo off set path=c:mingwbin g++ -g 274.cpp -o 274.exe if errorlevel == 1 goto :next 274.exe :next 然后在终端中运行run即可 对拍 创建pai.bat并输入如下代码： @echo off set path=c:mingwbin g++ -g makedata.cpp -o makedata.exe g++ -g 1.cpp -o 1.exe g++ -g 2.cpp -o 2.exe :loop set path=c:mingwbin makedata.exe 1.exe 2.exe set path=c:windowssystem32 fc read1.out read2.out if errorlevel == 1 pause goto loop 开栈 //Windows下代码： int __size__=20<<20;//20MB char __p__=(char)malloc(__size__)+__size__; __asm__("movl %0, %%espn"::"r"(__p__)); //linux下代码： pragma comment(linker, "/STACK:102400000,102400000") 常数优化 1、选几个主要的循环，定义循环变量为register int 2、循环中使用++i,而不是i++ 3、循环展开，一般展开4层足矣 4、使用读入优化和输出优化 5、如果某些OJ不开O2的话，你可以使用如下代码强制开O2 #pragma GCC optimize("-O2") inline int add(int a,int b){return (a+=b)>=mod?a-mod:a;} inline int sub(int a,int b){return (a-=b)<0?a+mod:a;} inline int mul(int a,int b){return 1LLab%mod;} 6、取模运算建议这样写：（这样避免了使用long long以及尽量少的使用%符号 gdb调试 //在终端里运行： $ gdb 文件名.exe $ b 13 //在13行设置断点 $ r //运行至断点 $ n //单步跟踪 $ s //进入函数 $ p a //输出变量a的值 云服务器ECS地址：阿里云·云小站
-
发表了文章 2020-10-01
C++ 虚函数表解析
C++中的虚函数的作用主要是实现了多态的机制。关于多态，简而言之就是用父类型别的指针指向其子类的实例，然后通过父类的指针调用实际子类的成员函数。这种技术可以让父类的指针有“多种形态”，这是一种泛型技术。所谓泛型技术，说白了就是试图使用不变的代码来实现可变的算法。比如：模板技术，RTTI技术，虚函数技术，要么是试图做到在编译时决议，要么试图做到运行时决议。 关于虚函数的使用方法，我在这里不做过多的阐述。大家可以看看相关的C++的书籍。在这篇文章中，我只想从虚函数的实现机制上面为大家 一个清晰的剖析。 当然，相同的文章在网上也出现过一些了，但我总感觉这些文章不是很容易阅读，大段大段的代码，没有图片，没有详细的说明，没有比较，没有举一反三。不利于学习和阅读，所以这是我想写下这篇文章的原因。也希望大家多给我提意见。 言归正传，让我们一起进入虚函数的世界。 虚函数表 对C++ 了解的人都应该知道虚函数（Virtual Function）是通过一张虚函数表（Virtual Table）来实现的。简称为V-Table。在这个表中，主是要一个类的虚函数的地址表，这张表解决了继承、覆盖的问题，保证其容真实反应实际的函数。这样，在有虚函数的类的实例中这个表被分配在了这个实例的内存中，所以，当我们用父类的指针来操作一个子类的时候，这张虚函数表就显得由为重要了，它就像一个地图一样，指明了实际所应该调用的函数。 这里我们着重看一下这张虚函数表。C++的编译器应该是保证虚函数表的指针存在于对象实例中最前面的位置（这是为了保证取到虚函数表的有最高的性能——如果有多层继承或是多重继承的情况下）。 这意味着我们通过对象实例的地址得到这张虚函数表，然后就可以遍历其中函数指针，并调用相应的函数。 听我扯了那么多，我可以感觉出来你现在可能比以前更加晕头转向了。 没关系，下面就是实际的例子，相信聪明的你一看就明白了。 假设我们有这样的一个类： class Base { public: virtual void f() { cout &lt;&lt; &#34;Base::f&#34; &lt;&lt; endl; } virtual void g() { cout &lt;&lt; &#34;Base::g&#34; &lt;&lt; endl; } virtual void h() { cout &lt;&lt; &#34;Base::h&#34; &lt;&lt; endl; } }; 按照上面的说法，我们可以通过Base的实例来得到虚函数表。 下面是实际例程： typedef void(*Fun)(void); Base b; Fun pFun = NULL; cout << "虚函数表地址：" << (int*)(&b) << endl;cout << "虚函数表 — 第一个函数地址：" << (int)(int*)(&b) << endl; // Invoke the first virtual functionpFun = (Fun)((int)(int)(&b));pFun(); 实际运行经果如下：(Windows XP+VS2003, Linux 2.6.22 + GCC 4.1.3) 虚函数表地址：0012FED4 虚函数表 — 第一个函数地址：0044F148 Base::f 通过这个示例，我们可以看到，我们可以通过强行把&b转成int ，取得虚函数表的地址，然后，再次取址就可以得到第一个虚函数的地址了，也就是Base::f()，这在上面的程序中得到了验证（把int 强制转成了函数指针）。通过这个示例，我们就可以知道如果要调用Base::g()和Base::h()，其代码如下： (Fun)((int)(int)(&b)+0); // Base::f()(Fun)((int)(int)(&b)+1); // Base::g()(Fun)((int)(int)(&b)+2); // Base::h() 这个时候你应该懂了吧。什么？还是有点晕。也是，这样的代码看着太乱了。没问题，让我画个图解释一下。如下所示： 注意：在上面这个图中，我在虚函数表的最后多加了一个结点，这是虚函数表的结束结点，就像字符串的结束符“/0”一样，其标志了虚函数表的结束。这个结束标志的值在不同的编译器下是不同的。在WinXP+VS2003下，这个值是NULL。而在Ubuntu 7.10 + Linux 2.6.22 + GCC 4.1.3下，这个值是如果1，表示还有下一个虚函数表，如果值是0，表示是最后一个虚函数表。 下面，我将分别说明“无覆盖”和“有覆盖”时的虚函数表的样子。没有覆盖父类的虚函数是毫无意义的。我之所以要讲述没有覆盖的情况，主要目的是为了给一个对比。在比较之下，我们可以更加清楚地知道其内部的具体实现。 一般继承（无虚函数覆盖） 下面，再让我们来看看继承时的虚函数表是什么样的。假设有如下所示的一个继承关系： 请注意，在这个继承关系中，子类没有重载任何父类的函数。那么，在派生类的实例中，其虚函数表如下所示： 对于实例：Derive d; 的虚函数表如下： 我们可以看到下面几点：1）虚函数按照其声明顺序放于表中。2）父类的虚函数在子类的虚函数前面。 我相信聪明的你一定可以参考前面的那个程序，来编写一段程序来验证。 一般继承（有虚函数覆盖） 覆盖父类的虚函数是很显然的事情，不然，虚函数就变得毫无意义。下面，我们来看一下，如果子类中有虚函数重载了父类的虚函数，会是一个什么样子？假设，我们有下面这样的一个继承关系。 为了让大家看到被继承过后的效果，在这个类的设计中，我只覆盖了父类的一个函数：f()。那么，对于派生类的实例，其虚函数表会是下面的一个样子： 我们从表中可以看到下面几点，1）覆盖的f()函数被放到了虚表中原来父类虚函数的位置。2）没有被覆盖的函数依旧。 这样，我们就可以看到对于下面这样的程序， Base *b = new Derive(); b->f(); 由b所指的内存中的虚函数表的f()的位置已经被Derive::f()函数地址所取代，于是在实际调用发生时，是Derive::f()被调用了。这就实现了多态。 多重继承（无虚函数覆盖） 下面，再让我们来看看多重继承中的情况，假设有下面这样一个类的继承关系。注意：子类并没有覆盖父类的函数。 对于子类实例中的虚函数表，是下面这个样子： 我们可以看到：1） 每个父类都有自己的虚表。2） 子类的成员函数被放到了第一个父类的表中。（所谓的第一个父类是按照声明顺序来判断的） 这样做就是为了解决不同的父类类型的指针指向同一个子类实例，而能够调用到实际的函数。 多重继承（有虚函数覆盖） 下面我们再来看看，如果发生虚函数覆盖的情况。 下图中，我们在子类中覆盖了父类的f()函数。 下面是对于子类实例中的虚函数表的图： 我们可以看见，三个父类虚函数表中的f()的位置被替换成了子类的函数指针。这样，我们就可以任一静态类型的父类来指向子类，并调用子类的f()了。如： Derive d;Base1 *b1 = &d;Base2 *b2 = &d;Base3 *b3 = &d;b1->f(); //Derive::f()b2->f(); //Derive::f()b3->f(); //Derive::f() b1->g(); //Base1::g()b2->g(); //Base2::g()b3->g(); //Base3::g()安全性 每次写C++的文章，总免不了要批判一下C++。这篇文章也不例外。通过上面的讲述，相信我们对虚函数表有一个比较细致的了解了。水可载舟，亦可覆舟。下面，让我们来看看我们可以用虚函数表来干点什么坏事吧。 一、通过父类型的指针访问子类自己的虚函数 我们知道，子类没有重载父类的虚函数是一件毫无意义的事情。因为多态也是要基于函数重载的。虽然在上面的图中我们可以看到Base1的虚表中有Derive的虚函数，但我们根本不可能使用下面的语句来调用子类的自有虚函数： Base1 *b1 = new Derive();b1->f1(); //编译出错任何妄图使用父类指针想调用子类中的未覆盖父类的成员函数的行为都会被编译器视为非法，所以，这样的程序根本无法编译通过。但在运行时，我们可以通过指针的方式访问虚函数表来达到违反C++语义的行为。（关于这方面的尝试，通过阅读后面附录的代码，相信你可以做到这一点） 二、访问non-public的虚函数 另外，如果父类的虚函数是private或是protected的，但这些非public的虚函数同样会存在于虚函数表中，所以，我们同样可以使用访问虚函数表的方式来访问这些non-public的虚函数，这是很容易做到的。 如： class Base { private: virtual void f() { cout &lt;&lt; &#34;Base::f&#34; &lt;&lt; endl; } }; class Derive : public Base{ }; typedef void(*Fun)(void); void main() { Derive d; Fun pFun &#61; (Fun)*((int*)*(int*)(&amp;d)&#43;0); pFun(); } 结束语 C++这门语言是一门Magic的语言，对于程序员来说，我们似乎永远摸不清楚这门语言背着我们在干了什么。需要熟悉这门语言，我们就必需要了解C++里面的那些东西，需要去了解C++中那些危险的东西。不然，这是一种搬起石头砸自己脚的编程语言。 附录一：VC中查看虚函数表 我们可以在VC的IDE环境中的Debug状态下展开类的实例就可以看到虚函数表了（并不是很完整的） 附录 二：例程 下面是一个关于多重继承的虚函数表访问的例程： #include <iostream>using namespace std; class Base1 {public: virtual void f() { cout &lt;&lt; &#34;Base1::f&#34; &lt;&lt; endl; } virtual void g() { cout &lt;&lt; &#34;Base1::g&#34; &lt;&lt; endl; } virtual void h() { cout &lt;&lt; &#34;Base1::h&#34; &lt;&lt; endl; } }; class Base2 {public: virtual void f() { cout &lt;&lt; &#34;Base2::f&#34; &lt;&lt; endl; } virtual void g() { cout &lt;&lt; &#34;Base2::g&#34; &lt;&lt; endl; } virtual void h() { cout &lt;&lt; &#34;Base2::h&#34; &lt;&lt; endl; } }; class Base3 {public: virtual void f() { cout &lt;&lt; &#34;Base3::f&#34; &lt;&lt; endl; } virtual void g() { cout &lt;&lt; &#34;Base3::g&#34; &lt;&lt; endl; } virtual void h() { cout &lt;&lt; &#34;Base3::h&#34; &lt;&lt; endl; } }; class Derive : public Base1, public Base2, public Base3 {public: virtual void f() { cout &lt;&lt; &#34;Derive::f&#34; &lt;&lt; endl; } virtual void g1() { cout &lt;&lt; &#34;Derive::g1&#34; &lt;&lt; endl; } }; typedef void(*Fun)(void); int main(){ Fun pFun &#61; NULL; Derive d; int** pVtab &#61; (int**)&amp;d; //Base1&#39;s vtable //pFun &#61; (Fun)*((int*)*(int*)((int*)&amp;d&#43;0)&#43;0); pFun &#61; (Fun)pVtab[0][0]; pFun(); //pFun &#61; (Fun)*((int*)*(int*)((int*)&amp;d&#43;0)&#43;1); pFun &#61; (Fun)pVtab[0][1]; pFun(); //pFun &#61; (Fun)*((int*)*(int*)((int*)&amp;d&#43;0)&#43;2); pFun &#61; (Fun)pVtab[0][2]; pFun(); //Derive&#39;s vtable //pFun &#61; (Fun)*((int*)*(int*)((int*)&amp;d&#43;0)&#43;3); pFun &#61; (Fun)pVtab[0][3]; pFun(); //The tail of the vtable pFun &#61; (Fun)pVtab[0][4]; cout&lt;&lt;pFun&lt;&lt;endl; //Base2&#39;s vtable //pFun &#61; (Fun)*((int*)*(int*)((int*)&amp;d&#43;1)&#43;0); pFun &#61; (Fun)pVtab[1][0]; pFun(); //pFun &#61; (Fun)*((int*)*(int*)((int*)&amp;d&#43;1)&#43;1); pFun &#61; (Fun)pVtab[1][1]; pFun(); pFun &#61; (Fun)pVtab[1][2]; pFun(); //The tail of the vtable pFun &#61; (Fun)pVtab[1][3]; cout&lt;&lt;pFun&lt;&lt;endl; //Base3&#39;s vtable //pFun &#61; (Fun)*((int*)*(int*)((int*)&amp;d&#43;1)&#43;0); pFun &#61; (Fun)pVtab[2][0]; pFun(); //pFun &#61; (Fun)*((int*)*(int*)((int*)&amp;d&#43;1)&#43;1); pFun &#61; (Fun)pVtab[2][1]; pFun(); pFun &#61; (Fun)pVtab[2][2]; pFun(); //The tail of the vtable pFun &#61; (Fun)pVtab[2][3]; cout&lt;&lt;pFun&lt;&lt;endl; return 0; } 注：本文年代久远，所有的示例都是在32位机上跑的。 云服务器ECS地址：阿里云·云小站
-
发表了文章 2020-09-30
阿里云服务器如何开发APP、门户网站？高可用架构常见场景v
一、 前言： “高可用性”（High Availability）通常来描述一个系统经过专门的设计，从而减少停工时间，而保持其服务的高度可用性。所以当我们一说到高可用，我们满脑子都是以负载均衡为主心骨搭建的拓扑图，以他为中心，从单节点拓展为多节点，消灭单点故障。但随着我们业务架构越来越庞大复杂，那么要考虑的就不再只是服务器维度的高可用了。接下来，我来给大家介绍一下不同维度的“高可用”在架构上是如何实现的。 二、 通用高可用 很多人在搭建业务的时候喜欢用一台高性能服务器搭建所有业务所需的应用和环境。比如服务器上搭建Nginx、会员系统、订单系统、自建数据库等等。这类搭建的初衷大概有简单省事、预算不足、初期业务量小感觉够用等因素。这些困难业主要集中在业务上线初期，都是很现实的问题，不过随之带来的是更加现实的困难。性能瓶颈很快到来，后期调整架构会因越来越大的数据量和停服带来收益减少等等问题。 所以业务初期搭建一个基础高可用框架，日后根据需要逐渐添加功能。 A、后期业务增加后我们再根据需要逐步扩容，例如数据库读写压力大了，我们用Redis、数据库读写分离等手段。这样扩容不用复杂的操作，不用长时间的停服迁移重要的数据信息。 B、再后来业务量进一步扩大，需要短信服务、需要组网、需要安全防护等等，都可以灵活拓展。所以对于服务器层面来说，一开始就搭建一个高可用架构是至关重要的。 三、 进阶高可用： 容灾方面： 通常对于一个普通的APP、门户网站、内部系统等等业务，通用高可用已经足够了。但为了实现客户们日益提高的对体验感的的高要求，工程师们不知踏平了多少坑以后实践出了与之对应的高级高可用架构。这种架构不再针对某一个业务集群做高可用，而是以业务为维度。举个例子当某一个地域的业务不可用时，能有其他地域的备用集群顶上。 客户体验感： 当业务做大到一定程度，客户群体就不仅仅局限于一个市或者一个省，乃至一个国家。这时候，因为客户离业务集群太远，导致通讯质量不佳，延迟、丢包问题层出不穷。以前我们经常用“三秒”来定义一个网站的好坏，但现在主流网站大多均已采用“1.5秒”来打分了。传统的单业务节点越来越难满足了，那就得考虑多节点同时运行承载业务，可通过全局流量来实现。而多节点之间的数据同步可以用阿里云的云企业网来实现。 负载均衡从其应用的地理结构上分为本地负载均衡和全局负载均衡。本地负载均衡是指对同地域的服务器群做负载均衡，全局负载均衡是指对分别部署在不同地域有不同网络结构的服务器群做负载均衡。 多线路智能化解析服务 全局流量管理利用DNS智能解析和应用服务的运行状态健康检查，将用户访问定向到最合适的IP地址，使访问用户获得最快捷、最流畅的体验。 跨地域容灾 全局流量支持将不同地域的IP地址添加到不同的地址池，并配置健康检查。在访问策略配置中，设置默认地址池为地址池甲，Failover地址池为地址池乙，即可以实现应用服务主备IP容灾切换。 不同地域访问加速 使用全局流量管理，可以使不同地域的用户访问不同的IP地址池，实现用户分组管理，分组接入，帮助应用服务提高用户访问体验。 这样我们也就能搭建一个便于客户就近访问的业务集群了，而用CEN组网打通各机房VPC，数据同步方面的工作也能变得更简单。>>直达阿里云官网云服务器租赁 云服务器ECS地址：阿里云·云小站
-
发表了文章 2020-09-30
Java架构师必须掌握的 21 个 Java 核心技术！（干货）
写这篇文章的目的是想总结一下自己这么多年来使用java的一些心得体会，希望可以给大家一些经验，能让大家更好学习和使用Java。 这次介绍的主要内容是和J2SE相关的部分，另外，会在以后再介绍些J2EE相关的、和Java中各个框架相关的内容。 经过这么多年的Java开发，以及结合平时面试Java开发者的一些经验，我觉得对于J2SE方面主要就是要掌握以下的一些内容。 1. JVM相关 对于刚刚接触Java的人来说，JVM相关的知识不一定需要理解很深，对此里面的概念有一些简单的了解即可。 不过对于一个有着3年以上Java经验的资深开发者来说，不会JVM几乎是不可接受的。 JVM作为java运行的基础，很难相信对于JVM一点都不了解的人可以把java语言吃得很透。 我在面试有超过3年Java经验的开发者的时候， JVM几乎就是一个必问的问题了。 当然JVM不是唯一决定技术能力好坏的面试问题，但是可以佐证java开发能力的高低。 在JVM这个大类中，我认为需要掌握的知识有： JVM内存模型和结构 GC原理，性能调优 调优：Thread Dump， 分析内存结构 class 二进制字节码结构， class loader 体系 ， class加载过程 ， 实例创建过程 方法执行过程 Java各个大版本更新提供的新特性(需要简单了解) 2. Java的运行 这条可能出看很简单，java程序的运行谁不会呢？ 不过很多时候， 我们只是单纯通过IDE去执行java程序，底层IDE又是如何执行java程序呢？很多人并不了解。 这个知识点是最最基本的java开发者需要掌握的，第一个肯定是教你如何在命令行中执行java程序，但是很多人一旦把java学完了，IDE用上了，就把这个都忘了。 为什么强调要知道这个呢，知道了java最纯粹的启动方式之后，你才能在启动出问题的时候，去分析当时启动的目录多少，执行命名如何，参数如何，是否有缺失等。 这样有利于你真正开发中去解决那些奇奇怪怪的可能和环境相关的问题。 在这里需要掌握的知识有： javac 编译java文件为 class 文件 java 命令的使用， 带package的java类如何在命令行中启动 java程序涉及到的各个路径(classpath， java。library。path， java运行的主目录等) 3. 数据类型 这条没有什么好多说的，无非就是Java中的基本类型和对象类型的掌握。 可以再了解一些JDK如何自动转换方面的知识，包括装箱拆箱等，还要注意避免装箱之后的类型相等的判断。 主要知识点： 基本类型： int， long， float， double， boolean 。。。 对应的对象类型： Integer 等类型到基本类型的转换， 装箱和拆箱 Object类型： equals， hashcode String 类型的特点 4. 对象和实例 在这方面，开发者需要了解class和instance的概念以及之间的差别， 这是java面向对象特性的一个基础。 主要知识点有： Class和 Instance 的概念 Instance 创建的过程： 无继承：分配内存空间， 初始化变量， 调用构造函数 有继承：处理静态动作， 分配内存空间， 变量定义为初始值 ， 从基类->子类， 处理定义处的初始化， 执行构造方法 需要注意的点： 静态属性等从基类->子类进行初始化 默认无参构造方法相关的特性 5. 访问控制 这也是java封装特性的一个基础，需要掌握的有：public protected default private 对于class， method， field 的修饰作用。 6. 流程控制 Java 流程控制的基础， 虽然有些语法不一定很常用，但是都需要了解，并且在合适的地方使用它们。 需要掌握的有：if， switch， loop， for， while 等流程控制的语法。 7. 面向对象编程的概念 这是一个java的核心概念，对于任何java开发者都需要熟练掌握。 Java中很多特性或者说知识点都是和java面向对象编程概念相关的。 在我的理解，一个好的开发者不仅仅需要了解这些特性（知识点）本身。 也更需要知道这些对象在java的面向对象编程概念中是如何体现出来的，这样更有利于开发者掌握java这门开发语言，以及其他面向对象编程的语言。 在这里只是简单罗列了一下，主要的知识点包括有： 面向对象三大特性：封装，继承，多态; 各自的定义概念，有哪些特性体现出来，各自的使用场景 静态多分派，动态单分派的概念 重载的概念和使用 继承：接口多实现，基类单继承 抽象，抽象类，接口 多态：方法覆盖的概念和使用 接口回调 8. static 静态属性在java日常开发中也是经常使用，需要了解和 static 关键字相关的用法，还有和其他关键字的配合使用， 如是否可以和 abstract， final 等关键字联合使用。 主要需要掌握的有： 静态属性的定义，使用，以及类加载时如何初始化 静态方法的定义和使用 静态类的定义和使用 静态代码块的定义和初始化时机 9. 基础知识点 这里主要罗列一些散落的，没有系统归类的一些java知识点。 在日常的开发中用到也不少。 这块内容其实还有很多，目前只是暂时归纳了这几个在这里： 包括有： equals hashcode tring/stringbuffer final finally finalize 10. 集合框架 这个是一个需要多加掌握的部分，做java开发，可以说没有不用到集合框架的，这很重要，这里整理的Java集合面试题及答案你必须都要清楚。 但是这里的知识点并不难，但是对于集合最好要了解内部的实现方式，因为这样有助于你在各个不同的场景选择适合的框架来解决问题，比如有1W个元素的集合，经常要进行contains判断操作，知道了集合的特性或者内部实现，就很容易做出正确的选择。 这里包括了如下内容(并发相关不包含在内)： 集合框架的体系： 基础Collection ，Map 具体集合实现的内容， List ，Set ，Map 具体的实现，内部结构， 特殊的方法， 适用场景等 集合相关的工具类 Collections 等的用法 11. 异常框架 异常在java的开发中可能没有那么被重视，异常处理的最佳实战详细说明了。 一般遇到异常，直接上抛，或者随便catch一下处理之后对于程序整体运行也没有什么大的影响。不过在企业级设计开发中， 异常的设计与处理的好坏，往往就关系着这个系统整体的健壮性。 一个好的系统的异常对于开发者来说，处理应该统一，避免各处散落很多异常处理逻辑；对于系统来说，异常应该是可控的，并且是易于运维的，某些异常出现后，应该有应对的方法，知道如何运维处理，所以虽然异常框架很简单，但是对于整个企业级应用开发来说，异常处理是很重要的，处理好异常就需要了解Java中的异常体系。 这部分需要掌握的知识点不多，主要就是： 异常的体系： Throwable Exception RuntimeException Error RuntimeException 和 一般 Exception 的区别， 具体处理方法等 12. Java IO IO 在java中不仅仅是文件读写那么简单，也包括了 socket 网络的读写等等一切的输入输出操作。比如说 标准HTTP请求中Post的内容的读取也是一个输出的过程，等等… 对于IO，Java不仅提供了基本Input、Output相关的api，也提供了一些简化操作的Reader、Writer等api，在某些开发（涉及大量IO操作的项目）中也很重要，一般日常的开发中也会涉及（日志，临时文件的读写等）。 在这中的知识点主要有： 基本IO的体系包括有InputStream ， OutputStream， Reader/Writer， 文件读取，各种流读取等，NIO 的概念， 具体使用方式和使用场景。 13. 多线程并发 多线程是Java中普遍认为比较难的一块。 多线程用好了可以有效提高cpu使用率， 提升整体系统效率， 特别是在有大量IO操作阻塞的情况下；这里整理的Java多线程面试题及答案你必须都要清楚。 但是它也是一柄双刃剑， 如果用不好，系统非但提升不大，或者没有提升，而且还会带来多线程之间的调试时等问题。 在多线程中内容有很多，只是简单说明一下Java中初步使用多线程需要掌握的知识点，以后有机会单独再详细介绍一些高级特性的使用场景。在Java技术栈公众号回复"多线程"可获取多线程系列教程。 多线程的实现和启动 callable 与 runable 区别 syncrhoized ，reentrantLock 各自特点和比对 线程池 future 异步方式获取执行结果 concurrent 包 lock 14. 网络 Java中也是提供了可以直接操作 TCP协议、UDP协议的API。 在需要强调网络性能的情况下，可以直接使用TCP/UDP 进行通讯。 在查看Tomcat等的源码中，就可以看到这些相关API的使用情况。 不过一般也比较少会直接使用TCP，会使用诸如MINA、Netty这样的框架来进行处理，因为这个方面的开发涉及不多，所以就不再详细罗列了。 15. 时间日期处理 几乎对于每个应用来说，时间日期的处理也是绕不过去的，但是JDK8 之前的时间相关API用法并不友好。 在那个时代，可以选择Joda等时间框架。到了JDK8 发布之后，全新的时间API基本融合了其他框架的优点，已经可以很好的直接使用了。 对于Java开发者来说，需要熟练地使用API来对时间和日期做相关的处理。 具体知识点不再罗列，会在以后再写个专门的文章来总结一下JDK8中时间日期API的用法。 16. XML解析/JSON解析 其实这两块内容都不是J2SE里面的内容，但是在日常开发中，和其他程序交互，和配置文件交互，越来越离不开这两种格式的解析。 不过对于一个开发者来说，能够了解一些XML/JSON具体解析的原理和方法，有助于你在各个具体的场景中更好的选择合适你的方式来使得你的程序更有效率和更加健壮。 XML： 需要了解 DOM解析和 SAX解析的基本原理和各自的适用场景 JSON： 需要了解一些常用JSON框架的用法， 如 Jackson， FastJson， Gson 等。 17. Maven使用 Maven也不是Java里面的内容，但是maven是革命性的，给java开发带来了巨大的便利，这30个Maven命令你必须熟悉。 从依赖的引入和管理，开发流程的更新和发布产出，乃至版本的更新，使用maven可以大大简化开发过程中的复杂度，从而节省大量时间。 可以说，maven已经成为java开发者的标配了。所以我把maven也作为一个java开发者对于基础必备的知识点。 18. 泛型 这是JDK5开始引入的新概念，其实是个语法糖。 在编写java代码时会有些许便利， 一般的应用或者是业务的开发，只需要简单使用，不一定会用到定义泛型这样的操作。 但是开发一些基础公共组件会使用到，可以在需要的时候再细看这个部分，一般情况下只要会简单使用即可。 19. 注解 也是jdk5 之后引入的，元注解你必须了解。 spring是个优秀的框架，最开始就以xml作为标准的配置文件。 不过到了Spring3 之后，尤其是 spring-boot 兴起之后，越来越推崇使用标注来简化xml配置文件了，对于开发者来说，可以节省不少xml配置的时间。 但是劣势是在于标注散落在各个类中，不像xml，可以对所有配置有个全局性的理解和管理，所以还没有办法说完全就取代所有的xml。 对于一般开发者，会使用标注即可，一些公共组建的开发者可能会需要了解标注的定义和实现，可以在具体需要的时候再细看。 20. RMI RemoteMethodInvocation ，Java语言特有的远程调用接口，使用还是比较简单方便，点击这里了解RMI与RPC的区别详情。 不过需要跨语言的情况下，就需要使用 webservice 等其他方式来支持。 一般来说，程序都不需要使用RMI，不过可以在特定的情况下使用，我就在一个项目中，使用RMI来进行程序远程启动停止的控制。 21. JNI Java Native Interface，可以允许Java中调用本地接口方法，一般用于C/C++代码的调用。 需要注意的是在java中加载so/dll文件的路径问题，本身调用接口并不复杂，但是经常在是否加载了所需的本地接口库中花费较多时间。 以上也只是简单介绍了下我对于这些java基本知识点和技术点的一些看法和介绍。 这些内容都源自于我这些年来使用java的一些总结 。这当中还有些内容不够完善的地方，会通过以后的文章再添加上。 云服务器ECS地址：阿里云·云小站
-
发表了文章 2020-09-30
kubernetes系列教程(三)kubernetes快速入门
写在前面 kubernetes中涉及很多概念，包含云生态社区中各类技术，学习成本比较高，k8s中通常以编写yaml文件完成资源的部署，对于较多入门的人来说是个较高的门坎，本文以命令行的形式带领大家快速入门，俯瞰kubernetes核心概念，快速入门。 1. 基础概念 1.1 集群与节点 kubernetes是一个开源的容器引擎管理平台，实现容器化应用的自动化部署，任务调度，弹性伸缩，负载均衡等功能，cluster是由master和node两种角色组成 master负责管理集群，master包含kube-apiserver，kube-controller-manager，kube-scheduler，etcd组件 node节点运行容器应用，由Container Runtime，kubelet和kube-proxy组成，其中Container Runtime可能是Docker，rke，containerd，node节点可由物理机或者虚拟机组成。 kubernetes集群概念 1、查看master组件角色 [root@node-1 ~]# kubectl get componentstatuses NAME STATUS MESSAGE ERRORscheduler Healthy ok controller-manager Healthy ok etcd-0 Healthy {"health":"true"} 2、 查看node节点列表 [root@node-1 ~]# kubectl get nodesNAME STATUS ROLES AGE VERSIONnode-1 Ready master 26h v1.14.1node-2 Ready <none> 26h v1.14.1node-3 Ready <none> 26h v1.14.1 3、查看node节点详情 [root@node-1 ~]# kubectl describe node node-3Name: node-3Roles: <none>Labels: beta.kubernetes.io/arch=amd64。#标签和Annotations beta.kubernetes.io/os&#61;linux kubernetes.io/arch&#61;amd64 kubernetes.io/hostname&#61;node-3 kubernetes.io/os&#61;linux Annotations: flannel.alpha.coreos.com/backend-data: {"VtepMAC":"22:f8:75:bb:da:4e"} flannel.alpha.coreos.com/backend-type: vxlan flannel.alpha.coreos.com/kube-subnet-manager: true flannel.alpha.coreos.com/public-ip: 10.254.100.103 kubeadm.alpha.kubernetes.io/cri-socket: /var/run/dockershim.sock node.alpha.kubernetes.io/ttl: 0 volumes.kubernetes.io/controller-managed-attach-detach: true CreationTimestamp: Sat, 10 Aug 2019 17:50:00 +0800Taints: <none>Unschedulable: false。#是否禁用调度，cordon命令控制的标识位。Conditions: #资源调度能力，MemoryPressure内存是否有压力（即内存不足） #DiskPressure磁盘压力 #PIDPressure磁盘压力 #Ready&#xff0c;是否就绪&#xff0c;表明节点是否处于正常工作状态&#xff0c;表示资源充足&#43;相关进程状态正常 Type Status LastHeartbeatTime LastTransitionTime Reason Message ---- ------ ----------------- ------------------ ------ ------- MemoryPressure False Sun, 11 Aug 2019 20:32:07 +0800 Sat, 10 Aug 2019 17:50:00 +0800 KubeletHasSufficientMemory kubelet has sufficient memory available DiskPressure False Sun, 11 Aug 2019 20:32:07 +0800 Sat, 10 Aug 2019 17:50:00 +0800 KubeletHasNoDiskPressure kubelet has no disk pressure PIDPressure False Sun, 11 Aug 2019 20:32:07 +0800 Sat, 10 Aug 2019 17:50:00 +0800 KubeletHasSufficientPID kubelet has sufficient PID available Ready True Sun, 11 Aug 2019 20:32:07 +0800 Sat, 10 Aug 2019 18:04:20 +0800 KubeletReady kubelet is posting ready statusAddresses: #地址和主机名 InternalIP: 10.254.100.103 Hostname: node-3Capacity: #容器的资源容量 cpu: 2 ephemeral-storage: 51473868Ki hugepages-2Mi: 0 memory: 3880524Ki pods: 110Allocatable: #已分配资源情况 cpu: 2 ephemeral-storage: 47438316671 hugepages-2Mi: 0 memory: 3778124Ki pods: 110System Info: #系统信息，如内核版本，操作系统版本，cpu架构，node节点软件版本 Machine ID: 0ea734564f9a4e2881b866b82d679dfc System UUID: D98ECAB1-2D9E-41CC-9A5E-51A44DC5BB97 Boot ID: 6ec81f5b-cb05-4322-b47a-a8e046d9bf79 Kernel Version: 3.10.0-957.el7.x86_64 OS Image: CentOS Linux 7 (Core) Operating System: linux Architecture: amd64 Container Runtime Version: docker://18.3.1 . #Container Runtime为docker，版本为18.3.1 Kubelet Version: v1.14.1 #kubelet版本 Kube-Proxy Version: v1.14.1 #kube-proxy版本PodCIDR: 10.244.2.0/24 #pod使用的网络Non-terminated Pods: (4 in total)。 #下面是每个pod资源占用情况 Namespace Name CPU Requests CPU Limits Memory Requests Memory Limits AGE --------- ---- ------------ ---------- --------------- ------------- --- kube-system coredns-fb8b8dccf-hrqm8 100m (5%) 0 (0%) 70Mi (1%) 170Mi (4%) 26h kube-system coredns-fb8b8dccf-qwwks 100m (5%) 0 (0%) 70Mi (1%) 170Mi (4%) 26h kube-system kube-flannel-ds-amd64-zzm2g 100m (5%) 100m (5%) 50Mi (1%) 50Mi (1%) 26h kube-system kube-proxy-x8zqh 0 (0%) 0 (0%) 0 (0%) 0 (0%) 26hAllocated resources: #已分配资源情况 (Total limits may be over 100 percent, i.e., overcommitted.) Resource Requests Limits -------- -------- ------ cpu 300m (15%) 100m (5%) memory 190Mi (5%) 390Mi (10%) ephemeral-storage 0 (0%) 0 (0%)Events: <none> 1.2 容器与应用 kubernetes是容器编排引擎，其负责容器的调度，管理和容器的运行，但kubernetes调度最小单位并非是container，而是pod，pod中可包含多个container，通常集群中不会直接运行pod，而是通过各种工作负载的控制器如Deployments，ReplicaSets，DaemonSets的方式运行，为啥？因为控制器能够保证pod状态的一致性，正如官方所描述的一样“make sure the current state match to the desire state”，确保当前状态和预期的一致，简单来说就是pod异常了，控制器会在其他节点重建，确保集群当前运行的pod和预期设定的一致。 pod是kubernetes中运行的最小单元 pod中包含一个容器或者多个容器 pod不会单独使用，需要有工作负载来控制，如Deployments，StatefulSets，DaemonSets，CronJobs等 container与pod Container，容器是一种轻量化的虚拟化技术，通过将应用封装在镜像中，实现便捷部署，应用分发。 Pod，kubernetes中最小的调度单位，封装容器，包含一个pause容器和应用容器，容器之间共享相同的命名空间，网络，存储，共享进程。 Deployments，部署组也称应用，严格上来说是无状态化工作负载，另外一种由状态化工组负载是StatefulSets，Deployments是一种控制器，可以控制工作负载的副本数replicas，通过kube-controller-manager中的Deployments Controller实现副本数状态的控制。 1.3 服务访问 kubernetes中pod是实际运行的载体，pod依附于node中，node可能会出现故障，kubernetes的控制器如replicasets会在其他node上重新拉起一个pod，新的pod会分配一个新的IP；再者，应用部署时会包含多个副本replicas，如同个应用deployments部署了3个pod副本，pod相当于后端的Real Server，如何实现这三个应用访问呢？对于这种情况，我们一般会在Real Server前面加一个负载均衡Load Balancer，service就是pod的负载均衡调度器，service将动态的pod抽象为一个服务，应用程序直接访问service即可，service会自动将请求转发到后端的pod。负责service转发规则有两种机制：iptables和ipvs，iptables通过设置DNAT等规则实现负载均衡，ipvs通过ipvsadm设置转发规。 service概念 根据服务不同的访问方式，service分为如下几种类型：ClusterIP，NodePort，LoadBalancer和_ExternalName，可通过type设置。 ClusterIP，集群内部互访，与DNS结合实现集群内部的服务发现； NodePort，通过NAT将每个node节点暴露一个端口实现外部访问； LoadBalancer，实现云厂商外部接入方式的接口，需要依赖云服务提供商实现具体技术细节，如腾讯云实现与CLB集成； ExternalName，通过服务名字暴露服务名，当前可由ingress实现，将外部的请求以域名转发的形式转发到集群，需要依附具体的外部实现，如nginx，traefik,各大云计算厂商实现接入细节。 pod是动态变化的，ip地址可能会变化（如node故障），副本数可能会变化，如应用扩展scale up，应用锁容scale down等，service如何识别到pod的动态变化呢？答案是labels，通过labels自动会过滤出某个应用的Endpoints，当pod变化时会自动更新Endpoints，不同的应用会有由不同的label组成。labels相关可以参考下https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/ service与labels 2. 创建应用 我们开始部署一个应用即deployments，kubernetes中包含各种workload如无状态话的Deployments，有状态化的StatefulSets，守护进程的DaemonSets，美中workload对应不同的应用场景，我们先以Deployments为例入门，其他workload均以此类似，一般而言，在kubernetes中部署应用均以yaml文件方式部署，对于初学者而言，编写yaml文件太冗长，不适合初学，我们先kubectl命令行方式实现API的接入。 1、部署nginx应用，部署三个副本 [root@node-1 ~]# kubectl run nginx-app-demo --image=nginx:1.7.9 --port=80 --replicas=3 kubectl run --generator=deployment/apps.v1 is DEPRECATED and will be removed in a future version. Use kubectl run --generator=run-pod/v1 or kubectl create instead.deployment.apps/nginx-app-demo created 2、查看应用列表,可以看到当前pod的状态均已正常，Ready是当前状态，AVAILABLE是目标状态 [root@node-1 ~]# kubectl get deploymentsNAME READY UP-TO-DATE AVAILABLE AGEnginx-app-demo 3/3 3 3 72s 3、查看应用的详细信息,如下我们可以知道Deployments是通过ReplicaSets控制副本数的，由Replicaset控制pod数 [root@node-1 ~]# kubectl describe deployments nginx-app-demo Name: nginx-app-demo #应用名称Namespace: default #命名空间CreationTimestamp: Sun, 11 Aug 2019 21:52:32 +0800Labels: run=nginx-app-demo #labels，很重要，后续service通过labels实现访问Annotations: deployment.kubernetes.io/revision: 1 #滚动升级版本号Selector: run=nginx-app-demo #labels的选择器selectorReplicas: 3 desired | 3 updated | 3 total | 3 available | 0 unavailable #副本控制器StrategyType: RollingUpdate #升级策略为RollingUpdateMinReadySeconds: 0RollingUpdateStrategy: 25% max unavailable, 25% max surge #RollingUpdate升级策略，即最大不超过25%的podPod Template: #容器应用模版，包含镜像，port，存储等 Labels: run=nginx-app-demo Containers: nginx-app-demo: Image: nginx:1.7.9 Port: 80/TCP Host Port: 0/TCP Environment: &lt;none&gt; Mounts: &lt;none&gt; Volumes: <none>Conditions: #当前状态 Type Status Reason ---- ------ ------ Available True MinimumReplicasAvailable Progressing True NewReplicaSetAvailableOldReplicaSets: <none>NewReplicaSet: nginx-app-demo-7bdfd97dcd (3/3 replicas created) #ReplicaSets控制器名称Events: #运行事件 Type Reason Age From Message ---- ------ ---- ---- ------- Normal ScalingReplicaSet 3m24s deployment-controller Scaled up replica set nginx-app-demo-7bdfd97dcd to 3 4、查看replicasets情况，通过查看可知replicasets副本控制器生成了三个pod 1. 查看replicasets列表 [root@node-1 ~]# kubectl get replicasetsNAME DESIRED CURRENT READY AGEnginx-app-demo-7bdfd97dcd 3 3 3 9m9s 查看replicasets详情[root@node-1 ~]# kubectl describe replicasets nginx-app-demo-7bdfd97dcdName: nginx-app-demo-7bdfd97dcdNamespace: defaultSelector: pod-template-hash=7bdfd97dcd,run=nginx-app-demoLabels: pod-template-hash=7bdfd97dcd #labels，增加了一个hash的label识别replicasets run&#61;nginx-app-demo Annotations: deployment.kubernetes.io/desired-replicas: 3 #滚动升级的信息，副本树，最大数，应用版本 deployment.kubernetes.io/max-replicas: 4 deployment.kubernetes.io/revision: 1 Controlled By: Deployment/nginx-app-demo #副本的父控制，为nginx-app-demo这个DeploymentsReplicas: 3 current / 3 desiredPods Status: 3 Running / 0 Waiting / 0 Succeeded / 0 FailedPod Template: #容器模板，继承于deployments Labels: pod-template-hash=7bdfd97dcd run&#61;nginx-app-demo Containers: nginx-app-demo: Image: nginx:1.7.9 Port: 80/TCP Host Port: 0/TCP Environment: &lt;none&gt; Mounts: &lt;none&gt; Volumes: <none>Events: #事件日志，生成了三个不同的pod Type Reason Age From Message ---- ------ ---- ---- ------- Normal SuccessfulCreate 9m25s replicaset-controller Created pod: nginx-app-demo-7bdfd97dcd-hsrft Normal SuccessfulCreate 9m25s replicaset-controller Created pod: nginx-app-demo-7bdfd97dcd-qtbzd Normal SuccessfulCreate 9m25s replicaset-controller Created pod: nginx-app-demo-7bdfd97dcd-7t72x 5、查看pod的情况,实际应用部署的载体，pod中部署了一个nginx的容器并分配了一个ip，可通过该ip直接访问应用 1. 查看pod的列表，和replicasets生成的名称一致[root@node-1 ~]# kubectl get podsNAME READY STATUS RESTARTS AGEnginx-app-demo-7bdfd97dcd-7t72x 1/1 Running 0 13mnginx-app-demo-7bdfd97dcd-hsrft 1/1 Running 0 13mnginx-app-demo-7bdfd97dcd-qtbzd 1/1 Running 0 13m 查看pod的详情[root@node-1 ~]# kubectl describe pods nginx-app-demo-7bdfd97dcd-7t72x Name: nginx-app-demo-7bdfd97dcd-7t72xNamespace: defaultPriority: 0PriorityClassName: <none>Node: node-3/10.254.100.103Start Time: Sun, 11 Aug 2019 21:52:32 +0800Labels: pod-template-hash=7bdfd97dcd #labels名称 run&#61;nginx-app-demo Annotations: <none>Status: RunningIP: 10.244.2.4 #pod的ip地址Controlled By: ReplicaSet/nginx-app-demo-7bdfd97dcd #副本控制器为replicasetsContainers: #容器的信息，包括容器id，镜像，丢按扣，状态，环境变量等信息 nginx-app-demo: Container ID: docker://5a0e5560583c5929e9768487cef43b045af4c6d3b7b927d9daf181cb28867766 Image: nginx:1.7.9 Image ID: docker-pullable://nginx&#64;sha256:e3456c851a152494c3e4ff5fcc26f240206abac0c9d794affb40e0714846c451 Port: 80/TCP Host Port: 0/TCP State: Running Started: Sun, 11 Aug 2019 21:52:40 &#43;0800 Ready: True Restart Count: 0 Environment: &lt;none&gt; Mounts: /var/run/secrets/kubernetes.io/serviceaccount from default-token-txhkc (ro) Conditions: #容器的状态条件 Type Status Initialized True Ready True ContainersReady True PodScheduled True Volumes: #容器卷 default-token-txhkc: Type: Secret (a volume populated by a Secret) SecretName: default-token-txhkc Optional: false QoS Class: BestEffort #QOS类型Node-Selectors: <none> #污点类型Tolerations: node.kubernetes.io/not-ready:NoExecute for 300s node.kubernetes.io/unreachable:NoExecute for 300s Events: #事件状态，拉镜像，启动容器 Type Reason Age From Message ---- ------ ---- ---- ------- Normal Scheduled 14m default-scheduler Successfully assigned default/nginx-app-demo-7bdfd97dcd-7t72x to node-3 Normal Pulling 14m kubelet, node-3 Pulling image "nginx:1.7.9" Normal Pulled 14m kubelet, node-3 Successfully pulled image "nginx:1.7.9" Normal Created 14m kubelet, node-3 Created container nginx-app-demo Normal Started 14m kubelet, node-3 Started container nginx-app-demo 3. 访问应用 kubernetes为每个pod都分配了一个ip地址，可通过该地址直接访问应用，相当于访问RS，但一个应用是一个整体，由多个副本数组成，需要依赖于service来实现应用的负载均衡，service我们探讨ClusterIP和NodePort的访问方式。 1、设置pod的内容，为了方便区分，我们将三个pod的nginx站点内容设置为不同，以观察负载均衡的效果 查看pod列表[root@node-1 ~]# kubectl get podsNAME READY STATUS RESTARTS AGEnginx-app-demo-7bdfd97dcd-7t72x 1/1 Running 0 28mnginx-app-demo-7bdfd97dcd-hsrft 1/1 Running 0 28mnginx-app-demo-7bdfd97dcd-qtbzd 1/1 Running 0 28m 进入pod容器中[root@node-1 ~]# kubectl exec -it nginx-app-demo-7bdfd97dcd-7t72x /bin/bash 设置站点内容[root@nginx-app-demo-7bdfd97dcd-7t72x:/# echo "web1" >/usr/share/nginx/html/index.html 以此类推设置另外两个pod的内容为web2和web3[root@nginx-app-demo-7bdfd97dcd-hsrft:/# echo web2 >/usr/share/nginx/html/index.html[root@nginx-app-demo-7bdfd97dcd-qtbzd:/# echo web3 >/usr/share/nginx/html/index.html 2、获取pod的ip地址，如何快速获取pod的ip地址呢，可以通过-o wide参数显示更多的内容,会包含pod所属node和ip [root@node-1 ~]# kubectl get pods -o wide NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATESnginx-app-demo-7bdfd97dcd-7t72x 1/1 Running 0 34m 10.244.2.4 node-3 <none> <none>nginx-app-demo-7bdfd97dcd-hsrft 1/1 Running 0 34m 10.244.1.2 node-2 <none> <none>nginx-app-demo-7bdfd97dcd-qtbzd 1/1 Running 0 34m 10.244.1.3 node-2 <none> <none> 3、访问pod的ip，查看站点内容,不同的pod站点内容和上述步骤设置一致。 [root@node-1 ~]# curl http://10.244.2.4web1[root@node-1 ~]# curl http://10.244.1.2web2[root@node-1 ~]# curl http://10.244.1.3web3 3.1 ClusterIP访问 通过pod的ip直接访问应用，对于单个pod的应用可以实现，对于多个副本replicas的应用则不符合要求，需要通过service来实现负载均衡，service需要设置不同的type，默认为ClusterIP即集群内部访问，如下通过expose子命令将服务暴露到service。 1、暴露service,其中port表示代理监听端口，target-port代表是容器的端口，type设置的是service的类型 [root@node-1 ~]# kubectl expose deployment nginx-app-demo --name nginx-service-demo \--port=80 \--protocol=TCP \--target-port=80 \--type ClusterIP service/nginx-service-demo exposed 2、查看service的详情，可以看到service通过labels选择器selector自动将pod的ip生成endpoints 查看service列表，显示有两个，kubernetes为默认集群创建的service[root@node-1 ~]# kubectl get servicesNAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGEkubernetes ClusterIP 10.96.0.1 <none> 443/TCP 29hnginx-service-demo ClusterIP 10.102.1.1 <none> 80/TCP 2m54s 查看service详情，可以看到Labels的Seletor和前面Deployments设置一致，Endpoints将pod组成一个列表[root@node-1 ~]# kubectl describe services nginx-service-demo Name: nginx-service-demo #名称Namespace: default #命名空间Labels: run=nginx-app-demo #标签名称Annotations: <none>Selector: run=nginx-app-demo #标签选择器Type: ClusterIP #service类型为ClusterIPIP: 10.102.1.1 #服务的ip，即vip，集群内部会自动分配一个Port: <unset> 80/TCP #服务端口，即ClusterIP对外访问的端口TargetPort: 80/TCP #容器端口Endpoints: 10.244.1.2:80,10.244.1.3:80,10.244.2.4:80 #访问地址列表Session Affinity: None #负载均衡调度算法Events: <none> 3、访问service的地址，可以访问的内容可知，service自动实现了pods的负载均衡，调度策略为轮询，为何？因为service默认的调度策略Session Affinity为None，即是轮训，可以设置为ClientIP，实现会话保持，相同客户端IP的请求会调度到相同的pod上。 [root@node-1 ~]# curl http://10.102.1.1web3[root@node-1 ~]# curl http://10.102.1.1web1[root@node-1 ~]# curl http://10.102.1.1web2[root@node-1 ~]# curl http://10.102.1.1 4、ClusterIP原理深入剖析，service后端实现有两种机制：iptables和ipvs，环境安装采用iptables，iptables通过nat的链生成访问规则，KUBE-SVC-R5Y5DZHD7Q6DDTFZ为入站DNAT转发规则，KUBE-MARK-MASQ为出站转发 [root@node-1 ~]# iptables -t nat -L -nChain KUBE-SERVICES (2 references)target prot opt source destination KUBE-MARK-MASQ tcp -- !10.244.0.0/16 10.102.1.1 / default/nginx-service-demo: cluster IP / tcp dpt:80KUBE-SVC-R5Y5DZHD7Q6DDTFZ tcp -- 0.0.0.0/0 10.102.1.1 / default/nginx-service-demo: cluster IP / tcp dpt:80 出站：KUBE-MARK-MASQ源地址段不是10.244.0.0/16访问10.102.1.1的目标端口80时，将请求转发给KUBE-MARK-MASQ链入站：KUBE-SVC-R5Y5DZHD7Q6DDTFZ任意原地址访问目标10.102.1.1的目标端口80时将请求转发给KUBE-SVC-R5Y5DZHD7Q6DDTFZ链 5、查看入站请求规则，入站请求规则将会映射到不同的链，不同链将会转发到不同pod的ip上。 1. 查看入站规则KUBE-SVC-R5Y5DZHD7Q6DDTFZ，请求将转发至三条链[root@node-1 ~]# iptables -t nat -L KUBE-SVC-R5Y5DZHD7Q6DDTFZ -nChain KUBE-SVC-R5Y5DZHD7Q6DDTFZ (1 references)target prot opt source destination KUBE-SEP-DSWLUQNR4UPH24AX all -- 0.0.0.0/0 0.0.0.0/0 statistic mode random probability 0.33332999982KUBE-SEP-56SLMGHHOILJT36K all -- 0.0.0.0/0 0.0.0.0/0 statistic mode random probability 0.50000000000KUBE-SEP-K6G4Z74HQYF6X7SI all -- 0.0.0.0/0 0.0.0.0/0 2. 查看实际转发的三条链的规则,实际映射到不同的pod的ip地址上[root@node-1 ~]# iptables -t nat -L KUBE-SEP-DSWLUQNR4UPH24AX -nChain KUBE-SEP-DSWLUQNR4UPH24AX (1 references)target prot opt source destination KUBE-MARK-MASQ all -- 10.244.1.2 0.0.0.0/0 DNAT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp to:10.244.1.2:80 [root@node-1 ~]# iptables -t nat -L KUBE-SEP-56SLMGHHOILJT36K -nChain KUBE-SEP-56SLMGHHOILJT36K (1 references)target prot opt source destination KUBE-MARK-MASQ all -- 10.244.1.3 0.0.0.0/0 DNAT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp to:10.244.1.3:80 [root@node-1 ~]# iptables -t nat -L KUBE-SEP-K6G4Z74HQYF6X7SI -nChain KUBE-SEP-K6G4Z74HQYF6X7SI (1 references)target prot opt source destination KUBE-MARK-MASQ all -- 10.244.2.4 0.0.0.0/0 DNAT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp to:10.244.2.4:80 3.2 NodePort访问 Service通过ClusterIP只能提供集群内部的应用访问，外部无法直接访问应用，如果需要外部访问有如下几种方式：NodePort，LoadBalancer和Ingress，其中LoadBalancer需要由云服务提供商实现，Ingress需要安装单独的Ingress Controller，日常测试可以通过NodePort的方式实现，NodePort可以将node的某个端口暴露给外部网络访问。 1、修改type的类型由ClusterIP修改为NodePort类型（或者重新创建，指定type的类型为NodePort） 1. 通过patch修改type的类型[root@node-1 ~]# kubectl patch services nginx-service-demo -p '{"spec":{"type": "NodePort"}}'service/nginx-service-demo patched 2. 确认yaml文件配置，分配了一个NodePort端口，即每个node上都会监听该端口[root@node-1 ~]# kubectl get services nginx-service-demo -o yamlapiVersion: v1kind: Servicemetadata: creationTimestamp: "2019-08-11T14:35:59Z" labels: run: nginx-app-demo name: nginx-service-demo namespace: default resourceVersion: "157676" selfLink: /api/v1/namespaces/default/services/nginx-service-demo uid: 55e29b78-bc45-11e9-b073-525400490421spec: clusterIP: 10.102.1.1 externalTrafficPolicy: Cluster ports: nodePort: 32416 #自动分配了一个NodePort端口 port: 80 protocol: TCP targetPort: 80selector: run: nginx-app-demosessionAffinity: Nonetype: NodePort #类型修改为NodePortstatus: loadBalancer: {} 3. 查看service列表，可以知道service的type已经修改为NodePort,同时还保留ClusterIP的访问IP[root@node-1 ~]# kubectl get servicesNAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGEkubernetes ClusterIP 10.96.0.1 <none> 443/TCP 30hnginx-service-demo NodePort 10.102.1.1 <none> 80:32416/TCP 68m 2、通过NodePort访问应用程序,每个node的地址相当于vip，可以实现相同的负载均衡效果，同时CluserIP功能依可用 1. NodePort的负载均衡[root@node-1 ~]# curl http://node-1:32416web1[root@node-1 ~]# curl http://node-2:32416web1[root@node-1 ~]# curl http://node-3:32416web1[root@node-1 ~]# curl http://node-3:32416web3[root@node-1 ~]# curl http://node-3:32416web2 ClusterIP的负载均衡[root@node-1 ~]# curl http://10.102.1.1web2[root@node-1 ~]# curl http://10.102.1.1web1[root@node-1 ~]# curl http://10.102.1.1web1[root@node-1 ~]# curl http://10.102.1.1web3 3、NodePort转发原理，每个node上通过kube-proxy监听NodePort的端口，由后端的iptables实现端口的转发 1. NodePort监听端口[root@node-1 ~]# netstat -antupl |grep 32416tcp6 0 0 :::32416 :::* LISTEN 32052/kube-proxy 2. 查看nat表的转发规则，有两条规则KUBE-MARK-MASQ出口和KUBE-SVC-R5Y5DZHD7Q6DDTFZ入站方向。Chain KUBE-NODEPORTS (1 references)target prot opt source destination KUBE-MARK-MASQ tcp -- 0.0.0.0/0 0.0.0.0/0 / default/nginx-service-demo: / tcp dpt:32416KUBE-SVC-R5Y5DZHD7Q6DDTFZ tcp -- 0.0.0.0/0 0.0.0.0/0 / default/nginx-service-demo: / tcp dpt:32416 3. 查看入站的请求规则链KUBE-SVC-R5Y5DZHD7Q6DDTFZ [root@node-1 ~]# iptables -t nat -L KUBE-SVC-R5Y5DZHD7Q6DDTFZ -nChain KUBE-SVC-R5Y5DZHD7Q6DDTFZ (2 references)target prot opt source destination KUBE-SEP-DSWLUQNR4UPH24AX all -- 0.0.0.0/0 0.0.0.0/0 statistic mode random probability 0.33332999982KUBE-SEP-56SLMGHHOILJT36K all -- 0.0.0.0/0 0.0.0.0/0 statistic mode random probability 0.50000000000KUBE-SEP-K6G4Z74HQYF6X7SI all -- 0.0.0.0/0 0.0.0.0/0 4. 继续查看转发链，包含有DNAT转发和KUBE-MARK-MASQ和出站返回的规则[root@node-1 ~]# iptables -t nat -L KUBE-SEP-DSWLUQNR4UPH24AX -nChain KUBE-SEP-DSWLUQNR4UPH24AX (1 references)target prot opt source destination KUBE-MARK-MASQ all -- 10.244.1.2 0.0.0.0/0 DNAT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp to:10.244.1.2:80 [root@node-1 ~]# iptables -t nat -L KUBE-SEP-56SLMGHHOILJT36K -nChain KUBE-SEP-56SLMGHHOILJT36K (1 references)target prot opt source destination KUBE-MARK-MASQ all -- 10.244.1.3 0.0.0.0/0 DNAT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp to:10.244.1.3:80 [root@node-1 ~]# iptables -t nat -L KUBE-SEP-K6G4Z74HQYF6X7SI -nChain KUBE-SEP-K6G4Z74HQYF6X7SI (1 references)target prot opt source destination KUBE-MARK-MASQ all -- 10.244.2.4 0.0.0.0/0 DNAT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp to:10.244.2.4:80 4. 扩展应用 当应用程序的负载比较高无法满足应用请求时，一般我们会通过扩展RS的数量来实现，在kubernetes中，扩展RS实际上通过扩展副本数replicas来实现，扩展RS非常便利，快速实现弹性伸缩。kubernets能提供两种方式的伸缩能力：1. 手动伸缩能力scale up和scale down，2. 动态的弹性伸缩horizontalpodautoscalers,基于CPU的利用率实现自动的弹性伸缩，需要依赖与监控组件如metrics server，当前未实现，后续再做深入探讨，本文以手动的scale的方式扩展应用的副本数。 Deployments副本扩展 1、手动扩展副本数 [root@node-1 ~]# kubectl scale --replicas=4 deployment nginx-app-demo deployment.extensions/nginx-app-demo scaled 2、查看副本扩展情况,deployments自动部署一个应用 [root@node-1 ~]# kubectl get deploymentsNAME READY UP-TO-DATE AVAILABLE AGEnginx-app-demo 4/4 4 4 133m 3、此时service的情况会怎样呢？查看service详情,新扩展的pod会自动更新到service的endpoints中，自动服务发现 查看service详情[root@node-1 ~]# kubectl describe services nginx-service-demo Name: nginx-service-demoNamespace: defaultLabels: run=nginx-app-demoAnnotations: <none>Selector: run=nginx-app-demoType: NodePortIP: 10.102.1.1Port: <unset> 80/TCPTargetPort: 80/TCPNodePort: <unset> 32416/TCPEndpoints: 10.244.1.2:80,10.244.1.3:80,10.244.2.4:80 + 1 more...#地址已自动加入Session Affinity: NoneExternal Traffic Policy: ClusterEvents: <none> 查看endpioints详情[root@node-1 ~]# kubectl describe endpoints nginx-service-demo Name: nginx-service-demoNamespace: defaultLabels: run=nginx-app-demoAnnotations: endpoints.kubernetes.io/last-change-trigger-time: 2019-08-11T16:04:56ZSubsets: Addresses: 10.244.1.2,10.244.1.3,10.244.2.4,10.244.2.5 NotReadyAddresses: <none> Ports: Name Port Protocol ---- ---- -------- &lt;unset&gt; 80 TCP Events: <none> 4、测试，将新加入的pod站点内容设置为web4，参考前面的设置方法，测试service的ip，查看负载均衡效果 [root@node-1 ~]# curl http://10.102.1.1web4[root@node-1 ~]# curl http://10.102.1.1web4[root@node-1 ~]# curl http://10.102.1.1web2[root@node-1 ~]# curl http://10.102.1.1web3[root@node-1 ~]# curl http://10.102.1.1web1[root@node-1 ~]# curl http://10.102.1.1web2[root@node-1 ~]# curl http://10.102.1.1web1 由此可知，弹性伸缩会自动自动加入到service中实现服务自动发现和负载均衡，应用的扩展相比于传统应用快速非常多。此外，kubernetes还支持自动弹性扩展的能力，即Horizontal Pod AutoScaler，自动横向伸缩能力，配合监控系统根据CPU的利用率弹性扩展Pod个数，详情可以参考文档kubernetes系列教程(十九)使用metric-server让HPA弹性伸缩愉快运行 5. 滚动升级 在kubernetes中更新应用程序时可以将应用程序打包到镜像中，然后更新应用程序的镜像以实现升级。默认Deployments的升级策略为RollingUpdate，其每次会更新应用中的25%的pod，新建新的pod逐个替换，防止应用程序在升级过程中不可用。同时，如果应用程序升级过程中失败，还可以通过回滚的方式将应用程序回滚到之前的状态，回滚时通过replicasets的方式实现。 滚动更新 1、更换nginx的镜像，将应用升级至最新版本,打开另外一个窗口使用kubectl get pods -w观察升级过程 [root@node-1 ~]# kubectl set image deployments/nginx-app-demo nginx-app-demo=nginx:latestdeployment.extensions/nginx-app-demo image updated 2、观察升级过程，通过查看可知，升级过程中是通过新建+删除的方式逐个替换pod的方式 [root@node-1 ~]# kubectl get pods -wNAME READY STATUS RESTARTS AGEnginx-app-demo-7bdfd97dcd-7t72x 1/1 Running 0 145mnginx-app-demo-7bdfd97dcd-hsrft 1/1 Running 0 145mnginx-app-demo-7bdfd97dcd-j6lgd 1/1 Running 0 12mnginx-app-demo-7bdfd97dcd-qtbzd 1/1 Running 0 145mnginx-app-demo-5cc8746f96-xsxz4 0/1 Pending 0 0s #新建一个podnginx-app-demo-5cc8746f96-xsxz4 0/1 Pending 0 0snginx-app-demo-7bdfd97dcd-j6lgd 1/1 Terminating 0 14m #删除旧的pod，替换nginx-app-demo-5cc8746f96-xsxz4 0/1 ContainerCreating 0 0snginx-app-demo-5cc8746f96-s49nv 0/1 Pending 0 0s #新建第二个podnginx-app-demo-5cc8746f96-s49nv 0/1 Pending 0 0snginx-app-demo-5cc8746f96-s49nv 0/1 ContainerCreating 0 0snginx-app-demo-7bdfd97dcd-j6lgd 0/1 Terminating 0 14m #更换第二个podnginx-app-demo-5cc8746f96-s49nv 1/1 Running 0 7snginx-app-demo-7bdfd97dcd-qtbzd 1/1 Terminating 0 146mnginx-app-demo-5cc8746f96-txjqh 0/1 Pending 0 0snginx-app-demo-5cc8746f96-txjqh 0/1 Pending 0 0snginx-app-demo-5cc8746f96-txjqh 0/1 ContainerCreating 0 0snginx-app-demo-7bdfd97dcd-j6lgd 0/1 Terminating 0 14mnginx-app-demo-7bdfd97dcd-j6lgd 0/1 Terminating 0 14mnginx-app-demo-5cc8746f96-xsxz4 1/1 Running 0 9snginx-app-demo-5cc8746f96-txjqh 1/1 Running 0 1snginx-app-demo-7bdfd97dcd-hsrft 1/1 Terminating 0 146mnginx-app-demo-7bdfd97dcd-qtbzd 0/1 Terminating 0 146mnginx-app-demo-5cc8746f96-rcpmw 0/1 Pending 0 0snginx-app-demo-5cc8746f96-rcpmw 0/1 Pending 0 0snginx-app-demo-5cc8746f96-rcpmw 0/1 ContainerCreating 0 0snginx-app-demo-7bdfd97dcd-7t72x 1/1 Terminating 0 146mnginx-app-demo-7bdfd97dcd-7t72x 0/1 Terminating 0 147mnginx-app-demo-7bdfd97dcd-hsrft 0/1 Terminating 0 147mnginx-app-demo-7bdfd97dcd-hsrft 0/1 Terminating 0 147mnginx-app-demo-5cc8746f96-rcpmw 1/1 Running 0 2snginx-app-demo-7bdfd97dcd-7t72x 0/1 Terminating 0 147mnginx-app-demo-7bdfd97dcd-7t72x 0/1 Terminating 0 147mnginx-app-demo-7bdfd97dcd-hsrft 0/1 Terminating 0 147mnginx-app-demo-7bdfd97dcd-hsrft 0/1 Terminating 0 147mnginx-app-demo-7bdfd97dcd-qtbzd 0/1 Terminating 0 147mnginx-app-demo-7bdfd97dcd-qtbzd 0/1 Terminating 0 147m 3、再次查看deployments的详情可知道，deployments已经更换了新的replicasets，原来的replicasets的版本为1，可用于回滚。 [root@node-1 ~]# kubectl describe deployments nginx-app-demo Name: nginx-app-demoNamespace: defaultCreationTimestamp: Sun, 11 Aug 2019 21:52:32 +0800Labels: run=nginx-app-demoAnnotations: deployment.kubernetes.io/revision: 2 #新的版本号，用于回滚Selector: run=nginx-app-demoReplicas: 4 desired | 4 updated | 4 total | 4 available | 0 unavailableStrategyType: RollingUpdateMinReadySeconds: 0RollingUpdateStrategy: 25% max unavailable, 25% max surgePod Template: Labels: run=nginx-app-demo Containers: nginx-app-demo: Image: nginx:latest Port: 80/TCP Host Port: 0/TCP Environment: &lt;none&gt; Mounts: &lt;none&gt; Volumes: <none>Conditions: Type Status Reason ---- ------ ------ Available True MinimumReplicasAvailable Progressing True NewReplicaSetAvailableOldReplicaSets: <none>NewReplicaSet: nginx-app-demo-5cc8746f96 (4/4 replicas created) #新的replicaset，实际是替换新的replicasetsEvents: Type Reason Age From Message ---- ------ ---- ---- ------- Normal ScalingReplicaSet 19m deployment-controller Scaled up replica set nginx-app-demo-7bdfd97dcd to 4 Normal ScalingReplicaSet 4m51s deployment-controller Scaled up replica set nginx-app-demo-5cc8746f96 to 1 Normal ScalingReplicaSet 4m51s deployment-controller Scaled down replica set nginx-app-demo-7bdfd97dcd to 3 Normal ScalingReplicaSet 4m51s deployment-controller Scaled up replica set nginx-app-demo-5cc8746f96 to 2 Normal ScalingReplicaSet 4m43s deployment-controller Scaled down replica set nginx-app-demo-7bdfd97dcd to 2 Normal ScalingReplicaSet 4m43s deployment-controller Scaled up replica set nginx-app-demo-5cc8746f96 to 3 Normal ScalingReplicaSet 4m42s deployment-controller Scaled down replica set nginx-app-demo-7bdfd97dcd to 1 Normal ScalingReplicaSet 4m42s deployment-controller Scaled up replica set nginx-app-demo-5cc8746f96 to 4 Normal ScalingReplicaSet 4m42s deployment-controller Scaled down replica set nginx-app-demo-7bdfd97dcd to 0 4、查看滚动升级的版本，可以看到有两个版本，分别对应的两个不同的replicasets [root@node-1 ~]# kubectl rollout history deployment nginx-app-demo deployment.extensions/nginx-app-demo REVISION CHANGE-CAUSE1 <none>2 <none> 查看replicasets列表,旧的包含pod为0[root@node-1 ~]# kubectl get replicasetsNAME DESIRED CURRENT READY AGEnginx-app-demo-5cc8746f96 4 4 4 9m2snginx-app-demo-7bdfd97dcd 0 0 0 155m 5、测试应用的升级情况,发现nginx已经升级到最新nginx/1.17.2版本 [root@node-1 ~]# curl -I http://10.102.1.1HTTP/1.1 200 OKServer: nginx/1.17.2 #nginx版本信息Date: Sun, 11 Aug 2019 16:30:03 GMTContent-Type: text/htmlContent-Length: 612Last-Modified: Tue, 23 Jul 2019 11:45:37 GMTConnection: keep-aliveETag: "5d36f361-264"Accept-Ranges: bytes 6、回滚到旧的版本 [root@node-1 ~]# kubectl rollout undo deployment nginx-app-demo --to-revision=1deployment.extensions/nginx-app-demo rolled back 再次测应用,已经回滚到旧版本。[root@node-1 ~]# curl -I http://10.102.1.1HTTP/1.1 200 OKServer: nginx/1.7.9Date: Sun, 11 Aug 2019 16:34:33 GMTContent-Type: text/htmlContent-Length: 612Last-Modified: Tue, 23 Dec 2014 16:25:09 GMTConnection: keep-aliveETag: "54999765-264"Accept-Ranges: bytes 6. 故障迁移 故障迁移 集群中的node节点物理服务器可能会因为各种原因导致机器不可用，如硬件故障，软件故障，网络故障等原因，当发生故障时容器可能会出现不可用，进而影响业务的使用。kubernetes内置已提供了应用的容错能力，通过工作负载Workload如Deployments，StatefulSets来控制，当node节点异常时会自动将其上的pod迁移至其他node节点上，保障应用的高可用。 Kubeadm默认部署的集群，默认当节点异常时，需要5min后才能迁移，因为默认pod中设置了污点容忍tolerations，当检测到节点状态是not-ready或者unreachable时，容忍tolerationSeconds时长300s后才做驱逐，如下是看pod详情中设置的污点容忍信息 tolerations: effect: NoExecute key: node.kubernetes.io/not-ready operator: Exists tolerationSeconds: 300effect: NoExecute key: node.kubernetes.io/unreachable operator: Exists tolerationSeconds: 300 如下是手动创建的yaml文件，通过调整污点容忍的时长为2s，当节点异常时，其上的pod能够实现快速迁移到其他node节点 apiVersion: apps/v1kind: Deploymentmetadata: labels: run: test name: testspec: replicas: 3 selector: matchLabels: run: test template: metadata: labels: run: test spec: containers: - image: nginx:1.7.9 name: test ports: - containerPort: 3 resources: {} tolerations: - effect: NoExecute key: node.kubernetes.io/not-ready operator: Exists tolerationSeconds: 2 - effect: NoExecute key: node.kubernetes.io/unreachable operator: Exists tolerationSeconds: 2 </code></pre> 写在最后 本文以命令行的方式实践探索kubernetes中涉及的最重要的几个概念：应用部署，负载均衡，弹性伸缩和滚动升级，故障迁移，并以命令行的形式实际操作，读者可以参照文档实现快速入门，后续会大部分以yaml文件的形式部署和kubernets交互。 云服务器ECS地址：阿里云·云小站
-
发表了文章 2020-09-30
编程语言排行榜 - 2020年度最热门编程语言盘点！
如今，广大用户更喜欢利用移动应用程序，来获取他们所关心的产品与信息。而移动应用程序也成为了企业在市场竞争中，保持领先地位的成功关键。据某项调查预测：到2020年，全英国移动应用的用户下载数量将增加到200亿次。当然，随着区块链和物联网技术的不断集成与迭代，移动应用程序的高使用率反而催生了该领域开发服务的需求猛增。 工欲善其事，必先利其器。业务需求的满足，离不开移动应用框架、工具和编程语言。为了简化和加快整个开发进程，下面让我们一起来探究一下，那些对于移动应用开发人员和业务服务来说，至关重要且需要谨慎选择的最佳编程语言。 Java 作为Android应用程序开发的官方语言，Java这一通用编程语言又焕发了第二春。目前，Google和其他庞大的开发者活跃社区都能够支持该语言。通过Java，开发人员可以编写出不同形式的类与对象代码。可以说，Java能够支持所有类型的Android编程需求，包括Web应用、桌面应用、客户端/服务器端应用、以及企业级应用。 首发日期：1995年5月23日 设计者：James Gosling 具有基于类和面向对象的属性 Kotlin 为了克服Java在Android编程方面的挑战与不足，Kotlin作为另一种Android编程语言应运而生。2019年5月7日，谷歌宣布：Kotlin编程语言现已成为了Android应用开发的首选语言。Kotlin的优势包括：减少了运行时(runtime)的崩溃，易于学习，且安全可靠。 由Jetbrains开发。 获得了Apache license 2.0 首发日期：2011年 具有互操作性 能够支持跨平台 是基于静态类型的通用编程语言。 Objective-C Objective-C是Apple推出的面向对象的主流通用编程语言。经历了专家严格测试的Objective-C，不但非常稳定，而且被称为最通用、最易学的Apple编程语言。 于1984年被推出设计者： Tom Love和Brad Cox 支持macOS、iOS和iPad OS等操作系统。 Swift Swift是一种现代化的Apple编程语言。它旨在与诸如：Apple Cocoa和Cocoa Touch等框架一起使用。在2019的WWDC期间，Apple宣布推出了SwiftUI，它针对所有Apple平台上的声明式UI结构设计，提供了同一个框架。为了克服Object-C所碰到的各种挑战，Swift经过了多层严格的研究与开发。 具有Apache License 由Apple推出 首次出现：2014年6月2日 被Apple用户十分看好 开放源代码快速易学能够被Core ML、AR套件、以及Vision框架等现代库所支持 C# 与Java类似，C#是一种通用的多范式(multi-paradigm)编程语言。此类编程语言有助于通过既定的语法，更加轻松地开发出相应的代码。同时，它还时常被开发人员用作结构化的编程语言。 由Microsoft开发 首次出现于2000年 设计者：Anders Hejlsberg 支持跨平台的实施方式 Python 作为另一种高级编程语言，Python因其能够提供更好的执行结果，以及更好的用户体验而广受欢迎。在iOS的应用开发过程中，我们可以使用该语言来创建各项后端功能函数和软件库。 由Guido van Rossum创建 1991年首次发布 开放源代码 基于机器学习和其他动态技术 JavaScript 通过与CSS、AJAX的协同使用，开发人员可以使用Javascript，来构建自己的移动应用程序。基于多模式语言的Javascript，能够支持面向对象的编程与功能实现。由于只需要一次性代码，便可以在多个平台(如Android和iOS)上启动，因此Javascript给开发者带来交互式的应用效果，以及对于跨平台开发的支持。 属于轻量级编程语言 首次出现：1995年12月4日 设计制作：Brendan Eich 基于原型的面向对象(object-orientation)方式 属于编译类程序语言 能够提供各种一流的功能 HTML5 HTML5可被用于构建基于Web的移动应用程序。它提供了包括多媒体支持，跨平台开发，更快的市场部署等多种功能。要想构建iOS之类的混合应用，开发人员可以将HTML5与CSS、或其他技术相集成。 总结 综上所述，我们在此为您罗列了本年度各位开发人员需要熟悉的、最受欢迎的各种编程语言。它们各有各的特点，因此我们需要在实际的开发任务中，充分利用它们的优势，合理选择，扬长避短。 云服务器ECS地址：阿里云·云小站
-
发表了文章 2020-09-29
阿里云弹性裸金属服务器是什么?如何选择？
阿里云弹性裸金属服务器是什么呢？阿里云弹性裸金属服务器（神龙）是阿里云提供的一款超强大的云计算服务器，其不仅具备云服务器弹性的特点，还具有物理机隔离和独占资源的优势。 阿里云弹性裸金属服务器（神龙）是基于阿里云完全自主研发的下一代虚拟化技术而打造的新型计算类服务器产品。与上一代虚拟化技术相比，下一代虚拟化技术的主要创新在于，不仅支持普通虚拟云服务器，而且全面支持嵌套虚拟化技术，保留了普通云服务器的资源弹性，并借助嵌套虚拟化技术保留了物理机的体验。 阿里云弹性裸金属服务器（神龙）的特点 用户独占计算资源作为一种云端弹性计算类产品，弹性裸金属服务器超越了当前时代下物理机级的性能和隔离性，使您独占计算资源，无虚拟化性能开销和特性损失。在CPU规格选择上支持8核、16核、32核、96核等多个规格，并支持超高主频实例。以8核产品为例，弹性裸金属服务器实例支持超高主频至3.7 GHz ~ 4.1 GHz，与同类产品相比，它可以让游戏以及金融类业务获得更好的性能和更快的响应。 加密计算安全性方面，弹性裸金属服务器除了具备物理隔离特性外，为了更好地保障您云上数据的安全性，弹性裸金属服务器采用了芯片级可信执行环境（Intel SGX），能确保加密数据只能在安全可信的环境中计算。这种芯片级的硬件安全保障相当于为您云上的数据提供了一个保险箱功能，您可以自己掌控数据加密和密钥保护的全部流程。详情请参见 SGX基础介绍。 兼容多种专有云弹性裸金属服务器兼顾物理机的性能优势、完整特性和 云服务器的管理便利、价格优势，它的推出进一步解决客户对高性能计算的强需求，更好地帮助客户搭建新型混合云。弹性裸金属服务器不仅具有虚拟机的灵活性和弹性，同时具备物理机的一切特性和优势，因此也具备再次虚拟化的能力，线下的专有云均可无缝平移到阿里云上，而不用担心嵌套虚拟化带来的性能开销，为客户上云提供一种新途径。 异构指令集处理器支持弹性裸金属服务器采用阿里云完全自主研发的虚拟化2.0技术，零成本支持ARM等其他指令集处理器。 阿里云弹性裸金属服务器（神龙）的实例规格 阿里云弹性裸金属服务器（神龙）的实例规格目前包括通用型弹性裸金属服务器ebmg5、 计算型弹性裸金属服务器ebmc4、高主频型弹性裸金属服务器 ebmhfg5。 阿里云弹性裸金属服务器常见问题有哪些？ 什么是弹性裸金属服务器？ 弹性裸金属服务器和传统云主机（虚拟机）和传统物理机有何本质区别？ 弹性裸金属服务器有哪些全球领先的技术创新？ 弹性裸金属服务器为客户您带来什么价值？ 弹性裸金属服务器的网络性能怎么样？ 弹性裸金属服务器支持哪些的磁盘类型有哪些？可以挂载多少块数据盘？ 如何创建弹性裸金属服务器实例？ 弹性裸金属服务器支持哪些系统镜像？ 弹性裸金属服务器是否支持规格变配和宕机迁移？ 更多参考阿里云文档 弹性裸金属服务器和SCC与物理机、虚拟机对比。Y表示支持，N表示不支持，N/A表示无数据。 功能分类 功能 弹性裸金属服务器/SCC 物理机 虚拟机 运维自动化 分钟级交付 Y N Y 计算 无性能损失 Y Y N 无特性损失 Y Y N 资源无争抢 Y Y N 存储 完全兼容ECS云盘系统 Y N Y 使用云盘（系统盘）启动 Y N Y 系统盘快速重置 Y N Y 使用云服务器ECS的镜像 Y N Y 物理机和虚拟机之间相互冷迁移 Y N Y 免操作系统安装 Y N Y 免本地RAID，提供更高云盘数据保护 Y N Y 网络 完全兼容ECS VPC网络 Y N Y 完全兼容ECS经典网络 Y N Y 物理机集群和虚拟机集群间VPC无通信瓶颈 Y N Y 管控 完全兼容ECS现有管控系统 Y N Y VNC等用户体验和虚拟机保持一致 Y N Y 带外网络安全 Y N N/A 点击直达阿里云官网弹性裸金属服务器（神龙）购买地址 云服务器ECS地址：阿里云·云小站
-
发表了文章 2020-09-29
为什么要购买阿里云服务器？云服务器用途有哪些？
很多人问，为什么要购买阿里云服务器呢？阿里云服务器用途有哪些？以前，当我们需要建个新的网站时，是非常麻烦且繁琐的一件事情，这意味着除了需要花大价钱买服务器外，还需要部署、测试、验证等一系列操作。而在云服务器出现之后，这些就都不是问题了。 在国内所有云服务器中，最稳定的就属阿里云服务器了，今天我们具体阿里云服务器可以干嘛？八大用途你都知道吗？ 一、网站搭建 不管针对个人还是企业而言，云服务器现阶段全是十分便捷的建立网站武器。因为它有着对外开放独立的主机IP，有利于实时监控与管理方法，另外还能出示一键设置的电脑操作系统，为我们试错提供了绝佳的机会。云服务器适用好几个集成化自然环境如宝塔、LNMP、LAMP等，那样有利于迅速实行安裝;并且还支持多宽芾挑选等資源拓展，进而可以完成群集内的延展性伸缩式;含有多种多样CMS建网站能用模版，有益于节省经营成本提高工作效率。 与个人用云服务器不一样的是，公司布署门户网址专用型的云服务器，BGP网络的可靠性要高过建造机房的单线互联网，终究企业官网的可靠性一定水平上体现出了公司的用户评价品牌形象，并且公司的信息量较大，云服务器既可用以储存数据信息，也可完成线上数据加载和共享资源，十分便捷。 二、构建自己的邮件服务器 应用自己的网站域名的邮件服务器，不用多少运行内存，尽管构建自己的邮箱服务器很厉害,可是我不会建议自己构建邮箱服务器。第三方的公司邮箱服务项目(例如:腾讯企业邮箱，阿里巴巴公司邮箱)早已彻底能够 满足你的要求!为何也要自己构建? 一般电子邮箱推送的电子邮件量挺大的情况下，总数便会被限定假如做网络产品营销推广和新闻报道消息提醒，推送的电子邮件量十分大，就必须自己构建邮政局网络服务器 三、外汇交易美股交易 云服务器还能用在外汇投资.上，做买卖的人，都担忧订单信息实行被延迟时间，害怕要提交订单或要交易量的情况下系统软件断开连接，选用云服务器，能够 远程桌面连接到买卖大数据中心，就可以合理减少买卖中的延迟时间，订单信息解决会变得快速。可是，有着金融业与技术相结合的逻辑思维，却确实不容易。 有下列特性:随时买卖，不用忧虑关闭电源难题，靠谱的安全系数，减少延迟时间、降低滑点的造成,程序化买卖的关键辅助软件 四、搭建私有云盘 中国网盘安全系数,可靠性都有待提高!如今较为时兴的私有云盘系统软件是seafile、owncloud!这里强烈推荐seafile。个人/企业云盘，构建网盘的I具备二种Seafilenextcould 你将有着一个归属于自己的nas,多服务平台同歩，版本控制,在线协作服务平台:在线文档编辑评价,Wiki,信息本地下载即然是免费 下载，为什么是离线? 把资源下载到云服务器网络服务器上，再根据FTP免费下载到当地为什么不立即下载? 网络速度被限定啊，并不是vip会员,呵,就缓缓挂慢慢等吧，上行带宽也是限定啊,你觉得家里下载文件极快,那提交呢?相互配合aria2也可以全自动上传入百度云盘。 五、在线爬虫 想让网络爬虫二十四小时不断的工作中?用自己的笔记本电脑或是PC不过不是太实际,有云服务器就可以让网络爬虫二十四小时都工作中，--天爬个上万个网页页面没有问题. 又叫网络蜘蛛，网络爬虫能做的事儿十分多，自动化技术获得海量信息信息内容，保存图片/视頻,文档等資源数据爬虫，HR想爬取招聘平台的个人简历，手机号，想租间新房子融合房地产网站中地图自动化技术剖析最佳竞争对手的商业数据分析和监控器 六、自助式备份数据 把网址或是网络爬虫抓取到的网页页面或是其他关键材料,设定按时一键备份到阿里云服务器。 七、小程序 中国的云服务器,这儿谈及阿里云服务器和腾讯云服务其保证的镜像系统能够 立即布署各种各样使用如wordpress网址，可以用一键生成blog微信小程序，不过更丰富作用的小程序或app后台管理，应用开源系统的wp软件,能够 迅速转化成微信小程序 八，营销推广智能机器人 根据itchat/wechat的微信机器人API，各种各样chatbot:qqbnot/telegrambot/及其weibobot 让自动化技术的实际操作和沟通交流提高工作效率,以洗脸盆智能机器人为例子 1.全自动回复疑难问题，省时省力 2.提高贴文碰触率，完全免费曝出 3.搜集客户信息，群发消息 云服务器ECS地址：阿里云·云小站
-
发表了文章 2020-09-29
有哪些常用的 Python 标准库？
1、提供了不少与操作系统相关联的函数库os； os包是Python与操作系统的接口。我们可以用os包来实现操作系统的许多功能，比如管理系统进程，改变当前路径(相当于’cd‘)，改变文件权限等，建立。但要注意，os包是建立在操作系统的平台上的，许多功能在Windows系统上是无法实现的。另外，在使用os包中，要注意其中的有些功能已经被其他的包取代。 我们通过文件系统来管理磁盘上储存的文件。查找、删除，复制文件，以及列出文件列表等都是常见的文件操作。这些功能经常可以在操作系统中看到（比如ls, mv, cp等Linux命令），但现在可以通过Python标准库中的glob包、shutil包、os.path包、以及os包的一些函数等，在Python内部实现。 2、通常用于命令行参数的库sys； sys包被用于管理Python自身的运行环境。Python是一个解释器(interpreter), 也是一个运行在操作系统上的程序。我们可以用sys包来控制这一程序运行的许多参数，比如说Python运行所能占据的内存和CPU， Python所要扫描的路径等。另一个重要功能是和Python自己的命令行互动，从命令行读取命令和参数。 3、用于生成随机数的random库； Python标准库中的random函数，可以生成随机浮点数、整数、字符串，甚至帮助你随机选择列表序 列中的一个元素，打乱一组数据等。 4、math库提供了数学常数和数学函数； 标准库中，Python定义了一些新的数字类型(decimal包, fractions包), 以弥补之前的数字类型(integer, float)可能的不足。标准库还包含了random包，用于处理随机数相关的功能（产生随机数，随机取样等）。math包补充了一些重要的数学常数和数学函数，比如pi，三角函数等等。 (尽管numpy并不是标准库中的包，但它的数组运算的良好支持，让它在基于Python的科研和计算方面得到相当广泛的应用，可以适当关注。) 5、日期和时间的操作库datetime。 日期和时间的管理并不复杂，但容易犯错。Python的标准库中对日期和时间的管理颇为完善（利用time包管理时间，利用datetime包管理日期和时间），你不仅可以进行日期时间的查询和变换（比如：2012年7月18日对应的是星期几），还可以对日期时间进行运算(比如2000.1.1 13:00的378小时之后是什么日期，什么时间)。通过这些标准库，还可以根据需要控制日期时间输出的文本格式(比如：输出’2012-7-18‘还是'18 Jul 2012') 云服务器ECS地址：阿里云·云小站
-
发表了文章 2020-09-29
买了阿里云服务器怎么用？六步完成部署网站
很多新手在买了阿里云服务器知道不太清楚具体如何使用，要如何部署网站，下面为大家详解： 第一步：安装网站程序建站的第一部就是先有一套完整的网站程序，知道如何建站，如果不是自己建站的话，那先把要求告诉对方，根据需求对方会选择开发语言、数据库类型及合适的运行环境来建站。第二步：购买服务器 这里推荐大家阅读：阿里云服务器新手教程—购买与配置篇第三步：搭建运行环境需要部署网站首先要保障服务器上安装web容器，常用的web容器有IIS、tomcat、apache、nginx，以上四种web服务除了IIS之外，其余均可以在windows或linux系统下运行；除了web容器外，我们还需要部署程序运行环境，常见的如PHP、java、python等，asp的站点可以直接使用IIS；最后我们就要安装数据库，常用的数据库如mysql、ms sql等等；当然也可以选择集成环境，例如LNMP、LAMP、宝塔面板等。 第四步：网站上传将做好的网站程序上传到服务器上，同时需要在web容器中进行路径绑定和域名绑定，如果在安装数据库时设置了独立的密码，这里也需要在程序连接数据库的文件中修改一下数据库连接字符串，包括IP地址（127.0.0.1或数据库服务器的IP地址）、账号和密码等； 第五步：备案一般服务器分为内地服务器、香港服务器及国外服务器，国外服务器和香港服务器是可以不用备案的，如果你购买的是内地服务器就需要备案了，因为只有备案通过了，你的域名才能解析到内地服务器的公网ip上。 备案一般需要15个工作日左右，所以建议备案先做；至于备案这块要求域名实名认证主体与备案主体一致，按照官方的备案流程填写备案信息即可。 第六步：域名解析 备案通过后，在域名控制台域名管理中添加解析记录即可，如果直接解析到IP地址，只需要添加@和www记录的解析即可通过域名例如http://aaaa.com或者http://www.aaaa.com访问网站。 云服务器ECS地址：阿里云·云小站
-
发表了文章 2020-09-29
阿里云服务器双11配置仅需85元/年
阿里云活动出现了一款性价比极高的云服务器，1核2GB 1M只要84.97元 。明星机型——254.92售价元的1核2GB 1Mb的ECS共享型。两款云服务器价格都非常便宜，但我这边强烈推荐大家买5M带宽的云服务器。 众所周知，很多用户购买这两款入门级配置一方面是为了学习，另一方面是为了建站或者运行一些爬虫之类的软件。但现在随便一个张图片，一个CSS，JS文件都在几百K左右，首页大小很少有小于1MB的。这样我们的1Mb小水管就不太够用了，大家都知道1Mb=128KB,以用户打开一个1MB左右的网页为例，1Mb小水管足足要8秒(1024/128=8),而5Mb只要1.6秒即可。 两款云服务器之间，相差4Mb带宽，价格相差只有99元;目前，阿里云服务器的各个组件最贵的就是带宽，每Mb的售价高达50元/月，因为带宽是各大运营商提供的，价格并不是直接受控于阿里云的。如果你想后期升级4Mb，你付出的决定不是99元，而是50412=2400元。 购买地址:阿里云大促活动 云服务器ECS地址：阿里云·云小站
-
发表了文章 2020-09-29
阿里云服务器1核2GB5M配置仅需201元/年
阿里云活动出现了一款性价比极高的云服务器，1核2GB 5M只要201元 。明星机型——售价91元的1核2GB 1Mb的T5型云服务器。两款云服务器价格都非常便宜，但我这边强烈推荐大家买5M带宽的云服务器。 众所周知，很多用户购买这两款入门级配置一方面是为了学习，另一方面是为了建站或者运行一些爬虫之类的软件。但现在随便一个张图片，一个CSS，JS文件都在几百K左右，首页大小很少有小于1MB的。这样我们的1Mb小水管就不太够用了，大家都知道1Mb=128KB,以用户打开一个1MB左右的网页为例，1Mb小水管足足要8秒(1024/128=8),而5Mb只要1.6秒即可。 两款云服务器之间，相差4Mb带宽，价格相差只有99元;目前，阿里云服务器的各个组件最贵的就是带宽，每Mb的售价高达50元/月，因为带宽是各大运营商提供的，价格并不是直接受控于阿里云的。如果你想后期升级4Mb，你付出的决定不是99元，而是50412=2400元。 领取阿里云3850元代金优惠券 云服务器ECS地址：阿里云·云小站
-
发表了文章 2020-09-28
基于阿里云ECS搭建云上博客
本场景将提供一台基础环境的 CentOS 6.4 64 位的 ECS（云服务器）实例。我们将会在这台服务器上安装和部署LAMP 环境，然后安装 WordPress，帮助开发者快速搭建自己的博客。 目录：基于ECS搭建云上博客 环境部署 Wordpress 安装部署 环境部署 一、创建资源 1. 请点击页面左侧的 云产品资源，在下拉栏中，查看本次实验资源信息； 2. 在资源下拉栏点击 免费开通 按钮，开始创建实验资源。 说明：资源创建过程需要1-3分钟。完成实验资源的创建后，用户可以通过 云产品资源 查看实验中所需的资源信息，例如：IP地址、用户名、密码等。 二、连接ECS服务器 1. 打开系统自带的终端工具。 Windows：CMD或Powershell。 MAC：Terminal。 Windows用户请检查系统中是否安装有ssh工具。检查方法： 1）在终端中输入命令ssh -V。 <span style="color:rgba(0, 0, 0, 0.75)"><span style="color:#000000"><code><span style="color:#4f4f4f !important"><span style="color:#4f4f4f !important"><span style="color:#4f4f4f !important">ssh</span></span></span> -V</code></span></span> 2）出现如下结果说明已安装。 3）否则请下载安装OpenSSH。 2. 在终端中输入连接命令ssh [username]@[ipaddress]。您需要将其中的username和ipaddress替换为第1小节中创建的ECS服务器的登录名和公网地址。例如： <span style="color:rgba(0, 0, 0, 0.75)"><span style="color:#000000"><code>ssh root@<span style="color:#006666 !important"><span style="color:#006666 !important"><span style="color:#006666 !important">123.123</span></span></span><span style="color:#006666 !important"><span style="color:#006666 !important"><span style="color:#006666 !important">.123</span></span></span><span style="color:#006666 !important"><span style="color:#006666 !important"><span style="color:#006666 !important">.123</span></span></span></code></span></span> 命令显示结果如下： 3. 输入yes。 4. 同意继续后将会提示输入登录密码。 密码为已创建的云服务的ECS的登录密码。 登录成功后会显示如下信息。 三、安装 Apache HTTP 服务 Apache是世界使用排名第一的Web服务器软件。它可以运行在几乎所有广泛使用的计算机平台上，由于其跨平台和安全性被广泛使用，是最流行的Web服务器端软件之一。 1. 执行如下命令，安装Apache服务及其扩展包。 <span style="color:rgba(0, 0, 0, 0.75)"><span style="color:#000000"><code>yum -y <span style="color:#000088 !important"><span style="color:#000088 !important">install</span></span> httpd httpd-<span style="color:#000088 !important"><span style="color:#000088 !important">manual</span></span> mod_ssl mod_perl mod_auth_mysql</code></span></span> 返回类似如下图结果则表示安装成功。 2. 执行如下命令，启动Apache服务。 <span style="color:rgba(0, 0, 0, 0.75)"><span style="color:#000000"><code>systemctl <span style="color:#000088 !important"><span style="color:#000088 !important">start</span></span> httpd.service</code></span></span> 3. 测试Apache服务是否安装并启动成功。 Apache默认监听80端口，所以只需在浏览器访问ECS分配的IP地址http://<ECS公网地址>，如下图： 四、安装 MySQL 数据库 由于使用wordpress搭建云上博客，需要使用MySQL数据库存储数据，所以这一步我们安装一下MySQL。 1. 执行如下命令，下载并安装MySQL官方的Yum Repository。 <span style="color:rgba(0, 0, 0, 0.75)"><span style="color:#000000"><code>wget http:<span style="color:#880000 !important"><span style="color:#880000 !important"><span style="color:#880000 !important">//dev.mysql.com/get/mysql57-community-release-el7-10.noarch.rpm</span></span></span></code></span></span> <span style="color:rgba(0, 0, 0, 0.75)"><span style="color:#000000"><code>yum -y <span style="color:#000088 !important"><span style="color:#000088 !important"><span style="color:#000088 !important">install</span></span></span> mysql57-community-<span style="color:#000088 !important"><span style="color:#000088 !important"><span style="color:#000088 !important">release</span></span></span>-el7-<span style="color:#006666 !important"><span style="color:#006666 !important"><span style="color:#006666 !important">10.</span></span></span>noarch.rpm</code></span></span> <span style="color:rgba(0, 0, 0, 0.75)"><span style="color:#000000"><code>yum -y <span style="color:#000088 !important"><span style="color:#000088 !important"><span style="color:#000088 !important">install</span></span></span> mysql-community-<span style="color:#000088 !important"><span style="color:#000088 !important"><span style="color:#000088 !important">server</span></span></span></code></span></span> 2. 执行如下命令，启动 MySQL 数据库。 <span style="color:rgba(0, 0, 0, 0.75)"><span style="color:#000000"><code>systemctl <span style="color:#000088 !important"><span style="color:#000088 !important"><span style="color:#000088 !important">start</span></span></span> mysqld.service</code></span></span> 3. 执行如下命令，查看MySQL运行状态。 <span style="color:rgba(0, 0, 0, 0.75)"><span style="color:#000000"><code><span style="color:#4f4f4f !important"><span style="color:#4f4f4f !important"><span style="color:#4f4f4f !important">systemctl</span></span></span> status mysqld.service</code></span></span> 4. 执行如下命令，查看MySQL初始密码。 <span style="color:rgba(0, 0, 0, 0.75)"><span style="color:#000000"><code><span style="color:#000088 !important"><span style="color:#000088 !important"><span style="color:#000088 !important">grep</span></span></span> <span style="color:#009900 !important"><span style="color:#009900 !important"><span style="color:#009900 !important">"password"</span></span></span> /var/<span style="color:#000088 !important"><span style="color:#000088 !important"><span style="color:#000088 !important">log</span></span></span>/mysqld.<span style="color:#000088 !important"><span style="color:#000088 !important"><span style="color:#000088 !important">log</span></span></span></code></span></span> 5. 执行如下命令，登录数据库。 <span style="color:rgba(0, 0, 0, 0.75)"><span style="color:#000000"><code><span style="color:#4f4f4f !important"><span style="color:#4f4f4f !important"><span style="color:#4f4f4f !important">mysql</span></span></span> -uroot -p</code></span></span> 6. 执行如下命令，修改MySQL默认密码。 说明 新密码设置的时候如果设置的过于简单会报错，必须同时包含大小写英文字母、数字和特殊符号中的三类字符。 <span style="color:rgba(0, 0, 0, 0.75)"><span style="color:#000000"><code><span style="color:#000088 !important"><span style="color:#000088 !important"><span style="color:#000088 !important">ALTER</span></span></span> <span style="color:#000088 !important"><span style="color:#000088 !important"><span style="color:#000088 !important">USER</span></span></span> <span style="color:#009900 !important"><span style="color:#009900 !important"><span style="color:#009900 !important">'root'</span></span></span>@<span style="color:#009900 !important"><span style="color:#009900 !important"><span style="color:#009900 !important">'localhost'</span></span></span> <span style="color:#000088 !important"><span style="color:#000088 !important"><span style="color:#000088 !important">IDENTIFIED</span></span></span> <span style="color:#000088 !important"><span style="color:#000088 !important"><span style="color:#000088 !important">BY</span></span></span> <span style="color:#009900 !important"><span style="color:#009900 !important"><span style="color:#009900 !important">'NewPassWord1.'</span></span></span>;</code></span></span> 7. 执行如下命令，创建wordpress库。 <span style="color:rgba(0, 0, 0, 0.75)"><span style="color:#000000"><code><span style="color:#000088 !important"><span style="color:#000088 !important"><span style="color:#000088 !important">create</span></span></span> <span style="color:#000088 !important"><span style="color:#000088 !important"><span style="color:#000088 !important">database</span></span></span> wordpress; </code></span></span> 8. 执行如下命令，创建wordpress库。 执行如下命令，查看是否创建成功。 <span style="color:rgba(0, 0, 0, 0.75)"><span style="color:#000000"><code><span style="color:#000088 !important"><span style="color:#000088 !important"><span style="color:#000088 !important">show</span></span></span> <span style="color:#000088 !important"><span style="color:#000088 !important"><span style="color:#000088 !important">databases</span></span></span>;</code></span></span> 9. 输入exit退出数据库。 五、安装 PHP 语言环境 WordPress是使用PHP语言开发的博客平台，用户可以在支持PHP和MySQL数据库的服务器上架设属于自己的网站。也可以把WordPress当作一个内容管理系统（CMS）来使用。 1. 执行如下命令，安装PHP环境。 <span style="color:rgba(0, 0, 0, 0.75)"><span style="color:#000000"><code>yum -y <span style="color:#000088 !important">install</span> php php-mysql gd php-gd gd-devel php-<span style="color:#000088 !important">xml</span> php-common php-mbstring php-ldap php-pear php-xmlrpc php-imap</code></span></span> 2. 执行如下命令创建PHP测试页面。 <span style="color:rgba(0, 0, 0, 0.75)"><span style="color:#000000"><code>echo "<span style="color:#009900 !important"><?php</span> phpinfo(); <span style="color:#009900 !important">?></span>" > /var/www/html/phpinfo.php</code></span></span> 3. 执行如下命令，重启Apache服务。 <span style="color:rgba(0, 0, 0, 0.75)"><span style="color:#000000"><code><span style="color:#4f4f4f !important">systemctl</span> restart httpd</code></span></span> 4. 打开浏览器，访问公网地址>/phpinfo.php，显示如下页面表示PHP语言环境安装成功。 Wordpress 安装部署 一、Wordpress安装和配置 本小节将在已搭建好的LAMP 环境中，安装部署 WordPress 1. 执行如下命令，安装wordpress。 <span style="color:rgba(0, 0, 0, 0.75)"><span style="color:#000000"><code>yum -y <span style="color:#000088 !important">install</span> wordpress</code></span></span> 显示如下信息表示安装成功。 2. 修改WordPress配置文件。 1）执行如下命令，修改wp-config.php指向路径为绝对路径。 <span style="color:rgba(0, 0, 0, 0.75)"><span style="color:#000000"><code><span style="color:#880000 !important"># 进入/usr/share/wordpress目录。</span><span style="color:#4f4f4f !important">cd</span> /usr/share/wordpress<span style="color:#880000 !important"># 修改路径。</span>ln -snf /etc/wordpress/wp-config.php wp-config.php<span style="color:#880000 !important"># 查看修改后的目录结构。</span>ll</code></span></span> 2）执行如下命令，移动wordpress到Apache根目录。 <span style="color:rgba(0, 0, 0, 0.75)"><span style="color:#000000"><code><span style="color:#009900 !important"># 在Apache的根目录/var/www/html下，创建一个wp-blog文件夹。</span>mkdir /<span style="color:#000088 !important">var</span>/www/html/wp-blogmv * /<span style="color:#000088 !important">var</span>/www/html/wp-blog/</code></span></span> 3）执行以下命令修改wp-config.php配置文件。 在执行命令前，请先替换以下三个参数值。 database_name_here为之前步骤中创建的数据库名称，本示例为wordpress。 username_here为数据库的用户名，本示例为root。 password_here为数据库的登录密码，本示例为NewPassWord1.。 <span style="color:rgba(0, 0, 0, 0.75)"><span style="color:#000000"><code>sed -i <span style="color:#009900 !important">'s/database_name_here/</span><em><span style="color:#009900 !important">wordpress</span></em><span style="color:#009900 !important">/'</span> /<span style="color:#000088 !important">var</span>/www/html/wp-blog/wp-config.phpsed -i <span style="color:#009900 !important">'s/username_here/</span><em><span style="color:#009900 !important">root</span></em><span style="color:#009900 !important">/'</span> /<span style="color:#000088 !important">var</span>/www/html/wp-blog/wp-config.phpsed -i <span style="color:#009900 !important">'s/password_here/</span><em><span style="color:#009900 !important">NewPassWord1.</span></em><span style="color:#009900 !important">/'</span> /<span style="color:#000088 !important">var</span>/www/html/wp-blog/wp-config.php</code></span></span> 4）执行以下命令，查看配置文件信息是否修改成功。 <span style="color:rgba(0, 0, 0, 0.75)"><span style="color:#000000"><code>cat -n /<span style="color:#000088 !important">var</span>/www/html/wp-blog/wp-config.php</code></span></span> 3. 执行如下命令，重启Apache服务。 <span style="color:rgba(0, 0, 0, 0.75)"><span style="color:#000000"><code><span style="color:#4f4f4f !important">systemctl</span> restart httpd</code></span></span> 二、测试Wordpress 完成以上所有步骤后，就可以测试我们基于ECS所搭建的云上博客了。 1. 打开浏览器并访问http://<ECS公网IP>/wp-blog/wp-admin/install.php。 2. 根据以下信息完成wordpress初始化配置。 Site Title：站点名称，例如：Hello ADC。 Username：管理员用户名，例如：admin。 Password：访问密码，例如：cIxWg9t@a8MJBAnf%j。 Your Email：email地址，建议为真实有效的地址。若没有，可以填写虚拟email地址，但将无法接收信息，例如：admin@admin.com。 3. 单击Install WordPress完成Wordpress初始化。 4. 单击Log In进行登录。 5. 输入设置的用户名和密码。 6. 登录后，您就可以添加博客进行发布了。 <a href="https://www.aliyun.com/minisite/goods?userCode=w1g62dpe" target="_blank">云服务器ECS地址：阿里云·云小站</a></p>
-
发表了文章 2020-09-28
如何购买阿里云服务器ECS更便宜实惠？
接触BAT云也有3个月了，从服务器、虚拟主机是什么都不知道，到现在对BAT服务器（海外、国内），虚拟主机（独享IP、共享IP等）均有所了解，其中吃过的苦，走过的弯路只有过来人才知道。 接触BAT云也有3个月了，从服务器、虚拟主机是什么都不知道，到现在对BAT服务器（海外、国内），虚拟主机（独享IP、共享IP等）均有所了解，其中吃过的苦，走过的弯路只有过来人才知道。 为了让新手了解去服务器，本期我们主要介绍如何购买阿里云ECS服务器，希望能通过我的经验，能帮助到大家！ 一：访问阿里云官网 二：注册阿里云账号，或者使用淘宝账号登录激活阿里云账号。个人建议直接单独注册比较好 三：从产品里面选择云服务器ECS 四：进入页面后选择立即购买，针对新用户一般有活动，比如最近可以用￥89.76/年购买1核2G的国内线路 五：选择购买的配置， 主要从以下几个方面考虑： 1.付费方式：按年付费，按使用量付费。建议新人按月或者按年付费，同时建议至少选1年-3年，因为折扣更多。 2.选择服务器所在的地区：如果国内的话，其实访问速度都差不多，建议选择华北区域，是新开的，价格会要比其他地区优惠。 3.选择实列，也就是选择你的服务器配置。这里有很多配置，我就只列举一下新手需要的配置：1VCPU，2Gbit就可以满足需求了更多的实例我抽时间写一个适合不同行业的。 4.镜像，也就是你的系统，如果你喜欢折腾就选择系统镜像，建议用linux，选centos操作系统比较好。这个镜像等你购买好服务器后，大概2-3分钟，你打开你的服务器就是一个崭新的系统，没有任何其他文件。 当然，如果你不想折腾，也可以在镜像市场选择一个，有免费的，也有付费的，马士虽笔记自动帮你安装好你选择的功能，免去了很多配置的要求，对于不会配置服务器的站长来说，不失为一个好的选择。 六：磁盘，默认系统盘是40GB，基本够用了，我们可以单独开一个OSS，用于放图片和文件。价格非常便宜1年也就12元。 七：公网带宽：也就是你的服务器外部访问的带宽，说点心得： 1.简单一点，你就按照1M带宽一天1000个IP来计算，比如你预估你网站一天有2000个IP来访问，你就选择固定的2M带宽。 2.你也可以选择弹性带宽，用多少算多少，不过这个是后付费的，你需要保证你的账号里面一直有余额，不然会停到你的外部访问，好处就是在开始访客较少的时候，你可以少付些带宽费用。 十：安全组，这个你记得勾选一下80端口和443端口，不然你弄了半天发现通过域名就是访问不了你的网站，在服务器打开又是正常的。那是因为你没有打开80端口的访问权限，所有在购买的时候就把端口打开。 到这里就可以直接确认订单，付款购买了。 也可以选择把服务器配置好了之后再付款。但是你配置的信息请一定记住，因为这些配置信息是你访问服务器的密码信息。 配置好了之后，付费完成大概5分钟左右，系统就会把你的系统安装完成。 云服务器ECS地址：阿里云·云小站
-
发表了文章 2020-09-28
阿里云ECS服务器入门使用流程
一、阿里云根据个人需要选合适的云服务器，选好cpu、内存、带宽，地域，这四个是主要的。其他可以默认选择。 二、登陆控制台 输入账号密码，进去看到服务界面，新手可能不容易看懂。点击左侧菜单，点击云服务器，显示界面如图： 点击实例，在左上角选择区域（一定要选对地域才能看到服务器），这时看到服务器信息了，如图： 大家不要看这里这么多信息，对我们有用的其实只有几个而已，别的都不用看。 更多参阅云服务器配置帮助文档。 三、连接主机 1、通过控制台连接 阿里云服务器要用到两个密码，一个是远程登录密码，一个是实例密码，就是我们平常登录服务器的root密码（以linux服务器为例）。 通过控制台连接服务器需要使用到这两个密码，如果不知道重置即可。 注意：修改实例密码需要重启服务器才能生效。 点击远程连接，输入远程连接密码 输入root用户和密码（就是刚才改过的实例密码），开始对服务器进行操作。 登录成功后，可以输入各种命令。 点击左侧按钮列表的断开连接，就能够断开与服务器的链接了。 2、通过工具连接 在云控制台的实例页面看到公网IP，通过工具软件连接服务器，和上面的作用一样，可以输入各种命令了。 三、开通安全组 同样在实例最右侧点击【更多】>>【网络和安全组】>>【安全组配置】 点击配置规则 入方向看到的就是目前服务器的安全组规则了，你可以在这里添加、修改、删除规则。 比如要开放 80端口，按照下面的例子填写。 这块挺重要的，规则添加不对了可能就无法正常访问了。 更多参阅安全组帮助文档。 四、网站搭建 做网站的话可以搭配系统镜像使用，阿里云自带一键开通，方法如下图： 点击【确定，更换系统盘】，注意提前保存数据。 点击【镜像市场】，从镜像市场选择 搜索【宝塔面板】，选择0/月的，注意看已使用人数，选择人数多的那个。 自定义密码，然后输入符合要求的密码。这里记住登陆名和密码，以后链接服务器都要用。 也可以用密钥方式，这里不细说了。 接下来记住宝塔面板的登陆地址，账号密码。 去登陆到宝塔面板中，开始建站之旅。 记住如果宝塔面板无法登陆，那是因为安全组中没有添加面板的端口，按照上面的办法去添加就行了。 更多参阅镜像市场帮助文档。 到此这篇关于阿里云ECS服务器入门使用流程(新手必看教程)的文章就介绍到这了,更多相关阿里云ECS服务器入门内容 云服务器ECS地址：阿里云·云小站
-
发表了文章 2020-09-28
阿里云ECS服务器CPU总是100%跑满该怎么排查？
一、背景和现象 初创公司，架构lanmp，web前端和后端分开服务器，业务驱动主要是nginx和apache，nginx主要是处理静态文件和反向代理，前后端、搜索引擎、缓存、队列等附加的服务都是用docker容器部署。因为比较初级，上传文件和采集文件都是直接写在硬盘上，涉及到的目录共享，就在其中一台服务器存储并且nfs共享。我们暂且分为ECS1（apache1）、ECS2（apache2）、ECS3（nginx）。某天网站业务中断，但是没有报错。一直在等待响应，默认响应超时是一分钟，所以很基础高可用没有起到作用。中断10分钟左右，重启服务，提示“open too many files”，但是lsof统计没几个。因为初级处理不了，所以直接重启服务器，一段时间后一切恢复正常，可是第二天又来一次这种情况。 阿里云1折优惠券领取（老用户可注册新账号领取） 二、第一次出现后的排查思路 本来第一次发现这种问题的时候就要追查原因了，看了一下zabbix监控图像其中断了十分钟，包括网络、内存、CPU、硬盘、IO等监控数据。首先想到的是网络问题，结论是zabbix-servert获取不到了zabbix-agent采集的数据，估计就是网络不通了。 但是，这个结论站不住脚，因为我本身通过ssh登录服务器，并且命令输入无卡顿，不至于头文件都传不过来。后来一看阿里云的云监控，上面有数据，似乎也可以佐证网络这个说法，因为云监控是阿里云内部的监控，可以内网获取到监控数据。直到看CPU的使用率这项，发现有一段时间的CPU使用率100%。并且我重启的时候CPU恢复正常，不能说网络一定没问题，但系统肯定有问题。也可以解释因为CPU使用已经是100%，zabbix-agent和根本不能正常运行，所以没有监控数据。因为这个公司全部都是云服务器，没有使用IDC所以我们也没有安装smokeping来监控，接着我们就不把重心在网络上了。 目前掌握的信息就是:在毫无征兆的情况下，CPU暴涨到100%，重启之前一直保留，重启之后恢复原样。匆忙之中又看了一下系统各日志，因为太匆忙，没有总结，没有找到什么有价值的东西。现在有下面几种猜想：第一，程序的bug或者部署不当，触发之后耗尽资源。第二、docker容器的bug。第三、网络攻击。第四、病毒入侵。第五、阿里云方系统不稳定。 小总结了一下，现在问题还没有找出来。下次还有这个问题的可能，所以先尽量防范，但是又不能重启一刀切。所以在zabbix上面设置了自动化，当检测到ECS1获取不到数据的时候马上操作ECS3标记后端为ECS1的apache为down。保留异常现场。（请求停止的时候，CPU100%还在） 三、现场排查 1、相应的排查计划（想到这些信息需要获取的，实际上没有严格按照这样的步骤） 1）用htop和top命令监控CPU、内存使用大的进程。先看看哪个进程消耗资源较多,用户态、内核态、内存、IO……同时sar -b查io的历史定时抽样。 2）统计tcp连接数，看看有没有DDOS攻击。netstat -anp |grep tcp |wc -l 。用iftop-i eth1看看通讯。同时用tail -n 1200 /var/log/messages查看内核日志。 3）用pstree查看打开进程，ps aux|wc-l看看有没有特别多的进程。虽然zabbix监控上说没有，但是我们要检查一下看看有没有异常的进程名字。 4）查看全部容器的资源使用docker stats $(docker ps -a -q)，看看能不能从容器上排查。 5）有了“too many open files”的启发，计算打开文件数目lsof|wc -l，根据进程看看ll /proc/PID/fd文件描述符有没有可疑的打开文件、文件描述符。 6）关于用lsof打开文件数找到的线索，排序打开文件找出进程号 lsof -n|awk '{print $2}'|sort|uniq -c|sort -nr|more 7）关于用lsof打开文件数找到的线索，用lsof -p PID查看进程打开的句柄。直接查看打开的文件。 8）启动容器的时候又总是“open too many files"。那就是打开文件数的问题，因为CPU的使用率是CPU的使用时间和空闲时间比，有可能因为打开文件数阻塞而导致CPU都在等待。针对连接数的问题，大不了最后一步试试echo 6553500 > /proc/sys/fs/file-max 测试打开文件对CPU的影响。 9）玩意测出来了消耗CPU的进程，可以使用strace最终程序。用户态的函数调用跟踪用「ltrace」，所以这里我们应该用「strace」-p PID 10）从程序里面看到调用系统底层的函数可以跟踪。跟踪操作 strace -T -e * -p PID，主要看看代码调用的函数有没有问题。 2、现场排查 第二天同样时间，ECS果然暴涨了CPU。这是时候zabbix的工作如希望进行保留了一台故障的ECS1给我。 1）用htop看到资源使用最大是，搜索引擎下我写的一个判断脚本xunsearch.sh。脚本里面很简单，判断索引和搜索服务缺一个就全部重启。就当是我的容器有问题我直接关掉搜索引擎容器。httpd顶上，我又关掉apache容器。rabbitmq相关进程又顶上。这时候我没心情周旋了，肯定不也是这个原因。sar -b查看的历史io也没有异常。 2）统计tcp连接，几百。先不用着重考虑攻击了。用tail -n 1200 /var/log/messages查看内核日志，是TCP TIME WAIT的错误。可以理解为CPU使用100%，程序无响应外面的tcp请求超时。这是结果，还是没有找到根本原因。 接着往下看系统内核日志，发现了和“open too many files”呼应的错误，“file-max limit 65535 reached”意思是，已到达了文件限制瓶颈。这里保持怀疑，继续收集其他信息。 3）查看进程数量，数量几百。列出来也看到都是熟悉的进程，可以先排除异常进程。 4）监控容器的资源使用，里面很不稳定，首先是xunsearch容器使用80%的CPU，关掉xunsearch，又变成了其他容器使用CPU最高。很大程度上可以排查容器的问题和执行程序的问题。 5）查看了最大连接数cat /proc/sys/fs/file-max是65535但是用lsof查到的连接数是10000多，完全没有达到连接数。 6）各项参数都正常，现在聚焦在打开的文件数这个问题上面。也可以用另外同一种方式查看一下内核统计文件 /proc/sys/fs/file-nr，比较一下差异，看看能不能找出问题。cat了一下，打开文件数是66080，果然超了！内核日志就以这个为标准。 但是看lsof怎么统计不出来，ll /proc/PID/fd也没几个。这个问题放在后面，先按照步骤echo 6553500 > /proc/sys/fs/file-max给连接数提高到100倍，CPU果然降了下来。原因确认了，但是必须找到根源，为什么忽然有这么大的打开文件数。关掉全部docker容器和docker引擎，打开文件数是少了一点，但是仍然在65535差不多。我就先排除一下业务的影响，把ECS3的nginx直接指向视频ECS2的apache，就等同于在ECS2上实现了ECS1的场景。查看一下ECS2的句柄数，才4000多，排除了业务相关应用对服务器的影响。那就能下个小结论，ECS1被神秘程序打开了6万多句柄数，打开业务就多了2000多的句柄数，然后就崩溃了。不过这个现象有点奇怪，ECS2和ECS1在一样的机房一样的配置一样的网络环境，一样的操作系统，一样的服务，一样的容器，为什么一个有问题，一个没问题呢？不同的只是有一台是共享nfs。难道是静态文件共享了，其他人读了，也算是本服务器打开的？ 7）现在程序找不到，没法继续lsof -p了。排查之前的猜想。带着排查得到对的结论往下想。 程序的bug和部署不当，那是不可能的，因为主要问题来自于打开句柄数，当部署到ECS2那里，一切正常。docker容器的bug，那也不可能的，每个都是我亲自写脚本，亲自编译，亲自构建的，关键是我关掉了docker容器和引擎都没有很大改善。网络攻击也排除，因为网络连接数没几个，流量也不变。那就只剩下病毒入侵也不是，没有异常进程。考虑到ECS的稳定性问题了。这方面就协助阿里云工程师去排查。 8）阿里云工程师用的排查手段和我差不多，最终也是没能看到什么。也只是给了我一些治标不治本的建议。后来上升到专家排查，专家直接在阿里云后端抓取了coredump文件分析打开的文件是图片，程序是nfsd。 好像印证了我刚才后面的猜想，应该就是ECS1使用了nfs共享其他服务器打开了然后算在ECS1头上。那问题又来了，我们的业务已经到达了可以影响服务器的程度吗？ 9）既然问题解决到这一步，先不管程序有没有关闭打开的文件和nfs的配置。我们架构上面的图片应该是归nginx读取，难道是linux的内存机制让它缓存了。带着缓存的问题，首先去ECS3上释放内存echo 3 > /proc/sys/vm/drop_caches，释放之后，发现没什么改善，有点失落。总是觉得还有一台后端是PHP主导，但是逻辑上是写入，没有打开文件之说。后来从程序员中了解到，PHP也有打开图片。我猛然去ECS2释放一下内存，果然，句柄数降下来。（这里大家一定有个疑问，为什么我直接想到内存缓存而不是目前打开的文件呢。其一，这是生产环境，web前端只有一个，不能乱来停服务。其二，第一次遇到问题的时候，重启之后没有问题，过了一天之后积累到一定的程度才爆发，这里已经引导了我的思路是积累的问题，那就是缓存不断积累了） 10）因为ECS2的调用ECS1的nfs共享文件，所以lsof也有读不到那么多句柄数的理由。如果说是nfs的服务本身就有缓存，导致问题的话，我查看了配置文件，还是默认值允许缓存，30S过期，根本不会因为nfs的缓存造成打开文件过多。如果我们的后端程序打开之后没好好处理的话，那倒有可能。然后尝试排除：我改了ECS3的配置，使程序只读ECS1后端，从ECS1上面却看不到有什么异常表现，说明PHP程序已经好好处理了打开的文件。也不是docker挂载了nfs的共享的问题，因为nginx也有挂载。排查到这里也很大程度上解决问题，而且缓存了nfs的全部共享文件，句柄并没有增加，也算合理，所以就增加了打开文件数的限制。 11）现在排查的结果是跟后端和nfs共享有关。就是说，后端挂载了nfs的网络共享，被程序读取。而程序释放之后，在正常背景的硬盘文件是没有缓存的。但是在nfs挂载的环境下，缓存并没有得到释放。 12）总结：很多问题的排查和我们的猜想结果一样，但是有些例外的情况。比如这次我想到的原因都一一排除，但是问题也是在一步步排查中，逐步被发现的。 云服务器ECS地址：阿里云·云小站
-
发表了文章 2020-09-28
阿里云服务器1核2GB5M配置仅需201元/年
阿里云活动出现了一款性价比极高的云服务器，1核2GB 5M只要201元 。明星机型——售价91元的1核2GB 1Mb的T5型云服务器。两款云服务器价格都非常便宜，但我这边强烈推荐大家买5M带宽的云服务器。 众所周知，很多用户购买这两款入门级配置一方面是为了学习，另一方面是为了建站或者运行一些爬虫之类的软件。但现在随便一个张图片，一个CSS，JS文件都在几百K左右，首页大小很少有小于1MB的。这样我们的1Mb小水管就不太够用了，大家都知道1Mb=128KB,以用户打开一个1MB左右的网页为例，1Mb小水管足足要8秒(1024/128=8),而5Mb只要1.6秒即可。 两款云服务器之间，相差4Mb带宽，价格相差只有99元;目前，阿里云服务器的各个组件最贵的就是带宽，每Mb的售价高达50元/月，因为带宽是各大运营商提供的，价格并不是直接受控于阿里云的。如果你想后期升级4Mb，你付出的决定不是99元，而是50412=2400元。 购买地址:阿里云大促活动 云服务器ECS地址：阿里云·云小站
-
发表了文章 2020-09-28
阿里云突发性能实例值得购买吗？
阿里云服务器突发性能实例优惠促销很便宜很性价比高，什么叫突发性能实例？阿里云服务器突发性能实例t5如何？值得购买吗？ 什么叫突发性能实例？ 突发性能实例t5：每台突发性能网络服务器都是有一个基准CPU测算性能，并会依据实例规格型号以特定速率不断获得CPU積分。每台t5实例一旦起动，便会刚开始耗费積分以满足需求。当实例具体工作中性能高过基准CPU测算性能时，会耗费大量的CPU積分来提高CPU性能，考虑工作中要求。 因为突发性能实例t5受制于基准CPU测算性能，因此 假如对云主机性能规定较高得话，提议不必挑选突发性能实例。 突发性能实例原理： 基准CPU测算性能 每个t5实例规格型号都是有一个基准CPU测算性能，即一切正常工作中负荷时，实例每一个vCPU核有一个较大使用率。例如ecs.t5-lc1m2.small实例在一切正常工作中负荷时，CPU使用率较大为10%。 CPU积分 每台t5实例依据基准CPU测算性能以固定不动速率获得CPU積分。一个CPU積分意味着的测算性能与vCPU核数、CPU使用率和上班时间相关： 1个CPU積分=一个vCPU核以100%使用率运作一分钟 1个CPU積分=一个vCPU核以50%使用率运作2分钟 1个CPU積分=两个vCPU核以25%使用率运作2分钟 假如期待一个vCPU核一小时（一个小时）都以100%使用率运作，一个vCPU核每钟头必须60个CPU積分。 举例说明： 以一台ecs.t5-lc1m2.small实例为例子，表明突发性能实例CPU積分转变： 1.实例建立后，实例分派到30个CPU積分。实例未起动前，CPU積分总产量为30。实例打开后，以0.1个CPU積分/分鐘的速率被分派CPU積分，另外耗费積分。 2.打开后第一分钟内，假定CPU使用率为5%，实例会耗费0.05个原始CPU積分，可是另外又会被分派0.1个CPU積分，这时到期的CPU積分为0，因此 ，事实上积累了0.05个CPU積分。 3.打开N分鐘后，假定CPU使用率为50%，并且会到期0.1个CPU積分，则这一分钟内实例会耗费0.五个CPU積分，另外又会被分派0.1个CPU積分，即事实上实例应用了0.五个CPU積分，并且沒有提升積分。 4.当积累的CPU積分耗费完后，实例的CPU使用率，较大只有为10%。 82元/年的突发性能T5一年是怎么购买 在云小站的优惠活动以及上云必备活动中都是102元/年，我想很多关注阿里云服务器最近想入手的朋友都有这个疑问，其实很简单，本身突发性能T5是102元/年的，要做到82一年需要使用阿里云的新用户优惠券，先领20元优惠券，在购买就可以做到82/年了，下面是教程，可以按流程操作。 首先，参加现在最新的优惠：阿里云小站活动 进入活动后先领取新用户优惠券，1核2G突发性能T5可以使用减20优惠券做到82元/年 不止这个突发性能t5服务器，这个新用户20券是可以和阿里云新用户活动的所有优惠叠加的，大家在购买服务器前已经要领券购买，下图中的大额券也可以都领一下，其他的券针对的是其他服务器，也是可以叠加优惠活动使用的。 云服务器ECS地址：阿里云·云小站
-
发表了文章 2020-09-28
阿里云服务器入门级和企业级有何区别？
阿里云服务器ECS分成入门级和企业级二种，那麼入门级和企业级有什么区别呢？入门级的云服务器ECS价钱比较划算，此外云服务器性相对性于企业级更差一些。现阶段阿里云官网已经市场销售的入门级云服务器以突发性性能案例t5主导，t5云服务器受限于标准CPU测算性能，因此 假如业务流程应用领域对性能规定较高，提议挑选企业级云服务器。笔者来详尽说下阿里巴巴云服务器入门级与企业级的区别： 阿里云服务器入门级和企业级的区别 入门级云服务器归类：现阶段阿里云服务器官方网出售的入门级云服务器ECS以突发性性能案例t5主导，t5云服务器受限于标准CPU测算性能，性能较弱一些； 企业级云服务器归类：通用性、测算型、运行内存型、互联网大数据型、当地SSD型、高cpu主频型等； 价钱较为：入门级云服务器价钱更加划算，一台入门级配备1核CPU/2GB运行内存/1M宽带价格为323元/年，企业级互联网加强型云服务器4核CPU/8G运行内存/1M宽带价格为299一元/年，留意：企业级沒有1核2GB的配备； 性能较为：企业级比入门级云服务器的性能好太多了，现阶段阿里云服务器入门级以突发性性能案例t5主导，t5受限于标准CPU测算性能，假如客户的应用领域对性能规定较高，提议客户挑选企业级云服务器。 82元/年的突发性能T5一年是怎么购买 目前优惠活动以及上云必备活动中都是102元/年，我想很多关注阿里云服务器最近想入手的朋友都有这个疑问，其实很简单，本身突发性能T5是102元/年的，要做到82一年需要使用阿里云的新用户优惠券，先领20元优惠券，在购买就可以做到82/年了，下面是教程，可以按流程操作。 首先，参加：阿里云小站活动 进入活动后先领取新用户优惠券，1核2G突发性能T5可以使用减20优惠券做到82元/年 不止这个突发性能t5服务器，这个新用户20券是可以和阿里云新用户活动的所有优惠叠加的，大家在购买服务器前已经要领券购买，下图中的大额券也可以都领一下，其他的券针对的是其他服务器，也是可以叠加优惠活动使用的。 云服务器ECS地址：阿里云·云小站
-
发表了文章 2020-09-28
公司数据如何迁移到阿里云服务器上？
公司数据如何迁移到阿里云服务器上 1）公司能够根据阿里云出示内嵌工具与帮助文件自身进行IT自然环境迁移工作中，即：自助服务终端； 2）公司还能够根据阿里云的合作方，根据合作方出示服务支持，协助公司进行IT自然环境迁移工作中，即：合作方适用。 下边关键来了解一下第一种方式 ，即自助式迁移。自助式迁移要求采用阿里云研发的“迁云工具”来迅速便捷地完成网址迁移目地。 阿里云迁云工具，通称迁云工具，是一个阿里云自主研发的能将电子计算机硬盘中的电脑操作系统、程序运行及其运用数据信息等迁移到虚拟器或者虚拟磁盘分区的方便快捷迁云工具。 阿里云迁云工具是致力于均衡阿里云客户的线上与线下服务器负荷，或是各种各样不一样云服务平台中间的负荷而研发的。以其轻便方便快捷的特性，阿里云迁云工具适用线上迁移物理机服务器、vm虚拟机及其别的云服务平台云服务器至ECS管理方法控制面板，完成统一部署資源的目地。 迁云工具是阿里云ECS的迁云服务项目手机客户端，适用线上迁移物理机服务器、vm虚拟机及其别的云服务平台云服务器至ECS。关键用以完成資源统一部署或是设计方案混和云计算架构。迁云工具既适用P2V和V2V。P2V（PhysicaltoVirtual）意味着从物理学IDC自然环境迁移到ECS，V2V（VirtualtoVirtual）意味着从vm虚拟机自然环境或是云服务平台服务器迁移到ECS。运用迁云工具，能够便捷地把网址和应用从源服务器或其他服务平台迁移到阿里云ECS服务器上去，源服务器指IDC服务器、vm虚拟机或是别的云服务平台云服务器。别的云服务平台就是指AWS、MicrosoftAzure、GoogleCloudPlatform、腾讯云服务和华为云服务这些这种同业竞争服务平台。 用迁云工具完成网址数据信息迁移的详尽全过程： 在迁移工具免费下载到你的源服务器之后，迁移工具根据你所编写的环境变量，在源服务器磁盘分区上运行计算机操作系统，程序根据数据信息在线生成数据信息快照更新，并在迁移过程中转换成自动镜像系统。您能够应用该自定镜像系统迅速建立ECS案例。下列为应用迁云工具迁移您的源服务器的步骤平面图： 迁云工具适用于以下电脑操作系统的物理机服务器、 vm虚拟机和其他云服务平台云服务器(32位系统或64位系统)。 WindowsLinux WindowsServer2003 WindowsServer2008 WindowsServer2012 WindowsServer2016 AmazonLinux2014及高些版本号 CentOS5/6/7 Debian7/8/9 Gentoo13.0 OpenSUSE13.1 OracleLinux5/6/7 RedHat5/6/7 SUSE11.4/12.1/12.2 Ubuntu10/12/14/16/17 迁云工具是完全免费的，没有附加费用。可是，在迁云全过程中会涉及到小量資源收费，这是由于阿里云的镜像系统和快照更新储存空间全是要收费标准的。迁云时，系统软件默认设置在您的阿里云账户下建立一个ECS案例做转运站，转站案例的付钱种类为按量付钱，按量付钱案例造成的資源消耗及收费表明，请参照阿里云官方网的按量付钱详细介绍。 当然，你也可以在这里领取阿里云服务器的优惠券，82元/年云服务器就到手了。 82元/年的突发性能T5一年是怎么购买 在云小站的优惠活动以及上云必备活动中都是102元/年，我想很多关注阿里云服务器最近想入手的朋友都有这个疑问，其实很简单，本身突发性能T5是102元/年的，要做到82一年需要使用阿里云的新用户优惠券，先领20元优惠券，在购买就可以做到82/年了，下面是教程，可以按流程操作。 首先，参加：阿里云小站活动 进入活动后先领取新用户优惠券，1核2G突发性能T5可以使用减20优惠券做到82元/年 不止这个突发性能t5服务器，这个新用户20券是可以和阿里云新用户活动的所有优惠叠加的，大家在购买服务器前已经要领券购买，下图中的大额券也可以都领一下，其他的券针对的是其他服务器，也是可以叠加优惠活动使用的。 云服务器ECS地址：阿里云·云小站
-
发表了文章 2020-09-11
云网络十年：探路者阿里云的理想和坚持
近日，阿里巴巴发布强劲财季业绩后，高盛、摩根大通等多家机构上调阿里云估值至千亿美元以上，其中高盛上调阿里云估值至1238亿美元。今年上半年阿里云营收达245亿元，市场份额连续四个季度上涨，给市场注入强劲信心。 阿里云的飞速发展，也映射了整个云计算产业的发展，经过将近二十年的发展，云计算已经从一个鲜为人知的专业术语变成了几乎家喻户晓的名词，而云计算产业也持续保持高速增长，据全球知名市场研究机构Gartner分析显示，云计算已经成为增长最快的科技领域，增长速度高达25%，而整体IT市场的增长率仅为1.1%，云计算增长速度是整个IT市场的25倍。未来，越来越多的企业将会向云端迁移，享受云计算给他们带来的红利。 目前，企业上云普遍使用的是计算，存储，网络等IaaS层产品线的产品。其中，计算产品线的云服务器ECS是大多数人最熟悉的，而阿里云网络产品线经过这几年快速发展，目前已经有近20个产品，大家对其中一些产品相对不那么熟悉，对于云网络也不是很了解。为此，在云网络10年之际, CSDN采访了阿里云网络产品线负责人，阿里云智能研究员祝顺民（花名江鹤）和阿里云资深产品专家吴天议。 云网络的本质是服务 什么是云网络呢？祝顺民表示，云网络的本质有两点： 第一是以云为中心。云网络被定义成一个数字经济体的连接，它的内涵是一个面向应用和租户的虚拟化网络基础设施，它具备云的特征，即按需、弹性、随处可获得、可计量。 第二是面向租户与应用的虚拟化。云网络可以把网络设备虚拟，并通过服务的方式提供给多个用户使用，同时又具有极致性能。 祝顺民强调，云网络更像是一种服务。如果把云计算比喻为一个电厂，云网络实际是连接各个电厂的电网，所以它不仅仅是服务于云计算中的数据中心，同时也连接各种终端、个人、企业。 吴天议介绍，计算正在从以算法为中心演进为以数据为中心，面对这样的变化，未来的网络将以“持续降低单比特的成本”为目标，通过提升带宽利用率，云原生重构网络设备，使得数据传输成本大幅降低，从而降低Capex。另外，通过AI OPS实现网络运营服务化，从而降低Opex。谈到云和网的关系，未来应该是云网一体。云网一体一方面是以云为中心无缝连接 “云-管-边-端“，另一方面对应用来说，对云和网的感知是无差异的，是一体的。当然，云网一体未来到底会呈现出怎样的特性目前还不是很明确，还需要持续的演进。而所谓云网络，就是把网络真正虚拟化，变成一个具备超高弹性、超强灵活性和超大规模的面向租户和应用的网络。 云网络的演进之路 吴天议介绍，就像许多新技术新概念一样，云网络的技术和概念也不是一蹴而就的，它也是伴随着互联网和云计算的发展逐步演进，最终慢慢形成、成熟并被大家所熟悉和认可的。 2010年以来，互联网获得了快速发展，很多互联网企业上云，通过云实现了计算的虚拟化，那时候对云网络的主要需求是公网接入能力。在这个阶段阿里云通过Classic经典网络对云计算用户提供支持。用户通过ECS上的公网IP和负载均衡产品来提供公网访问服务，这是云网络早期的产品。 到2014年，随着4G网络带来移动互联网发展，尤其是媒体、社交应用的发展，这些ToC业务需要解决同时接入多运营商问题。此外，随着更多的企业选择将应用搬迁上云，企业对云上网络安全隔离能力和互访能力、企业数据中心与云上网络互联，构建混合云的能力，以及在云上多地域部署业务后的多地域网络互联能力都提出了很多的需求，而这些需求在Classic经典网络架构下都力不从心，于是，阿里云开启了云网络1.0，面向租户的云网络的创新之旅。2014年，阿里云VPC产品上线， 实现了企业数据中心网络虚拟化，VPC中支持虚拟交换机，虚拟路由器；租户可独享SLB服务，可通过NAT/EIP主动访问公网；通过VPN，高速通道建立企业到云上的网络互联； 随着大数据与AI应用风起云涌，互联网线上/线下融合蔚然成风，企业出海方兴未艾。为了更好满足企业智能化，全球化的需求，阿里云开启云网络2.0产品与技术架构升级；2017年推出云上跨地域网络互联产品云企业网CEN。云网络开始走出数据中心网络，把云上数据中心之间，云上数据中心和云下IDC之间联通起来，这标志着云网络技术应用到整个阿里云的核心网络之中。2018年，阿里云进一步把用户上云的混合云网络也采用了云网络技术进行了改造，推出了智能接入网关SAG。云网络与容器网络进行融合，构建云原生应用层网络；云网络团队用十年的时间将云网络的技术和产品体系切实落地，云网络的概念慢慢形成。 祝顺民接着谈到了云网络中具体技术的发展，他表示，产品层面来看，从云网络1.0到2.0，云网络的范围得到了延展。横向从以前聚焦数据中心，进化到聚焦数据中心之间互联；更进一步的，甚至将企业的接入网也进行了虚拟化，这样，企业不仅不需要构建自己的核心网络，连接入网络的建设也省去了。纵向看，云网络产品不仅连接计算/存储，线下逐渐发展到连接企业的总部/分支与各种移动终端，线上企业可连接阿里云服务，阿里巴巴经济体应用，构建企业间服务生态； 云网络从核心技术来看，是对网络编址和网络性能的优化。云网络1.0的在编址上，使用Overlay技术，就是将很多块数据一起打包，即在物理网络之上叠加了一个租户的虚拟层，从而一次将多块数据一起运到正确的地址，从而提高网络的效率。在网络性能上，通过云原生重构网络设备形态持续提升数据转发性能：以虚拟交换机为例，服务器从10G升级到了25G，再到100G，经历了经典网络的Linux内核交换机，云网络1.0DPDK交换机，云网络2.0物理网卡交换机 洛神是何方神圣？ 洛神是阿里云网络的核心平台，伴随阿里“飞天”系统诞生的，是全自研的核心系统。为什么叫洛神呢？洛神的意思是洛河之神。在古代，河运是非常重要非常快速的交通手段，河网非常重要，就好比今天的网络一样重要，因此，在给云网络系统起名的时候就想，应该起一个河神的名字，因此就使用了洛神这个名字。 “洛神”作为是阿里云飞天操作系统的网络子系统，一方面通过实现网络虚拟化，对用户提供网络产品和服务。另一方面，作为底层技术系统，支撑了阿里云几乎所有产品，包括ECS，RDS，OSS等等。此外，随着阿里集团核心系统100%商业，“洛神”也是整个阿里云集团的基础设施，历经多年双十一的严峻考验，可以称得上是云网络技术的最佳实践。 2018年，洛神云网络架构全面升级，从1.0升级到2.0。为用户提供了超大规模、超高性能、超强弹性的云网络平台。 超大规模：随着越来越多的大型企业和大规模业务迁移上云，以及云原生的广泛应用，洛神2.0支持每地域百万VPC，每VPC 30万实例等超大规模能力。 超高性能：为了提升云网络的性能，洛神2.0采用自研神龙MOC卡，并针对VPC的基础组件做了全链路的软硬一体化设计，通过硬件化让vSwitch的性能对比软转发提升了10倍以上，大幅降低延迟。Gateway单机bps性能提升20倍以上，单机pps性能提升近百倍，延时降低数十倍，整体Capex和Opex大幅降低。 超强弹性：洛神2.0 的另外一个跨越式升级是NFV平台，平台的定位是构建通用、灵活的平台能力，降低业务网元NFV化的门槛和成本，实现了复杂业务网元超高的灵活性和弹性。NFV平台当前已经支持负载均衡、NAT网关、VPN网关等产品。 智能化演进：今年5月，阿里云网络的” VTrace: Automatic Diagnostic System for Persistent Packet Loss in Cloud-Scale Overlay Network”论文入选SIGCOMM2020 — 国际通信网络领域的顶尖会议。这是洛神2.0在智能化网络的阶段性技术研究成果。当用户业务部署在阿里云，如何通过数据分析和机器学习的能力，实现智能化的网络问题监测、预测分析和资源规划，将是洛神未来的演进方向。 企业上云 网络先行 如今，企业上云已经成为大势所趋，而企业上云，往往首先需要使用云网络，云网络作为云计算 IaaS层的核心产品线，一方面可以为企业上云提供丰富的云网络产品和服务，另一方面也作为基础设施承载所有的IaaS，PaaS和SaaS云产品。云网络是新兴网络技术的最大实践者，同时也承载了最多的用户和业务场景。 作为聚焦云网络长达10年的阿里云网络团队，其精心打造的云网络，在数字化转型蓬勃兴起的今天，将会为企业上云提供一条捷径，帮助企业迅速获得云网络的红利。 祝顺民表示，实际上，“网络先行”也是阿里巴巴“让天下没有难做的生意”使命的具体体现，今天阿里云要引领企业用户变革，帮助企业达成商业目标，必须先为企业搭建一条可靠的上云之路，所以必须“网络先行”。“网络先行”包含了很多先行的理念，包括数据中心一定是性能先行、技术先行，如果没有更高性能，就没有办法进行业务的变革。如果没有创新的技术，就无法应对2G、3G、4G、5G每代网络性能的提升带来的上层应用丰富的变化，所以阿里云为了“网络先行”研发了很多的创新技术，也在很多地区部署了丰富的资源，为的就是让企业用户上云更简单，让天下没有难做的生意。 实际上，阿里云网络不仅仅是改变了企业上云的方式，为企业提供了具备超高弹性、灵活性和超大规模租户的网络，同时，它也赋予了企业通达全球，连接万物的能力。这主要源于云网络覆盖全球的基础设施，连接万物的连接能力，云网一体的产品体系。 首先，阿里云拥有遍布全球的网络基础设施。据悉，目前阿里云在全球有 21个 Region、61 个可用区，120 多个 POP 节点。在这样的情况下，国内外用户在上云时，就可以基于阿里云的云网络产品在几分钟内快速构建出全球化的网络基础设施，而不再需要购买物理设备和寻找多家供应商。 其次，经过多年的自主研发，阿里云已经构建了云上网络、跨地域网络、混合云网络三大场景的产品体系。云上网络实现企业数据中心虚拟化，构建云上安全隔离的专有网络架构，并将应用连接到Internet，同时可以方便连接到阿里巴巴经济体。跨地域网络提供全球跨地域专有网络间互联，帮助客户快速构建分布式业务系统网络。而混合云网络帮助企业打通云上、云下系统和数据，构建云上云下一体的网络。 最后，云网络支持万物连接上云，包括数据中心/企业总部/分支/门店/各类移动终端，以及面向万物互联的IoT终端与云端互联。 如此众多的优势，能够帮助用户通达全球、连接万物也就不足为奇了。 云网络 数字经济的基础设施 随着云计算进入3.0时代，从技术层面上，企业希望通过虚拟化和软件化的技术手段，达到降低成本和灵活部署的目的，云计算的加持极大的增强了网络的弹性、易管理和开放性，加速了网络行业的变革。未来网络将不仅仅是连接，它将成为计算机I/O的延伸，向超高带宽、超低时延、超高性能的方向演进。从业务层面，越来越多的企业选择迁移上云，也将会有更多更复杂的业务应用通过云网络开展，例如IoT、5G、边缘的应用。云网络可以更好地帮助应用简化对底层网络复杂度依赖，让应用更简单。未来网络也将会加速以云服务为中心的架构转型，未来的网络也必定会是以云为中心的智能网络，必定是能够为人工智能与大数据应用以及云原生服务提供高性能、高弹性的网络。 同时，吴天议表示，移动化，全球化、智能化是大势所趋，降低成本、提升效率是企业永恒的话题。而使用云网络技术，将会帮助企业大幅度降低运营成本，提升运营网络的效率、最终给企业带来巨大的成本节省，这是传统网络无法做到的。更重要的是，云网络为企业提供了自建无法达到的连接全球，云-管-边-端一体的能力； 实际上，阿里云网络也得到了业界的认可，据Gartner发布的最新全球企业级网络市场份额报告显示，阿里云的负载均衡SLB增速最高达89.7%，远超亚马逊、Citrix等，位居全球第一。作为亚太唯一入围厂商，阿里云已经连续两季度增速赶超AWS、F5及Radware等国际大厂。同时，今年Gartner也将面向传统网络设备市场的“数据中心和网络”魔力象限更名为“数据中心和云网络”魔力象限，增加了一个“云”字。这些都说明云网络正在快速增长，正在受到越来越多的关注，网络云化是大势所趋。 因此，有理由相信，具有超高弹性、超强灵活性和超大规模租户、并能显著提升企业工作效率，降低企业运营成本的阿里云网络，将成为未来数据中心和云的基础设施，助力全社会数字化转型。
-
发表了文章 2020-09-11
如何让App首屏启动更快 -- httpdns持久化缓存方案
首屏启动之痛 对于大部分app而言，首屏启动是最为关键的场景之一，一旦出现阻塞将直接影响到用户体验，为此阿里云httpdns sdk推荐异步接口getIpByHostAsync来获取ip，其大致过程如下： 用户从调用getIpByHostAsync接口大致会经历： （1）内存缓存检查 （2）ip合法性检查 （3）异步httpdns请求 从流程中可以看出，由于httpdns请求是异步的，对于app首屏场景来说，httpdns可能正在解析途中，app在解析结果返回前会拿到空的ip，转而去做Local DNS解析。 解决之道：持久化缓存 为了追求极致的性能体验，尽量避免首屏启动时的Local DNS解析，本文推出httpdns的持久化缓存方案，新增接口： void setCachedIPEnabled(boolean enable); 初始化示例： service = HttpDns.getService(getApplicationContext(), ACCOUNT_ID); service.setCachedIPEnabled(true); 当setCachedIPEnabled(true)被调用时，httpdns解析记录从持久化缓存同步到内存缓存。httpdns请求成功，解析记录会同步更新到内存缓存和持久化缓存，其大致过程如下： Step1 httpdns sdk初始化 Step2 持久化缓存开启 Step3 持久化缓存记录更新到内存缓存 Step4 调用getIpByHostAsync Step5 检查ip是否合法 Step6 拿到ip，发起http请求 采用持久化缓存前，APP启动时发起业务请求时过程： 采用持久化缓存后的过程如下： 有了持久化缓存，app首屏启动就能立刻拿到解析好的ip，同时，阿里云httpdns sdk内部的过期机制也能保证拿到ip的可靠性。此外，网络切换发生后，SP（Server Provider，服务提供商）也可能发生变化，相同Host在不同SP下获取的ip也会区别对待。httpdns sdk会结合当前网络环境，通过SP和Host共同确定ip，让app拿到的结果更加精准。
-
发表了文章 2020-09-03
如何让App首屏启动更快 -- httpdns持久化缓存方案
首屏启动之痛 对于大部分app而言，首屏启动是最为关键的场景之一，一旦出现阻塞将直接影响到用户体验，为此阿里云httpdns sdk推荐异步接口getIpByHostAsync来获取ip，其大致过程如下： 用户从调用getIpByHostAsync接口大致会经历： （1）内存缓存检查 （2）ip合法性检查 （3）异步httpdns请求 从流程中可以看出，由于httpdns请求是异步的，对于app首屏场景来说，httpdns可能正在解析途中，app在解析结果返回前会拿到空的ip，转而去做Local DNS解析。 解决之道：持久化缓存 为了追求极致的性能体验，尽量避免首屏启动时的Local DNS解析，本文推出httpdns的持久化缓存方案，新增接口： void setCachedIPEnabled(boolean enable); 初始化示例： service = HttpDns.getService(getApplicationContext(), ACCOUNT_ID); service.setCachedIPEnabled(true); 当setCachedIPEnabled(true)被调用时，httpdns解析记录从持久化缓存同步到内存缓存。httpdns请求成功，解析记录会同步更新到内存缓存和持久化缓存，其大致过程如下： Step1 httpdns sdk初始化 Step2 持久化缓存开启 Step3 持久化缓存记录更新到内存缓存 Step4 调用getIpByHostAsync Step5 检查ip是否合法 Step6 拿到ip，发起http请求 采用持久化缓存前，APP启动时发起业务请求时过程： 采用持久化缓存后的过程如下： 有了持久化缓存，app首屏启动就能立刻拿到解析好的ip，同时，阿里云httpdns sdk内部的过期机制也能保证拿到ip的可靠性。此外，网络切换发生后，SP（Server Provider，服务提供商）也可能发生变化，相同Host在不同SP下获取的ip也会区别对待。httpdns sdk会结合当前网络环境，通过SP和Host共同确定ip，让app拿到的结果更加精准。
-
发表了文章 2020-08-07
移动互联网时代 , 如何优化你的网络 —— 域名解析篇
移动互联网时代 , 如何优化你的网络 —— 域名解析篇 阿里云 移动服务 泠茗 域名(Domain Name)，是由一串用点分隔的名字组成的互联网上某台计算机或某组计算机的标识，它的目的是为了方便人们更简单便捷地访问互联网上的服务。在实际的系统实现中，域名通过DNS（Domain Name System）系统转化为服务器的IP地址，以方便机器通过IP进行寻址和通信。上述行为，我们称之为域名解析。 作为一次网络通信最前置的环节，域名解析的重要性不言而喻。在传统的基于浏览器的网站访问场景下，域名解析环节由浏览器内核实现，网站开发者无需关心域名解析的细节。But there are always two sides to every coin，一旦域名解析环节发生异常，开发者面对这样的黑盒架构就会显得束手无策，一个很典型的例子即域名劫持问题，关于这一点我们在后文会有更详细的介绍。 进入移动互联网时代，大量的应用基于C/S架构构建。相较于传统的面向浏览器的Web App，C/S架构的应用赋予了我们非常大的软件定制空间，开发者甚至可以渗透到整个应用的底层网络实现当中，域名解析环节的优化因此变为了可能。本篇文章我们就一起来看一看传统域名解析存在的问题，对应的根源，以及可能的优化方案。 关于域名解析，你应该知道的基本概念 在了解传统域名解析的流程之前，有几个专有名词我们需要了解一下： 根域、顶级域、二级域 DNS系统一般采用树状结构进行组织，以ru.wikipedia.org为例，org为顶级域名，wikipedia为二级域名，ru为三级域名，域名树状组织结构如下图所示。 权威DNS 权威DNS即最终决定域名解析结果的服务器，开发者可以在权威DNS上配置、变更、删除具体域名的对应解析结果信息。阿里云云解析（ https://wanwang.aliyun.com/domain/dns ）即权威DNS服务提供商。 递归DNS 递归DNS又称为Local DNS，它没有域名解析结果的决定权，但代理了用户向权威DNS获取域名解析结果的过程。递归DNS上有缓存模块，当目标域名存在缓存解析结果并且TTL未过期时（每个域名都有TTL时间，即有效生存时间，若域名解析结果缓存的时间超过TTL，需要重新向权威DNS获取解析结果），递归DNS会返回缓存结果，否则，递归DNS会一级一级地查询各个层级域名的权威DNS直至获取最终完整域名的解析结果。关于域名解析的具体流程下文会举例说明。 公共DNS 公共DNS是递归DNS的一种特例，它是一种全网开放的递归DNS服务，而传统的递归DNS信息一般由运营商分发给用户。一个比较典型的公共DNS即Google的8.8.8.8，我们可以通过在操作系统配置文件中配置公共DNS来代替Local DNS完成域名解析流程。 在实际的使用过程中，我们通常不需要手工指定自己的Local DNS地址。运营商会通过DHCP协议在系统网络初始化阶段将Local DNS地址分配给我们的计算机。当我们需要使用公共DNS服务时，我们就必须手工指定这些服务的地址。以Linux为例，我们可以通过在'/etc/resolv.conf'中添加Local DNS地址项来改变本机Local DNS的地址。 了解了上述域名解析相关的常见术语，我们再来仔细看一看一次域名解析流程具体是如何发生的。 如上图所示，以访问www.taobao.com为例，一次完整的域名解析流程包括： 终端向Local DNS发起域名解析请求； Local DNS在获取到域名解析请求后首先从Root hints获取根域名服务器的地址（Root hints包含了互联网DNS根服务器的地址信息）； 获取了根域名服务器地址后Local DNS向根域名服务器发起DNS解析请求，根域名服务器返回com顶级域名服务器地址； 随后Local DNS向com域名服务器发起解析请求，并得到taobao.com二级域名服务器的地址； Local DNS向taobao.com二级域名服务器发起解析请求，并最终获得了www.taobao.com的IP地址信息； Local DNS将递归查询获得的IP地址信息缓存并返回给客户端； Local DNS服务器包含缓存模块，在实际域名解析过程中Local DNS服务器会首先查询缓存，缓存命中且解析结果TTL未过期的情况下直接返回，否则才启动递归查询的流程。 传统的域名解析面临的问题 了解了域名解析的基本概念和整体流程，我们再一起来探究一下传统域名解析存在的一系列问题。 域名劫持 域名劫持一直是困扰许多开发者的问题之一，其表现即域名A应该返回的DNS解析结果IP1被恶意替换为了IP2，导致A的访问失败或访问了一个不安全的站点。下面我们一起看看几种常见的域名劫持的场景。 一种可能的域名劫持方式即黑客侵入了宽带路由器并对终端用户的Local DNS进行篡改，指向黑客自己伪造的Local DNS，进而通过控制Local DNS的逻辑返回错误的IP信息进行域名劫持。另一方面，由于DNS解析主要是基于UDP协议，除了上述攻击行为外，攻击者还可以监听终端用户的域名解析请求，并在Local DNS返回正确结果之前将伪造的DNS解析响应传递给终端用户，进而控制终端用户的域名访问行为。 上述攻击行为的影响面相对比较有限，另一种我们最常碰到的域名劫持现象是缓存污染。我们知道在接收到域名解析请求时，Local DNS首先会查找缓存，如果缓存命中就会直接返回缓存结果，不再进行递归DNS查询。这时候如果Local DNS针对部分域名的缓存进行更改，比如将缓存结果指向第三方的广告页，就会导致用户的访问请求被引导到这些广告页地址上。 对比第一种攻击，这类缓存污染往往能带来更明显的群体伤害，比如某个省份某个运营商的用户群可能因为该地区Local DNS的缓存污染而导致访问服务异常。这类缓存污染行为往往是间歇性、局部性发生的，没有明显的规律，导致开发者很难对其进行量化、评估、预防。 有的同学可能会问，“我使用了HTTPS，是否就可以避免域名劫持的问题”，答案是否定的。域名解析环节发生在网络加密请求交互之前，试想一下，如果客户端还没有服务端的确切地址信息，我们又如何知道应该和谁进行加密的握手协商与通信呢？ 调度不精准 除了域名劫持问题，基于传统Local DNS的域名解析还会带来域名调度精准性的问题。对于类似CDN域名访问这类需要按地域、运营商进行智能解析调度的场景，精准调度的诉求是十分强烈的。 关于调度不精准的原因，我们主要可以从两个方面来探究一下。第一个常见的问题即解析转发。 部分Local DNS供应商为了降低运营成本，会将请求到自己节点的域名解析请求转发给其他供应商的Local DNS节点，如上图所示。假如用户请求解析一个CDN域名cdn.aliyun.com，用户分配到的Local DNS A为了节省成本，把该次请求转发给了另一运营商的Local DNS B，权威DNS在进行域名解析时会根据Local DNS的IP信息进行智能调度，即权威DNS会根据Local DNS B的IP78.29.29.1进行调度，分配与78.29.29.1相同运营商并且地理位置最近的CDN节点78.29.29.2，然而这个CDN节点对于终端135.35.35.1而言并不是最优的CDN节点，他们分属不同的运营商，并且地理位置上可能相隔很远。这类解析转发行为会严重影响域名解析的精准性并对用户业务访问延迟带来影响。 除了解析转发对调度精准性带来的影响外，Local DNS的布署情况同样影响着域名智能解析的精准性。 如上图所示，部分运营商Local DNS的布点受成本因素制约分布并不均匀，比如在东部地区部署比较密集，但在西部地区部署比较稀疏。这时候当一位西藏的用户准备访问CDN节点时，我们预期他应该会被调度到西藏的CDN节点A上以实现就近接入和访问加速。但由于Local DNS的资源有限，西部地区的终端用户被统一调度到青海的Local DNS B上，这时候权威DNS根据Local DNS B的IP进行CDN域名的智能解析，并将青海的CDN节点B返回给西藏用户，导致用户的网络访问延迟上升。另一种我们实际发现的情况是Local DNS的分配甚至并非遵循就近原则，比如有实际案例显示西藏的用户甚至被分配了北京的Local DNS节点C，导致西藏的用户在进行CDN资源访问时被调度到了北京的CDN节点C上，类似的由于调度精度的缺失带来的访问体验的影响是非常严重的。 解析生效滞后 部分业务场景下开发者对域名解析结果变更的生效时间非常敏感（这部分变更操作是开发者在权威DNS上完成的），比如当业务服务器受到攻击时，我们需要最快速地将业务IP切换到另一组集群上，这样的诉求在传统域名解析体系下是无法完成的。 Local DNS的部署是由各个地区的各个运营商独立部署的，因此各个Local DNS的服务质量参差不齐。在对域名解析缓存的处理上，各个独立节点的实现策略也有区别，比如部分节点为了节省开支忽略了域名解析结果的TTL时间限制，导致用户在权威DNS变更的解析结果全网生效的周期非常漫长（我们已知的最长生效时间甚至高达48小时）。这类延迟生效可能直接导致用户业务访问的异常。 延迟大 DNS首次查询或缓存过期后的查询，需要递归遍历多个DNS服务器以获取最终的解析结果，这增加了网络请求的前置延时时间。特别是在移动互联网场景下，移动网络质量参差不齐，弱网环境的RTT时间可能高达数百毫秒，对于一次普通的业务请求而言，上述延时是非常沉重的负担。另一方面，弱网环境下的解析超时、解析失败等现象屡见不鲜，如何合理优化DNS解析对于整体网络访问质量的提升至关重要。 HTTPDNS 通过上文的介绍，聪明的读者应该可以发现，传统域名解析面临的诸多问题与挑战本质根源在于Local DNS的服务质量不可控，如果有一个更安全、稳定、高效的递归DNS服务帮助我们代理了域名解析的过程，上述问题看起来就可以彻底地得到解决。 HTTPDNS在这样的背景下应运而生。我们一起来看看HTTPDNS的基本概念以及它是如何解决传统DNS解析面临的问题的。 防域名劫持 HTTPDNS使用HTTP协议进行域名解析，代替现有基于UDP的DNS协议，域名解析请求直接发送到HTTPDNS服务端，从而绕过运营商的Local DNS，如下图所示。 HTTPDNS代替了传统的LocalDNS完成递归解析的功能，基于HTTP协议的设计可以适用于几乎所有的网络环境，同时保留了鉴权、HTTPS等更高安全性的扩展能力，避免恶意攻击劫持行为。另一方面，商业化的HTTPDNS服务（ https://www.aliyun.com/product/httpdns ）缓存管理有严格的SLA保障，避免了类似Local DNS的缓存污染的问题。 精准调度 传统域名解析的调度精准性问题，本质根源在于Local DNS的部署和分配机制上。由于碎片化的管理方式，这些环节的服务质量同样很难得到保障。HTTPDNS在递归解析实现上优化了与权威DNS的交互，通过edns-client-subnet协议（ https://datatracker.ietf.org/doc/rfc7871 ）将终端用户的IP信息直接交付给权威DNS，这样权威DNS就可以忽略Local DNS IP信息，根据终端用户的IP信息进行精准调度，避免Local DNS的坐标干扰（当然上述精准调度方案的前提是权威DNS需要支持edns-client-subnet，可喜的是当前主流的权威DNS服务都已支持该协议）。精准调度的流程示例如下。 实时生效 在域名解析生效周期方面，HTTPDNS也有着传统域名解析体系所无法具备的能力。前文中我们提到由于各个地区的Local DNS是独立维护的，服务质量参差不齐，缓存实现不一，因此导致的解析变更全网生效滞后的问题，在商业化的HTTPDNS服务上就不会存在（HTTPDNS严格遵循DNS TTL限制进行缓存更新）。另一方面，即便我们假设Local DNS严格遵循域名TTL时间进行缓存管理（这里我们假设开发者配置的域名TTL时间为5min），当开发者业务受到攻击并需要快速进行切换时，Local DNS也会遵循域名TTL，在持续5min的时间段内返回旧IP信息，这5min的业务影响对于中大型企业而言是一个不小的损失（对于电商类的大型企业，5min的访问异常可能意味着几百万的交易额下跌）。以阿里云HTTPDNS服务（ https://www.aliyun.com/product/httpdns ）为例，HTTPDNS在快速生效方面有专有的方案，配合阿里云的权威DNS服务云解析（ https://wanwang.aliyun.com/domain/dns ），用户在权威DNS变更的解析结果将快速同步给HTTPDNS，覆盖原有的缓存记录，帮助用户实现秒级的域名解析切换。 在DNS解析延迟方面，由于HTTPDNS基于HTTP协议，而HTTP基于TCP协议，对比传统的UDP传输多了一些冗余的握手环节，因此从原理上而言网络请求方面的开销并没有降低。但在实际使用过程中，我们可以通过端上的策略来实现一个零延迟DNS解析的方案。接下来我们一起来看看HTTPDNS服务在移动端的最佳实践方案。实时生效的流程如下图所示。 域名解析最佳实践 通过HTTPDNS服务，我们可以实现包括防止域名劫持、精准调度、实时解析生效等功能，但在DNS解析开销的优化上，我们需要客户端一起配合。 预解析 绝大多数的APP在应用初始化阶段都有一个启动期，我们可以在这个启动期做一些preflight工作，即在初始化阶段我们可以针对业务的热点域名在后台发起异步的HTTPDNS解析请求。这部分预解析结果在后续的业务请求中可以直接使用，进而消除首次业务请求的DNS解析开销，提升APP首页的加载速度。 在客户端实际使用HTTPDNS的过程中，有一个大家需要关注的点。标准的Web服务器（以Nginx为例）一般会将HTTP请求头中的Host头的值作为请求的域名信息进行处理（取决于服务端的配置，但一般情况都如此）。比如当我们通过标准的网络库访问www.aliyun.com/index.html这个地址时，发出的网络请求一般是这样的： > GET /index.html HTTP/1.1> Host: www.aliyun.com> User-Agent: curl/7.43.0> Accept: / 使用HTTPDNS后，我们需要将HTTP请求URL中的Host域（注意这里的Host域指的是URL中的Host字段，而非HTTP请求头中的Host头）替换为HTTPDNS解析获得的IP，这时由于标准的网络库会将URL中的Host域赋值给HTTP请求头中的Host头，发出的网络请求如下： > GET /index.html HTTP/1.1> Host: 140.205.63.8> User-Agent: curl/7.43.0> Accept: / 上述Host信息将导致服务端的解析异常（服务端配置的是域名信息，而非IP信息，试想一下如果我们的服务端服务了两个域名www.a.com和www.b.com，这时候它接收到一个140.205.63.8/index.html请求，它如何判断应该返回a的首页还是b的首页信息呢？）。为了解决这个问题，我们需要主动设置HTTP请求Host头的值，以Android的官方网络库HttpURLConnection为例： String originalUrl = “http://www.aliyun.com/index.html";URL url = new URL(originalURL);String originalHost = url.getHost();// 同步获取IPString ip = httpdns.getIpByHost(originalHost);HttpURLConnection conn;if (ip != null) { // 通过HTTPDNS获取IP成功，进行URL替换和Host头设置 url = new URL(originalUrl.replaceFirst(originalHost, ip)); conn = (HttpURLConnection) url.openConnection(); // 设置请求Host头 conn.setRequestProperty("Host", originHost); } else { conn = (HttpURLConnection) url.openConnection(); } 主动设置Host头后，发出的网络请求就与未替换URL的网络请求一模一样了。 智能缓存 通过预解析获取的IP有一定的TTL有效时间，我们需要合理地缓存下来进行管理。操作系统本身的DNS缓存粒度比较粗，在客户端我们可以应用更细粒度的缓存管理来提升解析效率。比如在不同的网络运营商环境下，对CDN域名的解析结果会发生变化，当我们使用电信WIFI时，DNS解析会返回就近的电信CDN节点IP，当我们使用联通3G时，DNS解析会返回就近的联通CDN节点IP，针对不同运营商的解析结果缓存可以确保我们在网络切换时能够快速地进行网络请求，减免DNS解析带来的额外开销。甚至更激进的，我们可以做本地的持久化缓存，当下一次APP启动时直接读取缓存用于网络访问，以提升首屏加载的速度。 懒加载 懒加载策略的实施可以让我们真正实现DNS的零延迟解析。所谓懒加载策略，核心的实现思路如下： 业务层的域名解析请求只和缓存进行交互，不实际发生网络解析请求。如果缓存中存在记录，不论过期与否，直接返回业务层缓存中的记录； 如果缓存中的记录已过期，后台发起异步网络请求进行HTTPDNS解析； 有的同学可能会有疑惑，返回一个过期的IP岂不是违背了TTL设计的初衷？的确，上述行为并不符合标准的规范，但是当我们重新审视一下自己的业务特点，上述的变通策略就显得非常有意义了。绝大多数的业务场景下我们的后端IP是固定的若干个节点，因此连续的解析结果在环境不变的情况下有很大概率是保持一致的，这在一定程度上保证了懒加载的可行性。另一方面，即便我们由于返回过期IP导致了访问异常的行为，后台很快会进行新IP的异步解析和缓存更新，业务本身可以进行重试和快速的复原，因此上述行为带来的影响也是非常小的。再进一步，TTL过期的IP的服务在绝大多数场景下还是持续的，可预期的，因此懒加载可能带来的业务风险是完全可控的。通过0.1%场景下的业务瞬时访问风险来换取99.9%场景下的用户体验提升，这笔买卖还是非常划算的（当然懒加载的使用有赖于合适的业务场景，如果你的业务场景下IP变化频繁，并且TTL过期的IP访问不可用，是不建议应用懒加载策略的）。 下图描绘了预解析+懒加载的实现框架： 综上可以看到，当我们需要实现零延迟解析的效果时，在客户端还是有比较多的工作需要做的。商业化的HTTPDNS服务（ https://www.aliyun.com/product/httpdns ）提供了终端SDK方便开发者进行终端上的集成和使用，推荐大家可以尝试一下。
-
发表了文章 2020-08-07
移动互联网时代，如何优化你的网络 —— 域名解析篇
移动互联网时代 , 如何优化你的网络 —— 域名解析篇 阿里云 移动服务 泠茗 域名(Domain Name)，是由一串用点分隔的名字组成的互联网上某台计算机或某组计算机的标识，它的目的是为了方便人们更简单便捷地访问互联网上的服务。在实际的系统实现中，域名通过DNS（Domain Name System）系统转化为服务器的IP地址，以方便机器通过IP进行寻址和通信。上述行为，我们称之为域名解析。 作为一次网络通信最前置的环节，域名解析的重要性不言而喻。在传统的基于浏览器的网站访问场景下，域名解析环节由浏览器内核实现，网站开发者无需关心域名解析的细节。But there are always two sides to every coin，一旦域名解析环节发生异常，开发者面对这样的黑盒架构就会显得束手无策，一个很典型的例子即域名劫持问题，关于这一点我们在后文会有更详细的介绍。 进入移动互联网时代，大量的应用基于C/S架构构建。相较于传统的面向浏览器的Web App，C/S架构的应用赋予了我们非常大的软件定制空间，开发者甚至可以渗透到整个应用的底层网络实现当中，域名解析环节的优化因此变为了可能。本篇文章我们就一起来看一看传统域名解析存在的问题，对应的根源，以及可能的优化方案。 关于域名解析，你应该知道的基本概念 在了解传统域名解析的流程之前，有几个专有名词我们需要了解一下： 根域、顶级域、二级域 DNS系统一般采用树状结构进行组织，以ru.wikipedia.org为例，org为顶级域名，wikipedia为二级域名，ru为三级域名，域名树状组织结构如下图所示。 权威DNS 权威DNS即最终决定域名解析结果的服务器，开发者可以在权威DNS上配置、变更、删除具体域名的对应解析结果信息。阿里云云解析（ https://wanwang.aliyun.com/domain/dns ）即权威DNS服务提供商。 递归DNS 递归DNS又称为Local DNS，它没有域名解析结果的决定权，但代理了用户向权威DNS获取域名解析结果的过程。递归DNS上有缓存模块，当目标域名存在缓存解析结果并且TTL未过期时（每个域名都有TTL时间，即有效生存时间，若域名解析结果缓存的时间超过TTL，需要重新向权威DNS获取解析结果），递归DNS会返回缓存结果，否则，递归DNS会一级一级地查询各个层级域名的权威DNS直至获取最终完整域名的解析结果。关于域名解析的具体流程下文会举例说明。 公共DNS 公共DNS是递归DNS的一种特例，它是一种全网开放的递归DNS服务，而传统的递归DNS信息一般由运营商分发给用户。一个比较典型的公共DNS即Google的8.8.8.8，我们可以通过在操作系统配置文件中配置公共DNS来代替Local DNS完成域名解析流程。 在实际的使用过程中，我们通常不需要手工指定自己的Local DNS地址。运营商会通过DHCP协议在系统网络初始化阶段将Local DNS地址分配给我们的计算机。当我们需要使用公共DNS服务时，我们就必须手工指定这些服务的地址。以Linux为例，我们可以通过在'/etc/resolv.conf'中添加Local DNS地址项来改变本机Local DNS的地址。 了解了上述域名解析相关的常见术语，我们再来仔细看一看一次域名解析流程具体是如何发生的。 如上图所示，以访问www.taobao.com为例，一次完整的域名解析流程包括： 终端向Local DNS发起域名解析请求； Local DNS在获取到域名解析请求后首先从Root hints获取根域名服务器的地址（Root hints包含了互联网DNS根服务器的地址信息）； 获取了根域名服务器地址后Local DNS向根域名服务器发起DNS解析请求，根域名服务器返回com顶级域名服务器地址； 随后Local DNS向com域名服务器发起解析请求，并得到taobao.com二级域名服务器的地址； Local DNS向taobao.com二级域名服务器发起解析请求，并最终获得了www.taobao.com的IP地址信息； Local DNS将递归查询获得的IP地址信息缓存并返回给客户端； Local DNS服务器包含缓存模块，在实际域名解析过程中Local DNS服务器会首先查询缓存，缓存命中且解析结果TTL未过期的情况下直接返回，否则才启动递归查询的流程。 传统的域名解析面临的问题 了解了域名解析的基本概念和整体流程，我们再一起来探究一下传统域名解析存在的一系列问题。 域名劫持 域名劫持一直是困扰许多开发者的问题之一，其表现即域名A应该返回的DNS解析结果IP1被恶意替换为了IP2，导致A的访问失败或访问了一个不安全的站点。下面我们一起看看几种常见的域名劫持的场景。 一种可能的域名劫持方式即黑客侵入了宽带路由器并对终端用户的Local DNS进行篡改，指向黑客自己伪造的Local DNS，进而通过控制Local DNS的逻辑返回错误的IP信息进行域名劫持。另一方面，由于DNS解析主要是基于UDP协议，除了上述攻击行为外，攻击者还可以监听终端用户的域名解析请求，并在Local DNS返回正确结果之前将伪造的DNS解析响应传递给终端用户，进而控制终端用户的域名访问行为。 上述攻击行为的影响面相对比较有限，另一种我们最常碰到的域名劫持现象是缓存污染。我们知道在接收到域名解析请求时，Local DNS首先会查找缓存，如果缓存命中就会直接返回缓存结果，不再进行递归DNS查询。这时候如果Local DNS针对部分域名的缓存进行更改，比如将缓存结果指向第三方的广告页，就会导致用户的访问请求被引导到这些广告页地址上。 对比第一种攻击，这类缓存污染往往能带来更明显的群体伤害，比如某个省份某个运营商的用户群可能因为该地区Local DNS的缓存污染而导致访问服务异常。这类缓存污染行为往往是间歇性、局部性发生的，没有明显的规律，导致开发者很难对其进行量化、评估、预防。 有的同学可能会问，“我使用了HTTPS，是否就可以避免域名劫持的问题”，答案是否定的。域名解析环节发生在网络加密请求交互之前，试想一下，如果客户端还没有服务端的确切地址信息，我们又如何知道应该和谁进行加密的握手协商与通信呢？ 调度不精准 除了域名劫持问题，基于传统Local DNS的域名解析还会带来域名调度精准性的问题。对于类似CDN域名访问这类需要按地域、运营商进行智能解析调度的场景，精准调度的诉求是十分强烈的。 关于调度不精准的原因，我们主要可以从两个方面来探究一下。第一个常见的问题即解析转发。 部分Local DNS供应商为了降低运营成本，会将请求到自己节点的域名解析请求转发给其他供应商的Local DNS节点，如上图所示。假如用户请求解析一个CDN域名cdn.aliyun.com，用户分配到的Local DNS A为了节省成本，把该次请求转发给了另一运营商的Local DNS B，权威DNS在进行域名解析时会根据Local DNS的IP信息进行智能调度，即权威DNS会根据Local DNS B的IP78.29.29.1进行调度，分配与78.29.29.1相同运营商并且地理位置最近的CDN节点78.29.29.2，然而这个CDN节点对于终端135.35.35.1而言并不是最优的CDN节点，他们分属不同的运营商，并且地理位置上可能相隔很远。这类解析转发行为会严重影响域名解析的精准性并对用户业务访问延迟带来影响。 除了解析转发对调度精准性带来的影响外，Local DNS的布署情况同样影响着域名智能解析的精准性。 如上图所示，部分运营商Local DNS的布点受成本因素制约分布并不均匀，比如在东部地区部署比较密集，但在西部地区部署比较稀疏。这时候当一位西藏的用户准备访问CDN节点时，我们预期他应该会被调度到西藏的CDN节点A上以实现就近接入和访问加速。但由于Local DNS的资源有限，西部地区的终端用户被统一调度到青海的Local DNS B上，这时候权威DNS根据Local DNS B的IP进行CDN域名的智能解析，并将青海的CDN节点B返回给西藏用户，导致用户的网络访问延迟上升。另一种我们实际发现的情况是Local DNS的分配甚至并非遵循就近原则，比如有实际案例显示西藏的用户甚至被分配了北京的Local DNS节点C，导致西藏的用户在进行CDN资源访问时被调度到了北京的CDN节点C上，类似的由于调度精度的缺失带来的访问体验的影响是非常严重的。 解析生效滞后 部分业务场景下开发者对域名解析结果变更的生效时间非常敏感（这部分变更操作是开发者在权威DNS上完成的），比如当业务服务器受到攻击时，我们需要最快速地将业务IP切换到另一组集群上，这样的诉求在传统域名解析体系下是无法完成的。 Local DNS的部署是由各个地区的各个运营商独立部署的，因此各个Local DNS的服务质量参差不齐。在对域名解析缓存的处理上，各个独立节点的实现策略也有区别，比如部分节点为了节省开支忽略了域名解析结果的TTL时间限制，导致用户在权威DNS变更的解析结果全网生效的周期非常漫长（我们已知的最长生效时间甚至高达48小时）。这类延迟生效可能直接导致用户业务访问的异常。 延迟大 DNS首次查询或缓存过期后的查询，需要递归遍历多个DNS服务器以获取最终的解析结果，这增加了网络请求的前置延时时间。特别是在移动互联网场景下，移动网络质量参差不齐，弱网环境的RTT时间可能高达数百毫秒，对于一次普通的业务请求而言，上述延时是非常沉重的负担。另一方面，弱网环境下的解析超时、解析失败等现象屡见不鲜，如何合理优化DNS解析对于整体网络访问质量的提升至关重要。 HTTPDNS 通过上文的介绍，聪明的读者应该可以发现，传统域名解析面临的诸多问题与挑战本质根源在于Local DNS的服务质量不可控，如果有一个更安全、稳定、高效的递归DNS服务帮助我们代理了域名解析的过程，上述问题看起来就可以彻底地得到解决。 HTTPDNS在这样的背景下应运而生。我们一起来看看HTTPDNS的基本概念以及它是如何解决传统DNS解析面临的问题的。 防域名劫持 HTTPDNS使用HTTP协议进行域名解析，代替现有基于UDP的DNS协议，域名解析请求直接发送到HTTPDNS服务端，从而绕过运营商的Local DNS，如下图所示。 HTTPDNS代替了传统的LocalDNS完成递归解析的功能，基于HTTP协议的设计可以适用于几乎所有的网络环境，同时保留了鉴权、HTTPS等更高安全性的扩展能力，避免恶意攻击劫持行为。另一方面，商业化的HTTPDNS服务（ https://www.aliyun.com/product/httpdns ）缓存管理有严格的SLA保障，避免了类似Local DNS的缓存污染的问题。 精准调度 传统域名解析的调度精准性问题，本质根源在于Local DNS的部署和分配机制上。由于碎片化的管理方式，这些环节的服务质量同样很难得到保障。HTTPDNS在递归解析实现上优化了与权威DNS的交互，通过edns-client-subnet协议（ https://datatracker.ietf.org/doc/rfc7871 ）将终端用户的IP信息直接交付给权威DNS，这样权威DNS就可以忽略Local DNS IP信息，根据终端用户的IP信息进行精准调度，避免Local DNS的坐标干扰（当然上述精准调度方案的前提是权威DNS需要支持edns-client-subnet，可喜的是当前主流的权威DNS服务都已支持该协议）。精准调度的流程示例如下。 实时生效 在域名解析生效周期方面，HTTPDNS也有着传统域名解析体系所无法具备的能力。前文中我们提到由于各个地区的Local DNS是独立维护的，服务质量参差不齐，缓存实现不一，因此导致的解析变更全网生效滞后的问题，在商业化的HTTPDNS服务上就不会存在（HTTPDNS严格遵循DNS TTL限制进行缓存更新）。另一方面，即便我们假设Local DNS严格遵循域名TTL时间进行缓存管理（这里我们假设开发者配置的域名TTL时间为5min），当开发者业务受到攻击并需要快速进行切换时，Local DNS也会遵循域名TTL，在持续5min的时间段内返回旧IP信息，这5min的业务影响对于中大型企业而言是一个不小的损失（对于电商类的大型企业，5min的访问异常可能意味着几百万的交易额下跌）。以阿里云HTTPDNS服务（ https://www.aliyun.com/product/httpdns ）为例，HTTPDNS在快速生效方面有专有的方案，配合阿里云的权威DNS服务云解析（ https://wanwang.aliyun.com/domain/dns ），用户在权威DNS变更的解析结果将快速同步给HTTPDNS，覆盖原有的缓存记录，帮助用户实现秒级的域名解析切换。 在DNS解析延迟方面，由于HTTPDNS基于HTTP协议，而HTTP基于TCP协议，对比传统的UDP传输多了一些冗余的握手环节，因此从原理上而言网络请求方面的开销并没有降低。但在实际使用过程中，我们可以通过端上的策略来实现一个零延迟DNS解析的方案。接下来我们一起来看看HTTPDNS服务在移动端的最佳实践方案。实时生效的流程如下图所示。 域名解析最佳实践 通过HTTPDNS服务，我们可以实现包括防止域名劫持、精准调度、实时解析生效等功能，但在DNS解析开销的优化上，我们需要客户端一起配合。 预解析 绝大多数的APP在应用初始化阶段都有一个启动期，我们可以在这个启动期做一些preflight工作，即在初始化阶段我们可以针对业务的热点域名在后台发起异步的HTTPDNS解析请求。这部分预解析结果在后续的业务请求中可以直接使用，进而消除首次业务请求的DNS解析开销，提升APP首页的加载速度。 在客户端实际使用HTTPDNS的过程中，有一个大家需要关注的点。标准的Web服务器（以Nginx为例）一般会将HTTP请求头中的Host头的值作为请求的域名信息进行处理（取决于服务端的配置，但一般情况都如此）。比如当我们通过标准的网络库访问www.aliyun.com/index.html这个地址时，发出的网络请求一般是这样的： > GET /index.html HTTP/1.1> Host: www.aliyun.com> User-Agent: curl/7.43.0> Accept: / 使用HTTPDNS后，我们需要将HTTP请求URL中的Host域（注意这里的Host域指的是URL中的Host字段，而非HTTP请求头中的Host头）替换为HTTPDNS解析获得的IP，这时由于标准的网络库会将URL中的Host域赋值给HTTP请求头中的Host头，发出的网络请求如下： > GET /index.html HTTP/1.1> Host: 140.205.63.8> User-Agent: curl/7.43.0> Accept: / 上述Host信息将导致服务端的解析异常（服务端配置的是域名信息，而非IP信息，试想一下如果我们的服务端服务了两个域名www.a.com和www.b.com，这时候它接收到一个140.205.63.8/index.html请求，它如何判断应该返回a的首页还是b的首页信息呢？）。为了解决这个问题，我们需要主动设置HTTP请求Host头的值，以Android的官方网络库HttpURLConnection为例： String originalUrl = “http://www.aliyun.com/index.html";URL url = new URL(originalURL);String originalHost = url.getHost();// 同步获取IPString ip = httpdns.getIpByHost(originalHost);HttpURLConnection conn;if (ip != null) { // 通过HTTPDNS获取IP成功，进行URL替换和Host头设置 url = new URL(originalUrl.replaceFirst(originalHost, ip)); conn = (HttpURLConnection) url.openConnection(); // 设置请求Host头 conn.setRequestProperty("Host", originHost); } else { conn = (HttpURLConnection) url.openConnection(); } 主动设置Host头后，发出的网络请求就与未替换URL的网络请求一模一样了。 智能缓存 通过预解析获取的IP有一定的TTL有效时间，我们需要合理地缓存下来进行管理。操作系统本身的DNS缓存粒度比较粗，在客户端我们可以应用更细粒度的缓存管理来提升解析效率。比如在不同的网络运营商环境下，对CDN域名的解析结果会发生变化，当我们使用电信WIFI时，DNS解析会返回就近的电信CDN节点IP，当我们使用联通3G时，DNS解析会返回就近的联通CDN节点IP，针对不同运营商的解析结果缓存可以确保我们在网络切换时能够快速地进行网络请求，减免DNS解析带来的额外开销。甚至更激进的，我们可以做本地的持久化缓存，当下一次APP启动时直接读取缓存用于网络访问，以提升首屏加载的速度。 懒加载 懒加载策略的实施可以让我们真正实现DNS的零延迟解析。所谓懒加载策略，核心的实现思路如下： 业务层的域名解析请求只和缓存进行交互，不实际发生网络解析请求。如果缓存中存在记录，不论过期与否，直接返回业务层缓存中的记录； 如果缓存中的记录已过期，后台发起异步网络请求进行HTTPDNS解析； 有的同学可能会有疑惑，返回一个过期的IP岂不是违背了TTL设计的初衷？的确，上述行为并不符合标准的规范，但是当我们重新审视一下自己的业务特点，上述的变通策略就显得非常有意义了。绝大多数的业务场景下我们的后端IP是固定的若干个节点，因此连续的解析结果在环境不变的情况下有很大概率是保持一致的，这在一定程度上保证了懒加载的可行性。另一方面，即便我们由于返回过期IP导致了访问异常的行为，后台很快会进行新IP的异步解析和缓存更新，业务本身可以进行重试和快速的复原，因此上述行为带来的影响也是非常小的。再进一步，TTL过期的IP的服务在绝大多数场景下还是持续的，可预期的，因此懒加载可能带来的业务风险是完全可控的。通过0.1%场景下的业务瞬时访问风险来换取99.9%场景下的用户体验提升，这笔买卖还是非常划算的（当然懒加载的使用有赖于合适的业务场景，如果你的业务场景下IP变化频繁，并且TTL过期的IP访问不可用，是不建议应用懒加载策略的）。 下图描绘了预解析+懒加载的实现框架： 综上可以看到，当我们需要实现零延迟解析的效果时，在客户端还是有比较多的工作需要做的。商业化的HTTPDNS服务（ https://www.aliyun.com/product/httpdns ）提供了终端SDK方便开发者进行终端上的集成和使用，推荐大家可以尝试一下。
-
发表了文章 2020-08-07
App如何实现就近接入？如何改善调度不准问题？
一、常规DNS调度策略原理 以CDN系统为例（其他业务系统大多采用类似的策略），来说明一下多地域部署服务如何实现用户访问请求调度的。 Step 1:客户端（假设IP地址为IP1）向Local DNS（假设IP地址为IP2）发出域名解析请求（假设请求的域名为www.taobao.com） Step 2:Local DNS代理客户端向权威服务器发起域名解析请求 Step 3：权威服务器根据域名(www.taobao.com)和IP2（对应的地域和ISP）进行调度并返回对应的解析结果。 Step 4: 客户端根据调度返回的IP发起业务访问请求。 二、调度精确性问题 2.1 问题描述 从上面的调度过程可以看出，业务系统会根据客户端的local dns IP来判断客户所处地域和运营商，并根据该地域和运营商来调度到就近的服务节点。 可以看出，当客户的Local DNS与客户的地域和运营商不匹配时，此时按照Local DNS来调度就会出现调度不精确的问题。 下面看几个来自客户的反馈（探测结果来自AliCDN昆仑探测工具）： 探测的客户端IP和Local DNS IP以及对应的地域，运营商如下所示： 客户端IP 220.249.84.** 220.249.84.** 客户端归属 武汉联通 武汉联通 Local DNS IP 183.61.13.** 222.73.134.** Local DNS 归属 珠海电信 上海电信 很容易看出，Local DNS地域和运营商与客户端都不匹配，此时按照Local DNS IP调度会对用户体验造成非常大的影响（国内跨运营商的访问延迟和带宽都存在非常大的问题，相信大家有深刻体验）。 2.2 问题影响面 根据我们的经验，影响的客户端占比在3%-7%之间。 2.3 原因 无线场景下主要由于以下两个方面因素导致： （1）国内三大运营商Local DNS布点不足且不均匀，大量流量集中在2000个以内的Local DNS上，大的Local DNS对应的流量超过5Gb （2）很多手机（尤其是山寨机）Local DNS配置不准确 如果扩展到全网（含有线访问请求），还需要考虑一个因素： （3）公共DNS（如google 8.8.8.8，阿里的223.5.5.5,223.6.6.6）导致调度系统无法识别Local DNS的具体位置。 三、解决办法 业界当前常见的解决思路都是通过获取客户端的IP来精确定位客户端地域和运营商，实现上，有三种方式： （1）HTTPDNS 客户端通过HTTP请求向httpdns服务器发出域名解析请求，此时httpdns服务器可以拿到客户端的精确IP，并基于客户端IP进行调度。 （2）edns client subnet 通过dns包中加入客户端IP信息，使得DNS调度系统可以拿到客户端IP并进行调度。 （3）http 302跳转 当调度系统给出的调度结果不准确时，业务服务器仍然可以根据客户端IP来判断调度是否合理，并且在必要时通过302跳转来实现重定向进而实现精确调度。 三种方式的优缺点对比如下： 客户端修改 Local DNS修改 权威DNS修改 系统开销 使用范围 HTTPDNS 有 无 低 最广 edns client subnet 无 需支持edns client subnet 需支持edns client subnet 低 中等 http 302 有(需支持302跳转) 无 高 最差 HTTPDNS综合来看是最优的解决方案，当前阿里云已经推出了HTTPDNS商业化产品。
-
发表了文章 2020-08-07
如何让App首屏启动更快 -- httpdns持久化缓存方案
首屏启动之痛 对于大部分app而言，首屏启动是最为关键的场景之一，一旦出现阻塞将直接影响到用户体验，为此阿里云httpdns sdk推荐异步接口getIpByHostAsync来获取ip，其大致过程如下： 用户从调用getIpByHostAsync接口大致会经历： （1）内存缓存检查 （2）ip合法性检查 （3）异步httpdns请求 从流程中可以看出，由于httpdns请求是异步的，对于app首屏场景来说，httpdns可能正在解析途中，app在解析结果返回前会拿到空的ip，转而去做Local DNS解析。 解决之道：持久化缓存 为了追求极致的性能体验，尽量避免首屏启动时的Local DNS解析，本文推出httpdns的持久化缓存方案，新增接口： void setCachedIPEnabled(boolean enable); 初始化示例： service = HttpDns.getService(getApplicationContext(), ACCOUNT_ID); service.setCachedIPEnabled(true); 当setCachedIPEnabled(true)被调用时，httpdns解析记录从持久化缓存同步到内存缓存。httpdns请求成功，解析记录会同步更新到内存缓存和持久化缓存，其大致过程如下： Step1 httpdns sdk初始化 Step2 持久化缓存开启 Step3 持久化缓存记录更新到内存缓存 Step4 调用getIpByHostAsync Step5 检查ip是否合法 Step6 拿到ip，发起http请求 采用持久化缓存前，APP启动时发起业务请求时过程： 采用持久化缓存后的过程如下： 有了持久化缓存，app首屏启动就能立刻拿到解析好的ip，同时，阿里云httpdns sdk内部的过期机制也能保证拿到ip的可靠性。此外，网络切换发生后，SP（Server Provider，服务提供商）也可能发生变化，相同Host在不同SP下获取的ip也会区别对待。httpdns sdk会结合当前网络环境，通过SP和Host共同确定ip，让app拿到的结果更加精准。
2020年11月
-
11.04 10:30:08
发表了文章
2020-11-04 10:30:08
如何购买阿里云服务器ECS更便宜实惠？
为了让新手了解去服务器，本期我们主要介绍如何购买阿里云ECS服务器，希望能通过我的经验，能帮助到大家！
2020年10月
-
10.31 21:30:16发表了文章
2020-10-31 21:30:16
阿里云服务器1核2GB5M配置仅需201元/年
阿里云活动出现了一款性价比极高的云服务器，1核2GB 5M只要201元 。明星机型——售价91元的1核2GB 1Mb的T5型云服务器。两款云服务器价格都非常便宜，但我这边强烈推荐大家买5M带宽的云服务器。 -
10.31 21:28:06发表了文章
2020-10-31 21:28:06
阿里云服务器双十一配置仅需85元/年
阿里云服务器双十一配置仅需85元/年
-
10.08 09:18:25发表了文章
2020-10-08 09:18:25
阿里云GPU云服务器抢占式实例大幅度降低GPU云服务器实例成本
简介： 阿里云GPU云服务器可以选择抢占式实例（原竞价实例），可以降低GPU服务器成本 -
10.08 09:16:34发表了文章
2020-10-08 09:16:34
阿里云心选商城—网站建设篇之——云·企业官网定制
使用阿里云建站可以有三种，第一种是购买ECS云服务器；第二种方式是购买阿里云官网云速成美站；第三种是使用阿里云官方定制建站。 -
10.04 16:14:30发表了文章
2020-10-04 16:14:30
阿里云服务器操作系统怎么选择？
阿里云ECS云服务器操作系统分为Windows类和Linux类，下面我们一起探讨下阿里云服务器的windows和linux系统怎么选及操作系统32位和64位的区别：
-
10.04 15:55:19发表了文章
2020-10-04 15:55:19
2020年国内十大云计算商排名榜
云计算在中国经过数年发展后，技术和市场都越发成熟。随着性能和稳定的提高，成本的降低，个人和企业用户都开始逐步接受云服务，但无论在全球范围还是中国范围内，云计算市场还只是起步阶段。 中国云市场来看，表面看似巨头已经瓜分天下，但实际上，出色的新秀在不断涌现，利用自己的特色优势在细分市场中分一杯羹。笔者根据企业实力，产品性能、性价比、服务评价等方面选出了市场认可度高的中国十大公有云计算服务商云计算服务商。 -
10.04 12:29:27发表了文章
2020-10-04 12:29:27
阿里云服务器进入黑洞怎么办？如何查看进入黑洞时间与原因
阿里云服务器进入黑洞怎么办？阿里云服务器黑洞如何解封？阿里云黑洞多长时间？什么是黑洞？如何提高防护免遭黑洞？笔者来详细说下阿里云服务器黑洞策略常见问题及解答，以及阿里云黑洞解除方法： -
10.04 12:20:13发表了文章
2020-10-04 12:20:13
阿里云服务器4核8G支持多少在线用户并发访问？
阿里云服务器4核8G配置可以容纳多少人同时在线访问呢？阿里云10M带宽支持多少并发数？阿里云4核8G服务器配置如何选择？阿里云服务器10M带宽费用多少？笔者来详细说下：
-
10.04 12:01:45发表了文章
2020-10-04 12:01:45
阿里云/腾讯云/UCloud/华为云服务器主机对比测试报告
在2020年初之际，国内专业的云资源选型服务平台CloudBest旗下监测实验室，针对业界4家主流的云服务提供商，包括阿里云、腾讯云、UCloud与华为云进行了横向评测。本次测试在尽量保证测试环境相同的情况下，提供客观公正的测试数据，从技术层面对云服务提供商提供的云主机产品进行性能(CPU、磁盘、网络等)与性价比评测。以下为CloudBest监测实验室详细测试报告：
-
10.04 10:38:48发表了文章
2020-10-04 10:38:48
阿里云服务器租用价格表（2020年最新版）
阿里云服务器价格收费标准是多少？很多企业与站长想一览阿里云服务器价格，便于清晰了解前期项目开支预算，因此，笔者呕心沥血整理出阿里云服务器价格表，因不同地域宽带价格有所差异，所以不同地域节点的云服务器价格也有所不同。 -
10.04 10:31:35发表了文章
2020-10-04 10:31:35
史上最详细阿里云服务器搭建网站流程（图文教程）
新手如何用阿里云服务器Linux系统安装宝塔面板搭建WordPress博客网站呢？WordPress作为全球实用最广泛的CMS系统，以功能强大、扩展性强，插件众多，易扩充功能等特点，受到全球站长开发者青睐。而阿里云作为国内用户量最多的云服务器商，因此，本文以阿里云为例，详细介绍云服务器Linux系统如何安装宝塔面板搭建WordPress博客网站。 -
10.03 13:21:28发表了文章
2020-10-03 13:21:28
Linux中如何统计某个字符串个数？
在 Linux 系统下，有时候，我们可能要对一个日志文件进行分析。比如，分析日志文件中某个单词或者某个特殊字符串出现了多少次。 -
10.03 13:08:42发表了文章
2020-10-03 13:08:42
5G风起，未来数据库将会如何发展？
在自己工作的领域中，发现快乐是我坚持做技术的动力。而技术域其实就是一个画圆的过程，当你发现你的圈圈画得越大，需要求知的东西也就越多。每天必须保持一种持续学习，和与技术死磕的精神才能促使我们不断前行。我们不断前行，时代也在不断变化和发展。本文由变化看发展，从移动通讯发展的历程同步透视数据库能力的变迁，进而预测5G时代将会给数据库带来的重大变革。
-
10.03 12:31:35发表了文章
2020-10-03 12:31:35
公有云、私有云及混合云应用场景辨析
近几年我们经常能看到一些研究公司（Gartner朋友Alice Yang语，“我们是研究公司”）、咨询机构发布关于公有云、私有云以及混合云的市场趋势分析，种种“公有云是未来发展趋势”、“混合云是主流”等观点层出不穷。在此，笔者试图抛开趋势，仅从应用场景角度分析，试图阐述当前国内各类云的客户群体、供应商、服务和技术特点。 -
10.03 10:45:49发表了文章
2020-10-03 10:45:49
企业级IaaS架构的深度解析
根据IDC的分析报告，美国和中国云计算产业发展差异巨大：美国以公有云为主，SaaS最大、IaaS最小；而中国截然相反，以私有云为主，IaaS占了大约50%的份额。
-
10.03 10:26:32发表了文章
2020-10-03 10:26:32
阿里云服务器的系统盘与数据盘有什么区别？
阿里云ECS云服务器分为系统盘和数据盘，二者有什么区别呢？下面笔者科普ECS云服务器系统盘和数据盘的区别： -
10.03 10:23:10发表了文章
2020-10-03 10:23:10
阿里云突发性能T5实例与全新T6实例和有什么区别？
有细心的小伙伴应该发现了，阿里云最近新推出了全新突发性能实例规格族T6，很多用户都只知道突发性能实例规格族T5，那么T6跟T5有什么区别呢？一起来看看
-
10.03 10:19:25发表了文章
2020-10-03 10:19:25
学习Linux如何能事半功倍，明确这7点技巧！一位Linux大牛的心得分享
如今有很多关于Linux的书籍，博客。大多数都会比较“粗暴“的将一大堆的命令塞给读者，从而使很多Linux初学者望而却步，未入其门就路过了。 -
10.01 15:55:17发表了文章
2020-10-01 15:55:17
阿里云服务器部署Node.js项目
Node.js是一个基于Chrome V8引擎的JavaScript运行环境，用来方便快速地搭建易于扩展的网络应用。Node.js使用了一个事件驱动、非阻塞式I/O的模型，使其轻量又高效，非常适合运行在分布式设备的数据密集型的实时应用。Node.js的包管理器npm，是全球最大的开源库生态系统。Node.js的典型应用场景包括： -
10.01 15:36:46发表了文章
2020-10-01 15:36:46
基于阿里云CDN配置https协议教程
如今，https访问已经是不可置疑的大势所趋，阿里云很多产品都可以配置https访问，如果我们已经购买了阿里云虚拟主机、CDN以及ECS云服务器产品，可以参考以下步骤配置https访问。 -
10.01 13:12:31发表了文章
2020-10-01 13:12:31
阿里云服务器如何选择？ECS云服务器配置规格选择指南及使用体验
阿里云ECS云服务器如何选择？其中云服务器配置CPU、内存及宽带的选择，另外包括ECS云服务器规格的选择，笔者来说说阿里云ECS云服务器配置选择、规格说明及使用体验。 -
10.01 12:55:49发表了文章
2020-10-01 12:55:49
阿里云IIS服务器SSL证书安装
阿里云IIS服务器SSL证书安装 -
10.01 12:48:01发表了文章
2020-10-01 12:48:01
编程技巧总结
编程技巧总结 -
10.01 12:13:59发表了文章
2020-10-01 12:13:59
C++ 虚函数表解析
C++中的虚函数的作用主要是实现了多态的机制。关于多态，简而言之就是用父类型别的指针指向其子类的实例，然后通过父类的指针调用实际子类的成员函数。这种技术可以让父类的指针有“多种形态”，这是一种泛型技术。所谓泛型技术，说白了就是试图使用不变的代码来实现可变的算法。比如：模板技术，RTTI技术，虚函数技术，要么是试图做到在编译时决议，要么试图做到运行时决议。
2020年09月
-
09.30 23:54:45发表了文章
2020-09-30 23:54:45
阿里云服务器如何开发APP、门户网站？高可用架构常见场景v
“高可用性”（High Availability）通常来描述一个系统经过专门的设计，从而减少停工时间，而保持其服务的高度可用性。所以当我们一说到高可用，我们满脑子都是以负载均衡为主心骨搭建的拓扑图，以他为中心，从单节点拓展为多节点，消灭单点故障。但随着我们业务架构越来越庞大复杂，那么要考虑的就不再只是服务器维度的高可用了。接下来，我来给大家介绍一下不同维度的“高可用”在架构上是如何实现的。 -
09.30 23:49:59发表了文章
2020-09-30 23:49:59
Java架构师必须掌握的 21 个 Java 核心技术！（干货）
写这篇文章的目的是想总结一下自己这么多年来使用java的一些心得体会，希望可以给大家一些经验，能让大家更好学习和使用Java。 这次介绍的主要内容是和J2SE相关的部分，另外，会在以后再介绍些J2EE相关的、和Java中各个框架相关的内容。 经过这么多年的Java开发，以及结合平时面试Java开发者的一些经验，我觉得对于J2SE方面主要就是要掌握以下的一些内容。 -
09.30 23:35:54发表了文章
2020-09-30 23:35:54
阿里云服务器双11配置仅需85元/年
阿里云服务器双十一配置仅需85元/年
-
09.30 23:27:37发表了文章
2020-09-30 23:27:37
kubernetes系列教程(三)kubernetes快速入门
kubernetes中涉及很多概念，包含云生态社区中各类技术，学习成本比较高，k8s中通常以编写yaml文件完成资源的部署，对于较多入门的人来说是个较高的门坎，本文以命令行的形式带领大家快速入门，俯瞰kubernetes核心概念，快速入门。 -
09.30 22:49:07发表了文章
2020-09-30 22:49:07
编程语言排行榜 - 2020年度最热门编程语言盘点！
工欲善其事，必先利其器。业务需求的满足，离不开移动应用框架、工具和编程语言。为了简化和加快整个开发进程，下面让我们一起来探究一下，那些对于移动应用开发人员和业务服务来说，至关重要且需要谨慎选择的最佳编程语言。
-
09.29 11:22:37发表了文章
2020-09-29 11:22:37
阿里云弹性裸金属服务器是什么?如何选择？
阿里云弹性裸金属服务器是什么呢？阿里云弹性裸金属服务器（神龙）是阿里云提供的一款超强大的云计算服务器，其不仅具备云服务器弹性的特点，还具有物理机隔离和独占资源的优势。 -
09.29 11:14:33发表了文章
2020-09-29 11:14:33
为什么要购买阿里云服务器？云服务器用途有哪些？
很多人问，为什么要购买阿里云服务器呢？阿里云服务器用途有哪些？以前，当我们需要建个新的网站时，是非常麻烦且繁琐的一件事情，这意味着除了需要花大价钱买服务器外，还需要部署、测试、验证等一系列操作。而在云服务器出现之后，这些就都不是问题了。 -
09.29 10:54:09发表了文章
2020-09-29 10:54:09
有哪些常用的 Python 标准库？
有哪些常用的 Python 标准库？
-
发表了文章
2020-11-04
如何购买阿里云服务器ECS更便宜实惠？
-
发表了文章
2020-10-31
阿里云服务器1核2GB5M配置仅需201元/年
-
发表了文章
2020-10-31
阿里云服务器双十一配置仅需85元/年
-
发表了文章
2020-10-08
阿里云GPU云服务器抢占式实例大幅度降低GPU云服务器实例成本
-
发表了文章
2020-10-08
阿里云心选商城—网站建设篇之——云·企业官网定制
-
发表了文章
2020-10-04
阿里云服务器操作系统怎么选择？
-
发表了文章
2020-10-04
2020年国内十大云计算商排名榜
-
发表了文章
2020-10-04
阿里云服务器进入黑洞怎么办？如何查看进入黑洞时间与原因
-
发表了文章
2020-10-04
阿里云服务器4核8G支持多少在线用户并发访问？
-
发表了文章
2020-10-04
阿里云/腾讯云/UCloud/华为云服务器主机对比测试报告
-
发表了文章
2020-10-04
阿里云服务器租用价格表（2020年最新版）
-
发表了文章
2020-10-04
史上最详细阿里云服务器搭建网站流程（图文教程）
-
发表了文章
2020-10-03
Linux中如何统计某个字符串个数？
-
发表了文章
2020-10-03
5G风起，未来数据库将会如何发展？
-
发表了文章
2020-10-03
公有云、私有云及混合云应用场景辨析
-
发表了文章
2020-10-03
企业级IaaS架构的深度解析
-
发表了文章
2020-10-03
阿里云服务器的系统盘与数据盘有什么区别？
-
发表了文章
2020-10-03
阿里云突发性能T5实例与全新T6实例和有什么区别？
-
发表了文章
2020-10-03
学习Linux如何能事半功倍，明确这7点技巧！一位Linux大牛的心得分享
-
发表了文章
2020-10-01
阿里云服务器部署Node.js项目
滑动查看更多
暂无更多信息
暂无更多信息