SRE|当Google的核心准则遇到Xero的最佳实践

杨y 发表了文章 • 0 个评论 • 63 次浏览 • 2017-11-14 15:55 • 来自相关话题

关于SRE,数人云之前给大家分享很多相关的文章,想必大家已经有了一定的了解,今天给大家带来的这篇文章,分别从Xero和Google的角度讨论一些工具和框架,以及SRE的一些准则。

Xero的SRE之路

作为一个SRE,作者主要关心的是如何保持应用平台的稳定,减少崩溃,然而这也是不能避免的,本文会通过Xero的SRE经验去讨论一些工具和框架。

任何故障的开始都是至关重要的,因此需要在发现故障的第一时间就提醒能解决问题的人。

大多数的生产问题,都是通过监控基础设施进行检测的,用于告警的通道工具已经随着时间的推移而发生了变化,但是基本的流程仍然大同小异,如下图所示:






自动告警Pipeline

自动化Pipeline可以确保工程师快速、正确、一致和可靠的进行工作,理想的情况下, 所有的告警都应该是自动化的,但有时我们会接触到一些没有被发现的问题,所以希望有一种方法可以允许其他团队报告保留自动告警Pipeline,因此决定将这些请求转换为自动告警,如下所示:






 
手动报警Pipeline

使用这种方法,自动和手动告警都以同样的方式送达工程师,但是每个告警都有什么呢?

剖析一个告警

出现了什么错误?问题的性质和严重性?
故障出现后,都有哪些地方收到了影响?
它怎么能固定下来呢?链接到Runbooks或者How-to文档。

尝试编写自动告警模板以满足这些需求,对于手工报告的问题,依赖于通过在线表单提供这些信息,希望填写表格的过程是速度且无痛的,所以只有第一个问题是强制性的:

能否概括一下这个问题,比如,到底出了什么问题?
哪个站点/URL有问题?可以帮助识别受影响的地方。
问题是否仅限于特定的地点,帮助我们隔离网络/CDN问题。
问题是什么时候开始的?帮助设置日志/度量搜索的时间尺度。
谁在关注这些问题?这样可以将它们包含在事件的Pipeline中

虽然这些信息不可能如监控系统所提供的那样具体明确,但它仍然可以减少SRE工程师所需要的调查工作。

On-call as code

我们使用第三方的呼叫管理系统,允许我们建立多个On-call团队,定义每个团队的轮换,并将每个团队连接到监控基础设施,告警是针对拥有受影响系统的团队的,但是SRE为每个团队提供了额外的层,如下所示:








告警升级

在20多个产品和服务的呼叫团队中,On-call管理配置已经演化为相当复杂的设置,随着越来越多的团队加入其中,我们的支持模式也在不断地发展,要手动设置所有的东西将是一项艰巨的任务,处于这个原因,我们创建了一个“On-call as code”系统,类似于Chef这样的基础设施代码框架。








On-call configuration pipeline

延伸阅读:

Chef 是一款自动化服务器配置管理工具,可以对所管理的对象实行自动化配置,如系统管理,安装软件等。Chef 由三大组件组成:Chef Server、Chef Workstation 和 Chef Node。

Chef Server 是核心服务器,维护了一套配置脚本(Cookbook),与每个被管节点(Chef Node)交互并给出配置指令。

Chef Workstation 提供了我们与 Chef Server 交互的接口:我们在 Workstation 上创建定义 Cookbook,并将 Cookbook 上传到 Chef Server 上以保证被管机器能从 Chef Server 上取得最新的配置指令。

Chef Node 是安装了 chef-client 并注册了的被管理节点,可以是物理机或者虚拟机或者其他对象。Chef Node 每次运行 chef-client 时都会从 Chef Server 端取得最新的配置指令(Cookbook)并按照指令配置自己。 一套 Chef 环境包含一个 Chef Server,至少一个 Chef Workstation,以及一到多个 Chef Node。

团队可以通过将更改合并到Git存储库来更新他们的调用配置,然后,CI/CD系统运行一个Rake任务,它通过调用管理系统来同步存储库,这种方法为我们提供了一系列的好处:

所有的配置更改都可以通过标准的Git工作流进行同行评审。

CI服务器可以“Lint”每个配置更改,以验证它满足一些基本需求(例如,每个团队需要一个管理员)。

允许团队手动设置他们的调用轮换,因为On-call系统的Web界面提供了一种简单的方法,然而,团队调用设置的所有其他组件都由同步任务执行。

新团队不需要担心设置他们的告警端点或将他们的团队与SRE的时间表联系起来,同步任务从一个最小的配置文件自动地构建每个团队的调用配置,如果团队需要一个不寻常的调用设置,那他们就可以置顶额外的配置文件来这样做。

未来,可以很容易地改变所有团队的标准调用配置,例如更改每次升级之间的时间限制。

在这些倡议中,我们为管理良好的时间奠定了基础:

告警以相同的方式发出,无论它们是自动检测还是手动报告。

每个告警的内容都包含了足够的信息,让工程师开始计划响应。

On-Call作为代码系统,确保所有的团队都能以一致的方式接受告警。

虽然工作流程、优先级和日常操作从SRE团队到另一个SRE团队之间都有细微的差别,但都与他们支持的服务有着基本的信任,并坚持相同的核心原则。

一般来说,SRE团队负责可用性、延迟性、性能、效率、变更管理、监控、紧急响应以及服务的容量规划。

我们已经为SRE团队与其环境交互(不仅仅是生产环境,还包括开发团队、测试团队、用户等等)制定了相关的规则和原则,这些规则和工作实践帮助我们保持对工程工作的关注,而不是运维工作。

Google SRE准则
确保持久专注于工程

Google在50%的时间内为SREs的运维工作设置上限,他们的剩余时间应该用在项目工作的编程技能上,在实践当中,这是通过监控SRE们所做的运维工作数量来完成的,并将多余的运维工作重新定向到产品开发团队:重新分配Bug将开发人员集成到On-Call pager roUNK中等等。

当运维负载下降到50%或更低时,重新向结束,这也提供了一个有效的反馈机制,引导开发人员构建不需要人工干预的系统,当整个组织——SRE和开发人员理解为什么这个机制存在时,这种方法很有效,并且支持没有溢出事件的目标,因为产品没有产生足够的运维负载来要求她。

当他们专注于运维工作时,在平均每8-12小时中,SRE应该最多接受两个事件,这个目标量给呼叫工程师足够的时间准确快速地处理事件,清理和恢复正常服务,然后进行事后剖析,如果有两个以上的事件经常发生在呼叫转移上,问题就无法彻底调查,工程师们也无法从这些事件中吸取教训,一种寻呼机疲劳的情况下也不会随着规模而提高,相反,如果每次转换时,调用的SRE始终接受不到一个事件,那么这就无异于在浪费时间。

对于所有重大事件,无论是否寻呼,都应该写死后的纪录,没有触发界面的后期纪录甚至更有价值,因为它们可能指出了明显的监控漏洞,这个调查应该确定发生的细节,找出事件的所有根源,并分配行动来纠正问题化或改进下次处理的方法,Google在一个免费的分析文化下运行,目标是揭露出错误并应用工程来修复这些错误,而不是去避免或尽量最小化它们。

追求最大的变化速度而不违反服务的SLO

产品开发和SRE团队可以通过消除各自目标中的结构性冲突来享受高效的工作关系,结构冲突是在创新和产品稳定性之间,正如前面所述,这种冲突往往是间接表达的,在SRE中,我们将这个冲突引入到前面,然后通过引入错误预算来解决它。

预算错误源于这样一种观察, 即100%是所有东的错误可靠性目标,一般来说,对于任何软件服务或系统100%可用和99.999%可用,有许多其他系统用户和服务之间的路径(他们的笔记本电脑,家里的WIFI,ISP,电网……),这些系统集体远远低于99.999%,因此,99.999……和100%的差异在于其他不可用性的丢失,而且用户无法从需要添加走货0.001%的可用性中获益。

如果100%是一个系统的错误可靠性目标,那么,系统的正确可靠性目标是什么?这实际上并不是一个技术问题——这是一个产品问题,应该考虑以下因素:

考虑到他们是如何使用产品的,用户满意的程度是多少?

对于那些对产品的可用性不满意的用户有什么选择?

用户在不同可用级别上使用该产品会发生什么情况?

业务或产品必须建立系统的可用性目标,一旦确定了目标,错误预算就是一个减去可用性的目标。一个99.99%可用服务是0.01的不可用,允许0.01的不可用性是服务的错误预算,我们可以把预算画在问么想要的任何东西上,只要不超支。

那么要如何花费这个错误预算呢?开发团队希望推出特性并吸引新用户,理想情况下,我们会把所有的错误预算都花在我们发布的新产品上,以快速启动它们,这个基本前提描述了整个错误预算模型,一旦SRE活动在这个框架中被概念化,通过注入阶段性的滚转和1%的实验等策略释放错误预算,可以优化更快的启动。

错误预算的使用解决了开发和SRE之间的结构冲突,SRE的目标实在是“0消耗”;相反,SRE和产品开发人员的目标是将错误预算花在获得最大特征速度上,这种改变造成了不同,宕机不再是“坏”的事情——它是创新过程中预期的一部分,而且发展和SRE团队都在管理,而不是一直忧心忡忡。

监控

监控是服务所有者跟踪系统的健康和可用性的主要手段之一,因此,应当深思熟虑地构建监控策略,一个典型的、常见的监控方法是观察特定的值或条件,然后在超过该值或条件时触发电子邮件告警,然而,这种类型的电子邮件告警并不是一个有效的解决方案;一个需要一个人阅读电子邮件并决定是否需要采取某种行动的系统从根本上是有缺陷的,监控不应该要求人对告警区域的任何部分进行解释,相反,应用应做口译,只有当它们需要采取行动时,才去通知SRE。

三种有效地监控输出:

告警:意味着SRE需要立即采取行动来应对正在发生或即将发生的事情,以改善这种情况。

Tickets:表示SRE需要采取行动,但不是马上,系统不能自动处理这种情况,但如果一个人在几天内采取了动作,就不会造成事故。

日志记录:无需日日查看的信息,但它被记录为诊断错误或反刍的目的。

应急响应

可靠性是指故障时间(MTTF)和平均修复时间(MTTR)的函数,评估应急反应有效性地最相关的指标是反应小组能多快地将系统恢复到健康状态,即MTTR。 一个能够避免需要人工干预的紧急情况的系统比需要实际操作的系统有更高的可用性,当SRE有需求时,我们发现,在“剧本”中提前记录是最佳实践,在MTTR中产生大约3倍的改进,而不是“即兴发挥”的策略,谷歌SRE依赖于on -call playbooks,除了诸如“不幸之轮”这样的练习,还可以让工程师对on - call事件做出反应。

效率和性能

任何时候,有效利用资源都是非常重要的,由于SRE最终控制了供应,因此它也必须参与任何有关使用的工作,因为利用率是给定服务如何工作的一个函数,以及它是如何响应的。密切关注服务的供应策略,它的使用为服务的总成本提供了非常大的杠杆。

资源使用是需求(负载)、容量和应用效率的函数。SRE预测需求,提供能力,并可以修改软件,这三个因素是服务效率的很大一部分(尽管不是全部)。

随着负载的增加,应用系统会变得越来越慢,服务的减少等同于能力的丧失,在某一个时刻,当某个缓慢的系统停止服务,这相当于无限的慢。SRE提供以特性的响应速度满足容量目标,因此对服务的性能非常感兴趣,SRE和产品开发人员将(并且应该)监控和修改服务以提高其性能,从而增加容量和提高效率。

以上是小数今天给大家分享的文章,众所周知,SRE的理念最早出自Google,而数人云老王(王璞)曾供职于Google的广告部门,对于SRE有着深入的研究,在数人云的Meetup上就曾以SRE为题进行了多次分享,同时小数也给大家分享了多篇SRE相关的文章,有兴趣的可以点击查看: 查看全部

1.png



关于SRE,数人云之前给大家分享很多相关的文章,想必大家已经有了一定的了解,今天给大家带来的这篇文章,分别从Xero和Google的角度讨论一些工具和框架,以及SRE的一些准则。

Xero的SRE之路

作为一个SRE,作者主要关心的是如何保持应用平台的稳定,减少崩溃,然而这也是不能避免的,本文会通过Xero的SRE经验去讨论一些工具和框架。

任何故障的开始都是至关重要的,因此需要在发现故障的第一时间就提醒能解决问题的人。

大多数的生产问题,都是通过监控基础设施进行检测的,用于告警的通道工具已经随着时间的推移而发生了变化,但是基本的流程仍然大同小异,如下图所示:


2.png

自动告警Pipeline

自动化Pipeline可以确保工程师快速、正确、一致和可靠的进行工作,理想的情况下, 所有的告警都应该是自动化的,但有时我们会接触到一些没有被发现的问题,所以希望有一种方法可以允许其他团队报告保留自动告警Pipeline,因此决定将这些请求转换为自动告警,如下所示:


3.png

 
手动报警Pipeline

使用这种方法,自动和手动告警都以同样的方式送达工程师,但是每个告警都有什么呢?

剖析一个告警

出现了什么错误?问题的性质和严重性?
故障出现后,都有哪些地方收到了影响?
它怎么能固定下来呢?链接到Runbooks或者How-to文档。

尝试编写自动告警模板以满足这些需求,对于手工报告的问题,依赖于通过在线表单提供这些信息,希望填写表格的过程是速度且无痛的,所以只有第一个问题是强制性的:

能否概括一下这个问题,比如,到底出了什么问题?
哪个站点/URL有问题?可以帮助识别受影响的地方。
问题是否仅限于特定的地点,帮助我们隔离网络/CDN问题。
问题是什么时候开始的?帮助设置日志/度量搜索的时间尺度。
谁在关注这些问题?这样可以将它们包含在事件的Pipeline中

虽然这些信息不可能如监控系统所提供的那样具体明确,但它仍然可以减少SRE工程师所需要的调查工作。

On-call as code

我们使用第三方的呼叫管理系统,允许我们建立多个On-call团队,定义每个团队的轮换,并将每个团队连接到监控基础设施,告警是针对拥有受影响系统的团队的,但是SRE为每个团队提供了额外的层,如下所示:


4.png



告警升级

在20多个产品和服务的呼叫团队中,On-call管理配置已经演化为相当复杂的设置,随着越来越多的团队加入其中,我们的支持模式也在不断地发展,要手动设置所有的东西将是一项艰巨的任务,处于这个原因,我们创建了一个“On-call as code”系统,类似于Chef这样的基础设施代码框架。


5.png



On-call configuration pipeline

延伸阅读:

Chef 是一款自动化服务器配置管理工具,可以对所管理的对象实行自动化配置,如系统管理,安装软件等。Chef 由三大组件组成:Chef Server、Chef Workstation 和 Chef Node。

Chef Server 是核心服务器,维护了一套配置脚本(Cookbook),与每个被管节点(Chef Node)交互并给出配置指令。

Chef Workstation 提供了我们与 Chef Server 交互的接口:我们在 Workstation 上创建定义 Cookbook,并将 Cookbook 上传到 Chef Server 上以保证被管机器能从 Chef Server 上取得最新的配置指令。

Chef Node 是安装了 chef-client 并注册了的被管理节点,可以是物理机或者虚拟机或者其他对象。Chef Node 每次运行 chef-client 时都会从 Chef Server 端取得最新的配置指令(Cookbook)并按照指令配置自己。 一套 Chef 环境包含一个 Chef Server,至少一个 Chef Workstation,以及一到多个 Chef Node。

团队可以通过将更改合并到Git存储库来更新他们的调用配置,然后,CI/CD系统运行一个Rake任务,它通过调用管理系统来同步存储库,这种方法为我们提供了一系列的好处:

所有的配置更改都可以通过标准的Git工作流进行同行评审。

CI服务器可以“Lint”每个配置更改,以验证它满足一些基本需求(例如,每个团队需要一个管理员)。

允许团队手动设置他们的调用轮换,因为On-call系统的Web界面提供了一种简单的方法,然而,团队调用设置的所有其他组件都由同步任务执行。

新团队不需要担心设置他们的告警端点或将他们的团队与SRE的时间表联系起来,同步任务从一个最小的配置文件自动地构建每个团队的调用配置,如果团队需要一个不寻常的调用设置,那他们就可以置顶额外的配置文件来这样做。

未来,可以很容易地改变所有团队的标准调用配置,例如更改每次升级之间的时间限制。

在这些倡议中,我们为管理良好的时间奠定了基础:

告警以相同的方式发出,无论它们是自动检测还是手动报告。

每个告警的内容都包含了足够的信息,让工程师开始计划响应。

On-Call作为代码系统,确保所有的团队都能以一致的方式接受告警。

虽然工作流程、优先级和日常操作从SRE团队到另一个SRE团队之间都有细微的差别,但都与他们支持的服务有着基本的信任,并坚持相同的核心原则。

一般来说,SRE团队负责可用性、延迟性、性能、效率、变更管理、监控、紧急响应以及服务的容量规划。

我们已经为SRE团队与其环境交互(不仅仅是生产环境,还包括开发团队、测试团队、用户等等)制定了相关的规则和原则,这些规则和工作实践帮助我们保持对工程工作的关注,而不是运维工作。

Google SRE准则
确保持久专注于工程

Google在50%的时间内为SREs的运维工作设置上限,他们的剩余时间应该用在项目工作的编程技能上,在实践当中,这是通过监控SRE们所做的运维工作数量来完成的,并将多余的运维工作重新定向到产品开发团队:重新分配Bug将开发人员集成到On-Call pager roUNK中等等。

当运维负载下降到50%或更低时,重新向结束,这也提供了一个有效的反馈机制,引导开发人员构建不需要人工干预的系统,当整个组织——SRE和开发人员理解为什么这个机制存在时,这种方法很有效,并且支持没有溢出事件的目标,因为产品没有产生足够的运维负载来要求她。

当他们专注于运维工作时,在平均每8-12小时中,SRE应该最多接受两个事件,这个目标量给呼叫工程师足够的时间准确快速地处理事件,清理和恢复正常服务,然后进行事后剖析,如果有两个以上的事件经常发生在呼叫转移上,问题就无法彻底调查,工程师们也无法从这些事件中吸取教训,一种寻呼机疲劳的情况下也不会随着规模而提高,相反,如果每次转换时,调用的SRE始终接受不到一个事件,那么这就无异于在浪费时间。

对于所有重大事件,无论是否寻呼,都应该写死后的纪录,没有触发界面的后期纪录甚至更有价值,因为它们可能指出了明显的监控漏洞,这个调查应该确定发生的细节,找出事件的所有根源,并分配行动来纠正问题化或改进下次处理的方法,Google在一个免费的分析文化下运行,目标是揭露出错误并应用工程来修复这些错误,而不是去避免或尽量最小化它们。

追求最大的变化速度而不违反服务的SLO

产品开发和SRE团队可以通过消除各自目标中的结构性冲突来享受高效的工作关系,结构冲突是在创新和产品稳定性之间,正如前面所述,这种冲突往往是间接表达的,在SRE中,我们将这个冲突引入到前面,然后通过引入错误预算来解决它。

预算错误源于这样一种观察, 即100%是所有东的错误可靠性目标,一般来说,对于任何软件服务或系统100%可用和99.999%可用,有许多其他系统用户和服务之间的路径(他们的笔记本电脑,家里的WIFI,ISP,电网……),这些系统集体远远低于99.999%,因此,99.999……和100%的差异在于其他不可用性的丢失,而且用户无法从需要添加走货0.001%的可用性中获益。

如果100%是一个系统的错误可靠性目标,那么,系统的正确可靠性目标是什么?这实际上并不是一个技术问题——这是一个产品问题,应该考虑以下因素:

考虑到他们是如何使用产品的,用户满意的程度是多少?

对于那些对产品的可用性不满意的用户有什么选择?

用户在不同可用级别上使用该产品会发生什么情况?

业务或产品必须建立系统的可用性目标,一旦确定了目标,错误预算就是一个减去可用性的目标。一个99.99%可用服务是0.01的不可用,允许0.01的不可用性是服务的错误预算,我们可以把预算画在问么想要的任何东西上,只要不超支。

那么要如何花费这个错误预算呢?开发团队希望推出特性并吸引新用户,理想情况下,我们会把所有的错误预算都花在我们发布的新产品上,以快速启动它们,这个基本前提描述了整个错误预算模型,一旦SRE活动在这个框架中被概念化,通过注入阶段性的滚转和1%的实验等策略释放错误预算,可以优化更快的启动。

错误预算的使用解决了开发和SRE之间的结构冲突,SRE的目标实在是“0消耗”;相反,SRE和产品开发人员的目标是将错误预算花在获得最大特征速度上,这种改变造成了不同,宕机不再是“坏”的事情——它是创新过程中预期的一部分,而且发展和SRE团队都在管理,而不是一直忧心忡忡。

监控

监控是服务所有者跟踪系统的健康和可用性的主要手段之一,因此,应当深思熟虑地构建监控策略,一个典型的、常见的监控方法是观察特定的值或条件,然后在超过该值或条件时触发电子邮件告警,然而,这种类型的电子邮件告警并不是一个有效的解决方案;一个需要一个人阅读电子邮件并决定是否需要采取某种行动的系统从根本上是有缺陷的,监控不应该要求人对告警区域的任何部分进行解释,相反,应用应做口译,只有当它们需要采取行动时,才去通知SRE。

三种有效地监控输出:

告警:意味着SRE需要立即采取行动来应对正在发生或即将发生的事情,以改善这种情况。

Tickets:表示SRE需要采取行动,但不是马上,系统不能自动处理这种情况,但如果一个人在几天内采取了动作,就不会造成事故。

日志记录:无需日日查看的信息,但它被记录为诊断错误或反刍的目的。

应急响应

可靠性是指故障时间(MTTF)和平均修复时间(MTTR)的函数,评估应急反应有效性地最相关的指标是反应小组能多快地将系统恢复到健康状态,即MTTR。 一个能够避免需要人工干预的紧急情况的系统比需要实际操作的系统有更高的可用性,当SRE有需求时,我们发现,在“剧本”中提前记录是最佳实践,在MTTR中产生大约3倍的改进,而不是“即兴发挥”的策略,谷歌SRE依赖于on -call playbooks,除了诸如“不幸之轮”这样的练习,还可以让工程师对on - call事件做出反应。

效率和性能

任何时候,有效利用资源都是非常重要的,由于SRE最终控制了供应,因此它也必须参与任何有关使用的工作,因为利用率是给定服务如何工作的一个函数,以及它是如何响应的。密切关注服务的供应策略,它的使用为服务的总成本提供了非常大的杠杆。

资源使用是需求(负载)、容量和应用效率的函数。SRE预测需求,提供能力,并可以修改软件,这三个因素是服务效率的很大一部分(尽管不是全部)。

随着负载的增加,应用系统会变得越来越慢,服务的减少等同于能力的丧失,在某一个时刻,当某个缓慢的系统停止服务,这相当于无限的慢。SRE提供以特性的响应速度满足容量目标,因此对服务的性能非常感兴趣,SRE和产品开发人员将(并且应该)监控和修改服务以提高其性能,从而增加容量和提高效率。

以上是小数今天给大家分享的文章,众所周知,SRE的理念最早出自Google,而数人云老王(王璞)曾供职于Google的广告部门,对于SRE有着深入的研究,在数人云的Meetup上就曾以SRE为题进行了多次分享,同时小数也给大家分享了多篇SRE相关的文章,有兴趣的可以点击查看:

Docker?Rkt?Lxd?细说K8S容器进行时的又一选项Containerd

杨y 发表了文章 • 0 个评论 • 63 次浏览 • 2017-11-11 14:18 • 来自相关话题

器运行时是执行容器并在节点上管理容器镜像的软件,目前,最广为人知的容器运行时是Docker,但在生态系统中还有其他容器运行时软件,比如Rkt、Containerd和Lxd。Docker是现在于Kubernetes环境中使用的最常见的容器运行时,今天数人云给大家推荐一个Docker的组件——Containerd,它可能是更好的选择。

本文是由谷歌的软件工程师Lantao Liu和IBM的开源开发者Mike Brown基于自身相关实践,共同编写。

Kubernetes 1.5引入了一个名为容器运行时接口(CRI)的内部插件API,以方便地访问不同的容器运行时,CRI允许Kubernetes使用各种容器运行时,而不需要重新编译。从理论上说,Kubernetes可以使用任何实现CRI的容器运行时管理容器和容器镜像。

