云筏 CloudRaft 是一个*不负责任的云服务厂商

事件发生在 1 月,现在有时间写一下。

在 hostloc 上搜索云筏可以搜索到它家的差评。年初至今发生了两件事,一件是无预警删除用户 cf 解析,一件是 kvm 故障无通知无道歉甚至无赔偿(赔偿下面会讲到)。

第二件发生在我两个月前购买的一台机子上,当时刚好有台服务器过期,看到它在 V2EX 上发推广,就购买了一台测试一下。然后有一天就挂了。

它家的不负责体现在:

1. 是宿主机的故障但是没有通知用户,我提的工单过了接近 9 个小时才回复说在紧急修复中。

2. 说是在紧急修复中,但故障时间从北京时间 1 月 18 号早上 10 点至 1 月 20 号早上 10 点。

3. 不会主动告知进展,要在工单中问,而且问了也得过非常久才会回。

4. 没有一点道歉的姿态,也没有一点提到赔偿以安慰用户的意思。直接我提出质疑,才发来一条表示抱歉。

我问赔偿方案,其间回复我需要与领导沟通,在某个时间点会回复我,但实际上并没有按照约定回复我。
后面又回复会帮我延期服务,但实际上没有看到有变化。

5. 提出未使用金额退款诉求,回复可以,需要确认,还没等我确认, [把还在运行的服务器直接删除了] 。

6. 我问为什么未确认就删除,其回复 24 小时没回复就会删除。我问哪条服务协议上规定,没有得到回复。期间我本来也可以去后台看到并确认,但是他们后台 SSL 证书配置错误,导致有近半天无法访问。

7. 我问退款如何计算,是否把赔偿时间算上。其回复需要转交财务,直到现在 3 月 5 号,期间我催促 3 次,一次次都说转交财务,但没有回复。直到今天我想起来一看,工单变成已处理,原因是工单超时了。

8. 退款不是原路返还而是退到了余额,提现无法提现小数部分,提现需要扣手续费,提现需要实名。我今天又提了工单。

9. 发现退款后已消费金额无法开发票。

我认为这样一个*不负责的厂商不应该能继续在 V2EX 发推广,甚至已有帖子也不应该还展示出来,避免让用户入坑。

@livid

让我们再看一次它家口号:「云筏科技 CloudRaft 重塑国人云厂商形象」。

以及它家官网上写的:7X24 小时多渠道服务支持,双倍故障赔偿。

以上内容都体现在工单中,后面我会把工单截图 append 出来。

珍惜生命,远离云筏 CloudRaft 。
回复 云筏 工单 赔偿16 条回复 • 2021-04-13 18:24:15 +08:00
lyhiving 1
lyhiving 131 天前 via iPhone
云筏这个坑我也踩了,凌晨四点收到监控说站访问不了,立刻排查,重新上。

云筏这个算是彻底在圈内挂了,另外一个是企鹅小屋。

数据很重要不要用小厂商
guizhihu 2
guizhihu 131 天前 via Android ❤️ 1
重塑(负面)形象
efaun 3
efaun 131 天前
小众的云服务还是不要用的好,有点钱就跑路了
wdhwg001 4
wdhwg001 131 天前
去看了一下官网,标称 99.99%的高可用性,一年挂了 48 个小时,就离谱。
ushio 5
ushio 131 天前 via iPhone
云筏是学生创业搞出来的,技术不行,而且感觉有点玩票的性质
Kinnice 6
Kinnice 131 天前 via Android
这可能就是他们理解的 国人云厂商形象
Livid 7
Livid V2EX Moderator 131 天前
我*次听说这个名字,V2EX 和这个公司没有任何广告服务关系。发布到 /go/promotions 节点的主题是他们的自发行为。

谢谢你分享的使用体验。

@CloudRaft 你们有什么回应吗?
airyland 8
airyland 131 天前
@Livid 我明白是他们自己发的推广帖子。

在体验过他们服务后,我认为如果他们继续以免费赠送的形式发推广帖会让更多不知情用户入坑(毕竟我就是这样去尝试他们的服务),并因此可能影响到本站的 Credit 。所以我上面表达只是从用户角度提一个建议,不清楚从管理员角度具体如何看待和是否会处理这样的问题。
ragnaroks 9
ragnaroks 131 天前
国内有个专有名词“小学生云”,指的就是这类没有任何实际保障的“云”;

选用国内的 vps 服务,需要先去 hostloc 搜下有没有真实负面情况,如果有的话就可以忽略了(当然你会发现国内没有能用的了)
Livid 10
Livid V2EX Moderator 130 天前 via iPhone
@airyland 我已经 @ 他们。如果他们继续没有回应,那我们会彻底处理这个帐号。

11
tms 129 天前
同被半夜删过解析的路过。还不止一次。
chenjies 12
chenjies 128 天前
号称独享一核的 1C2G VPS 盒子,安装 ubuntu desktop 用了一个多小时,以及这家提供的 ubuntu 系统,ufw 竟然还要自己 ufw reset 与设置自启动。
CloudRaft 13
CloudRaft 92 天前
@Livid 感谢 @
@airyland 请问是否允许我们公开您的工单记录呢?
CloudRaft 14
CloudRaft 92 天前
服务器故障处理部分的工单因为不能断章取义,所以题主授权后我们可以公开,或者题主自己公开完整的记录?

