Browsed by
标签:aws

基于AWS的云架构设计最佳实践——传统环境和云计算环境之间的差异

基于AWS的云架构设计最佳实践——传统环境和云计算环境之间的差异

閱讀本文約花費: 8 (分鐘)译者序AWS用户广泛,产品线复杂,AWS发布的白皮书《Architecting for the Cloud-AWS Best Practices》介绍了常见场景下云架构的最佳实践,不仅对于使用AWS的用户,对于广大使用云的用户都有参考意义,新钛云服工程师特意翻译了本白皮书,供广大使用云的用户参考。 译者整理的脑图 摘要本白皮书适用于在Amazon Web Services(AWS)上的构建解决方案的架构师和开发人员。本白皮书提供有关技术设计模型的架构指导和建议,以及如何应用于云计算环境中。本白皮书提供了在AWS上设计解决方案时的关键概念和差异。本白皮书还讨论了如何利用特定于云计算动态特性的属性,如弹性和基础设施自动化。这些模型可以为对选择、操作状态和实现状态进行更详细的审查提供上下文,就像《AWS Well-Architected Framework》中详细描述的那样。 介绍将应用程序迁移到AWS,即使没有重大更改(称为直接迁移的方法),也可为组织提供安全且经济高效的基础架构优势。但是,为了充分利用云计算可能带来的弹性和灵活性,工程师必须改进其架构以利用AWS功能。对于新应用程序,基于云的IT体系架构模型可以帮助提高效率和可伸缩性。这些新架构可以支撑从互联网规模数据的实时分析到具有数千个连接的物联网(IoT),或移动设备的不可预测流量的应用程序的任何内…

Read More Read More

如何对 ElasticSearch 集群进行压力测试

如何对 ElasticSearch 集群进行压力测试

閱讀本文約花費: 14 (分鐘)当 ElasticSearch 的业务量足够大,比如每天都会产生数百 GB 数据的时候,你就会自然而然的需要一个性能更强的 ElasticSearch 集群。特别是当你使用的场景是一些典型的大量数据进入的场景,比如网站日志、用户行为记录、大型电商网站的站内搜索时,一个强劲的 ElasticSearch 是必不可少的组件。在这样的场景下,如何找到一组合适的 ElasticSearch 集群?如何评估 ElasticSearch 集群的性能,就成为了一个十分重要的因素。 用什么 ElasticSearch 进行压力测试? 对于 ElasticSearch 性能测试和压力测试方面,其实有很多不同的方案,比如: Rally:Rally 是 Elastic 官方针对于 ElasticSearch 的宏观测试工具。 ESPerf:一个基于 Golang 编写的 ElasticSerch 性能测试工具 Elasticsearch Stress Test:由著名的 ElasticSearch 服务提供商 Logzio 开发的性能测试工具 除了这些定制化的工具意外以外,ElasticSearch 也可以借由其 Restful API 来使用Load Runner、JMeter等老牌工具进行测试,这些工具零零散散,各有各的用法和用途,不过,对于广大开发者而言,还是官方出…

Read More Read More

如何构建以应用为中心的“Kubernetes”?

如何构建以应用为中心的“Kubernetes”?

閱讀本文約花費: 23 (分鐘)在上篇文章《上 Kubernetes 到底有什么业务价值?》,主要和大家介绍了上 Kubernetes 有什么业务价值,以及什么是“以应用为中心”的 Kubernetes。本文将跟大家具体分享如何构建“以应用为中心”的 Kubernetes。 如何构建“以应用为中心”的 Kubernetes? 构建这么一个以用户为中心的 Kubernetes,需要做几个层级的事情。 1. 应用层驱动 首先来看最核心的部分,上图中蓝色部分,也就是 Kubernetes。可以在 Kubernetes 之上定义一组 CRD 和 Controller。可以在 CRD 来做用户这一侧的 API,比如说 pipeline 就是一个 API,应用也是一个 API。像运维侧的扩容策略这些都是可以通过 CRD 的方式安装起来。 2. 应用层抽象 所以我们的需要解决第一个问题是应用抽象。如果在 Kubernetes 去做应用层抽象,就等同于定义 CRD 和 Controller,所以 Controller 可以叫做应用层的抽象。本身可以是社区里的,比如 Tekton,istio 这些,可以作为你的应用驱动层。这是第一个问题,解决的是抽象的问题。不是特别难。 3. 插件能力管理 很多功能不是 K8s 提供的,内置的 Controller 还是有限的,大部分能力来自于社区或者是自己开发的 …

Read More Read More

云上 ARM 实例应用优化之我见

云上 ARM 实例应用优化之我见