在过去的6个月中,来自Google、Docker、IBM、中兴和ZJU的工程师们一直在努力为CRI For Containerd,这个项目被称为cri-containerd,用户可以使用容器作为底层运行时运行Kubernetes集群,并且无需安装Docker。

Containerd

Containerd是一个兼容OCI的核心容器运行时,它被设计为嵌入到更大的系统当中,提供了在一个节点上执行容器和管理镜像的最小功能集,它是由Docker公司发起,并于2017年3月加入了CNCF,Docker引擎本身是建立在早期版本的容器之上,并且很快将更新到最新版本。

与Docker相比,Containerd的规模要小得多,提供了Golang客户端API,而且更专注于可嵌入,较小范围会导致一个更小的代码库,随着时间的推移,其更容器维护以及匹配Kubernetes的需求,如下图所示:












综上所述,从技术的角度来看,Containerd是Kubernetes的容器进行时比较好的选择。

Cri-Containerd

Cri-Containerd是对于容器的一个实现,它在与Kubelet和 Containerd相同的节点上运行,在Kuberntes和Containerd之间的分层中,Cri-Containerd处理来自Kubelet的所有国际服务请求,并使用Containerd管理容器和容器镜像,Cri-Containerd管理这些服务请求,在一定程度上是通过形成Containerd服务请求,同时添加足够的附加功能来去支持CRI需求。






与当前的Docker CRI实现(Dockershim)相比,Cri-Containerd消除了栈中的额外跳转,使堆栈更加稳定和高效。

体系结构







可以通过下面这个例子来演示当Kubele创建一个单一容器的时候,如何使用Cri-Containerd。

Kubelet通过国际运行时服务API调用了Cri-Containerd,用以创建一个Pod;

Cri-Containerd使用Containerd创建和启动一个特殊的暂停容器(沙箱容器),并将该容器放在Pod的Cgroups和名称空间中;

Containerd使用CNI配置了Pod的网络名称空间;

Kubelet随后通过国际服务API调用了“容器”,以拉出应用程序的容器的镜像;

如果镜像不存在于节点,则Cri-Containerd将进一步使用Containerd来拉出镜像;

然后,Kubelet通过“CRI”服务API调了“Cri-Containerd”通过拉取容器的镜像来创建和启动应用程序容器;

Cri-Containerd最终调用Containerd来创建应用程序容器,将其放入Pod的Cgroups和命名空间中,然后启动该容器的新应用程序容器。

在这些步骤之后,将创建并运行一个Pod及其相应的应用程序容器。

现阶段状态

Cri-Containerd V1.0.0-alpha.0是在2017年9月25日发布的。

其功能完备,所有的Kubernetes的特性都得到了支持。

