Cloud Native

Awesome Cloud Native

这是一份记录关于Cloud Native的软件、工具、架构以及参考资料的列表,是我在GitHub上开的一个项目,地址是https://github.com/rootsongjc/awesome-cloud-native。 初步划分成以下这些领域: Awesome Cloud Native API Containers CI-CD Database Logging Message broker Monitoring Networking Orchestration and scheduler PaaS Proxy and load balancer Service mesh Service registry and discovery Storage Tracing Tools Tutorial 今后会不断更新和完善该列表,不仅是为了本人平时的研究记录,也作为Cloud Native届的人士的参考。

企业迁移到云生应用架构时所需做出的变革

本文译自Migrating to Cloud Native Application Architectures第二部分,归档到https://github.com/rootsongjc/migrating-to-cloud-native-application-architectures 。 在变革中前行 从客户给我们下达订单开始,一直到我们收到现金为止,我们一直都关注时间线。而且我们正在通过删除非附加值的废物来减少这个时间表。 —— Taichi Ohno Taichi Ohno被公认为精益制造之父。 虽然精益制造的实践无法完全适用于软件开发领域,但它们的原则是一致的。 这些原则可以指导我们很好地寻求典型的企业IT组织采用云原生应用程序架构所需的变革,并且接受作为这一转变所带来的部分的文化和组织转型。 文化变革 企业IT采用云原生架构所需的变革根本不是技术性的,而是企业文化和组织的变革,围绕消除造成浪费的结构、流程和活动。 在本节中,我们将研究必要的文化转变。 从信息孤岛到DevOps 企业IT通常被组织成以下许多孤岛: 软件开发 质量保证 数据库管理 系统管理 IT运营 发布管理 项目管理 创建这些孤岛是为了让那些了解特定领域的人员来管理和指导那些执行该专业领域工作的人员。 这些孤岛通常具有不同的管理层次,工具集、沟通风格、词汇表和激励结构。这些差异启发了企业IT目标的不同范式,以及如何实现这一目标。 开发和运维分别对软件变更持有的观念就是个经常被提起的关于这些矛盾模式的例子。 开发的任务通常被视为通过开发软件功能为组织提供额外的价值。 这些功能本身就是向IT生态系统引入变更。 所以开发的使命可以被描述为“交付变化”,而且经常根据有多少次变更来进行激励。 相反,IT运营的使命可以被描述为“防止变更”。 IT运营通常负责维护IT系统所需的可用性、弹性、性能和耐用性。因此,他们经常以维持关键绩效指标(KPI)来进行激励,例如平均故障间隔时间(MTBF)和平均恢复时间(MTTR)。与这些措施相关的主要风险因素之一是在系统中引入任何类型的变更。 那么,不是设法将开发期望的变更安全地引入IT生态系统,而是通过将流程放在一起,使变更变得痛苦,从而降低了变化率。 这些不同的范式显然导致了许多额外的工作。项目工作中的协作、沟通和简单的交接变得乏味和痛苦,最糟糕的是导致绝对混乱(甚至是危险的)。 企业IT通常通过创建基于单据的系统和委员会会议驱动的复杂流程来尝试“修复”这种情况。企业IT价值流在所有非增值浪费下步履瞒珊。 像这样的环境与云原生的速度思想背道而驰。 专业的信息孤岛和流程往往是由创造安全环境的愿望所驱动。然而,他们通常提供很少的附加安全性,在某些情况下,会使事情变得更糟! 在其核心上,DevOps代表着这样一种思想,即将这些信息孤岛构建成共享的工具集、词汇表和沟通结构,以服务于专注于单一目标的文化:快速、安全得交付价值。 然后创建激励结构,强制和奖励领导组织朝着这一目标迈进的行为。 官僚主义和流程被信任和责任所取代。 在这个新的世界中,开发和IT运营部门向共同的直接领导者汇报,并进行合作,寻找能够持续提供价值并获得期望的可用性、弹性、性能和耐久性水平的实践。今天,这些对背景敏感的做法越来越多地包括采用云原生应用架构,提供完成组织的新的共同目标所需的技术支持。 从间断均衡到持续交付 企业经常采用敏捷流程,如Scrum,但是只能作为开发团队内部的本地优化。 在这个行业中,我们实际上已经成功地将个别开发团队转变为更灵活的工作方式。 我们可以这样开始项目,撰写用户故事,并执行敏捷开发的所有例程,如迭代计划会议,日常站会,回顾和客户展示demo。 我们中的冒险者甚至可能会冒险进行工程实践,如结对编程和测试驱动开发。持续集成,这在以前是一个相当激进的概念,现在已经成为企业软件词典的标准组成部分。事实上,我已经是几个企业软件团队中的一部分,并建立了高度优化的“故事到演示”周期,每个开发迭代的结果在客户演示期间被热烈接受。 但是,这些团队会遇到可怕的问题:我们什么时候可以在生产环境中看到这些功能? 这个问题是我们很难回答,因为它迫使我们考虑我们无法控制的力量: 我们需要多长时间才能浏览独立的质量保证流程? 我们什么时候可以加入生产发布的行列中? 我们可以让IT运营及时为我们提供生产环境吗? 在这一点上,我们意识到自己已经陷入了戴维·韦斯特哈斯(Dave Westhas)所说的scrum瀑布中了。 我们的团队已经开始接受敏捷原则,但我们的组织却没有。所以,不是每次迭代产生一次生产部署(这是敏捷宣言的原始出发点),代码实际上是批量参与一个更传统的下游发布周期。 这种操作风格产生直接的后果。我们不是每次迭代都将价值交付给客户,并将有价值的反馈回到开发团队,我们继续保持“间断均衡”的交付方式。 间断均衡实际上丧失了敏捷交付的两个主要优点: 客户可能需要几周的时间才能看到软件带来的新价值。 他们认为,这种新的敏捷工作方式只是“像往常一样”,不会增强对开发团队的信任。 因为他们没有看到可靠的交付节奏,他们回到了以前的套路将尽可能多的要求尽可能多地堆放到发布版上。 为什么? 因为他们对软件能够很快发布没有信心,他们希望尽可能多的价值被包括在最终交付时。 开发团队可能会好几周都没有得到真正的反馈。虽然演示很棒,但任何经验丰富的开发人员都知道,只有真实用户参与到软件之中才能获得最佳反馈。这些反馈能够帮助软件修正,使团队去做正确的事情。反馈推迟后,错误的可能性只能增加,并带来昂贵的返工。 获得云原生应用程序体系结构的好处需要我们转变为持续交付。 我们拥抱端到端拥抱价值的原则,而不是Water Scrum Fall组织驱动的间断平衡。设想这样一个生命周期的模型是由Mary和Tom Poppendieck在《实施精益软件开发(Addison-Wesley)》一书中描述的“概念到现金”的想法中提出来的。 这种方法考虑了所有必要的活动,将业务想法从概念传递到创造利润的角度,并构建可以使人们和过程达到最佳目标的价值流。

