NASA太难了:将247 PB数据放到AWS却付不起高额下载成本

NASA太难了:将247 PB数据放到AWS却付不起高额下载成本

閱讀本文約花費: 8 (分鐘) 单是这一项决策失误,就让 NASA 的云战略从天堂瞬间跌进了地狱。 到 2025 年,美国宇航局(NASA)计划新增 215 PB 数据存储空间,并希望 AWS 能够提供其中大部分云存储的容量。但让 NASA 没想到的是:把数据迁移至云端之后,出口端的数据下载成本却大幅激增,而他们并没给这比投入做预算。 换句话说,以后科学家们必须得付费才能下载这些本就属于他们的数据。 单是这一项决策失误,就让 NASA 的云战略从天堂瞬间跌进了地狱。 按原定计划,NASA 到 2025 年将拥有 247 PB 的数据处理能力,这些数据放在云端。NASA 跟 AWS 签下的是一笔多大的单子呢?每月花费达 543.9 万美元。到 2025 年,除 6500 万美元的原有交易额外,NASA 每年还得额外向 AWS 支付约 3000 万美元的新增云服务开销。 NASA 忘了一个前提——云端数据下载成本 受到影响的数据主要来自 NASA 下辖的地球科学数据与信息系统(ESDIS)计划,此项计划旨在从与地球观测相关的众多空间任务中收集信息。收集完成后,相应读数将由地球观测系统数据与信息系统(EOSDIS)向各研究机构交付。 为了存储所有数据并支持整套 EOSDIS,NASA 运营有 12 处分布式主归档中心(DAAC),并借此带来安全稳定的冗余和备份。但沉重的基础设施管理负担也…

Read More Read More

分布式系统中最基础的 CAP 理论及其应用

分布式系统中最基础的 CAP 理论及其应用

閱讀本文約花費: 10 (分鐘) 我们主要介绍分布式系统中最基础的 CAP 理论及其应用。 对于开发或设计分布式系统的架构师、工程师来说,CAP 是必须要掌握的基础理论,CAP 理论可以帮助架构师对系统设计中目标进行取舍,合理的规划系统拆分的维度。下面我们先讲讲分布式系统的特点。 分布式系统的特点 随着移动互联网的快速发展,互联网的用户数量越来越多,产生的数据规模也越来越大,对应用系统提出了更高的要求,我们的系统必须支持高并发访问和海量数据处理。 分布式系统技术就是用来解决集中式架构的性能瓶颈问题,来适应快速发展的业务规模,一般来说,分布式系统是建立在网络之上的硬件或者软件系统,彼此之间通过消息等方式进行通信和协调。 分布式系统的核心是可扩展性,通过对服务、存储的扩展,来提高系统的处理能力,通过对多台服务器协同工作,来完成单台服务器无法处理的任务,尤其是高并发或者大数据量的任务。 除了对可扩展性的需求,分布式系统还有不出现单点故障、服务或者存储无状态等特点。 单点故障(Single Point Failure)是指在系统中某个组件一旦失效,这会让整个系统无法工作,而不出现单点故障,单点不影响整体,就是分布式系统的设计目标之一; 无状态,是因为无状态的服务才能满足部分机器宕机不影响全部,可以随时进行扩展的需求。 由于分布式系统的特点,在分布式环境中更容易出现问题,比如节点之间通信失败…

Read More Read More

一文带你搞懂API网关

一文带你搞懂API网关