所有的CRI validation test(CRI validation test是一种测试框架,用于验证是否符合Kubernetes的所有要求。地址:https://github.com/kubernetes/ ... on.md)

所有的 Node e2e Test都已通过(用于测试Kubernetes节点级功能的测试框架如Managing Pods、Mounting Volumes等,地址:https://github.com/kubernetes/ ... ts.md)。

若想了解更多关于V1.0-Alpha的相关内容,请前往:https://github.com/kubernetes- ... pha.0

延伸阅读

对于一个多节点集群安装程序,并使用能应用和Kubeadm启动步骤请参见:https://github.com/kubernetes- ... ME.md

若想在Google云端从头创建一个集群,请参见:https://github.com/kelseyhight ... d-way

对于一个自发布Tarball的自定义安装,请参见:https://github.com/kubernetes- ... on.md

对于在本地VM上安装LinuxKit,请参见:https://github.com/linuxkit/li ... netes

下一阶段

Containerd承诺,在下一阶段将主要改进稳定性和可用性方面的问题:

稳定性:

在Kubernetes的测试基础设施上建立一套完整的Kubernetes集成测试,包括Ubuntu、COS(容器化的OS 地址:https://cloud.google.com/conta ... docs/)等等。

积极解决用户报告的任何测试失败和其他问题。

可用性:

提高Crictl(https://github.com/kubernetes- ... tl.md)的用户体验,Crictl是所有的CRI容器运行时的可移植命令行工具,这里的目标是使其易于用于调试和开发场景。

集成Kube-up.sh(https://kubernetes.io/docs/get ... /gce/)帮助用户使用Cri-Containerd来提高Kubernetes集群的生产质量。

改进文档。

预计在2017年底发布V1.0-Beta。

提供建议

Cri-Containerd是一个Kubernetes的孵化器项目,地址:ttps://github.com/kubernetes-incubator/cri-containerd。欢迎提供任何具有建设性的意见和建议,具体的使用入门指南请参见:https://github.com/kubernetes- ... opers

社区

Cri-Containerd是由Kubernetes Signode社区开发和维护的,如有相关的建议,可以加入社区:

Sig-Node社区网站:https://github.com/kubernetes/ ... -node

Slack:Kubernetes(kubernet.slack.com)的sig-节点通道:https://kubernetes.slack.com/

原文作者:Kubernetes 原文链接:http://blog.kubernetes.io/2017 ... erral 查看全部

1.png


器运行时是执行容器并在节点上管理容器镜像的软件,目前,最广为人知的容器运行时是Docker,但在生态系统中还有其他容器运行时软件,比如Rkt、Containerd和Lxd。Docker是现在于Kubernetes环境中使用的最常见的容器运行时,今天数人云给大家推荐一个Docker的组件——Containerd,它可能是更好的选择。

本文是由谷歌的软件工程师Lantao Liu和IBM的开源开发者Mike Brown基于自身相关实践,共同编写。

Kubernetes 1.5引入了一个名为容器运行时接口(CRI)的内部插件API,以方便地访问不同的容器运行时,CRI允许Kubernetes使用各种容器运行时,而不需要重新编译。从理论上说,Kubernetes可以使用任何实现CRI的容器运行时管理容器和容器镜像。

在过去的6个月中,来自Google、Docker、IBM、中兴和ZJU的工程师们一直在努力为CRI For Containerd,这个项目被称为cri-containerd,用户可以使用容器作为底层运行时运行Kubernetes集群,并且无需安装Docker。

Containerd

Containerd是一个兼容OCI的核心容器运行时,它被设计为嵌入到更大的系统当中,提供了在一个节点上执行容器和管理镜像的最小功能集,它是由Docker公司发起,并于2017年3月加入了CNCF,Docker引擎本身是建立在早期版本的容器之上,并且很快将更新到最新版本。

与Docker相比,Containerd的规模要小得多,提供了Golang客户端API,而且更专注于可嵌入,较小范围会导致一个更小的代码库,随着时间的推移,其更容器维护以及匹配Kubernetes的需求,如下图所示:

2.png


3.png



综上所述,从技术的角度来看,Containerd是Kubernetes的容器进行时比较好的选择。

Cri-Containerd

Cri-Containerd是对于容器的一个实现,它在与Kubelet和 Containerd相同的节点上运行,在Kuberntes和Containerd之间的分层中,Cri-Containerd处理来自Kubelet的所有国际服务请求,并使用Containerd管理容器和容器镜像,Cri-Containerd管理这些服务请求,在一定程度上是通过形成Containerd服务请求,同时添加足够的附加功能来去支持CRI需求。

4.png


与当前的Docker CRI实现(Dockershim)相比,Cri-Containerd消除了栈中的额外跳转,使堆栈更加稳定和高效。

体系结构

5.png



可以通过下面这个例子来演示当Kubele创建一个单一容器的时候,如何使用Cri-Containerd。

Kubelet通过国际运行时服务API调用了Cri-Containerd,用以创建一个Pod;

Cri-Containerd使用Containerd创建和启动一个特殊的暂停容器(沙箱容器),并将该容器放在Pod的Cgroups和名称空间中;

Containerd使用CNI配置了Pod的网络名称空间;

Kubelet随后通过国际服务API调用了“容器”,以拉出应用程序的容器的镜像;

如果镜像不存在于节点,则Cri-Containerd将进一步使用Containerd来拉出镜像;

然后,Kubelet通过“CRI”服务API调了“Cri-Containerd”通过拉取容器的镜像来创建和启动应用程序容器;

Cri-Containerd最终调用Containerd来创建应用程序容器,将其放入Pod的Cgroups和命名空间中,然后启动该容器的新应用程序容器。

在这些步骤之后,将创建并运行一个Pod及其相应的应用程序容器。

现阶段状态

Cri-Containerd V1.0.0-alpha.0是在2017年9月25日发布的。

其功能完备,所有的Kubernetes的特性都得到了支持。

所有的CRI validation test(CRI validation test是一种测试框架,用于验证是否符合Kubernetes的所有要求。地址:https://github.com/kubernetes/ ... on.md

所有的 Node e2e Test都已通过(用于测试Kubernetes节点级功能的测试框架如Managing Pods、Mounting Volumes等,地址:https://github.com/kubernetes/ ... ts.md)。

若想了解更多关于V1.0-Alpha的相关内容,请前往:https://github.com/kubernetes- ... pha.0

延伸阅读

对于一个多节点集群安装程序,并使用能应用和Kubeadm启动步骤请参见:https://github.com/kubernetes- ... ME.md

若想在Google云端从头创建一个集群,请参见:https://github.com/kelseyhight ... d-way

对于一个自发布Tarball的自定义安装,请参见:https://github.com/kubernetes- ... on.md

对于在本地VM上安装LinuxKit,请参见:https://github.com/linuxkit/li ... netes

下一阶段

Containerd承诺,在下一阶段将主要改进稳定性和可用性方面的问题:

稳定性:

在Kubernetes的测试基础设施上建立一套完整的Kubernetes集成测试,包括Ubuntu、COS(容器化的OS 地址:https://cloud.google.com/conta ... docs/)等等。

积极解决用户报告的任何测试失败和其他问题。

可用性:

提高Crictl(https://github.com/kubernetes- ... tl.md)的用户体验,Crictl是所有的CRI容器运行时的可移植命令行工具,这里的目标是使其易于用于调试和开发场景。

集成Kube-up.sh(https://kubernetes.io/docs/get ... /gce/)帮助用户使用Cri-Containerd来提高Kubernetes集群的生产质量。

改进文档。

预计在2017年底发布V1.0-Beta。

提供建议

Cri-Containerd是一个Kubernetes的孵化器项目,地址:ttps://github.com/kubernetes-incubator/cri-containerd。欢迎提供任何具有建设性的意见和建议,具体的使用入门指南请参见:https://github.com/kubernetes- ... opers

社区

Cri-Containerd是由Kubernetes Signode社区开发和维护的,如有相关的建议,可以加入社区:

Sig-Node社区网站:https://github.com/kubernetes/ ... -node

Slack:Kubernetes(kubernet.slack.com)的sig-节点通道:https://kubernetes.slack.com/

原文作者:Kubernetes 原文链接:http://blog.kubernetes.io/2017 ... erral

打走企业级落地微服务的拦路虎:数据

杨y 发表了文章 • 0 个评论 • 57 次浏览 • 2017-11-08 15:08 • 来自相关话题

数人云上几天给大家分享了:《踢开绊脚石:微服务难点之服务调用的解决方案》剖析了微服务的难点之一:服务调用的解决方案。今天再来跟大家聊聊微服务的另外一个难点:数据。

在尝试使用微服务架构的因由中,最主要的是允许团队能够以不同的速度在系统的不同部分进行工作,而且尽量将影响团队的相关因素最小化。因此,我们希望团队能够自治,做出关于实现和运营服务最好的决策,并且可以自由地进行更改。

为了获得这种自主权,需要“摆脱依赖”,很多人在某种程度上都引用了这句话,因为“每个微服务都应该拥有和控制自己的数据库,而不是两个服务去共享一个数据库。”这种理念是合情合理的,不要在服务之间共享一个数据库是因为会遇到读/写模式冲突、数据模型冲突、协调性问题等等。

当构建微服务时,如何安全地将数据库分切成多个小的数据库?首先对于企业级构建微服务,需要明确以下内容:

域是什么?它实现了什么
事物边界在哪里?
微服务如何跨越边界进行通信?
如果将数据库打开,会怎样?

什么是域

这似乎在很多地方都被忽视了,但在互联网公司如何实践微服务和传统企业如何(或者可能因为忽视了这一点而失败)实现微服务之间存在的巨大差异。

在构建微服务之前,以及它使用的数据(产品/消费等)的原因,需要对数据的表示有一个明确清晰的理解,例如,在我们可以将信息存储到一个数据库中,关于TicketMonster的预定和它向微服务的迁移,需要了解“什么是预定”,就如同在其他领域里需要了解什么是账户、什么是雇员、什么是索赔等等。

要做到这一点,需要深入了解现实中的“IT”是什么,例如,“什么是书?”,试着停下来想一想,因为这是一个很简单的例子,试着去想什么是一本书,那么,如何在数据模型中表达这一点呢?

关于“什么是一本书”没有一个客观的定义,因此,要回答这样的问题,必须知道“谁在问问题,什么是背景”,需要根据上下文去进行判断。作为人类,我们可以迅速(甚至是无意识地)解决着一理解的模糊性,因为在头脑、环境和问题中都有一个背景,但计算机没有,当构建应用并对数据建模时,需要明确地说出上下文,比如上面提到的企业拥有账户、用户、预定索赔等等,这让整个应用变得更为复杂,并且会产生很多的冲突和模糊,所以,需要界限。

在哪里划定界限?域驱动设计社区中的工作帮助处理整个域的复杂性,在实体、值对象和集合中绘制一个有界的上下文,换句话说,构建和细化一个代表域的模型,整个模型包含一个定义上下文的边界内,这些边界最终会成为微服务,或边界内的组件最终会成为微服务,抑或两者都是,无论哪种方式,微服务都是关于边界的,DDD(领域驱动设计)也是如此。







数据模型(希望如何在物理存储中表示的概念——注意,这里的显示差异)是由领域模型驱动的,当有这个边界时,可以知道并断言,在模型中什么是正确的,什么是不正确的,这些界限也意味着一定程度的自制,有界上下文的“A”可能对“Book”有不同的理解,而不是有界上下文的“B”(例如,可能有界上下文A是搜索服务,搜索标题为“Book”的标题,也许有界的上下文“B”是一种结账服务,它根据你购买的数据(标题+副本)来处理交易)。

关于DDD:

一些人试图复制Netflix,但他们只是复制了他们看到的那些,比如结果,而不是整个过程——Adrian Cockcroft,前Netflix首席云架构师。

对于不同的来说,微服务也是不尽相同的,没有一个硬性规定,只是根据自身实际情况去权衡,复制对一家公司有用的东西,仅仅因为它在这一刻似乎起到了作用,但跳过了过程以及其中的尝试,不会起到决定性的作用,需要注意的一点是,你的公司并不是Netflix,事实上,无论域在Netflix上有多么的复杂,它都要比你的传统企业简单的多。一些互联网公司之所以想实践落地微服务,是因为它们的速度非常快,而且规模庞大(在Twitter上发布一条推文很简单,但为5亿用户发布推文和显示Tweet流是非常复杂的),今天的企业将不得不面对领域和规模的复杂性,因此,接受这样一个事实:对于每个企业来说,都是不同的。

什么是事务边界

回到上文所设定的环境当中,需要一些如领域驱动设计这样的东西来帮助我们理解将要使用的模型来实现系统并在一个上下文中划定这些模型的边界,因此,接受客户、账户、预定等可能对不同的有界上下文意味着不同的东西,但最终,可能会在体系结构中分布这些相关的概念,但当发生变化时,需要一些方法协调这些不同的模型变化,需要对此进行解释,但在这之前,首先需要确定事务边界。

然而不幸,作为开发人员似乎仍然在构建分布式系统:仍然在查看一个单一的、关系型的、ACID的Database。也忽略了一个异步的、不可靠的网络危险,也就是说,做一些事情如编写一些奇特的框架,使我们不必对网络有任何了解(包括RPC框架、数据库抽象也可以忽略网络),并尝试用点对点同步调用(REST、SOAP、其他CORBA,比如对象序列化RPC库等等)来实现所有的东西。在不考虑权威和自治的情况下构建系统,最终试图通过许多独立服务来解决分布式数据问题,比如两阶段提交,或者把这些顾虑都忽略了?这种思维模式会导致构建非常脆弱的系统,而这些系统不具有规模,若把它称为SOA、微服务、迷你服务等等,那就无关紧要了。

交易边界的意思是需要最小的单位原子性,这是业务不变量的,无论使用数据库的ACID属性来实现原子性还是两段提交等都不重要,关键是想要使这些事物边界尽可能小(理想的是单一对象的单一事物:Vernon Vaughn有系列的文章描述了这种方法,用DDD聚集),这样就可以伸缩了,当使用DDD术语构建领域模型时,会识别实体、值对象和聚集,在这个上下文中,聚集的对象是封装其他实体/值对象的对象,并负责执行不变量(在一个有界的上下文中可以有多个聚合体)。

例如,假设有以下用例:

允许客户搜索航班
让客户在特定航班上选择座位
允许客户预定航班

可能会有三个有界的上下文:搜索、预定和票务(也许会有更多的支付、、待机、升级等等,但会将它缩小到这三个)。搜索负责显示特定路线的航班和特定时间的路线(天数、时间等等),预定将负责在预定过程中使用客户信息(姓名、地址、常旅客号等)、作为偏好和支付信息进行预定,票务将负责与航空公司的订位,并签发机票,在每个有界的上下文中,希望确定事务边界,在那里可以执行约束/不变量,不会考虑跨界上下文的原子事务,若想要小的事务边界(这是预定航班的一个非常简化的版本),改如何建模呢?可能是一个包含时间、日期、路线和像客户、飞机以及预定这样的实体航班集合?因为航班都有飞机、作为、客户和预定。为创造预定,飞行总机负责跟踪飞机、座椅等。这可能从数据库内部的数据模型角度(带有约束和外键的关系模型)或者在源代码中创建一个不错的对象模型(继承/组合),但来看看会发生什么:








在所有的预定、飞机、航班等方面是否真的存在不变量,只是为了创造一个预定?也就是说,如果在航班总数上增加了一架新飞机,是否应该在这一交易中包含客户和预定?可能不会,在这里所拥有的是一种聚合的聚合以及数据模型的便利,然而,事务的边界太大了,如果对航班、作为、预定等进行大量的更改,就会有巨大的事务冲突(无论是使用乐观的还是悲观的锁定都不重要),而且这显然没有规模(永远不要介意订单的不断下降,因为航班计划正在改变,这是一种糟糕的客户体验)。

如果打破了交易的界限,那就更小了。

也许预定、座椅可用性和航班是它们自己的独立集合,预定封装了客户信息、首选项和支付信息,Seat可利用聚合封装了飞机和飞机的配置,航班集合是由时间表、路线等组成的,但可以在不影响航班时刻表和飞机/座位可用性的情况下进行预定,从领域的角度看,希望能够做到这一点,不需要100%的严格一致性,但确实想要正确地记录飞行时间表的变化,如管理员,飞行的配置,以及客户的预定,那么,如何实现“在飞行上预定一个座位,”这样的事情呢?

在预定过程中,可能会呼叫座椅可用性集合,并要求它在飞机上预定一个作为,这个作为预定将被实现为一个单一的事务,例如(持有作为23A),并返回一个预定ID,可以将这个预定ID于预定联系起来,并且提交,知道这个座位是在一个“预定”的每一个(保留一个座位,并接受预定)都是单独的事务,并且可以独立地进行,而不需要任何两阶段提交或两阶段锁定。注意,这里使用“预定”是一个业务需求,不做座位分配,只保留座位,这个需求可能需要通过模型的迭代而被束缚,因为最初使用用例的语言可能只是简单地说“允许客户选择一个座位”,开发人员可以试着推新,这个需求意味着“从生育的座位中挑选,把它分配给客户,从库存中移除它,并且不出售比座位更多的票”。这将是额外的,不必要的不变量,这会给事务模型增加额外的负担,而业务模型实际上并不是不变的,在没有完全的座位分配情况下,这个业务当然可以接受预定,甚至是超额销售机票。








上图为一个示例,允许真正的域引导使用更小的、简化的、完全原子的事务边界来处理单个聚合,现在必须纠正这样一个事实:所有的个体交易都需要在某一时刻聚集在一起,数据的不同部分涉及到(例如,创建了一个预定和座位预定,但这些都不是通过固定的交易来获得登机牌/机票等)。

微服务如何跨边界通信

想要保持真正的业务 不变性,使用DDD可以选择将这些不变量建模为聚合,并使用单个事务进行聚合,在某些情况下,可以在单个事务中更新多聚合(跨单个数据或多个数据库),但这些场景可能是例外,仍然需要在聚合之间保持某种形式的一致性(最终在有界的上下文之间),那么应该怎么做呢?需要理解的一件事是:分布式系统是非常挑剔的,如果能在有限的时间内对分布式系统中的任何东西做出任何保证(事情将会失败,事情是不确定的,或者似乎失败了,系统有非同步的时间边界等等),那么为什么要尝试去解决它呢?如果接受并将其放入领域的一致性模型中会怎样呢?如果说“在必要的事务边界之间,可以与数据和域的其他部分进行协调,并在以后的某个时间点保持一致”?

正如一直说的,对于微服务,我们重视自主权,认为能够独立于其他系统(在可用性、协议、格式等方面)进行更改,时间的解耦和任何有限制的时间之间任何保证之间的任何保证,都允许真正实现这种自治(这不是计算机系统特有的,因此在事务边界和有界上线问之间,使用事件来保持一致性,事件是不可变的结构,它捕获了一个有趣的时间点,应该向对等点广播,同伴们会聆听它们感兴趣的事件,并根据这些数据做出的决定更新自己的数据等等。)

继续以订机票为例,当一个预定通过一个Acid风格的交易存储时,如何结束它?这是前面提到的“退票界”的背景,预定有界上下文将发布类似“New Booking创建”这样的事件,而票务绑定上下文将会消耗该事件,并继续与后端(可能是遗留的)票务系统进行交互,这显然需要某种集成和数据转换,这是Apache Camel非常擅长的。也引出了一些其他的问题,如何对数据库进行写操作,并以原子的方式将其发布到队列/消息传递设备中?

如果在事件之间有排序需求/因果需求呢?每个服务的一个数据库呢?

理想情况下,聚合会直接使用命令和域事件(作为第一个类公民,也就是说,)任何操作都是作为命令来实现的,任何响应都是作为对事件的响应来实现的)可以更清晰地映射使用内部上下文和上下文之间使用的事件之间关系,可以将事件(即Newbooking创建)发布到消息队列中,然后让侦听器从消息队列中使用该队列,并将其插入到数据库中,而无需使用Xa/2pc事务,而不需要将其插入到数据库中,可以将事件插入到一个专用的事件存储中,它就像数据库和消息发布-订阅主题一样(这可能是首选路由),或者可以继续使用一个ACID数据库,并将该数据库的变化流到一个持久的、复制的日志中,就像Apache卡夫卡一样,使用类似于Debezium的东西,并使用某种事件处理器来推断事件,无论哪种方式,关键是想要在时间事件中与不可变点之间的边界进行通信。








这带来了一些巨大的优势:

避免了跨边界且昂贵潜在的不可能的事务模型

可以对系统进行更改,而不妨碍系统的其他部分(时间和可用性)的进展

可以将数据存储在自己的数据库中,同时使用适合于服务的技术

可以在空闲时更改模式/数据库

变得更加可伸缩、容错、灵活

必须更加关注CAP定力和选择的技术来实现存储/队列

需要注意的是,这也有一些缺点:
更加复杂
难以调试
由于看到事件时有延迟,所以不能对其他系统所知道的内容作出任何假设
必须更加关注CAP定理和选择的技术来实现队列/存储

从这种方法中产生另一个有趣的概念是,能够实现一种称为“命令查询分离责任”的模式,在这种模式中,将读模型和编写模型分离到单独的服务中,请记住,我们对互联网公司没有非常复杂的领域模型感到遗憾,这在他们的编写模型中很明显(例如,在一个分布式日志中插入一条Tweet)。然而,他们的阅读模式因其规模而变得非常复杂,CQRS帮助分离了这些问题,另一方面,在企业中,编写模型可能非常复杂,而读取模型可能是简单的平面选择查询和扁平DTO对象,CQRS是一种强大的关注点隔离模式,一旦有了适当的边界和在聚集和有界上下文之间进行数据更改的好方法,就可以对其进行评估。

那么服务只有一个数据库,并且不与其他服务共享呢?在这个场景中,可能会侦听事件流的侦听器,并可能将数据插入到一个共享数据库中,而主聚合可能最终会使用这些数据,这个“共享数据库”非常好,记住,没有规则,只有权衡,在这种情况下,可能会有很多服务协同同一个数据库一起工作,只要团队拥有所有的过程,就不会否定自治的优势,当听到有人说“微服务应该有自己的数据库,而不是别人分享”时,你可以回答:好吧,有点。

打开数据库

如果将使用事件/流来进行所有的事情,并且永远的持久化这些事件呢?如果说数据库/缓存/索引实际上只是过去发生的事件的持久日志/流的物化视图,而当前状态是所有这些事件的左折叠?

这种方法带来了更多的好处,可以通过事件(上面列出的)来增加交流的好处:

现在可以将数据库看做是记录的:“当前状态”,而不是真正的纪录
可以引入新的应用,重新阅读过去的事件,并根据“将要发生的事情”来检查它们的行为
免费完善审计日志记录
可以引入应用的新版本,并通过重新播放事件对其执行非常详尽的测试
可以更容易地关于数据库版本/升级/模式变化的事件重演到新数据库中
可以迁移到全新的数据库技术(例如,可能发现已经超越了关系数据库,并且希望切换到专门的数据库/索引)







TM体系结构

当在aa.com、Delta.com或united.com上预定航班时,会看到其中的一些概念,当选择一个座位时,并没有实际地分配它。当订机票时,实际上并没有收到实体票,之后会收到一封电子邮件,通知已经被确认,你是否有过一次飞机换班的经历,并分配到一个不同的座位?或者是去登机口,听到工作人员要求放弃座位,因为机票已经超出预定座位,这些都是事务边界的例子,最终的一致性、补偿事务,甚至连工作中的道歉都属于。

Moral Of The Story

这里指的是:数据、数据集成、数据边界、企业使用模式、分布式系统理论、时间等等,都是微服务的难点(因为微服务是真正的分布式系统)在技术上看到了太多的困惑(“如果使用Spring引导,我正在做微服务”,“需要解决服务发现,在云计算之前负载均衡”,必须有一个每个微服务的数据库)和关于使用微服务的无用理论,别担心,因为一旦大的供应商来卖给你所有的高级产仍然需要做上面列出的那些困难部分。

原文作者:Software 原文链接:http://www.tuicool.com/articles/VnIvyyF 查看全部
数人云上几天给大家分享了:《踢开绊脚石:微服务难点之服务调用的解决方案》剖析了微服务的难点之一:服务调用的解决方案。今天再来跟大家聊聊微服务的另外一个难点:数据。

在尝试使用微服务架构的因由中,最主要的是允许团队能够以不同的速度在系统的不同部分进行工作,而且尽量将影响团队的相关因素最小化。因此,我们希望团队能够自治,做出关于实现和运营服务最好的决策,并且可以自由地进行更改。

为了获得这种自主权,需要“摆脱依赖”,很多人在某种程度上都引用了这句话,因为“每个微服务都应该拥有和控制自己的数据库,而不是两个服务去共享一个数据库。”这种理念是合情合理的,不要在服务之间共享一个数据库是因为会遇到读/写模式冲突、数据模型冲突、协调性问题等等。

当构建微服务时,如何安全地将数据库分切成多个小的数据库?首先对于企业级构建微服务,需要明确以下内容:

域是什么?它实现了什么
事物边界在哪里?
微服务如何跨越边界进行通信?
如果将数据库打开,会怎样?

什么是域

这似乎在很多地方都被忽视了,但在互联网公司如何实践微服务和传统企业如何(或者可能因为忽视了这一点而失败)实现微服务之间存在的巨大差异。

在构建微服务之前,以及它使用的数据(产品/消费等)的原因,需要对数据的表示有一个明确清晰的理解,例如,在我们可以将信息存储到一个数据库中,关于TicketMonster的预定和它向微服务的迁移,需要了解“什么是预定”,就如同在其他领域里需要了解什么是账户、什么是雇员、什么是索赔等等。

要做到这一点,需要深入了解现实中的“IT”是什么,例如,“什么是书?”,试着停下来想一想,因为这是一个很简单的例子,试着去想什么是一本书,那么,如何在数据模型中表达这一点呢?

关于“什么是一本书”没有一个客观的定义,因此,要回答这样的问题,必须知道“谁在问问题,什么是背景”,需要根据上下文去进行判断。作为人类,我们可以迅速(甚至是无意识地)解决着一理解的模糊性,因为在头脑、环境和问题中都有一个背景,但计算机没有,当构建应用并对数据建模时,需要明确地说出上下文,比如上面提到的企业拥有账户、用户、预定索赔等等,这让整个应用变得更为复杂,并且会产生很多的冲突和模糊,所以,需要界限。

在哪里划定界限?域驱动设计社区中的工作帮助处理整个域的复杂性,在实体、值对象和集合中绘制一个有界的上下文,换句话说,构建和细化一个代表域的模型,整个模型包含一个定义上下文的边界内,这些边界最终会成为微服务,或边界内的组件最终会成为微服务,抑或两者都是,无论哪种方式,微服务都是关于边界的,DDD(领域驱动设计)也是如此。

1.png



数据模型(希望如何在物理存储中表示的概念——注意,这里的显示差异)是由领域模型驱动的,当有这个边界时,可以知道并断言,在模型中什么是正确的,什么是不正确的,这些界限也意味着一定程度的自制,有界上下文的“A”可能对“Book”有不同的理解,而不是有界上下文的“B”(例如,可能有界上下文A是搜索服务,搜索标题为“Book”的标题,也许有界的上下文“B”是一种结账服务,它根据你购买的数据(标题+副本)来处理交易)。

关于DDD:

一些人试图复制Netflix,但他们只是复制了他们看到的那些,比如结果,而不是整个过程——Adrian Cockcroft,前Netflix首席云架构师。

对于不同的来说,微服务也是不尽相同的,没有一个硬性规定,只是根据自身实际情况去权衡,复制对一家公司有用的东西,仅仅因为它在这一刻似乎起到了作用,但跳过了过程以及其中的尝试,不会起到决定性的作用,需要注意的一点是,你的公司并不是Netflix,事实上,无论域在Netflix上有多么的复杂,它都要比你的传统企业简单的多。一些互联网公司之所以想实践落地微服务,是因为它们的速度非常快,而且规模庞大(在Twitter上发布一条推文很简单,但为5亿用户发布推文和显示Tweet流是非常复杂的),今天的企业将不得不面对领域和规模的复杂性,因此,接受这样一个事实:对于每个企业来说,都是不同的。

什么是事务边界

回到上文所设定的环境当中,需要一些如领域驱动设计这样的东西来帮助我们理解将要使用的模型来实现系统并在一个上下文中划定这些模型的边界,因此,接受客户、账户、预定等可能对不同的有界上下文意味着不同的东西,但最终,可能会在体系结构中分布这些相关的概念,但当发生变化时,需要一些方法协调这些不同的模型变化,需要对此进行解释,但在这之前,首先需要确定事务边界。

然而不幸,作为开发人员似乎仍然在构建分布式系统:仍然在查看一个单一的、关系型的、ACID的Database。也忽略了一个异步的、不可靠的网络危险,也就是说,做一些事情如编写一些奇特的框架,使我们不必对网络有任何了解(包括RPC框架、数据库抽象也可以忽略网络),并尝试用点对点同步调用(REST、SOAP、其他CORBA,比如对象序列化RPC库等等)来实现所有的东西。在不考虑权威和自治的情况下构建系统,最终试图通过许多独立服务来解决分布式数据问题,比如两阶段提交,或者把这些顾虑都忽略了?这种思维模式会导致构建非常脆弱的系统,而这些系统不具有规模,若把它称为SOA、微服务、迷你服务等等,那就无关紧要了。

交易边界的意思是需要最小的单位原子性,这是业务不变量的,无论使用数据库的ACID属性来实现原子性还是两段提交等都不重要,关键是想要使这些事物边界尽可能小(理想的是单一对象的单一事物:Vernon Vaughn有系列的文章描述了这种方法,用DDD聚集),这样就可以伸缩了,当使用DDD术语构建领域模型时,会识别实体、值对象和聚集,在这个上下文中,聚集的对象是封装其他实体/值对象的对象,并负责执行不变量(在一个有界的上下文中可以有多个聚合体)。

例如,假设有以下用例:

允许客户搜索航班
让客户在特定航班上选择座位
允许客户预定航班

可能会有三个有界的上下文:搜索、预定和票务(也许会有更多的支付、、待机、升级等等,但会将它缩小到这三个)。搜索负责显示特定路线的航班和特定时间的路线(天数、时间等等),预定将负责在预定过程中使用客户信息(姓名、地址、常旅客号等)、作为偏好和支付信息进行预定,票务将负责与航空公司的订位,并签发机票,在每个有界的上下文中,希望确定事务边界,在那里可以执行约束/不变量,不会考虑跨界上下文的原子事务,若想要小的事务边界(这是预定航班的一个非常简化的版本),改如何建模呢?可能是一个包含时间、日期、路线和像客户、飞机以及预定这样的实体航班集合?因为航班都有飞机、作为、客户和预定。为创造预定,飞行总机负责跟踪飞机、座椅等。这可能从数据库内部的数据模型角度(带有约束和外键的关系模型)或者在源代码中创建一个不错的对象模型(继承/组合),但来看看会发生什么:


2.png



在所有的预定、飞机、航班等方面是否真的存在不变量,只是为了创造一个预定?也就是说,如果在航班总数上增加了一架新飞机,是否应该在这一交易中包含客户和预定?可能不会,在这里所拥有的是一种聚合的聚合以及数据模型的便利,然而,事务的边界太大了,如果对航班、作为、预定等进行大量的更改,就会有巨大的事务冲突(无论是使用乐观的还是悲观的锁定都不重要),而且这显然没有规模(永远不要介意订单的不断下降,因为航班计划正在改变,这是一种糟糕的客户体验)。

如果打破了交易的界限,那就更小了。

也许预定、座椅可用性和航班是它们自己的独立集合,预定封装了客户信息、首选项和支付信息,Seat可利用聚合封装了飞机和飞机的配置,航班集合是由时间表、路线等组成的,但可以在不影响航班时刻表和飞机/座位可用性的情况下进行预定,从领域的角度看,希望能够做到这一点,不需要100%的严格一致性,但确实想要正确地记录飞行时间表的变化,如管理员,飞行的配置,以及客户的预定,那么,如何实现“在飞行上预定一个座位,”这样的事情呢?

在预定过程中,可能会呼叫座椅可用性集合,并要求它在飞机上预定一个作为,这个作为预定将被实现为一个单一的事务,例如(持有作为23A),并返回一个预定ID,可以将这个预定ID于预定联系起来,并且提交,知道这个座位是在一个“预定”的每一个(保留一个座位,并接受预定)都是单独的事务,并且可以独立地进行,而不需要任何两阶段提交或两阶段锁定。注意,这里使用“预定”是一个业务需求,不做座位分配,只保留座位,这个需求可能需要通过模型的迭代而被束缚,因为最初使用用例的语言可能只是简单地说“允许客户选择一个座位”,开发人员可以试着推新,这个需求意味着“从生育的座位中挑选,把它分配给客户,从库存中移除它,并且不出售比座位更多的票”。这将是额外的,不必要的不变量,这会给事务模型增加额外的负担,而业务模型实际上并不是不变的,在没有完全的座位分配情况下,这个业务当然可以接受预定,甚至是超额销售机票。


3.png



上图为一个示例,允许真正的域引导使用更小的、简化的、完全原子的事务边界来处理单个聚合,现在必须纠正这样一个事实:所有的个体交易都需要在某一时刻聚集在一起,数据的不同部分涉及到(例如,创建了一个预定和座位预定,但这些都不是通过固定的交易来获得登机牌/机票等)。

微服务如何跨边界通信

想要保持真正的业务 不变性,使用DDD可以选择将这些不变量建模为聚合,并使用单个事务进行聚合,在某些情况下,可以在单个事务中更新多聚合(跨单个数据或多个数据库),但这些场景可能是例外,仍然需要在聚合之间保持某种形式的一致性(最终在有界的上下文之间),那么应该怎么做呢?需要理解的一件事是:分布式系统是非常挑剔的,如果能在有限的时间内对分布式系统中的任何东西做出任何保证(事情将会失败,事情是不确定的,或者似乎失败了,系统有非同步的时间边界等等),那么为什么要尝试去解决它呢?如果接受并将其放入领域的一致性模型中会怎样呢?如果说“在必要的事务边界之间,可以与数据和域的其他部分进行协调,并在以后的某个时间点保持一致”?

正如一直说的,对于微服务,我们重视自主权,认为能够独立于其他系统(在可用性、协议、格式等方面)进行更改,时间的解耦和任何有限制的时间之间任何保证之间的任何保证,都允许真正实现这种自治(这不是计算机系统特有的,因此在事务边界和有界上线问之间,使用事件来保持一致性,事件是不可变的结构,它捕获了一个有趣的时间点,应该向对等点广播,同伴们会聆听它们感兴趣的事件,并根据这些数据做出的决定更新自己的数据等等。)

继续以订机票为例,当一个预定通过一个Acid风格的交易存储时,如何结束它?这是前面提到的“退票界”的背景,预定有界上下文将发布类似“New Booking创建”这样的事件,而票务绑定上下文将会消耗该事件,并继续与后端(可能是遗留的)票务系统进行交互,这显然需要某种集成和数据转换,这是Apache Camel非常擅长的。也引出了一些其他的问题,如何对数据库进行写操作,并以原子的方式将其发布到队列/消息传递设备中?

如果在事件之间有排序需求/因果需求呢?每个服务的一个数据库呢?

理想情况下,聚合会直接使用命令和域事件(作为第一个类公民,也就是说,)任何操作都是作为命令来实现的,任何响应都是作为对事件的响应来实现的)可以更清晰地映射使用内部上下文和上下文之间使用的事件之间关系,可以将事件(即Newbooking创建)发布到消息队列中,然后让侦听器从消息队列中使用该队列,并将其插入到数据库中,而无需使用Xa/2pc事务,而不需要将其插入到数据库中,可以将事件插入到一个专用的事件存储中,它就像数据库和消息发布-订阅主题一样(这可能是首选路由),或者可以继续使用一个ACID数据库,并将该数据库的变化流到一个持久的、复制的日志中,就像Apache卡夫卡一样,使用类似于Debezium的东西,并使用某种事件处理器来推断事件,无论哪种方式,关键是想要在时间事件中与不可变点之间的边界进行通信。


4.png



这带来了一些巨大的优势:

避免了跨边界且昂贵潜在的不可能的事务模型

可以对系统进行更改,而不妨碍系统的其他部分(时间和可用性)的进展

可以将数据存储在自己的数据库中,同时使用适合于服务的技术

可以在空闲时更改模式/数据库

变得更加可伸缩、容错、灵活

必须更加关注CAP定力和选择的技术来实现存储/队列

需要注意的是,这也有一些缺点:
更加复杂
难以调试
由于看到事件时有延迟,所以不能对其他系统所知道的内容作出任何假设
必须更加关注CAP定理和选择的技术来实现队列/存储

从这种方法中产生另一个有趣的概念是,能够实现一种称为“命令查询分离责任”的模式,在这种模式中,将读模型和编写模型分离到单独的服务中,请记住,我们对互联网公司没有非常复杂的领域模型感到遗憾,这在他们的编写模型中很明显(例如,在一个分布式日志中插入一条Tweet)。然而,他们的阅读模式因其规模而变得非常复杂,CQRS帮助分离了这些问题,另一方面,在企业中,编写模型可能非常复杂,而读取模型可能是简单的平面选择查询和扁平DTO对象,CQRS是一种强大的关注点隔离模式,一旦有了适当的边界和在聚集和有界上下文之间进行数据更改的好方法,就可以对其进行评估。

那么服务只有一个数据库,并且不与其他服务共享呢?在这个场景中,可能会侦听事件流的侦听器,并可能将数据插入到一个共享数据库中,而主聚合可能最终会使用这些数据,这个“共享数据库”非常好,记住,没有规则,只有权衡,在这种情况下,可能会有很多服务协同同一个数据库一起工作,只要团队拥有所有的过程,就不会否定自治的优势,当听到有人说“微服务应该有自己的数据库,而不是别人分享”时,你可以回答:好吧,有点。

打开数据库

如果将使用事件/流来进行所有的事情,并且永远的持久化这些事件呢?如果说数据库/缓存/索引实际上只是过去发生的事件的持久日志/流的物化视图,而当前状态是所有这些事件的左折叠?

这种方法带来了更多的好处,可以通过事件(上面列出的)来增加交流的好处:

现在可以将数据库看做是记录的:“当前状态”,而不是真正的纪录
可以引入新的应用,重新阅读过去的事件,并根据“将要发生的事情”来检查它们的行为
免费完善审计日志记录
可以引入应用的新版本,并通过重新播放事件对其执行非常详尽的测试
可以更容易地关于数据库版本/升级/模式变化的事件重演到新数据库中
可以迁移到全新的数据库技术(例如,可能发现已经超越了关系数据库,并且希望切换到专门的数据库/索引)


5.png


TM体系结构

当在aa.com、Delta.com或united.com上预定航班时,会看到其中的一些概念,当选择一个座位时,并没有实际地分配它。当订机票时,实际上并没有收到实体票,之后会收到一封电子邮件,通知已经被确认,你是否有过一次飞机换班的经历,并分配到一个不同的座位?或者是去登机口,听到工作人员要求放弃座位,因为机票已经超出预定座位,这些都是事务边界的例子,最终的一致性、补偿事务,甚至连工作中的道歉都属于。

Moral Of The Story

这里指的是:数据、数据集成、数据边界、企业使用模式、分布式系统理论、时间等等,都是微服务的难点(因为微服务是真正的分布式系统)在技术上看到了太多的困惑(“如果使用Spring引导,我正在做微服务”,“需要解决服务发现,在云计算之前负载均衡”,必须有一个每个微服务的数据库)和关于使用微服务的无用理论,别担心,因为一旦大的供应商来卖给你所有的高级产仍然需要做上面列出的那些困难部分。

原文作者:Software 原文链接:http://www.tuicool.com/articles/VnIvyyF

读完这19本经典,成为优秀架构师其实也不难

杨y 发表了文章 • 0 个评论 • 59 次浏览 • 2017-11-08 15:01 • 来自相关话题

[数人云|读完这19本经典,成为优秀架构师其实也不难]

数人云之前给大家分享了《成为“伟大”程序员需要学会的9种“姿势”》对于想转型成为架构师的童鞋们来说最急缺的是什么呢?当然是经验和实践案例,数人云今天精挑细选了19本架构师必读经典,想往这个方向发展的小伙伴千万不能错过。

软件架构已经成为每个软件项目的重要组成部分,在构建一个可靠的软件体系结构失,可以选择系统的重要部分,考虑这些部分如何组合在一起,并在设计这些系统时做出关键的决策,它是任何软件开发项目的基础。

高级开发和软件架构师之间存在着巨大的差异,作为一名架构师,需要更多的经验来设计最终的解决方案。

软件架构理论与实践同样重要,因此本文为软件开发团队和架构师推荐了一份今年最好的软件架构书籍列表,这些书籍对于理解并有效地应用软甲架构原则在实际的项目上非常有价值。

[数人云|读完这19本经典,成为优秀架构师其实也不难]

书名:《Beyond Software Architecture: Creating and Sustaining Winning Solutions》

作者:Luke Hohmann

本书为开发人员提供了可以使用的实用技术来提高生产力,通过几个合乎逻辑的章节,涵盖了典型的架构问题,例如:可移植性、可用性、性能、分层、API设计和安全性,以及其他有价值的材料注入业务和产品管理方面的软件架构,这是常常被忽略或者遗忘的,本书提供了关于现实世界中创建成功应用解决方案的宝贵简介和经验。

[数人云|读完这19本经典,成为优秀架构师其实也不难]

书名: 《Domain-Driven Design: Tackling Complexity in the Heart of Software》

作者:Eric Evans

这是一本很棒的书,关于如何让应用的设计与正在解决的问题领域模型相匹配,Eric认为,学习相关的问题领域要在项目结束时如同最初一样,所以重构是他技术的一个重要部分。

本书为读者提供了一种系统的领域驱动设计方法以及一套广泛的设计最佳实践,基于经验的技术和基本原则,促进面向复杂领域的软件项目开发,本书包含了许多基于实际项目的例子,用以说明域驱动设计在现实软件开发中的应用。

[数人云|读完这19本经典,成为优秀架构师其实也不难]

书名: 《97 Things Every Software Architect Should Know: Collective Wisdom from the Experts》

作者:Richard Monson-Haefel

在这本真正独特的技术书籍中,一些软件架构师在关键的开发问题上提出了一些宝贵的意见,这些意见已经超越了技术本身的价值。包括Neal Ford、Michael Nygard在内的40多位知名架构师,在本书中根据其自身经验让开发者了解如何消除复杂性,增强能力。像要成为一名成功的软件架构师,需要精通业务和技术,本书会告诉读者顶级架构师都认为哪些东西才是最重要的。

[数人云|读完这19本经典,成为优秀架构师其实也不难]

书名:《Enterprise Integration Patterns Designing, Bui**lding, and Deploying Messaging Solutions》

作者:Gregor Hohpe、Bobby Woolf

[数人云|读完这19本经典,成为优秀架构师其实也不难]

##书名:《Software Architecture in Practice 》

作者:Len Bass、Paul Clements、Rick Kazman

本书着重于软件体系结构中的关键主题:“ilities”、“Patterns/Styles”,记录体系结构和评估体系结构,作者分享他们自身的经验,涵盖了设计、制定和验证系统的基本技术主题,还强调了大型系统设计的业务上文的重要性。根据不同的案例研究,描述成功的软件架构是什么样的。

[数人云|读完这19本经典,成为优秀架构师其实也不难]

书名:《Design Patterns: Elements of Reusable Object-Oriented Software 》

作者:Erich Gamma、Ralph Johnson、John Vlissides、Richard Helm、Grady Booch

本书的作者们,对于面向对象软件的设计很有经验,为常见的设计问题提供了简单但又强大的解决方案,介绍了23种模式,允许设计人员创建更灵活、优雅、最终可重用的设计,而不必重新发现设计方案本身,通过本书,可以了解这些重要的模式如何适应软件开发过程,以及如何利用它们来最有效地解决设计问题。

[数人云|读完这19本经典,成为优秀架构师其实也不难]

书名: 《The Process of Software Architecting》

作者: Peter Eeles、Peter Cripps

任何成功的软件系统都离不开好的软件架构,有效地架构需要清楚地了解组织角色、工作、执行的活动,以及执行的最佳顺序。在本书中可以找到以下问题的答案,在典型的软件开发项目中,架构师处于什么角色?软件架构文档如何满足不同利益相关者的需求?可重用资产的适用性在设计的过程中,架构师的角色对于需求定义、体系结构的推导等等。

[数人云|读完这19本经典,成为优秀架构师其实也不难]

书名:《Just Enough Software Architecture: A Risk-Driven Approach》

作者:George H. Fairbanks

这是软件开发人员的实用指南,与其他软件架构书籍不同,它交到风险驱动的架构,本书旨在使架构与所有软件开发人员相关联,开发人员需要了解如何使用约束作为指导Rails来确保预期的结果,以及看似微笑的更改如何影响系统的属性。

本书会让读者清楚自己在做什么,除此之外,还强调工程学,提供了一些实用性的建议,软件设计决策影响体系结构,反之亦然,本书的方法通过描述具有不同抽象层次的模型,从架构到数据结构设计。

[数人云|读完这19本经典,成为优秀架构师其实也不难]

书名:《Software Architecture Patterns》

作者:Mark Richards

Mark Richards是一位经验丰富的软件架构师,其在应用、集成和企业架构方面具有相当大的成就,自1983年起,就活跃在软件行业,是o'reilly书籍和视频的作者和主持人。

任何应用程序或系统的成功都取决于使用的体系结构模式,通过描述体系结构的总体特征,这些模式不仅指导设计人员和开发人员如何设计组件,还决定了这些组件应该如何交互的方式,本书包含了基于几个体系结构和软件开发质量属性的每个模式分析,在本书中,读者可以看到更多关于分层架构、事件驱动架构、微内核体系结构、微服务体系结构、基于空间的体系结构等相关信息。

[数人云|读完这19本经典,成为优秀架构师其实也不难]

书名:《Continuous Delivery: Reliable Software Releases Through Build,Test,and Deployment Automation》

作者:Jez Humble、David Farley

将应用发布给用户通常是一个痛苦、危险和耗时的过程,本书阐述了使更高质量、有价值的功能向用户提供快速、增量交付的原则和技术实践,通过对构建、部署和测试过程的自动化,以及开发人员、测试人员和运维之间的协作,交付团队可以在几个小时的时间内发布变更,不管项目的规模大小,或代码库的复杂性。

Jez Humble首先提出了一个快速、可靠、低风险的交付过程基础,然后他们引入了部署管道,这是一个用于管理所有变更的自动化过程,从签入到发布,他们还讨论了支持持续交付所需的生态系统,从基础设施、数据和配置管理到治理,作者介绍了一些技术,包括自动化的基础设施管理和数据迁移,以及虚拟化的使用,对于每个人,他们回顾关键问题,确定最佳实践,并演示如何降低风险,覆盖范围包括:自动化建设的各个方面,集成、测试和部署软件,实现部署管道在团队和组织水平,改善合作开发人员、测试人员和运维团队之间的协作,逐步发展特性在大型的分布式团队,实施一个有效的配置管理策略,自动化验收测试,从分析到实现,测试能力和其他非功能性需求和实现部署的零宕机版本,此外,它们还讨论了如何管理基础设施,数据,组件和依赖关系以及如何导航风险管理、遵从性和审计。

[数人云|读完这19本经典,成为优秀架构师其实也不难]

书名:《 Scalability Rules: 50 Principles for Scaling Web Sites》

作者:Martin L. Abbott、Michael T. Fisher

对于任何处理在线业务的人来说,这都是必不可少的读物,本书确保了战略设计原则适用于日常挑战,它是设计和构建可伸缩系统的一个有洞察力的、实用指南。由于现代系统的复杂性,可伸缩性的考虑应该是体系结构和实现过程中不可或缺的一部分。

Martin L. Abbott、Michael T. Fisher将可伸缩性从“Black Art”转变为一套现实的、与技术无关的最佳实践,用于支持几乎任何环境中的超增长,包括前端和后端系统,对于架构师来说,他们提供了关于创建和评估设计的强有力新见解。对于开发人员,他们共享特定的技术来处理从数据库到状态的所有事情,对于管理者来说,他们在目标制定、决策制定和与技术团队的交互方面提供了宝贵的帮助,无论你的角色是什么,都可以为设定优先级和最大限度找到实际的利益指导。

[数人云|读完这19本经典,成为优秀架构师其实也不难]

书名:《Microservices vs Service-Oriented Architecture》

作者: Mark Richards

微服务架构近来获得了广泛的关注,它听起来很像面向服务的体系结构,这两种架构都专注于将大型单片应用程序拆分为小型独立服务的结合,并且都有简化开发的承诺,读者可以在本书中找到关键问题的答案:是什么让它们与众不同?微服务真的只是SOA做得对吗?这两种架构的不同之处以及微服务真的比SOA好吗?

[数人云|读完这19本经典,成为优秀架构师其实也不难]

书名:《Software Architecture: Foundations、Theory、and Practice》

作者: R. N. Taylor、N. Medvidovic、E. M. Dashofy

这是一本关于软件架构非常实用的书籍,但如果你不喜欢以“学术”风格写的书,这本书不适合你,软件架构是开发大型、实用的软件密集型应用程序的基础,本书不关注一种方法、代码、工具、或者过程,而是广泛地调查软件架构技术,当培训者和专业人员可以选择合适的工具来做手头的工作。

[数人云|读完这19本经典,成为优秀架构师其实也不难]

书名:《Essential Software Architecture》

作者:Ian Gorton

如今,软件行业充斥着“技术架构师”和“首席架构师”之类的职位,但许多人都觉得“架构”是专业软件开发中最被滥用和最不理解的术语之一,Gorton试图解决这一困境,它简明地描述了作为一个软件架构师所需要知识的基本要素和关键技能,这些解释好汉了架构思考、实践和支持技术的要点,它们从对结构和质量属性的一般理解,从中间件组件和面向服务的体系结构到最新的技术,如模型驱动的体系结构、软件产品线、面向方面的设计和语义Web,这些都影响了未来的软件系统。

[数人云|读完这19本经典,成为优秀架构师其实也不难]

书名:《Refactoring in Large Software Projects: Performing Complex Restructurings Successfully》

作者:Martin Lippert、Stephen Roock

重构是大型软件项目的一个重要主题,特别是在遵循敏捷方法的项目中,考虑到体系结构随着需求的变化而变化,它提供了真实重构项目的真实体验,并展示了如何重构软件以确保它是高效、新鲜和可适应的。

[数人云|读完这19本经典,成为优秀架构师其实也不难]

书名:《12 Essential Skills for Software Architects》

作者:Dave Hendricksen

对于许多开发人员来说,这些技能并不是与生俱来的,他们很少在正式的培训中得到解决问题的方案,现在,经验丰富的软件设计师Dave Hendricksen会帮助填补这一空白,让组织影响更大,并迅速转移到职业生涯的下一个层次,对于架构师来说,仅仅拥有技术技能是不够的,软件能同样重要的是作为一名架构师有效地生活,这本书对架构师所需要的12项技能进行了清晰而详细的讨论,如果你是一名开发者,并渴望成为一名叫架构师,本书会对你非技术技能有所帮助。

[数人云|读完这19本经典,成为优秀架构师其实也不难]

书名:《12 Essential Skills for Software Architects》

作者:Dave Hendricksen

对于许多开发人员来说,这些技能并不是与生俱来的,他们很少在正式的培训中得到解决问题的方案,现在,经验丰富的软件设计师Dave Hendricksen会帮助填补这一空白,让组织影响更大,并迅速转移到职业生涯的下一个层次,对于架构师来说,仅仅拥有技术技能是不够的,软件能同样重要的是作为一名架构师有效地生活,这本书对架构师所需要的12项技能进行了清晰而详细的讨论,如果你是一名开发者,并渴望成为一名叫架构师,本书会对你非技术技能有所帮助。

[数人云|读完这19本经典,成为优秀架构师其实也不难]

书名:《Reactive Design Patterns》

作者:Roland Kuhn Dr、Brian Hanafee、Jamie Allen

反应式设计模式,用于构建具有弹性、响应性的消息驱动分布式系统,本书中,读者可以得到消息传递、流控制、资源管理和并发性的模式以及类似于测试友好设计之类的实际问题解决方案,所有的模式都包括试用Scala和Akka的具体案例。

[数人云|读完这19本经典,成为优秀架构师其实也不难]

书名:《Object-Oriented Design Heuristics》

作者:Arthur J. Riel

最后一本书是关于“面向对象设计启发法”,这是一本优秀的面向对象开发手册,提供疼的基础经验指导方针,帮助开发人员做出正确的设计决策,本书为了解面向对象开发的基础知识的读者提供了下一步的目标,需要知道他们是否做对了,并做出正确的选择。

以上是小数给大家推荐的19本架构师必读书籍,当然学无止境,关于应用开发文档的另一个主要来源是GitHub,不仅可以找到关于架构方面的文档,还可以找到关于Docker、弹性搜索、TDD、DDD、BDD、CI等等。

原文作者: DZone 原文链接:https://www.tuicool.com/articles/Ijmyauq 查看全部

[数人云|读完这19本经典,成为优秀架构师其实也不难]

数人云之前给大家分享了《成为“伟大”程序员需要学会的9种“姿势”》对于想转型成为架构师的童鞋们来说最急缺的是什么呢?当然是经验和实践案例,数人云今天精挑细选了19本架构师必读经典,想往这个方向发展的小伙伴千万不能错过。

软件架构已经成为每个软件项目的重要组成部分,在构建一个可靠的软件体系结构失,可以选择系统的重要部分,考虑这些部分如何组合在一起,并在设计这些系统时做出关键的决策,它是任何软件开发项目的基础。

高级开发和软件架构师之间存在着巨大的差异,作为一名架构师,需要更多的经验来设计最终的解决方案。

软件架构理论与实践同样重要,因此本文为软件开发团队和架构师推荐了一份今年最好的软件架构书籍列表,这些书籍对于理解并有效地应用软甲架构原则在实际的项目上非常有价值。

[数人云|读完这19本经典,成为优秀架构师其实也不难]

书名:《Beyond Software Architecture: Creating and Sustaining Winning Solutions》

作者:Luke Hohmann

本书为开发人员提供了可以使用的实用技术来提高生产力,通过几个合乎逻辑的章节,涵盖了典型的架构问题,例如:可移植性、可用性、性能、分层、API设计和安全性,以及其他有价值的材料注入业务和产品管理方面的软件架构,这是常常被忽略或者遗忘的,本书提供了关于现实世界中创建成功应用解决方案的宝贵简介和经验。

[数人云|读完这19本经典,成为优秀架构师其实也不难]

书名: 《Domain-Driven Design: Tackling Complexity in the Heart of Software》

作者:Eric Evans

这是一本很棒的书,关于如何让应用的设计与正在解决的问题领域模型相匹配,Eric认为,学习相关的问题领域要在项目结束时如同最初一样,所以重构是他技术的一个重要部分。

本书为读者提供了一种系统的领域驱动设计方法以及一套广泛的设计最佳实践,基于经验的技术和基本原则,促进面向复杂领域的软件项目开发,本书包含了许多基于实际项目的例子,用以说明域驱动设计在现实软件开发中的应用。

[数人云|读完这19本经典,成为优秀架构师其实也不难]

书名: 《97 Things Every Software Architect Should Know: Collective Wisdom from the Experts》

作者:Richard Monson-Haefel

在这本真正独特的技术书籍中,一些软件架构师在关键的开发问题上提出了一些宝贵的意见,这些意见已经超越了技术本身的价值。包括Neal Ford、Michael Nygard在内的40多位知名架构师,在本书中根据其自身经验让开发者了解如何消除复杂性,增强能力。像要成为一名成功的软件架构师,需要精通业务和技术,本书会告诉读者顶级架构师都认为哪些东西才是最重要的。

[数人云|读完这19本经典,成为优秀架构师其实也不难]

书名:《Enterprise Integration Patterns Designing, Bui**lding, and Deploying Messaging Solutions》

作者:Gregor Hohpe、Bobby Woolf

[数人云|读完这19本经典,成为优秀架构师其实也不难]

##书名:《Software Architecture in Practice 》

作者:Len Bass、Paul Clements、Rick Kazman

本书着重于软件体系结构中的关键主题:“ilities”、“Patterns/Styles”,记录体系结构和评估体系结构,作者分享他们自身的经验,涵盖了设计、制定和验证系统的基本技术主题,还强调了大型系统设计的业务上文的重要性。根据不同的案例研究,描述成功的软件架构是什么样的。

[数人云|读完这19本经典,成为优秀架构师其实也不难]

书名:《Design Patterns: Elements of Reusable Object-Oriented Software 》

作者:Erich Gamma、Ralph Johnson、John Vlissides、Richard Helm、Grady Booch

本书的作者们,对于面向对象软件的设计很有经验,为常见的设计问题提供了简单但又强大的解决方案,介绍了23种模式,允许设计人员创建更灵活、优雅、最终可重用的设计,而不必重新发现设计方案本身,通过本书,可以了解这些重要的模式如何适应软件开发过程,以及如何利用它们来最有效地解决设计问题。

[数人云|读完这19本经典,成为优秀架构师其实也不难]

书名: 《The Process of Software Architecting》

作者: Peter Eeles、Peter Cripps

任何成功的软件系统都离不开好的软件架构,有效地架构需要清楚地了解组织角色、工作、执行的活动,以及执行的最佳顺序。在本书中可以找到以下问题的答案,在典型的软件开发项目中,架构师处于什么角色?软件架构文档如何满足不同利益相关者的需求?可重用资产的适用性在设计的过程中,架构师的角色对于需求定义、体系结构的推导等等。

[数人云|读完这19本经典,成为优秀架构师其实也不难]

书名:《Just Enough Software Architecture: A Risk-Driven Approach》

作者:George H. Fairbanks

这是软件开发人员的实用指南,与其他软件架构书籍不同,它交到风险驱动的架构,本书旨在使架构与所有软件开发人员相关联,开发人员需要了解如何使用约束作为指导Rails来确保预期的结果,以及看似微笑的更改如何影响系统的属性。

本书会让读者清楚自己在做什么,除此之外,还强调工程学,提供了一些实用性的建议,软件设计决策影响体系结构,反之亦然,本书的方法通过描述具有不同抽象层次的模型,从架构到数据结构设计。

[数人云|读完这19本经典,成为优秀架构师其实也不难]

书名:《Software Architecture Patterns》

作者:Mark Richards

Mark Richards是一位经验丰富的软件架构师,其在应用、集成和企业架构方面具有相当大的成就,自1983年起,就活跃在软件行业,是o'reilly书籍和视频的作者和主持人。

任何应用程序或系统的成功都取决于使用的体系结构模式,通过描述体系结构的总体特征,这些模式不仅指导设计人员和开发人员如何设计组件,还决定了这些组件应该如何交互的方式,本书包含了基于几个体系结构和软件开发质量属性的每个模式分析,在本书中,读者可以看到更多关于分层架构、事件驱动架构、微内核体系结构、微服务体系结构、基于空间的体系结构等相关信息。

[数人云|读完这19本经典,成为优秀架构师其实也不难]

书名:《Continuous Delivery: Reliable Software Releases Through Build,Test,and Deployment Automation》

作者:Jez Humble、David Farley

将应用发布给用户通常是一个痛苦、危险和耗时的过程,本书阐述了使更高质量、有价值的功能向用户提供快速、增量交付的原则和技术实践,通过对构建、部署和测试过程的自动化,以及开发人员、测试人员和运维之间的协作,交付团队可以在几个小时的时间内发布变更,不管项目的规模大小,或代码库的复杂性。

Jez Humble首先提出了一个快速、可靠、低风险的交付过程基础,然后他们引入了部署管道,这是一个用于管理所有变更的自动化过程,从签入到发布,他们还讨论了支持持续交付所需的生态系统,从基础设施、数据和配置管理到治理,作者介绍了一些技术,包括自动化的基础设施管理和数据迁移,以及虚拟化的使用,对于每个人,他们回顾关键问题,确定最佳实践,并演示如何降低风险,覆盖范围包括:自动化建设的各个方面,集成、测试和部署软件,实现部署管道在团队和组织水平,改善合作开发人员、测试人员和运维团队之间的协作,逐步发展特性在大型的分布式团队,实施一个有效的配置管理策略,自动化验收测试,从分析到实现,测试能力和其他非功能性需求和实现部署的零宕机版本,此外,它们还讨论了如何管理基础设施,数据,组件和依赖关系以及如何导航风险管理、遵从性和审计。

[数人云|读完这19本经典,成为优秀架构师其实也不难]

书名:《 Scalability Rules: 50 Principles for Scaling Web Sites》

作者:Martin L. Abbott、Michael T. Fisher

对于任何处理在线业务的人来说,这都是必不可少的读物,本书确保了战略设计原则适用于日常挑战,它是设计和构建可伸缩系统的一个有洞察力的、实用指南。由于现代系统的复杂性,可伸缩性的考虑应该是体系结构和实现过程中不可或缺的一部分。

Martin L. Abbott、Michael T. Fisher将可伸缩性从“Black Art”转变为一套现实的、与技术无关的最佳实践,用于支持几乎任何环境中的超增长,包括前端和后端系统,对于架构师来说,他们提供了关于创建和评估设计的强有力新见解。对于开发人员,他们共享特定的技术来处理从数据库到状态的所有事情,对于管理者来说,他们在目标制定、决策制定和与技术团队的交互方面提供了宝贵的帮助,无论你的角色是什么,都可以为设定优先级和最大限度找到实际的利益指导。

[数人云|读完这19本经典,成为优秀架构师其实也不难]

书名:《Microservices vs Service-Oriented Architecture》

作者: Mark Richards

微服务架构近来获得了广泛的关注,它听起来很像面向服务的体系结构,这两种架构都专注于将大型单片应用程序拆分为小型独立服务的结合,并且都有简化开发的承诺,读者可以在本书中找到关键问题的答案:是什么让它们与众不同?微服务真的只是SOA做得对吗?这两种架构的不同之处以及微服务真的比SOA好吗?

[数人云|读完这19本经典,成为优秀架构师其实也不难]

书名:《Software Architecture: Foundations、Theory、and Practice》

作者: R. N. Taylor、N. Medvidovic、E. M. Dashofy

这是一本关于软件架构非常实用的书籍,但如果你不喜欢以“学术”风格写的书,这本书不适合你,软件架构是开发大型、实用的软件密集型应用程序的基础,本书不关注一种方法、代码、工具、或者过程,而是广泛地调查软件架构技术,当培训者和专业人员可以选择合适的工具来做手头的工作。

[数人云|读完这19本经典,成为优秀架构师其实也不难]

书名:《Essential Software Architecture》

作者:Ian Gorton

如今,软件行业充斥着“技术架构师”和“首席架构师”之类的职位,但许多人都觉得“架构”是专业软件开发中最被滥用和最不理解的术语之一,Gorton试图解决这一困境,它简明地描述了作为一个软件架构师所需要知识的基本要素和关键技能,这些解释好汉了架构思考、实践和支持技术的要点,它们从对结构和质量属性的一般理解,从中间件组件和面向服务的体系结构到最新的技术,如模型驱动的体系结构、软件产品线、面向方面的设计和语义Web,这些都影响了未来的软件系统。

[数人云|读完这19本经典,成为优秀架构师其实也不难]

书名:《Refactoring in Large Software Projects: Performing Complex Restructurings Successfully》

作者:Martin Lippert、Stephen Roock

重构是大型软件项目的一个重要主题,特别是在遵循敏捷方法的项目中,考虑到体系结构随着需求的变化而变化,它提供了真实重构项目的真实体验,并展示了如何重构软件以确保它是高效、新鲜和可适应的。

[数人云|读完这19本经典,成为优秀架构师其实也不难]

书名:《12 Essential Skills for Software Architects》

作者:Dave Hendricksen

对于许多开发人员来说,这些技能并不是与生俱来的,他们很少在正式的培训中得到解决问题的方案,现在,经验丰富的软件设计师Dave Hendricksen会帮助填补这一空白,让组织影响更大,并迅速转移到职业生涯的下一个层次,对于架构师来说,仅仅拥有技术技能是不够的,软件能同样重要的是作为一名架构师有效地生活,这本书对架构师所需要的12项技能进行了清晰而详细的讨论,如果你是一名开发者,并渴望成为一名叫架构师,本书会对你非技术技能有所帮助。

[数人云|读完这19本经典,成为优秀架构师其实也不难]

书名:《12 Essential Skills for Software Architects》

作者:Dave Hendricksen

对于许多开发人员来说,这些技能并不是与生俱来的,他们很少在正式的培训中得到解决问题的方案,现在,经验丰富的软件设计师Dave Hendricksen会帮助填补这一空白,让组织影响更大,并迅速转移到职业生涯的下一个层次,对于架构师来说,仅仅拥有技术技能是不够的,软件能同样重要的是作为一名架构师有效地生活,这本书对架构师所需要的12项技能进行了清晰而详细的讨论,如果你是一名开发者,并渴望成为一名叫架构师,本书会对你非技术技能有所帮助。

[数人云|读完这19本经典,成为优秀架构师其实也不难]

书名:《Reactive Design Patterns》

作者:Roland Kuhn Dr、Brian Hanafee、Jamie Allen

反应式设计模式,用于构建具有弹性、响应性的消息驱动分布式系统,本书中,读者可以得到消息传递、流控制、资源管理和并发性的模式以及类似于测试友好设计之类的实际问题解决方案,所有的模式都包括试用Scala和Akka的具体案例。

[数人云|读完这19本经典,成为优秀架构师其实也不难]

书名:《Object-Oriented Design Heuristics》

作者:Arthur J. Riel

最后一本书是关于“面向对象设计启发法”,这是一本优秀的面向对象开发手册,提供疼的基础经验指导方针,帮助开发人员做出正确的设计决策,本书为了解面向对象开发的基础知识的读者提供了下一步的目标,需要知道他们是否做对了,并做出正确的选择。

以上是小数给大家推荐的19本架构师必读书籍,当然学无止境,关于应用开发文档的另一个主要来源是GitHub,不仅可以找到关于架构方面的文档,还可以找到关于Docker、弹性搜索、TDD、DDD、BDD、CI等等。

原文作者: DZone 原文链接:https://www.tuicool.com/articles/Ijmyauq

服务网格新生代Istio进化,与传统模式相较5大特性更助容器扩展

杨y 发表了文章 • 0 个评论 • 86 次浏览 • 2017-11-08 14:54 • 来自相关话题

关于Service Mesh,数人云之前给大家分享了敖小剑老师的《Qcon2017实录|Service Mesh:下一代微服务》那么它对于容器相比传统模式都有哪方面的优势呢?同作为Service Mesh的新生代,Istio v0.2都有哪些添加与改进?本文见分晓!
容器仍然是目前极度火热的话题,一些人称,通过容器他们正处于崛起的边缘,成为数据中心的主宰,另外一些人则认为容器只适用于云计算,还有一些人在耐心地等待着看容器是不是应用程序基础设施的SDN,一些权威人士在极力吹捧,但其实很少在生产中付诸实践。
通过一些研究和调查可以看到容器确实在吸引着人们的注意:
32%的公司每年花费50万美元或更多的资金用于容器技术的授权和使用费(Portworx的年度容器采用率调查)采用容器技术的公司在9个月内将其容器数量增加5倍(Datadog 8个令人惊讶的事实,关于Docker的采用。容器的密度为平均每台主机10个容器(Sys Docker 使用报告2017)2017年,Docker的使用率飙升至35%(2017年云计算报告)5%的企业希望采用容器来部署传统的网络托管应用服务(F5 Networks State of Application Delivery 2017)
如大多数的基础设施——无论是应用还是网络——在可预见的未来,容器都将与日常运行在大型机和Midranges Alike上的应用程序共存,这是应用基础设施最重要的转变,当WEB堆栈上升到主导地位时,它并没有消除Fat Client-Server应用程序,至少在一段时间内,它们是一同运行的。
然而,它所做的都是迫使我们改变这些应用的规模,WEB应用程序对网络及其服务器施加了巨大的压力,需要新的方式来扩展容量和确保可用性,使用容器来部署应用程序——特别是那些使用微服务体系结构的应用。
在容器化环境和传统WEB应用程序中使用的扩展模式之间存在着显著的差异。
 传统模式

无论在云端(公有云、私有云)还是数据中心,传统的模式都采用了相当标准的模式,它使用固定的“池”资源,配置和行为最终基于端口和IP地址。
负责实际扩展应用程序的软件(无论部署在特定的目的硬件和是COTS上)都是在一个相当独立的操作前提下执行的,从算法到可用的资源,所有的一切都是按照比例服务的。
同时也包括这些资源的状态,在传统的模式中,通常是扩展应用,跟踪资源的健康状况,并在不可用的情况下进行轮转。
传统的规模模式依赖于命令式的配置模式,并且只有很少的明显例外(如状态)变化是由配置事件驱动的,这意味着一个操作符或外部脚本已经发布了一个非常特定的命令——通过API、CLI或GUI——来更改配置。The Cloud Half-Step
当“自动扩展”的概念出现时,云计算开始影响这个模式,于大多数容器化的环境中,自动伸缩是传统模式和服务网格模式之间的一个半步,它融合了环境变化的概念,比如增加需求出发配置更改,比如添加或删除资源,然而,模式仍然是一个“推”模式,这意味着对规模负责的系统仍然必须被隐式地告知需要进行的更改。服务网格模式
容器的管理通常由一些外部系统实现,比如Kubernetes或Mesos或Open Shift,通过一个类似于容器集群的命令和控制中心的“主”控制器,它的职责是管理容器,并将其保存到最新的目录中。

对于给定服务(或应用程序)可用资源的“池”是动态的,很多东西都是由一个特定容器的实际寿命所做而成,但事实是,跟它们的前辈虚拟机的几周或者几个月的寿命相比,可能只有几分钟或几个小时。
这种速度是不可能手动进行跟踪了,这也是为什么服务注册中心存在的原因——为了保存一个实时列表,列出哪些资源可用,以及它们属于什么服务。
这是服务网格模式避免将应用程序和服务紧密耦合到IP地址和端口的原因之一,当然,它们仍然被使用,但波动性(以及网络属性的重要)要求应用程序和服务必须由其他东西来表示——比如标签。
然后,真个系统中的所有配置和行为都是基于这些标记的,它们与FQDNs很相似。

通过DNS映射到IP地址。
所有这些都导致了需要一个更加协作的操作前提,负责扩展容器化应用和服务的软件,与传统的模式有很大不同,它们的前提是“我需要其他服务的信息来决定,而我的目的可能在另一个地方”。
但是不能期望主控制器通知每一个更改的组件,这种集中式控制不考虑系统中的组件数量,记住,它不只是容器,除了用于监控和报告业务以及操作分析所需要的远程数据守护进程之外,还存在诸如服务和规则之类的构造,但扩展软件仍然需要,知道什么时候改变(或者资源转移)。
在服务网格模式中,更改是由其他地方发布的操作事件所驱动,扩展软件的职责是拉出这些更改并对它们进行操作,而不是通过脚本或人工操作来实现特定的配置更改。
这意味着更改必须与实现无关,更改不可能是特定的API调用或需要实现的命令,他们必须是“什么”而非“如何”。这是一种声明式的配置模式,而不是与传统的规模模式相关的命令式模式。
这就意味着:
这些变化对网络的流量产生了相当大的影响传统的模式可以被看做是一个交通信号灯系统

固定的配置限定方向路线预定义
另一方面,一个服务网格模式更类似于现代的交通管理系统:

基于实时条件的动态路径变量路线灵活
接受这个模式最困难的部分,从作者的个人经验来看,是在一个服务的设备中有多少移动的部件,这使得很难从一端(客户端),到另一端(应用程序)跟踪数据路径,服务于主控制器和服务注册中心的服务依赖于对路由请求的依赖,因为它们对于路由请求的重要性,就像ARP映射表在核心网络中路由数据包一样重要。
服务网格模式在那些采用容器的用户中获取了极大的兴趣和新引力,在墙的另一边,要了解它对网络的影响,并准备好管理它。Istio v0.2
Istio是Google/IBM/Lyft联合开发的开源项目,2017年5月发布第一个release 0.1.0, 官方定义为:
Istio:一个连接,管理和保护微服务的开放平台。
按照Isito文档中给出的定义:
Istio提供一种简单的方式来建立已部署的服务的网络,具备负载均衡,服务到服务认证,监控等等功能,而不需要改动任何服务代码。
——敖小剑《万字解读:Service Mesh服务网格新生代--Istio》
Istio v0.2添加很多新的功能以及改建,下面来谈一谈,Istio v0.2让人激动的5大改进:Automatic Sidecar Injection
对于自定义资源和初始化器的支持,Istio v0.2要求Kubernetes1.7.4或更新,如果集群中启用了I nitializer Alpha特性,建议安装Istio初始化器,它为所有想要的Istio管理的微服务部署注入了自动的Sidecar。IBM Bluemix容器服务集群在1.7.4或更新时自动运行,这与Istio初始化器很好地工作,由于仍然是Istio开发总体方案中的一个Alpha特性,所以建议谨慎使用。Traffic Management Improvement
在Istio v0.1中,用户可以使用Ingress路由规则来制定想要通过微服务进入的流量,现在,还可以使用e外出路由规则来制定想要从微服务中获得哪些类型的流量,以及服务可以与哪些外部服务进行通信,例如,用户可以轻松地配置服务,与IBM Cloud中的IBM Watson服务之一进行对话,从而为用户的服务提供人工智能功能。Improved Telemetry
作为Istio用户,无需做任何事情去启动各种度量或跟踪,这非常简便,用户可以部署微服务应用,让Istio进行管理,而不需要任何应用程序或部署。Yaml文件,Zipkin的跟踪为应用提供了详细的跟踪信息,Zipkin的进一步追踪让人可以深入到每一个请求中,以查看流量子啊服务网格中如何技术,如果用户更喜欢Jaeger,也提供支持。多环境支持
Istio的最初目标之一就是进行多环境的支持,在微服务体系结构中,无法要求所有的工作负载都在Kubernetes中运行,用户的一些应用程序可能在Kubernetes中运维,而另外一些可能在Docker Swarm或者VM中运行,在Istio v0.2中,引入了早期对VM的支持,并与一些更流行的服务发现系统进行了集成,Istio已经被扩展支持到其他运行时环境,这是让人兴奋的一件事。在Kubernetes环境中使用Kubectl与Istio进行交互
本文作者最喜欢的一项是Istio v0.2更新了配置的模式,并使用Kubernetes的自定义资源定义,这意味着用户现在可以在Kubernetes环境中使用Kubectl与Istio进行交互,如果有自动的Sidecar注入,在Kuberentes环境中与Istio互动时,就无需Istioctl了,当用户想要首都注入Sidecar或与诸如控制台和VM等多环境交互时,Istioctl就变得有用了。
原文作者:DevCentral 原文链接:https://www.tuicool.com/articles/uE3uyyV 查看全部
关于Service Mesh,数人云之前给大家分享了敖小剑老师的《Qcon2017实录|Service Mesh:下一代微服务》那么它对于容器相比传统模式都有哪方面的优势呢?同作为Service Mesh的新生代,Istio v0.2都有哪些添加与改进?本文见分晓!
容器仍然是目前极度火热的话题,一些人称,通过容器他们正处于崛起的边缘,成为数据中心的主宰,另外一些人则认为容器只适用于云计算,还有一些人在耐心地等待着看容器是不是应用程序基础设施的SDN,一些权威人士在极力吹捧,但其实很少在生产中付诸实践。
通过一些研究和调查可以看到容器确实在吸引着人们的注意:
  • 32%的公司每年花费50万美元或更多的资金用于容器技术的授权和使用费(Portworx的年度容器采用率调查)
  • 采用容器技术的公司在9个月内将其容器数量增加5倍(Datadog 8个令人惊讶的事实,关于Docker的采用。
  • 容器的密度为平均每台主机10个容器(Sys Docker 使用报告2017)
  • 2017年,Docker的使用率飙升至35%(2017年云计算报告)
  • 5%的企业希望采用容器来部署传统的网络托管应用服务(F5 Networks State of Application Delivery 2017)

如大多数的基础设施——无论是应用还是网络——在可预见的未来,容器都将与日常运行在大型机和Midranges Alike上的应用程序共存,这是应用基础设施最重要的转变,当WEB堆栈上升到主导地位时,它并没有消除Fat Client-Server应用程序,至少在一段时间内,它们是一同运行的。
然而,它所做的都是迫使我们改变这些应用的规模,WEB应用程序对网络及其服务器施加了巨大的压力,需要新的方式来扩展容量和确保可用性,使用容器来部署应用程序——特别是那些使用微服务体系结构的应用。
在容器化环境和传统WEB应用程序中使用的扩展模式之间存在着显著的差异。
 传统模式

无论在云端(公有云、私有云)还是数据中心,传统的模式都采用了相当标准的模式,它使用固定的“池”资源,配置和行为最终基于端口和IP地址。
负责实际扩展应用程序的软件(无论部署在特定的目的硬件和是COTS上)都是在一个相当独立的操作前提下执行的,从算法到可用的资源,所有的一切都是按照比例服务的。
同时也包括这些资源的状态,在传统的模式中,通常是扩展应用,跟踪资源的健康状况,并在不可用的情况下进行轮转。
传统的规模模式依赖于命令式的配置模式,并且只有很少的明显例外(如状态)变化是由配置事件驱动的,这意味着一个操作符或外部脚本已经发布了一个非常特定的命令——通过API、CLI或GUI——来更改配置。The Cloud Half-Step
当“自动扩展”的概念出现时,云计算开始影响这个模式,于大多数容器化的环境中,自动伸缩是传统模式和服务网格模式之间的一个半步,它融合了环境变化的概念,比如增加需求出发配置更改,比如添加或删除资源,然而,模式仍然是一个“推”模式,这意味着对规模负责的系统仍然必须被隐式地告知需要进行的更改。服务网格模式
容器的管理通常由一些外部系统实现,比如Kubernetes或Mesos或Open Shift,通过一个类似于容器集群的命令和控制中心的“主”控制器,它的职责是管理容器,并将其保存到最新的目录中。

对于给定服务(或应用程序)可用资源的“池”是动态的,很多东西都是由一个特定容器的实际寿命所做而成,但事实是,跟它们的前辈虚拟机的几周或者几个月的寿命相比,可能只有几分钟或几个小时。
这种速度是不可能手动进行跟踪了,这也是为什么服务注册中心存在的原因——为了保存一个实时列表,列出哪些资源可用,以及它们属于什么服务。
这是服务网格模式避免将应用程序和服务紧密耦合到IP地址和端口的原因之一,当然,它们仍然被使用,但波动性(以及网络属性的重要)要求应用程序和服务必须由其他东西来表示——比如标签。
然后,真个系统中的所有配置和行为都是基于这些标记的,它们与FQDNs很相似。

通过DNS映射到IP地址。
所有这些都导致了需要一个更加协作的操作前提,负责扩展容器化应用和服务的软件,与传统的模式有很大不同,它们的前提是“我需要其他服务的信息来决定,而我的目的可能在另一个地方”。
但是不能期望主控制器通知每一个更改的组件,这种集中式控制不考虑系统中的组件数量,记住,它不只是容器,除了用于监控和报告业务以及操作分析所需要的远程数据守护进程之外,还存在诸如服务和规则之类的构造,但扩展软件仍然需要,知道什么时候改变(或者资源转移)。
在服务网格模式中,更改是由其他地方发布的操作事件所驱动,扩展软件的职责是拉出这些更改并对它们进行操作,而不是通过脚本或人工操作来实现特定的配置更改。
这意味着更改必须与实现无关,更改不可能是特定的API调用或需要实现的命令,他们必须是“什么”而非“如何”。这是一种声明式的配置模式,而不是与传统的规模模式相关的命令式模式。
这就意味着:
  • 这些变化对网络的流量产生了相当大的影响
  • 传统的模式可以被看做是一个交通信号灯系统


  • 固定的配置
  • 限定方向
  • 路线预定义

另一方面,一个服务网格模式更类似于现代的交通管理系统:

  • 基于实时条件的动态
  • 路径变量
  • 路线灵活

接受这个模式最困难的部分,从作者的个人经验来看,是在一个服务的设备中有多少移动的部件,这使得很难从一端(客户端),到另一端(应用程序)跟踪数据路径,服务于主控制器和服务注册中心的服务依赖于对路由请求的依赖,因为它们对于路由请求的重要性,就像ARP映射表在核心网络中路由数据包一样重要。
服务网格模式在那些采用容器的用户中获取了极大的兴趣和新引力,在墙的另一边,要了解它对网络的影响,并准备好管理它。Istio v0.2

Istio是Google/IBM/Lyft联合开发的开源项目,2017年5月发布第一个release 0.1.0, 官方定义为:
Istio:一个连接,管理和保护微服务的开放平台。
按照Isito文档中给出的定义:
Istio提供一种简单的方式来建立已部署的服务的网络,具备负载均衡,服务到服务认证,监控等等功能,而不需要改动任何服务代码。


——敖小剑《万字解读:Service Mesh服务网格新生代--Istio》
Istio v0.2添加很多新的功能以及改建,下面来谈一谈,Istio v0.2让人激动的5大改进:Automatic Sidecar Injection
对于自定义资源和初始化器的支持,Istio v0.2要求Kubernetes1.7.4或更新,如果集群中启用了I nitializer Alpha特性,建议安装Istio初始化器,它为所有想要的Istio管理的微服务部署注入了自动的Sidecar。IBM Bluemix容器服务集群在1.7.4或更新时自动运行,这与Istio初始化器很好地工作,由于仍然是Istio开发总体方案中的一个Alpha特性,所以建议谨慎使用。Traffic Management Improvement
在Istio v0.1中,用户可以使用Ingress路由规则来制定想要通过微服务进入的流量,现在,还可以使用e外出路由规则来制定想要从微服务中获得哪些类型的流量,以及服务可以与哪些外部服务进行通信,例如,用户可以轻松地配置服务,与IBM Cloud中的IBM Watson服务之一进行对话,从而为用户的服务提供人工智能功能。Improved Telemetry
作为Istio用户,无需做任何事情去启动各种度量或跟踪,这非常简便,用户可以部署微服务应用,让Istio进行管理,而不需要任何应用程序或部署。Yaml文件,Zipkin的跟踪为应用提供了详细的跟踪信息,Zipkin的进一步追踪让人可以深入到每一个请求中,以查看流量子啊服务网格中如何技术,如果用户更喜欢Jaeger,也提供支持。多环境支持
Istio的最初目标之一就是进行多环境的支持,在微服务体系结构中,无法要求所有的工作负载都在Kubernetes中运行,用户的一些应用程序可能在Kubernetes中运维,而另外一些可能在Docker Swarm或者VM中运行,在Istio v0.2中,引入了早期对VM的支持,并与一些更流行的服务发现系统进行了集成,Istio已经被扩展支持到其他运行时环境,这是让人兴奋的一件事。在Kubernetes环境中使用Kubectl与Istio进行交互
本文作者最喜欢的一项是Istio v0.2更新了配置的模式,并使用Kubernetes的自定义资源定义,这意味着用户现在可以在Kubernetes环境中使用Kubectl与Istio进行交互,如果有自动的Sidecar注入,在Kuberentes环境中与Istio互动时,就无需Istioctl了,当用户想要首都注入Sidecar或与诸如控制台和VM等多环境交互时,Istioctl就变得有用了。
原文作者:DevCentral 原文链接:https://www.tuicool.com/articles/uE3uyyV

5位大咖同台论道,中西方微服务有何异同?(附PPT下载)

杨y 发表了文章 • 0 个评论 • 62 次浏览 • 2017-11-08 14:37 • 来自相关话题

11月4日[数人云](https://www.shurenyun.com/)与微软联合主办的 《论道云原生和微服务 剑指何方》在北京顺利举行

来自微软、数人云、EasyStack的五位技术大牛分别进行了分享,其中更有从美国赶来的微软Azure云容器技术的首席项目经理 Gabe Monroy、微软技术专家Rita,嘉宾们就Kubernetes、微服务、云原生等热点技术进行了深度剖析,为大家带来了一场精彩纷呈的技术盛宴。








△ 小伙伴们正聚精会神地听着分享

## Azure上运行Kubernetes








△ 微软Azure云容器技术的首席项目经理 Gabe Monroy



**分享内容**:主要分为五个方向——技术概览、容器服务、容器实例、用于Kubernetes的ACI Connector以及未来研发方向。

未来研发方向:
- 在Azure Stack上使用Kubernetes
- 服务代理:Azure Service Broker(ASB)

Kubernetes开发者工具集成
- Helm
- Draft
- Brigade


## 微服务道与术








△ 数人云资深架构师 敖小剑

**分享内容**:什么是Service Mesh、Service Mesh的演进路程、为何要选择Service Mesh。

**王者风范——Istio:**

为什么说Istio王者风范?最重要的是它为Service Mesh带来了前所未有的控制力。以Sidecar方式部署的Service Mesh控制了服务间所有的流量,只要能够控制Service Mesh就能够控制所有的流量,也就可以控制系统中的所有请求。为此Istio带来了一个集中式的控制面板,让你实现控制。

敖小剑老师在Qcon 2017也做了同一主题的演讲,相关实录请点击:[《Qcon2017实录|Service Mesh:下一代微服务》。](https://mp.weixin.qq.com/s%3F_ ... %23rd/)

## 微软Azure云助力微服务








△ 微软中国有限公司创新技术合作事业部技术顾问 赵文婧  

**分享内容**:微服务的演变过程、容器与微服务、Azure容器服务生态、持续集成和持续交付。

**集群和编排引擎:**

Cluster
- 由一组计算机节点组成,可以被看做一个单独的系统
- 由网络互联
- 用于高性能分布式计算

Orchestrators(Schedulers)
- 在一个集群中分配任务或分配容器
- 在服务或容器失效时重启
- 基于资源的消耗重新分配服务或者容器
- IaaS:网络 存储 负载均衡
- PaaS:发现 缩放 容错 监控 安全


## K8S与OpenStack融合支撑企业级微服务架构








△ EasyStack 容器架构师 王后明

**分享内容**:微服务架构基本概念、Kubernetes与微服务架构、Kubernetes与OpenStack融合支持微服务架构

**Kubernetes和OpenStack深度融合带来的收益:**

企业IT架构视角——

应用架构:
- 纷繁复杂的企业级应用架构:传统应用、云原生应用
- 无缝支撑全类型的应用

基础资源:
- 异构的私有云基础资源并存:容器、虚拟机、物理机
- 统一的编排、调度和管理

IT组织架构视角——

开发者:
- 提升应用系统架构设计和开发的灵活度和敏捷度

运维者:
- 降低异构的私有云基础设施的运维管理复杂度
- 统一的云平台运维管理

## ASB&Helm让应用部署变得更简单

△  微软技术专家 Rita 








分享内容:Service brokes、Helm、Demo。

为什么要开发 Azure Service Broker(ASB):

- 基于容器的数据服务
- 运维太困难和复杂
- 没有SLA

Azure 数据服务
- Strong operational characteristics
- 商业SLA

ASB在基于容器的应用和Azure数据服务之间建立了一个桥梁,提高开发者效率,降低运维复杂度。


下载PPT:http://dwz.cn/6OotWm 查看全部
11月4日[数人云](https://www.shurenyun.com/)与微软联合主办的 《论道云原生和微服务 剑指何方》在北京顺利举行

来自微软、数人云、EasyStack的五位技术大牛分别进行了分享,其中更有从美国赶来的微软Azure云容器技术的首席项目经理 Gabe Monroy、微软技术专家Rita,嘉宾们就Kubernetes、微服务、云原生等热点技术进行了深度剖析,为大家带来了一场精彩纷呈的技术盛宴。


1.png



△ 小伙伴们正聚精会神地听着分享

## Azure上运行Kubernetes



2.png


△ 微软Azure云容器技术的首席项目经理 Gabe Monroy



**分享内容**:主要分为五个方向——技术概览、容器服务、容器实例、用于Kubernetes的ACI Connector以及未来研发方向。

未来研发方向:
- 在Azure Stack上使用Kubernetes
- 服务代理:Azure Service Broker(ASB)

Kubernetes开发者工具集成
- Helm
- Draft
- Brigade


## 微服务道与术


3.png



△ 数人云资深架构师 敖小剑

**分享内容**:什么是Service Mesh、Service Mesh的演进路程、为何要选择Service Mesh。

**王者风范——Istio:**

为什么说Istio王者风范?最重要的是它为Service Mesh带来了前所未有的控制力。以Sidecar方式部署的Service Mesh控制了服务间所有的流量,只要能够控制Service Mesh就能够控制所有的流量,也就可以控制系统中的所有请求。为此Istio带来了一个集中式的控制面板,让你实现控制。

敖小剑老师在Qcon 2017也做了同一主题的演讲,相关实录请点击:[《Qcon2017实录|Service Mesh:下一代微服务》。](https://mp.weixin.qq.com/s%3F_ ... %23rd/)

## 微软Azure云助力微服务


4.png



△ 微软中国有限公司创新技术合作事业部技术顾问 赵文婧  

**分享内容**:微服务的演变过程、容器与微服务、Azure容器服务生态、持续集成和持续交付。

**集群和编排引擎:**

Cluster
- 由一组计算机节点组成,可以被看做一个单独的系统
- 由网络互联
- 用于高性能分布式计算

Orchestrators(Schedulers)
- 在一个集群中分配任务或分配容器
- 在服务或容器失效时重启
- 基于资源的消耗重新分配服务或者容器
- IaaS:网络 存储 负载均衡
- PaaS:发现 缩放 容错 监控 安全


## K8S与OpenStack融合支撑企业级微服务架构


5.png



△ EasyStack 容器架构师 王后明

**分享内容**:微服务架构基本概念、Kubernetes与微服务架构、Kubernetes与OpenStack融合支持微服务架构

**Kubernetes和OpenStack深度融合带来的收益:**

企业IT架构视角——

应用架构:
- 纷繁复杂的企业级应用架构:传统应用、云原生应用
- 无缝支撑全类型的应用

基础资源:
- 异构的私有云基础资源并存:容器、虚拟机、物理机
- 统一的编排、调度和管理

IT组织架构视角——

开发者:
- 提升应用系统架构设计和开发的灵活度和敏捷度

运维者:
- 降低异构的私有云基础设施的运维管理复杂度
- 统一的云平台运维管理

## ASB&Helm让应用部署变得更简单

△  微软技术专家 Rita 


6.png



分享内容:Service brokes、Helm、Demo。

为什么要开发 Azure Service Broker(ASB):

- 基于容器的数据服务
- 运维太困难和复杂
- 没有SLA

Azure 数据服务
- Strong operational characteristics
- 商业SLA

ASB在基于容器的应用和Azure数据服务之间建立了一个桥梁,提高开发者效率,降低运维复杂度。


下载PPT:http://dwz.cn/6OotWm

数人云PaaS Innovation 2017,重新定义PaaS进化

admin 发表了文章 • 0 个评论 • 137 次浏览 • 2017-10-11 17:50 • 来自相关话题

在这个数字化时代,互联网+以一种崭新的经济形态,改变着传统行业,并不断向传统行业延伸,构成传统企业新赛段的核心竞争力。它同时给传统的IT架构提出了新的挑战,新一代PaaS勇敢地接过接力棒, Docker、Kubernetes、微服务架构、DevOps理念、Mesos、服务网格等新的开源技术和理念层出不穷,不断革新,打破了传统PaaS僵局,为传统企业和商业继续积蓄能量。

不断成长的开源PaaS技术作为新的IT变革力量,改变了人们思考云计算的视角,带给市场和商业更多的技术和洞察。开源技术栈、服务框架和理念的不断出现和演进,打造了从业务需求、开发、交付到运维的一体化,真正实现业务应用的敏捷和弹性,从根本上提升IT生产效率、达成协作创新,加速IT的精益运营,向着更敏捷、更低成本、更智能的方向前进。

参会嘉宾








11月16日,由中国开源云联盟WG6容器工作组和数人云联合主办的“PaaS Innovation 2017,构建灵动新IT”技术盛宴将在北京青龙胡同一号发布厅举办。大会将邀请中科院院士、Google资深架构师、媒体记者、技术大牛,以及来自大型企事业单位、金融、能源、互联网等领域的客户代表齐聚一堂。共同探讨在这个被技术深度改变的时代,如何将IT技术与传统行业、新兴场景相结合,洞悉PaaS的进化与革新如何推动业务创新、企业发展,以及社会变革。

大会亮点








本次大会以“PaaS Innovation 2017,构建灵动新IT”为主题,在这里,与会者可以听到Google等巨头公司阐述应用弹性的真知灼见;探讨开源技术如何加入企业云化的PaaS应用;重磅权威发布企业级容器云技术的标准;分享金融、能源等不同行业PaaS落地实践;预见企业级云计算风口及发展脉络。

11月16日,让我们一起来见证PaaS Innovation!

独家售票平台【活动行】报名地址:http://www.huodongxing.com/event/8407438005800 查看全部


在这个数字化时代,互联网+以一种崭新的经济形态,改变着传统行业,并不断向传统行业延伸,构成传统企业新赛段的核心竞争力。它同时给传统的IT架构提出了新的挑战,新一代PaaS勇敢地接过接力棒, Docker、Kubernetes、微服务架构、DevOps理念、Mesos、服务网格等新的开源技术和理念层出不穷,不断革新,打破了传统PaaS僵局,为传统企业和商业继续积蓄能量。

不断成长的开源PaaS技术作为新的IT变革力量,改变了人们思考云计算的视角,带给市场和商业更多的技术和洞察。开源技术栈、服务框架和理念的不断出现和演进,打造了从业务需求、开发、交付到运维的一体化,真正实现业务应用的敏捷和弹性,从根本上提升IT生产效率、达成协作创新,加速IT的精益运营,向着更敏捷、更低成本、更智能的方向前进。

参会嘉宾


QQ图片20171011164035.png



11月16日,由中国开源云联盟WG6容器工作组和数人云联合主办的“PaaS Innovation 2017,构建灵动新IT”技术盛宴将在北京青龙胡同一号发布厅举办。大会将邀请中科院院士、Google资深架构师、媒体记者、技术大牛,以及来自大型企事业单位、金融、能源、互联网等领域的客户代表齐聚一堂。共同探讨在这个被技术深度改变的时代,如何将IT技术与传统行业、新兴场景相结合,洞悉PaaS的进化与革新如何推动业务创新、企业发展,以及社会变革。

大会亮点


QQ图片20171011164051.png



本次大会以“PaaS Innovation 2017,构建灵动新IT”为主题,在这里,与会者可以听到Google等巨头公司阐述应用弹性的真知灼见;探讨开源技术如何加入企业云化的PaaS应用;重磅权威发布企业级容器云技术的标准;分享金融、能源等不同行业PaaS落地实践;预见企业级云计算风口及发展脉络。

11月16日,让我们一起来见证PaaS Innovation!

独家售票平台【活动行】报名地址:http://www.huodongxing.com/event/8407438005800

企业级落地容器与DevOps,选用K8S都有哪些“姿势”

杨y 发表了文章 • 0 个评论 • 82 次浏览 • 2017-10-10 18:22 • 来自相关话题

作为时下最火热的热点词汇:Kubernetes,其拥有成熟的社区,大公司的背景等等获得了大部分人的认可,很多公司都在准备启用Kubernetes,但是你的企业真的准备好了去采用Kubernetes这项技术吗? 数人云今天给大家分享的本篇文章将从源头——容器入手,逐步分析选择Kubernetes所需要的思考及准备。

什么是容器?K8S适合在哪?需要什么工具去实现?

容器的使用比例正在迅速增长,开发商热爱它,企业也以前所未有的热情去拥抱它。

如果你的IT部门正在寻求一种更快,更简单的方法去进行应用开发,那么容器技术正好可以满足需求,但什么是容器呢?它们都会处理哪些问题?Kubernetes是否适用于容器和集群管理空间?为什么要向企业展示实施挑战?在探索容器和集群管理工具是否适合应用开发需求时,应考虑哪些因素?

以下是每个企业需要了解容器、容器集群管理、Kubernetes的优缺点以及如何从Kubernetes实现中获得最大利益的一些要点。

容器及其解决的问题

当应用开发人员进行测试时,必须确保在从一个计算环境移动到另一个计算环境时能够可靠得运行,这可能来自于从一个登台环境到生产环境,或者从一个前期服务器到云中的虚拟机,这产生的问题就是,不同的环境很少是共生的,软件可能不同,但网络和安全环境几乎不可能相同。

容器通过将组成的开发环境所有东西打包成一个包去解决这个问题,这引入了环境一致性的级别,并允许开发人员以相同的方式快速、可靠得部署应用程序,而不管部署环境如何,通过对应用平台及其依赖关系的容器化,操作系统分布和底层基础结构的差异被抽象出来了,事实上,使用容器,就可以忘记所有的基础设施。

模块化的、可执行的应用包应用,容器包括需要运行一个应用的每个元素——从代码到设置,这种可移植性使容器成为组织思考多云策略的重要资产。

容器还可以帮主准备适当的DevOps实现及高效、快速交付的目标,使用容器,可以更新和升级且不需要从每次开始的遗留问题,这也多亏了容器,在现有系统中实现新的应用和效率并不像想象的那么难。

最近的一项调查显示,在过去的12个月里,94%的受访者曾调研或正在使用比虚拟机更轻,资源更少的容器技术。

正在引领容器技术的公司

Docker现在是主流的容器技术,已经有了成熟的技术栈,强大的开源生态系统,且与任何平台的高强度兼容性,以及最主要的机遇和运气。Docker已经远远超越了曾经的对手——rkt,OpenVZ和LXC,与底层基础设施不可变和独立,让Docker在开发者机器上运行的方式与在生产环境中是一样的。

容器管理工具如何有效的管理容器

为了有效得实现DevOps方法,在企业级应用开发和有效管理容器技术和平台,需要合适的工具。

这就是容器集群管理或容器编排解决方案发挥作用的地方,随着企业将容器的使用扩展到生产中,问题出现在管理哪些容器运行在哪里,如何处理所有的这些容器,以及确保跨宿主的容器之间的简化通信,这些容器被称之为“集群”。

容器集群管理工具提供了一个企业框架,用于在大规模上集成和管理容器,并确保在实践DevOps时保持必要的连续性,基本上,它们可以帮助您定义初始容器部署,同时在后台处理关键的IT功能,如可用性、伸缩性和网络——所有这些都是Streamlined、标准化和统一的。

Kubernetes如何助力DevOps

根据Gartner最近的一项调查显示,大约50%的受访者计划在2017年年底前实施持续交付和DevOps,以便更快、更频繁、更可靠得提供服务,Puppet Labs发布的DevOps报告显示,专注于自动化和DevOps的高性能企业能够减少它们的交付和变更时间,因为它们提供的服务改变了4440个,并且增加了46倍的服务。这些结果帮助DevOps采用了一种主流的企业IT现象,因此,今天我们在几乎所有的行业和公司规模上都看到了DevOps的采用。

尽管DevOps的快速采用有许多驱动因素,但在技术方面,容器在提高所有团队的自动化程度方面发挥了关键性作用,由于Linux容器的简单性、可用性和可移植性,曾经为高度工程关注的组织保留的自动化技术现在已经变得可用了。

容器提供了标准的打包格式和运行时,无论应用是如何架构、配置和在容器内运行,都可以运行任何应用,标准化是一个操作系统、中间件、数据库和其他组建的长期标准操作环境(SOE)项目的目标,实际上已经变成了今天的容器,因此本文坐着看来,这是DevOps人气的主要转折点。

尽管容器可以提供标准化,但容器不能解决的是实现持续交付和DevOps所倡导的其他原则所需的端到端自动化,容器提供坚实的标准地面,然而,自动化的过程应该在它之上,以使更快的服务交付。

Kubernetes是在Googer的15年以上容器经验中诞生的,作为一个精心策划的框架,被创建并捐赠给社区,容器的自动化部署和管理基础设施无论使用如虚拟化服务器的基础设施,私有云或公有云等,在GitHub上,Kubernetes已经成为了最活跃的开放源码项目之一,有上千万的贡献者和数以百计的供应商。

虽然Kubernetes不提供完整的连续交付自动化,但它提供了比容器提供的坚实基础更高的起点,在容器中运行容器的许多操作复杂性已经通过编排框架来解决,尽管Kubernetes仍然需要团队在其上面构建一个端到端的自动化流程,但它确实提供了许多现成的模块,帮助用户构建一个定制的自动化流程,以进行持续交付。

哪些企业容器集群管理解决方案可用

对于容器集群管理有多种选择,然而Kubernetes现在比较火热,称为最广泛的开源解决方案,经过15年的Google研发,以及令人羡慕的开源社区(包括红帽、Canonical、CoreOS和微软),Kuberentes的成熟速度比市场上任何其他产品都要快。

Kubernetes为容器集群管理提供了一个很好的选择,因为它为开发者提供了一种工具,可以快速高效地响应客户需求,同时减轻云中的运行应用负担。通过消除与部署和伸缩您的容器应用相关的许多手工任务,以便在从一个环境移动到另一个环境时更可靠得运行应用,例如:可以调度并将任意数量的容器部署到节点集群(在公共、私有或混合云中)。然后Kubernetes扶着管理这些工作负载,让其执行意愿。

由于Kubernetes,容器任务被简化,包括部署操作(水平自动伸缩、滚动更新、金丝雀部署)和管理(监视资源、应用健康检查、调试应用等)。

Kubernetes的门槛

尽管Kubernetes有很多优势,但正如之前讨论过的,在选择最好的Kubernetes管理平台时,其仍然相对难以设置和使用,管理Kubernetes是一个耗时的过程,需要高技能的员工和一个潜在的巨大的货币承诺,对于没有经过培训的人员来说,Kubernetes似乎可以在数小时或数天内运行,但在生产环境中,需要额外的功能——安全性、高可用性、灾难恢复、备份和维护——所有需要让Kubernetes生产“准备就绪”的一切都是如此。

其结果是,那些应用了Kubernetes的企业很快就意识到,他们无法在不引入技术和昂贵外部资源的情况下交付它。

那么,有什么选择呢?答案在于Kubernetes的管理工具,为了简化企业的Kubernetes管理,即使你的系统是刚性的,流行的解决方案包括构造,红帽的开放移动容器平台,Rancher,andKublr。

如何选择正确的Kubernetes管理平台

当为企业选择Kubernetes管理平台时,有很多事情需要考虑,包括:

产品准备就绪:它是否提供了您需要完全自动化的Kubernetes配置的特性,没有配置麻烦?是否具有企业级的安全特性?它会自动处理集群中的所有管理任务吗?它是否为您的应用程序提供高可用性、可伸缩性和自愈性?

未来准备就绪:平台是否支持多云策略?尽管Kubernetes允许在任何地方运行应用且不需要使它们适应新的托管环境,但要确保Kubernetes管理平台能够支持这些功能,以便在将来需要时可以进行配置。

易于管理:是否包含自动化的智能监控和警报?是否消除了分析Kubernetes原始数据的问题,以便对系统状态、错误、事件和告警有一个单一的窗格视图。

支持和培训:当企业准备应用容器化战略时,Kuernetes管理平台提供商是否向企业保证24X7的支持以及培训?

在所有可用的选择中,只有少数的一些公司,如Kublr支持了这些选项。加速和简化了Kubernetes的建立和管理,提供自愈的自动伸缩解决方案,可以将遗留系统引入到单个引擎的云上,同时可以在后台无缝得维护、重建或替换它们,模块之间的动态、灵活性和不匹配的透明性,是一种双赢。

如何选择正确的Kubernetes管理平台供应商

当思考和计划Kubernetes企业战略时,要明确自己在前进道路上的障碍,以及对Kubernetes的挑战和误解,找出应当在Kubernetes平台上寻找什么,花点时间做一个Kubernetes平台的比较,最后,看看自动化工具如何能够提供生产准备(最重要的特性)、未来准备、易于管理和支持需要使用Kubernetes。

以上是小数今天分享的文章,给想采用Kubernetes的企业供以参考,希望对大家有所帮助。

原文作者:Kublr Team

原文链接:http://www.tuicool.com/articles/jUjENrZ 查看全部

作为时下最火热的热点词汇:Kubernetes,其拥有成熟的社区,大公司的背景等等获得了大部分人的认可,很多公司都在准备启用Kubernetes,但是你的企业真的准备好了去采用Kubernetes这项技术吗? 数人云今天给大家分享的本篇文章将从源头——容器入手,逐步分析选择Kubernetes所需要的思考及准备。

什么是容器?K8S适合在哪?需要什么工具去实现?

容器的使用比例正在迅速增长,开发商热爱它,企业也以前所未有的热情去拥抱它。

如果你的IT部门正在寻求一种更快,更简单的方法去进行应用开发,那么容器技术正好可以满足需求,但什么是容器呢?它们都会处理哪些问题?Kubernetes是否适用于容器和集群管理空间?为什么要向企业展示实施挑战?在探索容器和集群管理工具是否适合应用开发需求时,应考虑哪些因素?

以下是每个企业需要了解容器、容器集群管理、Kubernetes的优缺点以及如何从Kubernetes实现中获得最大利益的一些要点。

容器及其解决的问题

当应用开发人员进行测试时,必须确保在从一个计算环境移动到另一个计算环境时能够可靠得运行,这可能来自于从一个登台环境到生产环境,或者从一个前期服务器到云中的虚拟机,这产生的问题就是,不同的环境很少是共生的,软件可能不同,但网络和安全环境几乎不可能相同。

容器通过将组成的开发环境所有东西打包成一个包去解决这个问题,这引入了环境一致性的级别,并允许开发人员以相同的方式快速、可靠得部署应用程序,而不管部署环境如何,通过对应用平台及其依赖关系的容器化,操作系统分布和底层基础结构的差异被抽象出来了,事实上,使用容器,就可以忘记所有的基础设施。

模块化的、可执行的应用包应用,容器包括需要运行一个应用的每个元素——从代码到设置,这种可移植性使容器成为组织思考多云策略的重要资产。

容器还可以帮主准备适当的DevOps实现及高效、快速交付的目标,使用容器,可以更新和升级且不需要从每次开始的遗留问题,这也多亏了容器,在现有系统中实现新的应用和效率并不像想象的那么难。

最近的一项调查显示,在过去的12个月里,94%的受访者曾调研或正在使用比虚拟机更轻,资源更少的容器技术。

正在引领容器技术的公司

Docker现在是主流的容器技术,已经有了成熟的技术栈,强大的开源生态系统,且与任何平台的高强度兼容性,以及最主要的机遇和运气。Docker已经远远超越了曾经的对手——rkt,OpenVZ和LXC,与底层基础设施不可变和独立,让Docker在开发者机器上运行的方式与在生产环境中是一样的。

容器管理工具如何有效的管理容器

为了有效得实现DevOps方法,在企业级应用开发和有效管理容器技术和平台,需要合适的工具。

这就是容器集群管理或容器编排解决方案发挥作用的地方,随着企业将容器的使用扩展到生产中,问题出现在管理哪些容器运行在哪里,如何处理所有的这些容器,以及确保跨宿主的容器之间的简化通信,这些容器被称之为“集群”。

容器集群管理工具提供了一个企业框架,用于在大规模上集成和管理容器,并确保在实践DevOps时保持必要的连续性,基本上,它们可以帮助您定义初始容器部署,同时在后台处理关键的IT功能,如可用性、伸缩性和网络——所有这些都是Streamlined、标准化和统一的。

Kubernetes如何助力DevOps

根据Gartner最近的一项调查显示,大约50%的受访者计划在2017年年底前实施持续交付和DevOps,以便更快、更频繁、更可靠得提供服务,Puppet Labs发布的DevOps报告显示,专注于自动化和DevOps的高性能企业能够减少它们的交付和变更时间,因为它们提供的服务改变了4440个,并且增加了46倍的服务。这些结果帮助DevOps采用了一种主流的企业IT现象,因此,今天我们在几乎所有的行业和公司规模上都看到了DevOps的采用。

尽管DevOps的快速采用有许多驱动因素,但在技术方面,容器在提高所有团队的自动化程度方面发挥了关键性作用,由于Linux容器的简单性、可用性和可移植性,曾经为高度工程关注的组织保留的自动化技术现在已经变得可用了。

容器提供了标准的打包格式和运行时,无论应用是如何架构、配置和在容器内运行,都可以运行任何应用,标准化是一个操作系统、中间件、数据库和其他组建的长期标准操作环境(SOE)项目的目标,实际上已经变成了今天的容器,因此本文坐着看来,这是DevOps人气的主要转折点。

尽管容器可以提供标准化,但容器不能解决的是实现持续交付和DevOps所倡导的其他原则所需的端到端自动化,容器提供坚实的标准地面,然而,自动化的过程应该在它之上,以使更快的服务交付。

Kubernetes是在Googer的15年以上容器经验中诞生的,作为一个精心策划的框架,被创建并捐赠给社区,容器的自动化部署和管理基础设施无论使用如虚拟化服务器的基础设施,私有云或公有云等,在GitHub上,Kubernetes已经成为了最活跃的开放源码项目之一,有上千万的贡献者和数以百计的供应商。

虽然Kubernetes不提供完整的连续交付自动化,但它提供了比容器提供的坚实基础更高的起点,在容器中运行容器的许多操作复杂性已经通过编排框架来解决,尽管Kubernetes仍然需要团队在其上面构建一个端到端的自动化流程,但它确实提供了许多现成的模块,帮助用户构建一个定制的自动化流程,以进行持续交付。

哪些企业容器集群管理解决方案可用

对于容器集群管理有多种选择,然而Kubernetes现在比较火热,称为最广泛的开源解决方案,经过15年的Google研发,以及令人羡慕的开源社区(包括红帽、Canonical、CoreOS和微软),Kuberentes的成熟速度比市场上任何其他产品都要快。

Kubernetes为容器集群管理提供了一个很好的选择,因为它为开发者提供了一种工具,可以快速高效地响应客户需求,同时减轻云中的运行应用负担。通过消除与部署和伸缩您的容器应用相关的许多手工任务,以便在从一个环境移动到另一个环境时更可靠得运行应用,例如:可以调度并将任意数量的容器部署到节点集群(在公共、私有或混合云中)。然后Kubernetes扶着管理这些工作负载,让其执行意愿。

由于Kubernetes,容器任务被简化,包括部署操作(水平自动伸缩、滚动更新、金丝雀部署)和管理(监视资源、应用健康检查、调试应用等)。

Kubernetes的门槛

尽管Kubernetes有很多优势,但正如之前讨论过的,在选择最好的Kubernetes管理平台时,其仍然相对难以设置和使用,管理Kubernetes是一个耗时的过程,需要高技能的员工和一个潜在的巨大的货币承诺,对于没有经过培训的人员来说,Kubernetes似乎可以在数小时或数天内运行,但在生产环境中,需要额外的功能——安全性、高可用性、灾难恢复、备份和维护——所有需要让Kubernetes生产“准备就绪”的一切都是如此。

其结果是,那些应用了Kubernetes的企业很快就意识到,他们无法在不引入技术和昂贵外部资源的情况下交付它。

那么,有什么选择呢?答案在于Kubernetes的管理工具,为了简化企业的Kubernetes管理,即使你的系统是刚性的,流行的解决方案包括构造,红帽的开放移动容器平台,Rancher,andKublr。

如何选择正确的Kubernetes管理平台

当为企业选择Kubernetes管理平台时,有很多事情需要考虑,包括:

产品准备就绪:它是否提供了您需要完全自动化的Kubernetes配置的特性,没有配置麻烦?是否具有企业级的安全特性?它会自动处理集群中的所有管理任务吗?它是否为您的应用程序提供高可用性、可伸缩性和自愈性?

未来准备就绪:平台是否支持多云策略?尽管Kubernetes允许在任何地方运行应用且不需要使它们适应新的托管环境,但要确保Kubernetes管理平台能够支持这些功能,以便在将来需要时可以进行配置。

易于管理:是否包含自动化的智能监控和警报?是否消除了分析Kubernetes原始数据的问题,以便对系统状态、错误、事件和告警有一个单一的窗格视图。

支持和培训:当企业准备应用容器化战略时,Kuernetes管理平台提供商是否向企业保证24X7的支持以及培训?

在所有可用的选择中,只有少数的一些公司,如Kublr支持了这些选项。加速和简化了Kubernetes的建立和管理,提供自愈的自动伸缩解决方案,可以将遗留系统引入到单个引擎的云上,同时可以在后台无缝得维护、重建或替换它们,模块之间的动态、灵活性和不匹配的透明性,是一种双赢。

如何选择正确的Kubernetes管理平台供应商

当思考和计划Kubernetes企业战略时,要明确自己在前进道路上的障碍,以及对Kubernetes的挑战和误解,找出应当在Kubernetes平台上寻找什么,花点时间做一个Kubernetes平台的比较,最后,看看自动化工具如何能够提供生产准备(最重要的特性)、未来准备、易于管理和支持需要使用Kubernetes。

以上是小数今天分享的文章,给想采用Kubernetes的企业供以参考,希望对大家有所帮助。

原文作者:Kublr Team

原文链接:http://www.tuicool.com/articles/jUjENrZ

使微服务、容器趋向完美——Serverless架构你应当知道的二三事

杨y 发表了文章 • 0 个评论 • 122 次浏览 • 2017-10-09 19:02 • 来自相关话题

无服务架构(Serverless)和DevOps、SRE、微服务、容器等一样,是最近两年比较新兴的概念,数人云之前给大家分享过《Serverless用这5大优势,挽救了后来7亿用户的Instagram》,今天再来探讨下Serverless和容器与微服务之间的互补与碰撞。

近年来很多人在讨论云计算时都会提到容器,因为其几乎完美得解决了DevOps所面临的挑战。

本文将阐述Serverless的解决方案,它与传统和容器化的应用的不同之处。








一个典型的N层Web应用是由前端、公开的Web服务器组成;后端:高度隔离的数据层以及中间件层。

微服务

先来说说微服务,在微服务的模式下,可以无需使用服务器去呈现所有的用户界面,例如,处理所有的业务对象和逻辑,只需一个应用即可创建多个应用编程接口或API。








这是以酒店为应用场景的一种基于微服务的现代WEB和移动应用的方法。

假设经营了一家连锁酒店,需要面向公众的服务,允许用户登录到网站预定房间,通过第三方邮件列表进行邮件促销,以及提供WEB和移动应用页面的一般方式。

可以创建处理用户数据请求的API,这里用白色显示,与其拥有传统的服务器呈现的用户界面,还可以创建单个页面WEB应用和使用该API的移动应用,以获取所需的信息去适应该平台的方式提供信息。

这使得作者的工作量去除了整个开发链:设计人员和前端开发人员可以让界面看起来更漂亮,并且能够高效得执行,而后端团队只需要专注于创建一个单一的方法去为他们提供相同的信息。








只需要将代码和其依赖项打包到一个容器中,然后即可在任何地方运行——因为它们通常很小,可以将大量的容器装到一台机器上——TechCrunch。

容器

从业务的角度讲,能有什么原因不喜欢容器呢?答案是,没有。

容器之所以伟大,是因为它们可以让我们打包所有的东西——操作系统、代码、服务、以及应用需要工作的所有东西并且运行它们。这不仅显著得简化了DevOps模式,节约了大量的人工和时间的成本,而且它还为我们提供了如何部署解决方案的选项,其中许多现在都是免费的特定供应商。

另外,正如TechCrunch所指出的,可以在一台主机上运行几个容器,这意味着浪费的资源要少的多,反过来又浪费了成本。

所以可以用容器来提供这些微服务,也就是说,用户接口API可以在容器A中运行,而在容器B中预定API,以及在容器C中的电子邮件通讯API,容器D中的身份验证API。

容器使得上面所提到的具有高度可移植性,如果构建的得当,高度可伸缩,甚至可以很好得适应Bug。

DevOps和容器

从DevOps的角度去看,仍旧是没有理由不喜欢容器技术。其具有的优势有:

可快速地进行部署。
在一些基本配置中,可以安装所需的应用和服务,配置环境以及支持应用,并未整个流程编写脚本。
技术团队无需花费一整天的时间去创建新的环境:脚本一次就完成了。
运维的成本降低。

如果应用被适当得设计成可伸缩的需求,那么使用容器的扩展就像启动应用镜像的另一个实例一样简单,甚至可以自动化这个过程,应用可以响应时需求和规模来满足需求。

更为重要的是,可以自动化构建和部署过程,容器在自动化的构建过程和应用生命周期管理中非常有用。

可以轻松得使用容器简化版本和构建过程,所有的这些都很容易通过开源或低成本工具以及过程进行编排。

容器的不足之处

容器也有一些不足之处,因为容器化仍然是一项新技术,所以会有很多变化。不用担心Docker或Mesosphere会很快消失,但它们可能会发生重大的变化,对于在部署管道中管理容器镜像的最佳实践,还没有达成共识。

根据其特性,容器需要在客户机器上具有更高的权限,若成功利用这一点,就会让它们更加危险,例如:一台虚拟机在客户服务器上被破坏。

也很容易得到比需要的容器更多的容器以及曾经执行一些工作负载的孤立容器:它们已经失效,但没有被清理掉。

有一些研究表明,在所有基于云计算的虚拟机中,有四分之一到三分之一都是僵尸的,而容器也遇到了同样的问题,因为容器可以快速且轻而易举的创建,并且在很大程度上是为了处理一次性的工作负载而设计,所以这方面是存在着很大的隐患。

大多数容器都需要外部程序集——即“助手”应用,使用它们的主要应用能够运行,当容器从镜像中创建时,很难确保这些程序集所在的存储库是联机的,并且可以遇到容器对这些程序集的依赖可能会被破坏的情况。

最后,使用某些容器技术(如Docker)进行安全高效得网络连接,需要熟练的人手。

Serverless

Serverless在此基础上应用而生,可以消除几乎所有的问题和以及传统基础设施和容器上存在的大部分问题。

需要明确的一点是,无服务架构(Serverless)并不意味着没有任何服务器去运行代码。

Serverless是无需管理服务器,只需要关注代码,而提供者将处理其余的部分。

像所有的流行技术一样,Serverless有一些变化的定义,这取决于说的是谁,但在供应商的角度,核心概念是相同的:

Serverless计算提供了以通用的匿名操作系统,代码将会在其中运行,下文将进行详解。
这些实例由云提供应用完全管理,会做所有的补丁、调优、服务安装等等。只需要编写运行在此服务上的代码,而云提供应用将确保代码在该环境中运行。
每个匿名且通用的环境只在需要时提供,当不再需要代码时,该环境就会被减少。
最后,只需要为代码实际使用付费:代码被执行的次数以及所需的计算资源的数量。

微服务和Serverless

但如果所有这些相对简单的任务或微服务将它们组成一个解决方案继续进行交付,就如果它们是整个服务器应用一样,又有什么意义呢?

当然,容器在怎么创建和管理基于服务器的解决方案上面给予了很大的灵活性,不过它仍然像管理整个工作流一样管理架构。

这就是Serverless技术的切入点。

Serverless是一种新的工作流方法,用拟人的描述方式是它说:会有一些事件调用我的代码,当事件发生时,我可能会从某个东西中获取输入并可能创建一些输出,这就是我需要关心的。

正因如此,Serverless的应用可以快速扩展到需求,而因为它的设计高度可用,下面以一个例子去深入探讨这个问题:








在HTTP端点上侦听服务器函数的典型工作流

这里有一个典型的例子,说明了Serverless的函数是如何工作的,在Serverless的技术中,按需进行的代码被称为服务的功能,它们被称为“服务”,因为每个按需执行的执行都服务于特定的目的或功能。

在本例中,创建了一个处理Web请求的函数,首先,当介入到入站请求时,云提供程序将查看是否有可用的函数实例正在运行,若不是,它就创建一个,但如果是这样,它就将这个请求交给可用的函数。

然后,函数代码解析WEB请求,以某种方式处理它,并返回对请求客户机的响应。

通常,云提供程序将会让该实例运行几分钟,以加速处理下一个请求,从而消除生成另一个实例的需要,但在大约5分钟后,弱没有第二个请求,云提供商就会取消这个实例。

人人为我,我为人人

之前提到,在匿名且通用的操作实例上承载了服务器的功能。

这是它们工作的关键,云提供程序对基本操作系统(如Linux或Windows)进行定制,其环境和服务设置与特定的编程语言(如node JS、Java、Python或Dot net core)协同工作。

云提供程序可以非常快得创建实例,因为它们完全相同,没有什么特别之处,每个工作与其他实例完全相同。

当部署代码时,会被保存到云提供商的存储服务中。

当代码需要运行时,提供者检索代码、启动其中的一个实例,将代码放到它上面,然后执行该代码,正如前面所指出的,一旦代码执行完毕,提供者通常会让实例运行一点,以处理后续的请求,但一旦需求下降,就会取消该实例。








服务器成本低于大多数定价模型,包括容器,照片通过Joshua_Willson在Pixabay公共领域。

定价模型

这种方法导致了一个不同于虚拟机或容器的定价模型。

在VMs的情况下,通常根据VM的CPU内核和内存的容量来支付每小时的费用,也会经常把应用许可费捆绑在一起,需要支付存储数据和数据系统磁盘的费用。

同样的情况也适用于容器定价:需要为承载容器的VM付费。不同之处在于,在VM上的传统代码可能会留下许多未使用的资源,可以将多个容器打包到一个VM上,以相同的价格处理多个工作负载。

在Serverless功能的情况下,需要为代码运行的次数和每个执行使用的计算资源数量付费。这就为我们带来了很大的回报。

简而言之,降低实际的基础设施成本,大大简化了部署管道以及总体成本,这只是当前成本的一小部分。

来看看函数与虚拟机的直接托管成本。








每月执行50万次的费用,4GB/S

在这里,将承担一个包括每月50万次执行的工作量,每秒钟大约有两个请求,要完成这项工作,每秒钟大约需要4GB的内存。

因此,对于虚拟机,需要至少提供8GB的内存,在Azure中,最便宜的选择是D3V2 VM,如果运行Linux,每月的运行成本约为100美元和4美元,对于AWS来说,最便宜的EC2实际是T2,大的,每月约70美元。

但如果使用的是服务器功能,那么可以大幅降低成本,在Azure功能的情况下,可以将实际的基础设施成本削减到大约四分之一,使用Lambda,可以将成本与EC2的比例减半。







每月执行200万次执行,每次执行4 GB/ s。

如果将执行的次数增加到200万,就能得到更好的存储,VM成本显著增加,以满足32GB的内存需要。

服务器成本也在增加,减少了在VM上实现的百分比节省,但实际的节省会更好。

在Azure的情况下,通过使用函数,每月可以节省近100美元,在AWS的情况下,每个月可以节省150美元。








每个月处理2万次执行的费用,每次执行的费用为512 MB/ s。

如果工作负载更小的话,那么节省下来也会很明显,让我们将假设改为每个月2万次请求,或者每两分钟一次请求,每秒钟可以处理1G的RAM。

在这种情况下,可以使用一个Azure标准的A1 V2 VM,每月大约32美元,或一个T2小的EC2实例,每月大约17美元。

长尾定价

你可能会问自己:“AWS和Azure怎么能让这个服务免费?”

同样,它又回到了一个事实,即Serverless的实例都是一样的,由于底层图像是完全相同的,云提供程序可以轻松得提供它们,而且每个实例实际上变得比以前一个更便宜,所以在游戏中有巨大的规模。

就像Facebook一样,每个新用户几乎不用花费任何东西来创造,事实上,仅仅通过创建账户来实现盈利,同样的,最终也就是Serverless的实例。

每个工作负载几乎不需要部署,因此给您大量的免费计算时间和实例是有理可图的,因为即使是少数用户超过了免费的服务阈值,也只有周期性得获得了丰厚的回报。

而Serverless技术的用户几乎总是需要额外的服务:数据库作为服务,消息队列,内存缓存,API网关等等,这相当于赠送剃须刀手柄,并加价出售刀片。

这是一个长尾的效应,但利润抛物线非常陡峭,得到了很多只有执行和计算时间,因为它只需要稍微超过这些限制,云提供商就能实现利润。

因此当使用Serverles时,会得到显著的成本节省。

无论大小,在服务器上运行相同数量的工作比虚拟机上花费更少。

更好的是,没有服务器,也没有僵尸。

因为服务提供者会自动处理供应和自动设备,而且只需要支付代码运行的次数以及它在运行时所使用的计算资源的数量,就不会为正在使用电力的服务器实例付费。








Serverless并不意味着NoOps,但它确实意味着是更精简的DevOps团队。

Serverless的Ops

这里有Serverless的实际好处:如果没有服务器可以管理,那么构建和部署解决方案的工作就更少了吗?

答案是,是的,作为技术经理所需要领导的时间将会大大减少,每个员工的工作时间也会被压缩到生产当中。

什么叫NoOps?这是一个时髦的词,所以每个人的定义各有不同,但大部分的人都会同意以下观点:NoOps的核心是可以使用自动化、服务抽象和供应商提供的服务来减少或消除传统上需要在DevOps中执行的任务。

例如,今天可能有一个敏捷过程,在此之中,工作被分配给Sprint,每个星期、两周或任何时候,团队实现其变更,然后构建和测试,如果测试完毕即可部署。

这涉及到测试工程师的工作,构建工程师,系统工程师、开发团队等等,都会产生一些焦虑,尤其是在构建失败的时候。

在NoOps中,发展的速度要快得多,使用持续集成和持续部署,自动化构建和测试用于确保每个特性或修复不被破坏解决方案,如果有,将快速调整更改,重复这个自动构建和测试过程,直到特性或修复工作,然后就可以立即被推到登台和生产。

这种快速的节奏之所以有效,是因为构建(通过微服务)是有意分发的。

通过处理应用和几个小任务的组合,可以安全得处理每一个小任务,而不需要对给定的微服务任何变化都有很大的担心,降低了宕机时间。

另外由于函数是自动配置和分配以满足需求的,因此基于它们的应用往往会快速扩展并具有很高的可用性。

也就是说,无需监控微服务看它的在线或满足需求高峰,如果云提供商的底层服务器服务正常运行,即会处理需求峰值和出问题的实例。

因此,根据定义,除非云提供商正在历经服务中断,否则在一个不需要任何服务的应用中,就不能有宕机时间,即使这样也可以通过将完全相同的代码库部署到不同的区域,并使用基于DNS的路由来确保故障转移保护。

Serverless的好处

因此回顾一下Serverless功能的好处:

实际基础设施成本较低。
通过微服务架构进行工作,这是有意将业务逻辑关注点彼此分离的,这使您的应用开过过程更加简单,因为i额可以将解决方案的功能作为独立单元进行管理。
因为无需管理服务器,所以只需要关注代码,减少每个代码更改的人员和时间。
而事实上,这允许我们采用一个非常快速的开发过程,专注于自动化、抽象和持续交付以及持续集成。
而且由于云提供程序在实例被供应和分配时处理,有效的将高可用性和灾难恢复构建在基于服务器的解决方案中。
诚然,底层服务可能会遇到问题,但可以使用传统的基于云的业务连续性技术来管理这种情况。

若每个人都能专注于编程

事实上,Serverless是一个跳板,它本身就是一个让每个人都能成为程序员的通道,因为一旦完成了配置和部署服务器这种神秘的工作,就可以专注于代码本身的自动化。

微服务体系结构本身就是将几个小任务链接到一个工作流中的过程,可以将这些任务以新的方式结合起来,以新的投入为基础,为问题创造全新的解决方案。

我们已经达到了一个目标:使用人工智能和智能设备,比如Sire以及Google搜索、Alexa去理解相对非结构化的请求并生成有意义的响应,为什么这些相同类型的服务不能用于创建代码?或者至少是智能工作流呢?

为什么那些有创造力的人不能创造出新的和重要的解决方案,他们能够自己创造这些工作流程,利用现代计算的力量呢?

这些是值得去思考的问题。







微软的三种现代解决方案特点:“智能边缘”设备的遥测技术在“智能中心”中得到巩固和解释,使用人工智能,在中心和边缘进行Serverless的技术处理计算。

上面所说很大程度上借用了Satya Nadella在微软(Microsoft Build)的主题演讲。

Satya Nadella对计算机的未来提出了一个设想,包括两个领域:“智能边缘”和“智能云”。

智能EDGE是我们所有链接到互联网网的设备,而且通常也自身也足够强大,拥有独立思考的属性,不仅是我们的电脑,智能手机,平板电脑等,还包括电视、电器、汽车、医疗监视器、玩具,甚至是使用的工具。

从所有这些设备的输入中,有一个统一的平台去进行管理——智能云。

当每个设备都在我们的生活中实践时,云利用人工智能和大数据推导出真知灼见以及行动,然后反馈到每个设备上,指导它们如何行动,并且告诉它们这是为什么,以便于它们进行学习。

在微软的愿景当中,这种云处理是在Serverless的平台上进行的,这种平台是无限可伸缩的。

Serverless的欠缺处

和上面提到的容器的欠缺之处一样,Serverless本身也是拥有不足的,接下来就来谈谈它不能做什么,以及为什么虚拟机容器不会很快消失。

显然将大规模的应用集群改为微服务架构并非小事。

前期的成本很高,可能会有伙伴关系或其他业务和要求,比如数据隐私和主权,这限制或阻止简单得放弃一直在构建应用的方式。

即使有很好的基本的N层架构,从使用容器中得到得益处可能远远超过将应用重新构建为可移植单元的好处。

而且并不是每个工作负载都适用于微服务,如果你的任务不需要扩展——如果它有一个可预测的工作负载——那么就有一个强有力的理由反对使用微服务。

如果解决方案严重依赖于其他服务,或者需要对运行时环境进行高度专门化的控制,那么这一点尤其正确,不要试图绕过服务器运行时环境的限制,或补偿大量外部请求和响应;只需将解决方案构建为一个包,并将其部署到容器中。

或者,如果应用需要大量的计算资源来完成它的工作,当然,可能会在托管方面节省一些钱,但是不断供应的VM或容器的可靠性可能会超过服务器功能所固有的代码限制。

这是一个讨论Serverless解决方案局限性的好办法。

一个明显的问题是,因为实例只在需要时才提供,所以在很少使用Serverless代码的情况下,可能会有一些延迟处理,可以通过运行探测来修复这个代码,使得代码保持温暖,但这是一种黑客才使用的行为,也许最好只是简单得将不经常访问的代码放到一个总是热的容器当中去,特别是在调用代码时,性能是非常重要的。

此外,还需要准备好解决延迟和删除微服务之间的链接的解决方案,例如,如果有一个作为所有解决方案的微服务运行身份验证API,那么在它的通信中,即使是400微秒的延迟也会被放大成一个严重的、系统性的错误。

虽然容器还是一个比较新兴的技术,但是Serverless比它更要新,Azure的功能在一般情况下还不到一年,Google的Serverless解决方案仍处于测试阶段,IBM创建Serverless标准的努力也扔处于初级阶段。

这就引出了另外一个问题:无论采取什么Serverless的方法,它在这个时候会有点拘泥于一个供应商,几乎可以在任何地方运行一个容器,但如何获得服务器代码的运行将多少取决于云提供商所支持的语言,以及它们用于创建Serverless实例和支持服务的方法。

代码可以运行到云提供商所支持的运行时和版本上,这是很有限的,因此很难引入某些库或程序集,这会让编程更加复杂。

最后,Serverless的编程模型——一个触发接收输入并创建一些输出的事件——可能不是某个需求的正确解决方案。

总结

Serverless是云计算的下一个浪潮,它节约了巨大的时间和成本,而且总投入甚至少于容器,只需要按需付费,没有更多的僵尸服务占用整体利润。

云供应商也通过供给本质上相同的服务器给每个需要它们的人获取显著的利益,同时也保证了低成本和高性能。

由于是自动化的,Serverless的通用方面,高可用和灾难恢复是内置的,在区域性服务中断的情况下,您可以使用传统的基于云的业务连续性技术来保持运行。

整个微服务概念建立在快速部署、持续集成、持续交付和分离关注的基础上,使Serverless成为改进服务交付和快速适应的理想方法。

但Serverless并不是每个工作负载都适用的,最好在容器中建立一个解决方案。

原文地址:http://www.tuicool.com/articles/FnQ3UvV 原文作者:Doug Vanderweide 查看全部

无服务架构(Serverless)和DevOps、SRE、微服务、容器等一样,是最近两年比较新兴的概念,数人云之前给大家分享过《Serverless用这5大优势,挽救了后来7亿用户的Instagram》,今天再来探讨下Serverless和容器与微服务之间的互补与碰撞。

近年来很多人在讨论云计算时都会提到容器,因为其几乎完美得解决了DevOps所面临的挑战。

本文将阐述Serverless的解决方案,它与传统和容器化的应用的不同之处。


1.png



一个典型的N层Web应用是由前端、公开的Web服务器组成;后端:高度隔离的数据层以及中间件层。

微服务

先来说说微服务,在微服务的模式下,可以无需使用服务器去呈现所有的用户界面,例如,处理所有的业务对象和逻辑,只需一个应用即可创建多个应用编程接口或API。


2.png



这是以酒店为应用场景的一种基于微服务的现代WEB和移动应用的方法。

假设经营了一家连锁酒店,需要面向公众的服务,允许用户登录到网站预定房间,通过第三方邮件列表进行邮件促销,以及提供WEB和移动应用页面的一般方式。

可以创建处理用户数据请求的API,这里用白色显示,与其拥有传统的服务器呈现的用户界面,还可以创建单个页面WEB应用和使用该API的移动应用,以获取所需的信息去适应该平台的方式提供信息。

这使得作者的工作量去除了整个开发链:设计人员和前端开发人员可以让界面看起来更漂亮,并且能够高效得执行,而后端团队只需要专注于创建一个单一的方法去为他们提供相同的信息。


3.png



只需要将代码和其依赖项打包到一个容器中,然后即可在任何地方运行——因为它们通常很小,可以将大量的容器装到一台机器上——TechCrunch。

容器

从业务的角度讲,能有什么原因不喜欢容器呢?答案是,没有。

容器之所以伟大,是因为它们可以让我们打包所有的东西——操作系统、代码、服务、以及应用需要工作的所有东西并且运行它们。这不仅显著得简化了DevOps模式,节约了大量的人工和时间的成本,而且它还为我们提供了如何部署解决方案的选项,其中许多现在都是免费的特定供应商。

另外,正如TechCrunch所指出的,可以在一台主机上运行几个容器,这意味着浪费的资源要少的多,反过来又浪费了成本。

所以可以用容器来提供这些微服务,也就是说,用户接口API可以在容器A中运行,而在容器B中预定API,以及在容器C中的电子邮件通讯API,容器D中的身份验证API。

容器使得上面所提到的具有高度可移植性,如果构建的得当,高度可伸缩,甚至可以很好得适应Bug。

DevOps和容器

从DevOps的角度去看,仍旧是没有理由不喜欢容器技术。其具有的优势有:

可快速地进行部署。
在一些基本配置中,可以安装所需的应用和服务,配置环境以及支持应用,并未整个流程编写脚本。
技术团队无需花费一整天的时间去创建新的环境:脚本一次就完成了。
运维的成本降低。

如果应用被适当得设计成可伸缩的需求,那么使用容器的扩展就像启动应用镜像的另一个实例一样简单,甚至可以自动化这个过程,应用可以响应时需求和规模来满足需求。

更为重要的是,可以自动化构建和部署过程,容器在自动化的构建过程和应用生命周期管理中非常有用。

可以轻松得使用容器简化版本和构建过程,所有的这些都很容易通过开源或低成本工具以及过程进行编排。

容器的不足之处

容器也有一些不足之处,因为容器化仍然是一项新技术,所以会有很多变化。不用担心Docker或Mesosphere会很快消失,但它们可能会发生重大的变化,对于在部署管道中管理容器镜像的最佳实践,还没有达成共识。

根据其特性,容器需要在客户机器上具有更高的权限,若成功利用这一点,就会让它们更加危险,例如:一台虚拟机在客户服务器上被破坏。

也很容易得到比需要的容器更多的容器以及曾经执行一些工作负载的孤立容器:它们已经失效,但没有被清理掉。

有一些研究表明,在所有基于云计算的虚拟机中,有四分之一到三分之一都是僵尸的,而容器也遇到了同样的问题,因为容器可以快速且轻而易举的创建,并且在很大程度上是为了处理一次性的工作负载而设计,所以这方面是存在着很大的隐患。

大多数容器都需要外部程序集——即“助手”应用,使用它们的主要应用能够运行,当容器从镜像中创建时,很难确保这些程序集所在的存储库是联机的,并且可以遇到容器对这些程序集的依赖可能会被破坏的情况。

最后,使用某些容器技术(如Docker)进行安全高效得网络连接,需要熟练的人手。

Serverless

Serverless在此基础上应用而生,可以消除几乎所有的问题和以及传统基础设施和容器上存在的大部分问题。

需要明确的一点是,无服务架构(Serverless)并不意味着没有任何服务器去运行代码。

Serverless是无需管理服务器,只需要关注代码,而提供者将处理其余的部分。

像所有的流行技术一样,Serverless有一些变化的定义,这取决于说的是谁,但在供应商的角度,核心概念是相同的:

Serverless计算提供了以通用的匿名操作系统,代码将会在其中运行,下文将进行详解。
这些实例由云提供应用完全管理,会做所有的补丁、调优、服务安装等等。只需要编写运行在此服务上的代码,而云提供应用将确保代码在该环境中运行。
每个匿名且通用的环境只在需要时提供,当不再需要代码时,该环境就会被减少。
最后,只需要为代码实际使用付费:代码被执行的次数以及所需的计算资源的数量。

微服务和Serverless

但如果所有这些相对简单的任务或微服务将它们组成一个解决方案继续进行交付,就如果它们是整个服务器应用一样,又有什么意义呢?

当然,容器在怎么创建和管理基于服务器的解决方案上面给予了很大的灵活性,不过它仍然像管理整个工作流一样管理架构。

这就是Serverless技术的切入点。

Serverless是一种新的工作流方法,用拟人的描述方式是它说:会有一些事件调用我的代码,当事件发生时,我可能会从某个东西中获取输入并可能创建一些输出,这就是我需要关心的。

正因如此,Serverless的应用可以快速扩展到需求,而因为它的设计高度可用,下面以一个例子去深入探讨这个问题:


4.png



在HTTP端点上侦听服务器函数的典型工作流

这里有一个典型的例子,说明了Serverless的函数是如何工作的,在Serverless的技术中,按需进行的代码被称为服务的功能,它们被称为“服务”,因为每个按需执行的执行都服务于特定的目的或功能。

在本例中,创建了一个处理Web请求的函数,首先,当介入到入站请求时,云提供程序将查看是否有可用的函数实例正在运行,若不是,它就创建一个,但如果是这样,它就将这个请求交给可用的函数。

然后,函数代码解析WEB请求,以某种方式处理它,并返回对请求客户机的响应。

通常,云提供程序将会让该实例运行几分钟,以加速处理下一个请求,从而消除生成另一个实例的需要,但在大约5分钟后,弱没有第二个请求,云提供商就会取消这个实例。

人人为我,我为人人

之前提到,在匿名且通用的操作实例上承载了服务器的功能。

这是它们工作的关键,云提供程序对基本操作系统(如Linux或Windows)进行定制,其环境和服务设置与特定的编程语言(如node JS、Java、Python或Dot net core)协同工作。

云提供程序可以非常快得创建实例,因为它们完全相同,没有什么特别之处,每个工作与其他实例完全相同。

当部署代码时,会被保存到云提供商的存储服务中。

当代码需要运行时,提供者检索代码、启动其中的一个实例,将代码放到它上面,然后执行该代码,正如前面所指出的,一旦代码执行完毕,提供者通常会让实例运行一点,以处理后续的请求,但一旦需求下降,就会取消该实例。


5.png



服务器成本低于大多数定价模型,包括容器,照片通过Joshua_Willson在Pixabay公共领域。

定价模型

这种方法导致了一个不同于虚拟机或容器的定价模型。

在VMs的情况下,通常根据VM的CPU内核和内存的容量来支付每小时的费用,也会经常把应用许可费捆绑在一起,需要支付存储数据和数据系统磁盘的费用。

同样的情况也适用于容器定价:需要为承载容器的VM付费。不同之处在于,在VM上的传统代码可能会留下许多未使用的资源,可以将多个容器打包到一个VM上,以相同的价格处理多个工作负载。

在Serverless功能的情况下,需要为代码运行的次数和每个执行使用的计算资源数量付费。这就为我们带来了很大的回报。

简而言之,降低实际的基础设施成本,大大简化了部署管道以及总体成本,这只是当前成本的一小部分。

来看看函数与虚拟机的直接托管成本。


6.png



每月执行50万次的费用,4GB/S

在这里,将承担一个包括每月50万次执行的工作量,每秒钟大约有两个请求,要完成这项工作,每秒钟大约需要4GB的内存。

因此,对于虚拟机,需要至少提供8GB的内存,在Azure中,最便宜的选择是D3V2 VM,如果运行Linux,每月的运行成本约为100美元和4美元,对于AWS来说,最便宜的EC2实际是T2,大的,每月约70美元。

但如果使用的是服务器功能,那么可以大幅降低成本,在Azure功能的情况下,可以将实际的基础设施成本削减到大约四分之一,使用Lambda,可以将成本与EC2的比例减半。


7.png


每月执行200万次执行,每次执行4 GB/ s。

如果将执行的次数增加到200万,就能得到更好的存储,VM成本显著增加,以满足32GB的内存需要。

服务器成本也在增加,减少了在VM上实现的百分比节省,但实际的节省会更好。

在Azure的情况下,通过使用函数,每月可以节省近100美元,在AWS的情况下,每个月可以节省150美元。


8.png



每个月处理2万次执行的费用,每次执行的费用为512 MB/ s。

如果工作负载更小的话,那么节省下来也会很明显,让我们将假设改为每个月2万次请求,或者每两分钟一次请求,每秒钟可以处理1G的RAM。

在这种情况下,可以使用一个Azure标准的A1 V2 VM,每月大约32美元,或一个T2小的EC2实例,每月大约17美元。

长尾定价

你可能会问自己:“AWS和Azure怎么能让这个服务免费?”

同样,它又回到了一个事实,即Serverless的实例都是一样的,由于底层图像是完全相同的,云提供程序可以轻松得提供它们,而且每个实例实际上变得比以前一个更便宜,所以在游戏中有巨大的规模。

就像Facebook一样,每个新用户几乎不用花费任何东西来创造,事实上,仅仅通过创建账户来实现盈利,同样的,最终也就是Serverless的实例。

每个工作负载几乎不需要部署,因此给您大量的免费计算时间和实例是有理可图的,因为即使是少数用户超过了免费的服务阈值,也只有周期性得获得了丰厚的回报。

而Serverless技术的用户几乎总是需要额外的服务:数据库作为服务,消息队列,内存缓存,API网关等等,这相当于赠送剃须刀手柄,并加价出售刀片。

这是一个长尾的效应,但利润抛物线非常陡峭,得到了很多只有执行和计算时间,因为它只需要稍微超过这些限制,云提供商就能实现利润。

因此当使用Serverles时,会得到显著的成本节省。

无论大小,在服务器上运行相同数量的工作比虚拟机上花费更少。

更好的是,没有服务器,也没有僵尸。

因为服务提供者会自动处理供应和自动设备,而且只需要支付代码运行的次数以及它在运行时所使用的计算资源的数量,就不会为正在使用电力的服务器实例付费。


9.png



Serverless并不意味着NoOps,但它确实意味着是更精简的DevOps团队。

Serverless的Ops

这里有Serverless的实际好处:如果没有服务器可以管理,那么构建和部署解决方案的工作就更少了吗?

答案是,是的,作为技术经理所需要领导的时间将会大大减少,每个员工的工作时间也会被压缩到生产当中。

什么叫NoOps?这是一个时髦的词,所以每个人的定义各有不同,但大部分的人都会同意以下观点:NoOps的核心是可以使用自动化、服务抽象和供应商提供的服务来减少或消除传统上需要在DevOps中执行的任务。

例如,今天可能有一个敏捷过程,在此之中,工作被分配给Sprint,每个星期、两周或任何时候,团队实现其变更,然后构建和测试,如果测试完毕即可部署。

这涉及到测试工程师的工作,构建工程师,系统工程师、开发团队等等,都会产生一些焦虑,尤其是在构建失败的时候。

在NoOps中,发展的速度要快得多,使用持续集成和持续部署,自动化构建和测试用于确保每个特性或修复不被破坏解决方案,如果有,将快速调整更改,重复这个自动构建和测试过程,直到特性或修复工作,然后就可以立即被推到登台和生产。

这种快速的节奏之所以有效,是因为构建(通过微服务)是有意分发的。

通过处理应用和几个小任务的组合,可以安全得处理每一个小任务,而不需要对给定的微服务任何变化都有很大的担心,降低了宕机时间。

另外由于函数是自动配置和分配以满足需求的,因此基于它们的应用往往会快速扩展并具有很高的可用性。

也就是说,无需监控微服务看它的在线或满足需求高峰,如果云提供商的底层服务器服务正常运行,即会处理需求峰值和出问题的实例。

因此,根据定义,除非云提供商正在历经服务中断,否则在一个不需要任何服务的应用中,就不能有宕机时间,即使这样也可以通过将完全相同的代码库部署到不同的区域,并使用基于DNS的路由来确保故障转移保护。

Serverless的好处

因此回顾一下Serverless功能的好处:

实际基础设施成本较低。
通过微服务架构进行工作,这是有意将业务逻辑关注点彼此分离的,这使您的应用开过过程更加简单,因为i额可以将解决方案的功能作为独立单元进行管理。
因为无需管理服务器,所以只需要关注代码,减少每个代码更改的人员和时间。
而事实上,这允许我们采用一个非常快速的开发过程,专注于自动化、抽象和持续交付以及持续集成。
而且由于云提供程序在实例被供应和分配时处理,有效的将高可用性和灾难恢复构建在基于服务器的解决方案中。
诚然,底层服务可能会遇到问题,但可以使用传统的基于云的业务连续性技术来管理这种情况。

若每个人都能专注于编程

事实上,Serverless是一个跳板,它本身就是一个让每个人都能成为程序员的通道,因为一旦完成了配置和部署服务器这种神秘的工作,就可以专注于代码本身的自动化。

微服务体系结构本身就是将几个小任务链接到一个工作流中的过程,可以将这些任务以新的方式结合起来,以新的投入为基础,为问题创造全新的解决方案。

我们已经达到了一个目标:使用人工智能和智能设备,比如Sire以及Google搜索、Alexa去理解相对非结构化的请求并生成有意义的响应,为什么这些相同类型的服务不能用于创建代码?或者至少是智能工作流呢?

为什么那些有创造力的人不能创造出新的和重要的解决方案,他们能够自己创造这些工作流程,利用现代计算的力量呢?

这些是值得去思考的问题。


10.png


微软的三种现代解决方案特点:“智能边缘”设备的遥测技术在“智能中心”中得到巩固和解释,使用人工智能,在中心和边缘进行Serverless的技术处理计算。

上面所说很大程度上借用了Satya Nadella在微软(Microsoft Build)的主题演讲。

Satya Nadella对计算机的未来提出了一个设想,包括两个领域:“智能边缘”和“智能云”。

智能EDGE是我们所有链接到互联网网的设备,而且通常也自身也足够强大,拥有独立思考的属性,不仅是我们的电脑,智能手机,平板电脑等,还包括电视、电器、汽车、医疗监视器、玩具,甚至是使用的工具。

从所有这些设备的输入中,有一个统一的平台去进行管理——智能云。

当每个设备都在我们的生活中实践时,云利用人工智能和大数据推导出真知灼见以及行动,然后反馈到每个设备上,指导它们如何行动,并且告诉它们这是为什么,以便于它们进行学习。

在微软的愿景当中,这种云处理是在Serverless的平台上进行的,这种平台是无限可伸缩的。

Serverless的欠缺处

和上面提到的容器的欠缺之处一样,Serverless本身也是拥有不足的,接下来就来谈谈它不能做什么,以及为什么虚拟机容器不会很快消失。

显然将大规模的应用集群改为微服务架构并非小事。

前期的成本很高,可能会有伙伴关系或其他业务和要求,比如数据隐私和主权,这限制或阻止简单得放弃一直在构建应用的方式。

即使有很好的基本的N层架构,从使用容器中得到得益处可能远远超过将应用重新构建为可移植单元的好处。

而且并不是每个工作负载都适用于微服务,如果你的任务不需要扩展——如果它有一个可预测的工作负载——那么就有一个强有力的理由反对使用微服务。

如果解决方案严重依赖于其他服务,或者需要对运行时环境进行高度专门化的控制,那么这一点尤其正确,不要试图绕过服务器运行时环境的限制,或补偿大量外部请求和响应;只需将解决方案构建为一个包,并将其部署到容器中。

或者,如果应用需要大量的计算资源来完成它的工作,当然,可能会在托管方面节省一些钱,但是不断供应的VM或容器的可靠性可能会超过服务器功能所固有的代码限制。

这是一个讨论Serverless解决方案局限性的好办法。

一个明显的问题是,因为实例只在需要时才提供,所以在很少使用Serverless代码的情况下,可能会有一些延迟处理,可以通过运行探测来修复这个代码,使得代码保持温暖,但这是一种黑客才使用的行为,也许最好只是简单得将不经常访问的代码放到一个总是热的容器当中去,特别是在调用代码时,性能是非常重要的。

此外,还需要准备好解决延迟和删除微服务之间的链接的解决方案,例如,如果有一个作为所有解决方案的微服务运行身份验证API,那么在它的通信中,即使是400微秒的延迟也会被放大成一个严重的、系统性的错误。

虽然容器还是一个比较新兴的技术,但是Serverless比它更要新,Azure的功能在一般情况下还不到一年,Google的Serverless解决方案仍处于测试阶段,IBM创建Serverless标准的努力也扔处于初级阶段。

这就引出了另外一个问题:无论采取什么Serverless的方法,它在这个时候会有点拘泥于一个供应商,几乎可以在任何地方运行一个容器,但如何获得服务器代码的运行将多少取决于云提供商所支持的语言,以及它们用于创建Serverless实例和支持服务的方法。

代码可以运行到云提供商所支持的运行时和版本上,这是很有限的,因此很难引入某些库或程序集,这会让编程更加复杂。

最后,Serverless的编程模型——一个触发接收输入并创建一些输出的事件——可能不是某个需求的正确解决方案。

总结

Serverless是云计算的下一个浪潮,它节约了巨大的时间和成本,而且总投入甚至少于容器,只需要按需付费,没有更多的僵尸服务占用整体利润。

云供应商也通过供给本质上相同的服务器给每个需要它们的人获取显著的利益,同时也保证了低成本和高性能。

由于是自动化的,Serverless的通用方面,高可用和灾难恢复是内置的,在区域性服务中断的情况下,您可以使用传统的基于云的业务连续性技术来保持运行。

整个微服务概念建立在快速部署、持续集成、持续交付和分离关注的基础上,使Serverless成为改进服务交付和快速适应的理想方法。

但Serverless并不是每个工作负载都适用的,最好在容器中建立一个解决方案。

原文地址:http://www.tuicool.com/articles/FnQ3UvV 原文作者:Doug Vanderweide

容器5大深坑莫要踩,5种实践出真知

杨y 发表了文章 • 0 个评论 • 116 次浏览 • 2017-09-13 18:52 • 来自相关话题

 

误区1:Docker是万灵药

Docker并不解决云端所有的问题,所以在容器技术中,需要对计划目标有合理地规划,若考虑采用Docker在平台中加一些特定的东西,那么请自问:目前平台有哪些衍变?若已经有了小的应用服务,可以使用Docker去解决一些问题,但不要试图让它解决全部问题。

在评估环境是否合适容器时,经常使用牛或宠物作为比喻,想要迁移到容器,需要的环境是能像对待牲口那样简单粗暴,而不是那种娇滴滴的宠物。若有一个高强度且密集的程序,并且要不断地为服务器梳理毛发(比喻,意思为比较脆弱,需要经常维护),那么就不适合迁移到容器当中。
 
误解2:Docker有明确的最佳实践

如同在其生命周期快速采用阶段的任何突破性技术一样,容器还没有一组清晰的最佳实践,本文文末将给出一个较好的实践,但仍不算最佳。

虽然并没有什么“最佳实践”,但需要知道做什么,如,早期的想法是不希望在Docker中托管一个数据库,但现在已经在Docker上运行了整个搜索引擎(又称庞大的数据库),并找到了让它工作的方法。

Docker现在充满了争议,但这不意味着要去避开它,而是做到理解前沿的新技术和所做的事情。不要害怕尝试不同的事务,需要明白它能产生的作用,如果善于思考需要解决的问题,并进行一些实践测试,可能就会学到很多适合本企业自身的知识,缺乏最佳实践可能是一种挑战,但同时也意味着可以不受限地跳出条条框框去思考,想出创造性的办法去解决老问题。

如果已经有了一个范围广泛且松散耦合的集合,就可以很好地运用容器去解决一些,但要是已经有了大量流程模式的挑战,并且应用管理方法都是非常传统的,就需要在尝试迁移之前将这些问题解决掉,在迁移到容器之前,需要致力于不可变的基础设施概念和实践。
 
误解3:Docker总是比虚拟机便宜

从某个角度去看,运行容器确实会比虚拟机要便宜,比如,有600个AWS实例,分别是1个CPU和4-5GB的RAM,那么可以使用Docker容器将其减少到100个实例,其中有32个CPU和64G的RAM,因为实例数量的减少就可以显著地降低成本。

对于一些用例来说这是正确且可行的,至少在短期内如此,但从长远角度去看,如同其他任何技术一样,也为应用容器技术花费了不少人力、物力成本,逐渐将其复杂化也带来了成本上的问题。

当大规模地运行容器时,为了方便管理容器极其资源,不得不投资管理和编排平台,就需要一个全新的技术堆栈,由于没有明确的最佳实践,可能会遇到一些反复出现的错误,造成时间和成本上的浪费。

这笔账不能简单地去通过对比其价格计算,需要大量的时间去确定优先级,并理解在运用容器需要的成本是多少。
 
误解4:容器可以像虚拟机一样

容器不仅仅是更小,更离散的虚拟机,而且也是完全独立的。所以若使用的是像虚拟机那样的容器,护着打算再Docker容器中构建虚拟机,那么还是建议就此罢手,因为可能会导致一些重大问题。

将Docker想象成一台3D打印机,输入需求→Poof→出现容器,现在这是一个整体和自包含对象而并非是可以编辑或删除的对象。如果某些项不正确或需要新项,不得不进行重复性工作。

当运用Docker容器时需要自问一下如:

集成应用真正的含义是什么

是否了解依赖关系

如果能自答出这些问题,并构建适合容器的新工作流程,那么就能很便捷地实现。
 
误解5:Docker与虚拟机具有相同的安全模型

很多人部署了Docker后,认为它具有与虚拟机相同的安全模型,但可惜地是并非如此,Docker虽与操作系统有关,但它并不是操作系统,很多人使用名为Core OS的缩放操作系统运行容器,除了运行Docker,其无法做更多的事情。应用通常仍然需要更传统的操作系统提供一些东西,例如,从一个Linux发行版(如Ubuntu)构建容器。

一整套的安全挑战出现在迁移到容器时。其中一些是因为“一个进程一个容器”的最初目标难以执行,所以人们找到了实际上容器一个非常重要的特征捷径和方法。

若闯入容器化的环境,当发生的事件导致安全问题时,需要建立告警,比如构建了一系列容器运行的Java应用,若除了Java之外任何操作都开始运行就应该告警。

值得注意的是,容器可以让人真正了解这些类型的告警,可以缩小查找内容,但编写这些规则应用它们以及随着时间推移去进行管理则是一项挑战。
 

Docker的5大实践

前文说过,Docker目前并没有什么“最佳实践”,但本文仍会给出5个实践来供以参考:

实践1:基于应用的日志记录

在基于应用的方法中,容器内的应用使用日志框架来处理日志记录过程,如一个Java应用可能会用Log4j 2去格式化和发送日志文件到远程服务器,并完成绕过Docker和操作系统。


虽然基于应用的日志记录使开发这对日志事件有了最大控制,但这种方法也会在应用过程中产生大量开销,对于哪些在更传统的应用环境工作的人来说可能是有用的,因为其允许开发者继续使用应用的日志框架,无需向主机添加日志功能。

Docker实际上意味着不仅记录应用和主机操作系统,还包括Docker服务。
 
实践2:使用数据卷


容器本质上是临时的,因此若挂掉,里面任何文件都会丢失,相反,容器必须将日志事件转发到集中式日志记录服务(比如日志记录),或将日志事件存储在一个数据卷中(被定义为容器内的一个标记目录,该目录存在保存持久或共享的数据)。


使用数据卷记录事件的好处有:由于它们链接到主机上的一个目录,所以日志数据仍然存在,并且可以与其他容器共享,减少了容器关闭时丢失数据的可能性。(参见:https://www.digitalocean.com/community/tutorials/how-to-work-with-docker-data-volumes-on-ubuntu-14-04) 
 

实践3:Docker日志驱动程序

在Docker中记录实践的方式是使用平台的日志记录驱动程序将日志事件转发到在主机上运行的Syslog实例。Docker日志驱动程序直接从容器的Stdout和Stderr输出入去日志事件,这消除了从日志文件读取和写入的需要,转化为性能增益。

但使用Docker日志驱动程序有一些缺点:

不允许日志解析,只能记录转发

Docker日志命令仅适用于日志驱动程序JSON文件

当TCP服务器无法访问时,容器终止。

(参见:https://www.digitalocean.com/community/tutorials/how-to-work-with-docker-data-volumes-on-ubuntu-14-04)
 

实践4:专用记录容器

此种方法的主要优点在于可在Docker环境中完全管理日志事件。由于专用日志记录容器能从其他容器收集日志事件,聚合它们,然后将事件存储或转发到第三方服务,因此此方法消除了对主机的依赖,附加优点有:

自动收集,监控和分析日志事件

自动缩放日志事件,无需配置

通过多个日志事件,统计信息和Docker API数据流检索日志。
 
实践5:侧面方法

Sidecar已成为管理微服务架构的流行方式,侧面的想法来源于摩托车侧车架如何附着在摩托车上的类比,有消息称:一个Sidecar作为第二个进程与服务一起运行,并提供了通过同类界面暴露的平台基础设施功能,例如通过HTTP的类似REST的API。从日志角度看,优点是每个容器都链接到自己的日志记录容器(应用容器保存日志事件和记录容器标签,并将其转发到Loggly的日志记录管理系统)。
 

总结

不得不说,Docker容器是一项非常具有潜力而且十分炫酷的新技术,实践出真知,去了解Docker如何适应应用自身整体的策略非常值得,当了解了容器这些深坑之后,就可以避开它,同时也多去技术社区和线下交流了解更多的方法模式,不断充实自身。 查看全部
 

误区1:Docker是万灵药

Docker并不解决云端所有的问题,所以在容器技术中,需要对计划目标有合理地规划,若考虑采用Docker在平台中加一些特定的东西,那么请自问:目前平台有哪些衍变?若已经有了小的应用服务,可以使用Docker去解决一些问题,但不要试图让它解决全部问题。

在评估环境是否合适容器时,经常使用牛或宠物作为比喻,想要迁移到容器,需要的环境是能像对待牲口那样简单粗暴,而不是那种娇滴滴的宠物。若有一个高强度且密集的程序,并且要不断地为服务器梳理毛发(比喻,意思为比较脆弱,需要经常维护),那么就不适合迁移到容器当中。
 
误解2:Docker有明确的最佳实践

如同在其生命周期快速采用阶段的任何突破性技术一样,容器还没有一组清晰的最佳实践,本文文末将给出一个较好的实践,但仍不算最佳。

虽然并没有什么“最佳实践”,但需要知道做什么,如,早期的想法是不希望在Docker中托管一个数据库,但现在已经在Docker上运行了整个搜索引擎(又称庞大的数据库),并找到了让它工作的方法。

Docker现在充满了争议,但这不意味着要去避开它,而是做到理解前沿的新技术和所做的事情。不要害怕尝试不同的事务,需要明白它能产生的作用,如果善于思考需要解决的问题,并进行一些实践测试,可能就会学到很多适合本企业自身的知识,缺乏最佳实践可能是一种挑战,但同时也意味着可以不受限地跳出条条框框去思考,想出创造性的办法去解决老问题。

如果已经有了一个范围广泛且松散耦合的集合,就可以很好地运用容器去解决一些,但要是已经有了大量流程模式的挑战,并且应用管理方法都是非常传统的,就需要在尝试迁移之前将这些问题解决掉,在迁移到容器之前,需要致力于不可变的基础设施概念和实践。
 
误解3:Docker总是比虚拟机便宜

从某个角度去看,运行容器确实会比虚拟机要便宜,比如,有600个AWS实例,分别是1个CPU和4-5GB的RAM,那么可以使用Docker容器将其减少到100个实例,其中有32个CPU和64G的RAM,因为实例数量的减少就可以显著地降低成本。

对于一些用例来说这是正确且可行的,至少在短期内如此,但从长远角度去看,如同其他任何技术一样,也为应用容器技术花费了不少人力、物力成本,逐渐将其复杂化也带来了成本上的问题。

当大规模地运行容器时,为了方便管理容器极其资源,不得不投资管理和编排平台,就需要一个全新的技术堆栈,由于没有明确的最佳实践,可能会遇到一些反复出现的错误,造成时间和成本上的浪费。

这笔账不能简单地去通过对比其价格计算,需要大量的时间去确定优先级,并理解在运用容器需要的成本是多少。
 
误解4:容器可以像虚拟机一样

容器不仅仅是更小,更离散的虚拟机,而且也是完全独立的。所以若使用的是像虚拟机那样的容器,护着打算再Docker容器中构建虚拟机,那么还是建议就此罢手,因为可能会导致一些重大问题。

将Docker想象成一台3D打印机,输入需求→Poof→出现容器,现在这是一个整体和自包含对象而并非是可以编辑或删除的对象。如果某些项不正确或需要新项,不得不进行重复性工作。

当运用Docker容器时需要自问一下如:

集成应用真正的含义是什么

是否了解依赖关系

如果能自答出这些问题,并构建适合容器的新工作流程,那么就能很便捷地实现。
 
误解5:Docker与虚拟机具有相同的安全模型

很多人部署了Docker后,认为它具有与虚拟机相同的安全模型,但可惜地是并非如此,Docker虽与操作系统有关,但它并不是操作系统,很多人使用名为Core OS的缩放操作系统运行容器,除了运行Docker,其无法做更多的事情。应用通常仍然需要更传统的操作系统提供一些东西,例如,从一个Linux发行版(如Ubuntu)构建容器。

一整套的安全挑战出现在迁移到容器时。其中一些是因为“一个进程一个容器”的最初目标难以执行,所以人们找到了实际上容器一个非常重要的特征捷径和方法。

若闯入容器化的环境,当发生的事件导致安全问题时,需要建立告警,比如构建了一系列容器运行的Java应用,若除了Java之外任何操作都开始运行就应该告警。

值得注意的是,容器可以让人真正了解这些类型的告警,可以缩小查找内容,但编写这些规则应用它们以及随着时间推移去进行管理则是一项挑战。
 

Docker的5大实践

前文说过,Docker目前并没有什么“最佳实践”,但本文仍会给出5个实践来供以参考:

实践1:基于应用的日志记录

在基于应用的方法中,容器内的应用使用日志框架来处理日志记录过程,如一个Java应用可能会用Log4j 2去格式化和发送日志文件到远程服务器,并完成绕过Docker和操作系统。


虽然基于应用的日志记录使开发这对日志事件有了最大控制,但这种方法也会在应用过程中产生大量开销,对于哪些在更传统的应用环境工作的人来说可能是有用的,因为其允许开发者继续使用应用的日志框架,无需向主机添加日志功能。

Docker实际上意味着不仅记录应用和主机操作系统,还包括Docker服务。
 
实践2:使用数据卷


容器本质上是临时的,因此若挂掉,里面任何文件都会丢失,相反,容器必须将日志事件转发到集中式日志记录服务(比如日志记录),或将日志事件存储在一个数据卷中(被定义为容器内的一个标记目录,该目录存在保存持久或共享的数据)。


使用数据卷记录事件的好处有:由于它们链接到主机上的一个目录,所以日志数据仍然存在,并且可以与其他容器共享,减少了容器关闭时丢失数据的可能性。(参见:https://www.digitalocean.com/community/tutorials/how-to-work-with-docker-data-volumes-on-ubuntu-14-04) 
 

实践3:Docker日志驱动程序

在Docker中记录实践的方式是使用平台的日志记录驱动程序将日志事件转发到在主机上运行的Syslog实例。Docker日志驱动程序直接从容器的Stdout和Stderr输出入去日志事件,这消除了从日志文件读取和写入的需要,转化为性能增益。

但使用Docker日志驱动程序有一些缺点:

不允许日志解析,只能记录转发

Docker日志命令仅适用于日志驱动程序JSON文件

当TCP服务器无法访问时,容器终止。

(参见:https://www.digitalocean.com/community/tutorials/how-to-work-with-docker-data-volumes-on-ubuntu-14-04)
 

实践4:专用记录容器

此种方法的主要优点在于可在Docker环境中完全管理日志事件。由于专用日志记录容器能从其他容器收集日志事件,聚合它们,然后将事件存储或转发到第三方服务,因此此方法消除了对主机的依赖,附加优点有:

自动收集,监控和分析日志事件

自动缩放日志事件,无需配置

通过多个日志事件,统计信息和Docker API数据流检索日志。
 
实践5:侧面方法

Sidecar已成为管理微服务架构的流行方式,侧面的想法来源于摩托车侧车架如何附着在摩托车上的类比,有消息称:一个Sidecar作为第二个进程与服务一起运行,并提供了通过同类界面暴露的平台基础设施功能,例如通过HTTP的类似REST的API。从日志角度看,优点是每个容器都链接到自己的日志记录容器(应用容器保存日志事件和记录容器标签,并将其转发到Loggly的日志记录管理系统)。
 

总结

不得不说,Docker容器是一项非常具有潜力而且十分炫酷的新技术,实践出真知,去了解Docker如何适应应用自身整体的策略非常值得,当了解了容器这些深坑之后,就可以避开它,同时也多去技术社区和线下交流了解更多的方法模式,不断充实自身。