财务情况我们这边在收到工单后 1 小时就回复了,题主没有任何答复…
![image.png]( https://i.loli.net/2021/04/13/Sg9VFcXlivBEOIo.png)
CloudRaft 15
CloudRaft 92 天前
财务的回复原文:

“`
客户您好,非常抱歉我们的服务没有使您满意。针对您的问题,我将具体回答:由于订单日期或者部分退款等原因,系统有时会判定为无法自主申请开票的情形,如有需求可工单联系要求我们为您开具;提现手续费的收取是用于平衡支付宝平台收取的手续费,烦请谅解;系统目前不支持含小数的提现,实属无奈,我们将会竭力升级。客户余额内的所有金额均可用于正常产品购买,如确有全额提现需求,可工单至财务为您提现至支付宝。
“`
CloudRaft 16
CloudRaft 92 天前
另外客户提交的是技术工单,然后又在技术工单里咨询财务问题,工单系统可以转交至其他部门,但是一次只能一个部门。

这边翻出来工单记录查看了一下,全部都是客户这边 7 天没有回复,然后工单自动被关闭的

![image.png]( https://i.loli.net/2021/04/13/IfSMFyqGjgAVvXr.png)

Windows Server 的 RDP 连接能否做两部验证?

有没有类似手机安全令,短信验证码之类的东西实现两部验证?
验证 rdp 验证码 Server6 条回复 • 2021-07-11 17:56:11 +08:00
tsungkang 1
tsungkang 29 天前
市面上据说有些跳板机可以实现,不过貌似都需要使用配套客户端?有种变通的办法就是先 ssh 进跳板机然后再转发到 rdp
yzwduck 2
yzwduck 29 天前
有,比如 Duo Authentication for Windows Logon and RDP
trepwq 3
trepwq 29 天前 via iPhone
不知道 rdp 支持第三方账号系统不
flymeteor 4
flymeteor 29 天前 via Android ❤️ 1
https://github.com/multiOTP/multiOTPCredentialProvider
cheng6563 5
cheng6563 28 天前
@flymeteor 这玩意貌似可用,只是每次验证都要老半天,让人害怕。

国家统计局新闻发言人就2021年上半年国民经济运行情况答记者问

(2021年7月15日) 中央广播电视总台央视记者: 从刚刚发布的数据来看,我们看到中国上半年的经济两年平均增速比一季度有所加快,您认为有哪些因素在带动经济的增长?您如何评价上半年我国国民经济的总体表现?谢谢。 刘爱华: 谢谢你的提问。从刚才介绍的各个方面的数据来看,今年上半年,统筹疫情防控和经济社会发展的成果得到了持续拓展和巩固,经济运行持续稳定恢复,稳中加固、稳中向好。从特点上来讲,主要反映在五个方面: 一、经济持续恢复增长。上半年国内生产总值同比增长12.7%,其中二季度同比增长7.9%,环比增长1.3%,两年平均增长5.5%,比一季度加快0.5个百分点。从相关指标看,上半年全社会货运量同比增长24.6%,两年平均增长7.2%;初步统计,全社会用电量同比增长16.2%,两年平均增长7.1%左右。 二、经济结构调整优化。首先,产业支撑得到加强。上半年服务业增加值对经济增长的贡献率达到了53%,比一季度提高2.1个百分点;制造业占比得到提升,上半年制造业增加值占国内生产总值的比重为27.9%,比上年同期提高1.3个百分点。其次,消费拉动作用增强。上半年,*终消费支出对经济增长的贡献率达到61.7%,高于资本形成总额42.5个百分点;升级类商品消费较快增长,上半年限额以上单位体育娱乐用品类、通讯器材类、化妆品类的商品零售额两年平均增速都超过了10%。三是短板领域投资较快增长。上半年,高技术产业投资、社会领域投资两年平均分别增长14.6%和10.7%,分别快于全部投资10.2和6.3个百分点。四是城乡居民收入的比值缩小。上半年城乡居民人均可支配收入之比为2.61,比上年同期缩小0.07。 三、创新动能持续增强。首先,新市场主体较快增长。6月末,根据我局基本单位名录库统计,法人单位数首次突破3000万个,同比增长了16.6%。其次,新产业新产品较快增长,上半年,规模以上高技术制造业增加值两年平均增长13.2%,比一季度加快了0.9个百分点。1-5月份,规模以上高技术服务业企业利润总额同比增长27.4%,两年平均增长12.5%,快于全部规模以上服务业4.2个百分点。从产品看,上半年,新能源汽车、工业机器人、集成电路的产量同比都保持了较快增长。三是新业态新模式成长壮大。上半年,实物商品网上零售额两年平均增长16.5%,占社会消费品零售总额的比重达到了23.7%。七月初,全国快递业务量已经突破了500亿件,接近2018年全年水平。 四、质量效益总体提升。首先,企业盈利增强。1-5月份,规模以上工业企业利润总额同比增长83.4%,两年平均增长21.7%;营业收入利润率达到7.11%,比上年同期提高了2.05个百分点。1-5月份,规模以上服务业企业利润总额同比增长1.5倍。其次,财政收入继续增加,1-5月份,全国一般公共预算收入同比增长24.2%。三是产能利用率上升。二季度全国工业产能利用率为78.4%,比上年同期提高4个百分点,比一季度提高了1.2个百分点。 五、民生保障持续改善。首先,就业形势总体稳定。上半年,全国城镇调查失业率平均为5.2%,比上年同期下降0.6个百分点,比一季度下降0.2个百分点,低于5.5%左右的预期目标。全国城镇新增就业698万人,完成全年目标任务的63.5%。二季度末,外出务工农村劳动力1.8亿人,基本恢复到了2019年同期水平。其次,居民消费价格温和上涨。上半年,居民消费价格同比上涨0.5%,涨幅处于比较低的水平。三是居民收入增长与经济增长基本同步。上半年,全国居民人均可支配收入同比实际增长12%,两年平均增长5.2%,与经济增长基本同步。 从上述五个方面看,上半年国民经济可以说是持续稳定恢复,稳中加固,稳中向好。但同时也要看到,目前全球疫情仍在持续演变,外部不稳定、不确定因素比较多,国内经济恢复仍然不均衡,巩固稳定恢复发展的基础仍需努力。下一步,按照中央经济工作会议精神和政府工作报告决策部署,持续深化供给侧结构性改革,着力释放内需潜力,大力助企纾困发展,扎实推进高质量发展,努力完成全年经济社会发展的目标任务。谢谢。 彭博新闻社记者: 刚才您提到了上半年全国居民人均实际收入两年平均增长5.2%,略低于经济增速。我们之前从商务部了解到,在“十四五”时期,全国零售品销售总额预期目标是要提升5%,这是从今年到2025年之间设定的一个目标。就您刚才所发布的数据显示,居民的人均可支配收入略低于经济增速,这种情况下如何实现中国经济的再平衡?如何成功实现双循环的目标?谢谢。 刘爱华: 谢谢您的提问。从刚才公布的数据来看,今年上半年全国居民人均可支配收入实际增速两年平均达到了5.2%,这个速度和上半年GDP的两年平均增速5.3%是基本同步的。考虑到去年以来经济运行遭受疫情冲击,可以说实现5.2%的人均收入增速是相当不容易的。从具体的结构上来看,推动收入实现5.2%的增长,主要是三个方面的结构性因素。 *,随着经济持续稳定恢复,就业形势保持了总体稳定,带动了工资性收入增长比较快。今年上半年,工资性收入同比名义增长12.1%,两年平均名义增长7.2%。 第二,随着各地持续加大民生保障力度,提高了养老金标准,加强困难群体基本生活保障,及时做好社会救济和临时救助,人均转移性净收入名义增长9%,两年平均名义增长8.6%。 第三,随着疫情防控形势逐步好转,经营活动逐步恢复,经营净收入上半年同比名义增长17.5%,两年平均名义增长5.6%。实现这个增长,可以说既有经济恢复的因素,带动了就业增加,进而带动收入增加,同时也有政策支持的因素,各个地方都加大了民生保障力度。同时也有各个经济主体自身的努力。所以从这些方面来讲,5.2%的增速和经济增长基本同步,而且可以说成果是非常显著的。 从这几个方面判断,目前中国经济整体上内生动力是在持续增强的,市场主体活力也不断增强,下阶段收入增长仍然会得到比较好的支撑,从而对消费形成有力的支撑。谢谢。 香港紫荆杂志记者: 国家统计局发布的数据显示,近年来,“三新”经济增加值在GDP的占比不断提升,如何评价“三新”经济对我国经济的拉动作用?未来将如何促进“三新”经济持续快速发展?谢谢。 刘爱华: 谢谢你的提问。我们前一段时间公布了2020年“三新”经济占GDP比重的数据,首先我向大家介绍一下2020年“三新”经济基本情况。 总体上看,2020年,尽管受到了新冠肺炎疫情的巨大冲击和严峻复杂的国际形势的影响,但新产业、新业态、新商业模式继续保持了比较快的增长。全年“三新”经济增加值占比17.08%,比上年提高了0.7个百分点;“三新”经济的增加值比上年名义增长4.5%,比同期的GDP增速高1.5个百分点。“三新”经济持续加速、占比提高,可以归结于四个方面因素。 *,科技投入大幅增加。2020年,我国R&D(研究与试验发展)经费支出与GDP之比达到了2.4%,比2015年提高了0.34个百分点。 第二,科技人才队伍持续壮大。我国研发人员总量连续8年稳居世界首位。 第三,科技产业化步伐不断加快。工业化和信息化的融合不断深化,科技成果转化应用加快,带动新产业快速发展。“十三五”期间,高技术制造业增加值年均增长10.3%,明显快于全部规模以上工业增加值。 第四,政策支持力度不断加大。疫情对新产业的发展既是挑战也是机遇,我国积*应对挑战,努力化危为机,针对重点领域出台了一系列有针对性的支持举措。比如,加快完善以企业为主体的技术创新体系、采取研发费用加计扣除减免税等创新支持政策,加大“双创”力度,创新引领作用显著增强,有力地促进了新产业、新业态的成长壮大。 从今年上半年情况看,“三新”经济的快速成长发展态势得到了延续。刚才我给大家介绍了高技术产业增加值、新产品的增长情况,还有新商业模式的增长状况,可以看出,“三新”经济的快速增长对今年上半年国民经济的持续稳定恢复发挥了重要作用。从更长期的角度来看,对加快构建新发展格局也提供了强有力的战略支撑。谢谢。 香港经济导报记者: 请问怎么看待“双碳”目标对经济运行的压力?一些地方为了降能耗会采取比较激进的措施,比如对高耗能企业实施限产,以煤电为例,短期内如果限产量过大,可能会对煤电的供应造成不稳定,造成部分地方出现电力紧张的局面,也会影响到经济稳定增长。您认为地方该如何处理好绿色转型和稳增长的关系?谢谢。 刘爱华: 谢谢你的提问。当前中国经济已经由高速增长阶段转向高质量发展阶段,碳达峰、碳中和既是我们向世界的一个庄严承诺,也是高质量发展的必然要求,是现代化进程的必由之路。从我们当前的发展阶段看,目前仍然是世界上*大的发展中国家,还没有完成工业化的进程。在这个阶段,我们要实现碳达峰、碳中和,确实是任务很重,压力很大。 但是也要看到,推动绿色转型发展,可能会抑制部分高耗能行业、高排放行业的短期增长。但与此同时,绿色转型发展也将创造新的需求,催生新的产业,像节能环保、清洁能源这样的绿色行业,将迎来新的发展机遇,传统行业的绿色转型升级也将创造巨大的市场需求,所以我们还是要抓住这个历史机遇,积*应对挑战,推动中国经济行稳致远。谢谢。 封面新闻记者: 想请问发言人如何评价上半年的就业数据,今年高校毕业生的就业形势如何?数据显示,16-24岁人口的调查失业率达到了15.4%,比一季度末增加了近2个百分点。请问如何看待这一趋势的变化?谢谢。 刘爱华: 谢谢您的提问。从今年上半年总体来看,就业形势总体稳定。上半年在一系列减负稳岗扩就业政策的作用下,全国城镇调查失业率上半年平均是5.2%,比上年同期下降了0.6个百分点,比一季度下降了0.2个百分点。从各月的情况看,除了2月份是5.5%之外,其他的几个月都在5.5%以下。5、6月份全国城镇调查失业率都是5%,均比上年同月低了0.7个百分点。城镇调查失业率的回落,主要归因于经济持续稳定恢复和稳就业政策。从主要劳动年龄人口失业率来看,25-59岁主要劳动年龄人口失业率6月份下降到了4.2%,比上年同月低了1个点。从月度之间看,也是持续回落的。 当然,在看到总量稳定的同时,也要看到就业结构性矛盾凸显。就像您刚才提到的,随着6月份毕业季的到来,进入劳动力市场求职的高校毕业生不断增多,就业压力明显增加,带动青年失业率明显上升。6月份,16-24岁城镇的青年调查失业率为15.4%,比上个月上升了1.6个百分点,和上年同月持平。其中,20-24岁的大专及以上人员失业率还要更高一些。 从下阶段看,一方面要看到在疫情防控常态化的形势下,随着经济持续稳定恢复,劳动力市场在不断回暖,从目前了解的情况看,今年高校毕业生的就业志愿和去年相比更加趋于稳定,求职活跃度也明显上升。但是另外一方面,今年高校应届毕业生规模达到了909万人,再创历史新高,总量的就业压力确实比较大。所以,下一阶段我们还是要坚持就业优先政策,延续实施减负稳岗扩就业政策,加强对重点群体的就业帮扶,优化就业服务,扩大就业容量,巩固就业稳定的态势。谢谢。 中央广播电视总台央广记者: 我们注意到上半年固定资产投资在持续恢复,您怎么看待当前投资对经济增长的拉动作用?另外,当前投资两年平均增速和疫情前增长水平相比还是有较大差距,从下阶段来说,应该如何扩大有效投资?谢谢。 刘爱华: 谢谢你的提问。从今年上半年投资月度变化态势来看,投资呈现了持续稳定恢复的态势。上半年,固定资产投资两年平均增长4.4%,比一季度加快1.5个百分点,总体是在加快的。投资对优化供给结构的关键作用也得到了进一步的发挥,体现在三个方面:一是高技术产业投资增长比较快。上半年,高技术产业投资两年平均增长14.6%,比一季度加快4.7个百分点,其中高技术制造业投资和服务业投资增长都是在加速的。二是社会领域投资增长比较快。上半年社会领域投资两年平均增长10.7%,比一季度加快1.1个百分点;其中,卫生和社会工作投资增长20%以上。三是民间投资增速加快。上半年,民间投资两年平均增长3.8%,比一季度加快2.1个百分点。强动能的高技术投资、补短板的社会领域投资,还有反映市场活力的民间投资都是在加快的。所以总体上,有效投资对优化供给结构的关键作用得到了进一步发挥。 从下阶段判断,目前支持投资持续恢复的有利因素在不断增多。一是市场活力在逐步增强。从今年1-5月份的规上工业企业利润和服务业企业利润可以看到,企业效益普遍好转,有利于增强企业投资的信心和能力。二是资金保障比较有力。上半年固定资产投资到位资金同比增长16.8%,增速超过投资增速。三是稳投资政策持续发力。“十四五”规划确定的一批重大工程项目在陆续部署推进。从我们掌握的情况看,6月份新入库的5000万元及以上的大项目1万多个,环比增长11.6%。四是从长期看,新型工业化、信息化、城镇化、农业现代化都蕴藏了巨大的投资空间。推动城市基础设施更新改造、实施乡村振兴战略、优化和稳定产业链供应链、加快传统产业的转型升级都蕴藏着很大的投资潜力。总体上,下阶段投资将会继续保持持续恢复的态势。谢谢。 CNBC记者: 我的问题是关于数据对于下半年的影响,比如出口会不会持续增长?在消费方面,我看到汽车类有增长,这和汽车行业6月份的数据有些不一样,背后有什么主要的因素?谢谢。 刘爱华: 谢谢您的提问。*,关于外贸的走势,前两天有关部门已经发布了上半年的数据,从总体的数据情况来看,在国内外经济持续复苏以及去年基数比较低这些因素的共同作用下,今年上半年进出口实现了比较快的增长,上半年货物进出口总额同比增长27.1%,和2019年同期相比增长22.8%,两年平均增速10%以上。上半年外贸形势总体不错,展望下半年,要关注到两个方面的因素:*方面,目前全球疫情走势仍然错综复杂,大宗商品价格上涨压力仍然比较大,外部环境不稳定、不确定因素比较多,这会对我们的外贸环境造成一定影响。另外一方面,海外需求目前处于复苏态势,国内需求也在继续回升。同时企业应对外部变化的调整能力是在日益增强的,发展的韧性比较强,所以外贸出口也拥有比较多的有利条件。综合判断,全年外贸进出口有望保持一个比较快的增长。 第二,关于您提到的汽车行业的问题,今年上半年汽车行业增加值同比增长21.8%,两年平均增长8.6%,这两个速度都是快于整体工业增加值增速的。但是,目前汽车行业的增长也受到了一定制约,比如大家普遍关注的芯片短缺,还有一些政策的调整,在短期内可能会对汽车产业的发展造成一定制约,比如带来供货周期长、成本上升这样的阶段性影响。但是也要看到,目前从总体来看,我国的千人汽车保有量和发达国家相比还有比较大的差距,汽车行业发展潜力还是比较大的。从短期来看,目前在需求上升、价格上涨的市场信号带动下,集成电路的生产在逐步加快。当然也要看到外部的环境比较复杂严峻,全球生产能力的恢复也需要假以时日。总体上看,汽车行业长期发展潜力还是比较大的。谢谢。 *财经记者: 今年以来,大宗商品价格持续上涨,对产业链中下游造成了一定的冲击,中小企业利润承压。请问您对接下来大宗商品走势怎么看?中小企业如何应对?另外,猪肉价格在持续下行,成为CPI的主要拖累项。您认为当前猪肉价格是否已经触底,对全年的通胀怎么看?谢谢。 刘爱华: 谢谢你的问题。关于大宗商品价格走势,今年上半年工业生产者出厂价格(PPI)平均上涨5.1%,涨幅比一季度扩大3个百分点。工业生产者出厂价格在二季度涨幅扩大,主要有几个因素的影响。一是经济在持续恢复,需求在不断回升。二是国际大宗商品价格上涨的输入性影响。今年6月份,国际能源价格指数同比上涨92.6%,非能源价格指数上涨43.2%,涨幅都是比较高的。三是去年同期低基数的影响。受新冠肺炎疫情的影响,从去年2月份开始PPI持续下降,二季度每个月都同比下降3%以上。今年二季度PPI的同比涨幅明显扩大,给很多中下游企业、中小微企业带来了比较大的成本压力。下阶段,虽然国际大宗商品价格输入性的上涨压力仍然存在,但我国的工业生产能力比较强,工业品的供应能力比较充足。与此同时,近期有关部门实施国内大宗商品价格保供稳价的政策,效果在初步显现。6月份工业生产者出厂价格同比上涨8.8%,比5月份回落0.2个百分点。总体上工业品价格上涨的影响是可控的。 第二个问题是关于CPI的走势和对猪肉价格的判断。今年上半年CPI处于温和上涨的态势,上半年CPI平均上涨0.5%,涨幅比上年同期回落3.3个百分点,处于近年来比较低的水平。从月度变化看,6月份当月居民消费价格同比上涨1.1%,比5月份回落0.2个百分点。从结构看,食品价格由涨转降,是影响CPI涨幅回落*主要的原因。今年上半年,食品价格同比下降0.2%,去年同期食品价格上涨16.2%,食品价格从上拉居民消费价格的主要因素转为下拉居民消费价格的因素,影响今年上半年居民消费价格下降0.04个百分点。您刚才提到的猪肉价格同比已经连续9个月下降,上半年平均下降19.3%,影响CPI下降约0.45个百分点。 从非食品价格来看,今年上半年非食品价格上涨0.7%,涨幅和去年同期相同,影响了CPI上涨0.57个百分点。在非食品中主要还是能源价格上涨比较多,今年上半年汽油和柴油价格分别上涨8.5%和9.2%,合计影响CPI上涨约0.24个百分点。总的看今年上半年居民消费价格温和上涨有食品价格由涨转降的因素,也有非食品价格涨幅比较平稳的因素。 从下阶段影响CPI的三个板块来看,*个板块,食品价格来看。我们昨天刚刚公布了夏粮产量,夏粮再获丰收,所以粮食价格有望继续保持稳定。猪肉价格随着生猪生产持续恢复、国家收储政策又有支撑,所以价格有望保持稳定态势。总体上看,食品价格在粮食再获丰收、猪肉价格保持稳定的情况下,总体上涨压力不大。 第二个板块,工业消费品价格来看。国际大宗商品价格的上涨会带来部分工业消费品有所上涨,但从长期看,我国的供给能力比较强,工业生产能力比较强,产业体系比较完整,工业消费品的市场供应总体比较充足,工业消费品价格不存在持续大幅上涨的基础。 第三个板块,服务价格来看。今年上半年服务价格持续受到散发疫情的影响,目前处于近年来的低位,今年上半年服务价格同比上涨0.3%。下阶段,随着国内疫情防控形势的持续向好,餐饮、住宿、旅游的消费需求将会逐渐恢复,市场信心不断增强,加上居民收入增速也是在加快的,服务价格将会有一定程度的回升。但总体上看,考虑到疫情防控常态化的因素,服务价格有望保持小幅上涨。 综合上面三个板块未来发展的态势判断,全年物价保持温和上涨是有基础、有条件的,实现全年3%左右的调控目标也同样有基础、有条件。谢谢。 21世纪经济报道记者: 前几天央行进行全面降准,市场上有解读说是因为下半年我国经济面临较大的下行压力,所以提前让政策更加宽松,对这块您怎么看?前几天总理召开的经济座谈会上提到,我们要加强跨周期调控,尤其要注意应对一些周期性风险,跨周期调控应该怎么调控?当前我国经济主要面临哪些周期性风险?谢谢。 刘爱华: 谢谢你的提问。首先回答*个问题,经济未来的走势会怎么样?从刚才公布的数据来看,今年上半年经济持续稳定恢复,供需循环畅通,为下半年经济运行打下了比较好的基础。从影响下半年经济走势的因素来看,支持经济进一步恢复、进一步向好的因素在逐渐累积、逐渐增多。一是经济的内生动力逐步增强。今年上半年,内需对经济增长的贡献率达到80.9%,比一季度上升了4.9个百分点。其中市场销售稳步回升,今年上半年社会消费品零售总额两年平均增长4.4%,比一季度加快了0.2个百分点。投资也在持续稳定恢复,上半年固定资产投资两年平均增长4.4%,比一季度加快了1.5个百分点,说明内需对经济增长的支撑作用逐步增强。二是市场主体信心不断增强。6月份,制造业采购经理指数(PMI)为50.9%,已经连续16个月位于景气区间。非制造业商务活动指数和综合PMI产出指数也都位于比较高的景气区间,反映了市场主体对未来经济增长的信心、对未来增长活力的信心是在持续改善的。三是全球经济目前延续了复苏的态势,为外需的增长奠定了基础。6月份全球综合PMI是56.6%,保持在15年以来的高位,据WTO*新的预计,2021年全球货物贸易量有望增长8%,反映了全球贸易复苏步伐在加快,这有利于外需保持较快的增长。 在经济基本面、供需各方面稳中向好的同时,宏观政策继续保持了对实体经济的支持力度,支持小微企业和个体工商户的政策在不断落实落地,这有利于为企业纾困解难,为市场注入生机活力。同时也要看到,下半年外部不稳定、不确定因素也比较多。从国内来讲,经济恢复仍不均衡,比如您刚才提到的原材料价格上涨对小微企业、尤其是中下游的企业带来了生产经营压力。但是从总的基本面来讲,从供需循环、市场信心、内需持续增强来看,下半年中国经济有望保持持续稳定复苏的态势。 关于宏观政策,一方面要看到今年总体经济稳中加固、稳中向好,另外一方面也要看到,目前国内外环境错综复杂,特别是大宗商品价格的上涨,给中小微企业带来的成本压力比较大。针对运行中存在的突出问题,还是要按照党中央、国务院的决策部署,立足当前、着眼长远,做好跨周期调节,应对好可能发生的周期性风险。尤其是要把培育壮大市场主体放在重要位置,通过深化“放管服”改革,优化营商环境,给中小微企业更多的成长空间,为推动经济平稳健康运行奠定坚实基础。谢谢。 大公报香港文汇报记者: 我们看数据显示,1-6月,外商及港澳台商投资企业同比增长达到17%,您如何评价这一数据?谢谢。 刘爱华: 谢谢你的提问。今年上半年外商及港澳台商投资企业增加值同比增长17%,这个增速快于规模以上工业增加值增速。今年上半年,规模以上工业增加值同比增长15.9%。说明外商及港澳台商投资企业在应对疫情冲击、适应市场环境变化中,充分发挥了应变的能力。同时,宏观政策也在不断给予各类企业和实体经济更多的支持。总体上来讲,外商及港澳台商投资企业的增长也印证了我们总体经济的恢复,说明市场主体的经营状况在不断好转。谢谢。

存储进阶:怎么才能保证 IO 数据的安全?

 

%title插图%num

%title插图%num

写成功了数据就安全了吗?

思考一个问题:写数据做到什么程度才叫安全了?

就是:用户发过来一个写 IO 请求,只要你给他回复了 “写成功了”,那么无论机器发生掉电,还是重启等等之类的,数据都还能读出来。

所以,在我们不考虑数据静默错误的前提下,数据安全的*本质要求是什么?

划重点:那就是数据一定要在非易失性的存储介质里,你才能给用户回复“写成功”。请一定要记住这句话,做存储开发的人员,80% 的时间都在思考这句话。

那么常见的易失性介质和非易失性介质有哪些呢?

易失性介质:寄存器,内存 等;非易失性介质:磁盘,固态硬盘 等;

%title插图%num

从上到下,速度递减,容量递增,价格递减。

%title插图%num

Linux IO 简述

我们前面提到一个文件的读写方式,标准库的方式和系统调用的方式。无论是哪一种,本质上都是基于文件的一种形式,下面承接了一层文件系统,主要层次:系统调用 -> vfs -> 文件系统 -> 块设备 -> 硬件驱动 。

%title插图%num

我们 open 了这个文件,然后 write 数据进去。好,现在思考一个问题,当 write 返回成功之后,数据到磁盘了吗?

答案是:不确定。

因为有文件系统的 cache ,默认是 write back 的模式,数据写到内存就返回成功了,然后内核根据实际情况(比如定期或者脏数据达到某个阈值),异步刷盘。

这样的好处是保证了写的性能,貌似写的性能非常好(可不好嘛,数据写内存的速度),坏处是存在数据风险。因为用户收到成功的时候,数据可能还在内存,这个时候整机掉电,由于内存是易失性介质,数据就丢了。丢数据 是存储*不能接受的事情,相当于丢失了存储的生命线。

动画演示:

%title插图%num

那么,怎么保证数据的可靠?

划重点:还是那句话,一定要确保数据落盘之后,才向用户返回成功。

那么怎么才能保证这一点?有以下 3 种方法。

  1. open 文件的时候,用 O_DIRECT 模式打开,这样 write/read 的时候,文件系统的 IO 会绕过 cache,直接跟磁盘 IO;
  2. open 文件的时候,使用 O_SYNC 模式,确保每一笔 IO 都是同步落盘的。或者 write 之后,主动调用一把 fsync ,强制数据落盘;
  3. 读写文件的另一种方式是通过 mmap 函数把文件映射到进程的地址空间,读写进程内存的地址的数据其实是转发到磁盘上去读写,write 之后主动调用一把 msync 强制刷盘;

%title插图%num

三种安全的 IO 姿势

1   O_DIRECT 模式

DIRECT IO 模式能够保证每次 IO 都直接访问磁盘数据,而不是数据写到内存就向用户返回成功的结果,这样才能确保数据安全。因为内存是易失性的,掉电就丢了,数据只有写到持久化的介质才能安心。

动画演示:

%title插图%num

读的时候也是直接读磁盘,而不会缓存到内存中,从而也能节省整机内存的使用。

缺点也同样明显,由于每次 IO 都要落盘,那么性能肯定看起来差(但你要明白,其实这才是真实的磁盘性能)。

划重点:使用了 O_DIRECT 模式之后,必须要用户自己保证对齐规则,否则 IO 会报错,有 3 个需要对齐的规则:

  1. 磁盘 IO 的大小必须扇区大小(512字节)对齐
  2. 磁盘 IO 偏移按照扇区大小对齐;
  3. 内存 buffer 的地址也必须是扇区对齐;

c 语言示例:

  1. #include <stdio.h>
  2. #include <stdlib.h>
  3. #include <assert.h>
  4. #include <fcntl.h>
  5. #include <errno.h>
  6. #include <string.h>
  7. #include <stdint.h>
  8. extern int errno;
  9. #define align_ptr(p, a) \
  10.     (u_char *)(((uintptr_t)(p) + ((uintptr_t)a – 1)) & ~((uintptr_t)a – 1))
  11. int main(int argc, char **argv)
  12. {
  13.     char timestamp[8192] = {0,};
  14.     char *timestamp_buf = NULL;
  15.     int timestamp_len = 0;
  16.     ssize_t n = 0;
  17.     int fd = -1;
  18.     fd = open(“./test_directio.txt”, O_CREAT | O_RDWR | O_DIRECT, 0644);
  19.     assert(fd >= 0);
  20.     // 对齐内存地址
  21.     timestamp_buf = (char *)(align_ptr(timestamp, 512));
  22.     timestamp_len = 512;
  23.     n = pwrite(fd, timestamp_buf, timestamp_len, 0);
  24.     printf(“ret (%ld) errno (%s)\n”, n, strerror(errno));
  25.     return 0;
  26. }

编译命令:

  1. gcc -ggdb3 -O0 test.c -D_GNU_SOURCE

生成二进制文件,执行下就知道了,这个是成功的。

  1. sh-4.4# ./a.out
  2. ret (512) errno (Success)

如果为了验证对齐导致的错误,读者朋友可以故意让 io 的偏移或者大小,或者内存 buffer 地址不按照 512 对齐(比如故意让 timestamp_buf 对齐之后的地址减 1,再试下运行),会得到如下:

  1. sh-4.4# ./a.out
  2. ret (-1) errno (Invalid argument)

思考问题:有些童鞋可能会好奇问了?IO 大小和偏移按照 512 对齐我会,但是怎么才能保证 malloc 的地址是 512 对齐的呢?

是啊,我们无法用 malloc 来控制生成的地址。这对这个需求,我们有两个解决办法:

方法一:分配大一点的内存,然后在这个大块内存里找到对齐的地址,只需要确保 IO 大小不会超过*后的边界即可;

我上面的 demo 例子就是如此,分配了 8192 的内存块,然后从里面找到 512 对齐的地址。从这个地址开始往后 512 个字节是*对到不了这个大内存块的边界的。对齐的目的安全达成。

%title插图%num

这种方式实现简单且通用,但是比较浪费内存。

方法二:使用 posix 标准封装的接口 posix_memalign 来分配内存,这个接口分配的内存能保证对齐;

如下,分配 1 KiB 的内存 buffer,内存地址按照 512 字节对齐。

  1. ret = posix_memalign (&buf, 5121024);
  2. if (ret) {
  3.     return -1;
  4. }

思考一个问题:O_DIRECT 模式 的 IO 一般是哪些应用场景?

  • *常见的是数据库系统,数据库有自己的缓存体系和 IO 优化,无需内核消耗内存再去完成相同的事情,并且可能好心办坏事;
  • 不格式化文件系统,而是直接管理块设备的场景;

2   标准 IO + sync

sync 功能:强制刷新内核缓冲区到输出磁盘。

在 Linux 的缓存 I/O 机制中,用户和磁盘之间有一层易失性的介质——内核空间的 buffer cache

  • 读的时候会 cache 一份到内存中以便提高后续的读性能;
  • 写的时候用户数据写到内存 cache 就向用户返回成功,然后异步刷盘,从而提高用户的写性能。

读操作描述如下

  1. 操作系统先看内核的 buffer cache 有缓存不?有,那么就直接从缓存中返回;
  2. 否则从磁盘中读取,然后缓存在操作系统的缓存中;

写操作描述如下

  1. 将数据从用户空间复制到内核的内存 cache 中,这时就向用户返回成功,对用户来说写操作就已经完成;
  2. 至于内存的数据什么时候才真正写到磁盘由操作系统策略决定(如果此时机器掉电,那么就会丢失用户数据);
  3. 所以,如果你要保证落盘,必须显式调用了 sync 命令,显式把数据刷到磁盘(只有刷到磁盘,机器掉电才不会导致丢数据);

划重点:sync 机制能保证当前时间点之前的数据全部刷到磁盘。。而关于 sync 的方式大概有两种:

  1. open 的使用使用 O_SYNC 标识;
  2. 显式调用 fsync 之类的系统调用;

方法一:open 使用 O_SYNC 标识

c 语言示例:

  1. #include <stdio.h>
  2. #include <stdlib.h>
  3. #include <assert.h>
  4. #include <fcntl.h>
  5. #include <errno.h>
  6. #include <string.h>
  7. #include <stdint.h>
  8. extern int errno;
  9. int main(int argc, char **argv)
  10. {
  11.     char buffer[512] = {0,};
  12.     ssize_t n = 0;
  13.     int fd = -1;
  14.     fd = open(“./test_sync.txt”, O_CREAT | O_RDWR | O_SYNC, 0644);
  15.     assert(fd >= 0);
  16.     n = pwrite(fd, buffer, 5120);
  17.     printf(“ret (%ld) errno (%s)\n”, n, strerror(errno));
  18.     return 0;
  19. }

这种方式能保证每一笔 IO 都是同步 IO,一定是刷到磁盘才返回,但是这种使用姿势一般少见,因为这个性能会很差,并且不利于批量优化。

动画演示:

%title插图%num

方法二:单独调用函数 fsync

这个则是在 write 之后 fsync 一把数据到磁盘,这种方式实际生产环境用的多些,因为方便业务优化。这种方式对程序员提出了更高的要求,要求必须自己掌握好 fsync 的时机,达到既保证安全又保证性能的目的,这里通常是个权衡点。

比如,你可以 write 10 次之后,*后才调用一把 fsync,这样既能保证刷盘,又达成了批量 IO 的优化目的。

关于这种使用姿势,有几个类似函数,其中有些差异,各自体会下:

  1. // 文件数据和元数据部分都刷盘
  2. int fsync(int fildes);
  3. // 文件数据部分都刷盘
  4. int fdatasync(int fildes);
  5. // 整个内存 cache 都刷磁盘
  6. void sync(void);

动画演示:

%title插图%num

3   mmap + msync

这是一个非常有趣的 IO 模式,通过 mmap 函数将硬盘上文件与进程地址空间大小相同的区域映射起来,之后当要访问这段内存中一段数据时,内核会转换为访问该文件的对应位置的数据。从使用姿势上,就跟操作内存一样,但从结果上来看,本质上是文件 IO

%title插图%num

  1. void *
  2. mmap(void *addr, size_t len, int prot, int flags, int fd, off_t offset)
  3. int
  4. munmap(void *addr, size_t len);

mmap 这种方式可以减少数据在用户空间和内核空间之间的拷贝操作,当数据大的时候,采用内存映射方式去访问文件会获得比较好的效率(因为可以减少内存拷贝量,并且聚合 IO,数据批量下盘,有效的减少 IO 次数)。

当然,你 write 数据也还是异步落盘的,并没有实时落盘,如果要保证落盘,那么必须要调用 msync ,调用成功,才算持久化落盘。

mmap 的优点:

  • 减少系统调用的次数。只需要 mmap 一次的系统调用,后续的操作都是内存拷贝操作姿势,而不是 write/read 的系统调用;
  • 减少数据拷贝次数;

c 语言示例:

  1. #include <stdio.h>
  2. #include <stdlib.h>
  3. #include <sys/mman.h>
  4. #include <sys/types.h>
  5. #include <unistd.h>
  6. #include <sys/stat.h>
  7. #include <assert.h>
  8. #include <fcntl.h>
  9. #include <string.h>
  10. int main()
  11. {
  12.     int ret = -1;
  13.     int fd = -1;
  14.     fd = open(“test_mmap.txt”, O_CREAT | O_RDWR, 0644);
  15.     assert(fd >= 0);
  16.     ret = ftruncate(fd, 512);
  17.     assert(ret >= 0);
  18.     char *const address = (char *)mmap(NULL512, PROT_READ | PROT_WRITE, MAP_SHARED, fd, 0);
  19.     assert(address != MAP_FAILED);
  20.     // 神奇在这里(看起来是内存拷贝,其实是文件 IO)
  21.     strcpy(address, “hallo, world”);
  22.     ret = close(fd);
  23.     assert(ret >= 0);
  24.     // 落盘确保
  25.     ret = msync(address, 512, MS_SYNC);
  26.     assert(ret >= 0);
  27.     ret = munmap(address, 512);
  28.     assert(ret >= 0);
  29.     return 0;
  30. }

编译运行看看吧。

  1. gcc -ggdb3 -O0 test_mmap.c -D_GNU_SOURCE

是不是生成了一个 test_mmap.txt 文件,里面有一句 “hello,world”。

动画演示:

%title插图%num

%title插图%num

硬件缓存

以上方式保证了文件系统那一层的落盘,但是磁盘硬件其实本身也有缓存,这个属于硬件缓存,这层缓存也是易失的。所以*后一点是,为了保证数据的落盘,硬盘缓存也要关掉。

  1. # 查看写缓存状态;
  2. hdparm -W  /dev/sda
  3. # 关闭 HDD Cache,保证数据强一致性;避免断电时数据未落盘;
  4. hdparm -W  0 /dev/sda
  5. # 打开 HDD Cache(断电时可能导致丢数据)
  6. hdparm -W  1 /dev/sda

按照内核保证数据落盘,硬件保证关闭缓存,综合以上的 IO 姿势,当你写一笔 IO 落盘之后,才能说数据写到磁盘了,才能保证数据是掉电非易失的。

%title插图%num

总结

  1. 数据一定要写在非易失性的存储介质里,你才能给用户回复“写成功”。其他的取巧的方式都是耍流氓、走钢丝;
  2. 本文总结 3 种*根本的 IO 安全的方式,分别是 O_DIRECT 写,标准 IO + Sync 方式,mmap 写 + msync 方式。要么每次都是同步写盘,要么就是每次写完,再调用 sync 主动刷,才能保证数据安全
  3. O_DIRECT 对使用者提出了苛刻的要求,必须要满足 IO 的 offset,length 扇区对齐,内存 buffer 地址也要扇区对齐;
  4. 注意硬盘也有缓存,这个也是易失性的,必须要考虑在内,可以通过 hdparm 命令开关;

到底是谁发明了物联网?

1965年的越南战场,美军正深陷战争泥潭。

突然有一天,北越士兵在胡志明小道发现了一些奇怪的东西。这些东西看上去像树枝,但实际上由金属构成,里面包含一些神秘的电子元件。

这些士兵还发现,近来美军对小道的轰炸越来越频繁,而且轰炸的准确率比之前有大幅的提升,给己方带来了不小的损失。

越军意识到,这些小玩意很可能就是美军空投到胡志明小道的“眼线”。

他们没有猜错,这些小玩意确实是美军的“杰作”。

当时,战争愈演愈烈,美军伤亡人数不断攀升,达到7000人。为了扭转局面、加快战争进程,美军对北越战略要道胡志明小道进行了更大规模的轰炸和封锁。

%title插图%num

胡志明小道

除了大量使用燃烧弹和化学毒剂之外,美方智库贾森小组提出了一种新的构想——可以设计一些能够伪装成树叶、树枝和自然物的传感器,投放到胡志明小道,通过声波和震动识别北越士兵的行动,从而进行精准轰炸。

这个行动,被美军命名为“白色冰屋(Igloo Whiter)”行动。而这些被投放过去的传感器,则被称之为“热带树”。

%title插图%num

“热带树”传感器

除了热带树之外,美军还投放了伪装成动物粪便的T-1511“狗粪”(Dog Doo)传感器。

%title插图%num

T-1511“狗粪”(Dog Doo)传感器

这是一种内置内置无线电信标的震动传感器,空投后激活,感测到地面震动时就会发出无线电信号。

%title插图%num

传感器X光透视图

在小道上空巡逻的美军OP-2E“海王星”电子侦察机收到信号之后,就能得知北越士兵的精确位置,然后召唤轰炸机进行定点打击。

整个越战期间,美军大约空投了几百万个战场传感器,耗资7亿美元。

这些传感器在早期对北越战略物资运输造成了很大的影响。但是,随着时间的推移,效果很快减弱。

原因是多方面的。首先,部分传感器外型突兀,掉在地上容易被识别清除。其次,传感器容易受野生动物和自然环境(风雨)的影响,导致误报,严重影响轰炸效率。再则,传感器自身的故障率也比较高。

%title插图%num

北越方面甚至训练了一支由3000只猴子组成的“部队”,专门对这些传感器进行定点清除。

总而言之,美军的这次“白屋行动”并不成功。尽管如此,这些传感器却打开了传感网世界的大门。世界各国不管是军用还是民用,纷纷开始效仿。

从某种意义上来说,这个传感器网络是物联网的*早期模型。

时间继续推移,我们来到1982年的美国宾夕法尼亚州匹兹堡。著名的卡内基梅隆大学,就坐落于此。

有一天,卡内基梅隆大学计算机科学系的研究生大卫·尼科尔斯(David Nichols)坐在办公室里,突然想喝可乐。

当时,学校在这栋大楼里确实设置了一个可口可乐自动售货机。不过,因为需求旺盛,所以经常缺货。

这位老兄虽然很想喝可乐,但是,作为宅男程序员,他*不愿意白跑一趟。

“于是,我想起了斯坦福大学的*台电脑控制自动售货机‘Prancing Pony’的故事”,尼科尔斯回忆道,“我意识到,我们完全可以通过技术来解决这个问题呀!”

%title插图%num

他把自己的想法告诉了他的同学。很快,另外两位学生迈克·卡扎尔(Mike Kazar)、伊沃·达勒姆(Ivor Durham)以及学校的研究工程师约翰·扎尔奈(John Zsarnay)开始了对技术细节的研究。

他们把关注点放在了可乐机的指示灯上。这台机器有6个可乐瓶位置。当有人购买可乐时,对应位置的红色指示灯会闪烁几秒钟,然后灭掉。

于是,约翰·扎尔奈设计并安装了一块能感应指示灯状态的主板,并通过一条线路将主板连接到部门的主计算机上。这台计算机也连接到了ARPANET上。ARPANET,也就是我们今天互联网的前身。

后来,小组成员们在主计算机上添加了代码,允许连接到ARPANET或卡内基梅隆大学本地以太网的任何计算机访问可乐机的信息。只需要按几个键,他们就可以知道机器里是否还有可乐。

“我从来没有用过它,只是看看它是否起作用”,卡扎尔兴奋地说,“我从来不喜欢可乐。”

不过,卡内基梅隆大学喜欢可乐的人那是非常的多,这个程序受到了热烈的欢迎。也有很多人对这个创意进行了效仿。

这个远程监控自动可乐机,可以算是民用物联网领域的一次探索。此后的很长时间里,卡内基梅隆大学都保留着这台可乐机,也有不少学生在它身上进行着各种改进和实验。

更有趣的是,大学还给这个可乐机专门建了一个网页,介绍它的传奇历史。(链接:https://www.cs.cmu.edu/~coke/)

%title插图%num

虽然这个可乐机很神奇,但并没有被公认为是世界上*台物联网设备。那么,*台物联网设备是什么时候出现的呢?

1990年。

那一年,美国计算机网络工程师约翰·罗姆奇(John Romkey )发明了一台可以通过互联网打开和关闭的烤面包机。他打算带着这台面包机去参加那一年的INTEROP大会。

大会主席丹·林奇(Dan Lynch)向他承诺:“如果你的烤面包机能够通过网络启动,我就会给你整个楼层*明星的展位”。结果,他真的做到了。

%title插图%num

约翰·罗姆奇和他的“网络烤面包机”

烤面包机通过TCP/IP网络连接到一台电脑上,然后通过SNMP MIB打开工作电源。

这个网络烤面包机,被普遍认为是世界上*台“物联网设备”。(网上还有一种说法,说施乐公司推出的网络可乐贩售机是*台物联网设备,可是小枣君实在没有找到相关的资料。)

1995年,比尔盖茨出版了自己的新书《未来之路》。在书中,比尔盖茨对信息技术的未来进行了大胆预言,其中就包括很多和现在物联网应用类似的奇妙想法。

例如:

“用户遗失或遭窃的照相机将自动发回信息,告诉用户所处的具体位置,甚至当它已经身处不同的城市。”

他认为,未来越来越多的物体将连入网络,可以通过网络进行控制。

%title插图%num

《未来之路》

除了写书之外,比尔盖茨还将自己的想法付诸实践。那一年,比尔盖茨为自己新建的房子设计了一整套的物联网系统来进行智能调控。他本人也成为了*早的智能家居用户。

此后,关于“万物联网”的思潮愈演愈烈。1999年(网上很多资料说是1991年,那是错误的),麻省理工学院的凯文·阿什顿(Kevin Ashton)教授首次提出物联网(Internet of Things)的概念。同年,他在麻省理工学院领导建立了“自动识别中心(Auto-ID)”,提出“万物皆可通过网络互联”,阐明了物联网的基本含义。

%title插图%num

Kevin Ashton

凯文·阿什顿也因此被称为“物联网之父”。

2003年,美国《技术评论》杂志提出,传感网技术将是未来改变人们生活的十大技术之首。也是从这一年起,英国卫报、科学美国人和波士顿环球报等主流媒体开始使用“物联网(Internet of Things)”这一叫法取代传感网,两者开始明确划分界限。

2005年11月17日,在突尼斯举行的信息社会世界峰会上,国际电信联盟(ITU)发布了《ITU互联网报告2005:物联网》。这份报告,算是从官方层面正式给“物联网(IoT)”授予了一个合法的身份。

从此,物联网世界的大门正式打开,人类真正进入了物联网时代!

参考文献:

1、https://www.cs.cmu.edu/~coke/

2、https://www.ibm.com/blogs/industries/little-known-story-first-iot-device/

3、https://new.qq.com/omn/20190131/20190131A0WQ5I.html

4、《先进武器并非无所不能 电子传感器败走胡志明小道》,人民网

5、《未来之路》,比尔盖茨

6、https://en.wikipedia.org/wiki/Kevin_Ashton

何为“边缘计算”?

云原生除了K8S、微服务,还有…?中和大家聊了下关于云原生的话题,在云原生的概念中比较明确的一个特点就是云原生是基于云计算的。在这种模式下用户的计算请求会被发送到云端服务进行处理,由云端完成复杂的数据计算后,再将结果以同步或异步方式返回调用客户端。

这就是典型的互联网”客户端/服务端”处理模式。但这并不是说只有云原生架构的应用才是这种模式,传统非云场景下的*大多数互联网应用也都是这种模式,而这种方式也是互联网技术发展到今天*主流的计算场景。

只不过在这个过程中,随着用户数据计算规模越来越大,传统的非云场景要支撑日益增长的数据计算规模,所需的计算资源成本会大幅上升。而在这个时候,具备弹性伸缩能力的云计算服务,就应运而生了!相对于传统自建机房模式,使用云计算可以大大降低运维成本。

但这也只是从服务器计算资源的角度在看问题,要充分发挥云端服务的计算能力,还需要在系统架构上进行更合理的设计。而云原生架构模式就是从系统架构本身对整个软件系统的应用结构、部署模式等进行结构性优化,这一切的核心目的都是为了提高在”客户端/服务端”这种云端计算模式下服务的计算效率、提升用户响应速度。

然而云原生架构也并不是终*解决方案,在目前以移动互联网为主流的大数据时代,以及正在或即将到来的物联网、AI时代,数据的增长规模将达到PB级别(1TB=1024GB,1PB=1024TB),面对如此海量数据,分析计算结果所要求的时间却越来越短,在这种趋势之下,云端集中式数据处理方式将越来越难以满足这种需求。

我们也将被迫走到”边缘计算”这条路上,这也是为什么*近两年关于”边缘计算”、”Serverless”这些新概念讨论越来越多的原因。在今天的文章中,就和大家一起聊聊”边缘计算”这个话题。

%title插图%num

边缘计算是什么

通过前面的叙述,相信你大概理解了边缘计算到底缘何而来,那么它到底是什么,在现阶段有何具体的落地场景及技术呢?

说起边缘计算*常见的举例就是章鱼,作为无脊椎动物中智商*高的一种动物,章鱼拥有巨量的神经元,但这些神经元中60%都分布在章鱼的八条腿上,而大脑中的神经元只占40%。如下图所示:

%title插图%num

在这种生物结构下,章鱼在捕猎时异常灵巧迅速,腕足之间配合*好,从不会缠绕打结。而这种类似于“多个小脑+一个大脑”的分布式协作方式,就是边缘计算非常形象的表达。

回到我们所讲的边缘计算,它也是一种分布式计算:”在网络边缘侧的智能网关上就近处理采集的数据,而不是将大量数据上传到远端的数据中心进行集中处理”。边缘计算可以带来明显的计算优势,具体如下:

  • 边缘计算可以更实时地进行数据处理和分析,让数据处理更靠近数据源,而不是外部数据中心或者云,这样可以缩短延迟时间;
  • 减少网络流量。在物联网、AI时代随着各类设备数量的增加,数据的生产速度飞快,如果将这些数据都传回云端处理,那么将大大挤占网络带宽,造成更大的数据瓶颈;
  • 降低预算成本。利用边缘计算所要采取的本地设备采购及数据处理方案所花费的成本,要大大低于使用云或者数据中心处理所花费的成本。

按照上述说法,既然边缘计算有这么多优势,那么它是否就能取代云端计算了呢?实际上边缘计算更适合物联网和AI计算场景,边缘计算准确的说是对云端集中式计算方式的一种补充和优化。以下我列举了几种有代表性的边缘计算场景,具体如下:

%title插图%num

其实还有很多其他场景,随着物联网、AI时代的到来,边缘计算所延伸的场景将更加丰富。但说到这里,似乎边缘计算与咱们做互联网服务端的好像没有啥关系啊!但实际上技术都是相通的,虽然目前边缘计算更侧重于物联网/AI等领域,但是边缘计算的思想其实早就在互联网“客户端/服务端模式”中出现过,例如以Ajax为代表的“富客户端”技术,其本质就是一种减少服务端计算量的边缘计算思想。

只不过目前我们所谈论的边缘计算所涉及的层次要更加复杂,而不仅仅只是单个客户端的简单分散计算。就现阶段来说边缘计算的关键技术主要集中在以下两个方面:

%title插图%num

在上述两个关键技术方向中,边缘网关技术更多的是偏向于网络边缘设备的计算能力,例如5G基站。所以这方面技术的发展由于行业及场景的不同,目前也没有一个统一的标准,另外这方面的内容也的确超出了咱们做互联网所涉及的技术范围。

因此,关于边缘网关技术的内容就不过多讨论了,接下来我们重点看下与互联网相关性更多的Serverless技术。

%title插图%num

Serverless

从严格意义上来说,边缘计算与Serverless从定义及概念上并没有直接的关系。这主要是因为边缘计算与Serverless当前的应用场景还没有凸显出来,但从目前业界活跃的讨论氛围来看,Serverless技术未来有*大的可能会被应用于边缘计算场景。因为边缘计算的核心目的就是把原先必须在云端计算的逻辑放到边缘设备上去,从而更快地响应用户的操作需求,但要做到这一切就必须让边缘设备具备灵活执行用户计算代码的能力。

而以Serverless为代表的”云函数”技术,可以让用户在云端以比微服务粒度更细的单元去编写逻辑计算代码,但这种代码与传统云端运行的服务不同,它本身并不是一个持久存在并固定运行在某个服务器或容器中的进程,而是可以根据真正的用户事件进行触发式运算。在这个过程中,云服务所做的只是提供代码和配置的托管,以及根据事件触发运算调度,而真正的计算则是将”云函数”代码具体下放到某个具体的边缘设备去运行和使用。

这种无服务器计算的方式,能够非常巧妙的将云计算的调度能力与边缘具体算力有机结合起来,从而形成一个”大脑+多个小脑”的分布式计算系统。接下来我们具体看下Serverless的概念:

%title插图%num

如上图所示Serverless从架构上主要可以分为:BaaS(后端即服务)、FaaS(函数即服务)两部分。

后端即服务(BaaS)说的是尽量使用现成的第三方服务来替换我们原来自己编码实现或搭建的服务器组件,它从概念上更类似于SaaS服务,例如直接使用云服务所提供的各类技术服务——COS对象存储、CDN容分发、CDB云数据库等。从技术实质上说Baas本身并没有什么新奇之处,更多的是一种尽量使用第三方服务来减少自己构建通用基础服务的概率,而尽量做到无服务或少服务。

而函数即服务(SaaS)则是一种构建和部署软件的全新方法,它为云中运行的应用程序提供了一种新的系统体系结构。在这种结构之下,再也不用在服务器上持续运行服务进程以等待HTTP请求或调用,而是可以通过某种事件机制来具体触发函数代码执行,这是一种更节省成本的云计算方式。

目前许多云服务厂商都在抓紧布局Serverless技术,可见Serverless技术的发展将是大势所趋。下图为腾讯云所提供的云函数产品界面示意图:

%title插图%num

现阶段Serverless技术还处于早期发展阶段,相信随着更多应用场景的落地,在不久的将来Serverless技术必将被广大企业和开发者所接受,从而成为改变现有软件开发部署模式的新一代技术潮流。

以上就是本文想要表达的全部内容,感兴趣的朋友可以找个Serverless云服务产品(如腾讯云云函数或Serverless Framework)具体体验下Serverless的开发流程!如果觉得本文对你有所帮助,欢迎点赞关留言~

参考资料:https://blog.csdn.net/qcloudcommunity/article/details/79388590

说到 SASE,新的安全范式有哪些

前言

本系列目录:

对于SASE,当前可能存在两类看法:

  • 又瞎扯淡:感觉SASE没啥,和SD-WAN一样,炒作成分居多;
  • 不明觉厉:感觉SASE重要,但又说不上来哪里好,了解一些相关技术。

一个可能的原因是:诸如Gartner之类的高大上权威,在定义完SASE后,一上来就谈SASE有12点优势,“巴拉巴拉”小魔仙,非常感人。Gartner作为一家顶级咨询机构,客户都是花了大笔订阅费的,这也决定了必须要专业严肃一些。

作者没背景,没负担,无束缚,可以不按套路,会按一贯风格,侧重分析:

  • 散点知识如果没法融入知识体系,早晚都会是过眼浮云。
  • 更重要的一点,作者也不懂什么高深的安全技术,还得继续学习。
  • 一个人不可能全心投入他不认可的领域。所以,即便是为了跨界学习,也需要尽可能理解SASE,这也是整理本文*原始的初衷。

%title插图%num

什么是范式

In science and philosophy, a paradigm is a distinct set of concepts or thought patterns, including theories, research methods, postulates, and standards for what constitutes legitimate contributions to a field. — Wikipedia

什么是范式?在科学和哲学中,范式是一组独特的概念或思维模式,包括构成一个领域的一套自洽的理论,研究方法,假设和标准。

范式有什么用?范式会自带世界观,会引导人们带着其特有的倾向和思路去析构世界,认知/分析/解决问题

可能还是有些抽象,举一个*直接的范式例子:地心说和日心说。

%title插图%num
图2-1:日心说与地心说;来源:http://www.malinc.se/math/trigonometry/geocentrismen.php

  • 上图的右半部分,是地心说下的太阳系;
  • 上图的左半部分,是日心说下的太阳系。

推荐点击图片链接,可以看到动态轨迹图;地心说其实是挺精妙的。

以上,地心说是一种范式,日心说是另一个范式。

同一个世界,在不同范式的析构下,会呈现出巨大的复杂性差异,这就是范式的作用

作者认为,和SD-WAN类似,SASE也不是一种产品,不是一种技术,而是一种新的安全范式,这也意味着SASE可能会进一步衍生出不同的技术、工具和产品。

SASE至少提供了两个范式:

  • 一个是产品形态方面的,这里可能会卡一卡传统设备商;
  • 一个是业务建模方面的,这里可能会拼一拼产品架构。

%title插图%num

产品形态的范式

3.1 为什么产品形态重要

先回到一个经典例子:“客户不是要买电钻,而是要买墙上的那个洞”

%title插图%num 图3-1:客户要的是电钻吗;来源:互联网

假设你要挂一幅画:

  • 产品形态:你花了200元钱,在京东上买了一把电钻,京东很牛逼,次日达。次日,你叠起了两个凳子,晃晃悠悠,勉强打了两个洞,挂上了画。
  • 服务形态:你给物业打了个电话,物业报价20元/洞,15分钟内上门。物业带了一些列电钻钻头和折叠梯,30分钟完成挂画,还帮你清理了钻墙的粉屑。
  • 高级的服务形态:物业上门后,查看了一下画和墙,直接推荐挂钩方案,既不破坏墙体,也没有噪音灰尘。你认可了,物业也更方便,只收了20元。说这更高级,是因为“听用户说,但没有照着用户说的去做,而是在洞悉之后售卖了更为专业的服务”。
  • 更高级的服务形态:物业上门后,发现画风与墙饰风格不符,现场说出了三点原因,给出了完整建议。你一听还挺受用,购买了物业的装饰服务,收费200元。你很高兴,因为在亲友面前提升了品味;物业也很高兴,因为不但成了更大的单,而且因为准确挖掘了客户的根本诉求,客户的满意度和忠诚度也更高。说这更高级,是因为这项服务过渡到了“售卖标准”,在这个例子里,就是“审美标准”。售卖标准,长期是西方国家的优势领域,当前很多中国产品,正在试图突破这个阶段

为什么服务形态比产品形态更加高级?这个问题搜不到答案,以下是一些作者理解:

  • 更容易接近真实需求:产品是硬的,服务是软的。社会进步的标志就是分工越来越细,这也意味着需求越来越多样化,软性的服务相对更容易匹配用户的真实需求。以上例子,“打洞”就要比“电钻”更接近用户的真实需求:不同的客户有着不同的墙体,不同的孔径,不同的深度,“打洞”显然更要比“电钻”更容易匹配各种真实需求。一个更加宏大的例子:哪怕是*硬梆梆的制造业,在推的概念也是“柔性制造”,本质上就是“软件定义产线”,尽可能去快速逼近细分客户的特定需求。
  • 用户界面更简单:产品离满足需求,还差了一个“集成”。在这个例子里,集成比较简单,就是业主自己去操作打洞,但其实也是有一定门槛的;在很多2B产品的例子里,集成往往会更加困难,一个直接表现就是存在着大量的集成商;不过羊毛出在羊身上,这些都会增加客户的广义拥有成本。
  • 更快满足需求:客户,大多都会把时间留给自己,把难题留给供应商:下单之前,货比三家,磨磨叽叽;下单之后,立刻就要,拼命催单。这是客观存在的事实,很难改变客户的心理,那就只能改变自己的交付形态了。

3.2 产品形态的串联

SASE在产品形态方面的范式革新,已然比较明显:客户要的不是设备,也不是功能,而是服务

  • *好这个服务足够全,能涵盖我的所有相关需求,不用让我再去考虑多供应商和多供应商之间的集成问题;
  • *好这个服务刚刚好,可以调整到刚好涵盖我的所有相关需求,不用让我多花一分冤枉钱;
  • *好这个服务够专业,可以成标准成体系地从根本上解决相关顾虑,可以让我在老板面前更专业更得力。

前文提到,产品形态的范式,可能会卡一卡传统设备商,那我们就来稍微展开一下。

一个设备虚拟化了,就成为服务了吗?当然不是。虚拟化了的,还只是功能。功能和服务差在哪?功能是偏静态的,偏供给侧视角的;服务是偏动态的,偏需求侧视角的。这两者又有什么区别?偏静态的供给侧视角:我有这这这功能,超级牛逼,你来用用啊;偏动态的需求侧视角:客户发现,在他想睡觉的时候,路上出现了一个枕头;在他想打怪的时候,路上出现了一个耙子,他甚至不需要“懂”,只需要会“用”。

在客户随时需要时能随时满足,“敏捷、弹性、按量付费”,这样才叫云化服务;或者翻译成那句大白话:“不求天长地久,但求要时能有,随时要随时有”。所以,

  • 需要齐全的网络栈和安全栈,足以匹配各种场景的网络和安全需求;
  • 需要高度的虚拟化和模块化,足以刚刚匹配所需的场景;
  • 需要高效的建模能力和快速的投送能力,足以应对VUCA的用户和需求。

这方面,再啰嗦估计就要被嫌弃了,这个系列也已经铺垫很久了,可以参考前面几篇,不再赘述。

3.3 大道无形

本章*后,做个大胆预测:与SD-WAN类似,SASE可能也会分成“名义市场”和“无形市场”;会有一些更大的玩家去玩“无形市场”,即直接服务一个更大的产品或产品体系,不以“SASE”的名头直接出现在市场上,拭目以待。

%title插图%num

业务建模的范式

4.1 为什么业务建模重要

之前提到,范式能帮助我们析构世界,引导我们去认知/分析/解决更广更深的问题。

产品形态的范式,解决了用户界面复杂度的问题;业务建模的范式,解决了产品架构复杂度的问题。

2B产品,本质上是强化了某种生产关系。这就意味着,2B产品必须要解决具体的现实问题,而解决问题的效能和效率,取决于产品本身对现实世界的建模能力:模型越逼真,方案越匹配。

%title插图%num
图4-1:问题域与解决方案;来源:互联网

4.2 范式与技术

在进一步析构业务建模的范式之前,有必要先澄清一下范式与技术之间的关系,因为两者在SASE里,都会是重要的存在。

范式和技术是两个层面的词,先进的范式,不代表先进的技术。还是以地心说和日心说为例,反倒是地心说可能需要更高深的技术功底才能掌握,而日心说,初中物理水平就已足够理解。回望历史,往往正是旧范式的建模能力有限,为了逼近真相,才被迫发展出很多“高深”的技术来“代偿”

这也是为什么不建议直接投身技术而是先来研究一下范式背景:技术容易成为深深的竖井,贸然进去短时间可能爬不出来,反而就容易忽略新技术所代表的新范式本身的力量。一个*简单的例子,比如C和C++的区别在哪?

  • 表面上,两者的语法确实有区别,但这不是本质区别。
  • C++蕴含的是一种面向对象的编程范式(Object-oriented Programming Paradigm),语法变化只是为了落地新范式的手段之一。见语法而不见OOP,就容易有点知乎所以,不入门道。
  • 面向对象编程范式,与指令式编程范式、过程式编程范式相比有什么好处?并非后者无用,它们至今都仍在各自领域发挥重要作用;旧范式的问题,往往在于不适合构建复杂系统,难以适应快速变化的商业需求。需要用*趁手的工具,解决*迫切的问题,仅此而已。

其实,中国人理解范式与技术,应该是有些独特的优势的:

  • *、先哲智慧:君子不器。“形而上者谓之道,形而下者谓之器”。道是系统,器是工具;道有主动性,器为被动性。
  • 第二、武侠文化:范式和技术,有点像武侠中的心法和招式,两者都很重要。
    • 一直在夸范式,也得扶一扶技术:赵志敬只教杨过心法,不教招式,杨过空有心法但没法用招式使出来,就容易被胖道士欺负。
    • 此外,招式具有外在性,相对容易模仿习得,反而是心法,一般是不外法门。这么说,本文的价值更大一些。:-)

4.3 业务建模的串联

如果阅读过一些相关材料,可能已经可以看出一些相关端倪了,以下摘录一段CATO的表述:

Solving emerging business challenges with point solutions leads to technical silos that are complex and costly to own and manage. Complexity slows down IT and its response to these business needs. SASE changes this paradigm through a new networking and security platform that is identity-driven, cloud-native, globally distributed, and securely connects all edges (WAN, cloud, mobile, and IoT).

这段文字很精彩,逻辑非常清晰,大意如下:

  • 用当前点状的解决方案,去解决当下涌现的业务挑战,会导致一个个技术竖井,它们的获取和管理,都很复杂且昂贵。请对照一下地心说,如果拿地心说去析构太阳系,就会有这个特点,需要定义什么“本轮”、“均轮”、“恒星天”等概念,这些概念就像是一个个技术竖井——你还是可以去逼近世界,但是会发现越来越散,越来越累,直到开始怀疑人生:“如果我是上帝,会不会弄出这么复杂的宇宙”。
  • 复杂性会降低IT对业务需求的响应速度。请结合一下SASE的大背景:你理解成VUCA的延续也行,或者分解成云计算、移动计算、边缘计算、全球化等等也行。更快的需求响应速度,正是为了解决一个一个更加挑战的现实问题;所有的2B产品,都是生产工具性质的延伸,延伸了真实世界的逻辑关系。旧工具面对新问题,已经不再趁手了。
  • SASE通过一个新的身份驱动的,云原生的,全球分布的,安全连接所有边缘的网络和安全平台,改变了当前的范式。这是在一句话总结SASE,很精彩:
    • “云原生的”,“全球分布的”,“安全连接所有边缘的”,“网络和安全平台”,这些内容涵盖在“产品形态的范式”中,以及在本系列的前期铺垫中,这里不再赘述。
    • 以下会重点析构一下“业务建模的范式”的四个基础。

4.3.1 基于身份驱动

范式还有一些有意思的特点:

  • 初阶范式*符合人类的直觉。日心说如此,*符合人们仰望天空所得的直觉;基于边界的安全模型也是类似:大到国家冲突,小到同桌别扭,千百年来人们一直都是这么直接认知的,见下表。
  • 新范式一旦被发明之后,人们会觉得新范式是多么的自然,自然到“不值一提”。翻译成不太雅的话,有点像:许久便秘的憋屈,如今一气呵成,太特么舒服了;通了就好,鬼才想回忆过往,对比分析呢。例如,日心说发明之后,一切都是那么畅快那么自然那么不值一提,你很难再理解地心说在科学精英中发展了1000多年的事实。所以,以下析构新范式的四个基础时,可能也会让你觉得“这特么不是废话”么;如果有这种效果,作者就很高兴,认为达到了初衷。

表4-1:现实世界与网络世界安全模型对比

现实世界 网络世界
安全区域 内网区域
非安全区域 外网区域
缓冲区(例如莱茵河、外蒙古) DMZ, Demilitarized Zone

SASE摒弃了传统的基于边界的安全模型,确立了“身份”这一概念的重要性:身份是所有访问决策的中心,边界退化成了至多是某种需要参考的上下文之一

%title插图%num
图4-2:基于身份驱动;来源:Gartner

本章重点要谈的就是新范式逼近现实世界的能力,所以就找一些现实世界的映衬。这一条,翻译成大白话,就是:

  • “边界”模糊了,基于边界防守的安全模型不再可靠了;
  • “你是谁”才真正重要,边界退化成了至多是某种动态上下文——因为你在哪,边界可能就需要动态地跟到哪:基于“你是谁”,配合着“什么时间”,“什么场地”、“什么工具”,“什么任务”,等等动态上下文,才是现代安全的基础。

以上是什么?活脱脱就是以海湾战争为标志的现代战争理念的变迁啊。海湾战争改变了传统的作战模式,对二战以来形成的传统战争观念,产生了强烈的震撼:

  • “边境”?在现代化的打击手段面前,想捅破时不是比纸还薄吗?
  • “身份”到哪,依托现代化的快速投送能力(软件定义网络),迅速动态地构建针对作战对象的立体防御体系(软件定义安全),完成一个VUCA时代的业务目标,不是更像“软件定义边界”么。

%title插图%num
图4-3:沙漠盾牌与沙漠风暴行动,名字都起得那么有软件定义边界感;来源:互联网

在这里特别提起海湾战争,是因为海湾战争这种现代化的“战争范式”,让人们惊掉过一回下巴,包括兔子。尼玛老美当年还通过调整卫星网络(软件定义网络),对现代战争进行了人类历史上的首次电视直播,好好“教育了一回市场”;海湾战争后,海湾地区的军火市场,直接翻番——基于传统边界建立的政权,在现代战争面前,太特么脆弱了。

“兵者,国之大事,死生之地,不可不察也”,很多革命性的理念和技术,基本全部源于军事,在解决成本问题之后,民用跟进。民用市场,不知道会不会出现一次“海湾战争式的市场教育”。

海湾战争之后的另一个战争理念变迁,是以911为代表的反恐战争,进一步崩塌了传统边界。这方面,普京大帝给出过一个精彩回答。

%title插图%num
图4-4:不受边界束缚的反恐战争;来源:互联网

普京大帝事后后悔了,觉得自己在媒体面前太冲动了,不过这更加说明了这个答案的内心真实性。

本节*后,重新回到Gartner对SASE的定义:SASE是一种基于实体的身份、实时上下文、企业安全/合规策略,以及在整个会话中持续评估风险/信任的服务。实体的身份可与人员、人员组、设备、应用、服务、物联网系统或边缘计算场地相关联。

SASE按需提供所需的服务和策略执行,独立于请求服务的实体、场所和所访问的服务。

%title插图%num
图4-5:基于身份和动态上下文的功能栈;来源:Gartner

一些「基于身份驱动」的段子,活跃一下提到高大上机构之后的肃穆气氛:

我妈挖了一勺西瓜没拿稳掉地上了,她捡起来就要往我嘴里塞,看见我很诧异地盯着她,突然反应过来笑着说:“不好意思,我还以为你还是小时候呢!” 我突然感觉胸口有点疼。

身份+时间上下文:只核实了身份,没有留意时间上下文。

昨晚在路边停车等人,有个脑袋探到窗边问:“走吗?” 我心想:我TM又不是来拉客的黑车,于是头也不抬地说:“不走!” 过了一会儿,他递进来一张罚单。

身份+场地上下文:只留意到了位置上下文,没有核实身份。

一位北方的朋友去重庆吃火锅,问:“有麻酱吗?” 服务员说:“麻将要开包间才有。”

身份+场地上下文+访问信息的敏感程度:只核实了身份,没有留意位置上下文,以及访问信息的敏感程度。

以上段子,并不能直接套在SASE上,只是用来说明:用“基于身份驱动+动态上下文”,比“基于边界+隐含身份”,是更容易写出清晰易懂的规则去逼近真实世界的。

4.3.2 基于动态信任

可能有点残酷,但是现实世界里,可能不存在*对信任,信任是一个动态过程。以下两位大佬,对此颇有心得。

%title插图%num
图4-6:动态信任;来源:混子曰

两位大佬虽然签订了《苏德互不侵犯条约》,但都在之后疯狂瓜分夹在其中的国家作为缓冲区(基于边界的安全模型);结果已经明了了,谁信的更多一些谁倒霉。

不了解历史也没关系,回顾一下我们自己认识新朋友的心路历程,也可以足够明了:刚认识一个人时,信任是比较模糊的;随着“听其言观其行”,慢慢会对不同的人发展出不同的信任程度;但是无论到哪种程度,信任总是有范围的,不是*对的。

不知道孩子的初始状态是否有*对信任,不过长大之后都慢慢被教会了动态信任,说残酷也行,说成熟也行,这就是现实。动态信任,更能逼近现实世界。

「基于身份驱动」和「基于动态信任」是什么关系?觉得前者是信任的动态载体,后者是信任的动态过程。

活跃一下气氛,一些「基于动态信任」相关的段子:

朋友说他的媳妇儿特别懒,我问咋了,他说他家住三楼,他媳妇儿每次在网上买东西的时候都在备注上写:“孕妇,行动不便,请送货上门!” 前些天,快递小哥终于忍不住了,在楼下大喊:“三年了!我忍了你三年了!你怀的是哪吒吗!!”

这位快递小哥,具备了人性的初始信任,*后被迫学会了动态信任。

长官问花木兰:“听说你在出征前,先到东市买了骏马,再去西市买了鞍鞯,然后去南市买了辔头,*后,又到北市去买了长鞭,是不是这样?”

木兰说:“确实如此。”

长官接着问:“你是女人吧。”

木兰感觉十分吃惊:“将军你是如何得知我是女人?”

长官缓缓说道:“如果是男人,*对是不会跑去逛了四个市集,而就为了买这些东西的。”

这位长官很老道,已然具备了初级的态势感知能力,至少是全流量分析的能力。

以上两个段子,也在侧面说明:

  • 身份还是静态的,相对容易伪造;行为模式等是动态的,相对更难隐藏。
  • 在身份被突防之后,通过动态信任机制建立起的安全模型,更容易逼近现实世界。

4.3.3 基于分层设计

分层,是人们简化世界,理解世界的必须。网络原本就存在分层,例如广为人知的OSI七层模型。

%title插图%num
图4-7:OSI模型;来源:互联网

但问题是,从架构角度而言,这里的网络层,存在着较大问题。倒不是作者狂妄到敢批判协议,而是这与历史有关:还是那句话,哪怕是顶级专家,都容易低估未来,当时互联网规模*小,安全性并非设计时的首要考虑因素。网络层,顾名思义负责网络连接,这意味着它要面临整个世界的攻击面,但自身却缺乏有效的安全机制。活脱脱一个傻白甜,“傻白甜”只是一种昵称,另一个说法叫“坑爹”。

一个典型的例子就是DDoS类中的SYN Flood攻击:“爹在家中坐,祸从天上来”。

简单介绍一下SYN Flood攻击:TCP是面向连接的传输层协议,大量的应用都基于TCP协议;因为是面向连接的协议,所以建立一个TCP连接需要经历一个三步握手过程,以下选了一张比较直白的原理图。

%title插图%num
图4-8:TCP三步握手;来源:https://github.com/jawil/blog/issues/14

SYN Flood攻击者,操作一批肉鸡向服务器喊话:“喂,你在吗,伸出手来咱握一握呗”,然后玩消失,留着服务器在那伸手后傻等,直到超时。这种方式会消耗服务器大量的连接资源,进而没有能力去服务合法用户。

%title插图%num
图4-9:SYN Flood攻击;来源:AllOT

SYN Flood为什么能成功,是因为攻击者的喊话,在协议层面是完全合法的,服务器无法区分,只能做应答。作为家中端坐的爹(TCP层),心中定是一万头草泥马,丫的老子的手是谁都可以摸的吗?你丫龟儿子(IP层)能不能认清了再往家里带!

IP层说儿做不到啊!事实上,IP层确实做不到,因为“认人”这事,带了点语义层面的逻辑,IP层就一个负责通道的,哪管得到语义层面的事。那该怎么办呢?“网络革命的一声炮响,给我们送来了SDN主义”。SASE在这方面的革新,更进一步,采用了零信任的理念,例如CSA(Cloud Security Alliance, 云安全联盟)的SDP(Software-Defined Perimeter, 软件定义边界)实现方式:通过独立的认证中心,隐藏网络基础设施;通过SPA(Single Packet Authorization, 单包授权认证)技术,隐藏认证中心自己。结果就是在网络层,形成了一朵近乎零攻击面的暗云(Dark Cloud),从根本上解决了网络层自身的安全问题。

为什么说这也是SASE的范式基础,是因为长期以来,我们其实已经躺平接受了:网络层搞不定的安全问题,就蔓延到其他地方去转移解决。

可能会有人觉得,你SASE不也把问题转移到其他地方去了吗?对,不过这种转移,在架构上有着本质区别:这不是在纵向的层级之间转移,而是横向转移给了更加专业的管控平面或者认证平面,逻辑清晰,平面隔离。

继续拿现实世界做类比,你是否会把任何对象先领进家门,让家长先握握手保持联系?不会,家长有家长要负责的头疼事,你会先委托专业的第三方检查对方身份并开介绍信,比如具有国家信用背书的公安部门,有问题的对象,聪明如你,肯定连家门都不会让他找到。

注意,通过以上分析,希望也可以理解到,包括零信任、包括SASE,其实也解决不了全部的安全问题,理论上只能解决可管控范围内的部分问题。

4.3.4 统一开放架构

统一开放架构,可能是个隐藏的范式基础,但是已经比较好推导了:

  • 基于身份驱动,意味着认证中心需要独立于业务网络,这样才能独立完成初始验证。
  • 基于分层设计,意味着控制中心需要独立于业务网络,这样才能在完成初始验证后,控制整个网络基础设施的基于*小授权原则的闭合(先验证再*小授权再开放再连接),以及集中控制网络功能和安全功能的动态投放。
  • 基于动态信任,意味着评估中心需要独立于业务网络,评估中心采集包括认证中心、控制中心、网络基础设施等在内的全貌信息,这样才有可能通过记录、分析,态势感知等,保持动态信任。

以上,外加SASE需要较为完备的网络栈和安全栈,很难由一家独自完成,都意味着需要一个统一开放架构,去持续探索相关行业*佳实践。这方面,已经跟主流SD-WAN产品紧密相关了,而且更能体现出SD-WAN作为广域网云化这一生产方式变迁的发酵作用;此外,统一开放架构也还会进一步与其他相关领域综合演进,诸如云原生、NFV等。这些方面,稍后分析MEC时,会尽量做些力所能及的说明。

本节*后,回应一下一个潜在问题和一个潜在趋势:

  • 潜在问题:传统的安全功能还有用吗?当然有用,C语言不是也还至今顽强么;只不过在很多场合,可能需要适配到包括统一开放架构在内的范式框架中。
  • 潜在趋势:产业互联网可能会与SASE有什么样的关系?直接以5G为例,原文引用5G架构协议中的一些架构原则:
    • “Separate the User Plane (UP) functions from the Control Plane (CP) functions, allowing independent scalability, evolution and flexible deployments e.g. centralized location or distributed (remote) location.” 俗称的CUPS(控制平面与数据平面彻底分离),带来在独立伸缩性、演进性以及灵活部署方面的诸多优势。可以看作是基于分层设计以及基于统一开放架构方面的表现。
    • “Enable each Network Function and its Network Function Services to interact with other NF and its Network Function Services directly or indirectly via a Service Communication Proxy if required.” 每个网络功能和网络功能服务与其它网络功能和网络功能服务之间的交互,通过直接方式,或者以服务通信代理的方式间接完成。可以看作是基于统一开放架构方面的表现。
    • “Support a unified authentication framework.” 支持统一的身份验证框架。可以看作是基于身份驱动,基于分层设计,以及基于统一开放架构方面的表现。
    • 基于动态信任,作者当前暂未在协议层面找到,但可以理解,因为当前协议更多是在基础设施层面做规范,而基于动态信任有点偏向于业务建模方面。但即便如此,还是倾向于预测:在5G的各个层面,逐步都会有更多基于动态信任的体现。

SASE系列至此完结,下一话题会过度到5G MEC。如果要从事ICT行业,离不开参考协议,但协议可能比字典还厚,所以会侧重于对协议的导读和分析。听到过一些对通信行业的误解,觉得相对较大的一个就是“通信行业是协议驱动”,那就从澄清这个误解开始。

%title插图%num

后记

预测趋势要比预测时间点简单得多,一些分析判断:

  • 5G、物联网、边缘计算等技术革新,不是为了技术而技术,而是为了能将数字化、信息化、智能化,从消费互联网行业,延展到更为广阔的产业互联网领域。
  • 为什么产业互联网重要?因为第三次科技革命所能支撑起的消费互联网,已经接近尾声了,存量搏杀越来越激烈,政府、企业,都迫切需要新的增量来安抚“不安的灵魂”。
  • 那当下产业互联网为什么难做?除了技术原因之外,需要的主流创新模式不同。越上层的创新,复制起来也相对越快,这也客观造就了当下能直接复制解决的问题,大部分都已经解决了。这种情况下,需要ICT(Information and Communication Technology,信息和通信技术)领域与各个行业领域,能有更加广泛而深入的交流与融合,在原理层面相互理解贯通,才有可能孵化出更有意义的产品

Kubernetes 也有局限性吗?

2014 年发布的 Kubernetes 在今天俨然已成为容器编排领域的事实标准,相信谈到 Kubernetes 的开发者都会一再复述上述现象。如下图所示,今天的大多数个人或者团队都会选择 Kubernetes 管理容器,而也有 75% 的人会在生产环境中使用 Kubernetes。

%title插图%num图 1 – Kubernetes 容器编排[^1]

在这种全民学习和使用 Kubernetes 的大背景下,我们也应该非常清晰地知道 Kubernetes 有哪些局限性。虽然 Kubernetes 能够解决容器编排领域的大多数问题,但是仍然有一些场景是它很难处理、甚至无法处理的,只有对这些潜在的风险有清晰的认识,才能更好地驾驭这项技术,这篇文章将从集群管理和应用场景两个部分谈谈 Kubernetes 社区目前的发展和一些局限性。

%title插图%num

集群管理

集群是一组能够在一起协同工作的计算机,我们可以将集群中的所有计算机看成一个整体,所有资源调度系统都是以集群为维度进行管理的,集群中的所有机器构成了资源池,这个巨大的资源池会为待运行的容器提供资源执行计算任务,这里简单谈一谈 Kubernetes 集群管理面对的几个复杂问题。

%title插图%num

水平扩展性

集群大小是我们在评估资源管理系统时需要关注的重要指标之一,然而 Kubernetes 能够管理的集群规模远远小于业界的其他资源管理系统。集群大小为什么重要呢,我们先来看另一个同样重要的指标 — 资源利用率,很多工程师可能没有在公有云平台上申请过资源,这些资源都相当昂贵,在 AWS 上申请一个与主机差不多配置的虚拟机实例(8 CPU、16 GB)每个月大概需要 150 美金,约为 1000 人民币[^2]。

%title插图%num

图 2 – AWS EC2 价格

大多数的集群都会使用 48 CPU 或者 64 CPU 的物理机或者虚拟机作为集群中的节点,如果我们的集群中需要包含 5,000 个节点,那么这些节点每个月大概要 8,000,000 美元,约为 50,000,000 人民币,在这样的集群中提升 1% 的资源利用率就相当于每个月节省了 500,000 的成本。

多数在线任务的资源利用率都很低,更大的集群意味着能够运行更多的工作负载,而多种高峰和低谷期不同的负载部署在一起可以实现超售,这样能够显著地提高集群的资源利用率,如果单个集群的节点数足够多,我们在部署不同类型的任务时会有更合理的组合,可以完美错开不同服务的高峰期。

Kubernetes 社区对外宣传的是单个集群*多支持 5,000 节点,Pod 总数不超过 150,000,容器总数不超过 300,000 以及单节点 Pod 数量不超过 100 个[^3],与几万节点的 Apache Mesos 集群、50,000 节点的微软 YARN 集群[^4]相比,Kubernetes 的集群规模整整差了一个数量级。虽然阿里云的工程师也通过优化 Kubernetes 的各个组件实现了 5 位数的集群规模,但是与其他的资源管理方式相比却有比较大的差距[^5]。

%title插图%num

图 3 – Apache Mesos 与 Hadoop YARN

需要注意的是 Kubernetes 社区虽然对外宣称单集群可以支持 5,000 节点,同时社区也有各种各样的集成测试保证每个改动都不会影响它的伸缩性[^6],但是 Kubernetes 真的非常复杂,我们没有办法保证你使用的每个功能在扩容的过程中都不出问题。而在生产环境中,我们甚至可能在集群扩容到 1000 ~ 1500 节点时遇到瓶颈。

每个稍具规模的大公司都想要实现更大规模的 Kubernetes 集群,但是这不是一个改几行代码就能解决的简单问题,它可能需要我们限制 Kubernetes 中一些功能的使用,在扩容的过程中,etcd、API 服务器、调度器以及控制器都有可能出现问题。社区中已经有一些开发者注意到了其中的一些问题,例如在节点上增加缓存降低 API 服务器的负载[^7],但是要推动类似的改变还是很困难的,有志之士可以尝试在社区推动类似的项目。

%title插图%num

多集群管理

单个集群的容量再大也无法解决企业面对的问题,哪怕有一天 Kubernetes 集群可以达到 50,000 节点的规模,我们仍然需要管理多个集群,多集群管理也是 Kubernetes 社区目前正在探索的方向,社区中的多集群兴趣小组(SIG Multi-Cluster)目前就在完成相关的工作[^8]。在作者看来,Kubernetes 的多集群会带来资源不平衡、跨集群访问困难以及提高运维和管理成本三大问题,我们在这里谈一谈目前在开源社区和业界几种可供参考和选择的解决方案。

%title插图%num

kubefed

首先要介绍的是 kubefed,该项目是 Kubernetes 社区给出的解决方案,它同时提供了跨集群的资源和网络管理的功能,社区的多集群兴趣小组(SIG Multi-Cluster)负责了该项目的开发工作:

%title插图%num

图 4 – Kubernetes 联邦

kubefed 通过一个中心化的联邦控制面板管理多集群中的元数据,上层的控制面板会为管理器群中的资源创建对应的联邦对象,例如:FederatedDeployment:

  1. kind: FederatedDeployment
  2. spec:
  3.   …
  4.   overrides:
  5.   # Apply overrides to cluster1
  6.     – clusterName: cluster1
  7.       clusterOverrides:
  8.         # Set the replicas field to 5
  9.         – path: “/spec/replicas”
  10.           value: 5
  11.         # Set the image of the first container
  12.         – path: “/spec/template/spec/containers/0/image”
  13.           value: “nginx:1.17.0-alpine”
  14.         # Ensure the annotation “foo: bar” exists
  15.         – path: “/metadata/annotations”
  16.           op: “add”
  17.           value:
  18.             foo: bar
  19.         # Ensure an annotation with key “foo” does not exist
  20.         – path: “/metadata/annotations/foo”
  21.           op: “remove”
  22.         # Adds an argument `-q` at index 0 of the args list
  23.         # this will obviously shift the existing arguments, if any
  24.         – path: “/spec/template/spec/containers/0/args/0”
  25.           op: “add”
  26.           value: “-q”

上层的控制面板会根据联邦对象 FederatedDeployment 的规格文件生成对应的 Deployment 并推送到下层的集群,下层集群可以正常根据 Deployment 中的定义创建特定数量的副本。

%title插图%num

图 5 – 从联邦对象到普通对象

FederatedDeployment 只是一种*简单的分发策略,在生产环境中我们希望通过联邦的集群实现容灾等复杂功能,这时可以利用 ReplicaSchedulingPreference 在不同集群中实现更加智能的分发策略:

  1. apiVersion: scheduling.kubefed.io/v1alpha1
  2. kind: ReplicaSchedulingPreference
  3. metadata:
  4.   name: test-deployment
  5.   namespacetestns
  6. spec:
  7.   targetKindFederatedDeployment
  8.   totalReplicas: 9
  9.   clusters:
  10.     A:
  11.       minReplicas: 4
  12.       maxReplicas: 6
  13.       weight: 1
  14.     B:
  15.       minReplicas: 4
  16.       maxReplicas: 8
  17.       weight: 2

上述调度的策略可以实现工作负载在不同集群之间的权重,在集群资源不足甚至出现问题时将实例迁移到其他集群,这样既能够提高服务部署的灵活性和可用性,基础架构工程师也可以更好地平衡多个集群的负载。

我们可以认为 kubefed 的主要作用是将多个松散的集群组成强耦合的联邦集群,并提供更加高级的网络和部署功能,这样我们可以更容易地解决集群之间资源不平衡和连通性的一些问题,然而该项目的关注点不包含集群生命周期的管理。

%title插图%num

集群接口

Cluster API 也是 Kubernetes 社区中与多集群管理相关的项目,该项目由集群生命周期小组(SIG Cluster-Lifecycle)负责开发,其主要目标是通过声明式的 API 简化多集群的准备、更新和运维工作,你在该项目的 设计提案 中能够找到它的职责范围[^9]。

%title插图%num

图 6 – Cluster API 概念

在该项目中*重要的资源就是 Machine,它表示一个 Kubernetes 集群中的节点。当该资源被创建时,特定提供商的控制器会根据机器的定义初始化并将新的节点注册到集群中,在该资源被更新或者删除时,也会执行操作达到用户的状态。

这种策略与阿里的多集群管理的方式有一些相似,它们都使用声明式的 API 定义机器和集群的状态,然后使用 Kubernetes 原生的 Operator 模型在更高一层的集群中管理下层集群,这能够*大降低集群的运维成本并提高集群的运行效率[^10],不过类似的项目都没有考虑跨集群的资源管理和网络管理。

%title插图%num

应用场景

我们在这一节将谈谈 Kubernetes 中一些有趣的应用场景,其中包括应用分发方式的现状、批处理调度任务以及硬多租户在集群中的支持,这些是社区中比较关注的问题,也是 Kubernetes 目前的盲点。

应用分发

Kubernetes 主项目提供了几种部署应用的*基本方式,分别是 Deployment、StatefulSet 和 DaemonSet,这些资源分别适用于无状态服务、有状态服务和节点上的守护进程,这些资源能够提供*基本的策略,但是它们无法处理更加复杂的应用。

%title插图%num

图 7 – Kubernetes 应用管理

随着 CRD 的引入,目前社区的应用管理小组(SIG Apps)基本不会向 Kubernetes 主仓库引入较大的改动,大多数的改动都是在现有资源上进行的修补,很多常见的场景,例如只运行一次的 DaemonSet[^11] 以及金丝雀和蓝绿部署等功能,现在的资源也存在很多问题,例如 StatefulSet 在初始化容器中卡住无法回滚和更新[^12]。

我们可以理解社区不想在 Kubernetes 中维护更多的基本资源,通过几个基本的资源可以覆盖 90% 的场景,剩下的各种复杂场景可以让其他社区通过 CRD 的方式实现。不过作者认为如果社区能够在上游实现更多高质量的组件,这对于整个生态都是很有价值并且很重要的工作,需要注意的是假如各位读者想要在 Kubernetes 项目中成为贡献者,SIG Apps 可能不是一个很好的选择。

批处理调度

机器学习、批处理任务和流式任务等工作负载的运行从 Kubernetes 诞生*天起到今天都不是它的强项,大多数的公司都会使用 Kubernetes 运行在线服务处理用户请求,用 Yarn 管理的集群运行批处理的负载。

%title插图%num

hadoop-yarn

图 8 – Hadoop Yarn

在线任务和离线任务往往是两种截然不同的作业,大多数的在线任务都是无状态的服务,它们可以在不同机器上进行迁移,彼此很难有*强的依赖关系;但是很多离线任务的拓扑结构都很复杂,有些任务需要多个作业一同执行,而有些任务需要按照依赖关系先后执行,这种复杂的调度场景在 Kubernetes 中比较难以处理。

在 Kubernetes 调度器引入调度框架之前,所有的 Pod 在调度器看来是没有任何关联的,不过有了调度框架,我们可以在调度系统中实现更加复杂的调度策略,例如保证一组 Pod 同时调度的 PodGroup[^13],这对于 Spark 和 TensorFlow 任务非常有用。

  1. # PodGroup CRD spec
  2. apiVersion: scheduling.sigs.k8s.io/v1alpha1
  3. kind: PodGroup
  4. metadata:
  5.   name: nginx
  6. spec:
  7.   scheduleTimeoutSeconds: 10
  8.   minMember: 3
  9. # Add a label `pod-group.scheduling.sigs.k8s.io` to mark the pod belongs to a group
  10. labels:
  11.   pod-group.scheduling.sigs.k8s.io: nginx

Volcano 也是在 Kubernetes 上构建的批处理任务管理系统[^14],它能够处理机器学习、深度学习以及其他大数据应用,可以支持包括 TensorFlow、Spark、PyTorch 和 MPI 在内的多个框架。

%title插图%num

图 9 – Volcano

虽然 Kubernetes 能够运行一些批处理任务,但是距离在这个领域上取代 Yarn 等老牌资源管理系统上还有非常大的差距,相信在较长的一段时间内,大多数公司都会同时维护 Kubernetes 和 Yarn 两种技术栈,分别管理和运行不同类型的工作负载。

硬多租户

多租户是指同一个软件实例可以为不同的用户组提供服务,Kubernetes 的多租户是指多个用户或者用户组使用同一个 Kubernetes 集群,今天的 Kubernetes 还很难做到硬多租户支持,也就是同一个集群的多个租户不会相互影响,也感知不到彼此的存在。

硬多租户在 Kubernetes 中是一个很重要、也很困难的课题,合租公寓就是一个典型的多租户场景,多个租客共享房屋内的基础设施,硬多租户要求多个访客之间不会相互影响,你可以想象这有多么困难,Kubernetes 社区甚至有一个工作小组专门讨论和研究相关的问题[^15],然而虽然感兴趣的工程师很多,但是成果却非常有限。

%title插图%num

图 10 – 多租户

尽管 Kubernetes 使用命名空间来划分虚拟机群,然而这也很难实现真正的多租户。多租户的支持到底有哪些作用呢,这里简单列几个多租户带来的好处:

  • Kubernetes 带来的额外部署成本对于小集群来说非常高昂,稳定的 Kubernetes 集群一般都需要至少三个运行 etcd 的主节点,如果大多数的集群都是小集群,这些额外的机器会带来很高的额外开销;
  • Kubernetes 中运行的容器可能需要共享物理机和虚拟机,一些开发者可能在公司内部遇到过自己的服务被其他业务影响,因为主机上容器可能隔离了 CPU 和内存资源,但是没有隔离 I/O、网络 和 CPU 缓存等资源,这些资源的隔离是相对困难的;

如果 Kubernetes 能够实现硬多租户,这不仅对云服务商和小集群的使用者来说都是个福音,它还能够隔离不同容器之间的影响并防止潜在安全问题的发生,不过这在现阶段还是比较难实现的。

%title插图%num

总结

每个技术都有自己的生命周期,越底层的技术生命周期会越长,而越上层的技术生命周期也就越短,虽然 Kubernetes 是当今容器界的扛把子,但是未来的事情没有人可以说的准。我们要时刻清楚手中工具的优点和缺点,花一些时间学习 Kubernetes 中设计的精髓,不过如果在未来的某一天 Kubernetes 也成为了过去,我们也应该感到喜悦,因为会有更好的工具取代它。

[^1]: Kubernetes and Container Security and Adoption Trends https://www.stackrox.com/kubernetes-adoption-security-and-market-share-for-containers/

[^2]: AWS Pricing Calculator https://calculator.aws/#/createCalculator/EC2

[^3]: Considerations for large clusters https://kubernetes.io/docs/setup/best-practices/cluster-large/

[^4]: How Microsoft drives exabyte analytics on the world’s largest YARN cluster https://azure.microsoft.com/en-us/blog/how-microsoft-drives-exabyte-analytics-on-the-world-s-largest-yarn-cluster/

[^5]: 备战双 11!蚂蚁金服万级规模 K8s 集群管理系统如何设计?https://www.sofastack.tech/blog/ant-financial-managing-large-scale-kubernetes-clusters/

[^6]: sig-scalability-kubemark dashboard https://testgrid.k8s.io/sig-scalability-kubemark#kubemark-5000

[^7]: Node-local API cache #84248 https://github.com/kubernetes/kubernetes/issues/84248

[^8]: Multicluster Special Interest Group https://github.com/kubernetes/community/tree/master/sig-multicluster

[^9]: Cluster API Scope and Objectives https://github.com/kubernetes-sigs/cluster-api/blob/master/docs/scope-and-objectives.md

[^10]: Demystifying Kubernetes as a service – How Alibaba cloud manages 10,000s of Kubernetes clusters https://www.cncf.io/blog/2019/12/12/demystifying-kubernetes-as-a-service-how-does-alibaba-cloud-manage-10000s-of-kubernetes-clusters/

[^11]: Run job on each node once to help with setup #64623 https://github.com/kubernetes/kubernetes/issues/64623

[^12]: StatefulSet does not upgrade to a newer version of manifests #78007 https://github.com/kubernetes/kubernetes/issues/78007

[^13]: Coscheduling based on PodGroup CRD https://github.com/kubernetes-sigs/scheduler-plugins/tree/master/kep/42-podgroup-coscheduling

[^14]: Volcano · A Kubernetes Native Batch System https://github.com/volcano-sh/volcano

[^15]: Kubernetes Working Group for Multi-Tenancy https://github.com/kubernetes-sigs/multi-tenancy

iOS 使用QLPreviewController预览本地和网络文件

iOS 使用QLPreviewController预览本地和网络文件

*近在项目中要做一个文档预览的功能,做的时候用到了iOS原生的QLPreviewController类,在此做个记录分享

首先引入头文件

#import <QuickLook/QuickLook.h>

遵循代理

 

QLPreviewControllerDataSource

声明一个QLPreviewController变量

 

@property (strong, nonatomic)QLPreviewController *previewController;

 

再声明一个NSUrl对象存放要返回的文件路径

 

@property (copy, nonatomic)NSURL *fileURL;
 

在viewDidLoad中初始化

  1. – (void)viewDidLoad {
  2. [super viewDidLoad];
  3. self.previewController = [[QLPreviewController alloc] init];
  4. self.previewController.dataSource = self;
  5. }

 

 

在预览本地文件的事件里面写下如下代码

  1. //获取本地文件路径
  2. self.fileURL = [NSURL fileURLWithPath:[[NSBundle mainBundle]pathForResource:@”李碧华佳句赏析.doc” ofType:nil]];
  3. [self presentViewController:self.previewController animated:YES completion:nil];

遵循代理方法

  1. #pragma mark – QLPreviewControllerDataSource
  2. -(id<QLPreviewItem>)previewController:(QLPreviewController *)controller previewItemAtIndex:(NSInteger)index {
  3. return self.fileURL;
  4. }
  5. – (NSInteger)numberOfPreviewItemsInPreviewController:(QLPreviewController *)previewController{
  6. return 1;
  7. }

这样本地文件的预览就成了

 

添加文件到项目的时候要注意,将文件放到工程项目之后,还要到Build Phases的Copy Bundle Resources中将文件添加到资源库,不然使用的时候会找不到文件而崩溃

 

接下来是预览网络文件

在网络文件预览的事件里面写下如下代码(需要引入af)

  1. NSURLSessionConfiguration *configuration = [NSURLSessionConfiguration defaultSessionConfiguration];
  2. AFURLSessionManager *manager = [[AFURLSessionManager alloc] initWithSessionConfiguration:configuration];
  3. NSString *urlStr = @”https://www.tutorialspoint.com/ios/ios_tutorial.pdf”;
  4. NSString *fileName = [urlStr lastPathComponent]; //获取文件名称
  5. NSURL *URL = [NSURL URLWithString:urlStr];
  6. NSURLRequest *request = [NSURLRequest requestWithURL:URL];
  7. //判断是否存在
  8. if([self isFileExist:fileName]) {
  9. NSURL *documentsDirectoryURL = [[NSFileManager defaultManager] URLForDirectory:NSDocumentDirectory inDomain:NSUserDomainMask appropriateForURL:nil create:NO error:nil];
  10. NSURL *url = [documentsDirectoryURL URLByAppendingPathComponent:fileName];
  11. self.fileURL = url;
  12. [self presentViewController:self.previewController animated:YES completion:nil];
  13. }else {
  14. [SVProgressHUD showWithStatus:@”下载中”];
  15. NSURLSessionDownloadTask *downloadTask = [manager downloadTaskWithRequest:request progress:^(NSProgress *downloadProgress){
  16. } destination:^NSURL *(NSURL *targetPath, NSURLResponse *response) {
  17. NSURL *documentsDirectoryURL = [[NSFileManager defaultManager] URLForDirectory:NSDocumentDirectory inDomain:NSUserDomainMask appropriateForURL:nil create:NO error:nil];
  18. NSURL *url = [documentsDirectoryURL URLByAppendingPathComponent:fileName];
  19. return url;
  20. } completionHandler:^(NSURLResponse *response, NSURL *filePath, NSError *error) {
  21. [SVProgressHUD dismiss];
  22. self.fileURL = filePath;
  23. [self presentViewController:self.previewController animated:YES completion:nil];
  24. }];
  25. [downloadTask resume];
  26. }

添加文件是否存在判断方法

  1. //判断文件是否已经在沙盒中存在
  2. -(BOOL) isFileExist:(NSString *)fileName
  3. {
  4. NSArray *paths = NSSearchPathForDirectoriesInDomains(NSDocumentDirectory, NSUserDomainMask, YES);
  5. NSString *path = [paths objectAtIndex:0];
  6. NSString *filePath = [path stringByAppendingPathComponent:fileName];
  7. NSFileManager *fileManager = [NSFileManager defaultManager];
  8. BOOL result = [fileManager fileExistsAtPath:filePath];
  9. return result;
  10. }

 

 

这样网络文件预览就成了

iOS 证书设置指南

创建应用程序 ID
登陆 苹果开发者网站 进入开发者账户。

%title插图%num
从开发者账户页面左侧入口进入 “Certificates, IDs & Profiles” 页面。

%title插图%num
创建 App ID,填写 App ID 的 NAME 和 Bundle ID(如果 ID 已经存在可以直接跳过此步骤)。

%title插图%num
注: 此处需要指定具体的 Bundle ID 不要使用通配符。

%title插图%num
为 App 开启 Push Notification 功能。如果是已经创建的 App ID 也可以通过设置开启 Push Notification 功能。

%title插图%num
填写好以上属性后,点击 “Continue”,确认 AppId 属性的正确性,点击 “Register”,注册 AppId 成功。
两种鉴权方式的配置
*光官网应用的鉴权信息一旦配置,只能用相同 bundleID 的鉴权信息进行更新,无法修改为其他的 bundleID,请在配置前仔细检查 bundleID 是否正确,若因特殊原因需要修改,请联系 support@jpush.cn

方式一:通过 .p12 证书鉴权
如果你之前没有创建过 Push 证书或者是要重新创建一个新的,请在证书列表下面新建。

%title插图%num
新建证书需要注意选择 APNs 证书种类。如图 APNs 证书有开发(Development)和生产(Production)两种。
注:开发证书用于开发调试使用;生产证书既能用于开发调试,也可用于产品发布。此处我们选择生产证书为例。

%title插图%num
点击 “Continue”, 之后选择该证书准备绑定的 AppID。

%title插图%num
再点 “Continue” 会让你上传 CSR 文件。( CSR 文件会在下一步创建)

%title插图%num
打开系统自带的 KeychainAccess 创建 Certificate Signing Request。如下图操作:

%title插图%num
填写“用户邮箱”和“常用名称” ,并选择“存储到磁盘”,证书文件后缀为 .certSigningRequest 。

%title插图%num
回到浏览器中 CSR 上传页面,上传刚刚生成的后缀为 .certSigningRequest 的文件。
生成证书成功后,点击 “Download” 按钮把证书下载下来,是后缀为 .cer 的文件。

%title插图%num
双击证书后,会在 “KeychainAccess” 中打开,选择左侧“钥匙串”列表中“登录”,以及“种类”列表中“我的证书”,找到刚才下载的证书,并导出为 .p12 文件。如下图:

%title插图%num

%title插图%num

在*光控制台上,进入你应用的应用设置中 iOS 的鉴权方式选择 “证书”,上传刚才导出的 .p12 证书。*光会在后台为你的应用进行鉴权。
Apple 的生产推送证书允许用于开发环境的推送,勾选将生产证书用于开发环境,开发者可以仅上传生产证书,即可在官网推送平台处选择开发环境做推送,不用再生成和上传开发证书。

%title插图%num
方式二:通过 APNs Auth Key 鉴权
点击左侧列表 “Keys” 中的 “All”,看账户中是否已有 auth key,没有则点击 “+” 新建。

%title插图%num
填写该 key 的描述并选择服务,如下图。 (注:在开发和生产环境均可使用,且不会过期。)

%title插图%num
点击 “Continue” 让你确认信息,再点击 “confirm”,就可以下载该 key 了。(注意:记下 key id,而且只可以下载一次,请妥善保存。)

%title插图%num
获取你之前创建过的应用的 Bundle ID

%title插图%num
在开发者账户的 “Membership” 页面获取 Team ID

%title插图%num
在*光控制台上,进入你应用的应用设置中 iOS 的鉴权方式选择 “Token Authentication”,上传 auth key 文件,并填写你的 KEY ID,TeamID,和指定应用的 BundleID。*光会在后台为你的应用进行鉴权。

%title插图%num
Provisioning Profile 的创建
创建 Provisioning Profile 的前提,已在 Apple Developer 网站创建待发布应用所使用的 Bundle ID 的 App ID,且为该 App ID 创建了 iOS Development 证书。

在苹果开发者账号的 Provisioning Profile 页面点击下图按钮,创建 Provisioning Profile

%title插图%num

选择此 Provisioning Profile 的环境后点击 [Continue]:

%title插图%num
选择要创建 Provisioning Profile 的 App ID 后点击 [Continue]:

%title插图%num
选择所属的开发者证书,(这里创建了多个开发者证书,建议只创建一个,方便管理)为了方便,选择了 [Select All],再点击 [Continue] 进入下一步:

%title插图%num
为该 Provisioning Profile 选择将要安装的设备(一般选择 [Select All]),点击 [Continue]:

%title插图%num
给该 Provisioning Profile 填写 Profile Name,点击 [generate] 完成创建。

%title插图%num
填写完 Profile Name 后点击 [generate] 完成创建,之后点击 [DownLoad] 下载 Provisioning Profile

%title插图%num
双击下载下来的 Provisioning Profile,添加到 xcode。
XCode 的证书配置教程
参照 iOS SDK 集成指南集成 JPush SDK 和上传了推送用到的 p12 证书后在编译运行前需要先配置一下证书,步骤如下:

打开 xxx-info.plist 的 Bundle identifier 项把上传到 JPush 控制台的 bundle id 填写进去:

%title插图%num
点击项目,选择目标 TARGETS 后进入 Build Setting 界面,搜索 “Code signing”,按照下图配置

%title插图%num