閱讀本文約花費: 22 (分鐘) 亚马逊AWS官方博客 发布于:2020 年 8 月 10 日 10:00 ARM 处理器的崛起 过去两个月的科技媒体上关于 ARM 芯片的新闻可谓是高潮迭起,不断的引起人们的关注。 首先是在 5 月 11 日,AWS 宣布了基于自研的 Graviton 2 处理器(使用了 ARM Neoverse N1 核心)的第六代 EC2 实例 – M6g 正式发布。这似乎揭开了云计算市场上 ARM 处理器大规模应用的的序幕。 紧接着,在今年 6 月 23 日的 WWDC 大会上,Apple 公司宣布了一个影响深远的决定: 计划从 2020 年年底开始,Mac 计算机将会从 Intel 芯片过渡到使用基于 ARM 的自研芯片。也许我们要问,ARM 处理器将将会在桌面设备上复制移动设备的成功吗? 第三则新闻是关于高性能计算。6 月 22 日发表的最新的一期 TOP500 榜单上,日本的 Fugaku 系统以 415.5 千万亿次浮点运算的高性能 LINPAC 成绩成为 TOP500 的第一名。而令人惊讶的是这是第一个使用 ARM 处理器的高性能处理系统。 林林总总,即使我们是半导体行业的门外汉也不难得出一个结论 – ARM 处理器不仅仅统治了手机、嵌入式应用这些传统的优势领域,或将在桌面系统、高性能计算尤其是云计算领域扮演越来越重要的角色。 EC2 上的 ARM…

Read More Read More

使用Kubernetes实现高级调度技术

使用Kubernetes实现高级调度技术

閱讀本文約花費: 14 (分鐘)使用Kubernetes这样的高级容器编排工具的优势之一就是,它的调度程序非常灵活。这为用户提供了广泛的选择,可以用来指定将Pod分配给满足条件的特定工作站节点的环境,而不仅仅基于节点的可用资源。为了解释Kubernetes如何决定将pod放置在正确的主机上,我们可以看一下Kubernetes master及一些组件的简化图: 主API(kube-apiserver)是一种提供对集群需求和当前状态进行读/写的工具。像调度程序这样的组件可以使用主API检索当前状态信息,应用一些逻辑和计算,并使用有关所需状态的新信息更新API(例如,指定要将哪个节点安排到新pod,或者指定哪个pod应该移动到另一个节点)。另外,集群用户和管理员可以更新集群状态或通过Kubernetes仪表板查看它,该仪表板对外提供API。CI / CD管道还可以使用API创建新资源或修改现有资源。 其他调用api的主要角色是名为“kubelets”的代理节点,它在工作节点上管理容器运行状态(通常为Docker)。当Kubelet判断出要报告的主机预期状态与其实际状态之间存在差异时,它将启动或终止需要的容器以达到主API描述的目标状态。Kubelets经常查询API,或者观察它们的变化,这就是为什么Kubernetes对更新和更改的响应几乎是即时的。(几秒钟)。 正如我们所看到的,Kub…

Read More Read More

部署策略对比:蓝绿部署、金丝雀发布及其他

部署策略对比:蓝绿部署、金丝雀发布及其他

閱讀本文約花費: 13 (分鐘)目前,软件开发最大的变化是部署频率。产品团队更早(更频繁)的将产品发布到生产环境。数月或者数年的发布周期变得越来越短 – 对那些构建纯软件产品的人来说更是如此。 现在,使用面向服务的架构和微服务方式,开发者可以设计模块化的代码库。这允许他们同时在代码库中不同的地方编写和部署代变更。 缩短部署周期的业务优势狠明显: 缩短上市时间 客户可以在更短的时间内获得产品价值 客户的反馈也会更快的到达产品团队,这意味着团队可以更快的迭代特性和修复问题 开发人员的整体士气会上升 但是,这种转变也给运维或者 DevOps 团队带来了新挑战。更频繁的部署,意味着已经部署的代码会对站点可用性和客户体验带来负面影响。这就是制定代码部署策略如此重要的原因,因为它可以最大限度的降低产品和客户的风险。 在本文中,我们将讨论不同的部署策略、最佳实践和工具,让你的团队可以更快更可靠的工作。 现代应用的挑战 现代应用通常是分布式的,基于云的。它们可以弹性扩展来满足需求,基于高可用架构更好地容错。这些应用可以使用全托管服务,例如 AWS Lambda 和 Elastic Container Service(ECS) 等平台处理一些运维责任。 这些应用经常频繁部署。例如,移动 app 和 web 应用可能一个月内经历多次更改。有些甚至一天…