閱讀本文約花費: 19 (分鐘) 前言 假设你正在开发一个电商网站,那么这里会涉及到很多后端的微服务,比如会员、商品、推荐服务等等。 那么这里就会遇到一个问题,APP/Browser怎么去访问这些后端的服务? 如果业务比较简单的话,可以给每个业务都分配一个独立的域名(https://service.api.company.com),但这种方式会有几个问题: 每个业务都会需要鉴权、限流、权限校验等逻辑,如果每个业务都各自为战,自己造轮子实现一遍,会很蛋疼,完全可以抽出来,放到一个统一的地方去做。如果业务量比较简单的话,这种方式前期不会有什么问题,但随着业务越来越复杂,比如淘宝、亚马逊打开一个页面可能会涉及到数百个微服务协同工作,如果每一个微服务都分配一个域名的话,一方面客户端代码会很难维护,涉及到数百个域名,另一方面是连接数的瓶颈,想象一下你打开一个APP,通过抓包发现涉及到了数百个远程调用,这在移动端下会显得非常低效。每上线一个新的服务,都需要运维参与,申请域名、配置Nginx等,当上线、下线服务器时,同样也需要运维参与,另外采用域名这种方式,对于环境的隔离也不太友好,调用者需要自己根据域名自己进行判断。另外还有一个问题,后端每个微服务可能是由不同语言编写的、采用了不同的协议,比如HTTP、Dubbo、GRPC等,但是你不可能要求客户端去适配这么多种协议,这是一项非常有挑战的工作,…

Read More Read More

Etcd Raft使用入门及原理解析

Etcd Raft使用入门及原理解析

閱讀本文約花費: 13 (分鐘) 什么是Raft Raft是一个分布式一致性算法,充分的利用了可复制状态机以及日志。其最核心的设计目标就是易于理解。在性能、错误容错等方面来看有点类似Paxos,但不同之处在于,Raft论文较为清晰的描述了其主要流程以及其中一些细节问题,而Paxos我们知道非常难以理解。 当构建一个分布式系统时,一个非常重要的设计目标就是fault tolerance。如果系统基于Raft协议实现,那么当其中一个节点挂掉,或者发生了网络分区等异常情况时,只要大多数节点仍然能够正常通讯,整个集群就能够正常对外提供服务而不会挂掉。 关于Raft更多的细节,这里建议直接阅读论文: “In Search of an Understandable Consensus Algorithm“ 介绍 Etcd的Raft库已经在生产环境得到了非常广泛的应用,有力的支撑了etcd、K8S、Docker Swarm、TiDB/TiKV等分布式系统的构建,当你能够熟练的使用一个成熟的Raft库、甚至如果能够自己实现一个,那会有种’有了锤子,干什么都是钉子’的感觉。 特性 Etcd raft基本上已经实现了Raft协议的完整特性,包括: – Leader选举 – 日志复制 – 日志压缩 – 成员变…

Read More Read More

Cloud Native Computing Foundation Announces ‘Introduction to Kubernetes’ Course Surpasses 100,000 Registrations

Cloud Native Computing Foundation Announces ‘Introduction to Kubernetes’ Course Surpasses 100,000 Registrations

閱讀本文約花費: 2 (分鐘) Hosted by The Linux Foundation and edX.org, the course teaches the basics of Kubernetes to  developers and systems administrators SAN FRANCISCO, Calif. – January 28, 2020 – The Cloud Native Computing Foundation® (CNCF®), which builds sustainable ecosystems for cloud native software, today announced that more than 100,000 people have registered for the free ‘Introduction to Kubernetes’ course, hosted by The Linux Foundation with edX.org. CNCF has made significant investments to implement training, expert certification, and provider certification programs for Kuber…

Read More Read More

Kubernetes 1.18GA,15个稳定11个beta,引入kubectl debug命令

Kubernetes 1.18GA,15个稳定11个beta,引入kubectl debug命令

閱讀本文約花費: 9 (分鐘) 我们很高兴宣布Kubernetes 1.18的交付,这是我们2020年的第一版!Kubernetes 1.18包含38个增强功能:其中15个功能已趋于稳定,beta版本中有11个,alpha版本中有12个。 Kubernetes 1.18是一个“完美”的版本。为了改善用户体验,我们在beta和 stable 功能改进方面进行了大量工作:增加新的开发和新功能。对alpha,beta和 stable 版进行几乎一样多的增强是一项伟大的成就。这说明,社区在提高Kubernetes的可靠性以及继续扩展其现有功能方面所做的巨大努力。 Kubernetes 1.18主要更新内容 Kubernetes拓扑管理器(Topology Manager ) 升级到Beta版 ! 拓扑管理器功能 是1.18版中Kubernetes的beta版本功能,它可以使CPU和设备(如SR-IOV VFs)实现NUMA,这将使你的工作负载在针对低延迟而优化的环境中运行。在引入拓扑管理器之前,CPU和设备管理器会做出彼此独立的资源分配决策,那么可能会导致在多套接字( multi-socket )系统上分配不良,从而导致关键型应用程序的性能下降。 Serverside Apply引入Beta 2版本 Server-side Apply 在1.16中被升级为Beta,在1.18中引…

Read More Read More

如何以非root用户运行Docker容器

如何以非root用户运行Docker容器

閱讀本文約花費: 5 (分鐘) 需要用root用户运行Docker? 组织中,经常以Root用户运行Docker中的容器。但是你的工作负载真的需要root权限吗?显然很少。尽管如此,默认情况下,你的容器仍将以root用户身份运行,但这可能会带来严重的安全问题。实际上,如果以root用户运行容器内部的进程,就是以root用户身份运行主机的进程。这就为那些恶意访问主机的攻击者,提供了机会。 只需在常用的任何镜像上使用以下命令,你就可以自己查看它使用的用户身份, $ kubectl run -i –tty hello-world –image=hello-world –restart=Never — sh # ps aux PID USER TIME COMMAND 1 root 0:10 sh 显然,作为最佳实践,我们应该避免以超级用户身份运行容器。因此,让我们看看如何以非root用户身份运行容器。 将非root用户添加到Dockerfile 你可以在Dockerfile中使用RUN命令创建用户,这个用户仅具有容器内工作负载所需的权限。 RUN groupadd –gid 5000 newuser \ && useradd –home-dir /home/newuser –create-home –uid 5000 \ –gid 5000 –shel…

Read More Read More

fastjson存在反序列化和SSRF漏洞

fastjson存在反序列化和SSRF漏洞

閱讀本文約花費: 1 (分鐘) 【漏洞预警】 3月24日,fastjson官方git披露fastjson存在最新反序列化远程代码执行漏洞共计Gadgets,利用该最新的Gadgets,攻击者可以造成远程命令执行,或者造成SSRF漏洞,风险较大。目前官方已发布最新版本1.2.67,请使用到fastjson的用户尽快升级至安全版本。 【漏洞描述】 fastjson是阿里巴巴出品的一个json序列化工具,fastjson采用黑白名单的方法来防御反序列化漏洞,导致当黑客不断发掘新的可攻击的反序列化Gadgets类时,则可能可以绕过黑白名单防御机制,造成远程命令执行或者SSRF漏洞。提醒fastjson用户尽快采取安全措施阻止漏洞攻击。 【影响版本】 fastjson < 1.2.67 fastjson sec 版本 < sec09

子网与超网-Kubernetes基础知识

子网与超网-Kubernetes基础知识

閱讀本文約花費: 7 (分鐘) 子网 1、IP地址是以网络号和主机号来表示网络上的主机的,只有在一个网络号下的计算机之间才能“直接”互通,不同网络号的计算机要通过网关才能互通。但这样的划分在某些情况下显得并不十分灵活。为此IP网络还允许划分成更小的网络,称为子网。 2、作用::IP数据包从网际上的一个网络到达另一个网络时,选择路径可以基于网络而不是主机。在大型的网际中,这一点优势特别明显,因为路由表中只存储网络信息而不是主机信息,这样可以大大简化路由表。 3、因为有了子网,就产生了子网掩码。子网掩码的作用就是用来判断任意两个IP地址是否属于同一子网络,这时只有在同一子网的计算机才能”直接”互通。 4、子网掩码与IP地址都是由4个数段组成,每个数段的取值范围是0-255(共256个值,等于2的8次方),如我们在搭建局域网时通常用到的IP地址192.168.1.1,子网掩码255.255.255.0,当然十进制是为了方便人的理解,转换成机器能识别的二进制后,每个数段由8个0或1组成,一个完整的IP地址或子网掩码就转换成32个0或1组成的序列。子网掩码与IP地址是组合使用的,IP地址我们都知道是计算机在网络内的唯一标识,而子网掩码顾名思义是用于划分子网的,下面通过几个例子进行讲解。   (1)255.255.255.0   子网掩码由连续的1和0组成,连续的1表示…

Read More Read More

Spring Boot 2.x 与 1.x 的区别,以及如何做版本迁移

Spring Boot 2.x 与 1.x 的区别,以及如何做版本迁移

閱讀本文約花費: 5 (分鐘) 这一篇文章主要讲解 Spring Boot 2.x 与 1.5.x 的区别,2.x 主要更新了什么东西,以便对 Spring Boot 2.x 有一个详细的了解。 本文讲的 1.x 指的是 1.5.10, 2.x 指的是 2.0.0。 配置变更 在 2.x 中废除了一些 1.x 中的配置,并增加了许多新配置,详细请查看以下链接中的变更表格。 https://github.com/spring-projects/spring-boot/wiki/Spring-Boot-2.0-Configuration-Changelog 依赖 JDK 版本升级 2.x 至少需要 JDK 8 的支持,2.x 里面的许多方法应用了 JDK 8 的许多高级新特性,所以你要升级到 2.0 版本,先确认你的应用必须兼容 JDK 8。 另外,2.x 开始了对 JDK 9 的支持。 第三方类库升级 2.x 对第三方类库升级了所有能升级的稳定版本,一些值得关注的类库升级我给列出来了。 1) Spring Framework 5+ 2) Tomcat 8.5+ 3) Flyway 5+ 4) Hibernate 5.2+ 5) Thymeleaf 3+ 响应式 Spring 编程支持 2.x 通过启动器和自动配置全面支持 Spring 的响应式编程,响应式编程是完全异步和非阻塞的,它…

Read More Read More