什么是云原生应用架构

本文译自Migrating to Cloud Native Application Architectures第一部分,归档到https://github.com/rootsongjc/migrating-to-cloud-native-application-architectures 。 第1章 云原生的崛起 软件正在吞噬这个世界。—Mark Andreessen 近些年来,在一些长期由领导者支配的行业中,这些领导者的领先地位已经岌岌可危,这都是由以这些行业为核心业务的软件公司造成的。像Square、Uber、Netflix、Airbnb和特斯拉这样的公司能够持续快速增长,并并拥有傲人的市场估值,成为它们所在行业的新领导者。这些创新公司有什么共同点? 快速创新 持续可用的服务 弹性可扩展的Web 以移动为核心的用户体验 将软件迁移到云上是一种自演化,使用了云原生应用架构是这些公司能够如此具有破坏性的核心原因。通过云,任何能够按需、自助弹性提供和释放计算、网络和存储资源的计算环境。云的定义包括公有云(例如 Amazon Web Services、Google Cloud和Microsoft Azure)和私有云(例如 VMware vSphere和 OpenStack)。 本章中我们将探讨云原生应用架构的创新性,然后论证云原生应用架构的主要特性。 为何使用云原生应用架构 首先我们来阐述下将应用迁移到云原生架构的动机。 速度 天下武功,唯快不破,市场竞争亦是如此。想象一下,能够快速创新、实验并交付软件的企业,与使用传统软件交付模式的企业,谁将在市场竞争中胜出呢? 在传统企业中,为应用提供环境和部署新版本花费的时间通常以天、周或月来计算。这种速度严重限制了每个发行版可以承担的风险,因为修复这些错误往往跟发行一个新版本有差不多的耗时。 互联网公司经常提到它们每天极版次发布的实践。为什么频繁发布如此重要?如果你可以每天实现几百次发布,你们就可以几乎立即从错误的版本恢复过来。如果你可以立即从错误中恢复过来,你就能够承受更多的风险。如果你可以承受更多的风险,你就可以做更疯狂的试验——这些试验结果可能会成为你接下来的竞争优势。 基于云基础设置的弹性和自服务的特性天生就适应于这种工作方式。通过调用云服务API来提供新的应用程序环境比基于表单的手动过程要快几个数量级。然后通过另一个API调用将代码部署到新的环境中。将自服务和hook添加到团队的CI/CD服务器环境中进一步加快了速度。现在,我们可以回答精益大师Mary Poppendick提出的问题了——“如果只是改变了应用的一行代码,您的组织需要多长时间才能把应用部署到线上?“答案是几分钟或几秒钟。 你可以大胆想象 一下,如果你也可以达到这样的速度,你的团队、你的业务可以做哪些事情呢? 安全 光是速度快还是不够的。如果你开车是一开始就把油门踩到底,你将因此发生事故而付出惨痛的代价(有时甚至是致命的)!不同的交通方式如飞机和特快列车都会兼顾速度和安全性。云原生应用架构在快速变动的需求、稳定性、可用性和耐久性之间寻求平衡。这是可能的而且非常有必要同时实现的。 我们前面已经提到过,云原生应用架构可以让我们迅速地从错误中恢复。我们没有谈论如何预防错误,而在企业里往往在这一点上花费了大量的时间。在追寻速度的路上,大而全的前端升级,详尽的文档,架构复核委员会和漫长的回归测试周期在一次次成为我们的绊脚石。当然,之所以这样做都是出于好意。不幸的是,所有这些做法都不能提供一致可衡量的生产缺陷改善度量。 那么我们如何才能做到即安全又快速呢? 可视化 我们的架构必须为我们提供必要的工具,以便可以在发生故障时看到它。 我们需要观测一切的能力,建立一个“哪些是正常”的概况,检测与标准情况的偏差(包括绝对值和变化率),并确定哪些组件导致了这些偏差。功能丰富的指标、监控、警报、数据可视化框架和工具是所有云原生应用程序体系结构的核心。 故障隔离 为了限制与故障带来的风险,我们需要限制可能受到故障影响的组件或功能的范围。如果每次亚马逊的推荐引擎挂掉后人们就不能再在亚马逊上买产品,那将是灾难性的。单体架构通常就是这种类型的故障模式。云原生应用程序架构通常使用微服务。通过将系统拆解为微服务,我们可以将任何一个微服务的故障范围限制在这个微服务上,但还需要结合容错才能实现这一点。 容错 仅仅将系统拆解为可以独立部署的微服务还是不够的;还需要防止出现错误的组件将错误传递它所的依赖组件上造成级联故障。Mike Nygard 在他的《Release It! - Pragmatic Programmers》一书中描述了一些容错模型,最受欢迎的是断路器。软件断路器的工作原理就类似于电子断路器(保险丝):断开它所保护的组件与故障系统之间的回路以防止级联故障。它还可以提供一个优雅的回退行为,比如回路断开的时候提供一组默认的产品推荐。我们将在“容错”一节详细讨论该模型。 自动恢复 凭借可视化、故障隔离和容错能力,我们拥有确定故障所需的工具,从故障中恢复,并在进行错误检测和故障恢复的过程中为客户提供合理的服务水平。一些故障很容易识别:它们在每次发生时呈现出相同的易于检测的模式。以服务健康检查为例,结果只有两个:健康或不健康,up或down。很多时候,每次遇到这样的故障时,我们都会采取相同的行动。在健康检查失败的情况下,我们通常只需重新启动或重新部署相关服务。云原生应用程序架构不要当应用在这些情况下无需手动干预。相反,他们会自动检测和恢复。换句话说,他们给电脑装上了寻呼机而不是人。 弹性扩展 随着需求的增加,我们必须扩大服务能力。过去我们通过垂直扩展来处理更多的需求:购买了更强悍的服务器。我们最终实现了自己的目标,但是步伐太慢,并且产生了更多的花费。这导致了基于高峰使用预测的容量规划。我们会问”这项服务需要多大的计算能力?”然后购买足够的硬件来满足这个要求。很多时候我们依然会判断错误,会在如黑色星期五这类事件中打破我们的可用容量规划。但是,更多的时候,我们将会遇到数以百计的服务器,它们的CPU都是空闲的,这会让资源使用率指标很难看。 创新型的公司通过以下两个开创性的举措来解决这个问题: 它们不再继续购买更大型的服务器,取而代之的是用大量的更便宜机器来水平扩展应用实例。这些机器更容易获得,并且能够快速部署。 通过将大型服务器虚拟化成几个较小的服务器,并向其部署多个隔离的工作负载来改善现有大型服务器的资源利用率。 随着像亚马逊AWS这样的公有云基础设施的出现,这两个举措融合了起来。虚拟化工作被委托给云提供商,消费者只需要关注在大量的云服务器实例很想扩展它们的应用程序实例。最近,作为应用程序部署的单元,发生了另一个转变,从虚拟机转移到了容器。 由于公司不再需要大量启动资金来部署软件,所以向云的转变打开了更多创新之门。正在进行的维护还需要较少的资本投入,并且通过API进行配置不仅可以提高初始部署的速度,还可以最大限度地提高我们应对需求变化的速度。 不幸的是,所有这些好处都带有成本。相较于垂直扩展的应用,支持水平扩展的应用程序的架构必须不同。云的弹性要求应用程序的状态短暂性。我们不仅可以快速创建新的应用实例;我们也必须能够快速、安全地处置它们。这种需求是状态管理的问题:一次性与持久性相互作用如何? 在大多数垂直架构中采用的诸如聚类会话和共享文件系统的传统方法并不能很好地支持水平扩展。 云原生应用程序架构的另一个标志是将状态外部化到内存数据网格,缓存和持久对象存储,同时保持应用程序实例本身基本上是无状态的。无状态应用程序可以快速创建和销毁,以及附加到外部状态管理器和脱离外部状态管理器,增强我们响应需求变化的能力。当然这也需要外部状态管理器自己来扩展。大多数云基础设施提供商已经认识到这一必要性,并提供了这类服务的健康菜单。