Read More Read More

Kubernetes 下日志采集、存储与处理技术实践

Kubernetes 下日志采集、存储与处理技术实践

閱讀本文約花費: 25 (分鐘) 本文介绍了“Logtail + 日志服务 + 生态”架构,介绍了:Logtail客户端在Kubernetes日志采集场景下的优势. 日志服务作为基础设施一站式解决实时读写、HTAP两大日志强需求;日志服务数据的开放性以及与云产品、开源社区相结合,在实时计算、可视化、采集上为用户提供的丰富选择。 Kubernetes日志处理的趋势与挑战 Kubernetes的serveless化 Kubernetes容器技术促进了技术栈的去耦合,通过引入栈的分层使得开发者可以更加关注自身的应用程序和业务场景。从Kubernetes本身来看,这个技术解耦也在更进一步发展,容器化的一个发展的趋势是:这些容器都将会在无服务器的基础设施上运行。 谈到基础设施,首先可以联想到云,目前在AWS、阿里云、Azure的云上都提供了无服务器化的Kubernetes服务。在serverless Kubernetes上,我们将不再关心集群与机器,只需要声明容器的镜像、CPU、内存、对外服务方式就可以启动应用。 如上图,左右两边分别是经典Kubernetes、serverless Kubernetes的形态。在从左向右发展的过程中,日志采集也变得复杂: 1.在一个Kubernetes node上,可能会运行更大规模量级的pod,每个pod上都可能有日志或监控指标采集需求,意味着单node上…

Read More Read More

如何阅读OpenStack源码

如何阅读OpenStack源码

閱讀本文約花費: 28 (分鐘)原文:https://github.com/int32bit/openstack-workflow http://www.talkwithtrend.com/Article/240391 1 关于该项目 本项目使用在线绘图工具web sequencediagrams完成,目标是图形化OpenStack的所有操作流程,通过操作序列图能快速学习Openstack的工作原理,理清各个组件的关系,运维人员也能根据操作序列图进行更精确的故障定位和排查. 注意,该操作序列图基于L版OpenStack源码,未来版本的操作可能会有变化,请以最新版的源码为准,该项目提供的序列图仅供参考。 2 OpenStack基础 2.1 OpenStack组件介绍 OpenStack是一个IaaS层的云计算平台开源实现,其对标产品为AWS。最开始OpenStack只有两个组件,分别为提供计算服务的Nova以及提供对象存储服务的Swift,其中Nova不仅提供计算服务,还包含了网络服务、块存储服务、镜像服务以及裸机管理服务。之后随着项目的不断发展,从Nova中根据功能拆分为多个独立的项目,如nova-volume拆分为Cinder项目提供块存储服务,nova-image拆分为Glance项目,提供镜像存储服务,nova-network则是neutron的前身,裸机管理也从Nova中分…

Read More Read More

如何超过大多数人

如何超过大多数人

閱讀本文約花費: 23 (分鐘)当你看到这篇文章的标题,你一定对这篇文章产生了巨大的兴趣,因为你的潜意识在告诉你,这是一本人生的“武林秘籍”,而且还是左耳朵写的,一定有干货满满,只要读完,一定可以练就神功并找到超过大多数人的快车道和捷径……然而…… 当你看到我这样开篇时,你一定会觉得我马上就要有个转折,告诉你这是不可能的,一切都需要付出和努力……然而,你错了,这篇文章还真就是一篇“秘籍”,只要你把这些“秘籍”用起来,你就一定可以超过大多数人。而且,这篇文章只有我这个“人生导师”可以写得好。毕竟,我的生命过到了十六进制2B的年纪,踏入这个社会已超过20年,舍我其谁呢?! P.S. 这篇文章借鉴于《如何写出无法维护的代码》一文的风格……嘿嘿 相关技巧和最佳实践 要超过别人其实还是比较简单的,尤其在今天的中国,更是简单。因为,你只看看中国的互联网,你就会发现,他们基本上全部都是在消费大众,让大众变得更为地愚蠢和傻瓜。所以,在今天的中国,你基本上不用做什么,只需要不使用中国互联网,你就很自然地超过大多数人了。当然,如果你还想跟他们彻底拉开,甩他们几个身位,把别人打到底层,下面的这些“技巧”你要多多了解一下。 在信息获取上,你要不断地向大众鼓吹下面的这些事: 让大家都用百度搜索引擎查找信息,订阅微信公众号或是到知乎上学习知识……要做到这一步,你就需要把“百度一下”挂在嘴边,然后要经常在群或朋…

Read More Read More

《microservice & serverless》的一点感想

《microservice & serverless》的一点感想

閱讀本文約花費: 6 (分鐘)超哥是来自Amazon的顶级的架构师,经历了Amazon整个向微服务架构迁移的过程,以及向serverless的演化过程,有着极其丰富的经验,年过40,一直站在技术的最前沿,始终保持对技术的执着追求和热情,是名副其实的技术大牛,能与之一起工作,荣幸之至!今天超哥给我们分享的主题《microservice & serverless》,是超哥实际工作经验的一些分享,也为公司架构的演化提供了新的思路和指导。 microservice(微服务)这个可能是这些年最火的一种架构设计了,频繁地出现在各种技术大会上,各大互联网巨头纷纷向这种架构演化,很多小的互联网公司也往这些概念上去靠,大有一种不做微服务就要落伍的趋势。事实上,很多对于微服务的理解比较粗浅,盲目的微服务化甚至会带来更多的负面影响。 目前Amazon内部运行着超过2w过微服务,但是这些微服务并不是凭空产生的,在这之前,运行的服务都是超大的单体服务,但是随着业务的发展,这种服务在整个研发的pipeline(设计→研发→编译→测试→发布→部署→运维)中都出现了一些问题。设计阶段,老的单体服务会给我们带来一些技术限制,比如有些技术只有python语言的实现,但是我们的服务使用java开发,这样我们不得不拿出一个更复杂的设计去解决类似的问题;研发阶段,随着开发人数越来越多,代码冲突的问题越来越多,我们不…

Read More Read More

浅谈VPC二三,秒懂秒透

浅谈VPC二三,秒懂秒透

閱讀本文約花費: 13 (分鐘)VPC全称是Virtual Private Cloud,翻译成中文是虚拟私有云。但是在有些场合也被翻译成私有网络或者专有网络等。这里其实就有些让人迷惑,VPC究竟是指云还是网络?答案是,VPC即是一种云,也是一种网络模式,不过应该从服务和技术的角度分别来看。 一、虚拟私有云 首先从服务的角度来看,VPC指的是一种云(Cloud),这与它的字面意思相符。对于基础架构服务(IaaS),云就是指资源池。你或许听过公有云(Public Cloud)、私有云(Private Cloud)、混合云(Hybrid Cloud)。不过,VPC不属于这三种云中任一种。这是一种运行在公有云上,将一部分公有云资源为某个用户隔离出来,给这个用户私有使用的资源的集合。VPC是这么一种云,它由公有云管理,运行在公共资源上,但是保证每个用户之间的资源是隔离,用户在使用的时候不受其他用户的影响,感觉像是在使用自己的私有云一样。 从这种意义上看,VPC不是网络,我们可以对比VPC和它一个字面上相近的概念:VPN(Virtual Private Network)。VPN在公共的网络资源上虚拟隔离出一个个用户网络,例如IPsec VPN可以是在互联网上构建连接用户私有网络的隧道,MPLS VPN更是直接在运营商的PE设备上划分隔离的VRF给不同的用户。从提供服务的角度来,说如果VPC指的…

Read More Read More

科普一下公有云的网络

科普一下公有云的网络

閱讀本文約花費: 7 (分鐘)​​@admin一乐 同学发了一篇微博(http://weibo.com/1819367693/EwZFypkK6)说了一下因为一个安全问题的疏忽中招的事。​大意是redis有一个可以提权访问服务器安全漏洞,但是因为一乐家的redis服务器没有暴露给公网,所以一开始也就没有特别在意,不料还是被攻破了,原因虽然是这个服务器没有暴露在公网,但是因为阿里云的内网各个租户是可以互相访问的,所以,也相当于暴露给了别人…… 我简单地回复了一下这个事,就说让我想到了以前和阿里云解决多租户内网必需隔离的事(是什么事我也没细说,只是简单的感叹一下)。结果引发了些敏感的人的质疑和口水。那些口水对我来说无意义,不过,这个期间看到似乎大家对公有云的网络并不是很明白,所以,写下这篇文,希望大家都注意起来,以免出现公有云上的安全问题。 安全组 阿里云的内网是经典网络,也就是说,不同的租户是互通的,如果你只想让你自己的机器访问的话,那么你要给你每一台机器都配上互相可以访问的安全组。安全组是AWS的Security Group的中文翻译,说白了就是防火墙,你可以简单理解为你Windows机器上的防火墙——其中标明了网络出站和入站的规则。 这种经典网络就好像一个公司内的办公网络一下,所有员工的电脑都可以互相ping通和访问的(这就是为会什么有些病毒可以在公司内网里泛滥)。如果你不想让别…

Read More Read More

Scroll Up