云原生微服务治理框架Linkerd简介

(题图:青岛 May 26,2017) 前言 Linkerd是一个用于云原生应用的开源、可扩展的service mesh(一般翻译成服务网格,还有一种说法叫”服务啮合层“,见Istio:用于微服务的服务啮合层)。同时,Linkerd也是CNCF(云原生计算基金会)中的组件之一。 P.S 本文已归档到kubernetes-handbook中的【领域应用—微服务架构】章节中。 Linkerd是什么 Linkerd的出现是为了解决像twitter、google这类超大规模生产系统的复杂性问题。Linkerd不是通过控制服务之间的通信机制来解决这个问题,而是通过在服务实例之上添加一个抽象层来解决的。 Linkerd负责跨服务通信中最困难、易出错的部分,包括延迟感知、负载均衡、连接池、TLS、仪表盘、请求路由等——这些都会影响应用程序伸缩性、性能和弹性。 如何运行 Linkerd作为独立代理运行,无需特定的语言和库支持。应用程序通常会在已知位置运行linkerd实例,然后通过这些实例代理服务调用——即不是直接连接到目标服务,服务连接到它们对应的linkerd实例,并将它们视为目标服务。 在该层上,linkerd应用路由规则,与现有服务发现机制通信,对目标实例做负载均衡——与此同时调整通信并报告指标。 通过延迟调用linkerd的机制,应用程序代码与以下内容解耦: 生产拓扑 服务发现机制 负载均衡和连接管理逻辑 应用程序也将从一致的全局流量控制系统中受益。这对于多语言应用程序尤其重要,因为通过库来实现这种一致性是非常困难的。 Linkerd实例可以作为sidecar(既为每个应用实体或每个主机部署一个实例)来运行。 由于linkerd实例是无状态和独立的,因此它们可以轻松适应现有的部署拓扑。它们可以与各种配置的应用程序代码一起部署,并且基本不需要去协调它们。 参考 Buoyant发布服务网格Linkerd的1.0版本 Linkerd documentation Istio:用于微服务的服务啮合层

Cloud Native Go - 基于Go和React的web云服务构建指南

(题图:北京植物园桃花 Mar 26,2016) Kevin Hoffman和Dan Nemeth著的《Cloud Native Go - 基于Go和React的web云原生应用构建指南》将由电子工业出版社出版。 简介 Cloud Native Go向开发人员展示如何构建大规模云应用程序,在满足当今客户的强大需求的同时还可以动态扩展来处理几乎任何规模的数据量、流量或用户。 Kevin Hoffman和Dan Nemeth详细描述了现代云原生应用程序,阐明了与快速、可靠的云原生开发相关的因素、规则和习惯。他们还介绍了Go这种“简单优雅”的高性能语言,它特别适合于云开发。 在本书中你将使用Go语言创建微服务,使用ReactJS和Flux添加前端Web组件,并掌握基于Go的高级云原生技术。Hoffman和Nemeth展示了如何使用Wercker、Docker和Dockerhub等工具构建持续交付管道; 自动推送应用程序到平台上; 并系统地监控生产中的应用程序性能。 学习“云之道”:为什么开发好的云软件基本上是关于心态和规则 了解为什么使用Go语言是云本地微服务开发的理想选择 规划支持持续交付和部署的云应用程序 设计服务生态系统,然后以test-first的方式构建它们 将正在进行的工作推送到云 使用事件源和CQRS模式来响应大规模和高吞吐量 安全的基于云的Web应用程序:做与不做的选择 使用第三方消息传递供应商创建响应式云应用程序 使用React和Flux构建大规模,云友好的GUI 监控云中的动态扩展,故障转移和容错 章节简介如下图。 关于作者 Kevin Hoffman通过现代化和以多种不同语言构建云原生服务的方式帮助企业将其应用程序引入云端。他10岁时开始编程,在重新组装的CommodoreVIC-20上自习BASIC。从那时起,他已经沉迷于构建软件,并花了很多时间学习语言、框架和模式。他已经构建了从遥控摄影无人机、仿生性安全系统、超低延迟金融应用程序到移动应用程序等一系列软件。他在构建需要与Pivotal Cloud Foundry配合使用的自定义组件时爱上了Go语言。 Kevin 是流行的幻想书系列(*The Sigilord Chronicles*,http://amzn.to/ 2fc8iES)的作者,他热切地期待着最终能够将自己对构建软件的热爱与对构建幻想世界的热爱结合起来。 Dan Nemeth目前在Pivotal担任咨询解决方案架构师,负责支持Pivotal Cloud Foundry。他从Commodore 64开始就一直在开发软件,从1995年起开始专业编码,使用ANSIC编写了用于本地ISP的CGI脚本。从那时起,他职业生涯的大部分时间里是作为独立顾问为从金融到制药行业提供解决方案,并使用当时流行的各种语言和框架。Dan最近接受了Go作为自己的归宿,并热情地将它用于所有的项目。 如果你发现Dan没在电脑前,他很可能就是在靠近安纳波利斯的水域玩帆船或飞钓。 下面先罗列下目录,以飨读者。 目录 云之道.. 1 云之道的优点.. 2 遵循简单.. 2 测试优先,测试一切.. 3 尽早发布,频繁发布.. 5 自动化一切.. 6

Pivotal Cloud foundry快速开始指南

(题图:黄山日出后的云海 Oct 3,2013) 前言 最近研究了下Pivotal的Cloud foundry,CF本身是一款开源软件,很多PAAS厂商都加入了CF,我们用的是的PCF Dev(PCF Dev是一款可以在工作站上运行的轻量级PCF安装)来试用的,因为它可以部署在自己的环境里,而Pivotal Web Services只免费两个月,之后就要收费。这里有官方的详细教程。 开始 根据官网的示例,我们将运行一个Java程序示例。 安装命令行终端 下载后双击安装即可,然后执行cf help能够看到帮助。 安装PCF Dev 先下载,如果你没有Pivotal network账号的话,还需要注册个用户,然后用以下命令安装: $./pcfdev-VERSION-osx && \ cf dev start Less than 4096 MB of free memory detected, continue (y/N): > y Please sign in with your Pivotal Network account. Need an account? Join Pivotal Network: https://network.pivotal.io Email> 849122844@qq.com Password> Downloading VM... Progress: |+++++++++++++=======>| 100% VM downloaded. Allocating 4096 MB out of 16384 MB total system memory (3514 MB free).