数人云

数人云

复杂性排第5,当红炸子鸡K8S对用户来说最大的槽点是啥?

dataman 发表了文章 • 0 个评论 • 87 次浏览 • 2018-03-29 10:44 • 来自相关话题

导读:

在使用或部署Kubernetes时,人们面临着非常多的问题。虽然Kubernetes所面临的一些挑战是独一无二的,但更多挑战都是典型的使用大量技术所带来的成长中的痛苦。最近CNCF主导了一项有关“Kubernetes生态系统状况”的一项调研,对于当红炸子鸡Kubernetes来说,哪些方面的挑战是最突出的?小数还另外翻译了K8S环境中4种最可能的威胁模型。

1

“Kubernetes生态系统状况”阐述了在选择容器编排解决方案时不同标准的重要性,以及阻碍Kubernetes采用的主要因素。与安全性或资源优化等标准相比,扩展性成为编排解决方案的基本要求。其中最大的挑战是,使用Kubernetes经常需要改变IT组织的几个部分的角色或职责。


CNCF最近的调查询问到人们在使用或部署容器时面临的挑战。在我们对数据的独立分析中,我们将答案发布在“Kubernetes Deployment & Security Patterns”一文中,并将焦点集中于使用Kubernetes管理容器的组织。这提供了一种方法来说明Kubernetes用户所面临的问题。
 


安全、存储、网络是最重要的挑战

研究结果表明,在对Kubernetes的普遍批评中,复杂性仅仅是排在第五位的挑战。领先的是与基础设施相关的挑战。在Kubernetes用户中,有46%的人提到了安全问题,网络和存储排在第二和第三位。

KubeCon +CloudNativeCon会议召集了采用者和技术专家,进一步推进云原生计算的教育和发展。供应商中立的技术有该领域专家和关键维护者的支持,比如Kubernetes, Prometheus, gRPC,Envoy,OpenTracing等等。

Twistlock利用先进的智能,机器学习功能以及自动策略创建和执行功能,保护当今应用程序免受未来的威胁。作为第一个端到端的容器安全解决方案,Twistlock是专门为交付现代安全性而构建的。

Alcide提供网络安全平台,专为由多个编排系统运营的容器、虚拟机和裸金属数据中心组合而设计。Alcide通过简化和自动控制为DevOps,安全和工程团队授权,以管理和保护不断发展的数据中心和混合云。

23%的人表示,基于负载的扩展部署是一个挑战。这意味着许多需求得到满足Kubernetes实际上是在帮助扩展它应该做的事情。在列表的底部,10%的问题得到了供应商的支持。很少有人抱怨Kubernetes支持供应商的原因之一是,许多部署并不依赖于供应商的分销。展望未来,提供高质量服务的可能性很大,因为CNCF最近推出了Kubernetes认证服务供应商计划,确保服务提供商达到一定的能力。








超过40%的人认为安全、网络和存储是与容器相关的挑战。



偏大型的组织有更多的挑战

和其他研究一样,我们发现较大的组织更倾向于将许多问题列为他们所关心的挑战。例如,1000名或更多员工的组织中,有55%的人认为安全是一个挑战,而不到100名员工的组织中只有39%的人这么认为。这种情况下,与可靠性等其他类别一样,大型企业的需求与小企业不同。


在其他领域,例如网络,与仅使用容器数量相比,IT基础设施(带宽和站点数量)的规模和广度可能会给Kubernetes带来更多独特的挑战。事实上,在拥有6个或6个以上集群的组织中,以网络作为挑战的比例从42%上升到53%。


一些挑战不符合上述模式。对于存储,一种解释是技术“问题”不是基于可扩展性的。在监管方面,中型企业更有可能面临挑战。正如我们之前在文章中提到的,对容器运营的监控,小企业通常不需要创建正式的监控流程,而大型企业则有资源来创建更健壮的、自定义的监视系统。被困在中间的是那些拥有100到999名员工的企业。







图1.8:在拥有1000名或更多员工的组织中,安全与网络更大可能被列为与容器相关的挑战。
 


本地部署 VS 云部署

影响组织与容器相关的挑战的另一个因素是,它们是否只将容器部署到公有云或在本地服务器上。在只使用本地服务器的容器中,存储是最常见的挑战。这是因为这些企业需要管理自己的存储基础设施,甚至可能由一支独立的IT团队来处理。








图1.9:54%仅供本地使用的容器用户面临存储挑战,而只有34%的公有云组织面临存储挑战。


对于只在公有云上使用容器的组织来说,监控和日志记录常常被认为是一个挑战。尽管云供应商应该支持可扩展性,但只有使用本地服务器才能使用容器的组织很难说扩展部署是一项挑战。


CNCF的调查还询问了几种类型的云原生基础设施和工具,其中一些是专门针对与Kubernetes合作的。本系列的下一篇文章将讨论Kubernetes用户用来解决他们面临的挑战的最常用工具。



2

4种Kubernetes威胁模型

在Kubernetes环境中,通常有四种类型的威胁,不管部署模型是什么(有一些边界情况例外):


1.旨在危害Kubernetes控制的外部攻击:所有连接系统均存在此威胁。在Kubernetes集群环境中,这代表攻击者获得对系统的访问权限,或者损害某些会影响系统安全的控制。

2.受影响的容器或节点:如果Kubernetes控制的环境中存在恶意容器或集群内的恶意节点,那么对其他节点或集群有什么影响?你能否在节点和集群内有效地包含“爆炸半径”?

3.妥协的凭证:当Kubernetes管理员的凭据被泄露时会发生什么情况?这对集群有多大影响?

4.滥用合法权限:当系统配置错误,缺乏控制或操作不严密时,可能会发生这种情况。

这些不同的威胁可能会导致大量妥协和不受欢迎的情况,包括特权提升,敏感数据泄露,运营折中或违反合规政策。

KubeCon + CloudNativeCon会议聚集了采用者和技术专家,进一步推动云原生计算的教育和发展。供应商中立的特色领域由领域专家和关键维护者的支持,如Kubernetes,Prometheus, gRPC,Envoy,OpenTracing等等。


引起相当多关注的攻击场景之一是“爆炸半径”——受损容器对同一节点上的其他容器会造成多大的损害,或者受损的节点会对集群的其余部分造成多大的损害? 对于Kubernetes部署的所有安全考虑都是基于这些威胁模型以及最小化“爆炸半径”的需要。
 


外部攻击

在Kubernetes环境中,外部可访问的组件将受到外部攻击。这些组件可以包括API服务器、kubelet和etcd。

为了减轻外部攻击的威胁,确保只有必要的Kubernetes服务被公开。始终执行身份验证并为任何公开的服务配置正确的网络安全策略。
 


妥协的容器

最终,Kubernetes管理在容器中运行的工作负载。如果一个容器被破坏,问题是容器是否可以升级权限来控制其他容器或集群。

Kubernetes的隔离机制,比如命名空间或网络分割,以及一些内置的os级控制,调节容器可以访问的内容,可以帮助限制受影响的容器的影响。另一个控制用户应该注意的是限制能够以特权模式运行的容器数量的能力——如果一个特权容器被破坏,它将会比普通的容器造成更多的伤害。


妥协的凭证

当合法的用户凭证被破坏时,系统中可能有恶意用户。因此,正确地规范和限制用户对集群资源的访问并密切监视用户操作是非常重要的。

为了减少恶意用户的影响,需要强制执行最小权限访问、基于角色的访问控制或其他细粒度访问控制。
 


滥用特权

如果系统配置不正确,可能导致滥用用户权限。例如,如果网络策略不限制pods或命名空间之间访问,用户可能能够读取其他命名空间的通信流,而这些命名空间最初不应访问。

防止滥用特权的主要防御措施是适当强化。确保所有系统组件(如容器,pod,命名空间和kubelets)都得到了强化,以显著降低特权滥用的可能性。


另一个重要的防御是授权控制。Kubernetes支持插件架构,它允许包含复杂的授权逻辑。正确设计和实施授权;这是反对特权滥用最有效的武器之一。



原文链接:

1、The TopChallenges Kubernetes Users Face with Deployment

https://thenewstack.io/top-cha ... ment/

2、4 Threat Models for Kubernetes Deployment Security

https://www.tuicool.com/articles/AfI7RbQ 



相关阅读:


天啦噜!看国外大神如何用Docker+Jenkins&CI/CD打造微服务架构?

远离神乎其神,从Uber微服务看最佳实践如何炼成?
换个姿势学习Kubernetes运营,如何5个月在生产环境构建K8S?



添加小数微信:xiaoshu062

备注公司、姓名、职位

小数将拉您进入相应技术群 查看全部
导读:

在使用或部署Kubernetes时,人们面临着非常多的问题。虽然Kubernetes所面临的一些挑战是独一无二的,但更多挑战都是典型的使用大量技术所带来的成长中的痛苦。最近CNCF主导了一项有关“Kubernetes生态系统状况”的一项调研,对于当红炸子鸡Kubernetes来说,哪些方面的挑战是最突出的?小数还另外翻译了K8S环境中4种最可能的威胁模型。

1

“Kubernetes生态系统状况”阐述了在选择容器编排解决方案时不同标准的重要性,以及阻碍Kubernetes采用的主要因素。与安全性或资源优化等标准相比,扩展性成为编排解决方案的基本要求。其中最大的挑战是,使用Kubernetes经常需要改变IT组织的几个部分的角色或职责。


CNCF最近的调查询问到人们在使用或部署容器时面临的挑战。在我们对数据的独立分析中,我们将答案发布在“Kubernetes Deployment & Security Patterns”一文中,并将焦点集中于使用Kubernetes管理容器的组织。这提供了一种方法来说明Kubernetes用户所面临的问题。
 


安全、存储、网络是最重要的挑战

研究结果表明,在对Kubernetes的普遍批评中,复杂性仅仅是排在第五位的挑战。领先的是与基础设施相关的挑战。在Kubernetes用户中,有46%的人提到了安全问题,网络和存储排在第二和第三位。

KubeCon +CloudNativeCon会议召集了采用者和技术专家,进一步推进云原生计算的教育和发展。供应商中立的技术有该领域专家和关键维护者的支持,比如Kubernetes, Prometheus, gRPC,Envoy,OpenTracing等等。

Twistlock利用先进的智能,机器学习功能以及自动策略创建和执行功能,保护当今应用程序免受未来的威胁。作为第一个端到端的容器安全解决方案,Twistlock是专门为交付现代安全性而构建的。

Alcide提供网络安全平台,专为由多个编排系统运营的容器、虚拟机和裸金属数据中心组合而设计。Alcide通过简化和自动控制为DevOps,安全和工程团队授权,以管理和保护不断发展的数据中心和混合云。

23%的人表示,基于负载的扩展部署是一个挑战。这意味着许多需求得到满足Kubernetes实际上是在帮助扩展它应该做的事情。在列表的底部,10%的问题得到了供应商的支持。很少有人抱怨Kubernetes支持供应商的原因之一是,许多部署并不依赖于供应商的分销。展望未来,提供高质量服务的可能性很大,因为CNCF最近推出了Kubernetes认证服务供应商计划,确保服务提供商达到一定的能力。


微信图片_20180329103703.jpg



超过40%的人认为安全、网络和存储是与容器相关的挑战。



偏大型的组织有更多的挑战

和其他研究一样,我们发现较大的组织更倾向于将许多问题列为他们所关心的挑战。例如,1000名或更多员工的组织中,有55%的人认为安全是一个挑战,而不到100名员工的组织中只有39%的人这么认为。这种情况下,与可靠性等其他类别一样,大型企业的需求与小企业不同。


在其他领域,例如网络,与仅使用容器数量相比,IT基础设施(带宽和站点数量)的规模和广度可能会给Kubernetes带来更多独特的挑战。事实上,在拥有6个或6个以上集群的组织中,以网络作为挑战的比例从42%上升到53%。


一些挑战不符合上述模式。对于存储,一种解释是技术“问题”不是基于可扩展性的。在监管方面,中型企业更有可能面临挑战。正如我们之前在文章中提到的,对容器运营的监控,小企业通常不需要创建正式的监控流程,而大型企业则有资源来创建更健壮的、自定义的监视系统。被困在中间的是那些拥有100到999名员工的企业。

微信图片_20180329103205.jpg



图1.8:在拥有1000名或更多员工的组织中,安全与网络更大可能被列为与容器相关的挑战。
 


本地部署 VS 云部署

影响组织与容器相关的挑战的另一个因素是,它们是否只将容器部署到公有云或在本地服务器上。在只使用本地服务器的容器中,存储是最常见的挑战。这是因为这些企业需要管理自己的存储基础设施,甚至可能由一支独立的IT团队来处理。


微信图片_20180329103226.jpg



图1.9:54%仅供本地使用的容器用户面临存储挑战,而只有34%的公有云组织面临存储挑战。


对于只在公有云上使用容器的组织来说,监控和日志记录常常被认为是一个挑战。尽管云供应商应该支持可扩展性,但只有使用本地服务器才能使用容器的组织很难说扩展部署是一项挑战。


CNCF的调查还询问了几种类型的云原生基础设施和工具,其中一些是专门针对与Kubernetes合作的。本系列的下一篇文章将讨论Kubernetes用户用来解决他们面临的挑战的最常用工具。



2

4种Kubernetes威胁模型

在Kubernetes环境中,通常有四种类型的威胁,不管部署模型是什么(有一些边界情况例外):


1.旨在危害Kubernetes控制的外部攻击:所有连接系统均存在此威胁。在Kubernetes集群环境中,这代表攻击者获得对系统的访问权限,或者损害某些会影响系统安全的控制。

2.受影响的容器或节点:如果Kubernetes控制的环境中存在恶意容器或集群内的恶意节点,那么对其他节点或集群有什么影响?你能否在节点和集群内有效地包含“爆炸半径”?

3.妥协的凭证:当Kubernetes管理员的凭据被泄露时会发生什么情况?这对集群有多大影响?

4.滥用合法权限:当系统配置错误,缺乏控制或操作不严密时,可能会发生这种情况。

这些不同的威胁可能会导致大量妥协和不受欢迎的情况,包括特权提升,敏感数据泄露,运营折中或违反合规政策。

KubeCon + CloudNativeCon会议聚集了采用者和技术专家,进一步推动云原生计算的教育和发展。供应商中立的特色领域由领域专家和关键维护者的支持,如Kubernetes,Prometheus, gRPC,Envoy,OpenTracing等等。


引起相当多关注的攻击场景之一是“爆炸半径”——受损容器对同一节点上的其他容器会造成多大的损害,或者受损的节点会对集群的其余部分造成多大的损害? 对于Kubernetes部署的所有安全考虑都是基于这些威胁模型以及最小化“爆炸半径”的需要。
 


外部攻击

在Kubernetes环境中,外部可访问的组件将受到外部攻击。这些组件可以包括API服务器、kubelet和etcd。

为了减轻外部攻击的威胁,确保只有必要的Kubernetes服务被公开。始终执行身份验证并为任何公开的服务配置正确的网络安全策略。
 


妥协的容器

最终,Kubernetes管理在容器中运行的工作负载。如果一个容器被破坏,问题是容器是否可以升级权限来控制其他容器或集群。

Kubernetes的隔离机制,比如命名空间或网络分割,以及一些内置的os级控制,调节容器可以访问的内容,可以帮助限制受影响的容器的影响。另一个控制用户应该注意的是限制能够以特权模式运行的容器数量的能力——如果一个特权容器被破坏,它将会比普通的容器造成更多的伤害。


妥协的凭证

当合法的用户凭证被破坏时,系统中可能有恶意用户。因此,正确地规范和限制用户对集群资源的访问并密切监视用户操作是非常重要的。

为了减少恶意用户的影响,需要强制执行最小权限访问、基于角色的访问控制或其他细粒度访问控制。
 


滥用特权

如果系统配置不正确,可能导致滥用用户权限。例如,如果网络策略不限制pods或命名空间之间访问,用户可能能够读取其他命名空间的通信流,而这些命名空间最初不应访问。

防止滥用特权的主要防御措施是适当强化。确保所有系统组件(如容器,pod,命名空间和kubelets)都得到了强化,以显著降低特权滥用的可能性。


另一个重要的防御是授权控制。Kubernetes支持插件架构,它允许包含复杂的授权逻辑。正确设计和实施授权;这是反对特权滥用最有效的武器之一。



原文链接:

1、The TopChallenges Kubernetes Users Face with Deployment

https://thenewstack.io/top-cha ... ment/

2、4 Threat Models for Kubernetes Deployment Security

https://www.tuicool.com/articles/AfI7RbQ 



相关阅读:


天啦噜!看国外大神如何用Docker+Jenkins&CI/CD打造微服务架构?

远离神乎其神,从Uber微服务看最佳实践如何炼成?
换个姿势学习Kubernetes运营,如何5个月在生产环境构建K8S?



添加小数微信:xiaoshu062

备注公司、姓名、职位

小数将拉您进入相应技术群

换个姿势学习Kubernetes运营,如何5个月在生产环境构建K8S?

杨y 发表了文章 • 0 个评论 • 147 次浏览 • 2018-03-21 11:33 • 来自相关话题

在分布式系统上管理服务是运维团队面临的最困难的问题之一。在生产中突破新软件并学习如何可靠地运营是非常重要的。本文是一则实例,讲述为什么学习运营Kubernetes很重要,以及为什么很难。本文是关于Kubernetes bug导致的一小时中断故障的事后剖析。




为什么选择在Kubernetes之上构建?如何将Kubernetes集成到现有基础设施中?本文作者给出的方法是建立 (和改进) 对Kubernetes集群的可靠性的信任,以及构建在Kubernetes之上的抽象。

我们最近在Kubernetes之上构建了一个分布式的cron作业调度系统,这是一个令人兴奋的容器编排的新平台。Kubernetes现在非常流行,并且有许多令人兴奋的承诺:最令人兴奋的是,程序员不需要知道或关心他们的应用程序运行的是什么机器。

什么是Kubernetes?

Kubernetes是一个分布式系统,用于调度程序在集群中运行。你可以告诉Kubernetes运行一个程序的5个副本,它将在工作节点上动态调度它们。容器自动调度以增加利用率,节省资金,强大的deployment primitives允许逐步推出新的代码,安全上下文和网络策略允许企业以安全的方式运行多租户的工作负载。




Kubernetes有很多不同类型的调度能力。它可以调度长时间运行的HTTP服务、在集群中每台机器上运行的daemonsets、每小时运行的cron作业等等。

为什么是Kubernetes?

每个基础设施项目都是从业务需求开始的,我们的目标是提高现有分布式cron作业系统的可靠性和安全性。我们的要求是:




建立和运营一支小团队(只有2人在项目中全职工作)。

在20台机器上可靠地安排大约500个不同的cron作业。




我们决定在Kubernetes之上建立的几个原因:




希望构建一个现有的开源项目。

kubernetes包含一个分布式cron作业调度器,不必自己编写。

kubernetes是一个非常活跃的项目,经常接受捐赠。

kubernetes是用Go写的,很容易学。几乎所有Kubernetes的bug都是由团队中没有经验的程序员做的。




如果我们能够成功地运营Kubernetes,可以在未来的Kubernetes上构建,例如,目前正在开发基于kubernet的系统来训练机器学习模型。




我们以前使用Chronos作为cron作业调度系统,但它不再是满足可靠性要求,而且大部分都没有维护(在过去9个月中1次提交, 最后一次合并请求的时间是2016年3月))Chronos未维护的,我们认为不值得继续投资改善现有的集群。




如果你正考虑Kubernetes,请记住:不要仅仅因为其他公司在使用Kubernetes而使用它。建立一个可靠的集群需要花费大量的时间,使用它的业务案例并不是很突出。把你的时间用在聪明的方法上。

可靠性是什么意思?

说到运营服务,“可靠”这个词本身并没有什么意义。要讨论可靠性,首先需要建立一个SLO(服务级别目标)。




我们有三个主要目标:




99.99%的cron作业应该在预定运行时间的20分钟内开始运行。20分钟是一个很宽的窗口,但是我们采访了内部客户,没有人要求更高的精确度。

Jobs应该运行99.99%的时间(不被终止)。

向Kubernetes的迁移不会导致任何面向客户的事件。




这意味着:




Kubernetes API的短暂停机时间是可以接受的(如果停机10分钟,只要在5分钟内恢复即可)。

调度错误(cron作业运行完全丢失并且根本无法运行)是不可接受的。我们非常重视安排错误报告。

要谨慎对待pod evictions 和安全终止实例,以免作业过于频繁地终止。

需要一个好的迁移计划。

建立一个Kubernetes集群

我们建立第一个Kubernetes集群的基本方法是从零开始构建集群,而不是使用kubeadm或kops之类的工具。使用Puppet(常用的配置管理工具)调配了配置。从头开始构建很好,原因有两个:能够深入地集成Kubernetes在架构中,并且深入理解其内部。

 

我们希望将Kubernetes整合到现有的基础架构中。与现有系统无缝集成,以便进行日志记录,证书管理,加密,网络安全,监控,AWS实例管理,部署,数据库代理,内部DNS服务器,配置管理以及更多。整合所有这些系统有时需要一点创造力,但总体上比试图让kubeadm / kops成为我们想要的更容易。




在信任并了解如何操作这些现有系统后,我们希望继续在新的Kubernetes群集中使用。例如,安全证书管理是一个非常棘手的问题,已经有办法颁发和管理证书。通过适当的整合,我们避免了为Kubernetes创建新的CA。




准确了解设置的参数是如何影响Kubernetes设置的。例如,在配置用于身份验证的证书/CAs时,使用了超过12个参数。了解这些参数有助于在遇到身份验证问题时更容易调试设置。

对Kubernetes建立信心

在Kubernetes之初,团队中没有人使用过Kubernetes。如何从“没有人用过Kubernetes”到“我们有信心在生产中运行Kubernetes”?









战略0:与其他公司交谈




我们向其他公司询问了Kubernetes的经历。 他们都以不同的方式或在不同的环境中使用Kubernetes(运行HTTP服务,裸机,Google Kubernetes引擎等)。




在谈到Kubernetes这样庞大而复杂的系统时,重要的是认真思考自己的用例,做自己的实验,建立对自己环境的信心,并做出决定。 例如,你不该读这篇博客文章并得出结论:“Stripe正在成功使用Kubernetes,所以它也适用于我们!”

 

以下是我们在与几家运营Kubernetes集群的公司沟通后后学到的:




优先考虑企业etcd集群的可靠性(etcd是存储所有Kubernetes集群状态的地方)。

某些Kubernetes功能比其他功能更稳定,因此请小心Alpha功能。一些公司只有在稳定后才能使用稳定特性(例如,如果某个功能在1.8版本中保持稳定,则在使用它之前会等待1.9或1.10)。

考虑使用托管的Kubernetes系统,如GKE / AKS / EKS。从头开始建立高可用性Kubernetes系统是一项巨大的工作。 AWS在此项目中没有托管的Kubernetes服务,所以这不适合我们。

注意由覆盖网络/软件定义网络引入的额外网络延迟。




策略1:阅读代码。




我们计划很大程度上依赖于Kubernetes的一个组件,即cronjob控制器。这个组件当时处于alpha阶段,这让我们有点担心。我们在一个测试集群中尝试了它,但是如何判断它在生产中是否适合我们呢?




值得庆幸的是,所有cronjob控制器的核心功能只有400行Go。通过源代码快速读取显示:




cron作业控制器是一个无状态的服务(与其他Kubernetes组件一样,除了etcd)。

每10秒钟,这个控制器调用syncAll函数:go wait.Until(jm.syncAll,10 * time.Second,stopCh)

syncAll函数从Kubernetes API中获取所有cron作业,遍历该列表,确定下一步应该运行哪些作业,然后启动这些作业。




核心逻辑似乎相对容易理解。更重要的是,如果在这个控制器中有一个bug,它可能是我们可以修复的东西。




策略2:做负载测试




在开始认真构建集群之前,我们做了一些负载测试。我们并不担心Kubernetes集群能够处理多少节点(计划部署大约20个节点),但是确实想让某些Kubernetes能够处理我们希望运行的那么多的cron作业(大约每分钟50个)。




在一个3节点集群中运行了测试,创建了1000个cron作业,每个任务每分钟运行一次。这些工作中的每一个都简单地运行bash -c 'echo hello world'。我们选择简单的作业,是因为希望测试集群的调度和编排能力,而不是集群的总计算能力。









测试集群无法处理每分钟1000个cron作业。每个节点每秒最多只能启动一个pod,而集群能够每分钟运行200个cron作业。由于我们只希望每分钟运行大约50个cron作业,所以我们认为这些限制不是阻碍因素。




策略3:优先构建和测试高可用性etcd集群。




在设置Kubernetes时,最重要的事情之一就是运行etcd。Etcd是Kubernetes集群的核心,它是存储集群中所有数据的地方。除了etcd之外,其他一切都是无状态的。如果etcd没有运行,不能对Kubernetes集群进行任何更改(尽管现有的服务将继续运行!)




这张图显示了etcd是Kubernetes集群的核心——API服务器是etcd前面的无状态REST/认证端点,然后其他组件通过API服务器与etcd对话。 在运行时,有两个要点需要牢记:




设置复制,这样集群不会死如果你失去了一个节点。我们现在有三个etcd副本。

确保足够的I / O带宽。我们的etcd版本有一个问题,一个具有高fsync延迟的节点可能触发连续的leader elections,导致集群无法使用。通过确保所有节点的I/O带宽都比etcd的写入数量多,从而弥补了这一点。




 


设置复制不是一个设置-忘记操作。我们仔细地测试后发现可能会丢失一个etcd节点,并且集群优雅地恢复了。




以下是为建立etcd集群所做的一些工作:




设置复制

监控etcd服务是可用的

写一些简单的工具,以便轻松创建新的etcd节点,并加入到集群当中

编写一些简单的工具,以便我们可以轻松创建新的etcd节点并将它们加入到群集中

补丁etcd的高集成,这样我们可以在生产环境中运行超过1个 etcd集群

测试从一个etcd备份中恢复

测试可以在不停机情况下重建整个集群




很高兴很早就做了这个测试。某个周五的早晨,在我们的生产集群中,一个etcd节点停止了对ping的响应。我们得到了警报,终止了节点,带来了一个新的节点,加入到集群中,同时Kubernetes继续运行。




策略4:逐步将工作迁移到Kubernetes




我们的目标之一是将工作迁移到Kubernetes而不造成任何中断。成功进行生产迁移的秘诀不是避免犯错(这是不可能的),而是设计你的迁移以减少错误的影响。




我们很幸运有多种职位可以迁移到新集群,所以可以迁移一些低影响的工作岗位,接受一两次失败。




在开始迁移之前,构建了易于使用的工具,如果有必要,可以在不到五分钟的时间内在旧系统和新系统之间来回移动作业。这种简单的工具减少了错误的影响 - 如果迁移一个没有计划的依赖的工作,没有什么大不了的!可以将其移回原处,解决问题,然后再试。




以下是我们采用的整体迁移策略:




根据他们的重要程度大致排序

将一些重复的工作迁移到Kubernetes。如果发现新的情况,快速回滚,修复问题,然后重试。




策略5:调查 Kubernetes bug 并修复它们




我们在项目开始时制定了一个规则:如果Kubernetes做了一些意外的事情,必须调查,找出原因,并提出补救措施。




调查每个问题都很耗时,但很重要。如果只是简单地将Kubernetes的”古怪行为”看作是复杂的分布式系统的功能,我们担心,因为它们会被调用导致产生bug集群。




在使用了这种方法之后,我们发现并且修复了Kubernetes的几个bug。




以下是测试中发现的一些问题:




名称超过52个字符的Cronjob无法安排作业。

Pods有时会永远停留在挂起状态。

调度程序会每3个小时崩溃一次。

Flannel的hostgw后端没有替换过时的路由表项




修复这些bug让我们对Kubernetes项目的使用感觉好得多——不仅它运行得比较好,而且也接受补丁并有一个良好的PR审查过程。




Kubernetes有bug,像所有的软件一样。特别是,我们非常频繁地使用调度器(cron作业总是在创建新的pods),而调度器使用缓存有时会导致bug、回退和崩溃。缓存是困难的!但是代码库是可接近的,我们已经能够处理遇到的bug。




值得一提的是,Kubernetes的pod驱逐逻辑。Kubernetes有一个称为节点控制器的组件,它负责将pod驱逐出去,如果节点没有响应,则将它们移到另一个节点。allnodes会暂时无响应(例如,由于网络或配置问题),在这种情况下,Kubernetes可以终止集群中的所有pod。




如果运行的是大型Kubernetes集群,请仔细阅读节点控制器文档,仔细地考虑设置,并进行广泛测试。每次通过创建网络分区测试对这些设置的配置更改(例如,pod-驱逐超时),就会发生令人惊讶的事情。最好在测试中发现这些意外,而不是在生产中发现。




策略6:有意引起Kubernetes集群问题




之前讨论过在Stripe中进行游戏日练习。这个想法是要想出你最终会在生产中发生的情况,然后在生产中故意造成这些情况,从而确保能够处理它们。




在集群上进行了几次练习之后,经常发现诸如监视或配置错误等问题。很高兴在早期发现这些问题,而不是六个月后突然发现。




以下是运行的一些比赛日练习:




终止Kubernetes API服务器

终止所有Kubernetes API服务器并将其恢复(这非常有效)

终止etcd节点

从API服务器中关闭Kubernetes集群中的工作节点(以便它们无法通信)。这导致节点上的所有pods被迁移到其他节点。




很高兴看到Kubernetes如何应对我们投入的大量干扰。 Kubernetes的设计是为了适应错误 - 它有存储所有状态的etcd集群,一个只是该数据库的REST接口的API服务器,以及一个协调所有集群管理的无状态控制器集合。




如果任何Kubernetes核心组件(API服务器,控制器管理器或调度程序)被中断或重新启动,一旦它们出现,它们将从etcd读取相关状态并继续无缝运行。这是我们希望的事情之一,而且在实践中实际运作良好。




以下是测试中发现的一些问题:




“没有得到paged,来修复监控。“

“当销毁API服务器实例并将其恢复后,需要人工干预。最好解决这个问题。“

“有时执行etcd故障转移时,API服务器会启动超时请求,直至重新启动。”




在运行这些测试后,针对发现的问题开发了补救措施:改进了监控,发现了固定配置问题,并提交了Kubernetes bug。

使cron作业易于使用

简单地探讨一下我们是如何使基于kubernetes的系统易于使用的。




最初的目标是设计一个运行cron作业的系统,团队有信心运营和维护。一旦建立了对Kubernetes的信心,就需要工程师们轻松地配置和增加新的cron作业。我们开发了一个简单的YAML配置格式,这样用户就不需要了解Kubernetes的内部结构来使用这个系统。这是我们开发的格式:




name: job-name-here

kubernetes:

  schedule: '15 */2 * * *'

command:

- ruby

- "/path/to/script.rb"

resources:

  requests:

    cpu: 0.1

    memory: 128M

  limits:

    memory: 1024M




没有做什么特别的事情——我们编写了一个简单的程序,将这种格式转换为Kubernetes cron作业配置,将其应用于kubectl。




我们还编写了一个测试套件,以确保作业名称不会太长,并且所有名称都是惟一的。我们目前不使用cgroups来强化对大多数作业的内存限制,但计划将来推出。




我们的简单格式易于使用,而且由于自动生成了来自相同格式的Chronos和Kubernetes cron作业定义,所以在两个系统之间迁移作业非常简单。这是使我们的增量迁移工作良好的关键部分。将作业迁移到Kubernetes时,可以用一个简单的三行配置更改,在不到十分钟的时间内将其移回。

监控Kubernetes

监测Kubernetes集群的内部状态非常令人愉悦。我们使用kube-state-metrics软件包进行监测,并使用一个名为veneurl - Prometheus的小型Go程序来获取Prometheus的度量标准,将它们作为statsd指标发布到我们的监控系统中。









例如,以下是过去一小时内集群中未决Pod的数量图表。Pending意味着等待分配一个工作节点来运行。可以看到上午11点的数字峰值,很多cron作业在每小时的第0分钟运行。

还有一个监视器,用于检查有没有任何Pod在Pending状态中卡住 - 每个Pod在5分钟内开始在worker节点上运行,否则会收到警报。

Kubernetes未来计划

设置Kubernetes,到顺畅地运行生产代码并将所有cron作业迁移到新集群,花了五个月的时间,三位工程师全职工作。我们投资学习Kubernetes的一个重要原因是希望能够在Stripe中更广泛地使用Kubernetes。




以下是适用于运行Kubernetes(或任何其他复杂分布式系统)的原则:




为企业的Kubernetes项目,以及所有基础设施项目,定义清晰的商业原因。了解业务案例和用户的需求使项目变得更加容易。

积极削减范围。避免使用许多Kubernetes的基本特性来简化集群。这让我们可以更快速地发送消息,例如,由于pod-to-pod联网不是我们项目的必需条件,可以关闭节点之间的所有网络连接,并将Kubernetes的网络安全性推迟。




花大量时间学习如何正确地运营Kubernetes集群。仔细测试边界情况。分布式系统非常复杂,有很多潜在的问题。以前面的例子为例:如果节点控制器由于配置与API服务器失去联系,那么它可以杀死集群中的所有pods。学习Kubernetes在每次配置更改后的表现如何,需要时间和精心的关注。




通过专注于这些原则,我们已经有信心在生产中使用Kubernetes。我们将继续开发Kubernetes的使用,例如,我们正在关注AWS EKS的发布。我们正在完成另一个系统的工作,训练机器学习模型,并且正在探索将一些HTTP服务迁移到Kubernetes。随着我们继续在生产中运行Kubernetes时,我们计划对开源项目做出贡献。

 







原文作者:Julia Evans

原文链接:

Learning to operate Kubernetes reliably

https://stripe.com/blog/operating-kubernetes
  查看全部
在分布式系统上管理服务是运维团队面临的最困难的问题之一。在生产中突破新软件并学习如何可靠地运营是非常重要的。本文是一则实例,讲述为什么学习运营Kubernetes很重要,以及为什么很难。本文是关于Kubernetes bug导致的一小时中断故障的事后剖析。




为什么选择在Kubernetes之上构建?如何将Kubernetes集成到现有基础设施中?本文作者给出的方法是建立 (和改进) 对Kubernetes集群的可靠性的信任,以及构建在Kubernetes之上的抽象。

我们最近在Kubernetes之上构建了一个分布式的cron作业调度系统,这是一个令人兴奋的容器编排的新平台。Kubernetes现在非常流行,并且有许多令人兴奋的承诺:最令人兴奋的是,程序员不需要知道或关心他们的应用程序运行的是什么机器。

什么是Kubernetes?

Kubernetes是一个分布式系统,用于调度程序在集群中运行。你可以告诉Kubernetes运行一个程序的5个副本,它将在工作节点上动态调度它们。容器自动调度以增加利用率,节省资金,强大的deployment primitives允许逐步推出新的代码,安全上下文和网络策略允许企业以安全的方式运行多租户的工作负载。




Kubernetes有很多不同类型的调度能力。它可以调度长时间运行的HTTP服务、在集群中每台机器上运行的daemonsets、每小时运行的cron作业等等。

为什么是Kubernetes?

每个基础设施项目都是从业务需求开始的,我们的目标是提高现有分布式cron作业系统的可靠性和安全性。我们的要求是:




建立和运营一支小团队(只有2人在项目中全职工作)。

在20台机器上可靠地安排大约500个不同的cron作业。




我们决定在Kubernetes之上建立的几个原因:




希望构建一个现有的开源项目。

kubernetes包含一个分布式cron作业调度器,不必自己编写。

kubernetes是一个非常活跃的项目,经常接受捐赠。

kubernetes是用Go写的,很容易学。几乎所有Kubernetes的bug都是由团队中没有经验的程序员做的。




如果我们能够成功地运营Kubernetes,可以在未来的Kubernetes上构建,例如,目前正在开发基于kubernet的系统来训练机器学习模型。




我们以前使用Chronos作为cron作业调度系统,但它不再是满足可靠性要求,而且大部分都没有维护(在过去9个月中1次提交, 最后一次合并请求的时间是2016年3月))Chronos未维护的,我们认为不值得继续投资改善现有的集群。




如果你正考虑Kubernetes,请记住:不要仅仅因为其他公司在使用Kubernetes而使用它。建立一个可靠的集群需要花费大量的时间,使用它的业务案例并不是很突出。把你的时间用在聪明的方法上。

可靠性是什么意思?

说到运营服务,“可靠”这个词本身并没有什么意义。要讨论可靠性,首先需要建立一个SLO(服务级别目标)。




我们有三个主要目标:




99.99%的cron作业应该在预定运行时间的20分钟内开始运行。20分钟是一个很宽的窗口,但是我们采访了内部客户,没有人要求更高的精确度。

Jobs应该运行99.99%的时间(不被终止)。

向Kubernetes的迁移不会导致任何面向客户的事件。




这意味着:




Kubernetes API的短暂停机时间是可以接受的(如果停机10分钟,只要在5分钟内恢复即可)。

调度错误(cron作业运行完全丢失并且根本无法运行)是不可接受的。我们非常重视安排错误报告。

要谨慎对待pod evictions 和安全终止实例,以免作业过于频繁地终止。

需要一个好的迁移计划。

建立一个Kubernetes集群

我们建立第一个Kubernetes集群的基本方法是从零开始构建集群,而不是使用kubeadm或kops之类的工具。使用Puppet(常用的配置管理工具)调配了配置。从头开始构建很好,原因有两个:能够深入地集成Kubernetes在架构中,并且深入理解其内部。

 

我们希望将Kubernetes整合到现有的基础架构中。与现有系统无缝集成,以便进行日志记录,证书管理,加密,网络安全,监控,AWS实例管理,部署,数据库代理,内部DNS服务器,配置管理以及更多。整合所有这些系统有时需要一点创造力,但总体上比试图让kubeadm / kops成为我们想要的更容易。




在信任并了解如何操作这些现有系统后,我们希望继续在新的Kubernetes群集中使用。例如,安全证书管理是一个非常棘手的问题,已经有办法颁发和管理证书。通过适当的整合,我们避免了为Kubernetes创建新的CA。




准确了解设置的参数是如何影响Kubernetes设置的。例如,在配置用于身份验证的证书/CAs时,使用了超过12个参数。了解这些参数有助于在遇到身份验证问题时更容易调试设置。

对Kubernetes建立信心

在Kubernetes之初,团队中没有人使用过Kubernetes。如何从“没有人用过Kubernetes”到“我们有信心在生产中运行Kubernetes”?


112.jpg




战略0:与其他公司交谈




我们向其他公司询问了Kubernetes的经历。 他们都以不同的方式或在不同的环境中使用Kubernetes(运行HTTP服务,裸机,Google Kubernetes引擎等)。




在谈到Kubernetes这样庞大而复杂的系统时,重要的是认真思考自己的用例,做自己的实验,建立对自己环境的信心,并做出决定。 例如,你不该读这篇博客文章并得出结论:“Stripe正在成功使用Kubernetes,所以它也适用于我们!”

 

以下是我们在与几家运营Kubernetes集群的公司沟通后后学到的:




优先考虑企业etcd集群的可靠性(etcd是存储所有Kubernetes集群状态的地方)。

某些Kubernetes功能比其他功能更稳定,因此请小心Alpha功能。一些公司只有在稳定后才能使用稳定特性(例如,如果某个功能在1.8版本中保持稳定,则在使用它之前会等待1.9或1.10)。

考虑使用托管的Kubernetes系统,如GKE / AKS / EKS。从头开始建立高可用性Kubernetes系统是一项巨大的工作。 AWS在此项目中没有托管的Kubernetes服务,所以这不适合我们。

注意由覆盖网络/软件定义网络引入的额外网络延迟。




策略1:阅读代码。




我们计划很大程度上依赖于Kubernetes的一个组件,即cronjob控制器。这个组件当时处于alpha阶段,这让我们有点担心。我们在一个测试集群中尝试了它,但是如何判断它在生产中是否适合我们呢?




值得庆幸的是,所有cronjob控制器的核心功能只有400行Go。通过源代码快速读取显示:




cron作业控制器是一个无状态的服务(与其他Kubernetes组件一样,除了etcd)。

每10秒钟,这个控制器调用syncAll函数:go wait.Until(jm.syncAll,10 * time.Second,stopCh)

syncAll函数从Kubernetes API中获取所有cron作业,遍历该列表,确定下一步应该运行哪些作业,然后启动这些作业。




核心逻辑似乎相对容易理解。更重要的是,如果在这个控制器中有一个bug,它可能是我们可以修复的东西。




策略2:做负载测试




在开始认真构建集群之前,我们做了一些负载测试。我们并不担心Kubernetes集群能够处理多少节点(计划部署大约20个节点),但是确实想让某些Kubernetes能够处理我们希望运行的那么多的cron作业(大约每分钟50个)。




在一个3节点集群中运行了测试,创建了1000个cron作业,每个任务每分钟运行一次。这些工作中的每一个都简单地运行bash -c 'echo hello world'。我们选择简单的作业,是因为希望测试集群的调度和编排能力,而不是集群的总计算能力。



113.jpg



测试集群无法处理每分钟1000个cron作业。每个节点每秒最多只能启动一个pod,而集群能够每分钟运行200个cron作业。由于我们只希望每分钟运行大约50个cron作业,所以我们认为这些限制不是阻碍因素。




策略3:优先构建和测试高可用性etcd集群。




在设置Kubernetes时,最重要的事情之一就是运行etcd。Etcd是Kubernetes集群的核心,它是存储集群中所有数据的地方。除了etcd之外,其他一切都是无状态的。如果etcd没有运行,不能对Kubernetes集群进行任何更改(尽管现有的服务将继续运行!)




这张图显示了etcd是Kubernetes集群的核心——API服务器是etcd前面的无状态REST/认证端点,然后其他组件通过API服务器与etcd对话。 在运行时,有两个要点需要牢记:




设置复制,这样集群不会死如果你失去了一个节点。我们现在有三个etcd副本。

确保足够的I / O带宽。我们的etcd版本有一个问题,一个具有高fsync延迟的节点可能触发连续的leader elections,导致集群无法使用。通过确保所有节点的I/O带宽都比etcd的写入数量多,从而弥补了这一点。




 


设置复制不是一个设置-忘记操作。我们仔细地测试后发现可能会丢失一个etcd节点,并且集群优雅地恢复了。




以下是为建立etcd集群所做的一些工作:




设置复制

监控etcd服务是可用的

写一些简单的工具,以便轻松创建新的etcd节点,并加入到集群当中

编写一些简单的工具,以便我们可以轻松创建新的etcd节点并将它们加入到群集中

补丁etcd的高集成,这样我们可以在生产环境中运行超过1个 etcd集群

测试从一个etcd备份中恢复

测试可以在不停机情况下重建整个集群




很高兴很早就做了这个测试。某个周五的早晨,在我们的生产集群中,一个etcd节点停止了对ping的响应。我们得到了警报,终止了节点,带来了一个新的节点,加入到集群中,同时Kubernetes继续运行。




策略4:逐步将工作迁移到Kubernetes




我们的目标之一是将工作迁移到Kubernetes而不造成任何中断。成功进行生产迁移的秘诀不是避免犯错(这是不可能的),而是设计你的迁移以减少错误的影响。




我们很幸运有多种职位可以迁移到新集群,所以可以迁移一些低影响的工作岗位,接受一两次失败。




在开始迁移之前,构建了易于使用的工具,如果有必要,可以在不到五分钟的时间内在旧系统和新系统之间来回移动作业。这种简单的工具减少了错误的影响 - 如果迁移一个没有计划的依赖的工作,没有什么大不了的!可以将其移回原处,解决问题,然后再试。




以下是我们采用的整体迁移策略:




根据他们的重要程度大致排序

将一些重复的工作迁移到Kubernetes。如果发现新的情况,快速回滚,修复问题,然后重试。




策略5:调查 Kubernetes bug 并修复它们




我们在项目开始时制定了一个规则:如果Kubernetes做了一些意外的事情,必须调查,找出原因,并提出补救措施。




调查每个问题都很耗时,但很重要。如果只是简单地将Kubernetes的”古怪行为”看作是复杂的分布式系统的功能,我们担心,因为它们会被调用导致产生bug集群。




在使用了这种方法之后,我们发现并且修复了Kubernetes的几个bug。




以下是测试中发现的一些问题:




名称超过52个字符的Cronjob无法安排作业。

Pods有时会永远停留在挂起状态。

调度程序会每3个小时崩溃一次。

Flannel的hostgw后端没有替换过时的路由表项




修复这些bug让我们对Kubernetes项目的使用感觉好得多——不仅它运行得比较好,而且也接受补丁并有一个良好的PR审查过程。




Kubernetes有bug,像所有的软件一样。特别是,我们非常频繁地使用调度器(cron作业总是在创建新的pods),而调度器使用缓存有时会导致bug、回退和崩溃。缓存是困难的!但是代码库是可接近的,我们已经能够处理遇到的bug。




值得一提的是,Kubernetes的pod驱逐逻辑。Kubernetes有一个称为节点控制器的组件,它负责将pod驱逐出去,如果节点没有响应,则将它们移到另一个节点。allnodes会暂时无响应(例如,由于网络或配置问题),在这种情况下,Kubernetes可以终止集群中的所有pod。




如果运行的是大型Kubernetes集群,请仔细阅读节点控制器文档,仔细地考虑设置,并进行广泛测试。每次通过创建网络分区测试对这些设置的配置更改(例如,pod-驱逐超时),就会发生令人惊讶的事情。最好在测试中发现这些意外,而不是在生产中发现。




策略6:有意引起Kubernetes集群问题




之前讨论过在Stripe中进行游戏日练习。这个想法是要想出你最终会在生产中发生的情况,然后在生产中故意造成这些情况,从而确保能够处理它们。




在集群上进行了几次练习之后,经常发现诸如监视或配置错误等问题。很高兴在早期发现这些问题,而不是六个月后突然发现。




以下是运行的一些比赛日练习:




终止Kubernetes API服务器

终止所有Kubernetes API服务器并将其恢复(这非常有效)

终止etcd节点

从API服务器中关闭Kubernetes集群中的工作节点(以便它们无法通信)。这导致节点上的所有pods被迁移到其他节点。




很高兴看到Kubernetes如何应对我们投入的大量干扰。 Kubernetes的设计是为了适应错误 - 它有存储所有状态的etcd集群,一个只是该数据库的REST接口的API服务器,以及一个协调所有集群管理的无状态控制器集合。




如果任何Kubernetes核心组件(API服务器,控制器管理器或调度程序)被中断或重新启动,一旦它们出现,它们将从etcd读取相关状态并继续无缝运行。这是我们希望的事情之一,而且在实践中实际运作良好。




以下是测试中发现的一些问题:




“没有得到paged,来修复监控。“

“当销毁API服务器实例并将其恢复后,需要人工干预。最好解决这个问题。“

“有时执行etcd故障转移时,API服务器会启动超时请求,直至重新启动。”




在运行这些测试后,针对发现的问题开发了补救措施:改进了监控,发现了固定配置问题,并提交了Kubernetes bug。

使cron作业易于使用

简单地探讨一下我们是如何使基于kubernetes的系统易于使用的。




最初的目标是设计一个运行cron作业的系统,团队有信心运营和维护。一旦建立了对Kubernetes的信心,就需要工程师们轻松地配置和增加新的cron作业。我们开发了一个简单的YAML配置格式,这样用户就不需要了解Kubernetes的内部结构来使用这个系统。这是我们开发的格式:




name: job-name-here

kubernetes:

  schedule: '15 */2 * * *'

command:

- ruby

- "/path/to/script.rb"

resources:

  requests:

    cpu: 0.1

    memory: 128M

  limits:

    memory: 1024M




没有做什么特别的事情——我们编写了一个简单的程序,将这种格式转换为Kubernetes cron作业配置,将其应用于kubectl。




我们还编写了一个测试套件,以确保作业名称不会太长,并且所有名称都是惟一的。我们目前不使用cgroups来强化对大多数作业的内存限制,但计划将来推出。




我们的简单格式易于使用,而且由于自动生成了来自相同格式的Chronos和Kubernetes cron作业定义,所以在两个系统之间迁移作业非常简单。这是使我们的增量迁移工作良好的关键部分。将作业迁移到Kubernetes时,可以用一个简单的三行配置更改,在不到十分钟的时间内将其移回。

监控Kubernetes

监测Kubernetes集群的内部状态非常令人愉悦。我们使用kube-state-metrics软件包进行监测,并使用一个名为veneurl - Prometheus的小型Go程序来获取Prometheus的度量标准,将它们作为statsd指标发布到我们的监控系统中。



111.jpg



例如,以下是过去一小时内集群中未决Pod的数量图表。Pending意味着等待分配一个工作节点来运行。可以看到上午11点的数字峰值,很多cron作业在每小时的第0分钟运行。

还有一个监视器,用于检查有没有任何Pod在Pending状态中卡住 - 每个Pod在5分钟内开始在worker节点上运行,否则会收到警报。

Kubernetes未来计划

设置Kubernetes,到顺畅地运行生产代码并将所有cron作业迁移到新集群,花了五个月的时间,三位工程师全职工作。我们投资学习Kubernetes的一个重要原因是希望能够在Stripe中更广泛地使用Kubernetes。




以下是适用于运行Kubernetes(或任何其他复杂分布式系统)的原则:




为企业的Kubernetes项目,以及所有基础设施项目,定义清晰的商业原因。了解业务案例和用户的需求使项目变得更加容易。

积极削减范围。避免使用许多Kubernetes的基本特性来简化集群。这让我们可以更快速地发送消息,例如,由于pod-to-pod联网不是我们项目的必需条件,可以关闭节点之间的所有网络连接,并将Kubernetes的网络安全性推迟。




花大量时间学习如何正确地运营Kubernetes集群。仔细测试边界情况。分布式系统非常复杂,有很多潜在的问题。以前面的例子为例:如果节点控制器由于配置与API服务器失去联系,那么它可以杀死集群中的所有pods。学习Kubernetes在每次配置更改后的表现如何,需要时间和精心的关注。




通过专注于这些原则,我们已经有信心在生产中使用Kubernetes。我们将继续开发Kubernetes的使用,例如,我们正在关注AWS EKS的发布。我们正在完成另一个系统的工作,训练机器学习模型,并且正在探索将一些HTTP服务迁移到Kubernetes。随着我们继续在生产中运行Kubernetes时,我们计划对开源项目做出贡献。

 







原文作者:Julia Evans

原文链接:

Learning to operate Kubernetes reliably

https://stripe.com/blog/operating-kubernetes
 

kubernetes落地 |不捧不踩,国外公司向Kubernetes迁移实践

dataman 发表了文章 • 0 个评论 • 141 次浏览 • 2018-03-16 10:50 • 来自相关话题

导读:

Kubernetes一骑绝尘开挂来,那么企业应该开始向Kubernetes迁移吗?什么情况下真正的接受它?一些技术前沿公司先行一步的实践恐怕最有说服力和参考价值。本文即是一则很好的参考。



1

Kubernetes如今风靡一时,它是庞大的云原生运动中的一部分。所有主要的云提供商都将其作为部署云原生应用的解决方案。就在几个星期前,AWS重新推出了EKS(Amazon Elastic Container Service for Kubernetes),这是一个完全托管的Kubernetes集群。

这是一个巨大的进步,因为AWS是最大的公有云提供商,大多数Kubernetes的部署都在AWS上。官方kops工具用于部署和管理Kubernetes集群,目前已准备就绪。随着Kubernetes越来越受欢迎,企业正在努力接受它,希望借助Kubernetes解决许多常见问题。

那么,企业真的应该开始向Kubernetes迁移吗?什么情况下真正的接受它?本篇文章,将试图回答这个问题,并给出迁移到K8S和云原生的一些挑战和建议。


The Problem 问题

今年早些时候,我们开始对Sematext云进行容器化部署,这看起来似乎非常简单。企业所要做的就是将所有应用程序打包,为其资源(如部署、服务等)创建一些Kubernetes配置,然后即可进行操作。然而,并不是那么容易。

问题主要在于,用于管理发布过程的所有东西都不适合云原生模式。企业的应用程序不是云原生的,就无法使用CI/CD部署管道,运行状况检查或使用监视工具来记录日志、指标和警报。企业的应用程序可能非常静态且部署复杂。这种复杂性不会随着迁移到Kubernetes而消失,只会让事情变得更糟。云原生意味着将操作系统从应用程序中解耦出来,这就是容器正在做的事情。

在软件行业的演进中,首先是瀑布流,然后是敏捷,如今有了DevOps管理。这是一个非常重要的难题,这里没有规则可循。每个团队使用最适合他们的方式,如果你想坚持现有的常规,没什么问题,请照常做。只需要确保你的日常工作适用于云原生,这意味着需要做出一些改变。要切换整个团队来接受DevOps原则并不容易,需要一些时间做准备。


The Solution解决方案

这不是一个需要盲目跟随的解决方案。它给出一个想法,并解释可能遇到的过程和问题。

第一步,首先对所有未使用的组件进行清理。软件在开发了几年之后,会变得非常复杂,因为总有更重要的事情要做——新功能、新产品修复等等。

其次,对Kubernetes readiness and liveness probes进行健康检查,这点不难。花费时间管理配置才是最难的部分。我的建议是利用配置地图(config maps)和secrets ,远离环境变量。你可以使用其中一部分,但不要仅使用环境变量来进行整个配置管理。应用程序应该充分发挥Kubernetes的潜力。


Kubernetes应用程序正在使用服务进行通信。在Kubernetes中有不同类型的服务,并将它们视为负载均衡器。定义的服务名称是你的端点http://service_name:port。如果正在使用有状态应用程序,会希望使用 headless services,能够访问特定的Pod。Kubernetes的服务也在某种程度上解决了服务发现问题。如果你已经使用了Consul之类的服务发现,恭喜你!可以坚持下去,并将它部署在Kubernetes上。

从Kubernetes的角度来看,在无状态应用程序下,应用程序容易扩展。使用部署作为资源,这种类型的服务还可以管理简单的升级-滚动更新。当然,你的应用程序需要在没有任何问题的情况下处理扩展,并且需要一些代码更改来实现它。

主要问题在于有状态的应用程序,如数据库。Kubernetes为这类应用程序提供了一种StatefulSet资源,但不知道在添加新节点或出现故障时,特定的应用程序应该如何反应,这是运维人员在管理时通常要做的事情。不过,编写Kubernetes的操作符不是多么困难的事情。

简而言之,操作符是Kubernetes custom resource definition(即CRD),可以自行编写或使用现有的。我们使用的是 Elastic search Operator,很乐意为这个项目做出贡献。我已经提出了一些pull requests。

你可能已经开始把所有的片段连接起来了。有两种计算资源:请求,它在一个节点上指定最小数量的空闲资源,用于Kubernetes调度程序运行特定的Pod,以及限制,这是Pod可以使用的最大计算资源数量。这一点非常重要,特别是对于Java应用程序来说。对于Java应用,还需要根据heap memory需求调整限制。根据对Docker CPU和内存限制的了解,我的建议是使用Java version 8u131或更新版本。

给你的应用标上标签——当需要监控容器和应用程序时,这真的很有用,而元数据信息通常就是如何通过选择器连接不同的资源。例如,部署和服务。

当开始编写Kubernetes配置文件时,你会觉得很好,并且认为维护不是什么大问题。但是,在尝试实现部署管道时,你会发现使用一堆配置文件是一个非常糟糕的想法。这时Helm可以拯救,Helm是一个用于打包Kubernetes应用程序的工具,我强烈推荐使用它来部署管道。诸如支持多种环境、依赖关系、版本控制、回滚和不同hooks(考虑DB迁移)就足够描述Helm的所有优点了。坏消息是你需要学习另一种工具,但它很容易学,值得你花时间。

企业不需要多个集群来搭建不同的环境,只需使用不同的Kubernetes命名空间。例如,为了创建一个新环境,只需要创建一个单独的命名空间,完成测试后把它删除,节省了大量时间和资金。但是,不要忘记安全。Kubectl就像集群中的根用户。让每个人都访问kubectl可能不是一个好主意。有时,创建一个全新的集群比管理RBAC更好,而这可能非常复杂。尽管如此,还是强烈建议使用RBAC。


那么,企业将如何为容器镜像、Helm packages等提供版本呢?这取决于自己的选择。最常用的方法是提交ID给镜像打标签,然后release tag。此时,需要将Docker镜像存储到某个地方,即私人或公共注册中心。我的建议是使用DockerHub。这或许是最具成本效益的。如果解决了所有问题,那么需要创建一个部署管道。企业可以使用Jenkins来部署所有内容,并将其作为DevOps的主要工具之一。

The Conclusion 结论

最近,人们关注的焦点是云原生,而并非仅仅Kubernetes本身。Kubernetes只是一个工具,我们向Kubernetes迁移Sematext云和Sematext的工作正在进行中。需要把它看作一个过程,这不是一项一次性的工作,也从来没有完全完成。

迁移到云原生和Kubernetes的过程,既困难又费时,但对企业的公司文化和软件非常有益。扩展不再是问题,基础设施只是代码和软件问题。拥抱Kubernetes,但要准备好面对挑战。




2

Kubernetes可以在任一环境下部署

在开始进行云原生开发和部署时,来看看Kubernetes所扮演的角色,以及如何从编排中获得更多的功能。

容器提供了将应用程序及其依赖与操作系统分离的能力。通过与虚拟机镜像不同的方式打包操作系统,容器节省了大量系统资源:计算、内存和磁盘空间。容器也更快地下载、更新、部署和迭代。因此,在技术领域,容器已经引起了一场小型革命,并被谷歌、微软和亚马逊等公司采用。


容器的小型革命也带来了激烈的竞争,以满足编排和管理的需要。Kubernetes,谷歌的开源容器编排工具,已经成为领先的解决方案(替代方案有有亚马逊ECS和DockerSwarm等),归功于三个主要原因:


云原生设计:支持部署和运行下一代应用程序。

开源特性:快速创新,避免厂商锁定。

可移植性:在任何地方部署,无论是在云中、on-premise、还是虚拟机中等等。

下图显示了Kubernetes在云原生部署中所扮演的角色:






Kubernetes容器编排

Kubernetes可以部署和管理容器应用,其中包括NGINX、MySQL、Apache和其他许多应用程序。它可以为容器提供布局、缩放、复制、监视和其他功能。


一旦选择了容器编排平台,下一步就是部署Kubernetes。如前所述,Kubernetes是一个可移植的解决方案。因为Kubernetes使用相同的镜像和配置,它在笔记本电脑上、云里、或在本地所使用的方式完全相同。

Kubernetes-as-a-Service

这些解决方案提供了在各种基础设施中部署Kubernetes的能力:公有云或内部部署。为Kubernetes集群选择这种方法的优势包括:

1.通过KaaS供应商进行升级、监控和支持。

2.轻松扩展混合云或多云环境。

3.多集群的单一窗格视图。

4.高可用性,多主Kubernetes集群,根据工作负载自动扩缩。

5.通用企业集成,如SSO /独立命名空间; 以及通过Helm图表部署应用程序的能力。

6.集群联合,提供跨多个云或数据中心的真正无缝混合环境。






Kubernetes-as-a-Service(Kubernetes即服务)


Kubernetes即服务的例子包括Platform9和StackPoint.io。


托管的基础设施

谷歌云平台和Microsoft Azure分别通过谷歌容器引擎(GKE)和Azure容器服务(ACS)提供Kubernetes。容器放置在公有云中可以快速启动,但是现在企业的数据将留存在网络防火墙之外。


谷歌GKE领导着其他公有云供应商。谷歌通过一个名为Borg的集群管理器,广泛地将容器用于内部项目,并拥有超过十年的开发经验(来源: TheNextPlatform)。相比之下,微软的ACS是一个更年轻的产品,Kubernetes支持仅在2017年2月才被引入。


然而,ACS提供了灵活性:用户可以选择容器编排平台(Kubernetes, Docker Swarm, DCOS),以及选择除了Linux以外,在Windows中部署容器化的应用程序的选项。如下所示,GKE和ACS完全基于公有云,Kubernetes服务和基础设施由托管提供商部署和管理。






Hosted Infrastructure for Kubernetes



本地部署

Minikube是在本地部署Kubernetes最流行的方式。它支持各种虚拟化管理程序,包括VirtualBox、VMware Fusion、KVM、xhyve和OSs,包括OSX、Windows和Linux。下面的插图进一步描述了Minikube的部署:


部署与Minikube

如上所示,用户使用Minikube CLI和Kubernetes的原生CLI Kubectl与笔记本电脑部署进行交互。 Minikube CLI可用于在虚拟机上启动,停止,删除,获取状态以及执行其他操作。一旦Minikube虚拟机启动,Kubectl CLI将在Kubernetes群集上执行操作。 以下命令启动现有的Minikube虚拟机并创建NGINX Kubernetes部署:#  minikube start
# cat > example.yaml<<EOF
apiVersion: apps/v1beta1
kind: Deployment
metadata:
 name: nginx-deployment
spec:
 replicas: 1
 template:
   metadata:
     labels:
       app: nginx
   spec:
     containers:
     - name: nginx
       image: nginx
       ports:
       - containerPort: 80
EOF
# kubectl create -f example.yaml(手动往下翻)


原文链接:

1、Embracing Kubernetes Successfully

https://sematext.com/blog/embr ... ully/

2、Deploy Kubernetes Anywhere

https://dzone.com/articles/dep ... where


推荐活动:

数人云联合ServiceComb、ServiceMesh社区举办的 Building Microservice Meetup系列活动第2站--3月31日,北京站开始报名啦!本期主题为《微服务,从架构到发布》依旧大咖汇集,点击最下方的“链接”快来报名~




相关阅读:

后Kubernetes时代,带你系统梳理K8S 12大关键特性

女神特辑 | 关于DevOps和职场,4位DevOps领域杰出女性都关注些啥?

有趣 | 马斯洛理论告诉你,Kubernetes可以满足微服务的这15大需求
  查看全部
导读:

Kubernetes一骑绝尘开挂来,那么企业应该开始向Kubernetes迁移吗?什么情况下真正的接受它?一些技术前沿公司先行一步的实践恐怕最有说服力和参考价值。本文即是一则很好的参考。



1

Kubernetes如今风靡一时,它是庞大的云原生运动中的一部分。所有主要的云提供商都将其作为部署云原生应用的解决方案。就在几个星期前,AWS重新推出了EKS(Amazon Elastic Container Service for Kubernetes),这是一个完全托管的Kubernetes集群。

这是一个巨大的进步,因为AWS是最大的公有云提供商,大多数Kubernetes的部署都在AWS上。官方kops工具用于部署和管理Kubernetes集群,目前已准备就绪。随着Kubernetes越来越受欢迎,企业正在努力接受它,希望借助Kubernetes解决许多常见问题。

那么,企业真的应该开始向Kubernetes迁移吗?什么情况下真正的接受它?本篇文章,将试图回答这个问题,并给出迁移到K8S和云原生的一些挑战和建议。


The Problem 问题

今年早些时候,我们开始对Sematext云进行容器化部署,这看起来似乎非常简单。企业所要做的就是将所有应用程序打包,为其资源(如部署、服务等)创建一些Kubernetes配置,然后即可进行操作。然而,并不是那么容易。

问题主要在于,用于管理发布过程的所有东西都不适合云原生模式。企业的应用程序不是云原生的,就无法使用CI/CD部署管道,运行状况检查或使用监视工具来记录日志、指标和警报。企业的应用程序可能非常静态且部署复杂。这种复杂性不会随着迁移到Kubernetes而消失,只会让事情变得更糟。云原生意味着将操作系统从应用程序中解耦出来,这就是容器正在做的事情。

在软件行业的演进中,首先是瀑布流,然后是敏捷,如今有了DevOps管理。这是一个非常重要的难题,这里没有规则可循。每个团队使用最适合他们的方式,如果你想坚持现有的常规,没什么问题,请照常做。只需要确保你的日常工作适用于云原生,这意味着需要做出一些改变。要切换整个团队来接受DevOps原则并不容易,需要一些时间做准备。


The Solution解决方案

这不是一个需要盲目跟随的解决方案。它给出一个想法,并解释可能遇到的过程和问题。

第一步,首先对所有未使用的组件进行清理。软件在开发了几年之后,会变得非常复杂,因为总有更重要的事情要做——新功能、新产品修复等等。

其次,对Kubernetes readiness and liveness probes进行健康检查,这点不难。花费时间管理配置才是最难的部分。我的建议是利用配置地图(config maps)和secrets ,远离环境变量。你可以使用其中一部分,但不要仅使用环境变量来进行整个配置管理。应用程序应该充分发挥Kubernetes的潜力。


Kubernetes应用程序正在使用服务进行通信。在Kubernetes中有不同类型的服务,并将它们视为负载均衡器。定义的服务名称是你的端点http://service_name:port。如果正在使用有状态应用程序,会希望使用 headless services,能够访问特定的Pod。Kubernetes的服务也在某种程度上解决了服务发现问题。如果你已经使用了Consul之类的服务发现,恭喜你!可以坚持下去,并将它部署在Kubernetes上。

从Kubernetes的角度来看,在无状态应用程序下,应用程序容易扩展。使用部署作为资源,这种类型的服务还可以管理简单的升级-滚动更新。当然,你的应用程序需要在没有任何问题的情况下处理扩展,并且需要一些代码更改来实现它。

主要问题在于有状态的应用程序,如数据库。Kubernetes为这类应用程序提供了一种StatefulSet资源,但不知道在添加新节点或出现故障时,特定的应用程序应该如何反应,这是运维人员在管理时通常要做的事情。不过,编写Kubernetes的操作符不是多么困难的事情。

简而言之,操作符是Kubernetes custom resource definition(即CRD),可以自行编写或使用现有的。我们使用的是 Elastic search Operator,很乐意为这个项目做出贡献。我已经提出了一些pull requests。

你可能已经开始把所有的片段连接起来了。有两种计算资源:请求,它在一个节点上指定最小数量的空闲资源,用于Kubernetes调度程序运行特定的Pod,以及限制,这是Pod可以使用的最大计算资源数量。这一点非常重要,特别是对于Java应用程序来说。对于Java应用,还需要根据heap memory需求调整限制。根据对Docker CPU和内存限制的了解,我的建议是使用Java version 8u131或更新版本。

给你的应用标上标签——当需要监控容器和应用程序时,这真的很有用,而元数据信息通常就是如何通过选择器连接不同的资源。例如,部署和服务。

当开始编写Kubernetes配置文件时,你会觉得很好,并且认为维护不是什么大问题。但是,在尝试实现部署管道时,你会发现使用一堆配置文件是一个非常糟糕的想法。这时Helm可以拯救,Helm是一个用于打包Kubernetes应用程序的工具,我强烈推荐使用它来部署管道。诸如支持多种环境、依赖关系、版本控制、回滚和不同hooks(考虑DB迁移)就足够描述Helm的所有优点了。坏消息是你需要学习另一种工具,但它很容易学,值得你花时间。

企业不需要多个集群来搭建不同的环境,只需使用不同的Kubernetes命名空间。例如,为了创建一个新环境,只需要创建一个单独的命名空间,完成测试后把它删除,节省了大量时间和资金。但是,不要忘记安全。Kubectl就像集群中的根用户。让每个人都访问kubectl可能不是一个好主意。有时,创建一个全新的集群比管理RBAC更好,而这可能非常复杂。尽管如此,还是强烈建议使用RBAC。


那么,企业将如何为容器镜像、Helm packages等提供版本呢?这取决于自己的选择。最常用的方法是提交ID给镜像打标签,然后release tag。此时,需要将Docker镜像存储到某个地方,即私人或公共注册中心。我的建议是使用DockerHub。这或许是最具成本效益的。如果解决了所有问题,那么需要创建一个部署管道。企业可以使用Jenkins来部署所有内容,并将其作为DevOps的主要工具之一。

The Conclusion 结论

最近,人们关注的焦点是云原生,而并非仅仅Kubernetes本身。Kubernetes只是一个工具,我们向Kubernetes迁移Sematext云和Sematext的工作正在进行中。需要把它看作一个过程,这不是一项一次性的工作,也从来没有完全完成。

迁移到云原生和Kubernetes的过程,既困难又费时,但对企业的公司文化和软件非常有益。扩展不再是问题,基础设施只是代码和软件问题。拥抱Kubernetes,但要准备好面对挑战。




2

Kubernetes可以在任一环境下部署

在开始进行云原生开发和部署时,来看看Kubernetes所扮演的角色,以及如何从编排中获得更多的功能。

容器提供了将应用程序及其依赖与操作系统分离的能力。通过与虚拟机镜像不同的方式打包操作系统,容器节省了大量系统资源:计算、内存和磁盘空间。容器也更快地下载、更新、部署和迭代。因此,在技术领域,容器已经引起了一场小型革命,并被谷歌、微软和亚马逊等公司采用。


容器的小型革命也带来了激烈的竞争,以满足编排和管理的需要。Kubernetes,谷歌的开源容器编排工具,已经成为领先的解决方案(替代方案有有亚马逊ECS和DockerSwarm等),归功于三个主要原因:


云原生设计:支持部署和运行下一代应用程序。

开源特性:快速创新,避免厂商锁定。

可移植性:在任何地方部署,无论是在云中、on-premise、还是虚拟机中等等。

下图显示了Kubernetes在云原生部署中所扮演的角色:

微信图片_20180316102623.jpg


Kubernetes容器编排

Kubernetes可以部署和管理容器应用,其中包括NGINX、MySQL、Apache和其他许多应用程序。它可以为容器提供布局、缩放、复制、监视和其他功能。


一旦选择了容器编排平台,下一步就是部署Kubernetes。如前所述,Kubernetes是一个可移植的解决方案。因为Kubernetes使用相同的镜像和配置,它在笔记本电脑上、云里、或在本地所使用的方式完全相同。

Kubernetes-as-a-Service

这些解决方案提供了在各种基础设施中部署Kubernetes的能力:公有云或内部部署。为Kubernetes集群选择这种方法的优势包括:

1.通过KaaS供应商进行升级、监控和支持。

2.轻松扩展混合云或多云环境。

3.多集群的单一窗格视图。

4.高可用性,多主Kubernetes集群,根据工作负载自动扩缩。

5.通用企业集成,如SSO /独立命名空间; 以及通过Helm图表部署应用程序的能力。

6.集群联合,提供跨多个云或数据中心的真正无缝混合环境。

微信图片_20180316102658.jpg


Kubernetes-as-a-Service(Kubernetes即服务)


Kubernetes即服务的例子包括Platform9和StackPoint.io。


托管的基础设施

谷歌云平台和Microsoft Azure分别通过谷歌容器引擎(GKE)和Azure容器服务(ACS)提供Kubernetes。容器放置在公有云中可以快速启动,但是现在企业的数据将留存在网络防火墙之外。


谷歌GKE领导着其他公有云供应商。谷歌通过一个名为Borg的集群管理器,广泛地将容器用于内部项目,并拥有超过十年的开发经验(来源: TheNextPlatform)。相比之下,微软的ACS是一个更年轻的产品,Kubernetes支持仅在2017年2月才被引入。


然而,ACS提供了灵活性:用户可以选择容器编排平台(Kubernetes, Docker Swarm, DCOS),以及选择除了Linux以外,在Windows中部署容器化的应用程序的选项。如下所示,GKE和ACS完全基于公有云,Kubernetes服务和基础设施由托管提供商部署和管理。

微信图片_20180316102938.jpg


Hosted Infrastructure for Kubernetes



本地部署

Minikube是在本地部署Kubernetes最流行的方式。它支持各种虚拟化管理程序,包括VirtualBox、VMware Fusion、KVM、xhyve和OSs,包括OSX、Windows和Linux。下面的插图进一步描述了Minikube的部署:


部署与Minikube

如上所示,用户使用Minikube CLI和Kubernetes的原生CLI Kubectl与笔记本电脑部署进行交互。 Minikube CLI可用于在虚拟机上启动,停止,删除,获取状态以及执行其他操作。一旦Minikube虚拟机启动,Kubectl CLI将在Kubernetes群集上执行操作。 以下命令启动现有的Minikube虚拟机并创建NGINX Kubernetes部署:#  minikube start
# cat > example.yaml<<EOF
apiVersion: apps/v1beta1
kind: Deployment
metadata:
 name: nginx-deployment
spec:
 replicas: 1
 template:
   metadata:
     labels:
       app: nginx
   spec:
     containers:
     - name: nginx
       image: nginx
       ports:
       - containerPort: 80
EOF
# kubectl create -f example.yaml(手动往下翻)


原文链接:

1、Embracing Kubernetes Successfully

https://sematext.com/blog/embr ... ully/

2、Deploy Kubernetes Anywhere

https://dzone.com/articles/dep ... where


推荐活动:

数人云联合ServiceComb、ServiceMesh社区举办的 Building Microservice Meetup系列活动第2站--3月31日,北京站开始报名啦!本期主题为《微服务,从架构到发布》依旧大咖汇集,点击最下方的“链接”快来报名~




相关阅读:

后Kubernetes时代,带你系统梳理K8S 12大关键特性

女神特辑 | 关于DevOps和职场,4位DevOps领域杰出女性都关注些啥?

有趣 | 马斯洛理论告诉你,Kubernetes可以满足微服务的这15大需求
 

【详解】以银行零售业务为例,一个案例说清楚可视化微服务架构

dataman 发表了文章 • 0 个评论 • 127 次浏览 • 2018-03-08 10:27 • 来自相关话题

Part 1: API设计和策略

软件系统的复杂性是一个很痛苦的问题,而且无法避免。Fred Brooks将复杂性描述为,软件系统解决业务问题所固有的本质复杂性,以及实施该解决方案所带来的偶发复杂性。

随着与采用“API优先”工程实践和微服务架构的组织进行更密切的合作,我发现这种描述越来越有用。首先,通过这种方式分离复杂性,它允许架构师和工程师专注于最小化系统的偶发复杂性。

与微服务相关的技术创新有很大帮助:容器,自动化工具和API管理平台。但我真正喜欢这种复杂性划分的原因是,它帮助我们认清一个事实:任何技术都不能降低系统的本质复杂性。

“开发软件产品的许多经典问题源于这种本质的复杂性,其非线性随着规模的增加而增加。” – 出自Fred Brooks著《No Silver Bullet—Essence & Accident in Software Engineering》

但是,我们能做的至少是理解和记录一个系统的本质复杂性。对于大多数技术人员来说,有效完成这一任务很重要,因为系统的本质复杂性不包括解决方案中使用的底层技术。

系统本质复杂性定义的本质要素是系统执行的任务和功能,以及执行所需的对象和交互。为了优化这种定义的认知负荷,将此定义表达为视觉模型也是很自然的。即使在可视化的情况下,软件架构师仍然努力保持模型中的元素不受技术限制,并且保持一致。

Eric Evans的领域驱动设计(Domain-Driven Design ,DDD)方法论突出的原因是,它提供了一种可视化定义软件系统本质复杂性的方法。特别是,显示域,子域,有界上下文及其相互关系的上下文映射,与我见过的以有效方式说明本质复杂性的任何方法都非常接近。 UML意在提供一种用于定义与技术无关的应用程序描述的手段,但它的许多模型自然偏向于面向对象的根源。事实上,如果你深入DDD工具箱,我认为你会遇到同样的偏见。

我在定义一个互连微服务系统时,使用了DDD上下文映射的派生。将在未来的文章中详细介绍这种方法。







示例上下文映射

为什么理解和记录软件系统的本质复杂性很重要,这与微服务有什么关系?随着微服务系统的发展和演变,其许多好处来自于服务本身的凝聚力。PhilCalçado在他的博客文章“微服务与分布式对象的第一定律(Microservices & the First Law of Distributed Objects)”中强调了这一需求。凝聚力是确定服务边界的产物,这是模拟系统本质复杂性的必要步骤。

有趣的是,与Brooks所描述的复杂性似乎是矛盾的,微服务系统的技术无关上下文映射在某种程度上与它的实现的拓扑结构是同构的,远远超过一整套单体应用的拓扑。这可能是一个巧合,也表明我们正在采用这种微服务架构方法。


Part 2:设计微服务系统

最近我一直在与许多大型组织合作,帮助他们理解并实现Web API和微服务体系结构的价值。在这项工作中,我看到这些组织一直在努力于,如何定义企业里微服务之间的最佳边界。这是一个已知的问题,但没有解决。虽然关于凝聚式服务(cohesive services)的价值和有界上下文已经写了很多,但如何实际识别这些内容似乎没有指导意义。

这个问题的一个原因是,试图确定服务边界的人是技术人员,他们天生就在寻找技术解决方案,但是定义凝聚力和能力一致性的服务边界(cohesive, capability-aligned service boundaries)却需要领域专家。从根本上说,这应该是一种建模练习,它独立于任何技术的覆盖。然而,即使那些有意识地采用了技术无关建模方法的组织,也一直在努力定义服务边界。

发生这种情况的部分原因是,最流行的软件建模方法往往存在实施偏差。例如,领域驱动设计(DDD)倾向于面向对象的编程,而UML偏向数据建模的角度。除此之外,业界还没有就如何直观地描绘微服务系统模型达成共识,诸如应该描述哪些组件,应该如何表示关系,应该使用什么术语,更不用说这其中的任何工具。

不过,所有的希望都不会丢失。 DDD的一些概念,最明显的是“有界上下文”( bounded contexts)的概念,已经获得了普及,并启动了关于服务边界定义的行业对话。重要的是,DDD方法论中更高层次的抽象,包括域,子域,有界上下文,聚合(aggregates),上下文映射,都是技术不可知和模型为中心的。

理解系统的方法是关注组件之间的关系,如果想要一个微服务系统的基本表示,不需要比上下文映射更深入。因此,也许我们可以使用DDD上下文映射作为可视化微服务系统的起点。

即使在上下文映射层面,大型组织的完整服务系统也是不可理解的。因此,为了使上下文映射有用,为上下文映射本身设置上下文非常重要。这种上下文可以是特定整体应用程序的分解,或特定计划的服务交互。连贯地构建一个大型组织的微服务系统的唯一方法就是,逐条地,上下文地进行。


微服务上下文映射示例

来看一个例子。一家大型零售银行希望引入以客户为中心的服务,以实现留住客户的战略目标。它希望提供一种新的以客户为中心的支付解决方案,允许客户根据他们与银行的关系(他们的账户,投资,资产,交互模式)进行购买,而不是将授权决策基于一个特定帐户。

零售银行业务本身就是一个复杂的业务领域。客户,产品和服务渠道(分支机构,网上银行,销售点)等实体之间存在相互关系,以及与财务透明度和数据隐私相关的强制性规定。因此,尽管这种新的支付服务背后的想法很直观,但它却呈现出一个复杂的问题空间。那么从哪里开始呢?

继DDD方法松散之后,我们可以首先将零售银行业务领域划分为子域。作为一个起点,并遵循康威法则的必然性,可以从组成零售银行的组织单位开始,并与以客户为中心的支付解决方案相关。这些是:

这些子域可以通过以下方式进行可视化描述:






这给了我们一个考虑如何分类创建以客户为中心的支付解决方案服务的起点。自助银行和客户与卡片管理子域名突出显示,因为它们已被确定为解决方案的关键子域名。使用DDD的“语言边界”概念,显然有一些有界上下文出现在子域中。

在自助银行内部,有两种截然不同的有界上下文。网上银行渠道与手机银行渠道有共同的语言,他们都提供个性化的客户体验,而支持移动渠道的应用程序则是由网络渠道构建和共享组件。我们将这种情况称为context Online Banking。另一方面,销售点具有独特的语言,更多地集中在设备管理和商家关系上。我们将称之为销售点(context Point of Sale)。

客户与卡片管理甚至更加分散。核心客户信息,包括银行客户的权威列表,他们的联系信息和产品库,形成了一个独特的词汇表,我们称之为客户信息有界的上下文。另一种不同的语言被用来描述卡功能,这主要与支付活动有关。这是“消费者支付和交易”上下文。最后,还有一个客户身份上下文专注于客户安全和访问控制。

产品子域名对于此付款解决方案并不重要,但值得注意的是零售贷款和贷款子域划分为单独的PLC账户和信用卡上下文。完整的相关有界上下文如下所示:






在确定了有界上下文之后,现在可以考虑顾客将在其中使用哪些服务。如前所述,网上银行有两种服务消费者:网上银行web App和手机银行App。新的支付解决方案也将通过销售点的POS网络收到的消息请求所消耗。

客户身份上下文必须提供客户身份验证服务,以确保只有合适的请求者才能访问新的付款服务。客户信息背景包含客户和产品持有人之间的交叉参考,因此需要核心客户信息服务来为新的支付解决方案提供这些数据。

除此之外,跟踪客户财务活动,与其产品持有相关的财务事件,将有助于做出授权决策。因此,客户活动分析服务可以在客户信息上下文中创建。

消费者支付和交易环境是为新的以客户为中心的支付解决方案建立核心服务的场所。首先,客户需要注册新产品并设置其帐户和产品偏好。为此,引入了以客户为中心的支付管理服务。

对于非功能性原因(例如性能,安全性和可用性),我们将创建一个单独的授权支付服务,称为以客户为中心的支付授权服务。最后,由于向客户帐户发布交易可以晚于授权决定发布,因此我们将创建与授权服务分离的交易发布服务(Transaction Posting Service)。


对于产品子域,我们只会在每个有界的上下文中引用单个同名服务。例如,存款账户上下文只包含一个存款账户服务。整个服务系统现在看起来像这样:






这个设计过程的最后一步是注释将发生在服务之间的交互。事实上,人们可能想要模拟有界上下文之间的相互作用,以便梳理出单个服务,但为了覆盖视觉效果,我们将最后描述这一步骤。在这个阶段举例说明所有可能的交互会造成视觉混淆,因此只会关注一些能够帮助理解系统如何运作的关键信息。这里有些例子:
 
客户使用网上银行Web应用程序通过以客户为中心的支付管理服务,注册并设置新支付解决方案的偏好;

以客户为中心的支付管理服务从客户信息服务中检索客户的产品组合;

客户活动分析服务使用来自产品系统的信息构建客户财务状况;

客户通过移动银行应用程序执行以客户为中心的支付,该应用程序称为以客户为中心的支付授权服务;

以客户为中心的支付授权服务,依次使用来自以客户为中心的支付管理服务和客户活动分析服务的信息构建授权配置文件;
 
一旦获得授权,支付将被转发至交易发布服务完成,然后调用相应的产品服务;

关于微服务系统有几点需要注意。首先,不要假定在为最终用户活动提供服务时,这些交互中的每一个都会实时发生。例如,尽管以客户为中心的授权服务需要来自其他一些服务的信息,但可以使用基于事件的方法结合缓存来确保其处理是独立的,以便实时服务客户的授权请求。

其次,可以在有界上下文之间建立防腐层(ACL),以提供松散的语义耦合。最后,虽然这是一个相当复杂的图片,但没有实现细节。换句话说,这种模式可以使用许多不同的技术来实现,包括语言,主机环境和网络协议。

最终的上下文映射(包括交互)如下所示:






最终,此系统设计过程的目的是,帮助企业如何在复杂解决方案中定义微服务的服务边界进行最佳猜测。希望这里的方法既能为服务建立一个良好的初始模型,又能更容易地重新绘制服务边界。


Part 3:微服务设计画布

微服务有自身的起源,通常从现有单体应用程序中涌现出来,以满足眼前的需求。提高交付速度的愿望推动了微服务的采用,开发人员通常采取“代码优先,问题排后”的方法,并重复实现有用的结果。这可行,但它是最佳的吗?回答这个问题会带来另一个问题:在开发微服务之前应该考虑哪些设计因素?正如软件架构师Simon Brown所说,“前期做大设计是愚蠢的,但没有前期的设计更愚蠢。”

借鉴精益画布(lean canvas )方法设计商业模型,介绍一下微服务设计画布。这个画布是一个工具,可以帮助企业在构建服务之前捕获服务中最重要的前端属性。画布采用了一种外部方法,它可以很好地将您的界面与其底层实现松散耦合。






你可以先在底部框中填写服务的自由格式“说明”。从这里开始,你应该完成“消费者任务”框,记录服务消费者需要执行的任务。列举服务的消费者以及他们需要执行的任务有助于明确服务的目的,并提供设计界面所需的材料输入。这些信息可以帮助填写“界面”框。在这里,消费者任务可以细分为与服务接口的特定交互。根据模式(查询,命令,事件)对交互进行分类,将有助于形成底层服务实现,并最终推动API的设计。

除了服务的任务和交互之外,还必须考虑服务的非功能方面。可以使用“质量(Qualities)”框来确定服务属性,例如可用性和性能级别,可扩展性方法和安全性期望。这将有助于消费者进一步了解服务,并影响其实施。总而言之,消费者的任务,界面和品质定义了服务的“表面”。这对系统的设计至关重要,因为它捕获了系统中其他利益相关者所需的最重要的信息。

在表面之下,还有一些关键的考虑因素。 “逻辑/规则”和“数据”框为服务设计人员提供了一个位置,以记录这些领域的关键因素。抵制在这个阶段太深的诱惑。没有必要为服务的工作编写一个完整的内部系统设计,但是可能需要感觉独特和支持表面属性所需的项目。最后,应列出服务“依赖关系”,以便调出服务需要的任务。对于具有相当数量业务逻辑的任务繁重的微服务,需要与更多面向数据的服务进行交互是很自然的。但是,本着微服务架构的精神,目标是最大限度地减少这些依赖关系。

来看几个示例画布。首先是以客户为中心的支付管理服务画布:






请注意,该服务看起来好像在交互中很直接,并且与其数据相对独立。 从非功能角度来看,这不是关键任务,也不需要最高级别的事务完整性。 因此,它的实现可能相当简单。

接下来是以客户为中心的支付授权服务的画布:






这项服务有一些更复杂的考虑因素。首先,它预计将是高容量和低延迟。这对服务的工程设计产生了明确的影响,需要复杂的授权信息缓存。其次,由于它的交互涉及金钱的流动,交易完整性和审计至关重要。最后,有一些事件交互意味着接口将超越典型的RESTful API。事实上,看到这些非功能性差异就清楚地说明,为什么将以客户为中心的支付解决方案的授权和管理功能,分解为单独的服务是一个很好的设计决策。在系统视图和服务视图之间迭代将有助于定义服务边界。

希望这个微服务设计画布可以成为着手微服务部署的企业的有用工具。它清楚地与API设计联系在一起。

作者:Matt McLarty

原文链接:

1、Visualizing Microservices: API Design and Strategy

https://dzone.com/articles/vis ... ategy

2、Visualizing Microservices: Designing a Microservice System

https://dzone.com/articles/vis ... rvice

3、Visualizing Microservices: The Microservice Design Canvas

https://dzone.com/articles/vis ... esign



相关阅读:
2018最难招聘的11类IT人员

悉数四代PaaS发展,一文理顺基础设施、平台和工作流之间的关系
悉数四代PaaS发展,一文理顺基础设施、平台和工作流之间的关系


添加小数微信:xiaoshu062

备注公司、姓名、职位

小数将拉您进入相应技术群 查看全部
Part 1: API设计和策略

软件系统的复杂性是一个很痛苦的问题,而且无法避免。Fred Brooks将复杂性描述为,软件系统解决业务问题所固有的本质复杂性,以及实施该解决方案所带来的偶发复杂性。

随着与采用“API优先”工程实践和微服务架构的组织进行更密切的合作,我发现这种描述越来越有用。首先,通过这种方式分离复杂性,它允许架构师和工程师专注于最小化系统的偶发复杂性。

与微服务相关的技术创新有很大帮助:容器,自动化工具和API管理平台。但我真正喜欢这种复杂性划分的原因是,它帮助我们认清一个事实:任何技术都不能降低系统的本质复杂性。

“开发软件产品的许多经典问题源于这种本质的复杂性,其非线性随着规模的增加而增加。” – 出自Fred Brooks著《No Silver Bullet—Essence & Accident in Software Engineering》

但是,我们能做的至少是理解和记录一个系统的本质复杂性。对于大多数技术人员来说,有效完成这一任务很重要,因为系统的本质复杂性不包括解决方案中使用的底层技术。

系统本质复杂性定义的本质要素是系统执行的任务和功能,以及执行所需的对象和交互。为了优化这种定义的认知负荷,将此定义表达为视觉模型也是很自然的。即使在可视化的情况下,软件架构师仍然努力保持模型中的元素不受技术限制,并且保持一致。

Eric Evans的领域驱动设计(Domain-Driven Design ,DDD)方法论突出的原因是,它提供了一种可视化定义软件系统本质复杂性的方法。特别是,显示域,子域,有界上下文及其相互关系的上下文映射,与我见过的以有效方式说明本质复杂性的任何方法都非常接近。 UML意在提供一种用于定义与技术无关的应用程序描述的手段,但它的许多模型自然偏向于面向对象的根源。事实上,如果你深入DDD工具箱,我认为你会遇到同样的偏见。

我在定义一个互连微服务系统时,使用了DDD上下文映射的派生。将在未来的文章中详细介绍这种方法。


0.jpg


示例上下文映射

为什么理解和记录软件系统的本质复杂性很重要,这与微服务有什么关系?随着微服务系统的发展和演变,其许多好处来自于服务本身的凝聚力。PhilCalçado在他的博客文章“微服务与分布式对象的第一定律(Microservices & the First Law of Distributed Objects)”中强调了这一需求。凝聚力是确定服务边界的产物,这是模拟系统本质复杂性的必要步骤。

有趣的是,与Brooks所描述的复杂性似乎是矛盾的,微服务系统的技术无关上下文映射在某种程度上与它的实现的拓扑结构是同构的,远远超过一整套单体应用的拓扑。这可能是一个巧合,也表明我们正在采用这种微服务架构方法。


Part 2:设计微服务系统

最近我一直在与许多大型组织合作,帮助他们理解并实现Web API和微服务体系结构的价值。在这项工作中,我看到这些组织一直在努力于,如何定义企业里微服务之间的最佳边界。这是一个已知的问题,但没有解决。虽然关于凝聚式服务(cohesive services)的价值和有界上下文已经写了很多,但如何实际识别这些内容似乎没有指导意义。

这个问题的一个原因是,试图确定服务边界的人是技术人员,他们天生就在寻找技术解决方案,但是定义凝聚力和能力一致性的服务边界(cohesive, capability-aligned service boundaries)却需要领域专家。从根本上说,这应该是一种建模练习,它独立于任何技术的覆盖。然而,即使那些有意识地采用了技术无关建模方法的组织,也一直在努力定义服务边界。

发生这种情况的部分原因是,最流行的软件建模方法往往存在实施偏差。例如,领域驱动设计(DDD)倾向于面向对象的编程,而UML偏向数据建模的角度。除此之外,业界还没有就如何直观地描绘微服务系统模型达成共识,诸如应该描述哪些组件,应该如何表示关系,应该使用什么术语,更不用说这其中的任何工具。

不过,所有的希望都不会丢失。 DDD的一些概念,最明显的是“有界上下文”( bounded contexts)的概念,已经获得了普及,并启动了关于服务边界定义的行业对话。重要的是,DDD方法论中更高层次的抽象,包括域,子域,有界上下文,聚合(aggregates),上下文映射,都是技术不可知和模型为中心的。

理解系统的方法是关注组件之间的关系,如果想要一个微服务系统的基本表示,不需要比上下文映射更深入。因此,也许我们可以使用DDD上下文映射作为可视化微服务系统的起点。

即使在上下文映射层面,大型组织的完整服务系统也是不可理解的。因此,为了使上下文映射有用,为上下文映射本身设置上下文非常重要。这种上下文可以是特定整体应用程序的分解,或特定计划的服务交互。连贯地构建一个大型组织的微服务系统的唯一方法就是,逐条地,上下文地进行。


微服务上下文映射示例

来看一个例子。一家大型零售银行希望引入以客户为中心的服务,以实现留住客户的战略目标。它希望提供一种新的以客户为中心的支付解决方案,允许客户根据他们与银行的关系(他们的账户,投资,资产,交互模式)进行购买,而不是将授权决策基于一个特定帐户。

零售银行业务本身就是一个复杂的业务领域。客户,产品和服务渠道(分支机构,网上银行,销售点)等实体之间存在相互关系,以及与财务透明度和数据隐私相关的强制性规定。因此,尽管这种新的支付服务背后的想法很直观,但它却呈现出一个复杂的问题空间。那么从哪里开始呢?

继DDD方法松散之后,我们可以首先将零售银行业务领域划分为子域。作为一个起点,并遵循康威法则的必然性,可以从组成零售银行的组织单位开始,并与以客户为中心的支付解决方案相关。这些是:

这些子域可以通过以下方式进行可视化描述:

1.jpg


这给了我们一个考虑如何分类创建以客户为中心的支付解决方案服务的起点。自助银行和客户与卡片管理子域名突出显示,因为它们已被确定为解决方案的关键子域名。使用DDD的“语言边界”概念,显然有一些有界上下文出现在子域中。

在自助银行内部,有两种截然不同的有界上下文。网上银行渠道与手机银行渠道有共同的语言,他们都提供个性化的客户体验,而支持移动渠道的应用程序则是由网络渠道构建和共享组件。我们将这种情况称为context Online Banking。另一方面,销售点具有独特的语言,更多地集中在设备管理和商家关系上。我们将称之为销售点(context Point of Sale)。

客户与卡片管理甚至更加分散。核心客户信息,包括银行客户的权威列表,他们的联系信息和产品库,形成了一个独特的词汇表,我们称之为客户信息有界的上下文。另一种不同的语言被用来描述卡功能,这主要与支付活动有关。这是“消费者支付和交易”上下文。最后,还有一个客户身份上下文专注于客户安全和访问控制。

产品子域名对于此付款解决方案并不重要,但值得注意的是零售贷款和贷款子域划分为单独的PLC账户和信用卡上下文。完整的相关有界上下文如下所示:

2.jpg


在确定了有界上下文之后,现在可以考虑顾客将在其中使用哪些服务。如前所述,网上银行有两种服务消费者:网上银行web App和手机银行App。新的支付解决方案也将通过销售点的POS网络收到的消息请求所消耗。

客户身份上下文必须提供客户身份验证服务,以确保只有合适的请求者才能访问新的付款服务。客户信息背景包含客户和产品持有人之间的交叉参考,因此需要核心客户信息服务来为新的支付解决方案提供这些数据。

除此之外,跟踪客户财务活动,与其产品持有相关的财务事件,将有助于做出授权决策。因此,客户活动分析服务可以在客户信息上下文中创建。

消费者支付和交易环境是为新的以客户为中心的支付解决方案建立核心服务的场所。首先,客户需要注册新产品并设置其帐户和产品偏好。为此,引入了以客户为中心的支付管理服务。

对于非功能性原因(例如性能,安全性和可用性),我们将创建一个单独的授权支付服务,称为以客户为中心的支付授权服务。最后,由于向客户帐户发布交易可以晚于授权决定发布,因此我们将创建与授权服务分离的交易发布服务(Transaction Posting Service)。


对于产品子域,我们只会在每个有界的上下文中引用单个同名服务。例如,存款账户上下文只包含一个存款账户服务。整个服务系统现在看起来像这样:

3.jpg


这个设计过程的最后一步是注释将发生在服务之间的交互。事实上,人们可能想要模拟有界上下文之间的相互作用,以便梳理出单个服务,但为了覆盖视觉效果,我们将最后描述这一步骤。在这个阶段举例说明所有可能的交互会造成视觉混淆,因此只会关注一些能够帮助理解系统如何运作的关键信息。这里有些例子:
 
客户使用网上银行Web应用程序通过以客户为中心的支付管理服务,注册并设置新支付解决方案的偏好;

以客户为中心的支付管理服务从客户信息服务中检索客户的产品组合;

客户活动分析服务使用来自产品系统的信息构建客户财务状况;

客户通过移动银行应用程序执行以客户为中心的支付,该应用程序称为以客户为中心的支付授权服务;

以客户为中心的支付授权服务,依次使用来自以客户为中心的支付管理服务和客户活动分析服务的信息构建授权配置文件;
 
一旦获得授权,支付将被转发至交易发布服务完成,然后调用相应的产品服务;

关于微服务系统有几点需要注意。首先,不要假定在为最终用户活动提供服务时,这些交互中的每一个都会实时发生。例如,尽管以客户为中心的授权服务需要来自其他一些服务的信息,但可以使用基于事件的方法结合缓存来确保其处理是独立的,以便实时服务客户的授权请求。

其次,可以在有界上下文之间建立防腐层(ACL),以提供松散的语义耦合。最后,虽然这是一个相当复杂的图片,但没有实现细节。换句话说,这种模式可以使用许多不同的技术来实现,包括语言,主机环境和网络协议。

最终的上下文映射(包括交互)如下所示:

4.jpg


最终,此系统设计过程的目的是,帮助企业如何在复杂解决方案中定义微服务的服务边界进行最佳猜测。希望这里的方法既能为服务建立一个良好的初始模型,又能更容易地重新绘制服务边界。


Part 3:微服务设计画布

微服务有自身的起源,通常从现有单体应用程序中涌现出来,以满足眼前的需求。提高交付速度的愿望推动了微服务的采用,开发人员通常采取“代码优先,问题排后”的方法,并重复实现有用的结果。这可行,但它是最佳的吗?回答这个问题会带来另一个问题:在开发微服务之前应该考虑哪些设计因素?正如软件架构师Simon Brown所说,“前期做大设计是愚蠢的,但没有前期的设计更愚蠢。”

借鉴精益画布(lean canvas )方法设计商业模型,介绍一下微服务设计画布。这个画布是一个工具,可以帮助企业在构建服务之前捕获服务中最重要的前端属性。画布采用了一种外部方法,它可以很好地将您的界面与其底层实现松散耦合。

5.jpg


你可以先在底部框中填写服务的自由格式“说明”。从这里开始,你应该完成“消费者任务”框,记录服务消费者需要执行的任务。列举服务的消费者以及他们需要执行的任务有助于明确服务的目的,并提供设计界面所需的材料输入。这些信息可以帮助填写“界面”框。在这里,消费者任务可以细分为与服务接口的特定交互。根据模式(查询,命令,事件)对交互进行分类,将有助于形成底层服务实现,并最终推动API的设计。

除了服务的任务和交互之外,还必须考虑服务的非功能方面。可以使用“质量(Qualities)”框来确定服务属性,例如可用性和性能级别,可扩展性方法和安全性期望。这将有助于消费者进一步了解服务,并影响其实施。总而言之,消费者的任务,界面和品质定义了服务的“表面”。这对系统的设计至关重要,因为它捕获了系统中其他利益相关者所需的最重要的信息。

在表面之下,还有一些关键的考虑因素。 “逻辑/规则”和“数据”框为服务设计人员提供了一个位置,以记录这些领域的关键因素。抵制在这个阶段太深的诱惑。没有必要为服务的工作编写一个完整的内部系统设计,但是可能需要感觉独特和支持表面属性所需的项目。最后,应列出服务“依赖关系”,以便调出服务需要的任务。对于具有相当数量业务逻辑的任务繁重的微服务,需要与更多面向数据的服务进行交互是很自然的。但是,本着微服务架构的精神,目标是最大限度地减少这些依赖关系。

来看几个示例画布。首先是以客户为中心的支付管理服务画布:

6.jpg


请注意,该服务看起来好像在交互中很直接,并且与其数据相对独立。 从非功能角度来看,这不是关键任务,也不需要最高级别的事务完整性。 因此,它的实现可能相当简单。

接下来是以客户为中心的支付授权服务的画布:

7.jpg


这项服务有一些更复杂的考虑因素。首先,它预计将是高容量和低延迟。这对服务的工程设计产生了明确的影响,需要复杂的授权信息缓存。其次,由于它的交互涉及金钱的流动,交易完整性和审计至关重要。最后,有一些事件交互意味着接口将超越典型的RESTful API。事实上,看到这些非功能性差异就清楚地说明,为什么将以客户为中心的支付解决方案的授权和管理功能,分解为单独的服务是一个很好的设计决策。在系统视图和服务视图之间迭代将有助于定义服务边界。

希望这个微服务设计画布可以成为着手微服务部署的企业的有用工具。它清楚地与API设计联系在一起。

作者:Matt McLarty

原文链接:

1、Visualizing Microservices: API Design and Strategy

https://dzone.com/articles/vis ... ategy

2、Visualizing Microservices: Designing a Microservice System

https://dzone.com/articles/vis ... rvice

3、Visualizing Microservices: The Microservice Design Canvas

https://dzone.com/articles/vis ... esign



相关阅读:
2018最难招聘的11类IT人员

悉数四代PaaS发展,一文理顺基础设施、平台和工作流之间的关系
悉数四代PaaS发展,一文理顺基础设施、平台和工作流之间的关系


添加小数微信:xiaoshu062

备注公司、姓名、职位

小数将拉您进入相应技术群

号称“天生一对”的容器+微服务,能躲开微服务的悖论陷阱吗?

dataman 发表了文章 • 0 个评论 • 97 次浏览 • 2018-02-27 10:20 • 来自相关话题

导读:
容器和微服务是不是天生一对?容器化环境是否能更好地实施微服务?本文作者走访了数位亲身实践者,给出了一些进行容器化微服务管理的6大建议。如果您也在评估考虑微服务技术,此文不要错过。
 
 
01微服务的悖论
 
Gianna作为高级软件工程师加入了Avidoo公司,这是一家生产力平台。在与其他团队的会议上,她提出了微服务的问题,以及团队是否开始采用。她立即得到了强烈的反应。
 
拜伦表示:“我们尝试过采用微服务,但是它们不起作用。
 
“这带来了可怕的混乱!”另一位同事补充说。
 
Gianna三次眨巴眼睛,期待着某种阐述,但没有一个往下接着说。
 
Gianna沉默了一会儿,问:“发生了什么事?
 
“起初很棒。每次我们被要求做新的东西时,我们都可以添加一个服务,并使用想要实验的任何语言和框架。
 
我们将REST API 公布在需要与之协作或在其数据库上工作的系统上。但过了一段时间,事情开始越来越频繁地割裂,开发速度放慢了。

Gianna叹了口气。听起来像她的团队一直在建立一个分布式的巨石应用,而他们打算建立的是微服务。

 
分布式巨石应用和其他庞然大物

Gianna所遇到的问题太常见了。微服务是灵丹妙药,IT经理和工程师倾向于区分哪些优势与他们的组织相适应。
 
却忘记了天下没有免费的午餐这件事。除了优势之外,精心打造的微服务架构也有被微辞的一面。没有任何“错误”的微服务,只有微服务不能提供的好处,或者由于它们的缺点而造成的不可接受的风险。
 
使用微服务的优势

选择采用微服务应该首先决定哪种优势适合自身的企业。以下是一些突出的优点:
 
1.增强团队的自主性
许多公司围绕团队成员具备的知识或组件组织团队。在创造真正的客户价值时,这要求团队之间进行大量的协调,不可能同时处理一个特性。







利用单一专业团队创造价值
 
微服务通过cover一个功能来促进自治。因此,一个团队可以完全拥有它,而不需要多个团队一起,这有助于减少跨团队的协调。






利用多学科团队创造价值

 2.更大的容错

团队自治的地方也应该有自治的特点。一个功能通常依赖于另一个。在大多数环境中,通信通过REST接口,按需和pull-based。当这种互动是关键任务时,依靠这种通信的服务要么必须有合理的fall-back,要么就会失败。这种不健康的模式常常被系统运行状况检查所证明,如果系统的一个依赖性不健康,系统运行就会失败。除了导致部署顺序难以管理之外,它还说明了系统依赖性的困难。







运行时依赖关系
 
使用正确的软件架构(如event sourcing),可能补充CQRS,可以完全消除大多数功能之间的运行时依赖。这主要是由于从pull-based系统向push-based系统的转变。
 
3.细粒度的软件生命周期管理
 
开发和业务人员一个共同的愿望是,尽快用新程序替换应用程序中的某个功能。无论是因为要求改变或者重写,又或由于紧张的上市周期需求而导致的技术债务,都使得开发速度落后了。有人可能天真地认为,这些是可以快速被替代的,但其实不然。经常更换功能导致不得不对其所依赖的许多系统进行更改,反之亦然。







缺乏细粒度的软件生命周期管理
 
通过高度调节系统间通信,可以完全切换一个或多个功能,而不必触发任何依赖系统。

 
4.灵活的技术选择

不可否认,这是一个棘手的问题。在需求或个人兴趣的推动下,入职和培训员工切换到通用技术有助于团队间的流动性。但是对于使用不同技术的几个部门的员工,坦白地说,这可能导致大规模的罢工。







迫使技术做出选择
 
只要这些技术可以集成到自动化测试和部署工作流程中,一个团队就可以保持自己的技术选择。为什么要改变一个团结在对C#所有东西都非常热爱的胜利团队呢?只要他们能够产出符合平台监控,日志记录和通信规则的组件。
 
那么为什么他们失败了?
 
因为不知道应该如何去做微服务。采用微服务并不会失败,因为人们不知道如何去做,他们经常不记得首先要解决什么问题。与其他任何决定一样,采用微服务会带来一些成本。软件架构师往往会忘记,他们不应该帮助企业的管理者采用微服务,而应该帮助他们解决真正的业务问题。恰当地衡量这些方面的成本和收益对企业的需求至关重要。
 

02微服务和容器:6大长期管理技巧

部署基于容器的微服务仅仅是个开始,如何有效管理它呢?在我们最近发布的有关微服务和容器入门的文章中,Cloud Technology Partners公司副总裁兼首席云架构师 Mike Kavis分享了一个好消息:“部署容器非常容易。
 
他言简意赅的说:“尽管部署容器很容易,但是要多思考这些系统的运维。”
 
你可以用容器化的微服务深入到生产环境,但大多数专家不会推荐它,特别是如果这是你第一次使用这个强大的技术。
 
基于容器的微服务有相当多的优势:正如红帽技术布道者(Gordon Haff)最近写到的:“即使Match.com(编者注:一家相亲配对网站)也找不到微服务更好的合作伙伴。”但是 IT Heaven所做的大部分工作都需要强大灵活的计划,持续管理企业的容器化微服务架构。你的企业中可能存在一条学习曲线,需要实施智能最佳实践,确保高效运营。
 
SolarWinds公司的负责人Kong Yang说:“第一天之后,所有事情都变得更加复杂。
 
我们询问了Yang、Kavis等人,他们对有效管理容器化微服务的最佳建议。
 
1.保持简单
面对不断增加的复杂性,想要保持高效吗?那就保持简单,愚蠢。这种设计和工程原理,通常被认为是航空和系统工程师Clarence “Kelly” Johnson的指导原则。
 
对于Johnson来说,KISS和管理哲学一样重要,“我们的目标是通过对棘手问题的常识应用来更快更高效地获得结果。
 
对于IT团队来说,这些想法有一个可见的翻译,特别是在微服务和容器方面。
 
“为确保今后的成功运营,让每个微服务做一件事,做得非常好。不要将附加功能扩大到现有的执行良好的微服务里。”
 
2.尽早把管理计划落实到位
微服务和容器可以实现更快,更灵活,更弹性,响应速度更快的软件团队。但首要的事情是,在部署到生产之前制定一个计划。这样一个计划的范例框架如下:
开发部署,安全和运维的最佳实践微服务和容器利用现代化的日志记录和监控解决方案探索容器管理工具(又名编排平台,如Kubernetes),在云端和非云端点上了解自身的环境定期实行post-mortems,不断学习和提高
 
3.选择一个编排平台 

编排工具对于容器化微服务的长期成功至关重要。
 
“每个微服务都需要与管理应用程序共享其状态。这可以决定微服务的生命周期。” ShieldXNetworks 首席技术官 Manuel Nedbal说。“例如,一旦微服务不报告或者正在被超载,就可以用一个新服务替换或者被复制。”
 
4.制定一套最低限度的运营能力

一个容器管理平台不会为你做所有的工作。Retriever Communications首席技术官Nic Grange 说,除了像Kubernetes这样的编排系统之外,还需要确保每个容器化的微服务都遵循“最低限度的运营能力”,以便在这样的环境下运行良好。他提供了以下这些功能的关键示例列表:
编排系统需要能够访问每个微服务上的API,确定它是否准备好接收流量,以及是否健康。需要告知微服务何时正常关闭的方法。需要微服务公开指标和日志记录。在大多数情况下,微服务需要能够水平扩展,并且在某些情况下具备集群意识。
 
Grange也为开发人员分享了一些好消息:特定语言的微服务模板库(如go-kit for Go)和dropwizard for Java,可以节省大量的开发这些最低功能的前期工作。
 
Grange说:“这些让开发人员更容易做正确的事情,获得许多开箱即用的功能,而不必编写更多的代码。
 

5.实施持续集成和持续交付

Sungard Availability Services CTO& 高级架构师 Kevin McGrath 表示,持续集成和持续交付实践对于基于容器的微服务的长期管理是一个巨大的好处,尤其是作为支撑企业编排工具的基础。
 
McGrath说:“如果没有CI / CD,微服务的维护将会因为手动流程而变得不堪重负,无法按预期进行扩展,并且最终将比基础设施和人力资源中的整体应用成本更高。”
 
随着时间的推移,CI / CD将帮助团队释放编排或管理工具的潜力,尤其是在管理如何在主机池中分配CPU,内存和存储时。
 
McGrath解释说:“一旦CI / CD成为产品生命周期一个自然的组成部分,管理系统就非常好,它们处理各种基础架构需求,并将其作为工程师的逻辑配置参数。“对于运维来说,要全面了解主机,容器和服务的资源消耗情况,以便更好地了解需要更多资源的位置。当服务不再与特定的基础设施绑定,而是与基础设施需求相联系时,这一点非常重要。”
 

6.不断重新审视并重新投资业务

容器和微服务不是一劳永逸的技术。DigitalOcean公司的工程经理 Mac Browning 建议说,为了正确使用他们,需要不断在如何运行基于容器的微服务上进行投资。这个建议适用于企业的人员、流程和工具。编排平台是一个好的开始。
 
Browning说:“如果完全投资并使用像Kubernetes这样的编排平台,那就意味着要花时间和资源来跟上项目和更新,并在自己的部署中体现这些变化。“由于企业微服务现在集中运行,这项投资将对所有要运行的服务产生积极影响,而不是一个或两个特定的单一服务。”
 
 
原文链接:1、The Microservices Paradox
https://blog.xebialabs.com/2018/01/30/the-microservices-paradox/2、Microservices and containers: 6management tips for the long haul
https://enterprisersproject.com/article/2017/10/microservices-and-containers-6-management-tips-long-haul 
 
关注数人云了解更多技术信息
推荐阅读
跳槽季 | IT 8大热门招聘趋势 VS 8大受冷落岗位,你不能不看
看好还是看衰?8位业界大咖这么看Serverless的2018
看好还是看衰?8位业界大咖这么看Serverless的2018 查看全部
导读:
容器和微服务是不是天生一对?容器化环境是否能更好地实施微服务?本文作者走访了数位亲身实践者,给出了一些进行容器化微服务管理的6大建议。如果您也在评估考虑微服务技术,此文不要错过。
 
 
01微服务的悖论
 

Gianna作为高级软件工程师加入了Avidoo公司,这是一家生产力平台。在与其他团队的会议上,她提出了微服务的问题,以及团队是否开始采用。她立即得到了强烈的反应。
 
拜伦表示:“我们尝试过采用微服务,但是它们不起作用。
 
“这带来了可怕的混乱!”另一位同事补充说。
 
Gianna三次眨巴眼睛,期待着某种阐述,但没有一个往下接着说。
 
Gianna沉默了一会儿,问:“发生了什么事?
 
“起初很棒。每次我们被要求做新的东西时,我们都可以添加一个服务,并使用想要实验的任何语言和框架。
 
我们将REST API 公布在需要与之协作或在其数据库上工作的系统上。但过了一段时间,事情开始越来越频繁地割裂,开发速度放慢了。

Gianna叹了口气。听起来像她的团队一直在建立一个分布式的巨石应用,而他们打算建立的是微服务。

 
分布式巨石应用和其他庞然大物

Gianna所遇到的问题太常见了。微服务是灵丹妙药,IT经理和工程师倾向于区分哪些优势与他们的组织相适应。
 
却忘记了天下没有免费的午餐这件事。除了优势之外,精心打造的微服务架构也有被微辞的一面。没有任何“错误”的微服务,只有微服务不能提供的好处,或者由于它们的缺点而造成的不可接受的风险。
 
使用微服务的优势

选择采用微服务应该首先决定哪种优势适合自身的企业。以下是一些突出的优点:
 
1.增强团队的自主性
许多公司围绕团队成员具备的知识或组件组织团队。在创造真正的客户价值时,这要求团队之间进行大量的协调,不可能同时处理一个特性。


微信图片_20180227101017.jpg


利用单一专业团队创造价值
 
微服务通过cover一个功能来促进自治。因此,一个团队可以完全拥有它,而不需要多个团队一起,这有助于减少跨团队的协调。

微信图片_20180227101045.jpg


利用多学科团队创造价值

 2.更大的容错

团队自治的地方也应该有自治的特点。一个功能通常依赖于另一个。在大多数环境中,通信通过REST接口,按需和pull-based。当这种互动是关键任务时,依靠这种通信的服务要么必须有合理的fall-back,要么就会失败。这种不健康的模式常常被系统运行状况检查所证明,如果系统的一个依赖性不健康,系统运行就会失败。除了导致部署顺序难以管理之外,它还说明了系统依赖性的困难。


微信图片_20180227101133.jpg


运行时依赖关系
 
使用正确的软件架构(如event sourcing),可能补充CQRS,可以完全消除大多数功能之间的运行时依赖。这主要是由于从pull-based系统向push-based系统的转变。
 
3.细粒度的软件生命周期管理
 
开发和业务人员一个共同的愿望是,尽快用新程序替换应用程序中的某个功能。无论是因为要求改变或者重写,又或由于紧张的上市周期需求而导致的技术债务,都使得开发速度落后了。有人可能天真地认为,这些是可以快速被替代的,但其实不然。经常更换功能导致不得不对其所依赖的许多系统进行更改,反之亦然。


微信图片_20180227100334.jpg


缺乏细粒度的软件生命周期管理
 
通过高度调节系统间通信,可以完全切换一个或多个功能,而不必触发任何依赖系统。

 
4.灵活的技术选择

不可否认,这是一个棘手的问题。在需求或个人兴趣的推动下,入职和培训员工切换到通用技术有助于团队间的流动性。但是对于使用不同技术的几个部门的员工,坦白地说,这可能导致大规模的罢工。


微信图片_20180227101222.jpg


迫使技术做出选择
 
只要这些技术可以集成到自动化测试和部署工作流程中,一个团队就可以保持自己的技术选择。为什么要改变一个团结在对C#所有东西都非常热爱的胜利团队呢?只要他们能够产出符合平台监控,日志记录和通信规则的组件。
 
那么为什么他们失败了?
 
因为不知道应该如何去做微服务。采用微服务并不会失败,因为人们不知道如何去做,他们经常不记得首先要解决什么问题。与其他任何决定一样,采用微服务会带来一些成本。软件架构师往往会忘记,他们不应该帮助企业的管理者采用微服务,而应该帮助他们解决真正的业务问题。恰当地衡量这些方面的成本和收益对企业的需求至关重要。
 

02微服务和容器:6大长期管理技巧

部署基于容器的微服务仅仅是个开始,如何有效管理它呢?在我们最近发布的有关微服务和容器入门的文章中,Cloud Technology Partners公司副总裁兼首席云架构师 Mike Kavis分享了一个好消息:“部署容器非常容易。
 
他言简意赅的说:“尽管部署容器很容易,但是要多思考这些系统的运维。”
 
你可以用容器化的微服务深入到生产环境,但大多数专家不会推荐它,特别是如果这是你第一次使用这个强大的技术。
 
基于容器的微服务有相当多的优势:正如红帽技术布道者(Gordon Haff)最近写到的:“即使Match.com(编者注:一家相亲配对网站)也找不到微服务更好的合作伙伴。”但是 IT Heaven所做的大部分工作都需要强大灵活的计划,持续管理企业的容器化微服务架构。你的企业中可能存在一条学习曲线,需要实施智能最佳实践,确保高效运营。
 
SolarWinds公司的负责人Kong Yang说:“第一天之后,所有事情都变得更加复杂。
 
我们询问了Yang、Kavis等人,他们对有效管理容器化微服务的最佳建议。
 
1.保持简单
面对不断增加的复杂性,想要保持高效吗?那就保持简单,愚蠢。这种设计和工程原理,通常被认为是航空和系统工程师Clarence “Kelly” Johnson的指导原则。
 
对于Johnson来说,KISS和管理哲学一样重要,“我们的目标是通过对棘手问题的常识应用来更快更高效地获得结果。
 
对于IT团队来说,这些想法有一个可见的翻译,特别是在微服务和容器方面。
 
“为确保今后的成功运营,让每个微服务做一件事,做得非常好。不要将附加功能扩大到现有的执行良好的微服务里。”
 
2.尽早把管理计划落实到位
微服务和容器可以实现更快,更灵活,更弹性,响应速度更快的软件团队。但首要的事情是,在部署到生产之前制定一个计划。这样一个计划的范例框架如下:
  • 开发部署,安全和运维的最佳实践
  • 微服务和容器利用现代化的日志记录和监控解决方案
  • 探索容器管理工具(又名编排平台,如Kubernetes),在云端和非云端点上了解自身的环境
  • 定期实行post-mortems,不断学习和提高

 
3.选择一个编排平台 

编排工具对于容器化微服务的长期成功至关重要。
 
“每个微服务都需要与管理应用程序共享其状态。这可以决定微服务的生命周期。” ShieldXNetworks 首席技术官 Manuel Nedbal说。“例如,一旦微服务不报告或者正在被超载,就可以用一个新服务替换或者被复制。”
 
4.制定一套最低限度的运营能力

一个容器管理平台不会为你做所有的工作。Retriever Communications首席技术官Nic Grange 说,除了像Kubernetes这样的编排系统之外,还需要确保每个容器化的微服务都遵循“最低限度的运营能力”,以便在这样的环境下运行良好。他提供了以下这些功能的关键示例列表:
  • 编排系统需要能够访问每个微服务上的API,确定它是否准备好接收流量,以及是否健康。
  • 需要告知微服务何时正常关闭的方法。
  • 需要微服务公开指标和日志记录。
  • 在大多数情况下,微服务需要能够水平扩展,并且在某些情况下具备集群意识。

 
Grange也为开发人员分享了一些好消息:特定语言的微服务模板库(如go-kit for Go)和dropwizard for Java,可以节省大量的开发这些最低功能的前期工作。
 
Grange说:“这些让开发人员更容易做正确的事情,获得许多开箱即用的功能,而不必编写更多的代码。
 

5.实施持续集成和持续交付

Sungard Availability Services CTO& 高级架构师 Kevin McGrath 表示,持续集成和持续交付实践对于基于容器的微服务的长期管理是一个巨大的好处,尤其是作为支撑企业编排工具的基础。
 
McGrath说:“如果没有CI / CD,微服务的维护将会因为手动流程而变得不堪重负,无法按预期进行扩展,并且最终将比基础设施和人力资源中的整体应用成本更高。”
 
随着时间的推移,CI / CD将帮助团队释放编排或管理工具的潜力,尤其是在管理如何在主机池中分配CPU,内存和存储时。
 
McGrath解释说:“一旦CI / CD成为产品生命周期一个自然的组成部分,管理系统就非常好,它们处理各种基础架构需求,并将其作为工程师的逻辑配置参数。“对于运维来说,要全面了解主机,容器和服务的资源消耗情况,以便更好地了解需要更多资源的位置。当服务不再与特定的基础设施绑定,而是与基础设施需求相联系时,这一点非常重要。”
 

6.不断重新审视并重新投资业务

容器和微服务不是一劳永逸的技术。DigitalOcean公司的工程经理 Mac Browning 建议说,为了正确使用他们,需要不断在如何运行基于容器的微服务上进行投资。这个建议适用于企业的人员、流程和工具。编排平台是一个好的开始。
 
Browning说:“如果完全投资并使用像Kubernetes这样的编排平台,那就意味着要花时间和资源来跟上项目和更新,并在自己的部署中体现这些变化。“由于企业微服务现在集中运行,这项投资将对所有要运行的服务产生积极影响,而不是一个或两个特定的单一服务。”
 
 
原文链接:1、The Microservices Paradox
https://blog.xebialabs.com/2018/01/30/the-microservices-paradox/2、Microservices and containers: 6management tips for the long haul
https://enterprisersproject.com/article/2017/10/microservices-and-containers-6-management-tips-long-haul 
 
关注数人云了解更多技术信息
推荐阅读
跳槽季 | IT 8大热门招聘趋势 VS 8大受冷落岗位,你不能不看
看好还是看衰?8位业界大咖这么看Serverless的2018
看好还是看衰?8位业界大咖这么看Serverless的2018

看好还是看衰?8位业界大咖这么看Serverless的2018

dataman 发表了文章 • 0 个评论 • 107 次浏览 • 2018-02-23 11:37 • 来自相关话题

导读:

Serverless,也称为FaaS(功能即服务),它并不意味着没有服务器在执行繁重的任务 ;而是用户看不到或者不必维护服务器,并且不关心它所在的世界。小数之前跟大家分享过多次Serverless的话题,比如,思考+案例,大咖研究了Serverless14个月,优缺全体现!,再比如,容器之后的下一个明星,关于无服务器(Serverless)架构你要搞懂的8件事。今天这篇主要由8位业内意见领袖谈2018Serverless的去向。
在所谓的无服务器IT系统中,数据工作负载是如何处理的? 

亚马逊的AWS Lambda是无服务器计算最大、最著名的例子,它的未来对很多IT人来说是非常诱人的。Lambda是由 Amazon开发的一个事件驱动的计算平台,当特定事件发生时,它会自动触发或执行代码。Lambda只在需要时执行代码,并自动伸缩,为企业处理一些数据流程和应用程序,提供潜在的成本节约和灵活性。

Amazon 在2014年发布了Lambda,作为企业在云中运行代码的“无服务器”平台,不需要物理服务器,也不需要在企业端提供或管理任何服务器。



1、Serverless无服务器是未来的潮流


在应用程序代码方面,AWS支持Node.js、Java、c#和现在的Python,只要开发人员在其中一种语言中编写代码,代码就可以在Lambda运行环境中运行,并利用Lambda资源。


亚马逊并不是唯一的FaaS供应商,其他还包括谷歌云,微软Azure,IBM OpenWhisk和开源项目Iron.io,以及Webtask。


无服务器的工作负载生产仍然处于初级阶段,但如果IT界的各种预言者都是正确的,那么它将很快在我们眼前成长起来。


以下是一些来自行业专家对serverless未来的展望:>>>>Sumo Logic (相扑逻辑):无服务器计算可能是继容器之后的未来AWS的采用率几乎翻了一番,从2016年的12%上升到2017年的23%。serverless的整个想法是,它通过完全跳过容器和DevOps将微服务转移到未来。事实上,有四分之一的开发人员已经在使用serverless,这对于遵循应用程序架构和采用的人来说是一种强烈的信号。IT领导者已经在谈论DevOps,但是serverless将它带到一个全新的世界“NoOps”——在没有基础设施的情况下,应用程序在云中运行。>>>>Avere Systems技术总监Dan Nydick : 我们将看到更多serverless技术和托管服务企业经常花费大量的时间和精力来管理计算基础设施,这不是他们任务和使命的核心任务。公有云的好处之一是,将应用程序迁移到云上之后,企业不再需要管理这些基础设施。云供应商提供了越来越高水平的管理服务,允许客户专注于自身业务,而不必被虚拟机、web服务器或数据库管理分散注意力。


我们将看到更多使用托管的、可伸缩的web服务(如谷歌 App Engine和AWS Beanstalk)和无服务器技术(如AWS Lambda和谷歌CloudFunctions),作为管理和部署复杂企业应用程序的更经济的方式。


“我们预计云供应商将继续向更高级别的托管服务发展,例如完全分布式数据库管理(谷歌Cloud Spanner),以及第三方出售托管在公有云(Azure Managed Apps)中的应用程序的新能力。”>>>>Atlassian平台负责人Steve Deasy:2018将如何改变软件的构建方式“随着来自主要云供应商的支持,无服务器的框架将会受到欢迎。”此外,数据驱动的应用程序将继续受到欢迎,而对工程师需求的支持也将以工具、基础设施和争论(wrangling)的形式出现。在《Mortal Kombat》中提到,Kubernetes将给现有的平台带来致命的灾难。

 

>>>>Evident.io公司CEO Tim Prendergast和客户解决方案副总裁John Martinez:容器和无服务器计算增加,它们会带来安全问题。


“2018年,公司将采用云计算的方式,传统的基于主机的操作系统将变得无关紧要,或者需要重新设计。”从安全的角度来看,没有人真正准备好保护所有这些容器和功能计算,但是人们还是采用了它。>>>>Contino公司主席Jason McDonald:无服务器采用将继续增加其影响。“Serverless将从云产业的小角落转移到聚光灯下,因为它解决了IT三个关键领域的管理:速度、成本和风险。事实上,亚马逊推出AWS Fargate,这是一种创新,它通过删除服务器,消除运行ECS集群所需的基础设施管理,从而极大地改变了容器的演化。


目前,至少有一家美国主要银行正在运行企业级应用程序,这是一个基于Lambda的专职基础架构,可解决成本和规模问题。未来将会有越来越多类似这样的故事,基于云的堆栈越来越多地迁移到无服务器架构中。



>>>>OVH US公司技术布道者和首席系统工程师 Paul Stephenson: 无服务器计算解决哪些用例将会更清晰。


“这项技术目前非常具有探索性,事件驱动的技术仍在继续。”很高兴看到这一领域发生的一切, 因为IT做的任何事情都可以提高企业业绩表现,同时保持相同或较低的风险状况,这将推动企业进行调研和投资。”>>>>Data Expedition CEO Seth Noble: 2018年,Serverless将与其他技术整合云供应商给客户和第三方留下了许多关键的云迁移元素。这为一些关键领域(如数据输入、数据组织和应用部署)带来了隐形成本。2018年,我们将会看到更多客户要求实际的解决方案,如真正的网络加速,缩小对象存储和文件存储之间的差距,以及更好的工具来集成基于无服务器的应用程序和无服务器服务。
>>>>Platform9 CEO Sirish Raghuram: Kubernetes将会在AWS Lambda无服务器部署中变得更有影响力。Kubernetes不仅可以让云更容易交叉使用,还可以降低云提供的其他高价值应用服务的价值。比如Lambda,用于无服务器计算。有很多开源的替代方案,比如Fission,开源并运行在任何Kubernetes集群上,提供了相同的价值主张。这仅仅是一个例子,说明云提供商自身原生服务的价值可能会发生级联变化,还会发生在Kubernetes生态系统中可用的应用服务范围内。“

 

2、7大提供FaaS的开源无服务器框架

随着虚拟化技术的发展,企业开始意识到物理硬件的利用率越来越高。随着云计算的发展,企业开始逐渐将虚拟机用于即付即用的服务中,AWS在2014年推出了Lambda服务,引入了云计算的新范例,如今已经成为通常所说的无服务器计算。在无服务器模式中,企业将功能作为服务付费,而不需要为永远在线的状态虚拟机付费。AWS lambda开创了serverless,现在有多个开源项目构建可用于多重部署的无服务器框架:

1.Apache Openwhisk

IBM启动了apache openwhisk项目,现在它是IBMCloud Functions服务的基础。


2.Fission uses kubernetes for serverless

由云服务供应商Platform9领导的开源Fission项目是一个基于Kubernetes的无服务器框架。”Fission是开放源代码项目,旨在成为lambda事实上的开源替代品,”Madhura Maskasky,PLatform9的联合创始人,在2017年1月采访时对eWEEK说。


3.IronFunctions

IronFunctions是一种以Go语言编写的FaaS平台。功能是任何云计算,包括公有云、私有云和混合云提供开源无服务器计算平台。


4.Fn project backed by Oracle

2017年10月甲骨文公司宣布开源Fn项目,为apache许可的无服务器项目。


5.OpenFaas

OpenFaas 是一种能够使docker或者kubernetes都变成无服务器的开源项目,是一种FaaS框架。


6.Kubeless

开源框架Kubeless是由2017年3月被Bitnami收购的软件供应商Skippbox开发的。

kubeless是一个kubernetes本地无服务器框架,具有符合AWS Lambda CLI的命令行界面(CLI)


7.Riff

在最新的开源无服务器框架中,Riff项目得到了关键支持,并且是即将到来的Pivotal Function Service(PFS)的基础。
 
 
 
>>>>调查显示企业不断从私有云转向公有云

一项对300名IT专业人员的调查显示,公有云系统将继续快速增长,因为企业将把他们的本地数据中心资产转移到云平台。

Serverless这种新兴的云计算服务交付模式为开发人员和管理人员带了很多好处。它提供了合适的灵活性和控制性级别。Serverless架构正在彻底改变软件开发和部署流程。



原文链接:

1、Predictions 2018: Why Serverless Processing May Be Wave of the Future

http://www.eweek.com/innovatio ... uture

2、7 Open-Source Serverless Frameworks Providing Functions as a Service

http://www.eweek.com/cloud/7-open-source-serverless-frameworks-providing-functions-as-a-service
 
 
  查看全部
导读:

Serverless,也称为FaaS(功能即服务),它并不意味着没有服务器在执行繁重的任务 ;而是用户看不到或者不必维护服务器,并且不关心它所在的世界。小数之前跟大家分享过多次Serverless的话题,比如,思考+案例,大咖研究了Serverless14个月,优缺全体现!,再比如,容器之后的下一个明星,关于无服务器(Serverless)架构你要搞懂的8件事。今天这篇主要由8位业内意见领袖谈2018Serverless的去向。
在所谓的无服务器IT系统中,数据工作负载是如何处理的? 

亚马逊的AWS Lambda是无服务器计算最大、最著名的例子,它的未来对很多IT人来说是非常诱人的。Lambda是由 Amazon开发的一个事件驱动的计算平台,当特定事件发生时,它会自动触发或执行代码。Lambda只在需要时执行代码,并自动伸缩,为企业处理一些数据流程和应用程序,提供潜在的成本节约和灵活性。

Amazon 在2014年发布了Lambda,作为企业在云中运行代码的“无服务器”平台,不需要物理服务器,也不需要在企业端提供或管理任何服务器。



1、Serverless无服务器是未来的潮流


在应用程序代码方面,AWS支持Node.js、Java、c#和现在的Python,只要开发人员在其中一种语言中编写代码,代码就可以在Lambda运行环境中运行,并利用Lambda资源。


亚马逊并不是唯一的FaaS供应商,其他还包括谷歌云,微软Azure,IBM OpenWhisk和开源项目Iron.io,以及Webtask。


无服务器的工作负载生产仍然处于初级阶段,但如果IT界的各种预言者都是正确的,那么它将很快在我们眼前成长起来。


以下是一些来自行业专家对serverless未来的展望:>>>>Sumo Logic (相扑逻辑):无服务器计算可能是继容器之后的未来AWS的采用率几乎翻了一番,从2016年的12%上升到2017年的23%。serverless的整个想法是,它通过完全跳过容器和DevOps将微服务转移到未来。事实上,有四分之一的开发人员已经在使用serverless,这对于遵循应用程序架构和采用的人来说是一种强烈的信号。IT领导者已经在谈论DevOps,但是serverless将它带到一个全新的世界“NoOps”——在没有基础设施的情况下,应用程序在云中运行。>>>>Avere Systems技术总监Dan Nydick : 我们将看到更多serverless技术和托管服务企业经常花费大量的时间和精力来管理计算基础设施,这不是他们任务和使命的核心任务。公有云的好处之一是,将应用程序迁移到云上之后,企业不再需要管理这些基础设施。云供应商提供了越来越高水平的管理服务,允许客户专注于自身业务,而不必被虚拟机、web服务器或数据库管理分散注意力。


我们将看到更多使用托管的、可伸缩的web服务(如谷歌 App Engine和AWS Beanstalk)和无服务器技术(如AWS Lambda和谷歌CloudFunctions),作为管理和部署复杂企业应用程序的更经济的方式。


“我们预计云供应商将继续向更高级别的托管服务发展,例如完全分布式数据库管理(谷歌Cloud Spanner),以及第三方出售托管在公有云(Azure Managed Apps)中的应用程序的新能力。”>>>>Atlassian平台负责人Steve Deasy:2018将如何改变软件的构建方式“随着来自主要云供应商的支持,无服务器的框架将会受到欢迎。”此外,数据驱动的应用程序将继续受到欢迎,而对工程师需求的支持也将以工具、基础设施和争论(wrangling)的形式出现。在《Mortal Kombat》中提到,Kubernetes将给现有的平台带来致命的灾难。

 

>>>>Evident.io公司CEO Tim Prendergast和客户解决方案副总裁John Martinez:容器和无服务器计算增加,它们会带来安全问题。


“2018年,公司将采用云计算的方式,传统的基于主机的操作系统将变得无关紧要,或者需要重新设计。”从安全的角度来看,没有人真正准备好保护所有这些容器和功能计算,但是人们还是采用了它。>>>>Contino公司主席Jason McDonald:无服务器采用将继续增加其影响。“Serverless将从云产业的小角落转移到聚光灯下,因为它解决了IT三个关键领域的管理:速度、成本和风险。事实上,亚马逊推出AWS Fargate,这是一种创新,它通过删除服务器,消除运行ECS集群所需的基础设施管理,从而极大地改变了容器的演化。


目前,至少有一家美国主要银行正在运行企业级应用程序,这是一个基于Lambda的专职基础架构,可解决成本和规模问题。未来将会有越来越多类似这样的故事,基于云的堆栈越来越多地迁移到无服务器架构中。



>>>>OVH US公司技术布道者和首席系统工程师 Paul Stephenson: 无服务器计算解决哪些用例将会更清晰。


“这项技术目前非常具有探索性,事件驱动的技术仍在继续。”很高兴看到这一领域发生的一切, 因为IT做的任何事情都可以提高企业业绩表现,同时保持相同或较低的风险状况,这将推动企业进行调研和投资。”>>>>Data Expedition CEO Seth Noble: 2018年,Serverless将与其他技术整合云供应商给客户和第三方留下了许多关键的云迁移元素。这为一些关键领域(如数据输入、数据组织和应用部署)带来了隐形成本。2018年,我们将会看到更多客户要求实际的解决方案,如真正的网络加速,缩小对象存储和文件存储之间的差距,以及更好的工具来集成基于无服务器的应用程序和无服务器服务。
>>>>Platform9 CEO Sirish Raghuram: Kubernetes将会在AWS Lambda无服务器部署中变得更有影响力。Kubernetes不仅可以让云更容易交叉使用,还可以降低云提供的其他高价值应用服务的价值。比如Lambda,用于无服务器计算。有很多开源的替代方案,比如Fission,开源并运行在任何Kubernetes集群上,提供了相同的价值主张。这仅仅是一个例子,说明云提供商自身原生服务的价值可能会发生级联变化,还会发生在Kubernetes生态系统中可用的应用服务范围内。“

 

2、7大提供FaaS的开源无服务器框架

随着虚拟化技术的发展,企业开始意识到物理硬件的利用率越来越高。随着云计算的发展,企业开始逐渐将虚拟机用于即付即用的服务中,AWS在2014年推出了Lambda服务,引入了云计算的新范例,如今已经成为通常所说的无服务器计算。在无服务器模式中,企业将功能作为服务付费,而不需要为永远在线的状态虚拟机付费。AWS lambda开创了serverless,现在有多个开源项目构建可用于多重部署的无服务器框架:

1.Apache Openwhisk

IBM启动了apache openwhisk项目,现在它是IBMCloud Functions服务的基础。


2.Fission uses kubernetes for serverless

由云服务供应商Platform9领导的开源Fission项目是一个基于Kubernetes的无服务器框架。”Fission是开放源代码项目,旨在成为lambda事实上的开源替代品,”Madhura Maskasky,PLatform9的联合创始人,在2017年1月采访时对eWEEK说。


3.IronFunctions

IronFunctions是一种以Go语言编写的FaaS平台。功能是任何云计算,包括公有云、私有云和混合云提供开源无服务器计算平台。


4.Fn project backed by Oracle

2017年10月甲骨文公司宣布开源Fn项目,为apache许可的无服务器项目。


5.OpenFaas

OpenFaas 是一种能够使docker或者kubernetes都变成无服务器的开源项目,是一种FaaS框架。


6.Kubeless

开源框架Kubeless是由2017年3月被Bitnami收购的软件供应商Skippbox开发的。

kubeless是一个kubernetes本地无服务器框架,具有符合AWS Lambda CLI的命令行界面(CLI)


7.Riff

在最新的开源无服务器框架中,Riff项目得到了关键支持,并且是即将到来的Pivotal Function Service(PFS)的基础。
 
 
 
>>>>调查显示企业不断从私有云转向公有云

一项对300名IT专业人员的调查显示,公有云系统将继续快速增长,因为企业将把他们的本地数据中心资产转移到云平台。

Serverless这种新兴的云计算服务交付模式为开发人员和管理人员带了很多好处。它提供了合适的灵活性和控制性级别。Serverless架构正在彻底改变软件开发和部署流程。



原文链接:

1、Predictions 2018: Why Serverless Processing May Be Wave of the Future

http://www.eweek.com/innovatio ... uture

2、7 Open-Source Serverless Frameworks Providing Functions as a Service

http://www.eweek.com/cloud/7-open-source-serverless-frameworks-providing-functions-as-a-service
 
 
 

25篇技术干货说尽微服务、Service Mesh、容器、DevOps | Meetup年度实录集

dataman 发表了文章 • 0 个评论 • 244 次浏览 • 2018-02-09 11:03 • 来自相关话题

导读:

小数为大家汇总了数人云2017年举办的十几场技术meetup上的演讲实录。这些实录有关微服务、服务网格Service Mesh、DevOps、云原生、Kubernetes、SRE以及容器等等,分享嘉宾都是前沿技术公司技术专家和大咖,以及传统企业和互联网企业的落地实践。满满的干货,值得温习一遍又一遍!
 
 
 
1

Cloud Native架构下的K8S和微服务实践
 
时间:2018年1月27日,地点:深圳

PPT | 从架构到组件,深挖istio如何连接、管理和保护微服务2.0?
亿级用户万台服务器背后,vivo云服务容器化如何破茧化蝶?


2

服务网格:ServiceMesh is Coming
 
时间:2017年12月16日,地点:北京

ServiceMesh谁主沉浮?数人云资深架构师最新解读

WeiboMesh服务化实践如何应对明星劈腿的顶级流量?
 
3

论道云原生和微服务,剑指何方?
 
时间:2017年11月4日,地点:北京

5位大咖同台论道,中西方微服务有何异同?
 
 
4

将微服务进行到底
 
时间:2017年9月23日,地点:北京

90%产品服务化,细说豆瓣的5年变革之路
 
 
5

K8S GeekGathering 2017 上海站
 
时间:2017年9月10日 地点:上海

数人云架构师:微服务体系中的K8S&Mesos调度与服务发现
 
 
6

K8S、Mesos还不够? 8月19日更多Container+技术
 
时间:2017年8月19日  地点:北京

微软AzureContainer Service的容器化应用

当K8S遇上微服务-京东金融PaaS平台思考与实践
 
7

DevOps&SRE 超越传统运维之道上海站
 
时间:2017年7月15日 地点:上海

有心了,他写了一份DevOps&SRE参会笔记分享给你 | 附PPT下载

SRE遇上金融老干部,解决发布协调&监控告警两大难题
 
 
8

DevOps&SRE 超越传统运维之道深圳站
 
时间:2017年5月6日  地点:深圳

数人云王璞:《SRE在传统企业中的落地实践》

腾讯大梁:《DevOps最后一棒,有效构建海量运营的持续反馈能力》
 
 
9

大牛的成长轨迹之架构&运维
 
时间:2017年4月15日  地点:北京

当当架构部张亮:从码农到大牛,技术与心境的双重提升
 
 
10

当西方的SRE遇上东方的互联网
 
时间:2017年3月4日  地点:北京

活学活用SRE,美团点评,前Google SRE线下分享视频

活学活用SRE,数人云,某金融线下分享视频
 
 
11

告别人肉运维
 
时间: 2017年2月25日  地点:上海

告别人肉运维,饿了么和数人云的经验都在这里了

拒绝删库到跑路,探究饿了么数据安全保障体系

DesignFor Failure——饿了么技术运营实践
 
 
12

容器之Mesos/K8S/Swarm三国演义深圳站
 
时间:2017年1月7日,地点:深圳

Kubernetes在腾讯游戏的应用实践

实录分享 | Mesos PMC带你回顾Mesos 2016

广发银行运维实践分享:Docker适配传统运维那些事
 
13

容器之Mesos/K8S/Swarm三国演义上海站
 
时间:2017年1月7日,地点:上海

.Net大户的选择:Windows Container在携程的应用

构建与定制:唯品会PaaS基于Kubernetes的实践

Docker在Bilibili的实战:由痛点推动的容器化



添加小数微信:xiaoshu062

备注公司、姓名、职位

小数将拉您进入相应技术群 查看全部
导读:

小数为大家汇总了数人云2017年举办的十几场技术meetup上的演讲实录。这些实录有关微服务、服务网格Service Mesh、DevOps、云原生、Kubernetes、SRE以及容器等等,分享嘉宾都是前沿技术公司技术专家和大咖,以及传统企业和互联网企业的落地实践。满满的干货,值得温习一遍又一遍!
 
 
 
1

Cloud Native架构下的K8S和微服务实践
 
时间:2018年1月27日,地点:深圳

PPT | 从架构到组件,深挖istio如何连接、管理和保护微服务2.0?
亿级用户万台服务器背后,vivo云服务容器化如何破茧化蝶?


2

服务网格:ServiceMesh is Coming
 
时间:2017年12月16日,地点:北京

ServiceMesh谁主沉浮?数人云资深架构师最新解读

WeiboMesh服务化实践如何应对明星劈腿的顶级流量?
 
3

论道云原生和微服务,剑指何方?
 
时间:2017年11月4日,地点:北京

5位大咖同台论道,中西方微服务有何异同?
 
 
4

将微服务进行到底
 
时间:2017年9月23日,地点:北京

90%产品服务化,细说豆瓣的5年变革之路
 
 
5

K8S GeekGathering 2017 上海站
 
时间:2017年9月10日 地点:上海

数人云架构师:微服务体系中的K8S&Mesos调度与服务发现
 
 
6

K8S、Mesos还不够? 8月19日更多Container+技术
 
时间:2017年8月19日  地点:北京

微软AzureContainer Service的容器化应用

当K8S遇上微服务-京东金融PaaS平台思考与实践
 
7

DevOps&SRE 超越传统运维之道上海站
 
时间:2017年7月15日 地点:上海

有心了,他写了一份DevOps&SRE参会笔记分享给你 | 附PPT下载

SRE遇上金融老干部,解决发布协调&监控告警两大难题
 
 
8

DevOps&SRE 超越传统运维之道深圳站
 
时间:2017年5月6日  地点:深圳

数人云王璞:《SRE在传统企业中的落地实践》

腾讯大梁:《DevOps最后一棒,有效构建海量运营的持续反馈能力》
 
 
9

大牛的成长轨迹之架构&运维
 
时间:2017年4月15日  地点:北京

当当架构部张亮:从码农到大牛,技术与心境的双重提升
 
 
10

当西方的SRE遇上东方的互联网
 
时间:2017年3月4日  地点:北京

活学活用SRE,美团点评,前Google SRE线下分享视频

活学活用SRE,数人云,某金融线下分享视频
 
 
11

告别人肉运维
 
时间: 2017年2月25日  地点:上海

告别人肉运维,饿了么和数人云的经验都在这里了

拒绝删库到跑路,探究饿了么数据安全保障体系

DesignFor Failure——饿了么技术运营实践
 
 
12

容器之Mesos/K8S/Swarm三国演义深圳站
 
时间:2017年1月7日,地点:深圳

Kubernetes在腾讯游戏的应用实践

实录分享 | Mesos PMC带你回顾Mesos 2016

广发银行运维实践分享:Docker适配传统运维那些事
 
13

容器之Mesos/K8S/Swarm三国演义上海站
 
时间:2017年1月7日,地点:上海

.Net大户的选择:Windows Container在携程的应用

构建与定制:唯品会PaaS基于Kubernetes的实践

Docker在Bilibili的实战:由痛点推动的容器化



添加小数微信:xiaoshu062

备注公司、姓名、职位

小数将拉您进入相应技术群

4大维度3大预测,基于容器生态扩张的DevSecOps为啥引关注?

dataman 发表了文章 • 0 个评论 • 116 次浏览 • 2018-02-08 10:22 • 来自相关话题

 





DevSecOps可能不是一个优雅的术语,但其结果是有吸引力的: 在开发的早期带来更强大的安全性。DevOps最终是要建立更好的软件,也意味着更安全的软件。
 
像任何IT术语一样,DevSecOps--由DevOps衍生而来,很容易被炒作和盗用。但是这个术语对拥抱DevOps文化的IT领导者以及实现其承诺的实践和工具而言,具有真正的意义。
 

 DevSecOps什么意思?
 
Datic公司首席技术官兼共同创始人RobertReeves说:“DevSecOps是开发,安全和运维的组合。它提醒我们,对于应用程序来说,安全和创建、部署到生产上同样重要。”
 
向非技术人员解释DevSecOps的一个简单方法:它有意识地更早地将安全性融入到开发过程中。
 
红帽安全战略家Kirsten Newcomer 最近告诉我们: “历史上,安全团队从开发团队中分离出来,每个团队都在不同的IT领域拥有深厚的专业知识  。“其实不需要这样。关心安全的企业也非常关心通过软件快速交付业务价值的能力,这些企业正在寻找方法,将安全性留在应用开发生命周期内。通过在整个CI / CD中集成安全实践,工具和自动化来采用DevSecOps。”
 
她说:“为了做到这一点,他们正在整合团队。安全专业人员将从应用开发团队一直嵌入到生产部署中。” “双方都看到了价值,每个团队都拓展了他们的技能和知识基础,成为更有价值的技术专家。正确的DevOps或DevSecOps ,提高IT安全性。”
 
IT团队的任务是更快,更频繁地交付服务。DevOps成为一个很好的推动因素,部分原因是它可以消除开发和运营团队之间的一些传统冲突,Ops通常在部署之前被排除在外,而Dev将其代码丢在无形的墙上,从来不进行二次管理,更没有任何的基础设施维护责任。说得委婉一些,在数字化时代,这种孤立的做法会产生问题。按照Reeves的说法,如果安全是孤立的,也会存在类似的问题。
 
Reeves说:“我们采用DevOps,它被证明可以通过扫除开发与运维之间的障碍来提高IT的性能。“就像不应该等到部署周期结束才开始运维一样,也不应该等到最后才考虑安全问题。”
 

 DevSecOps为什么会出现?
 
将DevSecOps看作是另一个流行语是一种诱惑,但对于安全意识强的IT领导者来说,这是一个实质性的概念。安全必须是软件开发流程中的“一等公民”,而并非最终步骤部署,或者更糟糕,只有在发生实际的安全事件后才受到重视。
SumoLogic公司安全与合规副总裁George Gerchow表示:“DevSecOps不仅仅是一个流行词,由于诸多原因它是IT的当前和未来状态。“最重要的好处是能够将安全性融入到开发和运营流程中,为实现敏捷性和创新提供保障。”
 
此外,在场景中出现的DevSecOps可能是DevOps自身正在成熟并深入挖掘IT内部的另一个标志。
 
“企业DevOps文化意味着开发人员能够以更快的速度向生产环境提供功能和更新,特别是当自组织团队更加乐于协作和衡量结果。”CYBRIC首席技术官兼联合创始人Mike Kail说。
 
在采用DevOps的同时,保持原有的安全实践的团队和公司会遇到更多的管理安全风险的痛苦,因为DevOps团队会部署地更快、更频繁。
 

 手动测试安全方法逐渐落后

 “目前,手动测试安全方法逐渐落后,利用自动化和协作将安全测试转移到软件开发生命周期,从而推动DevSecOps文化,这是IT领导者提高整体弹性和交付安全保证的唯一路径。”凯尔说。
 
(早期)对安全性测试的改变也让开发人员受益:在开发新服务或部署更新服务之前,他们并没有发现代码中的明显漏洞,而是经常在开发的早期阶段发现并解决潜在的问题,几乎没有安全人员的介入。
 
SAS首席信息安全官Brian Wilson表示:“正确的做法是,DevSecOps可以将安全性纳入开发生命周期,使开发人员能够更快,更方便地保护应用程序,不会造成安全干扰。
 
Wilson将静态(SAST)和源代码分析(SCA)工具集成到团队的持续交付中,帮助开发人员在代码中对潜在问题,以及第三方依赖的漏洞进行反馈。
 
Wilson说:“开发人员可以主动、反复地缓解app的安全问题,并重新进行安全扫描,无需安全人员参与。DevSecOps还可以帮助开发团队简化更新和修补程序。
 
DevSecOps并不意味着企业不再需要安全专家,就像DevOps并不意味着企业不再需要基础架构专家一样。它只是有助于减少瑕疵进入生产的可能性,或减缓部署。
 

 DevSecOps遭遇的危机
 
来自Sumo Logic公司的Gerchow分享了DevSecOps文化的实例:当最近的Meltdown和Spectre消息出现时,团队的DevSecOps方法能够迅速做出响应,以减轻风险,而对内外部客户没有任何明显的干扰。 对云原生和受高度监管的公司来说非常重要。
 
第一步,Gerchow的小型安全团队(具备开发技能)能够通过Slack与其主要云供应商之一合作,确保基础设施在24小时内完全修补好。
 
 “然后,我的团队立即开始了OS级别的修复,不需要给终端用户停机时间,也无需请求工程师,那样意味着要等待长时间的变更管理流程。所有这些变化都是通过Slack打开自动化Jira tickets进行的,并通过日志和分析解决方案进行监控,“Gerchow解释说。
 
这听起来像DevOps文化,正确的人员、流程和工具组合相匹配,但它明确地将安全作为该文化和组合的一部分。
 
Gerchow说:“在传统环境下,停机需要花费数周或数月的时间,因为开发、运营和安全这三项功能都是孤立的。凭借DevSecOps流程和理念,终端用户可以通过简单的沟通和当天的修复获得无缝的体验。”
 
 
02
2018DevSecOps三大预测
 
2018年企业的DevSecOps将迎来一些真正的变革。
 
对于DevSecOps来说,2017年是美好的一年,DevSecOps从一个半朦胧的概念演变成可行的企业功能。
 
容器和容器市场的迅速扩张在很大程度上推动了这一演变,容器市场本质上与DevOps和DevSecOps相互交织在一起。一般来说,快速增长和创新往往比科学更能预测趋势,但我仍然愿意尝试一下。
 
从Docker Hub和成熟的容器生态系统中获取了超过120亿张图片,就企业的DevSecOps而言,我们几乎看不到冰山的一角。不过,相信在2018年,我们将看到:基础变革的开始。我认为它会是这样的:
 

 >>>>1.企业领导者和IT利益相关者意识到DevSecOps正在改进DevOps
 
DevOps将开发团队和运维团队聚在一起,它推动协作文化不足为奇。加入安全举措可能听起来很简单,但多年来,安全问题一直是事后的事情,导致企业文化容易使安全团队与其他IT团队形成对立,包括开发团队。 
但是事情发生了变化。
在雅虎亏损3.5亿美元的商业环境下,暴露了其脆弱的安全状况,企业领导者将网络安全看作是一个运维sinkhole的时代已经结束。加强网络安全现在是企业的当务之急。但这种转变需要时间才能重新回到IT文化中。
DevOps和DevSecOps的崛起无疑为重塑应用程序安全性创造了一个难得且令人兴奋的机会,但是DevOps可能会导致转变速度发生变化。DevOps团队和应用程序架构师每天都能够认识到安全的重要性,并欢迎安全团队的加入,但他们之间仍然存在需要磨合的鸿沟。
为正确实施DevSecOps,安全团队需要与DevOps团队保持一致,企业领导者需要为此打造空间和预算。到2019年,希望企业领导人能够意识到推动一个重要的、合法的安全胜利的机会。
 

>>>>2.成功的组织模式将会出现,最可能的是,安全与DevOps团队之间的紧密协作。

虽然该预测并不特别具有启发性,但是相关的。了解DevSecOps需要来自安全和DevOps团队的平等协作,快速跟踪标准蓝图或实施模型,将DevSecOps集成(并最终自动化)到CI / CD进程中。
虽然不同企业有不同的需求,但大多数公司都使用相同的技术工具,特别是在使用容器的情况下。这就为统一的标准化提供了条件。此外,容器的开源特性可以促进相关信息的共享和标准开发。
到目前为止,由于DevOps团队拥有开发流程,他们一直在安全方面处于领先地位。然而,我认为,DevSecOps需要由安全团队领导, 他们是负责企业安全和风险的人,当安全事故发生时,他们会被解雇或被迫离开。
2018年,安全团队需要加强并展示团队的价值和技能。将安全性融入到IT结构中,而不是在网络安全问题成为事实之后才想起。现在我们有机会来实现这一目标。
 

>>>>3.安全团队仍然要缓慢适应DevOps的现实

过去,企业安全团队通常在不重视或不了解安全需要的文化中运营。难怪今天的电商环境是大多数企业相对容易被破坏的环境。 
强大的安全性不仅仅是外围的防火墙。尽管许多安全专家可能最终会看到这种转变,但可能不像DevOps团队所期望的那样灵活。当谈到容器(通常是appsec)时,即使是最有才华和最优秀的安全专家也会面临学习的瓶颈。更不用说已经被充分证明的网络安全技能短缺的现状。
虽然这些因素可能在短期内降低安全对DevOps和 DevSecOps的支持,但是我认为DevSecOps是解决技能短缺问题的一部分。将安全集成到应用程序交付过程中,并将其自动化比用回溯方法更有效率和更具成本效益,可以解决在部署应用程序之前解决安全漏洞。安全专业人士可以通过开放的态度,以新的方式发挥他们的才能,从而获得很多收益。 
2018年希望这个故事有一个快乐的结局。
 

原文链接:
1、3 predictions for devsecops in 2018https://www.infoworld.com/article/3243155/devops/3-predictions-for-devsecops-in-2018.html2、   Why DevSecOps matters to IT leadershttps://enterprisersproject.com/article/2018/1/why-devsecops-matters-it-leaders
 
 
 
推荐阅读:
企业级落地容器与DevOps,选用K8S都有哪些“姿势”
7大ChatOps&5种团队协作工具助力DevOps实践
如果没按这7种习惯,你可能实践的是假DevOps
这款分布式配置中心,会是微服务的降维打击利器吗?
从架构到组件,深挖istio如何连接、管理和保护微服务2.0?
 
 
添加小数微信:xiaoshu062
备注公司、姓名、职位
小数将拉您进入相应技术群
 
点击数人云了解更多信息 查看全部
 
v2-174b0611f0cdb3c1c3ac4bd4db13a3d3_hd.jpg


DevSecOps可能不是一个优雅的术语,但其结果是有吸引力的: 在开发的早期带来更强大的安全性。DevOps最终是要建立更好的软件,也意味着更安全的软件。
 
像任何IT术语一样,DevSecOps--由DevOps衍生而来,很容易被炒作和盗用。但是这个术语对拥抱DevOps文化的IT领导者以及实现其承诺的实践和工具而言,具有真正的意义。
 

 DevSecOps什么意思?
 
Datic公司首席技术官兼共同创始人RobertReeves说:“DevSecOps是开发,安全和运维的组合。它提醒我们,对于应用程序来说,安全和创建、部署到生产上同样重要。”
 
向非技术人员解释DevSecOps的一个简单方法:它有意识地更早地将安全性融入到开发过程中。
 
红帽安全战略家Kirsten Newcomer 最近告诉我们: “历史上,安全团队从开发团队中分离出来,每个团队都在不同的IT领域拥有深厚的专业知识  。“其实不需要这样。关心安全的企业也非常关心通过软件快速交付业务价值的能力,这些企业正在寻找方法,将安全性留在应用开发生命周期内。通过在整个CI / CD中集成安全实践,工具和自动化来采用DevSecOps。”
 
她说:“为了做到这一点,他们正在整合团队。安全专业人员将从应用开发团队一直嵌入到生产部署中。” “双方都看到了价值,每个团队都拓展了他们的技能和知识基础,成为更有价值的技术专家。正确的DevOps或DevSecOps ,提高IT安全性。”
 
IT团队的任务是更快,更频繁地交付服务。DevOps成为一个很好的推动因素,部分原因是它可以消除开发和运营团队之间的一些传统冲突,Ops通常在部署之前被排除在外,而Dev将其代码丢在无形的墙上,从来不进行二次管理,更没有任何的基础设施维护责任。说得委婉一些,在数字化时代,这种孤立的做法会产生问题。按照Reeves的说法,如果安全是孤立的,也会存在类似的问题。
 
Reeves说:“我们采用DevOps,它被证明可以通过扫除开发与运维之间的障碍来提高IT的性能。“就像不应该等到部署周期结束才开始运维一样,也不应该等到最后才考虑安全问题。”
 

 DevSecOps为什么会出现?
 
将DevSecOps看作是另一个流行语是一种诱惑,但对于安全意识强的IT领导者来说,这是一个实质性的概念。安全必须是软件开发流程中的“一等公民”,而并非最终步骤部署,或者更糟糕,只有在发生实际的安全事件后才受到重视。
SumoLogic公司安全与合规副总裁George Gerchow表示:“DevSecOps不仅仅是一个流行词,由于诸多原因它是IT的当前和未来状态。“最重要的好处是能够将安全性融入到开发和运营流程中,为实现敏捷性和创新提供保障。”
 
此外,在场景中出现的DevSecOps可能是DevOps自身正在成熟并深入挖掘IT内部的另一个标志。
 
“企业DevOps文化意味着开发人员能够以更快的速度向生产环境提供功能和更新,特别是当自组织团队更加乐于协作和衡量结果。”CYBRIC首席技术官兼联合创始人Mike Kail说。
 
在采用DevOps的同时,保持原有的安全实践的团队和公司会遇到更多的管理安全风险的痛苦,因为DevOps团队会部署地更快、更频繁。
 

 手动测试安全方法逐渐落后

 “目前,手动测试安全方法逐渐落后,利用自动化和协作将安全测试转移到软件开发生命周期,从而推动DevSecOps文化,这是IT领导者提高整体弹性和交付安全保证的唯一路径。”凯尔说。
 
(早期)对安全性测试的改变也让开发人员受益:在开发新服务或部署更新服务之前,他们并没有发现代码中的明显漏洞,而是经常在开发的早期阶段发现并解决潜在的问题,几乎没有安全人员的介入。
 
SAS首席信息安全官Brian Wilson表示:“正确的做法是,DevSecOps可以将安全性纳入开发生命周期,使开发人员能够更快,更方便地保护应用程序,不会造成安全干扰。
 
Wilson将静态(SAST)和源代码分析(SCA)工具集成到团队的持续交付中,帮助开发人员在代码中对潜在问题,以及第三方依赖的漏洞进行反馈。
 
Wilson说:“开发人员可以主动、反复地缓解app的安全问题,并重新进行安全扫描,无需安全人员参与。DevSecOps还可以帮助开发团队简化更新和修补程序。
 
DevSecOps并不意味着企业不再需要安全专家,就像DevOps并不意味着企业不再需要基础架构专家一样。它只是有助于减少瑕疵进入生产的可能性,或减缓部署。
 

 DevSecOps遭遇的危机
 
来自Sumo Logic公司的Gerchow分享了DevSecOps文化的实例:当最近的Meltdown和Spectre消息出现时,团队的DevSecOps方法能够迅速做出响应,以减轻风险,而对内外部客户没有任何明显的干扰。 对云原生和受高度监管的公司来说非常重要。
 
第一步,Gerchow的小型安全团队(具备开发技能)能够通过Slack与其主要云供应商之一合作,确保基础设施在24小时内完全修补好。
 
 “然后,我的团队立即开始了OS级别的修复,不需要给终端用户停机时间,也无需请求工程师,那样意味着要等待长时间的变更管理流程。所有这些变化都是通过Slack打开自动化Jira tickets进行的,并通过日志和分析解决方案进行监控,“Gerchow解释说。
 
这听起来像DevOps文化,正确的人员、流程和工具组合相匹配,但它明确地将安全作为该文化和组合的一部分。
 
Gerchow说:“在传统环境下,停机需要花费数周或数月的时间,因为开发、运营和安全这三项功能都是孤立的。凭借DevSecOps流程和理念,终端用户可以通过简单的沟通和当天的修复获得无缝的体验。”
 
 
02
2018DevSecOps三大预测
 
2018年企业的DevSecOps将迎来一些真正的变革。
 
对于DevSecOps来说,2017年是美好的一年,DevSecOps从一个半朦胧的概念演变成可行的企业功能。
 
容器和容器市场的迅速扩张在很大程度上推动了这一演变,容器市场本质上与DevOps和DevSecOps相互交织在一起。一般来说,快速增长和创新往往比科学更能预测趋势,但我仍然愿意尝试一下。
 
从Docker Hub和成熟的容器生态系统中获取了超过120亿张图片,就企业的DevSecOps而言,我们几乎看不到冰山的一角。不过,相信在2018年,我们将看到:基础变革的开始。我认为它会是这样的:
 

 >>>>1.企业领导者和IT利益相关者意识到DevSecOps正在改进DevOps
 
DevOps将开发团队和运维团队聚在一起,它推动协作文化不足为奇。加入安全举措可能听起来很简单,但多年来,安全问题一直是事后的事情,导致企业文化容易使安全团队与其他IT团队形成对立,包括开发团队。 
但是事情发生了变化。
在雅虎亏损3.5亿美元的商业环境下,暴露了其脆弱的安全状况,企业领导者将网络安全看作是一个运维sinkhole的时代已经结束。加强网络安全现在是企业的当务之急。但这种转变需要时间才能重新回到IT文化中。
DevOps和DevSecOps的崛起无疑为重塑应用程序安全性创造了一个难得且令人兴奋的机会,但是DevOps可能会导致转变速度发生变化。DevOps团队和应用程序架构师每天都能够认识到安全的重要性,并欢迎安全团队的加入,但他们之间仍然存在需要磨合的鸿沟。
为正确实施DevSecOps,安全团队需要与DevOps团队保持一致,企业领导者需要为此打造空间和预算。到2019年,希望企业领导人能够意识到推动一个重要的、合法的安全胜利的机会。
 

>>>>2.成功的组织模式将会出现,最可能的是,安全与DevOps团队之间的紧密协作。

虽然该预测并不特别具有启发性,但是相关的。了解DevSecOps需要来自安全和DevOps团队的平等协作,快速跟踪标准蓝图或实施模型,将DevSecOps集成(并最终自动化)到CI / CD进程中。
虽然不同企业有不同的需求,但大多数公司都使用相同的技术工具,特别是在使用容器的情况下。这就为统一的标准化提供了条件。此外,容器的开源特性可以促进相关信息的共享和标准开发。
到目前为止,由于DevOps团队拥有开发流程,他们一直在安全方面处于领先地位。然而,我认为,DevSecOps需要由安全团队领导, 他们是负责企业安全和风险的人,当安全事故发生时,他们会被解雇或被迫离开。
2018年,安全团队需要加强并展示团队的价值和技能。将安全性融入到IT结构中,而不是在网络安全问题成为事实之后才想起。现在我们有机会来实现这一目标。
 

>>>>3.安全团队仍然要缓慢适应DevOps的现实

过去,企业安全团队通常在不重视或不了解安全需要的文化中运营。难怪今天的电商环境是大多数企业相对容易被破坏的环境。 
强大的安全性不仅仅是外围的防火墙。尽管许多安全专家可能最终会看到这种转变,但可能不像DevOps团队所期望的那样灵活。当谈到容器(通常是appsec)时,即使是最有才华和最优秀的安全专家也会面临学习的瓶颈。更不用说已经被充分证明的网络安全技能短缺的现状。
虽然这些因素可能在短期内降低安全对DevOps和 DevSecOps的支持,但是我认为DevSecOps是解决技能短缺问题的一部分。将安全集成到应用程序交付过程中,并将其自动化比用回溯方法更有效率和更具成本效益,可以解决在部署应用程序之前解决安全漏洞。安全专业人士可以通过开放的态度,以新的方式发挥他们的才能,从而获得很多收益。 
2018年希望这个故事有一个快乐的结局。
 

原文链接:
1、3 predictions for devsecops in 2018https://www.infoworld.com/article/3243155/devops/3-predictions-for-devsecops-in-2018.html2、   Why DevSecOps matters to IT leadershttps://enterprisersproject.com/article/2018/1/why-devsecops-matters-it-leaders
 
 
 
推荐阅读:
企业级落地容器与DevOps,选用K8S都有哪些“姿势”
7大ChatOps&5种团队协作工具助力DevOps实践
如果没按这7种习惯,你可能实践的是假DevOps
这款分布式配置中心,会是微服务的降维打击利器吗?
从架构到组件,深挖istio如何连接、管理和保护微服务2.0?
 
 
添加小数微信:xiaoshu062
备注公司、姓名、职位
小数将拉您进入相应技术群
 
点击数人云了解更多信息

微服务迁移前,来听听这6个思考和经验

dataman 发表了文章 • 0 个评论 • 118 次浏览 • 2018-01-30 10:15 • 来自相关话题

 
 
 小数近期为大家推送了不少微服务方面的文章,之前的一份微服务调研报告《微服务2017年度报告出炉:4大客户画像,15%传统企业已领跑》受到广泛关注。今天推送的这篇技术文章,与您再来深入探讨下企业为什么要寻求微服务,会遇到哪些问题,做好哪些准备。


今天,对软件的需求变化比以往任何时候都快。这就要求有一个合适的架构来实现灵活的变更。然而,考虑到Web应用的角度,灵活性往往受到阻碍。随着时间的推移,各种意想不到的依赖关系会使架构看起来像一个大泥球(Big Ball of Mud,BBoM)。


类似BBoM的庞大单体架构显示出的复杂性急剧增加。这需要各个团队之间的协调努力,才不会导致生产力降低。作为对策,企业引入了Scrum敏捷方法来优化他们的软件工程流程。但是,经常缺乏技术自主权。




1、敏捷性和微服务

在敏捷软件开发中,一个理想的架构足够灵活,可以处理快速调整的需求。遵循敏捷宣言的原则,最好的架构以功能需求驱动的方式出现。但架构也需要前期设计的努力,以实现预期的灵活性。由于需求的不确定性,严格的瀑布式的前期大型设计(Big Design Upfront ,BDUF)被忽略了。BDUF不适合大量连贯工作量的敏捷思想,也称为the batch size。


微服务方法限制了batch size,因为每一个微服务只涵盖整个应用的一部分。所有部分共同涵盖不同的业务功能,例如在电商应用中显示产品的详细信息。重要的一点是,单一业务能力的责任转移到一个需要跨职能一致和需要DevOps文化的团队。


因此,微服务是一个模块化的概念,可以解释技术层面和组织层面。这个想法是围绕清晰分离的业务能力建模一个架构,每个业务能力都是作为一个微服务实现的。通过实施自己的架构与系统的其他部分分离,允许建立大规模的软件增量与小型和独立的团队。微服务最适宜的企业是,旨在缩短业务上线时间,但无法应对当前架构和组织结构快速变化需求的那些企业。


向微服务迁移有许多挑战。以下提供了从BBoM引入微服务的几点指南。



2、微服务迁移的六大影响因素

向微服务的迁移可以完全脱离,也依赖于单体(因素1)。关键的决定是,目标架构的微服务是否包含自己的前端(frontend)(因素2)。在这个阶段,技术和组织方面之间的相互作用已经变得明确。当涉及从巨石中分离出第一个微服务时,应该确保底层的新模型不会被旧的破坏(因素3)。运维中的迁移应该考虑风险,并采取适当的措施(因素4)。通过自动化过程来支持(因素5)。把适当的工作放在优先位置。所需的透明度通过敏捷的组织文化来建立。将敏捷转换与微服务迁移结合起来会带来额外的挑战(因素6)。


1改变
人们经常认为,完全重写应用程序是充满风险的。但是这个应用程序的发布并不是以一个Big Bang的方式来完成的。相反,可以选择渐进的方法。但是,巨石应用和微服务一起构成应用程序的“微服务 – 单体 - 混合”架构往往是不可避免的。特别是如果有竞争的压力,新的特性必须不断传递给客户,那么混合是唯一的解决方案。迁移是一个长期的过程,可以持续2年以上。


为了缩短应用程序处于混合状态的时间,建议将迁移视为变化的机会。在这种情况下,改变意味着实施新的要求,而且接受现有功能的遗漏。一方面,考虑迁移的应用程序是旧的应用程序的准确副本,减少迁移工作是明智的。另一方面,提供不适用于旧技术堆栈的新功能增强利益相关方的信任。这种迁移可以视为进步而并非停滞。


2系统分解有两个必须考虑的决定。
首先,是否通过使用现有的代码库或者完全重写功能来提取微服务。
其次,定义目标架构,并且必须做出决定,微服务是自带前端,还是多个微服务集成在一个UI单体中。

当使用现有的代码库时,该代码库的副本就是跳板。那么给定的部分已经表现出高度的自主性。而且,当项目范围局限于较少人数开发应用时,这种方法可能会取得成功。当挑战是将多个团队分离时,建议将微服务定义为自己的前端。


这需要进一步讨论如何解释微服务的层次。关于三层架构,可以区分两种微服务类型。一方面是只包含数据和应用程序层的微服务(图1)。另一方面还有从数据层到表现层的微服务。


当使用“2层微服务”时,在建立前端的这种多微服务时建立了一个UI单体。这带来了将微服务整合到同一个前端的耦合团队的风险。相比之下,提供自己的前端部分的“全栈微服务”(例如UI碎片)则为团队提供了更高程度的自主权(图2)。


3模型边界保护作为一个起点,建议从中等复杂度的单个上下文开始。这样做的时候,保护即将实现这个上下文的微服务底层模型很重要。因此,应该规定一条规则,即禁止通过数据层访问(如JDBC或直接API调用)从整体数据访问数据。相反,数据应该从后台异步传输到后台的微服务,同时还要在新旧模式之间进行转换。这可以看作两个数据存储的同步,并符合构建防腐层(ACL)的思想,这是一个域驱动设计(DDD)的概念。在这种情况下,ACL可以作为微服务和巨石的模型完整性保护器(图3)。

风险监测任何迁移都有风险。特别是在进行完全重写时,如果新应用程序与现有应用程序相比得到相同的结果,则应使用与业务相关的度量标准(如营业额)进行衡量。然后,通过逐渐将新应用交付给越来越多的客户,控制经济风险。在这一点上,应该考虑诸如Canary Releasing的部署策略。


另外,建议在生产环境中测试微服务,然后再将其推广给客户。这可以通过向微服务提供请求并完全观察他们的行为Shadow Traffic来实现。性能问题可以在不影响应用程序的情况下展开,因为各自的响应被省略。这种做法是由两位专家和文献描述的。


其他措施也可以支持降低云服务迁移过程中的风险。使用诸如特性切换之类的机制在旧的和新的实现之间切换。它们提供了灵活性,仅通过更改配置来控制这一点,而无需重新部署整个应用程序。


5自动化和测试为了减少TTM(上市时间),作为微服务的部署流水线,建议将价值流建模和自动化。在这里,要考虑从代码提交到部署构建的每一步。这确保部署可以经常进行。此外,这从一开始就支持高度的测试覆盖,因为测试也是该流水线的一部分。


在考虑自动化测试时,专家会参考所谓的自动化测试金字塔。测试金字塔由三个测试层组成:单元,服务和UI测试。每层测试的数量减少,导致金字塔形状--许多单元测试和少量UI测试。为了确保多个微服务如预期的那样相互整合,依靠UI测试是合理的。但UI测试对于开发和维护来说是脆弱和昂贵的。这就是为什么在没有UI的情况下单独进行测试非常重要:使用模拟对象自主地测试微服务。借助模拟对象,可以模拟与其他微服务或巨石应用的交互。相应的测试被称为,自动测试金字塔内的服务级别测试。


6敏捷转型引入敏捷方法并立即迁移到微服务是巨大的变化。因此,建议将其分成几个步骤,并寻求逐渐改变。否则动机和定向障碍的风险太高。通过引入Scrum这样的敏捷方法,理想的微服务出现,是随着时间的推移争取团队的自主性。

尽管Scrum主要是在一个跨职能和以产品为中心的团队中解决软件开发过程,大规模的组织也需要采用。Scrum没有提供解决多个敏捷团队协调的解决方案。还有一些坚定的观点认为,对于大型项目来说,应该避免使用灵活的方法来分割产品。随着时间的推移,出现了不同的Scrum和敏捷方法扩展方法。例如,LeSS(大规模Scrum),Nexus和SAFe(缩放敏捷框架)是根据其市场份额为大型组织提供敏捷性的相关方法。


在更大的组织环境中建立敏捷方法时,建议先从一个团队开始,然后再增加越来越多的团队。同样在LeSS中,这被描述为耗时,但却是以功能为中心的团队,同时打破功能孤岛的安全方式。




透明度

此外建议记录产生的非功能性工作,例如在积压工作中实施ACL,并合理安排其他要求。在SAFe中,引入了可以代表上述技术和机制的实施以及迁移工作的推动者的故事。它们确保了透明度,展现了业务与IT之间潜在的相互依赖关系。因此,应根据2位专家的建议,与企业和技术负责人进行优先排序。

图4:敏捷和微服务之路



3、总结

微服务包含组织层面和技术方面。这就是为什么引入微服务涉及两种情况下的措施。如果没有单体考虑,微服务的好处是脆弱的。从纯粹的技术角度来看,微服务可以使用瀑布式软件工程方法来实现。但是,为了充分发挥每个微服务的自主性,它们被嵌入到敏捷文化中。


特别是,拥有多个团队的组织可以从微服务的非技术方面获益。从数据层向前端分解一个系统,将团队分离开来。因此,如果多个团队使用一个前端开发应用程序,那么团队边界在架构中反映最好。这些团队可以自主地加速应用程序的部分。在单体应用程序和分层的团队中,这是更困难的。在这里,复杂的依赖需要协调跨越团队边界的活动。因此TTM下降。


由于敏捷团队由开发人员和非技术人员组成,因此IT和业务需要携手合作。微服务的出现是由于敏捷团队争取自主权。当团队决定转向微服务时,迁移本身没有任何价值,可以向客户交付新功能。尽管如此,微服务迁移工作仍需要优先考虑。这需要透明度。只有不断提高透明度,敏捷性和微服务才能彼此加速。否则,长期不会降低TTM的风险很高。


为了避免在引入微服务时构建未来的传统软件,建立敏捷思维和不断重新思考解决方案很重要。


原文链接:
6 Things to Consider for Microservice Migration

  查看全部

v2-342dd117dd4cd06bde68a2b67dc3857e_hd.jpg

 
 
 小数近期为大家推送了不少微服务方面的文章,之前的一份微服务调研报告《微服务2017年度报告出炉:4大客户画像,15%传统企业已领跑》受到广泛关注。今天推送的这篇技术文章,与您再来深入探讨下企业为什么要寻求微服务,会遇到哪些问题,做好哪些准备。


今天,对软件的需求变化比以往任何时候都快。这就要求有一个合适的架构来实现灵活的变更。然而,考虑到Web应用的角度,灵活性往往受到阻碍。随着时间的推移,各种意想不到的依赖关系会使架构看起来像一个大泥球(Big Ball of Mud,BBoM)。


类似BBoM的庞大单体架构显示出的复杂性急剧增加。这需要各个团队之间的协调努力,才不会导致生产力降低。作为对策,企业引入了Scrum敏捷方法来优化他们的软件工程流程。但是,经常缺乏技术自主权。




1、敏捷性和微服务

在敏捷软件开发中,一个理想的架构足够灵活,可以处理快速调整的需求。遵循敏捷宣言的原则,最好的架构以功能需求驱动的方式出现。但架构也需要前期设计的努力,以实现预期的灵活性。由于需求的不确定性,严格的瀑布式的前期大型设计(Big Design Upfront ,BDUF)被忽略了。BDUF不适合大量连贯工作量的敏捷思想,也称为the batch size。


微服务方法限制了batch size,因为每一个微服务只涵盖整个应用的一部分。所有部分共同涵盖不同的业务功能,例如在电商应用中显示产品的详细信息。重要的一点是,单一业务能力的责任转移到一个需要跨职能一致和需要DevOps文化的团队。


因此,微服务是一个模块化的概念,可以解释技术层面和组织层面。这个想法是围绕清晰分离的业务能力建模一个架构,每个业务能力都是作为一个微服务实现的。通过实施自己的架构与系统的其他部分分离,允许建立大规模的软件增量与小型和独立的团队。微服务最适宜的企业是,旨在缩短业务上线时间,但无法应对当前架构和组织结构快速变化需求的那些企业。


向微服务迁移有许多挑战。以下提供了从BBoM引入微服务的几点指南。



2、微服务迁移的六大影响因素

向微服务的迁移可以完全脱离,也依赖于单体(因素1)。关键的决定是,目标架构的微服务是否包含自己的前端(frontend)(因素2)。在这个阶段,技术和组织方面之间的相互作用已经变得明确。当涉及从巨石中分离出第一个微服务时,应该确保底层的新模型不会被旧的破坏(因素3)。运维中的迁移应该考虑风险,并采取适当的措施(因素4)。通过自动化过程来支持(因素5)。把适当的工作放在优先位置。所需的透明度通过敏捷的组织文化来建立。将敏捷转换与微服务迁移结合起来会带来额外的挑战(因素6)。


1改变
人们经常认为,完全重写应用程序是充满风险的。但是这个应用程序的发布并不是以一个Big Bang的方式来完成的。相反,可以选择渐进的方法。但是,巨石应用和微服务一起构成应用程序的“微服务 – 单体 - 混合”架构往往是不可避免的。特别是如果有竞争的压力,新的特性必须不断传递给客户,那么混合是唯一的解决方案。迁移是一个长期的过程,可以持续2年以上。


为了缩短应用程序处于混合状态的时间,建议将迁移视为变化的机会。在这种情况下,改变意味着实施新的要求,而且接受现有功能的遗漏。一方面,考虑迁移的应用程序是旧的应用程序的准确副本,减少迁移工作是明智的。另一方面,提供不适用于旧技术堆栈的新功能增强利益相关方的信任。这种迁移可以视为进步而并非停滞。


2系统分解有两个必须考虑的决定。
首先,是否通过使用现有的代码库或者完全重写功能来提取微服务。
其次,定义目标架构,并且必须做出决定,微服务是自带前端,还是多个微服务集成在一个UI单体中。

当使用现有的代码库时,该代码库的副本就是跳板。那么给定的部分已经表现出高度的自主性。而且,当项目范围局限于较少人数开发应用时,这种方法可能会取得成功。当挑战是将多个团队分离时,建议将微服务定义为自己的前端。


这需要进一步讨论如何解释微服务的层次。关于三层架构,可以区分两种微服务类型。一方面是只包含数据和应用程序层的微服务(图1)。另一方面还有从数据层到表现层的微服务。


当使用“2层微服务”时,在建立前端的这种多微服务时建立了一个UI单体。这带来了将微服务整合到同一个前端的耦合团队的风险。相比之下,提供自己的前端部分的“全栈微服务”(例如UI碎片)则为团队提供了更高程度的自主权(图2)。


3模型边界保护作为一个起点,建议从中等复杂度的单个上下文开始。这样做的时候,保护即将实现这个上下文的微服务底层模型很重要。因此,应该规定一条规则,即禁止通过数据层访问(如JDBC或直接API调用)从整体数据访问数据。相反,数据应该从后台异步传输到后台的微服务,同时还要在新旧模式之间进行转换。这可以看作两个数据存储的同步,并符合构建防腐层(ACL)的思想,这是一个域驱动设计(DDD)的概念。在这种情况下,ACL可以作为微服务和巨石的模型完整性保护器(图3)。

风险监测任何迁移都有风险。特别是在进行完全重写时,如果新应用程序与现有应用程序相比得到相同的结果,则应使用与业务相关的度量标准(如营业额)进行衡量。然后,通过逐渐将新应用交付给越来越多的客户,控制经济风险。在这一点上,应该考虑诸如Canary Releasing的部署策略。


另外,建议在生产环境中测试微服务,然后再将其推广给客户。这可以通过向微服务提供请求并完全观察他们的行为Shadow Traffic来实现。性能问题可以在不影响应用程序的情况下展开,因为各自的响应被省略。这种做法是由两位专家和文献描述的。


其他措施也可以支持降低云服务迁移过程中的风险。使用诸如特性切换之类的机制在旧的和新的实现之间切换。它们提供了灵活性,仅通过更改配置来控制这一点,而无需重新部署整个应用程序。


5自动化和测试为了减少TTM(上市时间),作为微服务的部署流水线,建议将价值流建模和自动化。在这里,要考虑从代码提交到部署构建的每一步。这确保部署可以经常进行。此外,这从一开始就支持高度的测试覆盖,因为测试也是该流水线的一部分。


在考虑自动化测试时,专家会参考所谓的自动化测试金字塔。测试金字塔由三个测试层组成:单元,服务和UI测试。每层测试的数量减少,导致金字塔形状--许多单元测试和少量UI测试。为了确保多个微服务如预期的那样相互整合,依靠UI测试是合理的。但UI测试对于开发和维护来说是脆弱和昂贵的。这就是为什么在没有UI的情况下单独进行测试非常重要:使用模拟对象自主地测试微服务。借助模拟对象,可以模拟与其他微服务或巨石应用的交互。相应的测试被称为,自动测试金字塔内的服务级别测试。


6敏捷转型引入敏捷方法并立即迁移到微服务是巨大的变化。因此,建议将其分成几个步骤,并寻求逐渐改变。否则动机和定向障碍的风险太高。通过引入Scrum这样的敏捷方法,理想的微服务出现,是随着时间的推移争取团队的自主性。

尽管Scrum主要是在一个跨职能和以产品为中心的团队中解决软件开发过程,大规模的组织也需要采用。Scrum没有提供解决多个敏捷团队协调的解决方案。还有一些坚定的观点认为,对于大型项目来说,应该避免使用灵活的方法来分割产品。随着时间的推移,出现了不同的Scrum和敏捷方法扩展方法。例如,LeSS(大规模Scrum),Nexus和SAFe(缩放敏捷框架)是根据其市场份额为大型组织提供敏捷性的相关方法。


在更大的组织环境中建立敏捷方法时,建议先从一个团队开始,然后再增加越来越多的团队。同样在LeSS中,这被描述为耗时,但却是以功能为中心的团队,同时打破功能孤岛的安全方式。




透明度

此外建议记录产生的非功能性工作,例如在积压工作中实施ACL,并合理安排其他要求。在SAFe中,引入了可以代表上述技术和机制的实施以及迁移工作的推动者的故事。它们确保了透明度,展现了业务与IT之间潜在的相互依赖关系。因此,应根据2位专家的建议,与企业和技术负责人进行优先排序。

图4:敏捷和微服务之路



3、总结

微服务包含组织层面和技术方面。这就是为什么引入微服务涉及两种情况下的措施。如果没有单体考虑,微服务的好处是脆弱的。从纯粹的技术角度来看,微服务可以使用瀑布式软件工程方法来实现。但是,为了充分发挥每个微服务的自主性,它们被嵌入到敏捷文化中。


特别是,拥有多个团队的组织可以从微服务的非技术方面获益。从数据层向前端分解一个系统,将团队分离开来。因此,如果多个团队使用一个前端开发应用程序,那么团队边界在架构中反映最好。这些团队可以自主地加速应用程序的部分。在单体应用程序和分层的团队中,这是更困难的。在这里,复杂的依赖需要协调跨越团队边界的活动。因此TTM下降。


由于敏捷团队由开发人员和非技术人员组成,因此IT和业务需要携手合作。微服务的出现是由于敏捷团队争取自主权。当团队决定转向微服务时,迁移本身没有任何价值,可以向客户交付新功能。尽管如此,微服务迁移工作仍需要优先考虑。这需要透明度。只有不断提高透明度,敏捷性和微服务才能彼此加速。否则,长期不会降低TTM的风险很高。


为了避免在引入微服务时构建未来的传统软件,建立敏捷思维和不断重新思考解决方案很重要。


原文链接:
6 Things to Consider for Microservice Migration

 

微服务落地践行渐进,4个Q&A一窥金融微服务现状

杨y 发表了文章 • 0 个评论 • 133 次浏览 • 2018-01-18 00:47 • 来自相关话题

1月13日,中国双态运维用户大会在北京举办。来自银行、保险、证券、政府、央企等多个行业的330多位企业用户参加,其中工商银行信息科技部副总经理张艳,国泰君安信息技术部总经理俞枫、海关总署科技发展司运行安全处处长张芳、平安科技系统运营部总经理陈亚殊等分别发表了演讲。本文为数人云CEO王璞在双态运维用户大会DevOps、容器与微服务分论坛上的演讲实录。演讲结束,与在座金融客户展开了精彩的Q&A分享。

容器、微服务、DevOps三者,业内的共识是密不可分。没有微服务,DevOps落地不下去,没有容器,DevOps也无法真正实现敏捷运维、自动化运维。DevOps、容器、微服务为更好的构建PaaS提供了方法论和技术手段。

1、PaaS之承上启下

PaaS作为云计算的承上启下要素,向上支撑各环境应用,向下跟IaaS、计算环境、计算资源对接,是企业云化的必由之路。>>>>PaaS三大技术趋势

1.应用容器化,容器正在成为云计算原生应用的标准交付方式。

2.微服务网格化,随着企业对微服务的认知越来越深入,下一代微服务着重把应用管理作为核心。因为企业应用一定要有很强的管理在微服务架构上,不能让应用去“裸奔”。数人云没有提微服务化,因为微服务化已经是不争的事实。应用微服务缺乏强大的管理,需要服务网格这样的下一代微服务技术。

3.行业生态化,PaaS技术本质上是支持应用的,应用跟业务紧密结合,所以PaaS最终是要和业务层面融合,行业需要生态化。>>>>PaaS落地三大要素:

PaaS要在企业客户方面落地不可或缺三要素:规模化、统一化、标准化。企业客户落地云计算平台、技术,本质上是希望提高效率,对业务有更好的敏捷支撑。

所有应用,比如容器应用、微服务应用,都实现标准化。标准化以后进行统一化管理,包括部署、发布、故障恢复、监控告警等都实现统一化管理。最后实现模块化,整个系统都是轻量的,微小模块化的。只有基于这三点的PaaS平台和云计算平台,才能够让IT系统真正实现敏捷轻量,提高IT对业务支撑的效果。

2、企业IT架构转型之开发&运维

企业客户目前在架构转型应用中面临的现状是,企业里大量传统应用,客户希望先实现轻量的单体架构,即摆脱很多中间件,摆脱外部服务,MVC架构、单体复杂架构等首先实现轻量化。

数人云日常接触的客户中,走的比较靠前的客户已经在用Spring Cloud、Dubbo等架构,部分客户相当数量的应用已经微服务化,不过处于中间状态,正在考虑评估微服务架构的客户比例还是最大。总之,企业目前的现状是为服务应用、轻量单体应用,以及传统的巨石应用并存。

在架构转型过程中,正确和常态的路径一定是一步步走过来,而不是传统架构丢掉直接上微服务。>>>>DevOps和容器@轻量单体应用架构

在单体应用架构下,DevOps、容器帮助企业实现敏捷IT。首先,持续集成持续交付CI/CD,只要应用是相对轻量的,就能加快中间件应用。CI/CD其中重要的一点是变更发布管理。


数人云某客户上了容器的应用都是轻量化的,基于 Tomcat 和微服务的应用。当基于容器实现快速发布以后,企业发现,所有发布里有一半的发布失败是由于配置不正确引起的。所以,如果没有发布变更管理,发布失败的中间环节有方方面面的因素。

当基于容器实现快速发布之后,容器对环境的异构做了一层屏蔽,这时如果出现处理的问题就是配置管理的问题了,由于涉及不同的环境和应用,配置环境变成应用发布很容易出错的环节。>>>>DevOps和容器@微服务应用架构

数人云做了企业客户微服务落地状况的调研(微服务2017年度报告出炉:4大客户画像,15%传统企业已领跑),在报告中,有15%左右的企业引入了Spring Cloud、Dubbo。微服务在企业里首当其冲的是敏捷开发,因为微服务是一种切实的敏捷开发的方法。


敏捷开发在IT界已经推广多年,但很多时候敏捷开发推的都是方法论,比如Scrum。微服务是一套切实能够落地到IT人员、开发人员开发过程中的实践方法,这是微服务首当其冲的好处,很多企业的开发部门对微服务非常欢迎。不过,15%还是偏小的一个采用比例,微服务还不是企业客户主流的IT架构。

开发人员都比较欢迎微服务,因为能够提升开发效率,落地敏捷开发,但微服务的阻碍还是不小的,微服务对开发运维来说,带来的复杂度急剧上升。传统运维管理的服务器数量、应用数量有限。企业决定采用微服务本身就表明业务很复杂,单体应用做传统的瀑布式开发效率太低,微服务将应用拆分成较小的模块,因此微服务应用一旦上线,程序的数量呈现爆炸式增长。


例如,数人云某个传统企业的客户,目前部署了微服务相关的应用,基于Spring Cloud、Spring Boot,跑在几千个容器上,几千个容器如果通过传统运维方式去管理的话几乎是不可能的。这就是很多微服务无法落地的原因——很多企业客户缺乏相应的运维能力,没有相应的平台、工具、方式、方法管理微服务应用。
 
>>>>微服务落地的必要条件


微服务应用落地,首当其冲是配套工具链的完善。开发人员采用微服务的影响相对改变小一些。采用SpringCloud或者Dubbo、gRPC等,只是开发框架上的并更。其他开发流程如代码托管、代码审查、测试等并不涉及,所以开发流程相对简单。但微服务对运维功能的要求就会复杂,相应的快速配置能力、完备的监控能力、快速部署能力等对传统运维来说都是缺失的,容器能够补足这方面的能力,让运维部门具有DevOps的能力。

关于微服务的拆分,其实是业务部门需要真正解决的问题。微服务对组织上也有变更,将团队化整为零。通常每个单独的微服务程序都由7-10人的小团队来负责维护,这些都是微服务落地的必要条件。
 
对于数人云来说,直接能够给客户提供的帮助,首先是工具链方面,数人云产品层面具备丰富的微服务配套工具链,从监控、日志、调度、故障自动化修复等等都有完备的工具链。在落地方法上,数人云搭建了自己的生态圈,和很多合作伙伴合作,例如跟埃森哲公司在合作,帮助企业客户落地微服务,进行业务的梳理。
 
>>>>容器和微服务共生


容器技术补齐了微服务相关的工具链,对企业全面向云计算转型提供了很大帮助。应用架构是微服务分布式的,相应的运维也要有自动化、敏捷运维的能力。微服务跑在容器上才能发挥它最好的特性。容器是目前最流行的应用环境,基于容器的微服务部署和更新更快,更轻量,服务之间的调用、服务发现、负载均衡等更灵活。


不过,微服务不是万能的。简单的业务场景单体应用其实足够,微服务一定是应用在复杂的业务场景下,只有复杂的业务场景才有很大的维护成本、维护压力,微服务是用来降低复杂业务场景的维护成本。>>>>基于容器云的微服务运行时管理体系

一个完整的微服务管理体系,除了开发框架之外,对运维部门来说,运维微服务应用最基本的路由、负载均衡等功能,容器可以提供,不过容器提供的只是一部分跟微服务相关的能力和工具链。周围还有一大批需要配套的工具,比如配置管理、API网关、注册发现、应用监控等等。这里的监控不是容器CPU内存的监控,而是业务逻辑的监控,更准确一点是全链路跟踪的全链路监控。容器满足了微服务运行时管理的需求,不过周边许多权限、网关、配置等尚无余力满足。

>>>>统一配置中心是微服务体系的核心

统一配置管理,是微服务落地时很核心的点。要在平台工具上落地微服务首先要具备快速配置能力,因为客户采用微服务和容器平台以后,很快会发现50%以上的发布失败是因为配置没搞对,因此配置管理是微服务里首当其冲的问题。

因为每个企业客户都有开发环境、测试环境、生产环境等很多环境,同一个应用不同版本在不同环境下的配置不同。几何级数的配置项、配置元素的增长会导致配置管理的复杂度急剧上升,需要统一的配置中心进行管理。数人云在帮助企业客户落地微服务时,首先会做的是把配置搞定,没有灵活快速的配置管理能力,微服务运行不起来。
 
>>>>变更发布管理(灰度发布 v.s. 蓝绿部署)

在发布管理方面,数人云帮助企业落地的发布管理主要是蓝绿部署,因为很多企业的应用本身不支持灰度发布。蓝绿部署也是切切实实的快速发布,发布用变更窗口的方式来实现。

例如,周五晚上12点起进行发布变更,12点就要停服务中心。蓝绿部署可以显著地缩短服务不可用的变更窗口。怎么做呢?客户在线上有两个版本,蓝版本和绿版本。现在负载均衡器将流量指向对外提供服务的绿版本,蓝版本作为备用的方案。同时,新程序往蓝版本上部署推送,更新时只需要把流量切换到蓝版本。发布流程最后简化为只需要进行流量的切换。流量可以快速切换,中间的窗口期只有短短几分钟,如果流量切换过来一切正常发布即完成,如果流量切换过来发现问题,可以再将流量切回去。这样开发人员、运维人员不必当场熬夜去修复,极大地减轻了发布的压力。

传统发布方式下,每次变更窗口有好几个应用排队发布,一个应用发布完成后才可以发布下一个应用,一旦中间某一个应用发布失败现场修复的压力非常大,短短的发布窗口需要几个小时内完成抢修,非常不可控,团队经常需要晚上熬夜排队。而结果往往等了半天,前面的应用没发布成功,后面的还得继续排队等。

3、金融行业之践行渐进

数人云在金融、能源、制造、快消、政企等行业的基础上,继续深耕强监管、强安全,高复杂度的金融行业。以某商业银行为例,数人云帮助落地了大规模微服务容器平台。该商业银行近年来互联网业务发展迅猛,原有系统架构无法支撑其未来规划。2016年6月开始全面实施应用微服务化,已实现蓝绿发布。


首先,营销系统全部是轻量化的应用,基于Spring Boot、Tomcat、SpringCloud等,跑在容器平台上。该银行对外营销频次非常高,通过线上微信公众号、手机APP、线上门户、合作伙伴等渠道,每月对外营销达上百场。

每次营销活动或多或少都对IT系统有变更,哪怕是配置变更,因此每次营销活动对IT系统都是一次不小的挑战。发布的时候仅仅靠容器是不够的,需要实现模板的批量发布。每次发布看起来只是一个个的容器程序,实则不然,其实是一组组一批批的容器,只有帮客户做到批量的应用发布,才能显著提升发布效率。

蓝绿部署方面,该银行密集的线上营销中,每一天会有一个重点营销活动,那么营销活动的流量如何分到特别的人群、区域?在后台应用的上千个实例中,并不是每一个实例都分配同等的流量,要通过流量分发,做线上流量控制。数人云借鉴Google做灰度发布的方式为客户提供图形化的流量控制,这和微服务实施后的限流分流是息息相关的。

另外,该银行客户的数据流量非常大,对日志收集带来非常大的的压力。数人云建议客户将应用程序的日志全部交给Kafka采集,Kafka可以做到很大数据流量的分布式消息应用。

分布式数据传输分布式消息应用很难保证每一个消息都可靠地传递。Kafka有两种模式:一种保证消息传递至少一次,但也可能多次,对很大的日志量来说偶尔丢一两条可以忽略不计。Kafka的并发量很大,可能带来偶尔很小的数据量丢失,也可能带来日志的乱序,这在分布式系统下都是可以容忍的,“鱼和熊掌不可兼得”。

关于快速建立支撑微服务体系,数人云有几点总结:
 
1.开发框架不能用重量级的应用体系,要么是轻量化单体架构的Tomcat等,要么采用Spring Cloud等微服务架构。

2.要有微服务平台,具备快速配置管理能力、部署能力、监控能力、应用管理能力等配套管理能力。很多企业的痛点是,开发人员快速学习微服务开发技术,基于Spring Cloud做业务系统后,业务系统无法上线,因为运维部门缺乏配套的工具、平台支撑微服务线上运行管理。

3.DevOps融合,平台管理需要把链条全打通,实现快速发布、快速上线、自动修复等。容器经过几年的普及企业已经相对了解,但容器本身是纯技术平台,基于容器、DevOps的落地还有很长的路要走。>>>>数人云微服务On PaaS 产品体系


数人云现在的重点是微服务、轻量单体应用。以前数人云帮企业客户落地重应用的容器平台,但后来发现价值不大,反而对企业来说,除了维护重的应用外还需要维护容器,容器平台并不能实现自动化运维。经过几年的实践和摸索,数人云跟企业客户达成的共识是,传统应用不经过改造无法上到云PaaS平台。

 轻量架构下的应用如何基于PaaS平台支撑?以敏捷开发为例,企业客户通常选择 Spring Cloud、gRPC 等主流的开发框架,然后在微服务工具链层面配置监控、报警、部署、快速发布等方方面面的能力,最下面承载的则是容器平台。


数人云现在还可以帮助客户落地服务网格化技术。它能够进行异构架构的兼容,gRPC就是服务网格的一部分,Google推的 Istio,Linkerd的Kubernetes 都支持 gRPC,gRPC成为通讯协议的一部分。基于通讯协议相应周边的管理,在服务网格这一层可以做灰度发布、A/B测试、流量控制、高级熔断、加密、白/黑名单机制、权限访问控制等等。


服务网格被称作下一代的微服务,因为用了服务网格以后,所有微服务管理的诉求都自动化地满足了。80%-90%的应用管理需求都在服务网格里自动涵盖。这对开发人员来讲,微服务开发的门槛急剧降低,不需要考虑未来应用上线时流量控制、灰度发布等等,只需要考虑业务。数人云微服务On PaaS 目的就是帮助企业客户降低微服务架构、上云转型的门槛。


 Q&A
 
Q1:感觉对DevOps的理解不太到位,能不能具体地讲一下?A1:DevOps准确来讲,现在业内还没有统一的认识。互联网公司的DevOps目前是比较统一的,比如Goolge,但是互联网公司的DevOps,我个人理解没办法在企业直接落地。




在Google,程序员不止要负责应用的开发,还要负责相应的测试,单元测试、集成测试等等。另外,应用的部署、发布、上线也是开发人员自己做。所以互联网公司讲DevOps,更多讲的是开发运维的融合。我之前在Google时,不仅要做代码开发,也要把测试的代码全写出来。

Google有一个理念,开发人员每写一行业务代码,测试代码要写十行。然后,开发人员利用各种发布平台定期发布,比如每周做发布,在Google 运维的人员叫“SRE”。SRE部门准备好各种平台,开发人员可以用这些平台做发布、监控、日志管理等工作。

Google目前有三万名左右的IT人员,其中SRE的运维人员只有一千多,比例很低。所以在Google运维人员不可能帮每一个开发人员或者业务部门做上线。像传统IT开发人员提工单给运维,在Google是不可能的。Google这种做法,它让开发做更多的事情,运维人员很少,只是负责维护平台。所以,Google一千多人管理着几百万台服务器,平均每人管两千台。


但传统企业目前不是这样,传统企业开发和运维之间壁垒比较大。数人云帮助客户落地DevOps 时,基于的理念是,不要破坏现有开发的流程。DevOps应该是开发和运维深度融合才能做到的。讲DevOps,首先要讲理念、组织的变革,但是要想把文化变革、组织变革打破要很长时间。

从落地的角度,DevOps更多落地在运维部门,很具象的工作就是,帮助运维部门去实现DevOps的能力,比如快速部署、快速上线,应用的快速配置,自动化管理能力、故障的自动化处理等等。把以前的运维工作尽可能的自动化,提高效率,这是狭义的DevOps理念,也是我们现在接触到的。数人云不会帮客户落地像互联网公司那样的DevOps,开发做很多事情,运维可做的很少,并不是这样的。

Q2:微服务适合复杂的场景,那么一个简单的促销是不是适合?微服务有多“微”呢?微服务和ESB 服务相比,有什么差别?A2:第一个促销场景,促销场景本身有些条件,促销很重要一点就是必须特别频繁,促销内容在平台要发生变化。比如,今天的促销内容和明天的不太一样,或者这周的促销和下周的不太一样,业务平台需要频繁变更,这时候微服务是适合的。

因为微服务是一种敏捷开发的落地实践方法,只要业务频繁变更,对开发的要求就必须敏捷开发,快速实现。所以,只要业务场景在不停地快速变化,促销又是互联网线上的方式,肯定是适合的。

关于复杂性,如果业务逻辑简单,逻辑变化少,并不适合微服务。比如数人云和很多银行客户合作,银行核心系统很复杂,但是银行系统并不是需求频繁变化的场景。很多银行在做“瘦核心系统”,就是银行核心系统的功能越来越单一,越来越瘦,并不是把复杂的周边的业务也放到银行核心系统里。银行核心系统虽然复杂,但业务不会频繁变化,也不一定要上到微服务场景下。复杂的业务系统,业务需求又不停变化,这种场景适合微服务。

第二个问题是和ESB 比,服务网格和 ESB 有很多相像的地方。ESB有业务逻辑串起来,很多不同的业务系统都上到ESB,互相的权限通过ESB打通。从功能角度讲,ESB和服务网格之间很相像,不同点在于ESB是传统架构下的,并没有考虑频繁迭代、流量集中爆发等问题。


但是微服务情况下,整个之间的互相请求、依赖、通讯等等都会进行统一的管理,这种情况下也很像ESB把不同业务之间的流量进行统一管理,但是服务网格更看重的是面向大规模的控制,那流量突发怎么做限流,或者突然故障怎么做熔断等等。最本质的问题是类似的,但是具体的问题表象和需求不同。

Q3:在实际部署过程中,PaaS平台在底层资源的调用一定要用分布式云架构,传统主机是否可以?两者在最后效果上有没有什么异同?A3:数人云当初两种情况都有,有些场景比如业务量比较大,企业客户为了减少复杂度,容器PaaS平台直接落地到物理服务器上。还有客户为了方便管理,把PaaS落地到IaaS上,两种情况都有。

这其中的考虑是,首先业务量大如果再引入虚拟化这一层会引来额外的复杂度,此时用物理服务器更好。其次,客户有很大规模的物理服务器,直接在上面部署PaaS,在物理服务器上去调用。


第三种,资源动态的调整或资源频繁调配,这个场景很常见,需要IaaS。比如银行客户,内部业务系统分不同的域,不同域的业务复杂性随时间变化经常会发生变化,需要不停地做资源动态的调整。如果用物理机太麻烦,企业客户会选择下面有一层IaaS来做。

基于PaaS也能做一部分的资源动态调配,但是调配维度不同。数人云帮客户落地PaaS时会做资源的整合。从划分的维度,PaaS平台是按照应用程序来划分,IaaS的资源划分是按照业务系统。

Q4:微服务重新开发,最佳的开发框架或者实践有什么可以分享的?第二,旧有的系统改造到微服务这块有没有什么经验?第三,DevOps以前也有很多像敏捷开发的方法论,它们之间有没有什么关系?A4:首先第一个问题,微服务的开发框架。企业客户在做选择时都希望降低风险,选最主流的框架,现在看最主流的开发框架就是Spring cloud,这也是业界的自然选择结果。其他语言也都有些微服务开发,但是用的人少一些。如果是Java应用,目前比较好的选择是Spring Cloud,也有很多客户用了Dubbo,其他架构都是偏小众的架构,主要还是看客户自己的需求。

第二个问题,传统业务要转到微服务架构上,一定要循序渐进。比如Java应用,首先Java中间件的应用,先脱掉,不要再基于这么重的Java中间件。目前相对流行的是Spring Boot这套逻辑。

有了轻量的单体化应用之后(基于Tomcat),往后走基于微服务的框架,上到Spring Boot,再上到Spring Cloud,这是比较平滑的方式。Spring Boot 在很企业客户中用的非常多,是很方便的一套单体开发架构。

企业客户目前的现状是老的应用很多,不会一次就改造完,传统的应用可以先选择一部分容易转的转到轻量单体架构上,然后再转到微服务框架上。目前企业客户是轻量的单体架构、微服务架构,以及大量传统的架构应用并存。老的架构应用目前上不到PaaS平台,只有轻量的单体化加微服务应用才能上到PaaS平台。

现在业内的共识是,微服务、容器、DevOps这三者是密不可分的。微服务更多是针对开发人员,是一种真正落地的云开发方法。很多企业客户也讲敏捷开发,派团队成员学习敏捷开发的方法论,但是敏捷开发仍然无法在企业当中落地。

这是因为,只学会了方法,但没办法落地到具体的编程,即开发环节上去,自然没办法做到敏捷开发。很多开发者回来写的程序依然是J2EE。J2EE 编程的理念和方法并不是敏捷开发的,是偏向于瀑布式的。

微服务是具体的开发环节上的敏捷开发方法,开发能力化整为零,每个团队做简单、具象、单一的逻辑。微服务首先是一个具像的敏捷开发方法,实践方法。

微服务在落地时,比如程序运行时,复杂度很高,因为不是一个程序,是一批程序一起运行,对运维的管理就比较复杂,这时候可以利用容器实现微服务应用的自动化管理。微服务一般都会上到容器,因为微服务应用不再是单体的部署方式,不再是部署到Java中间件上。基于微服务架构,几百个进程进来,用容器的方式实现快速部署动态调度,微服务部署到容器上,实现基础的轻量化运维。


轻量化运维,快速部署、自动化调度,逐步往DevOps方向走。DevOps更多强调自动化的运维能力,提高运维的效率,快速部署,出了问题自动化修复。需要用到工具和平台,这就是数人云现在帮客户去做的。


把微服务业务在运行时缺失的管理方式方法、工具平台,工具链补齐。首先是配置管理能力、完备的监控能力等等,普及之后运维人员就有能力来管微服务应用。这其实是DevOps里面最狭义的,让运维的能力变得轻量。


如果要真正实现DevOps,就像目前一些互联网公司做到的,开发和运维真正的深度融合在一起。企业目前的运维一般不具有编程能力,所以真正的DevOps还需要很长时间去落地。 查看全部

1月13日,中国双态运维用户大会在北京举办。来自银行、保险、证券、政府、央企等多个行业的330多位企业用户参加,其中工商银行信息科技部副总经理张艳,国泰君安信息技术部总经理俞枫、海关总署科技发展司运行安全处处长张芳、平安科技系统运营部总经理陈亚殊等分别发表了演讲。本文为数人云CEO王璞在双态运维用户大会DevOps、容器与微服务分论坛上的演讲实录。演讲结束,与在座金融客户展开了精彩的Q&A分享。

容器、微服务、DevOps三者,业内的共识是密不可分。没有微服务,DevOps落地不下去,没有容器,DevOps也无法真正实现敏捷运维、自动化运维。DevOps、容器、微服务为更好的构建PaaS提供了方法论和技术手段。

1、PaaS之承上启下

PaaS作为云计算的承上启下要素,向上支撑各环境应用,向下跟IaaS、计算环境、计算资源对接,是企业云化的必由之路。>>>>PaaS三大技术趋势

1.应用容器化,容器正在成为云计算原生应用的标准交付方式。

2.微服务网格化,随着企业对微服务的认知越来越深入,下一代微服务着重把应用管理作为核心。因为企业应用一定要有很强的管理在微服务架构上,不能让应用去“裸奔”。数人云没有提微服务化,因为微服务化已经是不争的事实。应用微服务缺乏强大的管理,需要服务网格这样的下一代微服务技术。

3.行业生态化,PaaS技术本质上是支持应用的,应用跟业务紧密结合,所以PaaS最终是要和业务层面融合,行业需要生态化。>>>>PaaS落地三大要素:

PaaS要在企业客户方面落地不可或缺三要素:规模化、统一化、标准化。企业客户落地云计算平台、技术,本质上是希望提高效率,对业务有更好的敏捷支撑。

所有应用,比如容器应用、微服务应用,都实现标准化。标准化以后进行统一化管理,包括部署、发布、故障恢复、监控告警等都实现统一化管理。最后实现模块化,整个系统都是轻量的,微小模块化的。只有基于这三点的PaaS平台和云计算平台,才能够让IT系统真正实现敏捷轻量,提高IT对业务支撑的效果。

2、企业IT架构转型之开发&运维

企业客户目前在架构转型应用中面临的现状是,企业里大量传统应用,客户希望先实现轻量的单体架构,即摆脱很多中间件,摆脱外部服务,MVC架构、单体复杂架构等首先实现轻量化。

数人云日常接触的客户中,走的比较靠前的客户已经在用Spring Cloud、Dubbo等架构,部分客户相当数量的应用已经微服务化,不过处于中间状态,正在考虑评估微服务架构的客户比例还是最大。总之,企业目前的现状是为服务应用、轻量单体应用,以及传统的巨石应用并存。

在架构转型过程中,正确和常态的路径一定是一步步走过来,而不是传统架构丢掉直接上微服务。>>>>DevOps和容器@轻量单体应用架构

在单体应用架构下,DevOps、容器帮助企业实现敏捷IT。首先,持续集成持续交付CI/CD,只要应用是相对轻量的,就能加快中间件应用。CI/CD其中重要的一点是变更发布管理。


数人云某客户上了容器的应用都是轻量化的,基于 Tomcat 和微服务的应用。当基于容器实现快速发布以后,企业发现,所有发布里有一半的发布失败是由于配置不正确引起的。所以,如果没有发布变更管理,发布失败的中间环节有方方面面的因素。

当基于容器实现快速发布之后,容器对环境的异构做了一层屏蔽,这时如果出现处理的问题就是配置管理的问题了,由于涉及不同的环境和应用,配置环境变成应用发布很容易出错的环节。>>>>DevOps和容器@微服务应用架构

数人云做了企业客户微服务落地状况的调研(微服务2017年度报告出炉:4大客户画像,15%传统企业已领跑),在报告中,有15%左右的企业引入了Spring Cloud、Dubbo。微服务在企业里首当其冲的是敏捷开发,因为微服务是一种切实的敏捷开发的方法。


敏捷开发在IT界已经推广多年,但很多时候敏捷开发推的都是方法论,比如Scrum。微服务是一套切实能够落地到IT人员、开发人员开发过程中的实践方法,这是微服务首当其冲的好处,很多企业的开发部门对微服务非常欢迎。不过,15%还是偏小的一个采用比例,微服务还不是企业客户主流的IT架构。

开发人员都比较欢迎微服务,因为能够提升开发效率,落地敏捷开发,但微服务的阻碍还是不小的,微服务对开发运维来说,带来的复杂度急剧上升。传统运维管理的服务器数量、应用数量有限。企业决定采用微服务本身就表明业务很复杂,单体应用做传统的瀑布式开发效率太低,微服务将应用拆分成较小的模块,因此微服务应用一旦上线,程序的数量呈现爆炸式增长。


例如,数人云某个传统企业的客户,目前部署了微服务相关的应用,基于Spring Cloud、Spring Boot,跑在几千个容器上,几千个容器如果通过传统运维方式去管理的话几乎是不可能的。这就是很多微服务无法落地的原因——很多企业客户缺乏相应的运维能力,没有相应的平台、工具、方式、方法管理微服务应用。
 
>>>>微服务落地的必要条件


微服务应用落地,首当其冲是配套工具链的完善。开发人员采用微服务的影响相对改变小一些。采用SpringCloud或者Dubbo、gRPC等,只是开发框架上的并更。其他开发流程如代码托管、代码审查、测试等并不涉及,所以开发流程相对简单。但微服务对运维功能的要求就会复杂,相应的快速配置能力、完备的监控能力、快速部署能力等对传统运维来说都是缺失的,容器能够补足这方面的能力,让运维部门具有DevOps的能力。

关于微服务的拆分,其实是业务部门需要真正解决的问题。微服务对组织上也有变更,将团队化整为零。通常每个单独的微服务程序都由7-10人的小团队来负责维护,这些都是微服务落地的必要条件。
 
对于数人云来说,直接能够给客户提供的帮助,首先是工具链方面,数人云产品层面具备丰富的微服务配套工具链,从监控、日志、调度、故障自动化修复等等都有完备的工具链。在落地方法上,数人云搭建了自己的生态圈,和很多合作伙伴合作,例如跟埃森哲公司在合作,帮助企业客户落地微服务,进行业务的梳理。
 
>>>>容器和微服务共生


容器技术补齐了微服务相关的工具链,对企业全面向云计算转型提供了很大帮助。应用架构是微服务分布式的,相应的运维也要有自动化、敏捷运维的能力。微服务跑在容器上才能发挥它最好的特性。容器是目前最流行的应用环境,基于容器的微服务部署和更新更快,更轻量,服务之间的调用、服务发现、负载均衡等更灵活。


不过,微服务不是万能的。简单的业务场景单体应用其实足够,微服务一定是应用在复杂的业务场景下,只有复杂的业务场景才有很大的维护成本、维护压力,微服务是用来降低复杂业务场景的维护成本。>>>>基于容器云的微服务运行时管理体系

一个完整的微服务管理体系,除了开发框架之外,对运维部门来说,运维微服务应用最基本的路由、负载均衡等功能,容器可以提供,不过容器提供的只是一部分跟微服务相关的能力和工具链。周围还有一大批需要配套的工具,比如配置管理、API网关、注册发现、应用监控等等。这里的监控不是容器CPU内存的监控,而是业务逻辑的监控,更准确一点是全链路跟踪的全链路监控。容器满足了微服务运行时管理的需求,不过周边许多权限、网关、配置等尚无余力满足。

>>>>统一配置中心是微服务体系的核心

统一配置管理,是微服务落地时很核心的点。要在平台工具上落地微服务首先要具备快速配置能力,因为客户采用微服务和容器平台以后,很快会发现50%以上的发布失败是因为配置没搞对,因此配置管理是微服务里首当其冲的问题。

因为每个企业客户都有开发环境、测试环境、生产环境等很多环境,同一个应用不同版本在不同环境下的配置不同。几何级数的配置项、配置元素的增长会导致配置管理的复杂度急剧上升,需要统一的配置中心进行管理。数人云在帮助企业客户落地微服务时,首先会做的是把配置搞定,没有灵活快速的配置管理能力,微服务运行不起来。
 
>>>>变更发布管理(灰度发布 v.s. 蓝绿部署)

在发布管理方面,数人云帮助企业落地的发布管理主要是蓝绿部署,因为很多企业的应用本身不支持灰度发布。蓝绿部署也是切切实实的快速发布,发布用变更窗口的方式来实现。

例如,周五晚上12点起进行发布变更,12点就要停服务中心。蓝绿部署可以显著地缩短服务不可用的变更窗口。怎么做呢?客户在线上有两个版本,蓝版本和绿版本。现在负载均衡器将流量指向对外提供服务的绿版本,蓝版本作为备用的方案。同时,新程序往蓝版本上部署推送,更新时只需要把流量切换到蓝版本。发布流程最后简化为只需要进行流量的切换。流量可以快速切换,中间的窗口期只有短短几分钟,如果流量切换过来一切正常发布即完成,如果流量切换过来发现问题,可以再将流量切回去。这样开发人员、运维人员不必当场熬夜去修复,极大地减轻了发布的压力。

传统发布方式下,每次变更窗口有好几个应用排队发布,一个应用发布完成后才可以发布下一个应用,一旦中间某一个应用发布失败现场修复的压力非常大,短短的发布窗口需要几个小时内完成抢修,非常不可控,团队经常需要晚上熬夜排队。而结果往往等了半天,前面的应用没发布成功,后面的还得继续排队等。

3、金融行业之践行渐进

数人云在金融、能源、制造、快消、政企等行业的基础上,继续深耕强监管、强安全,高复杂度的金融行业。以某商业银行为例,数人云帮助落地了大规模微服务容器平台。该商业银行近年来互联网业务发展迅猛,原有系统架构无法支撑其未来规划。2016年6月开始全面实施应用微服务化,已实现蓝绿发布。


首先,营销系统全部是轻量化的应用,基于Spring Boot、Tomcat、SpringCloud等,跑在容器平台上。该银行对外营销频次非常高,通过线上微信公众号、手机APP、线上门户、合作伙伴等渠道,每月对外营销达上百场。

每次营销活动或多或少都对IT系统有变更,哪怕是配置变更,因此每次营销活动对IT系统都是一次不小的挑战。发布的时候仅仅靠容器是不够的,需要实现模板的批量发布。每次发布看起来只是一个个的容器程序,实则不然,其实是一组组一批批的容器,只有帮客户做到批量的应用发布,才能显著提升发布效率。

蓝绿部署方面,该银行密集的线上营销中,每一天会有一个重点营销活动,那么营销活动的流量如何分到特别的人群、区域?在后台应用的上千个实例中,并不是每一个实例都分配同等的流量,要通过流量分发,做线上流量控制。数人云借鉴Google做灰度发布的方式为客户提供图形化的流量控制,这和微服务实施后的限流分流是息息相关的。

另外,该银行客户的数据流量非常大,对日志收集带来非常大的的压力。数人云建议客户将应用程序的日志全部交给Kafka采集,Kafka可以做到很大数据流量的分布式消息应用。

分布式数据传输分布式消息应用很难保证每一个消息都可靠地传递。Kafka有两种模式:一种保证消息传递至少一次,但也可能多次,对很大的日志量来说偶尔丢一两条可以忽略不计。Kafka的并发量很大,可能带来偶尔很小的数据量丢失,也可能带来日志的乱序,这在分布式系统下都是可以容忍的,“鱼和熊掌不可兼得”。

关于快速建立支撑微服务体系,数人云有几点总结:
 
1.开发框架不能用重量级的应用体系,要么是轻量化单体架构的Tomcat等,要么采用Spring Cloud等微服务架构。

2.要有微服务平台,具备快速配置管理能力、部署能力、监控能力、应用管理能力等配套管理能力。很多企业的痛点是,开发人员快速学习微服务开发技术,基于Spring Cloud做业务系统后,业务系统无法上线,因为运维部门缺乏配套的工具、平台支撑微服务线上运行管理。

3.DevOps融合,平台管理需要把链条全打通,实现快速发布、快速上线、自动修复等。容器经过几年的普及企业已经相对了解,但容器本身是纯技术平台,基于容器、DevOps的落地还有很长的路要走。>>>>数人云微服务On PaaS 产品体系


数人云现在的重点是微服务、轻量单体应用。以前数人云帮企业客户落地重应用的容器平台,但后来发现价值不大,反而对企业来说,除了维护重的应用外还需要维护容器,容器平台并不能实现自动化运维。经过几年的实践和摸索,数人云跟企业客户达成的共识是,传统应用不经过改造无法上到云PaaS平台。

 轻量架构下的应用如何基于PaaS平台支撑?以敏捷开发为例,企业客户通常选择 Spring Cloud、gRPC 等主流的开发框架,然后在微服务工具链层面配置监控、报警、部署、快速发布等方方面面的能力,最下面承载的则是容器平台。


数人云现在还可以帮助客户落地服务网格化技术。它能够进行异构架构的兼容,gRPC就是服务网格的一部分,Google推的 Istio,Linkerd的Kubernetes 都支持 gRPC,gRPC成为通讯协议的一部分。基于通讯协议相应周边的管理,在服务网格这一层可以做灰度发布、A/B测试、流量控制、高级熔断、加密、白/黑名单机制、权限访问控制等等。


服务网格被称作下一代的微服务,因为用了服务网格以后,所有微服务管理的诉求都自动化地满足了。80%-90%的应用管理需求都在服务网格里自动涵盖。这对开发人员来讲,微服务开发的门槛急剧降低,不需要考虑未来应用上线时流量控制、灰度发布等等,只需要考虑业务。数人云微服务On PaaS 目的就是帮助企业客户降低微服务架构、上云转型的门槛。


 Q&A
 
Q1:感觉对DevOps的理解不太到位,能不能具体地讲一下?A1:DevOps准确来讲,现在业内还没有统一的认识。互联网公司的DevOps目前是比较统一的,比如Goolge,但是互联网公司的DevOps,我个人理解没办法在企业直接落地。




在Google,程序员不止要负责应用的开发,还要负责相应的测试,单元测试、集成测试等等。另外,应用的部署、发布、上线也是开发人员自己做。所以互联网公司讲DevOps,更多讲的是开发运维的融合。我之前在Google时,不仅要做代码开发,也要把测试的代码全写出来。

Google有一个理念,开发人员每写一行业务代码,测试代码要写十行。然后,开发人员利用各种发布平台定期发布,比如每周做发布,在Google 运维的人员叫“SRE”。SRE部门准备好各种平台,开发人员可以用这些平台做发布、监控、日志管理等工作。

Google目前有三万名左右的IT人员,其中SRE的运维人员只有一千多,比例很低。所以在Google运维人员不可能帮每一个开发人员或者业务部门做上线。像传统IT开发人员提工单给运维,在Google是不可能的。Google这种做法,它让开发做更多的事情,运维人员很少,只是负责维护平台。所以,Google一千多人管理着几百万台服务器,平均每人管两千台。


但传统企业目前不是这样,传统企业开发和运维之间壁垒比较大。数人云帮助客户落地DevOps 时,基于的理念是,不要破坏现有开发的流程。DevOps应该是开发和运维深度融合才能做到的。讲DevOps,首先要讲理念、组织的变革,但是要想把文化变革、组织变革打破要很长时间。

从落地的角度,DevOps更多落地在运维部门,很具象的工作就是,帮助运维部门去实现DevOps的能力,比如快速部署、快速上线,应用的快速配置,自动化管理能力、故障的自动化处理等等。把以前的运维工作尽可能的自动化,提高效率,这是狭义的DevOps理念,也是我们现在接触到的。数人云不会帮客户落地像互联网公司那样的DevOps,开发做很多事情,运维可做的很少,并不是这样的。

Q2:微服务适合复杂的场景,那么一个简单的促销是不是适合?微服务有多“微”呢?微服务和ESB 服务相比,有什么差别?A2:第一个促销场景,促销场景本身有些条件,促销很重要一点就是必须特别频繁,促销内容在平台要发生变化。比如,今天的促销内容和明天的不太一样,或者这周的促销和下周的不太一样,业务平台需要频繁变更,这时候微服务是适合的。

因为微服务是一种敏捷开发的落地实践方法,只要业务频繁变更,对开发的要求就必须敏捷开发,快速实现。所以,只要业务场景在不停地快速变化,促销又是互联网线上的方式,肯定是适合的。

关于复杂性,如果业务逻辑简单,逻辑变化少,并不适合微服务。比如数人云和很多银行客户合作,银行核心系统很复杂,但是银行系统并不是需求频繁变化的场景。很多银行在做“瘦核心系统”,就是银行核心系统的功能越来越单一,越来越瘦,并不是把复杂的周边的业务也放到银行核心系统里。银行核心系统虽然复杂,但业务不会频繁变化,也不一定要上到微服务场景下。复杂的业务系统,业务需求又不停变化,这种场景适合微服务。

第二个问题是和ESB 比,服务网格和 ESB 有很多相像的地方。ESB有业务逻辑串起来,很多不同的业务系统都上到ESB,互相的权限通过ESB打通。从功能角度讲,ESB和服务网格之间很相像,不同点在于ESB是传统架构下的,并没有考虑频繁迭代、流量集中爆发等问题。


但是微服务情况下,整个之间的互相请求、依赖、通讯等等都会进行统一的管理,这种情况下也很像ESB把不同业务之间的流量进行统一管理,但是服务网格更看重的是面向大规模的控制,那流量突发怎么做限流,或者突然故障怎么做熔断等等。最本质的问题是类似的,但是具体的问题表象和需求不同。

Q3:在实际部署过程中,PaaS平台在底层资源的调用一定要用分布式云架构,传统主机是否可以?两者在最后效果上有没有什么异同?A3:数人云当初两种情况都有,有些场景比如业务量比较大,企业客户为了减少复杂度,容器PaaS平台直接落地到物理服务器上。还有客户为了方便管理,把PaaS落地到IaaS上,两种情况都有。

这其中的考虑是,首先业务量大如果再引入虚拟化这一层会引来额外的复杂度,此时用物理服务器更好。其次,客户有很大规模的物理服务器,直接在上面部署PaaS,在物理服务器上去调用。


第三种,资源动态的调整或资源频繁调配,这个场景很常见,需要IaaS。比如银行客户,内部业务系统分不同的域,不同域的业务复杂性随时间变化经常会发生变化,需要不停地做资源动态的调整。如果用物理机太麻烦,企业客户会选择下面有一层IaaS来做。

基于PaaS也能做一部分的资源动态调配,但是调配维度不同。数人云帮客户落地PaaS时会做资源的整合。从划分的维度,PaaS平台是按照应用程序来划分,IaaS的资源划分是按照业务系统。

Q4:微服务重新开发,最佳的开发框架或者实践有什么可以分享的?第二,旧有的系统改造到微服务这块有没有什么经验?第三,DevOps以前也有很多像敏捷开发的方法论,它们之间有没有什么关系?A4:首先第一个问题,微服务的开发框架。企业客户在做选择时都希望降低风险,选最主流的框架,现在看最主流的开发框架就是Spring cloud,这也是业界的自然选择结果。其他语言也都有些微服务开发,但是用的人少一些。如果是Java应用,目前比较好的选择是Spring Cloud,也有很多客户用了Dubbo,其他架构都是偏小众的架构,主要还是看客户自己的需求。

第二个问题,传统业务要转到微服务架构上,一定要循序渐进。比如Java应用,首先Java中间件的应用,先脱掉,不要再基于这么重的Java中间件。目前相对流行的是Spring Boot这套逻辑。

有了轻量的单体化应用之后(基于Tomcat),往后走基于微服务的框架,上到Spring Boot,再上到Spring Cloud,这是比较平滑的方式。Spring Boot 在很企业客户中用的非常多,是很方便的一套单体开发架构。

企业客户目前的现状是老的应用很多,不会一次就改造完,传统的应用可以先选择一部分容易转的转到轻量单体架构上,然后再转到微服务框架上。目前企业客户是轻量的单体架构、微服务架构,以及大量传统的架构应用并存。老的架构应用目前上不到PaaS平台,只有轻量的单体化加微服务应用才能上到PaaS平台。

现在业内的共识是,微服务、容器、DevOps这三者是密不可分的。微服务更多是针对开发人员,是一种真正落地的云开发方法。很多企业客户也讲敏捷开发,派团队成员学习敏捷开发的方法论,但是敏捷开发仍然无法在企业当中落地。

这是因为,只学会了方法,但没办法落地到具体的编程,即开发环节上去,自然没办法做到敏捷开发。很多开发者回来写的程序依然是J2EE。J2EE 编程的理念和方法并不是敏捷开发的,是偏向于瀑布式的。

微服务是具体的开发环节上的敏捷开发方法,开发能力化整为零,每个团队做简单、具象、单一的逻辑。微服务首先是一个具像的敏捷开发方法,实践方法。

微服务在落地时,比如程序运行时,复杂度很高,因为不是一个程序,是一批程序一起运行,对运维的管理就比较复杂,这时候可以利用容器实现微服务应用的自动化管理。微服务一般都会上到容器,因为微服务应用不再是单体的部署方式,不再是部署到Java中间件上。基于微服务架构,几百个进程进来,用容器的方式实现快速部署动态调度,微服务部署到容器上,实现基础的轻量化运维。


轻量化运维,快速部署、自动化调度,逐步往DevOps方向走。DevOps更多强调自动化的运维能力,提高运维的效率,快速部署,出了问题自动化修复。需要用到工具和平台,这就是数人云现在帮客户去做的。


把微服务业务在运行时缺失的管理方式方法、工具平台,工具链补齐。首先是配置管理能力、完备的监控能力等等,普及之后运维人员就有能力来管微服务应用。这其实是DevOps里面最狭义的,让运维的能力变得轻量。


如果要真正实现DevOps,就像目前一些互联网公司做到的,开发和运维真正的深度融合在一起。企业目前的运维一般不具有编程能力,所以真正的DevOps还需要很长时间去落地。

数人云可否用于devops?

回复

prometheus 回复了问题 • 4 人关注 • 4 个回复 • 1204 次浏览 • 2015-11-18 18:20 • 来自相关话题

显示出现错位怎么办?

回复

dataman 回复了问题 • 2 人关注 • 1 个回复 • 919 次浏览 • 2015-11-18 15:30 • 来自相关话题

复杂性排第5,当红炸子鸡K8S对用户来说最大的槽点是啥?

dataman 发表了文章 • 0 个评论 • 87 次浏览 • 2018-03-29 10:44 • 来自相关话题

导读:

在使用或部署Kubernetes时,人们面临着非常多的问题。虽然Kubernetes所面临的一些挑战是独一无二的,但更多挑战都是典型的使用大量技术所带来的成长中的痛苦。最近CNCF主导了一项有关“Kubernetes生态系统状况”的一项调研,对于当红炸子鸡Kubernetes来说,哪些方面的挑战是最突出的?小数还另外翻译了K8S环境中4种最可能的威胁模型。

1

“Kubernetes生态系统状况”阐述了在选择容器编排解决方案时不同标准的重要性,以及阻碍Kubernetes采用的主要因素。与安全性或资源优化等标准相比,扩展性成为编排解决方案的基本要求。其中最大的挑战是,使用Kubernetes经常需要改变IT组织的几个部分的角色或职责。


CNCF最近的调查询问到人们在使用或部署容器时面临的挑战。在我们对数据的独立分析中,我们将答案发布在“Kubernetes Deployment & Security Patterns”一文中,并将焦点集中于使用Kubernetes管理容器的组织。这提供了一种方法来说明Kubernetes用户所面临的问题。
 


安全、存储、网络是最重要的挑战

研究结果表明,在对Kubernetes的普遍批评中,复杂性仅仅是排在第五位的挑战。领先的是与基础设施相关的挑战。在Kubernetes用户中,有46%的人提到了安全问题,网络和存储排在第二和第三位。

KubeCon +CloudNativeCon会议召集了采用者和技术专家,进一步推进云原生计算的教育和发展。供应商中立的技术有该领域专家和关键维护者的支持,比如Kubernetes, Prometheus, gRPC,Envoy,OpenTracing等等。

Twistlock利用先进的智能,机器学习功能以及自动策略创建和执行功能,保护当今应用程序免受未来的威胁。作为第一个端到端的容器安全解决方案,Twistlock是专门为交付现代安全性而构建的。

Alcide提供网络安全平台,专为由多个编排系统运营的容器、虚拟机和裸金属数据中心组合而设计。Alcide通过简化和自动控制为DevOps,安全和工程团队授权,以管理和保护不断发展的数据中心和混合云。

23%的人表示,基于负载的扩展部署是一个挑战。这意味着许多需求得到满足Kubernetes实际上是在帮助扩展它应该做的事情。在列表的底部,10%的问题得到了供应商的支持。很少有人抱怨Kubernetes支持供应商的原因之一是,许多部署并不依赖于供应商的分销。展望未来,提供高质量服务的可能性很大,因为CNCF最近推出了Kubernetes认证服务供应商计划,确保服务提供商达到一定的能力。








超过40%的人认为安全、网络和存储是与容器相关的挑战。



偏大型的组织有更多的挑战

和其他研究一样,我们发现较大的组织更倾向于将许多问题列为他们所关心的挑战。例如,1000名或更多员工的组织中,有55%的人认为安全是一个挑战,而不到100名员工的组织中只有39%的人这么认为。这种情况下,与可靠性等其他类别一样,大型企业的需求与小企业不同。


在其他领域,例如网络,与仅使用容器数量相比,IT基础设施(带宽和站点数量)的规模和广度可能会给Kubernetes带来更多独特的挑战。事实上,在拥有6个或6个以上集群的组织中,以网络作为挑战的比例从42%上升到53%。


一些挑战不符合上述模式。对于存储,一种解释是技术“问题”不是基于可扩展性的。在监管方面,中型企业更有可能面临挑战。正如我们之前在文章中提到的,对容器运营的监控,小企业通常不需要创建正式的监控流程,而大型企业则有资源来创建更健壮的、自定义的监视系统。被困在中间的是那些拥有100到999名员工的企业。







图1.8:在拥有1000名或更多员工的组织中,安全与网络更大可能被列为与容器相关的挑战。
 


本地部署 VS 云部署

影响组织与容器相关的挑战的另一个因素是,它们是否只将容器部署到公有云或在本地服务器上。在只使用本地服务器的容器中,存储是最常见的挑战。这是因为这些企业需要管理自己的存储基础设施,甚至可能由一支独立的IT团队来处理。








图1.9:54%仅供本地使用的容器用户面临存储挑战,而只有34%的公有云组织面临存储挑战。


对于只在公有云上使用容器的组织来说,监控和日志记录常常被认为是一个挑战。尽管云供应商应该支持可扩展性,但只有使用本地服务器才能使用容器的组织很难说扩展部署是一项挑战。


CNCF的调查还询问了几种类型的云原生基础设施和工具,其中一些是专门针对与Kubernetes合作的。本系列的下一篇文章将讨论Kubernetes用户用来解决他们面临的挑战的最常用工具。



2

4种Kubernetes威胁模型

在Kubernetes环境中,通常有四种类型的威胁,不管部署模型是什么(有一些边界情况例外):


1.旨在危害Kubernetes控制的外部攻击:所有连接系统均存在此威胁。在Kubernetes集群环境中,这代表攻击者获得对系统的访问权限,或者损害某些会影响系统安全的控制。

2.受影响的容器或节点:如果Kubernetes控制的环境中存在恶意容器或集群内的恶意节点,那么对其他节点或集群有什么影响?你能否在节点和集群内有效地包含“爆炸半径”?

3.妥协的凭证:当Kubernetes管理员的凭据被泄露时会发生什么情况?这对集群有多大影响?

4.滥用合法权限:当系统配置错误,缺乏控制或操作不严密时,可能会发生这种情况。

这些不同的威胁可能会导致大量妥协和不受欢迎的情况,包括特权提升,敏感数据泄露,运营折中或违反合规政策。

KubeCon + CloudNativeCon会议聚集了采用者和技术专家,进一步推动云原生计算的教育和发展。供应商中立的特色领域由领域专家和关键维护者的支持,如Kubernetes,Prometheus, gRPC,Envoy,OpenTracing等等。


引起相当多关注的攻击场景之一是“爆炸半径”——受损容器对同一节点上的其他容器会造成多大的损害,或者受损的节点会对集群的其余部分造成多大的损害? 对于Kubernetes部署的所有安全考虑都是基于这些威胁模型以及最小化“爆炸半径”的需要。
 


外部攻击

在Kubernetes环境中,外部可访问的组件将受到外部攻击。这些组件可以包括API服务器、kubelet和etcd。

为了减轻外部攻击的威胁,确保只有必要的Kubernetes服务被公开。始终执行身份验证并为任何公开的服务配置正确的网络安全策略。
 


妥协的容器

最终,Kubernetes管理在容器中运行的工作负载。如果一个容器被破坏,问题是容器是否可以升级权限来控制其他容器或集群。

Kubernetes的隔离机制,比如命名空间或网络分割,以及一些内置的os级控制,调节容器可以访问的内容,可以帮助限制受影响的容器的影响。另一个控制用户应该注意的是限制能够以特权模式运行的容器数量的能力——如果一个特权容器被破坏,它将会比普通的容器造成更多的伤害。


妥协的凭证

当合法的用户凭证被破坏时,系统中可能有恶意用户。因此,正确地规范和限制用户对集群资源的访问并密切监视用户操作是非常重要的。

为了减少恶意用户的影响,需要强制执行最小权限访问、基于角色的访问控制或其他细粒度访问控制。
 


滥用特权

如果系统配置不正确,可能导致滥用用户权限。例如,如果网络策略不限制pods或命名空间之间访问,用户可能能够读取其他命名空间的通信流,而这些命名空间最初不应访问。

防止滥用特权的主要防御措施是适当强化。确保所有系统组件(如容器,pod,命名空间和kubelets)都得到了强化,以显著降低特权滥用的可能性。


另一个重要的防御是授权控制。Kubernetes支持插件架构,它允许包含复杂的授权逻辑。正确设计和实施授权;这是反对特权滥用最有效的武器之一。



原文链接:

1、The TopChallenges Kubernetes Users Face with Deployment

https://thenewstack.io/top-cha ... ment/

2、4 Threat Models for Kubernetes Deployment Security

https://www.tuicool.com/articles/AfI7RbQ 



相关阅读:


天啦噜!看国外大神如何用Docker+Jenkins&CI/CD打造微服务架构?

远离神乎其神,从Uber微服务看最佳实践如何炼成?
换个姿势学习Kubernetes运营,如何5个月在生产环境构建K8S?



添加小数微信:xiaoshu062

备注公司、姓名、职位

小数将拉您进入相应技术群 查看全部
导读:

在使用或部署Kubernetes时,人们面临着非常多的问题。虽然Kubernetes所面临的一些挑战是独一无二的,但更多挑战都是典型的使用大量技术所带来的成长中的痛苦。最近CNCF主导了一项有关“Kubernetes生态系统状况”的一项调研,对于当红炸子鸡Kubernetes来说,哪些方面的挑战是最突出的?小数还另外翻译了K8S环境中4种最可能的威胁模型。

1

“Kubernetes生态系统状况”阐述了在选择容器编排解决方案时不同标准的重要性,以及阻碍Kubernetes采用的主要因素。与安全性或资源优化等标准相比,扩展性成为编排解决方案的基本要求。其中最大的挑战是,使用Kubernetes经常需要改变IT组织的几个部分的角色或职责。


CNCF最近的调查询问到人们在使用或部署容器时面临的挑战。在我们对数据的独立分析中,我们将答案发布在“Kubernetes Deployment & Security Patterns”一文中,并将焦点集中于使用Kubernetes管理容器的组织。这提供了一种方法来说明Kubernetes用户所面临的问题。
 


安全、存储、网络是最重要的挑战

研究结果表明,在对Kubernetes的普遍批评中,复杂性仅仅是排在第五位的挑战。领先的是与基础设施相关的挑战。在Kubernetes用户中,有46%的人提到了安全问题,网络和存储排在第二和第三位。

KubeCon +CloudNativeCon会议召集了采用者和技术专家,进一步推进云原生计算的教育和发展。供应商中立的技术有该领域专家和关键维护者的支持,比如Kubernetes, Prometheus, gRPC,Envoy,OpenTracing等等。

Twistlock利用先进的智能,机器学习功能以及自动策略创建和执行功能,保护当今应用程序免受未来的威胁。作为第一个端到端的容器安全解决方案,Twistlock是专门为交付现代安全性而构建的。

Alcide提供网络安全平台,专为由多个编排系统运营的容器、虚拟机和裸金属数据中心组合而设计。Alcide通过简化和自动控制为DevOps,安全和工程团队授权,以管理和保护不断发展的数据中心和混合云。

23%的人表示,基于负载的扩展部署是一个挑战。这意味着许多需求得到满足Kubernetes实际上是在帮助扩展它应该做的事情。在列表的底部,10%的问题得到了供应商的支持。很少有人抱怨Kubernetes支持供应商的原因之一是,许多部署并不依赖于供应商的分销。展望未来,提供高质量服务的可能性很大,因为CNCF最近推出了Kubernetes认证服务供应商计划,确保服务提供商达到一定的能力。


微信图片_20180329103703.jpg



超过40%的人认为安全、网络和存储是与容器相关的挑战。



偏大型的组织有更多的挑战

和其他研究一样,我们发现较大的组织更倾向于将许多问题列为他们所关心的挑战。例如,1000名或更多员工的组织中,有55%的人认为安全是一个挑战,而不到100名员工的组织中只有39%的人这么认为。这种情况下,与可靠性等其他类别一样,大型企业的需求与小企业不同。


在其他领域,例如网络,与仅使用容器数量相比,IT基础设施(带宽和站点数量)的规模和广度可能会给Kubernetes带来更多独特的挑战。事实上,在拥有6个或6个以上集群的组织中,以网络作为挑战的比例从42%上升到53%。


一些挑战不符合上述模式。对于存储,一种解释是技术“问题”不是基于可扩展性的。在监管方面,中型企业更有可能面临挑战。正如我们之前在文章中提到的,对容器运营的监控,小企业通常不需要创建正式的监控流程,而大型企业则有资源来创建更健壮的、自定义的监视系统。被困在中间的是那些拥有100到999名员工的企业。

微信图片_20180329103205.jpg



图1.8:在拥有1000名或更多员工的组织中,安全与网络更大可能被列为与容器相关的挑战。
 


本地部署 VS 云部署

影响组织与容器相关的挑战的另一个因素是,它们是否只将容器部署到公有云或在本地服务器上。在只使用本地服务器的容器中,存储是最常见的挑战。这是因为这些企业需要管理自己的存储基础设施,甚至可能由一支独立的IT团队来处理。


微信图片_20180329103226.jpg



图1.9:54%仅供本地使用的容器用户面临存储挑战,而只有34%的公有云组织面临存储挑战。


对于只在公有云上使用容器的组织来说,监控和日志记录常常被认为是一个挑战。尽管云供应商应该支持可扩展性,但只有使用本地服务器才能使用容器的组织很难说扩展部署是一项挑战。


CNCF的调查还询问了几种类型的云原生基础设施和工具,其中一些是专门针对与Kubernetes合作的。本系列的下一篇文章将讨论Kubernetes用户用来解决他们面临的挑战的最常用工具。



2

4种Kubernetes威胁模型

在Kubernetes环境中,通常有四种类型的威胁,不管部署模型是什么(有一些边界情况例外):


1.旨在危害Kubernetes控制的外部攻击:所有连接系统均存在此威胁。在Kubernetes集群环境中,这代表攻击者获得对系统的访问权限,或者损害某些会影响系统安全的控制。

2.受影响的容器或节点:如果Kubernetes控制的环境中存在恶意容器或集群内的恶意节点,那么对其他节点或集群有什么影响?你能否在节点和集群内有效地包含“爆炸半径”?

3.妥协的凭证:当Kubernetes管理员的凭据被泄露时会发生什么情况?这对集群有多大影响?

4.滥用合法权限:当系统配置错误,缺乏控制或操作不严密时,可能会发生这种情况。

这些不同的威胁可能会导致大量妥协和不受欢迎的情况,包括特权提升,敏感数据泄露,运营折中或违反合规政策。

KubeCon + CloudNativeCon会议聚集了采用者和技术专家,进一步推动云原生计算的教育和发展。供应商中立的特色领域由领域专家和关键维护者的支持,如Kubernetes,Prometheus, gRPC,Envoy,OpenTracing等等。


引起相当多关注的攻击场景之一是“爆炸半径”——受损容器对同一节点上的其他容器会造成多大的损害,或者受损的节点会对集群的其余部分造成多大的损害? 对于Kubernetes部署的所有安全考虑都是基于这些威胁模型以及最小化“爆炸半径”的需要。
 


外部攻击

在Kubernetes环境中,外部可访问的组件将受到外部攻击。这些组件可以包括API服务器、kubelet和etcd。

为了减轻外部攻击的威胁,确保只有必要的Kubernetes服务被公开。始终执行身份验证并为任何公开的服务配置正确的网络安全策略。
 


妥协的容器

最终,Kubernetes管理在容器中运行的工作负载。如果一个容器被破坏,问题是容器是否可以升级权限来控制其他容器或集群。

Kubernetes的隔离机制,比如命名空间或网络分割,以及一些内置的os级控制,调节容器可以访问的内容,可以帮助限制受影响的容器的影响。另一个控制用户应该注意的是限制能够以特权模式运行的容器数量的能力——如果一个特权容器被破坏,它将会比普通的容器造成更多的伤害。


妥协的凭证

当合法的用户凭证被破坏时,系统中可能有恶意用户。因此,正确地规范和限制用户对集群资源的访问并密切监视用户操作是非常重要的。

为了减少恶意用户的影响,需要强制执行最小权限访问、基于角色的访问控制或其他细粒度访问控制。
 


滥用特权

如果系统配置不正确,可能导致滥用用户权限。例如,如果网络策略不限制pods或命名空间之间访问,用户可能能够读取其他命名空间的通信流,而这些命名空间最初不应访问。

防止滥用特权的主要防御措施是适当强化。确保所有系统组件(如容器,pod,命名空间和kubelets)都得到了强化,以显著降低特权滥用的可能性。


另一个重要的防御是授权控制。Kubernetes支持插件架构,它允许包含复杂的授权逻辑。正确设计和实施授权;这是反对特权滥用最有效的武器之一。



原文链接:

1、The TopChallenges Kubernetes Users Face with Deployment

https://thenewstack.io/top-cha ... ment/

2、4 Threat Models for Kubernetes Deployment Security

https://www.tuicool.com/articles/AfI7RbQ 



相关阅读:


天啦噜!看国外大神如何用Docker+Jenkins&CI/CD打造微服务架构?

远离神乎其神,从Uber微服务看最佳实践如何炼成?
换个姿势学习Kubernetes运营,如何5个月在生产环境构建K8S?



添加小数微信:xiaoshu062

备注公司、姓名、职位

小数将拉您进入相应技术群

换个姿势学习Kubernetes运营,如何5个月在生产环境构建K8S?

杨y 发表了文章 • 0 个评论 • 147 次浏览 • 2018-03-21 11:33 • 来自相关话题

在分布式系统上管理服务是运维团队面临的最困难的问题之一。在生产中突破新软件并学习如何可靠地运营是非常重要的。本文是一则实例,讲述为什么学习运营Kubernetes很重要,以及为什么很难。本文是关于Kubernetes bug导致的一小时中断故障的事后剖析。




为什么选择在Kubernetes之上构建?如何将Kubernetes集成到现有基础设施中?本文作者给出的方法是建立 (和改进) 对Kubernetes集群的可靠性的信任,以及构建在Kubernetes之上的抽象。

我们最近在Kubernetes之上构建了一个分布式的cron作业调度系统,这是一个令人兴奋的容器编排的新平台。Kubernetes现在非常流行,并且有许多令人兴奋的承诺:最令人兴奋的是,程序员不需要知道或关心他们的应用程序运行的是什么机器。

什么是Kubernetes?

Kubernetes是一个分布式系统,用于调度程序在集群中运行。你可以告诉Kubernetes运行一个程序的5个副本,它将在工作节点上动态调度它们。容器自动调度以增加利用率,节省资金,强大的deployment primitives允许逐步推出新的代码,安全上下文和网络策略允许企业以安全的方式运行多租户的工作负载。




Kubernetes有很多不同类型的调度能力。它可以调度长时间运行的HTTP服务、在集群中每台机器上运行的daemonsets、每小时运行的cron作业等等。

为什么是Kubernetes?

每个基础设施项目都是从业务需求开始的,我们的目标是提高现有分布式cron作业系统的可靠性和安全性。我们的要求是:




建立和运营一支小团队(只有2人在项目中全职工作)。

在20台机器上可靠地安排大约500个不同的cron作业。




我们决定在Kubernetes之上建立的几个原因:




希望构建一个现有的开源项目。

kubernetes包含一个分布式cron作业调度器,不必自己编写。

kubernetes是一个非常活跃的项目,经常接受捐赠。

kubernetes是用Go写的,很容易学。几乎所有Kubernetes的bug都是由团队中没有经验的程序员做的。




如果我们能够成功地运营Kubernetes,可以在未来的Kubernetes上构建,例如,目前正在开发基于kubernet的系统来训练机器学习模型。




我们以前使用Chronos作为cron作业调度系统,但它不再是满足可靠性要求,而且大部分都没有维护(在过去9个月中1次提交, 最后一次合并请求的时间是2016年3月))Chronos未维护的,我们认为不值得继续投资改善现有的集群。




如果你正考虑Kubernetes,请记住:不要仅仅因为其他公司在使用Kubernetes而使用它。建立一个可靠的集群需要花费大量的时间,使用它的业务案例并不是很突出。把你的时间用在聪明的方法上。

可靠性是什么意思?

说到运营服务,“可靠”这个词本身并没有什么意义。要讨论可靠性,首先需要建立一个SLO(服务级别目标)。




我们有三个主要目标:




99.99%的cron作业应该在预定运行时间的20分钟内开始运行。20分钟是一个很宽的窗口,但是我们采访了内部客户,没有人要求更高的精确度。

Jobs应该运行99.99%的时间(不被终止)。

向Kubernetes的迁移不会导致任何面向客户的事件。




这意味着:




Kubernetes API的短暂停机时间是可以接受的(如果停机10分钟,只要在5分钟内恢复即可)。

调度错误(cron作业运行完全丢失并且根本无法运行)是不可接受的。我们非常重视安排错误报告。

要谨慎对待pod evictions 和安全终止实例,以免作业过于频繁地终止。

需要一个好的迁移计划。

建立一个Kubernetes集群

我们建立第一个Kubernetes集群的基本方法是从零开始构建集群,而不是使用kubeadm或kops之类的工具。使用Puppet(常用的配置管理工具)调配了配置。从头开始构建很好,原因有两个:能够深入地集成Kubernetes在架构中,并且深入理解其内部。

 

我们希望将Kubernetes整合到现有的基础架构中。与现有系统无缝集成,以便进行日志记录,证书管理,加密,网络安全,监控,AWS实例管理,部署,数据库代理,内部DNS服务器,配置管理以及更多。整合所有这些系统有时需要一点创造力,但总体上比试图让kubeadm / kops成为我们想要的更容易。




在信任并了解如何操作这些现有系统后,我们希望继续在新的Kubernetes群集中使用。例如,安全证书管理是一个非常棘手的问题,已经有办法颁发和管理证书。通过适当的整合,我们避免了为Kubernetes创建新的CA。




准确了解设置的参数是如何影响Kubernetes设置的。例如,在配置用于身份验证的证书/CAs时,使用了超过12个参数。了解这些参数有助于在遇到身份验证问题时更容易调试设置。

对Kubernetes建立信心

在Kubernetes之初,团队中没有人使用过Kubernetes。如何从“没有人用过Kubernetes”到“我们有信心在生产中运行Kubernetes”?









战略0:与其他公司交谈




我们向其他公司询问了Kubernetes的经历。 他们都以不同的方式或在不同的环境中使用Kubernetes(运行HTTP服务,裸机,Google Kubernetes引擎等)。




在谈到Kubernetes这样庞大而复杂的系统时,重要的是认真思考自己的用例,做自己的实验,建立对自己环境的信心,并做出决定。 例如,你不该读这篇博客文章并得出结论:“Stripe正在成功使用Kubernetes,所以它也适用于我们!”

 

以下是我们在与几家运营Kubernetes集群的公司沟通后后学到的:




优先考虑企业etcd集群的可靠性(etcd是存储所有Kubernetes集群状态的地方)。

某些Kubernetes功能比其他功能更稳定,因此请小心Alpha功能。一些公司只有在稳定后才能使用稳定特性(例如,如果某个功能在1.8版本中保持稳定,则在使用它之前会等待1.9或1.10)。

考虑使用托管的Kubernetes系统,如GKE / AKS / EKS。从头开始建立高可用性Kubernetes系统是一项巨大的工作。 AWS在此项目中没有托管的Kubernetes服务,所以这不适合我们。

注意由覆盖网络/软件定义网络引入的额外网络延迟。




策略1:阅读代码。




我们计划很大程度上依赖于Kubernetes的一个组件,即cronjob控制器。这个组件当时处于alpha阶段,这让我们有点担心。我们在一个测试集群中尝试了它,但是如何判断它在生产中是否适合我们呢?




值得庆幸的是,所有cronjob控制器的核心功能只有400行Go。通过源代码快速读取显示:




cron作业控制器是一个无状态的服务(与其他Kubernetes组件一样,除了etcd)。

每10秒钟,这个控制器调用syncAll函数:go wait.Until(jm.syncAll,10 * time.Second,stopCh)

syncAll函数从Kubernetes API中获取所有cron作业,遍历该列表,确定下一步应该运行哪些作业,然后启动这些作业。




核心逻辑似乎相对容易理解。更重要的是,如果在这个控制器中有一个bug,它可能是我们可以修复的东西。




策略2:做负载测试




在开始认真构建集群之前,我们做了一些负载测试。我们并不担心Kubernetes集群能够处理多少节点(计划部署大约20个节点),但是确实想让某些Kubernetes能够处理我们希望运行的那么多的cron作业(大约每分钟50个)。




在一个3节点集群中运行了测试,创建了1000个cron作业,每个任务每分钟运行一次。这些工作中的每一个都简单地运行bash -c 'echo hello world'。我们选择简单的作业,是因为希望测试集群的调度和编排能力,而不是集群的总计算能力。









测试集群无法处理每分钟1000个cron作业。每个节点每秒最多只能启动一个pod,而集群能够每分钟运行200个cron作业。由于我们只希望每分钟运行大约50个cron作业,所以我们认为这些限制不是阻碍因素。




策略3:优先构建和测试高可用性etcd集群。




在设置Kubernetes时,最重要的事情之一就是运行etcd。Etcd是Kubernetes集群的核心,它是存储集群中所有数据的地方。除了etcd之外,其他一切都是无状态的。如果etcd没有运行,不能对Kubernetes集群进行任何更改(尽管现有的服务将继续运行!)




这张图显示了etcd是Kubernetes集群的核心——API服务器是etcd前面的无状态REST/认证端点,然后其他组件通过API服务器与etcd对话。 在运行时,有两个要点需要牢记:




设置复制,这样集群不会死如果你失去了一个节点。我们现在有三个etcd副本。

确保足够的I / O带宽。我们的etcd版本有一个问题,一个具有高fsync延迟的节点可能触发连续的leader elections,导致集群无法使用。通过确保所有节点的I/O带宽都比etcd的写入数量多,从而弥补了这一点。




 


设置复制不是一个设置-忘记操作。我们仔细地测试后发现可能会丢失一个etcd节点,并且集群优雅地恢复了。




以下是为建立etcd集群所做的一些工作:




设置复制

监控etcd服务是可用的

写一些简单的工具,以便轻松创建新的etcd节点,并加入到集群当中

编写一些简单的工具,以便我们可以轻松创建新的etcd节点并将它们加入到群集中

补丁etcd的高集成,这样我们可以在生产环境中运行超过1个 etcd集群

测试从一个etcd备份中恢复

测试可以在不停机情况下重建整个集群




很高兴很早就做了这个测试。某个周五的早晨,在我们的生产集群中,一个etcd节点停止了对ping的响应。我们得到了警报,终止了节点,带来了一个新的节点,加入到集群中,同时Kubernetes继续运行。




策略4:逐步将工作迁移到Kubernetes




我们的目标之一是将工作迁移到Kubernetes而不造成任何中断。成功进行生产迁移的秘诀不是避免犯错(这是不可能的),而是设计你的迁移以减少错误的影响。




我们很幸运有多种职位可以迁移到新集群,所以可以迁移一些低影响的工作岗位,接受一两次失败。




在开始迁移之前,构建了易于使用的工具,如果有必要,可以在不到五分钟的时间内在旧系统和新系统之间来回移动作业。这种简单的工具减少了错误的影响 - 如果迁移一个没有计划的依赖的工作,没有什么大不了的!可以将其移回原处,解决问题,然后再试。




以下是我们采用的整体迁移策略:




根据他们的重要程度大致排序

将一些重复的工作迁移到Kubernetes。如果发现新的情况,快速回滚,修复问题,然后重试。




策略5:调查 Kubernetes bug 并修复它们




我们在项目开始时制定了一个规则:如果Kubernetes做了一些意外的事情,必须调查,找出原因,并提出补救措施。




调查每个问题都很耗时,但很重要。如果只是简单地将Kubernetes的”古怪行为”看作是复杂的分布式系统的功能,我们担心,因为它们会被调用导致产生bug集群。




在使用了这种方法之后,我们发现并且修复了Kubernetes的几个bug。




以下是测试中发现的一些问题:




名称超过52个字符的Cronjob无法安排作业。

Pods有时会永远停留在挂起状态。

调度程序会每3个小时崩溃一次。

Flannel的hostgw后端没有替换过时的路由表项




修复这些bug让我们对Kubernetes项目的使用感觉好得多——不仅它运行得比较好,而且也接受补丁并有一个良好的PR审查过程。




Kubernetes有bug,像所有的软件一样。特别是,我们非常频繁地使用调度器(cron作业总是在创建新的pods),而调度器使用缓存有时会导致bug、回退和崩溃。缓存是困难的!但是代码库是可接近的,我们已经能够处理遇到的bug。




值得一提的是,Kubernetes的pod驱逐逻辑。Kubernetes有一个称为节点控制器的组件,它负责将pod驱逐出去,如果节点没有响应,则将它们移到另一个节点。allnodes会暂时无响应(例如,由于网络或配置问题),在这种情况下,Kubernetes可以终止集群中的所有pod。




如果运行的是大型Kubernetes集群,请仔细阅读节点控制器文档,仔细地考虑设置,并进行广泛测试。每次通过创建网络分区测试对这些设置的配置更改(例如,pod-驱逐超时),就会发生令人惊讶的事情。最好在测试中发现这些意外,而不是在生产中发现。




策略6:有意引起Kubernetes集群问题




之前讨论过在Stripe中进行游戏日练习。这个想法是要想出你最终会在生产中发生的情况,然后在生产中故意造成这些情况,从而确保能够处理它们。




在集群上进行了几次练习之后,经常发现诸如监视或配置错误等问题。很高兴在早期发现这些问题,而不是六个月后突然发现。




以下是运行的一些比赛日练习:




终止Kubernetes API服务器

终止所有Kubernetes API服务器并将其恢复(这非常有效)

终止etcd节点

从API服务器中关闭Kubernetes集群中的工作节点(以便它们无法通信)。这导致节点上的所有pods被迁移到其他节点。




很高兴看到Kubernetes如何应对我们投入的大量干扰。 Kubernetes的设计是为了适应错误 - 它有存储所有状态的etcd集群,一个只是该数据库的REST接口的API服务器,以及一个协调所有集群管理的无状态控制器集合。




如果任何Kubernetes核心组件(API服务器,控制器管理器或调度程序)被中断或重新启动,一旦它们出现,它们将从etcd读取相关状态并继续无缝运行。这是我们希望的事情之一,而且在实践中实际运作良好。




以下是测试中发现的一些问题:




“没有得到paged,来修复监控。“

“当销毁API服务器实例并将其恢复后,需要人工干预。最好解决这个问题。“

“有时执行etcd故障转移时,API服务器会启动超时请求,直至重新启动。”




在运行这些测试后,针对发现的问题开发了补救措施:改进了监控,发现了固定配置问题,并提交了Kubernetes bug。

使cron作业易于使用

简单地探讨一下我们是如何使基于kubernetes的系统易于使用的。




最初的目标是设计一个运行cron作业的系统,团队有信心运营和维护。一旦建立了对Kubernetes的信心,就需要工程师们轻松地配置和增加新的cron作业。我们开发了一个简单的YAML配置格式,这样用户就不需要了解Kubernetes的内部结构来使用这个系统。这是我们开发的格式:




name: job-name-here

kubernetes:

  schedule: '15 */2 * * *'

command:

- ruby

- "/path/to/script.rb"

resources:

  requests:

    cpu: 0.1

    memory: 128M

  limits:

    memory: 1024M




没有做什么特别的事情——我们编写了一个简单的程序,将这种格式转换为Kubernetes cron作业配置,将其应用于kubectl。




我们还编写了一个测试套件,以确保作业名称不会太长,并且所有名称都是惟一的。我们目前不使用cgroups来强化对大多数作业的内存限制,但计划将来推出。




我们的简单格式易于使用,而且由于自动生成了来自相同格式的Chronos和Kubernetes cron作业定义,所以在两个系统之间迁移作业非常简单。这是使我们的增量迁移工作良好的关键部分。将作业迁移到Kubernetes时,可以用一个简单的三行配置更改,在不到十分钟的时间内将其移回。

监控Kubernetes

监测Kubernetes集群的内部状态非常令人愉悦。我们使用kube-state-metrics软件包进行监测,并使用一个名为veneurl - Prometheus的小型Go程序来获取Prometheus的度量标准,将它们作为statsd指标发布到我们的监控系统中。









例如,以下是过去一小时内集群中未决Pod的数量图表。Pending意味着等待分配一个工作节点来运行。可以看到上午11点的数字峰值,很多cron作业在每小时的第0分钟运行。

还有一个监视器,用于检查有没有任何Pod在Pending状态中卡住 - 每个Pod在5分钟内开始在worker节点上运行,否则会收到警报。

Kubernetes未来计划

设置Kubernetes,到顺畅地运行生产代码并将所有cron作业迁移到新集群,花了五个月的时间,三位工程师全职工作。我们投资学习Kubernetes的一个重要原因是希望能够在Stripe中更广泛地使用Kubernetes。




以下是适用于运行Kubernetes(或任何其他复杂分布式系统)的原则:




为企业的Kubernetes项目,以及所有基础设施项目,定义清晰的商业原因。了解业务案例和用户的需求使项目变得更加容易。

积极削减范围。避免使用许多Kubernetes的基本特性来简化集群。这让我们可以更快速地发送消息,例如,由于pod-to-pod联网不是我们项目的必需条件,可以关闭节点之间的所有网络连接,并将Kubernetes的网络安全性推迟。




花大量时间学习如何正确地运营Kubernetes集群。仔细测试边界情况。分布式系统非常复杂,有很多潜在的问题。以前面的例子为例:如果节点控制器由于配置与API服务器失去联系,那么它可以杀死集群中的所有pods。学习Kubernetes在每次配置更改后的表现如何,需要时间和精心的关注。




通过专注于这些原则,我们已经有信心在生产中使用Kubernetes。我们将继续开发Kubernetes的使用,例如,我们正在关注AWS EKS的发布。我们正在完成另一个系统的工作,训练机器学习模型,并且正在探索将一些HTTP服务迁移到Kubernetes。随着我们继续在生产中运行Kubernetes时,我们计划对开源项目做出贡献。

 







原文作者:Julia Evans

原文链接:

Learning to operate Kubernetes reliably

https://stripe.com/blog/operating-kubernetes
  查看全部
在分布式系统上管理服务是运维团队面临的最困难的问题之一。在生产中突破新软件并学习如何可靠地运营是非常重要的。本文是一则实例,讲述为什么学习运营Kubernetes很重要,以及为什么很难。本文是关于Kubernetes bug导致的一小时中断故障的事后剖析。




为什么选择在Kubernetes之上构建?如何将Kubernetes集成到现有基础设施中?本文作者给出的方法是建立 (和改进) 对Kubernetes集群的可靠性的信任,以及构建在Kubernetes之上的抽象。

我们最近在Kubernetes之上构建了一个分布式的cron作业调度系统,这是一个令人兴奋的容器编排的新平台。Kubernetes现在非常流行,并且有许多令人兴奋的承诺:最令人兴奋的是,程序员不需要知道或关心他们的应用程序运行的是什么机器。

什么是Kubernetes?

Kubernetes是一个分布式系统,用于调度程序在集群中运行。你可以告诉Kubernetes运行一个程序的5个副本,它将在工作节点上动态调度它们。容器自动调度以增加利用率,节省资金,强大的deployment primitives允许逐步推出新的代码,安全上下文和网络策略允许企业以安全的方式运行多租户的工作负载。




Kubernetes有很多不同类型的调度能力。它可以调度长时间运行的HTTP服务、在集群中每台机器上运行的daemonsets、每小时运行的cron作业等等。

为什么是Kubernetes?

每个基础设施项目都是从业务需求开始的,我们的目标是提高现有分布式cron作业系统的可靠性和安全性。我们的要求是:




建立和运营一支小团队(只有2人在项目中全职工作)。

在20台机器上可靠地安排大约500个不同的cron作业。




我们决定在Kubernetes之上建立的几个原因:




希望构建一个现有的开源项目。

kubernetes包含一个分布式cron作业调度器,不必自己编写。

kubernetes是一个非常活跃的项目,经常接受捐赠。

kubernetes是用Go写的,很容易学。几乎所有Kubernetes的bug都是由团队中没有经验的程序员做的。




如果我们能够成功地运营Kubernetes,可以在未来的Kubernetes上构建,例如,目前正在开发基于kubernet的系统来训练机器学习模型。




我们以前使用Chronos作为cron作业调度系统,但它不再是满足可靠性要求,而且大部分都没有维护(在过去9个月中1次提交, 最后一次合并请求的时间是2016年3月))Chronos未维护的,我们认为不值得继续投资改善现有的集群。




如果你正考虑Kubernetes,请记住:不要仅仅因为其他公司在使用Kubernetes而使用它。建立一个可靠的集群需要花费大量的时间,使用它的业务案例并不是很突出。把你的时间用在聪明的方法上。

可靠性是什么意思?

说到运营服务,“可靠”这个词本身并没有什么意义。要讨论可靠性,首先需要建立一个SLO(服务级别目标)。




我们有三个主要目标:




99.99%的cron作业应该在预定运行时间的20分钟内开始运行。20分钟是一个很宽的窗口,但是我们采访了内部客户,没有人要求更高的精确度。

Jobs应该运行99.99%的时间(不被终止)。

向Kubernetes的迁移不会导致任何面向客户的事件。




这意味着:




Kubernetes API的短暂停机时间是可以接受的(如果停机10分钟,只要在5分钟内恢复即可)。

调度错误(cron作业运行完全丢失并且根本无法运行)是不可接受的。我们非常重视安排错误报告。

要谨慎对待pod evictions 和安全终止实例,以免作业过于频繁地终止。

需要一个好的迁移计划。

建立一个Kubernetes集群

我们建立第一个Kubernetes集群的基本方法是从零开始构建集群,而不是使用kubeadm或kops之类的工具。使用Puppet(常用的配置管理工具)调配了配置。从头开始构建很好,原因有两个:能够深入地集成Kubernetes在架构中,并且深入理解其内部。

 

我们希望将Kubernetes整合到现有的基础架构中。与现有系统无缝集成,以便进行日志记录,证书管理,加密,网络安全,监控,AWS实例管理,部署,数据库代理,内部DNS服务器,配置管理以及更多。整合所有这些系统有时需要一点创造力,但总体上比试图让kubeadm / kops成为我们想要的更容易。




在信任并了解如何操作这些现有系统后,我们希望继续在新的Kubernetes群集中使用。例如,安全证书管理是一个非常棘手的问题,已经有办法颁发和管理证书。通过适当的整合,我们避免了为Kubernetes创建新的CA。




准确了解设置的参数是如何影响Kubernetes设置的。例如,在配置用于身份验证的证书/CAs时,使用了超过12个参数。了解这些参数有助于在遇到身份验证问题时更容易调试设置。

对Kubernetes建立信心

在Kubernetes之初,团队中没有人使用过Kubernetes。如何从“没有人用过Kubernetes”到“我们有信心在生产中运行Kubernetes”?


112.jpg




战略0:与其他公司交谈




我们向其他公司询问了Kubernetes的经历。 他们都以不同的方式或在不同的环境中使用Kubernetes(运行HTTP服务,裸机,Google Kubernetes引擎等)。




在谈到Kubernetes这样庞大而复杂的系统时,重要的是认真思考自己的用例,做自己的实验,建立对自己环境的信心,并做出决定。 例如,你不该读这篇博客文章并得出结论:“Stripe正在成功使用Kubernetes,所以它也适用于我们!”

 

以下是我们在与几家运营Kubernetes集群的公司沟通后后学到的:




优先考虑企业etcd集群的可靠性(etcd是存储所有Kubernetes集群状态的地方)。

某些Kubernetes功能比其他功能更稳定,因此请小心Alpha功能。一些公司只有在稳定后才能使用稳定特性(例如,如果某个功能在1.8版本中保持稳定,则在使用它之前会等待1.9或1.10)。

考虑使用托管的Kubernetes系统,如GKE / AKS / EKS。从头开始建立高可用性Kubernetes系统是一项巨大的工作。 AWS在此项目中没有托管的Kubernetes服务,所以这不适合我们。

注意由覆盖网络/软件定义网络引入的额外网络延迟。




策略1:阅读代码。




我们计划很大程度上依赖于Kubernetes的一个组件,即cronjob控制器。这个组件当时处于alpha阶段,这让我们有点担心。我们在一个测试集群中尝试了它,但是如何判断它在生产中是否适合我们呢?




值得庆幸的是,所有cronjob控制器的核心功能只有400行Go。通过源代码快速读取显示:




cron作业控制器是一个无状态的服务(与其他Kubernetes组件一样,除了etcd)。

每10秒钟,这个控制器调用syncAll函数:go wait.Until(jm.syncAll,10 * time.Second,stopCh)

syncAll函数从Kubernetes API中获取所有cron作业,遍历该列表,确定下一步应该运行哪些作业,然后启动这些作业。




核心逻辑似乎相对容易理解。更重要的是,如果在这个控制器中有一个bug,它可能是我们可以修复的东西。




策略2:做负载测试




在开始认真构建集群之前,我们做了一些负载测试。我们并不担心Kubernetes集群能够处理多少节点(计划部署大约20个节点),但是确实想让某些Kubernetes能够处理我们希望运行的那么多的cron作业(大约每分钟50个)。




在一个3节点集群中运行了测试,创建了1000个cron作业,每个任务每分钟运行一次。这些工作中的每一个都简单地运行bash -c 'echo hello world'。我们选择简单的作业,是因为希望测试集群的调度和编排能力,而不是集群的总计算能力。



113.jpg



测试集群无法处理每分钟1000个cron作业。每个节点每秒最多只能启动一个pod,而集群能够每分钟运行200个cron作业。由于我们只希望每分钟运行大约50个cron作业,所以我们认为这些限制不是阻碍因素。




策略3:优先构建和测试高可用性etcd集群。




在设置Kubernetes时,最重要的事情之一就是运行etcd。Etcd是Kubernetes集群的核心,它是存储集群中所有数据的地方。除了etcd之外,其他一切都是无状态的。如果etcd没有运行,不能对Kubernetes集群进行任何更改(尽管现有的服务将继续运行!)




这张图显示了etcd是Kubernetes集群的核心——API服务器是etcd前面的无状态REST/认证端点,然后其他组件通过API服务器与etcd对话。 在运行时,有两个要点需要牢记:




设置复制,这样集群不会死如果你失去了一个节点。我们现在有三个etcd副本。

确保足够的I / O带宽。我们的etcd版本有一个问题,一个具有高fsync延迟的节点可能触发连续的leader elections,导致集群无法使用。通过确保所有节点的I/O带宽都比etcd的写入数量多,从而弥补了这一点。




 


设置复制不是一个设置-忘记操作。我们仔细地测试后发现可能会丢失一个etcd节点,并且集群优雅地恢复了。




以下是为建立etcd集群所做的一些工作:




设置复制

监控etcd服务是可用的

写一些简单的工具,以便轻松创建新的etcd节点,并加入到集群当中

编写一些简单的工具,以便我们可以轻松创建新的etcd节点并将它们加入到群集中

补丁etcd的高集成,这样我们可以在生产环境中运行超过1个 etcd集群

测试从一个etcd备份中恢复

测试可以在不停机情况下重建整个集群




很高兴很早就做了这个测试。某个周五的早晨,在我们的生产集群中,一个etcd节点停止了对ping的响应。我们得到了警报,终止了节点,带来了一个新的节点,加入到集群中,同时Kubernetes继续运行。




策略4:逐步将工作迁移到Kubernetes




我们的目标之一是将工作迁移到Kubernetes而不造成任何中断。成功进行生产迁移的秘诀不是避免犯错(这是不可能的),而是设计你的迁移以减少错误的影响。




我们很幸运有多种职位可以迁移到新集群,所以可以迁移一些低影响的工作岗位,接受一两次失败。




在开始迁移之前,构建了易于使用的工具,如果有必要,可以在不到五分钟的时间内在旧系统和新系统之间来回移动作业。这种简单的工具减少了错误的影响 - 如果迁移一个没有计划的依赖的工作,没有什么大不了的!可以将其移回原处,解决问题,然后再试。




以下是我们采用的整体迁移策略:




根据他们的重要程度大致排序

将一些重复的工作迁移到Kubernetes。如果发现新的情况,快速回滚,修复问题,然后重试。




策略5:调查 Kubernetes bug 并修复它们




我们在项目开始时制定了一个规则:如果Kubernetes做了一些意外的事情,必须调查,找出原因,并提出补救措施。




调查每个问题都很耗时,但很重要。如果只是简单地将Kubernetes的”古怪行为”看作是复杂的分布式系统的功能,我们担心,因为它们会被调用导致产生bug集群。




在使用了这种方法之后,我们发现并且修复了Kubernetes的几个bug。




以下是测试中发现的一些问题:




名称超过52个字符的Cronjob无法安排作业。

Pods有时会永远停留在挂起状态。

调度程序会每3个小时崩溃一次。

Flannel的hostgw后端没有替换过时的路由表项




修复这些bug让我们对Kubernetes项目的使用感觉好得多——不仅它运行得比较好,而且也接受补丁并有一个良好的PR审查过程。




Kubernetes有bug,像所有的软件一样。特别是,我们非常频繁地使用调度器(cron作业总是在创建新的pods),而调度器使用缓存有时会导致bug、回退和崩溃。缓存是困难的!但是代码库是可接近的,我们已经能够处理遇到的bug。




值得一提的是,Kubernetes的pod驱逐逻辑。Kubernetes有一个称为节点控制器的组件,它负责将pod驱逐出去,如果节点没有响应,则将它们移到另一个节点。allnodes会暂时无响应(例如,由于网络或配置问题),在这种情况下,Kubernetes可以终止集群中的所有pod。




如果运行的是大型Kubernetes集群,请仔细阅读节点控制器文档,仔细地考虑设置,并进行广泛测试。每次通过创建网络分区测试对这些设置的配置更改(例如,pod-驱逐超时),就会发生令人惊讶的事情。最好在测试中发现这些意外,而不是在生产中发现。




策略6:有意引起Kubernetes集群问题




之前讨论过在Stripe中进行游戏日练习。这个想法是要想出你最终会在生产中发生的情况,然后在生产中故意造成这些情况,从而确保能够处理它们。




在集群上进行了几次练习之后,经常发现诸如监视或配置错误等问题。很高兴在早期发现这些问题,而不是六个月后突然发现。




以下是运行的一些比赛日练习:




终止Kubernetes API服务器

终止所有Kubernetes API服务器并将其恢复(这非常有效)

终止etcd节点

从API服务器中关闭Kubernetes集群中的工作节点(以便它们无法通信)。这导致节点上的所有pods被迁移到其他节点。




很高兴看到Kubernetes如何应对我们投入的大量干扰。 Kubernetes的设计是为了适应错误 - 它有存储所有状态的etcd集群,一个只是该数据库的REST接口的API服务器,以及一个协调所有集群管理的无状态控制器集合。




如果任何Kubernetes核心组件(API服务器,控制器管理器或调度程序)被中断或重新启动,一旦它们出现,它们将从etcd读取相关状态并继续无缝运行。这是我们希望的事情之一,而且在实践中实际运作良好。




以下是测试中发现的一些问题:




“没有得到paged,来修复监控。“

“当销毁API服务器实例并将其恢复后,需要人工干预。最好解决这个问题。“

“有时执行etcd故障转移时,API服务器会启动超时请求,直至重新启动。”




在运行这些测试后,针对发现的问题开发了补救措施:改进了监控,发现了固定配置问题,并提交了Kubernetes bug。

使cron作业易于使用

简单地探讨一下我们是如何使基于kubernetes的系统易于使用的。




最初的目标是设计一个运行cron作业的系统,团队有信心运营和维护。一旦建立了对Kubernetes的信心,就需要工程师们轻松地配置和增加新的cron作业。我们开发了一个简单的YAML配置格式,这样用户就不需要了解Kubernetes的内部结构来使用这个系统。这是我们开发的格式:




name: job-name-here

kubernetes:

  schedule: '15 */2 * * *'

command:

- ruby

- "/path/to/script.rb"

resources:

  requests:

    cpu: 0.1

    memory: 128M

  limits:

    memory: 1024M




没有做什么特别的事情——我们编写了一个简单的程序,将这种格式转换为Kubernetes cron作业配置,将其应用于kubectl。




我们还编写了一个测试套件,以确保作业名称不会太长,并且所有名称都是惟一的。我们目前不使用cgroups来强化对大多数作业的内存限制,但计划将来推出。




我们的简单格式易于使用,而且由于自动生成了来自相同格式的Chronos和Kubernetes cron作业定义,所以在两个系统之间迁移作业非常简单。这是使我们的增量迁移工作良好的关键部分。将作业迁移到Kubernetes时,可以用一个简单的三行配置更改,在不到十分钟的时间内将其移回。

监控Kubernetes

监测Kubernetes集群的内部状态非常令人愉悦。我们使用kube-state-metrics软件包进行监测,并使用一个名为veneurl - Prometheus的小型Go程序来获取Prometheus的度量标准,将它们作为statsd指标发布到我们的监控系统中。



111.jpg



例如,以下是过去一小时内集群中未决Pod的数量图表。Pending意味着等待分配一个工作节点来运行。可以看到上午11点的数字峰值,很多cron作业在每小时的第0分钟运行。

还有一个监视器,用于检查有没有任何Pod在Pending状态中卡住 - 每个Pod在5分钟内开始在worker节点上运行,否则会收到警报。

Kubernetes未来计划

设置Kubernetes,到顺畅地运行生产代码并将所有cron作业迁移到新集群,花了五个月的时间,三位工程师全职工作。我们投资学习Kubernetes的一个重要原因是希望能够在Stripe中更广泛地使用Kubernetes。




以下是适用于运行Kubernetes(或任何其他复杂分布式系统)的原则:




为企业的Kubernetes项目,以及所有基础设施项目,定义清晰的商业原因。了解业务案例和用户的需求使项目变得更加容易。

积极削减范围。避免使用许多Kubernetes的基本特性来简化集群。这让我们可以更快速地发送消息,例如,由于pod-to-pod联网不是我们项目的必需条件,可以关闭节点之间的所有网络连接,并将Kubernetes的网络安全性推迟。




花大量时间学习如何正确地运营Kubernetes集群。仔细测试边界情况。分布式系统非常复杂,有很多潜在的问题。以前面的例子为例:如果节点控制器由于配置与API服务器失去联系,那么它可以杀死集群中的所有pods。学习Kubernetes在每次配置更改后的表现如何,需要时间和精心的关注。




通过专注于这些原则,我们已经有信心在生产中使用Kubernetes。我们将继续开发Kubernetes的使用,例如,我们正在关注AWS EKS的发布。我们正在完成另一个系统的工作,训练机器学习模型,并且正在探索将一些HTTP服务迁移到Kubernetes。随着我们继续在生产中运行Kubernetes时,我们计划对开源项目做出贡献。

 







原文作者:Julia Evans

原文链接:

Learning to operate Kubernetes reliably

https://stripe.com/blog/operating-kubernetes
 

kubernetes落地 |不捧不踩,国外公司向Kubernetes迁移实践

dataman 发表了文章 • 0 个评论 • 141 次浏览 • 2018-03-16 10:50 • 来自相关话题

导读:

Kubernetes一骑绝尘开挂来,那么企业应该开始向Kubernetes迁移吗?什么情况下真正的接受它?一些技术前沿公司先行一步的实践恐怕最有说服力和参考价值。本文即是一则很好的参考。



1

Kubernetes如今风靡一时,它是庞大的云原生运动中的一部分。所有主要的云提供商都将其作为部署云原生应用的解决方案。就在几个星期前,AWS重新推出了EKS(Amazon Elastic Container Service for Kubernetes),这是一个完全托管的Kubernetes集群。

这是一个巨大的进步,因为AWS是最大的公有云提供商,大多数Kubernetes的部署都在AWS上。官方kops工具用于部署和管理Kubernetes集群,目前已准备就绪。随着Kubernetes越来越受欢迎,企业正在努力接受它,希望借助Kubernetes解决许多常见问题。

那么,企业真的应该开始向Kubernetes迁移吗?什么情况下真正的接受它?本篇文章,将试图回答这个问题,并给出迁移到K8S和云原生的一些挑战和建议。


The Problem 问题

今年早些时候,我们开始对Sematext云进行容器化部署,这看起来似乎非常简单。企业所要做的就是将所有应用程序打包,为其资源(如部署、服务等)创建一些Kubernetes配置,然后即可进行操作。然而,并不是那么容易。

问题主要在于,用于管理发布过程的所有东西都不适合云原生模式。企业的应用程序不是云原生的,就无法使用CI/CD部署管道,运行状况检查或使用监视工具来记录日志、指标和警报。企业的应用程序可能非常静态且部署复杂。这种复杂性不会随着迁移到Kubernetes而消失,只会让事情变得更糟。云原生意味着将操作系统从应用程序中解耦出来,这就是容器正在做的事情。

在软件行业的演进中,首先是瀑布流,然后是敏捷,如今有了DevOps管理。这是一个非常重要的难题,这里没有规则可循。每个团队使用最适合他们的方式,如果你想坚持现有的常规,没什么问题,请照常做。只需要确保你的日常工作适用于云原生,这意味着需要做出一些改变。要切换整个团队来接受DevOps原则并不容易,需要一些时间做准备。


The Solution解决方案

这不是一个需要盲目跟随的解决方案。它给出一个想法,并解释可能遇到的过程和问题。

第一步,首先对所有未使用的组件进行清理。软件在开发了几年之后,会变得非常复杂,因为总有更重要的事情要做——新功能、新产品修复等等。

其次,对Kubernetes readiness and liveness probes进行健康检查,这点不难。花费时间管理配置才是最难的部分。我的建议是利用配置地图(config maps)和secrets ,远离环境变量。你可以使用其中一部分,但不要仅使用环境变量来进行整个配置管理。应用程序应该充分发挥Kubernetes的潜力。


Kubernetes应用程序正在使用服务进行通信。在Kubernetes中有不同类型的服务,并将它们视为负载均衡器。定义的服务名称是你的端点http://service_name:port。如果正在使用有状态应用程序,会希望使用 headless services,能够访问特定的Pod。Kubernetes的服务也在某种程度上解决了服务发现问题。如果你已经使用了Consul之类的服务发现,恭喜你!可以坚持下去,并将它部署在Kubernetes上。

从Kubernetes的角度来看,在无状态应用程序下,应用程序容易扩展。使用部署作为资源,这种类型的服务还可以管理简单的升级-滚动更新。当然,你的应用程序需要在没有任何问题的情况下处理扩展,并且需要一些代码更改来实现它。

主要问题在于有状态的应用程序,如数据库。Kubernetes为这类应用程序提供了一种StatefulSet资源,但不知道在添加新节点或出现故障时,特定的应用程序应该如何反应,这是运维人员在管理时通常要做的事情。不过,编写Kubernetes的操作符不是多么困难的事情。

简而言之,操作符是Kubernetes custom resource definition(即CRD),可以自行编写或使用现有的。我们使用的是 Elastic search Operator,很乐意为这个项目做出贡献。我已经提出了一些pull requests。

你可能已经开始把所有的片段连接起来了。有两种计算资源:请求,它在一个节点上指定最小数量的空闲资源,用于Kubernetes调度程序运行特定的Pod,以及限制,这是Pod可以使用的最大计算资源数量。这一点非常重要,特别是对于Java应用程序来说。对于Java应用,还需要根据heap memory需求调整限制。根据对Docker CPU和内存限制的了解,我的建议是使用Java version 8u131或更新版本。

给你的应用标上标签——当需要监控容器和应用程序时,这真的很有用,而元数据信息通常就是如何通过选择器连接不同的资源。例如,部署和服务。

当开始编写Kubernetes配置文件时,你会觉得很好,并且认为维护不是什么大问题。但是,在尝试实现部署管道时,你会发现使用一堆配置文件是一个非常糟糕的想法。这时Helm可以拯救,Helm是一个用于打包Kubernetes应用程序的工具,我强烈推荐使用它来部署管道。诸如支持多种环境、依赖关系、版本控制、回滚和不同hooks(考虑DB迁移)就足够描述Helm的所有优点了。坏消息是你需要学习另一种工具,但它很容易学,值得你花时间。

企业不需要多个集群来搭建不同的环境,只需使用不同的Kubernetes命名空间。例如,为了创建一个新环境,只需要创建一个单独的命名空间,完成测试后把它删除,节省了大量时间和资金。但是,不要忘记安全。Kubectl就像集群中的根用户。让每个人都访问kubectl可能不是一个好主意。有时,创建一个全新的集群比管理RBAC更好,而这可能非常复杂。尽管如此,还是强烈建议使用RBAC。


那么,企业将如何为容器镜像、Helm packages等提供版本呢?这取决于自己的选择。最常用的方法是提交ID给镜像打标签,然后release tag。此时,需要将Docker镜像存储到某个地方,即私人或公共注册中心。我的建议是使用DockerHub。这或许是最具成本效益的。如果解决了所有问题,那么需要创建一个部署管道。企业可以使用Jenkins来部署所有内容,并将其作为DevOps的主要工具之一。

The Conclusion 结论

最近,人们关注的焦点是云原生,而并非仅仅Kubernetes本身。Kubernetes只是一个工具,我们向Kubernetes迁移Sematext云和Sematext的工作正在进行中。需要把它看作一个过程,这不是一项一次性的工作,也从来没有完全完成。

迁移到云原生和Kubernetes的过程,既困难又费时,但对企业的公司文化和软件非常有益。扩展不再是问题,基础设施只是代码和软件问题。拥抱Kubernetes,但要准备好面对挑战。




2

Kubernetes可以在任一环境下部署

在开始进行云原生开发和部署时,来看看Kubernetes所扮演的角色,以及如何从编排中获得更多的功能。

容器提供了将应用程序及其依赖与操作系统分离的能力。通过与虚拟机镜像不同的方式打包操作系统,容器节省了大量系统资源:计算、内存和磁盘空间。容器也更快地下载、更新、部署和迭代。因此,在技术领域,容器已经引起了一场小型革命,并被谷歌、微软和亚马逊等公司采用。


容器的小型革命也带来了激烈的竞争,以满足编排和管理的需要。Kubernetes,谷歌的开源容器编排工具,已经成为领先的解决方案(替代方案有有亚马逊ECS和DockerSwarm等),归功于三个主要原因:


云原生设计:支持部署和运行下一代应用程序。

开源特性:快速创新,避免厂商锁定。

可移植性:在任何地方部署,无论是在云中、on-premise、还是虚拟机中等等。

下图显示了Kubernetes在云原生部署中所扮演的角色:






Kubernetes容器编排

Kubernetes可以部署和管理容器应用,其中包括NGINX、MySQL、Apache和其他许多应用程序。它可以为容器提供布局、缩放、复制、监视和其他功能。


一旦选择了容器编排平台,下一步就是部署Kubernetes。如前所述,Kubernetes是一个可移植的解决方案。因为Kubernetes使用相同的镜像和配置,它在笔记本电脑上、云里、或在本地所使用的方式完全相同。

Kubernetes-as-a-Service

这些解决方案提供了在各种基础设施中部署Kubernetes的能力:公有云或内部部署。为Kubernetes集群选择这种方法的优势包括:

1.通过KaaS供应商进行升级、监控和支持。

2.轻松扩展混合云或多云环境。

3.多集群的单一窗格视图。

4.高可用性,多主Kubernetes集群,根据工作负载自动扩缩。

5.通用企业集成,如SSO /独立命名空间; 以及通过Helm图表部署应用程序的能力。

6.集群联合,提供跨多个云或数据中心的真正无缝混合环境。






Kubernetes-as-a-Service(Kubernetes即服务)


Kubernetes即服务的例子包括Platform9和StackPoint.io。


托管的基础设施

谷歌云平台和Microsoft Azure分别通过谷歌容器引擎(GKE)和Azure容器服务(ACS)提供Kubernetes。容器放置在公有云中可以快速启动,但是现在企业的数据将留存在网络防火墙之外。


谷歌GKE领导着其他公有云供应商。谷歌通过一个名为Borg的集群管理器,广泛地将容器用于内部项目,并拥有超过十年的开发经验(来源: TheNextPlatform)。相比之下,微软的ACS是一个更年轻的产品,Kubernetes支持仅在2017年2月才被引入。


然而,ACS提供了灵活性:用户可以选择容器编排平台(Kubernetes, Docker Swarm, DCOS),以及选择除了Linux以外,在Windows中部署容器化的应用程序的选项。如下所示,GKE和ACS完全基于公有云,Kubernetes服务和基础设施由托管提供商部署和管理。






Hosted Infrastructure for Kubernetes



本地部署

Minikube是在本地部署Kubernetes最流行的方式。它支持各种虚拟化管理程序,包括VirtualBox、VMware Fusion、KVM、xhyve和OSs,包括OSX、Windows和Linux。下面的插图进一步描述了Minikube的部署:


部署与Minikube

如上所示,用户使用Minikube CLI和Kubernetes的原生CLI Kubectl与笔记本电脑部署进行交互。 Minikube CLI可用于在虚拟机上启动,停止,删除,获取状态以及执行其他操作。一旦Minikube虚拟机启动,Kubectl CLI将在Kubernetes群集上执行操作。 以下命令启动现有的Minikube虚拟机并创建NGINX Kubernetes部署:#  minikube start
# cat > example.yaml<<EOF
apiVersion: apps/v1beta1
kind: Deployment
metadata:
 name: nginx-deployment
spec:
 replicas: 1
 template:
   metadata:
     labels:
       app: nginx
   spec:
     containers:
     - name: nginx
       image: nginx
       ports:
       - containerPort: 80
EOF
# kubectl create -f example.yaml(手动往下翻)


原文链接:

1、Embracing Kubernetes Successfully

https://sematext.com/blog/embr ... ully/

2、Deploy Kubernetes Anywhere

https://dzone.com/articles/dep ... where


推荐活动:

数人云联合ServiceComb、ServiceMesh社区举办的 Building Microservice Meetup系列活动第2站--3月31日,北京站开始报名啦!本期主题为《微服务,从架构到发布》依旧大咖汇集,点击最下方的“链接”快来报名~




相关阅读:

后Kubernetes时代,带你系统梳理K8S 12大关键特性

女神特辑 | 关于DevOps和职场,4位DevOps领域杰出女性都关注些啥?

有趣 | 马斯洛理论告诉你,Kubernetes可以满足微服务的这15大需求
  查看全部
导读:

Kubernetes一骑绝尘开挂来,那么企业应该开始向Kubernetes迁移吗?什么情况下真正的接受它?一些技术前沿公司先行一步的实践恐怕最有说服力和参考价值。本文即是一则很好的参考。



1

Kubernetes如今风靡一时,它是庞大的云原生运动中的一部分。所有主要的云提供商都将其作为部署云原生应用的解决方案。就在几个星期前,AWS重新推出了EKS(Amazon Elastic Container Service for Kubernetes),这是一个完全托管的Kubernetes集群。

这是一个巨大的进步,因为AWS是最大的公有云提供商,大多数Kubernetes的部署都在AWS上。官方kops工具用于部署和管理Kubernetes集群,目前已准备就绪。随着Kubernetes越来越受欢迎,企业正在努力接受它,希望借助Kubernetes解决许多常见问题。

那么,企业真的应该开始向Kubernetes迁移吗?什么情况下真正的接受它?本篇文章,将试图回答这个问题,并给出迁移到K8S和云原生的一些挑战和建议。


The Problem 问题

今年早些时候,我们开始对Sematext云进行容器化部署,这看起来似乎非常简单。企业所要做的就是将所有应用程序打包,为其资源(如部署、服务等)创建一些Kubernetes配置,然后即可进行操作。然而,并不是那么容易。

问题主要在于,用于管理发布过程的所有东西都不适合云原生模式。企业的应用程序不是云原生的,就无法使用CI/CD部署管道,运行状况检查或使用监视工具来记录日志、指标和警报。企业的应用程序可能非常静态且部署复杂。这种复杂性不会随着迁移到Kubernetes而消失,只会让事情变得更糟。云原生意味着将操作系统从应用程序中解耦出来,这就是容器正在做的事情。

在软件行业的演进中,首先是瀑布流,然后是敏捷,如今有了DevOps管理。这是一个非常重要的难题,这里没有规则可循。每个团队使用最适合他们的方式,如果你想坚持现有的常规,没什么问题,请照常做。只需要确保你的日常工作适用于云原生,这意味着需要做出一些改变。要切换整个团队来接受DevOps原则并不容易,需要一些时间做准备。


The Solution解决方案

这不是一个需要盲目跟随的解决方案。它给出一个想法,并解释可能遇到的过程和问题。

第一步,首先对所有未使用的组件进行清理。软件在开发了几年之后,会变得非常复杂,因为总有更重要的事情要做——新功能、新产品修复等等。

其次,对Kubernetes readiness and liveness probes进行健康检查,这点不难。花费时间管理配置才是最难的部分。我的建议是利用配置地图(config maps)和secrets ,远离环境变量。你可以使用其中一部分,但不要仅使用环境变量来进行整个配置管理。应用程序应该充分发挥Kubernetes的潜力。


Kubernetes应用程序正在使用服务进行通信。在Kubernetes中有不同类型的服务,并将它们视为负载均衡器。定义的服务名称是你的端点http://service_name:port。如果正在使用有状态应用程序,会希望使用 headless services,能够访问特定的Pod。Kubernetes的服务也在某种程度上解决了服务发现问题。如果你已经使用了Consul之类的服务发现,恭喜你!可以坚持下去,并将它部署在Kubernetes上。

从Kubernetes的角度来看,在无状态应用程序下,应用程序容易扩展。使用部署作为资源,这种类型的服务还可以管理简单的升级-滚动更新。当然,你的应用程序需要在没有任何问题的情况下处理扩展,并且需要一些代码更改来实现它。

主要问题在于有状态的应用程序,如数据库。Kubernetes为这类应用程序提供了一种StatefulSet资源,但不知道在添加新节点或出现故障时,特定的应用程序应该如何反应,这是运维人员在管理时通常要做的事情。不过,编写Kubernetes的操作符不是多么困难的事情。

简而言之,操作符是Kubernetes custom resource definition(即CRD),可以自行编写或使用现有的。我们使用的是 Elastic search Operator,很乐意为这个项目做出贡献。我已经提出了一些pull requests。

你可能已经开始把所有的片段连接起来了。有两种计算资源:请求,它在一个节点上指定最小数量的空闲资源,用于Kubernetes调度程序运行特定的Pod,以及限制,这是Pod可以使用的最大计算资源数量。这一点非常重要,特别是对于Java应用程序来说。对于Java应用,还需要根据heap memory需求调整限制。根据对Docker CPU和内存限制的了解,我的建议是使用Java version 8u131或更新版本。

给你的应用标上标签——当需要监控容器和应用程序时,这真的很有用,而元数据信息通常就是如何通过选择器连接不同的资源。例如,部署和服务。

当开始编写Kubernetes配置文件时,你会觉得很好,并且认为维护不是什么大问题。但是,在尝试实现部署管道时,你会发现使用一堆配置文件是一个非常糟糕的想法。这时Helm可以拯救,Helm是一个用于打包Kubernetes应用程序的工具,我强烈推荐使用它来部署管道。诸如支持多种环境、依赖关系、版本控制、回滚和不同hooks(考虑DB迁移)就足够描述Helm的所有优点了。坏消息是你需要学习另一种工具,但它很容易学,值得你花时间。

企业不需要多个集群来搭建不同的环境,只需使用不同的Kubernetes命名空间。例如,为了创建一个新环境,只需要创建一个单独的命名空间,完成测试后把它删除,节省了大量时间和资金。但是,不要忘记安全。Kubectl就像集群中的根用户。让每个人都访问kubectl可能不是一个好主意。有时,创建一个全新的集群比管理RBAC更好,而这可能非常复杂。尽管如此,还是强烈建议使用RBAC。


那么,企业将如何为容器镜像、Helm packages等提供版本呢?这取决于自己的选择。最常用的方法是提交ID给镜像打标签,然后release tag。此时,需要将Docker镜像存储到某个地方,即私人或公共注册中心。我的建议是使用DockerHub。这或许是最具成本效益的。如果解决了所有问题,那么需要创建一个部署管道。企业可以使用Jenkins来部署所有内容,并将其作为DevOps的主要工具之一。

The Conclusion 结论

最近,人们关注的焦点是云原生,而并非仅仅Kubernetes本身。Kubernetes只是一个工具,我们向Kubernetes迁移Sematext云和Sematext的工作正在进行中。需要把它看作一个过程,这不是一项一次性的工作,也从来没有完全完成。

迁移到云原生和Kubernetes的过程,既困难又费时,但对企业的公司文化和软件非常有益。扩展不再是问题,基础设施只是代码和软件问题。拥抱Kubernetes,但要准备好面对挑战。




2

Kubernetes可以在任一环境下部署

在开始进行云原生开发和部署时,来看看Kubernetes所扮演的角色,以及如何从编排中获得更多的功能。

容器提供了将应用程序及其依赖与操作系统分离的能力。通过与虚拟机镜像不同的方式打包操作系统,容器节省了大量系统资源:计算、内存和磁盘空间。容器也更快地下载、更新、部署和迭代。因此,在技术领域,容器已经引起了一场小型革命,并被谷歌、微软和亚马逊等公司采用。


容器的小型革命也带来了激烈的竞争,以满足编排和管理的需要。Kubernetes,谷歌的开源容器编排工具,已经成为领先的解决方案(替代方案有有亚马逊ECS和DockerSwarm等),归功于三个主要原因:


云原生设计:支持部署和运行下一代应用程序。

开源特性:快速创新,避免厂商锁定。

可移植性:在任何地方部署,无论是在云中、on-premise、还是虚拟机中等等。

下图显示了Kubernetes在云原生部署中所扮演的角色:

微信图片_20180316102623.jpg


Kubernetes容器编排

Kubernetes可以部署和管理容器应用,其中包括NGINX、MySQL、Apache和其他许多应用程序。它可以为容器提供布局、缩放、复制、监视和其他功能。


一旦选择了容器编排平台,下一步就是部署Kubernetes。如前所述,Kubernetes是一个可移植的解决方案。因为Kubernetes使用相同的镜像和配置,它在笔记本电脑上、云里、或在本地所使用的方式完全相同。

Kubernetes-as-a-Service

这些解决方案提供了在各种基础设施中部署Kubernetes的能力:公有云或内部部署。为Kubernetes集群选择这种方法的优势包括:

1.通过KaaS供应商进行升级、监控和支持。

2.轻松扩展混合云或多云环境。

3.多集群的单一窗格视图。

4.高可用性,多主Kubernetes集群,根据工作负载自动扩缩。

5.通用企业集成,如SSO /独立命名空间; 以及通过Helm图表部署应用程序的能力。

6.集群联合,提供跨多个云或数据中心的真正无缝混合环境。

微信图片_20180316102658.jpg


Kubernetes-as-a-Service(Kubernetes即服务)


Kubernetes即服务的例子包括Platform9和StackPoint.io。


托管的基础设施

谷歌云平台和Microsoft Azure分别通过谷歌容器引擎(GKE)和Azure容器服务(ACS)提供Kubernetes。容器放置在公有云中可以快速启动,但是现在企业的数据将留存在网络防火墙之外。


谷歌GKE领导着其他公有云供应商。谷歌通过一个名为Borg的集群管理器,广泛地将容器用于内部项目,并拥有超过十年的开发经验(来源: TheNextPlatform)。相比之下,微软的ACS是一个更年轻的产品,Kubernetes支持仅在2017年2月才被引入。


然而,ACS提供了灵活性:用户可以选择容器编排平台(Kubernetes, Docker Swarm, DCOS),以及选择除了Linux以外,在Windows中部署容器化的应用程序的选项。如下所示,GKE和ACS完全基于公有云,Kubernetes服务和基础设施由托管提供商部署和管理。

微信图片_20180316102938.jpg


Hosted Infrastructure for Kubernetes



本地部署

Minikube是在本地部署Kubernetes最流行的方式。它支持各种虚拟化管理程序,包括VirtualBox、VMware Fusion、KVM、xhyve和OSs,包括OSX、Windows和Linux。下面的插图进一步描述了Minikube的部署:


部署与Minikube

如上所示,用户使用Minikube CLI和Kubernetes的原生CLI Kubectl与笔记本电脑部署进行交互。 Minikube CLI可用于在虚拟机上启动,停止,删除,获取状态以及执行其他操作。一旦Minikube虚拟机启动,Kubectl CLI将在Kubernetes群集上执行操作。 以下命令启动现有的Minikube虚拟机并创建NGINX Kubernetes部署:#  minikube start
# cat > example.yaml<<EOF
apiVersion: apps/v1beta1
kind: Deployment
metadata:
 name: nginx-deployment
spec:
 replicas: 1
 template:
   metadata:
     labels:
       app: nginx
   spec:
     containers:
     - name: nginx
       image: nginx
       ports:
       - containerPort: 80
EOF
# kubectl create -f example.yaml(手动往下翻)


原文链接:

1、Embracing Kubernetes Successfully

https://sematext.com/blog/embr ... ully/

2、Deploy Kubernetes Anywhere

https://dzone.com/articles/dep ... where


推荐活动:

数人云联合ServiceComb、ServiceMesh社区举办的 Building Microservice Meetup系列活动第2站--3月31日,北京站开始报名啦!本期主题为《微服务,从架构到发布》依旧大咖汇集,点击最下方的“链接”快来报名~




相关阅读:

后Kubernetes时代,带你系统梳理K8S 12大关键特性

女神特辑 | 关于DevOps和职场,4位DevOps领域杰出女性都关注些啥?

有趣 | 马斯洛理论告诉你,Kubernetes可以满足微服务的这15大需求
 

【详解】以银行零售业务为例,一个案例说清楚可视化微服务架构

dataman 发表了文章 • 0 个评论 • 127 次浏览 • 2018-03-08 10:27 • 来自相关话题

Part 1: API设计和策略

软件系统的复杂性是一个很痛苦的问题,而且无法避免。Fred Brooks将复杂性描述为,软件系统解决业务问题所固有的本质复杂性,以及实施该解决方案所带来的偶发复杂性。

随着与采用“API优先”工程实践和微服务架构的组织进行更密切的合作,我发现这种描述越来越有用。首先,通过这种方式分离复杂性,它允许架构师和工程师专注于最小化系统的偶发复杂性。

与微服务相关的技术创新有很大帮助:容器,自动化工具和API管理平台。但我真正喜欢这种复杂性划分的原因是,它帮助我们认清一个事实:任何技术都不能降低系统的本质复杂性。

“开发软件产品的许多经典问题源于这种本质的复杂性,其非线性随着规模的增加而增加。” – 出自Fred Brooks著《No Silver Bullet—Essence & Accident in Software Engineering》

但是,我们能做的至少是理解和记录一个系统的本质复杂性。对于大多数技术人员来说,有效完成这一任务很重要,因为系统的本质复杂性不包括解决方案中使用的底层技术。

系统本质复杂性定义的本质要素是系统执行的任务和功能,以及执行所需的对象和交互。为了优化这种定义的认知负荷,将此定义表达为视觉模型也是很自然的。即使在可视化的情况下,软件架构师仍然努力保持模型中的元素不受技术限制,并且保持一致。

Eric Evans的领域驱动设计(Domain-Driven Design ,DDD)方法论突出的原因是,它提供了一种可视化定义软件系统本质复杂性的方法。特别是,显示域,子域,有界上下文及其相互关系的上下文映射,与我见过的以有效方式说明本质复杂性的任何方法都非常接近。 UML意在提供一种用于定义与技术无关的应用程序描述的手段,但它的许多模型自然偏向于面向对象的根源。事实上,如果你深入DDD工具箱,我认为你会遇到同样的偏见。

我在定义一个互连微服务系统时,使用了DDD上下文映射的派生。将在未来的文章中详细介绍这种方法。







示例上下文映射

为什么理解和记录软件系统的本质复杂性很重要,这与微服务有什么关系?随着微服务系统的发展和演变,其许多好处来自于服务本身的凝聚力。PhilCalçado在他的博客文章“微服务与分布式对象的第一定律(Microservices & the First Law of Distributed Objects)”中强调了这一需求。凝聚力是确定服务边界的产物,这是模拟系统本质复杂性的必要步骤。

有趣的是,与Brooks所描述的复杂性似乎是矛盾的,微服务系统的技术无关上下文映射在某种程度上与它的实现的拓扑结构是同构的,远远超过一整套单体应用的拓扑。这可能是一个巧合,也表明我们正在采用这种微服务架构方法。


Part 2:设计微服务系统

最近我一直在与许多大型组织合作,帮助他们理解并实现Web API和微服务体系结构的价值。在这项工作中,我看到这些组织一直在努力于,如何定义企业里微服务之间的最佳边界。这是一个已知的问题,但没有解决。虽然关于凝聚式服务(cohesive services)的价值和有界上下文已经写了很多,但如何实际识别这些内容似乎没有指导意义。

这个问题的一个原因是,试图确定服务边界的人是技术人员,他们天生就在寻找技术解决方案,但是定义凝聚力和能力一致性的服务边界(cohesive, capability-aligned service boundaries)却需要领域专家。从根本上说,这应该是一种建模练习,它独立于任何技术的覆盖。然而,即使那些有意识地采用了技术无关建模方法的组织,也一直在努力定义服务边界。

发生这种情况的部分原因是,最流行的软件建模方法往往存在实施偏差。例如,领域驱动设计(DDD)倾向于面向对象的编程,而UML偏向数据建模的角度。除此之外,业界还没有就如何直观地描绘微服务系统模型达成共识,诸如应该描述哪些组件,应该如何表示关系,应该使用什么术语,更不用说这其中的任何工具。

不过,所有的希望都不会丢失。 DDD的一些概念,最明显的是“有界上下文”( bounded contexts)的概念,已经获得了普及,并启动了关于服务边界定义的行业对话。重要的是,DDD方法论中更高层次的抽象,包括域,子域,有界上下文,聚合(aggregates),上下文映射,都是技术不可知和模型为中心的。

理解系统的方法是关注组件之间的关系,如果想要一个微服务系统的基本表示,不需要比上下文映射更深入。因此,也许我们可以使用DDD上下文映射作为可视化微服务系统的起点。

即使在上下文映射层面,大型组织的完整服务系统也是不可理解的。因此,为了使上下文映射有用,为上下文映射本身设置上下文非常重要。这种上下文可以是特定整体应用程序的分解,或特定计划的服务交互。连贯地构建一个大型组织的微服务系统的唯一方法就是,逐条地,上下文地进行。


微服务上下文映射示例

来看一个例子。一家大型零售银行希望引入以客户为中心的服务,以实现留住客户的战略目标。它希望提供一种新的以客户为中心的支付解决方案,允许客户根据他们与银行的关系(他们的账户,投资,资产,交互模式)进行购买,而不是将授权决策基于一个特定帐户。

零售银行业务本身就是一个复杂的业务领域。客户,产品和服务渠道(分支机构,网上银行,销售点)等实体之间存在相互关系,以及与财务透明度和数据隐私相关的强制性规定。因此,尽管这种新的支付服务背后的想法很直观,但它却呈现出一个复杂的问题空间。那么从哪里开始呢?

继DDD方法松散之后,我们可以首先将零售银行业务领域划分为子域。作为一个起点,并遵循康威法则的必然性,可以从组成零售银行的组织单位开始,并与以客户为中心的支付解决方案相关。这些是:

这些子域可以通过以下方式进行可视化描述:






这给了我们一个考虑如何分类创建以客户为中心的支付解决方案服务的起点。自助银行和客户与卡片管理子域名突出显示,因为它们已被确定为解决方案的关键子域名。使用DDD的“语言边界”概念,显然有一些有界上下文出现在子域中。

在自助银行内部,有两种截然不同的有界上下文。网上银行渠道与手机银行渠道有共同的语言,他们都提供个性化的客户体验,而支持移动渠道的应用程序则是由网络渠道构建和共享组件。我们将这种情况称为context Online Banking。另一方面,销售点具有独特的语言,更多地集中在设备管理和商家关系上。我们将称之为销售点(context Point of Sale)。

客户与卡片管理甚至更加分散。核心客户信息,包括银行客户的权威列表,他们的联系信息和产品库,形成了一个独特的词汇表,我们称之为客户信息有界的上下文。另一种不同的语言被用来描述卡功能,这主要与支付活动有关。这是“消费者支付和交易”上下文。最后,还有一个客户身份上下文专注于客户安全和访问控制。

产品子域名对于此付款解决方案并不重要,但值得注意的是零售贷款和贷款子域划分为单独的PLC账户和信用卡上下文。完整的相关有界上下文如下所示:






在确定了有界上下文之后,现在可以考虑顾客将在其中使用哪些服务。如前所述,网上银行有两种服务消费者:网上银行web App和手机银行App。新的支付解决方案也将通过销售点的POS网络收到的消息请求所消耗。

客户身份上下文必须提供客户身份验证服务,以确保只有合适的请求者才能访问新的付款服务。客户信息背景包含客户和产品持有人之间的交叉参考,因此需要核心客户信息服务来为新的支付解决方案提供这些数据。

除此之外,跟踪客户财务活动,与其产品持有相关的财务事件,将有助于做出授权决策。因此,客户活动分析服务可以在客户信息上下文中创建。

消费者支付和交易环境是为新的以客户为中心的支付解决方案建立核心服务的场所。首先,客户需要注册新产品并设置其帐户和产品偏好。为此,引入了以客户为中心的支付管理服务。

对于非功能性原因(例如性能,安全性和可用性),我们将创建一个单独的授权支付服务,称为以客户为中心的支付授权服务。最后,由于向客户帐户发布交易可以晚于授权决定发布,因此我们将创建与授权服务分离的交易发布服务(Transaction Posting Service)。


对于产品子域,我们只会在每个有界的上下文中引用单个同名服务。例如,存款账户上下文只包含一个存款账户服务。整个服务系统现在看起来像这样:






这个设计过程的最后一步是注释将发生在服务之间的交互。事实上,人们可能想要模拟有界上下文之间的相互作用,以便梳理出单个服务,但为了覆盖视觉效果,我们将最后描述这一步骤。在这个阶段举例说明所有可能的交互会造成视觉混淆,因此只会关注一些能够帮助理解系统如何运作的关键信息。这里有些例子:
 
客户使用网上银行Web应用程序通过以客户为中心的支付管理服务,注册并设置新支付解决方案的偏好;

以客户为中心的支付管理服务从客户信息服务中检索客户的产品组合;

客户活动分析服务使用来自产品系统的信息构建客户财务状况;

客户通过移动银行应用程序执行以客户为中心的支付,该应用程序称为以客户为中心的支付授权服务;

以客户为中心的支付授权服务,依次使用来自以客户为中心的支付管理服务和客户活动分析服务的信息构建授权配置文件;
 
一旦获得授权,支付将被转发至交易发布服务完成,然后调用相应的产品服务;

关于微服务系统有几点需要注意。首先,不要假定在为最终用户活动提供服务时,这些交互中的每一个都会实时发生。例如,尽管以客户为中心的授权服务需要来自其他一些服务的信息,但可以使用基于事件的方法结合缓存来确保其处理是独立的,以便实时服务客户的授权请求。

其次,可以在有界上下文之间建立防腐层(ACL),以提供松散的语义耦合。最后,虽然这是一个相当复杂的图片,但没有实现细节。换句话说,这种模式可以使用许多不同的技术来实现,包括语言,主机环境和网络协议。

最终的上下文映射(包括交互)如下所示:






最终,此系统设计过程的目的是,帮助企业如何在复杂解决方案中定义微服务的服务边界进行最佳猜测。希望这里的方法既能为服务建立一个良好的初始模型,又能更容易地重新绘制服务边界。


Part 3:微服务设计画布

微服务有自身的起源,通常从现有单体应用程序中涌现出来,以满足眼前的需求。提高交付速度的愿望推动了微服务的采用,开发人员通常采取“代码优先,问题排后”的方法,并重复实现有用的结果。这可行,但它是最佳的吗?回答这个问题会带来另一个问题:在开发微服务之前应该考虑哪些设计因素?正如软件架构师Simon Brown所说,“前期做大设计是愚蠢的,但没有前期的设计更愚蠢。”

借鉴精益画布(lean canvas )方法设计商业模型,介绍一下微服务设计画布。这个画布是一个工具,可以帮助企业在构建服务之前捕获服务中最重要的前端属性。画布采用了一种外部方法,它可以很好地将您的界面与其底层实现松散耦合。






你可以先在底部框中填写服务的自由格式“说明”。从这里开始,你应该完成“消费者任务”框,记录服务消费者需要执行的任务。列举服务的消费者以及他们需要执行的任务有助于明确服务的目的,并提供设计界面所需的材料输入。这些信息可以帮助填写“界面”框。在这里,消费者任务可以细分为与服务接口的特定交互。根据模式(查询,命令,事件)对交互进行分类,将有助于形成底层服务实现,并最终推动API的设计。

除了服务的任务和交互之外,还必须考虑服务的非功能方面。可以使用“质量(Qualities)”框来确定服务属性,例如可用性和性能级别,可扩展性方法和安全性期望。这将有助于消费者进一步了解服务,并影响其实施。总而言之,消费者的任务,界面和品质定义了服务的“表面”。这对系统的设计至关重要,因为它捕获了系统中其他利益相关者所需的最重要的信息。

在表面之下,还有一些关键的考虑因素。 “逻辑/规则”和“数据”框为服务设计人员提供了一个位置,以记录这些领域的关键因素。抵制在这个阶段太深的诱惑。没有必要为服务的工作编写一个完整的内部系统设计,但是可能需要感觉独特和支持表面属性所需的项目。最后,应列出服务“依赖关系”,以便调出服务需要的任务。对于具有相当数量业务逻辑的任务繁重的微服务,需要与更多面向数据的服务进行交互是很自然的。但是,本着微服务架构的精神,目标是最大限度地减少这些依赖关系。

来看几个示例画布。首先是以客户为中心的支付管理服务画布:






请注意,该服务看起来好像在交互中很直接,并且与其数据相对独立。 从非功能角度来看,这不是关键任务,也不需要最高级别的事务完整性。 因此,它的实现可能相当简单。

接下来是以客户为中心的支付授权服务的画布:






这项服务有一些更复杂的考虑因素。首先,它预计将是高容量和低延迟。这对服务的工程设计产生了明确的影响,需要复杂的授权信息缓存。其次,由于它的交互涉及金钱的流动,交易完整性和审计至关重要。最后,有一些事件交互意味着接口将超越典型的RESTful API。事实上,看到这些非功能性差异就清楚地说明,为什么将以客户为中心的支付解决方案的授权和管理功能,分解为单独的服务是一个很好的设计决策。在系统视图和服务视图之间迭代将有助于定义服务边界。

希望这个微服务设计画布可以成为着手微服务部署的企业的有用工具。它清楚地与API设计联系在一起。

作者:Matt McLarty

原文链接:

1、Visualizing Microservices: API Design and Strategy

https://dzone.com/articles/vis ... ategy

2、Visualizing Microservices: Designing a Microservice System

https://dzone.com/articles/vis ... rvice

3、Visualizing Microservices: The Microservice Design Canvas

https://dzone.com/articles/vis ... esign



相关阅读:
2018最难招聘的11类IT人员

悉数四代PaaS发展,一文理顺基础设施、平台和工作流之间的关系
悉数四代PaaS发展,一文理顺基础设施、平台和工作流之间的关系


添加小数微信:xiaoshu062

备注公司、姓名、职位

小数将拉您进入相应技术群 查看全部
Part 1: API设计和策略

软件系统的复杂性是一个很痛苦的问题,而且无法避免。Fred Brooks将复杂性描述为,软件系统解决业务问题所固有的本质复杂性,以及实施该解决方案所带来的偶发复杂性。

随着与采用“API优先”工程实践和微服务架构的组织进行更密切的合作,我发现这种描述越来越有用。首先,通过这种方式分离复杂性,它允许架构师和工程师专注于最小化系统的偶发复杂性。

与微服务相关的技术创新有很大帮助:容器,自动化工具和API管理平台。但我真正喜欢这种复杂性划分的原因是,它帮助我们认清一个事实:任何技术都不能降低系统的本质复杂性。

“开发软件产品的许多经典问题源于这种本质的复杂性,其非线性随着规模的增加而增加。” – 出自Fred Brooks著《No Silver Bullet—Essence & Accident in Software Engineering》

但是,我们能做的至少是理解和记录一个系统的本质复杂性。对于大多数技术人员来说,有效完成这一任务很重要,因为系统的本质复杂性不包括解决方案中使用的底层技术。

系统本质复杂性定义的本质要素是系统执行的任务和功能,以及执行所需的对象和交互。为了优化这种定义的认知负荷,将此定义表达为视觉模型也是很自然的。即使在可视化的情况下,软件架构师仍然努力保持模型中的元素不受技术限制,并且保持一致。

Eric Evans的领域驱动设计(Domain-Driven Design ,DDD)方法论突出的原因是,它提供了一种可视化定义软件系统本质复杂性的方法。特别是,显示域,子域,有界上下文及其相互关系的上下文映射,与我见过的以有效方式说明本质复杂性的任何方法都非常接近。 UML意在提供一种用于定义与技术无关的应用程序描述的手段,但它的许多模型自然偏向于面向对象的根源。事实上,如果你深入DDD工具箱,我认为你会遇到同样的偏见。

我在定义一个互连微服务系统时,使用了DDD上下文映射的派生。将在未来的文章中详细介绍这种方法。


0.jpg


示例上下文映射

为什么理解和记录软件系统的本质复杂性很重要,这与微服务有什么关系?随着微服务系统的发展和演变,其许多好处来自于服务本身的凝聚力。PhilCalçado在他的博客文章“微服务与分布式对象的第一定律(Microservices & the First Law of Distributed Objects)”中强调了这一需求。凝聚力是确定服务边界的产物,这是模拟系统本质复杂性的必要步骤。

有趣的是,与Brooks所描述的复杂性似乎是矛盾的,微服务系统的技术无关上下文映射在某种程度上与它的实现的拓扑结构是同构的,远远超过一整套单体应用的拓扑。这可能是一个巧合,也表明我们正在采用这种微服务架构方法。


Part 2:设计微服务系统

最近我一直在与许多大型组织合作,帮助他们理解并实现Web API和微服务体系结构的价值。在这项工作中,我看到这些组织一直在努力于,如何定义企业里微服务之间的最佳边界。这是一个已知的问题,但没有解决。虽然关于凝聚式服务(cohesive services)的价值和有界上下文已经写了很多,但如何实际识别这些内容似乎没有指导意义。

这个问题的一个原因是,试图确定服务边界的人是技术人员,他们天生就在寻找技术解决方案,但是定义凝聚力和能力一致性的服务边界(cohesive, capability-aligned service boundaries)却需要领域专家。从根本上说,这应该是一种建模练习,它独立于任何技术的覆盖。然而,即使那些有意识地采用了技术无关建模方法的组织,也一直在努力定义服务边界。

发生这种情况的部分原因是,最流行的软件建模方法往往存在实施偏差。例如,领域驱动设计(DDD)倾向于面向对象的编程,而UML偏向数据建模的角度。除此之外,业界还没有就如何直观地描绘微服务系统模型达成共识,诸如应该描述哪些组件,应该如何表示关系,应该使用什么术语,更不用说这其中的任何工具。

不过,所有的希望都不会丢失。 DDD的一些概念,最明显的是“有界上下文”( bounded contexts)的概念,已经获得了普及,并启动了关于服务边界定义的行业对话。重要的是,DDD方法论中更高层次的抽象,包括域,子域,有界上下文,聚合(aggregates),上下文映射,都是技术不可知和模型为中心的。

理解系统的方法是关注组件之间的关系,如果想要一个微服务系统的基本表示,不需要比上下文映射更深入。因此,也许我们可以使用DDD上下文映射作为可视化微服务系统的起点。

即使在上下文映射层面,大型组织的完整服务系统也是不可理解的。因此,为了使上下文映射有用,为上下文映射本身设置上下文非常重要。这种上下文可以是特定整体应用程序的分解,或特定计划的服务交互。连贯地构建一个大型组织的微服务系统的唯一方法就是,逐条地,上下文地进行。


微服务上下文映射示例

来看一个例子。一家大型零售银行希望引入以客户为中心的服务,以实现留住客户的战略目标。它希望提供一种新的以客户为中心的支付解决方案,允许客户根据他们与银行的关系(他们的账户,投资,资产,交互模式)进行购买,而不是将授权决策基于一个特定帐户。

零售银行业务本身就是一个复杂的业务领域。客户,产品和服务渠道(分支机构,网上银行,销售点)等实体之间存在相互关系,以及与财务透明度和数据隐私相关的强制性规定。因此,尽管这种新的支付服务背后的想法很直观,但它却呈现出一个复杂的问题空间。那么从哪里开始呢?

继DDD方法松散之后,我们可以首先将零售银行业务领域划分为子域。作为一个起点,并遵循康威法则的必然性,可以从组成零售银行的组织单位开始,并与以客户为中心的支付解决方案相关。这些是:

这些子域可以通过以下方式进行可视化描述:

1.jpg


这给了我们一个考虑如何分类创建以客户为中心的支付解决方案服务的起点。自助银行和客户与卡片管理子域名突出显示,因为它们已被确定为解决方案的关键子域名。使用DDD的“语言边界”概念,显然有一些有界上下文出现在子域中。

在自助银行内部,有两种截然不同的有界上下文。网上银行渠道与手机银行渠道有共同的语言,他们都提供个性化的客户体验,而支持移动渠道的应用程序则是由网络渠道构建和共享组件。我们将这种情况称为context Online Banking。另一方面,销售点具有独特的语言,更多地集中在设备管理和商家关系上。我们将称之为销售点(context Point of Sale)。

客户与卡片管理甚至更加分散。核心客户信息,包括银行客户的权威列表,他们的联系信息和产品库,形成了一个独特的词汇表,我们称之为客户信息有界的上下文。另一种不同的语言被用来描述卡功能,这主要与支付活动有关。这是“消费者支付和交易”上下文。最后,还有一个客户身份上下文专注于客户安全和访问控制。

产品子域名对于此付款解决方案并不重要,但值得注意的是零售贷款和贷款子域划分为单独的PLC账户和信用卡上下文。完整的相关有界上下文如下所示:

2.jpg


在确定了有界上下文之后,现在可以考虑顾客将在其中使用哪些服务。如前所述,网上银行有两种服务消费者:网上银行web App和手机银行App。新的支付解决方案也将通过销售点的POS网络收到的消息请求所消耗。

客户身份上下文必须提供客户身份验证服务,以确保只有合适的请求者才能访问新的付款服务。客户信息背景包含客户和产品持有人之间的交叉参考,因此需要核心客户信息服务来为新的支付解决方案提供这些数据。

除此之外,跟踪客户财务活动,与其产品持有相关的财务事件,将有助于做出授权决策。因此,客户活动分析服务可以在客户信息上下文中创建。

消费者支付和交易环境是为新的以客户为中心的支付解决方案建立核心服务的场所。首先,客户需要注册新产品并设置其帐户和产品偏好。为此,引入了以客户为中心的支付管理服务。

对于非功能性原因(例如性能,安全性和可用性),我们将创建一个单独的授权支付服务,称为以客户为中心的支付授权服务。最后,由于向客户帐户发布交易可以晚于授权决定发布,因此我们将创建与授权服务分离的交易发布服务(Transaction Posting Service)。


对于产品子域,我们只会在每个有界的上下文中引用单个同名服务。例如,存款账户上下文只包含一个存款账户服务。整个服务系统现在看起来像这样:

3.jpg


这个设计过程的最后一步是注释将发生在服务之间的交互。事实上,人们可能想要模拟有界上下文之间的相互作用,以便梳理出单个服务,但为了覆盖视觉效果,我们将最后描述这一步骤。在这个阶段举例说明所有可能的交互会造成视觉混淆,因此只会关注一些能够帮助理解系统如何运作的关键信息。这里有些例子:
 
客户使用网上银行Web应用程序通过以客户为中心的支付管理服务,注册并设置新支付解决方案的偏好;

以客户为中心的支付管理服务从客户信息服务中检索客户的产品组合;

客户活动分析服务使用来自产品系统的信息构建客户财务状况;

客户通过移动银行应用程序执行以客户为中心的支付,该应用程序称为以客户为中心的支付授权服务;

以客户为中心的支付授权服务,依次使用来自以客户为中心的支付管理服务和客户活动分析服务的信息构建授权配置文件;
 
一旦获得授权,支付将被转发至交易发布服务完成,然后调用相应的产品服务;

关于微服务系统有几点需要注意。首先,不要假定在为最终用户活动提供服务时,这些交互中的每一个都会实时发生。例如,尽管以客户为中心的授权服务需要来自其他一些服务的信息,但可以使用基于事件的方法结合缓存来确保其处理是独立的,以便实时服务客户的授权请求。

其次,可以在有界上下文之间建立防腐层(ACL),以提供松散的语义耦合。最后,虽然这是一个相当复杂的图片,但没有实现细节。换句话说,这种模式可以使用许多不同的技术来实现,包括语言,主机环境和网络协议。

最终的上下文映射(包括交互)如下所示:

4.jpg


最终,此系统设计过程的目的是,帮助企业如何在复杂解决方案中定义微服务的服务边界进行最佳猜测。希望这里的方法既能为服务建立一个良好的初始模型,又能更容易地重新绘制服务边界。


Part 3:微服务设计画布

微服务有自身的起源,通常从现有单体应用程序中涌现出来,以满足眼前的需求。提高交付速度的愿望推动了微服务的采用,开发人员通常采取“代码优先,问题排后”的方法,并重复实现有用的结果。这可行,但它是最佳的吗?回答这个问题会带来另一个问题:在开发微服务之前应该考虑哪些设计因素?正如软件架构师Simon Brown所说,“前期做大设计是愚蠢的,但没有前期的设计更愚蠢。”

借鉴精益画布(lean canvas )方法设计商业模型,介绍一下微服务设计画布。这个画布是一个工具,可以帮助企业在构建服务之前捕获服务中最重要的前端属性。画布采用了一种外部方法,它可以很好地将您的界面与其底层实现松散耦合。

5.jpg


你可以先在底部框中填写服务的自由格式“说明”。从这里开始,你应该完成“消费者任务”框,记录服务消费者需要执行的任务。列举服务的消费者以及他们需要执行的任务有助于明确服务的目的,并提供设计界面所需的材料输入。这些信息可以帮助填写“界面”框。在这里,消费者任务可以细分为与服务接口的特定交互。根据模式(查询,命令,事件)对交互进行分类,将有助于形成底层服务实现,并最终推动API的设计。

除了服务的任务和交互之外,还必须考虑服务的非功能方面。可以使用“质量(Qualities)”框来确定服务属性,例如可用性和性能级别,可扩展性方法和安全性期望。这将有助于消费者进一步了解服务,并影响其实施。总而言之,消费者的任务,界面和品质定义了服务的“表面”。这对系统的设计至关重要,因为它捕获了系统中其他利益相关者所需的最重要的信息。

在表面之下,还有一些关键的考虑因素。 “逻辑/规则”和“数据”框为服务设计人员提供了一个位置,以记录这些领域的关键因素。抵制在这个阶段太深的诱惑。没有必要为服务的工作编写一个完整的内部系统设计,但是可能需要感觉独特和支持表面属性所需的项目。最后,应列出服务“依赖关系”,以便调出服务需要的任务。对于具有相当数量业务逻辑的任务繁重的微服务,需要与更多面向数据的服务进行交互是很自然的。但是,本着微服务架构的精神,目标是最大限度地减少这些依赖关系。

来看几个示例画布。首先是以客户为中心的支付管理服务画布:

6.jpg


请注意,该服务看起来好像在交互中很直接,并且与其数据相对独立。 从非功能角度来看,这不是关键任务,也不需要最高级别的事务完整性。 因此,它的实现可能相当简单。

接下来是以客户为中心的支付授权服务的画布:

7.jpg


这项服务有一些更复杂的考虑因素。首先,它预计将是高容量和低延迟。这对服务的工程设计产生了明确的影响,需要复杂的授权信息缓存。其次,由于它的交互涉及金钱的流动,交易完整性和审计至关重要。最后,有一些事件交互意味着接口将超越典型的RESTful API。事实上,看到这些非功能性差异就清楚地说明,为什么将以客户为中心的支付解决方案的授权和管理功能,分解为单独的服务是一个很好的设计决策。在系统视图和服务视图之间迭代将有助于定义服务边界。

希望这个微服务设计画布可以成为着手微服务部署的企业的有用工具。它清楚地与API设计联系在一起。

作者:Matt McLarty

原文链接:

1、Visualizing Microservices: API Design and Strategy

https://dzone.com/articles/vis ... ategy

2、Visualizing Microservices: Designing a Microservice System

https://dzone.com/articles/vis ... rvice

3、Visualizing Microservices: The Microservice Design Canvas

https://dzone.com/articles/vis ... esign



相关阅读:
2018最难招聘的11类IT人员

悉数四代PaaS发展,一文理顺基础设施、平台和工作流之间的关系
悉数四代PaaS发展,一文理顺基础设施、平台和工作流之间的关系


添加小数微信:xiaoshu062

备注公司、姓名、职位

小数将拉您进入相应技术群

号称“天生一对”的容器+微服务,能躲开微服务的悖论陷阱吗?

dataman 发表了文章 • 0 个评论 • 97 次浏览 • 2018-02-27 10:20 • 来自相关话题

导读:
容器和微服务是不是天生一对?容器化环境是否能更好地实施微服务?本文作者走访了数位亲身实践者,给出了一些进行容器化微服务管理的6大建议。如果您也在评估考虑微服务技术,此文不要错过。
 
 
01微服务的悖论
 
Gianna作为高级软件工程师加入了Avidoo公司,这是一家生产力平台。在与其他团队的会议上,她提出了微服务的问题,以及团队是否开始采用。她立即得到了强烈的反应。
 
拜伦表示:“我们尝试过采用微服务,但是它们不起作用。
 
“这带来了可怕的混乱!”另一位同事补充说。
 
Gianna三次眨巴眼睛,期待着某种阐述,但没有一个往下接着说。
 
Gianna沉默了一会儿,问:“发生了什么事?
 
“起初很棒。每次我们被要求做新的东西时,我们都可以添加一个服务,并使用想要实验的任何语言和框架。
 
我们将REST API 公布在需要与之协作或在其数据库上工作的系统上。但过了一段时间,事情开始越来越频繁地割裂,开发速度放慢了。

Gianna叹了口气。听起来像她的团队一直在建立一个分布式的巨石应用,而他们打算建立的是微服务。

 
分布式巨石应用和其他庞然大物

Gianna所遇到的问题太常见了。微服务是灵丹妙药,IT经理和工程师倾向于区分哪些优势与他们的组织相适应。
 
却忘记了天下没有免费的午餐这件事。除了优势之外,精心打造的微服务架构也有被微辞的一面。没有任何“错误”的微服务,只有微服务不能提供的好处,或者由于它们的缺点而造成的不可接受的风险。
 
使用微服务的优势

选择采用微服务应该首先决定哪种优势适合自身的企业。以下是一些突出的优点:
 
1.增强团队的自主性
许多公司围绕团队成员具备的知识或组件组织团队。在创造真正的客户价值时,这要求团队之间进行大量的协调,不可能同时处理一个特性。







利用单一专业团队创造价值
 
微服务通过cover一个功能来促进自治。因此,一个团队可以完全拥有它,而不需要多个团队一起,这有助于减少跨团队的协调。






利用多学科团队创造价值

 2.更大的容错

团队自治的地方也应该有自治的特点。一个功能通常依赖于另一个。在大多数环境中,通信通过REST接口,按需和pull-based。当这种互动是关键任务时,依靠这种通信的服务要么必须有合理的fall-back,要么就会失败。这种不健康的模式常常被系统运行状况检查所证明,如果系统的一个依赖性不健康,系统运行就会失败。除了导致部署顺序难以管理之外,它还说明了系统依赖性的困难。







运行时依赖关系
 
使用正确的软件架构(如event sourcing),可能补充CQRS,可以完全消除大多数功能之间的运行时依赖。这主要是由于从pull-based系统向push-based系统的转变。
 
3.细粒度的软件生命周期管理
 
开发和业务人员一个共同的愿望是,尽快用新程序替换应用程序中的某个功能。无论是因为要求改变或者重写,又或由于紧张的上市周期需求而导致的技术债务,都使得开发速度落后了。有人可能天真地认为,这些是可以快速被替代的,但其实不然。经常更换功能导致不得不对其所依赖的许多系统进行更改,反之亦然。







缺乏细粒度的软件生命周期管理
 
通过高度调节系统间通信,可以完全切换一个或多个功能,而不必触发任何依赖系统。

 
4.灵活的技术选择

不可否认,这是一个棘手的问题。在需求或个人兴趣的推动下,入职和培训员工切换到通用技术有助于团队间的流动性。但是对于使用不同技术的几个部门的员工,坦白地说,这可能导致大规模的罢工。







迫使技术做出选择
 
只要这些技术可以集成到自动化测试和部署工作流程中,一个团队就可以保持自己的技术选择。为什么要改变一个团结在对C#所有东西都非常热爱的胜利团队呢?只要他们能够产出符合平台监控,日志记录和通信规则的组件。
 
那么为什么他们失败了?
 
因为不知道应该如何去做微服务。采用微服务并不会失败,因为人们不知道如何去做,他们经常不记得首先要解决什么问题。与其他任何决定一样,采用微服务会带来一些成本。软件架构师往往会忘记,他们不应该帮助企业的管理者采用微服务,而应该帮助他们解决真正的业务问题。恰当地衡量这些方面的成本和收益对企业的需求至关重要。
 

02微服务和容器:6大长期管理技巧

部署基于容器的微服务仅仅是个开始,如何有效管理它呢?在我们最近发布的有关微服务和容器入门的文章中,Cloud Technology Partners公司副总裁兼首席云架构师 Mike Kavis分享了一个好消息:“部署容器非常容易。
 
他言简意赅的说:“尽管部署容器很容易,但是要多思考这些系统的运维。”
 
你可以用容器化的微服务深入到生产环境,但大多数专家不会推荐它,特别是如果这是你第一次使用这个强大的技术。
 
基于容器的微服务有相当多的优势:正如红帽技术布道者(Gordon Haff)最近写到的:“即使Match.com(编者注:一家相亲配对网站)也找不到微服务更好的合作伙伴。”但是 IT Heaven所做的大部分工作都需要强大灵活的计划,持续管理企业的容器化微服务架构。你的企业中可能存在一条学习曲线,需要实施智能最佳实践,确保高效运营。
 
SolarWinds公司的负责人Kong Yang说:“第一天之后,所有事情都变得更加复杂。
 
我们询问了Yang、Kavis等人,他们对有效管理容器化微服务的最佳建议。
 
1.保持简单
面对不断增加的复杂性,想要保持高效吗?那就保持简单,愚蠢。这种设计和工程原理,通常被认为是航空和系统工程师Clarence “Kelly” Johnson的指导原则。
 
对于Johnson来说,KISS和管理哲学一样重要,“我们的目标是通过对棘手问题的常识应用来更快更高效地获得结果。
 
对于IT团队来说,这些想法有一个可见的翻译,特别是在微服务和容器方面。
 
“为确保今后的成功运营,让每个微服务做一件事,做得非常好。不要将附加功能扩大到现有的执行良好的微服务里。”
 
2.尽早把管理计划落实到位
微服务和容器可以实现更快,更灵活,更弹性,响应速度更快的软件团队。但首要的事情是,在部署到生产之前制定一个计划。这样一个计划的范例框架如下:
开发部署,安全和运维的最佳实践微服务和容器利用现代化的日志记录和监控解决方案探索容器管理工具(又名编排平台,如Kubernetes),在云端和非云端点上了解自身的环境定期实行post-mortems,不断学习和提高
 
3.选择一个编排平台 

编排工具对于容器化微服务的长期成功至关重要。
 
“每个微服务都需要与管理应用程序共享其状态。这可以决定微服务的生命周期。” ShieldXNetworks 首席技术官 Manuel Nedbal说。“例如,一旦微服务不报告或者正在被超载,就可以用一个新服务替换或者被复制。”
 
4.制定一套最低限度的运营能力

一个容器管理平台不会为你做所有的工作。Retriever Communications首席技术官Nic Grange 说,除了像Kubernetes这样的编排系统之外,还需要确保每个容器化的微服务都遵循“最低限度的运营能力”,以便在这样的环境下运行良好。他提供了以下这些功能的关键示例列表:
编排系统需要能够访问每个微服务上的API,确定它是否准备好接收流量,以及是否健康。需要告知微服务何时正常关闭的方法。需要微服务公开指标和日志记录。在大多数情况下,微服务需要能够水平扩展,并且在某些情况下具备集群意识。
 
Grange也为开发人员分享了一些好消息:特定语言的微服务模板库(如go-kit for Go)和dropwizard for Java,可以节省大量的开发这些最低功能的前期工作。
 
Grange说:“这些让开发人员更容易做正确的事情,获得许多开箱即用的功能,而不必编写更多的代码。
 

5.实施持续集成和持续交付

Sungard Availability Services CTO& 高级架构师 Kevin McGrath 表示,持续集成和持续交付实践对于基于容器的微服务的长期管理是一个巨大的好处,尤其是作为支撑企业编排工具的基础。
 
McGrath说:“如果没有CI / CD,微服务的维护将会因为手动流程而变得不堪重负,无法按预期进行扩展,并且最终将比基础设施和人力资源中的整体应用成本更高。”
 
随着时间的推移,CI / CD将帮助团队释放编排或管理工具的潜力,尤其是在管理如何在主机池中分配CPU,内存和存储时。
 
McGrath解释说:“一旦CI / CD成为产品生命周期一个自然的组成部分,管理系统就非常好,它们处理各种基础架构需求,并将其作为工程师的逻辑配置参数。“对于运维来说,要全面了解主机,容器和服务的资源消耗情况,以便更好地了解需要更多资源的位置。当服务不再与特定的基础设施绑定,而是与基础设施需求相联系时,这一点非常重要。”
 

6.不断重新审视并重新投资业务

容器和微服务不是一劳永逸的技术。DigitalOcean公司的工程经理 Mac Browning 建议说,为了正确使用他们,需要不断在如何运行基于容器的微服务上进行投资。这个建议适用于企业的人员、流程和工具。编排平台是一个好的开始。
 
Browning说:“如果完全投资并使用像Kubernetes这样的编排平台,那就意味着要花时间和资源来跟上项目和更新,并在自己的部署中体现这些变化。“由于企业微服务现在集中运行,这项投资将对所有要运行的服务产生积极影响,而不是一个或两个特定的单一服务。”
 
 
原文链接:1、The Microservices Paradox
https://blog.xebialabs.com/2018/01/30/the-microservices-paradox/2、Microservices and containers: 6management tips for the long haul
https://enterprisersproject.com/article/2017/10/microservices-and-containers-6-management-tips-long-haul 
 
关注数人云了解更多技术信息
推荐阅读
跳槽季 | IT 8大热门招聘趋势 VS 8大受冷落岗位,你不能不看
看好还是看衰?8位业界大咖这么看Serverless的2018
看好还是看衰?8位业界大咖这么看Serverless的2018 查看全部
导读:
容器和微服务是不是天生一对?容器化环境是否能更好地实施微服务?本文作者走访了数位亲身实践者,给出了一些进行容器化微服务管理的6大建议。如果您也在评估考虑微服务技术,此文不要错过。
 
 
01微服务的悖论
 

Gianna作为高级软件工程师加入了Avidoo公司,这是一家生产力平台。在与其他团队的会议上,她提出了微服务的问题,以及团队是否开始采用。她立即得到了强烈的反应。
 
拜伦表示:“我们尝试过采用微服务,但是它们不起作用。
 
“这带来了可怕的混乱!”另一位同事补充说。
 
Gianna三次眨巴眼睛,期待着某种阐述,但没有一个往下接着说。
 
Gianna沉默了一会儿,问:“发生了什么事?
 
“起初很棒。每次我们被要求做新的东西时,我们都可以添加一个服务,并使用想要实验的任何语言和框架。
 
我们将REST API 公布在需要与之协作或在其数据库上工作的系统上。但过了一段时间,事情开始越来越频繁地割裂,开发速度放慢了。

Gianna叹了口气。听起来像她的团队一直在建立一个分布式的巨石应用,而他们打算建立的是微服务。

 
分布式巨石应用和其他庞然大物

Gianna所遇到的问题太常见了。微服务是灵丹妙药,IT经理和工程师倾向于区分哪些优势与他们的组织相适应。
 
却忘记了天下没有免费的午餐这件事。除了优势之外,精心打造的微服务架构也有被微辞的一面。没有任何“错误”的微服务,只有微服务不能提供的好处,或者由于它们的缺点而造成的不可接受的风险。
 
使用微服务的优势

选择采用微服务应该首先决定哪种优势适合自身的企业。以下是一些突出的优点:
 
1.增强团队的自主性
许多公司围绕团队成员具备的知识或组件组织团队。在创造真正的客户价值时,这要求团队之间进行大量的协调,不可能同时处理一个特性。


微信图片_20180227101017.jpg


利用单一专业团队创造价值
 
微服务通过cover一个功能来促进自治。因此,一个团队可以完全拥有它,而不需要多个团队一起,这有助于减少跨团队的协调。

微信图片_20180227101045.jpg


利用多学科团队创造价值

 2.更大的容错

团队自治的地方也应该有自治的特点。一个功能通常依赖于另一个。在大多数环境中,通信通过REST接口,按需和pull-based。当这种互动是关键任务时,依靠这种通信的服务要么必须有合理的fall-back,要么就会失败。这种不健康的模式常常被系统运行状况检查所证明,如果系统的一个依赖性不健康,系统运行就会失败。除了导致部署顺序难以管理之外,它还说明了系统依赖性的困难。


微信图片_20180227101133.jpg


运行时依赖关系
 
使用正确的软件架构(如event sourcing),可能补充CQRS,可以完全消除大多数功能之间的运行时依赖。这主要是由于从pull-based系统向push-based系统的转变。
 
3.细粒度的软件生命周期管理
 
开发和业务人员一个共同的愿望是,尽快用新程序替换应用程序中的某个功能。无论是因为要求改变或者重写,又或由于紧张的上市周期需求而导致的技术债务,都使得开发速度落后了。有人可能天真地认为,这些是可以快速被替代的,但其实不然。经常更换功能导致不得不对其所依赖的许多系统进行更改,反之亦然。


微信图片_20180227100334.jpg


缺乏细粒度的软件生命周期管理
 
通过高度调节系统间通信,可以完全切换一个或多个功能,而不必触发任何依赖系统。

 
4.灵活的技术选择

不可否认,这是一个棘手的问题。在需求或个人兴趣的推动下,入职和培训员工切换到通用技术有助于团队间的流动性。但是对于使用不同技术的几个部门的员工,坦白地说,这可能导致大规模的罢工。


微信图片_20180227101222.jpg


迫使技术做出选择
 
只要这些技术可以集成到自动化测试和部署工作流程中,一个团队就可以保持自己的技术选择。为什么要改变一个团结在对C#所有东西都非常热爱的胜利团队呢?只要他们能够产出符合平台监控,日志记录和通信规则的组件。
 
那么为什么他们失败了?
 
因为不知道应该如何去做微服务。采用微服务并不会失败,因为人们不知道如何去做,他们经常不记得首先要解决什么问题。与其他任何决定一样,采用微服务会带来一些成本。软件架构师往往会忘记,他们不应该帮助企业的管理者采用微服务,而应该帮助他们解决真正的业务问题。恰当地衡量这些方面的成本和收益对企业的需求至关重要。
 

02微服务和容器:6大长期管理技巧

部署基于容器的微服务仅仅是个开始,如何有效管理它呢?在我们最近发布的有关微服务和容器入门的文章中,Cloud Technology Partners公司副总裁兼首席云架构师 Mike Kavis分享了一个好消息:“部署容器非常容易。
 
他言简意赅的说:“尽管部署容器很容易,但是要多思考这些系统的运维。”
 
你可以用容器化的微服务深入到生产环境,但大多数专家不会推荐它,特别是如果这是你第一次使用这个强大的技术。
 
基于容器的微服务有相当多的优势:正如红帽技术布道者(Gordon Haff)最近写到的:“即使Match.com(编者注:一家相亲配对网站)也找不到微服务更好的合作伙伴。”但是 IT Heaven所做的大部分工作都需要强大灵活的计划,持续管理企业的容器化微服务架构。你的企业中可能存在一条学习曲线,需要实施智能最佳实践,确保高效运营。
 
SolarWinds公司的负责人Kong Yang说:“第一天之后,所有事情都变得更加复杂。
 
我们询问了Yang、Kavis等人,他们对有效管理容器化微服务的最佳建议。
 
1.保持简单
面对不断增加的复杂性,想要保持高效吗?那就保持简单,愚蠢。这种设计和工程原理,通常被认为是航空和系统工程师Clarence “Kelly” Johnson的指导原则。
 
对于Johnson来说,KISS和管理哲学一样重要,“我们的目标是通过对棘手问题的常识应用来更快更高效地获得结果。
 
对于IT团队来说,这些想法有一个可见的翻译,特别是在微服务和容器方面。
 
“为确保今后的成功运营,让每个微服务做一件事,做得非常好。不要将附加功能扩大到现有的执行良好的微服务里。”
 
2.尽早把管理计划落实到位
微服务和容器可以实现更快,更灵活,更弹性,响应速度更快的软件团队。但首要的事情是,在部署到生产之前制定一个计划。这样一个计划的范例框架如下:
  • 开发部署,安全和运维的最佳实践
  • 微服务和容器利用现代化的日志记录和监控解决方案
  • 探索容器管理工具(又名编排平台,如Kubernetes),在云端和非云端点上了解自身的环境
  • 定期实行post-mortems,不断学习和提高

 
3.选择一个编排平台 

编排工具对于容器化微服务的长期成功至关重要。
 
“每个微服务都需要与管理应用程序共享其状态。这可以决定微服务的生命周期。” ShieldXNetworks 首席技术官 Manuel Nedbal说。“例如,一旦微服务不报告或者正在被超载,就可以用一个新服务替换或者被复制。”
 
4.制定一套最低限度的运营能力

一个容器管理平台不会为你做所有的工作。Retriever Communications首席技术官Nic Grange 说,除了像Kubernetes这样的编排系统之外,还需要确保每个容器化的微服务都遵循“最低限度的运营能力”,以便在这样的环境下运行良好。他提供了以下这些功能的关键示例列表:
  • 编排系统需要能够访问每个微服务上的API,确定它是否准备好接收流量,以及是否健康。
  • 需要告知微服务何时正常关闭的方法。
  • 需要微服务公开指标和日志记录。
  • 在大多数情况下,微服务需要能够水平扩展,并且在某些情况下具备集群意识。

 
Grange也为开发人员分享了一些好消息:特定语言的微服务模板库(如go-kit for Go)和dropwizard for Java,可以节省大量的开发这些最低功能的前期工作。
 
Grange说:“这些让开发人员更容易做正确的事情,获得许多开箱即用的功能,而不必编写更多的代码。
 

5.实施持续集成和持续交付

Sungard Availability Services CTO& 高级架构师 Kevin McGrath 表示,持续集成和持续交付实践对于基于容器的微服务的长期管理是一个巨大的好处,尤其是作为支撑企业编排工具的基础。
 
McGrath说:“如果没有CI / CD,微服务的维护将会因为手动流程而变得不堪重负,无法按预期进行扩展,并且最终将比基础设施和人力资源中的整体应用成本更高。”
 
随着时间的推移,CI / CD将帮助团队释放编排或管理工具的潜力,尤其是在管理如何在主机池中分配CPU,内存和存储时。
 
McGrath解释说:“一旦CI / CD成为产品生命周期一个自然的组成部分,管理系统就非常好,它们处理各种基础架构需求,并将其作为工程师的逻辑配置参数。“对于运维来说,要全面了解主机,容器和服务的资源消耗情况,以便更好地了解需要更多资源的位置。当服务不再与特定的基础设施绑定,而是与基础设施需求相联系时,这一点非常重要。”
 

6.不断重新审视并重新投资业务

容器和微服务不是一劳永逸的技术。DigitalOcean公司的工程经理 Mac Browning 建议说,为了正确使用他们,需要不断在如何运行基于容器的微服务上进行投资。这个建议适用于企业的人员、流程和工具。编排平台是一个好的开始。
 
Browning说:“如果完全投资并使用像Kubernetes这样的编排平台,那就意味着要花时间和资源来跟上项目和更新,并在自己的部署中体现这些变化。“由于企业微服务现在集中运行,这项投资将对所有要运行的服务产生积极影响,而不是一个或两个特定的单一服务。”
 
 
原文链接:1、The Microservices Paradox
https://blog.xebialabs.com/2018/01/30/the-microservices-paradox/2、Microservices and containers: 6management tips for the long haul
https://enterprisersproject.com/article/2017/10/microservices-and-containers-6-management-tips-long-haul 
 
关注数人云了解更多技术信息
推荐阅读
跳槽季 | IT 8大热门招聘趋势 VS 8大受冷落岗位,你不能不看
看好还是看衰?8位业界大咖这么看Serverless的2018
看好还是看衰?8位业界大咖这么看Serverless的2018

看好还是看衰?8位业界大咖这么看Serverless的2018

dataman 发表了文章 • 0 个评论 • 107 次浏览 • 2018-02-23 11:37 • 来自相关话题

导读:

Serverless,也称为FaaS(功能即服务),它并不意味着没有服务器在执行繁重的任务 ;而是用户看不到或者不必维护服务器,并且不关心它所在的世界。小数之前跟大家分享过多次Serverless的话题,比如,思考+案例,大咖研究了Serverless14个月,优缺全体现!,再比如,容器之后的下一个明星,关于无服务器(Serverless)架构你要搞懂的8件事。今天这篇主要由8位业内意见领袖谈2018Serverless的去向。
在所谓的无服务器IT系统中,数据工作负载是如何处理的? 

亚马逊的AWS Lambda是无服务器计算最大、最著名的例子,它的未来对很多IT人来说是非常诱人的。Lambda是由 Amazon开发的一个事件驱动的计算平台,当特定事件发生时,它会自动触发或执行代码。Lambda只在需要时执行代码,并自动伸缩,为企业处理一些数据流程和应用程序,提供潜在的成本节约和灵活性。

Amazon 在2014年发布了Lambda,作为企业在云中运行代码的“无服务器”平台,不需要物理服务器,也不需要在企业端提供或管理任何服务器。



1、Serverless无服务器是未来的潮流


在应用程序代码方面,AWS支持Node.js、Java、c#和现在的Python,只要开发人员在其中一种语言中编写代码,代码就可以在Lambda运行环境中运行,并利用Lambda资源。


亚马逊并不是唯一的FaaS供应商,其他还包括谷歌云,微软Azure,IBM OpenWhisk和开源项目Iron.io,以及Webtask。


无服务器的工作负载生产仍然处于初级阶段,但如果IT界的各种预言者都是正确的,那么它将很快在我们眼前成长起来。


以下是一些来自行业专家对serverless未来的展望:>>>>Sumo Logic (相扑逻辑):无服务器计算可能是继容器之后的未来AWS的采用率几乎翻了一番,从2016年的12%上升到2017年的23%。serverless的整个想法是,它通过完全跳过容器和DevOps将微服务转移到未来。事实上,有四分之一的开发人员已经在使用serverless,这对于遵循应用程序架构和采用的人来说是一种强烈的信号。IT领导者已经在谈论DevOps,但是serverless将它带到一个全新的世界“NoOps”——在没有基础设施的情况下,应用程序在云中运行。>>>>Avere Systems技术总监Dan Nydick : 我们将看到更多serverless技术和托管服务企业经常花费大量的时间和精力来管理计算基础设施,这不是他们任务和使命的核心任务。公有云的好处之一是,将应用程序迁移到云上之后,企业不再需要管理这些基础设施。云供应商提供了越来越高水平的管理服务,允许客户专注于自身业务,而不必被虚拟机、web服务器或数据库管理分散注意力。


我们将看到更多使用托管的、可伸缩的web服务(如谷歌 App Engine和AWS Beanstalk)和无服务器技术(如AWS Lambda和谷歌CloudFunctions),作为管理和部署复杂企业应用程序的更经济的方式。


“我们预计云供应商将继续向更高级别的托管服务发展,例如完全分布式数据库管理(谷歌Cloud Spanner),以及第三方出售托管在公有云(Azure Managed Apps)中的应用程序的新能力。”>>>>Atlassian平台负责人Steve Deasy:2018将如何改变软件的构建方式“随着来自主要云供应商的支持,无服务器的框架将会受到欢迎。”此外,数据驱动的应用程序将继续受到欢迎,而对工程师需求的支持也将以工具、基础设施和争论(wrangling)的形式出现。在《Mortal Kombat》中提到,Kubernetes将给现有的平台带来致命的灾难。

 

>>>>Evident.io公司CEO Tim Prendergast和客户解决方案副总裁John Martinez:容器和无服务器计算增加,它们会带来安全问题。


“2018年,公司将采用云计算的方式,传统的基于主机的操作系统将变得无关紧要,或者需要重新设计。”从安全的角度来看,没有人真正准备好保护所有这些容器和功能计算,但是人们还是采用了它。>>>>Contino公司主席Jason McDonald:无服务器采用将继续增加其影响。“Serverless将从云产业的小角落转移到聚光灯下,因为它解决了IT三个关键领域的管理:速度、成本和风险。事实上,亚马逊推出AWS Fargate,这是一种创新,它通过删除服务器,消除运行ECS集群所需的基础设施管理,从而极大地改变了容器的演化。


目前,至少有一家美国主要银行正在运行企业级应用程序,这是一个基于Lambda的专职基础架构,可解决成本和规模问题。未来将会有越来越多类似这样的故事,基于云的堆栈越来越多地迁移到无服务器架构中。



>>>>OVH US公司技术布道者和首席系统工程师 Paul Stephenson: 无服务器计算解决哪些用例将会更清晰。


“这项技术目前非常具有探索性,事件驱动的技术仍在继续。”很高兴看到这一领域发生的一切, 因为IT做的任何事情都可以提高企业业绩表现,同时保持相同或较低的风险状况,这将推动企业进行调研和投资。”>>>>Data Expedition CEO Seth Noble: 2018年,Serverless将与其他技术整合云供应商给客户和第三方留下了许多关键的云迁移元素。这为一些关键领域(如数据输入、数据组织和应用部署)带来了隐形成本。2018年,我们将会看到更多客户要求实际的解决方案,如真正的网络加速,缩小对象存储和文件存储之间的差距,以及更好的工具来集成基于无服务器的应用程序和无服务器服务。
>>>>Platform9 CEO Sirish Raghuram: Kubernetes将会在AWS Lambda无服务器部署中变得更有影响力。Kubernetes不仅可以让云更容易交叉使用,还可以降低云提供的其他高价值应用服务的价值。比如Lambda,用于无服务器计算。有很多开源的替代方案,比如Fission,开源并运行在任何Kubernetes集群上,提供了相同的价值主张。这仅仅是一个例子,说明云提供商自身原生服务的价值可能会发生级联变化,还会发生在Kubernetes生态系统中可用的应用服务范围内。“

 

2、7大提供FaaS的开源无服务器框架

随着虚拟化技术的发展,企业开始意识到物理硬件的利用率越来越高。随着云计算的发展,企业开始逐渐将虚拟机用于即付即用的服务中,AWS在2014年推出了Lambda服务,引入了云计算的新范例,如今已经成为通常所说的无服务器计算。在无服务器模式中,企业将功能作为服务付费,而不需要为永远在线的状态虚拟机付费。AWS lambda开创了serverless,现在有多个开源项目构建可用于多重部署的无服务器框架:

1.Apache Openwhisk

IBM启动了apache openwhisk项目,现在它是IBMCloud Functions服务的基础。


2.Fission uses kubernetes for serverless

由云服务供应商Platform9领导的开源Fission项目是一个基于Kubernetes的无服务器框架。”Fission是开放源代码项目,旨在成为lambda事实上的开源替代品,”Madhura Maskasky,PLatform9的联合创始人,在2017年1月采访时对eWEEK说。


3.IronFunctions

IronFunctions是一种以Go语言编写的FaaS平台。功能是任何云计算,包括公有云、私有云和混合云提供开源无服务器计算平台。


4.Fn project backed by Oracle

2017年10月甲骨文公司宣布开源Fn项目,为apache许可的无服务器项目。


5.OpenFaas

OpenFaas 是一种能够使docker或者kubernetes都变成无服务器的开源项目,是一种FaaS框架。


6.Kubeless

开源框架Kubeless是由2017年3月被Bitnami收购的软件供应商Skippbox开发的。

kubeless是一个kubernetes本地无服务器框架,具有符合AWS Lambda CLI的命令行界面(CLI)


7.Riff

在最新的开源无服务器框架中,Riff项目得到了关键支持,并且是即将到来的Pivotal Function Service(PFS)的基础。
 
 
 
>>>>调查显示企业不断从私有云转向公有云

一项对300名IT专业人员的调查显示,公有云系统将继续快速增长,因为企业将把他们的本地数据中心资产转移到云平台。

Serverless这种新兴的云计算服务交付模式为开发人员和管理人员带了很多好处。它提供了合适的灵活性和控制性级别。Serverless架构正在彻底改变软件开发和部署流程。



原文链接:

1、Predictions 2018: Why Serverless Processing May Be Wave of the Future

http://www.eweek.com/innovatio ... uture

2、7 Open-Source Serverless Frameworks Providing Functions as a Service

http://www.eweek.com/cloud/7-open-source-serverless-frameworks-providing-functions-as-a-service
 
 
  查看全部
导读:

Serverless,也称为FaaS(功能即服务),它并不意味着没有服务器在执行繁重的任务 ;而是用户看不到或者不必维护服务器,并且不关心它所在的世界。小数之前跟大家分享过多次Serverless的话题,比如,思考+案例,大咖研究了Serverless14个月,优缺全体现!,再比如,容器之后的下一个明星,关于无服务器(Serverless)架构你要搞懂的8件事。今天这篇主要由8位业内意见领袖谈2018Serverless的去向。
在所谓的无服务器IT系统中,数据工作负载是如何处理的? 

亚马逊的AWS Lambda是无服务器计算最大、最著名的例子,它的未来对很多IT人来说是非常诱人的。Lambda是由 Amazon开发的一个事件驱动的计算平台,当特定事件发生时,它会自动触发或执行代码。Lambda只在需要时执行代码,并自动伸缩,为企业处理一些数据流程和应用程序,提供潜在的成本节约和灵活性。

Amazon 在2014年发布了Lambda,作为企业在云中运行代码的“无服务器”平台,不需要物理服务器,也不需要在企业端提供或管理任何服务器。



1、Serverless无服务器是未来的潮流


在应用程序代码方面,AWS支持Node.js、Java、c#和现在的Python,只要开发人员在其中一种语言中编写代码,代码就可以在Lambda运行环境中运行,并利用Lambda资源。


亚马逊并不是唯一的FaaS供应商,其他还包括谷歌云,微软Azure,IBM OpenWhisk和开源项目Iron.io,以及Webtask。


无服务器的工作负载生产仍然处于初级阶段,但如果IT界的各种预言者都是正确的,那么它将很快在我们眼前成长起来。


以下是一些来自行业专家对serverless未来的展望:>>>>Sumo Logic (相扑逻辑):无服务器计算可能是继容器之后的未来AWS的采用率几乎翻了一番,从2016年的12%上升到2017年的23%。serverless的整个想法是,它通过完全跳过容器和DevOps将微服务转移到未来。事实上,有四分之一的开发人员已经在使用serverless,这对于遵循应用程序架构和采用的人来说是一种强烈的信号。IT领导者已经在谈论DevOps,但是serverless将它带到一个全新的世界“NoOps”——在没有基础设施的情况下,应用程序在云中运行。>>>>Avere Systems技术总监Dan Nydick : 我们将看到更多serverless技术和托管服务企业经常花费大量的时间和精力来管理计算基础设施,这不是他们任务和使命的核心任务。公有云的好处之一是,将应用程序迁移到云上之后,企业不再需要管理这些基础设施。云供应商提供了越来越高水平的管理服务,允许客户专注于自身业务,而不必被虚拟机、web服务器或数据库管理分散注意力。


我们将看到更多使用托管的、可伸缩的web服务(如谷歌 App Engine和AWS Beanstalk)和无服务器技术(如AWS Lambda和谷歌CloudFunctions),作为管理和部署复杂企业应用程序的更经济的方式。


“我们预计云供应商将继续向更高级别的托管服务发展,例如完全分布式数据库管理(谷歌Cloud Spanner),以及第三方出售托管在公有云(Azure Managed Apps)中的应用程序的新能力。”>>>>Atlassian平台负责人Steve Deasy:2018将如何改变软件的构建方式“随着来自主要云供应商的支持,无服务器的框架将会受到欢迎。”此外,数据驱动的应用程序将继续受到欢迎,而对工程师需求的支持也将以工具、基础设施和争论(wrangling)的形式出现。在《Mortal Kombat》中提到,Kubernetes将给现有的平台带来致命的灾难。

 

>>>>Evident.io公司CEO Tim Prendergast和客户解决方案副总裁John Martinez:容器和无服务器计算增加,它们会带来安全问题。


“2018年,公司将采用云计算的方式,传统的基于主机的操作系统将变得无关紧要,或者需要重新设计。”从安全的角度来看,没有人真正准备好保护所有这些容器和功能计算,但是人们还是采用了它。>>>>Contino公司主席Jason McDonald:无服务器采用将继续增加其影响。“Serverless将从云产业的小角落转移到聚光灯下,因为它解决了IT三个关键领域的管理:速度、成本和风险。事实上,亚马逊推出AWS Fargate,这是一种创新,它通过删除服务器,消除运行ECS集群所需的基础设施管理,从而极大地改变了容器的演化。


目前,至少有一家美国主要银行正在运行企业级应用程序,这是一个基于Lambda的专职基础架构,可解决成本和规模问题。未来将会有越来越多类似这样的故事,基于云的堆栈越来越多地迁移到无服务器架构中。



>>>>OVH US公司技术布道者和首席系统工程师 Paul Stephenson: 无服务器计算解决哪些用例将会更清晰。


“这项技术目前非常具有探索性,事件驱动的技术仍在继续。”很高兴看到这一领域发生的一切, 因为IT做的任何事情都可以提高企业业绩表现,同时保持相同或较低的风险状况,这将推动企业进行调研和投资。”>>>>Data Expedition CEO Seth Noble: 2018年,Serverless将与其他技术整合云供应商给客户和第三方留下了许多关键的云迁移元素。这为一些关键领域(如数据输入、数据组织和应用部署)带来了隐形成本。2018年,我们将会看到更多客户要求实际的解决方案,如真正的网络加速,缩小对象存储和文件存储之间的差距,以及更好的工具来集成基于无服务器的应用程序和无服务器服务。
>>>>Platform9 CEO Sirish Raghuram: Kubernetes将会在AWS Lambda无服务器部署中变得更有影响力。Kubernetes不仅可以让云更容易交叉使用,还可以降低云提供的其他高价值应用服务的价值。比如Lambda,用于无服务器计算。有很多开源的替代方案,比如Fission,开源并运行在任何Kubernetes集群上,提供了相同的价值主张。这仅仅是一个例子,说明云提供商自身原生服务的价值可能会发生级联变化,还会发生在Kubernetes生态系统中可用的应用服务范围内。“

 

2、7大提供FaaS的开源无服务器框架

随着虚拟化技术的发展,企业开始意识到物理硬件的利用率越来越高。随着云计算的发展,企业开始逐渐将虚拟机用于即付即用的服务中,AWS在2014年推出了Lambda服务,引入了云计算的新范例,如今已经成为通常所说的无服务器计算。在无服务器模式中,企业将功能作为服务付费,而不需要为永远在线的状态虚拟机付费。AWS lambda开创了serverless,现在有多个开源项目构建可用于多重部署的无服务器框架:

1.Apache Openwhisk

IBM启动了apache openwhisk项目,现在它是IBMCloud Functions服务的基础。


2.Fission uses kubernetes for serverless

由云服务供应商Platform9领导的开源Fission项目是一个基于Kubernetes的无服务器框架。”Fission是开放源代码项目,旨在成为lambda事实上的开源替代品,”Madhura Maskasky,PLatform9的联合创始人,在2017年1月采访时对eWEEK说。


3.IronFunctions

IronFunctions是一种以Go语言编写的FaaS平台。功能是任何云计算,包括公有云、私有云和混合云提供开源无服务器计算平台。


4.Fn project backed by Oracle

2017年10月甲骨文公司宣布开源Fn项目,为apache许可的无服务器项目。


5.OpenFaas

OpenFaas 是一种能够使docker或者kubernetes都变成无服务器的开源项目,是一种FaaS框架。


6.Kubeless

开源框架Kubeless是由2017年3月被Bitnami收购的软件供应商Skippbox开发的。

kubeless是一个kubernetes本地无服务器框架,具有符合AWS Lambda CLI的命令行界面(CLI)


7.Riff

在最新的开源无服务器框架中,Riff项目得到了关键支持,并且是即将到来的Pivotal Function Service(PFS)的基础。
 
 
 
>>>>调查显示企业不断从私有云转向公有云

一项对300名IT专业人员的调查显示,公有云系统将继续快速增长,因为企业将把他们的本地数据中心资产转移到云平台。

Serverless这种新兴的云计算服务交付模式为开发人员和管理人员带了很多好处。它提供了合适的灵活性和控制性级别。Serverless架构正在彻底改变软件开发和部署流程。



原文链接:

1、Predictions 2018: Why Serverless Processing May Be Wave of the Future

http://www.eweek.com/innovatio ... uture

2、7 Open-Source Serverless Frameworks Providing Functions as a Service

http://www.eweek.com/cloud/7-open-source-serverless-frameworks-providing-functions-as-a-service
 
 
 

25篇技术干货说尽微服务、Service Mesh、容器、DevOps | Meetup年度实录集

dataman 发表了文章 • 0 个评论 • 244 次浏览 • 2018-02-09 11:03 • 来自相关话题

导读:

小数为大家汇总了数人云2017年举办的十几场技术meetup上的演讲实录。这些实录有关微服务、服务网格Service Mesh、DevOps、云原生、Kubernetes、SRE以及容器等等,分享嘉宾都是前沿技术公司技术专家和大咖,以及传统企业和互联网企业的落地实践。满满的干货,值得温习一遍又一遍!
 
 
 
1

Cloud Native架构下的K8S和微服务实践
 
时间:2018年1月27日,地点:深圳

PPT | 从架构到组件,深挖istio如何连接、管理和保护微服务2.0?
亿级用户万台服务器背后,vivo云服务容器化如何破茧化蝶?


2

服务网格:ServiceMesh is Coming
 
时间:2017年12月16日,地点:北京

ServiceMesh谁主沉浮?数人云资深架构师最新解读

WeiboMesh服务化实践如何应对明星劈腿的顶级流量?
 
3

论道云原生和微服务,剑指何方?
 
时间:2017年11月4日,地点:北京

5位大咖同台论道,中西方微服务有何异同?
 
 
4

将微服务进行到底
 
时间:2017年9月23日,地点:北京

90%产品服务化,细说豆瓣的5年变革之路
 
 
5

K8S GeekGathering 2017 上海站
 
时间:2017年9月10日 地点:上海

数人云架构师:微服务体系中的K8S&Mesos调度与服务发现
 
 
6

K8S、Mesos还不够? 8月19日更多Container+技术
 
时间:2017年8月19日  地点:北京

微软AzureContainer Service的容器化应用

当K8S遇上微服务-京东金融PaaS平台思考与实践
 
7

DevOps&SRE 超越传统运维之道上海站
 
时间:2017年7月15日 地点:上海

有心了,他写了一份DevOps&SRE参会笔记分享给你 | 附PPT下载

SRE遇上金融老干部,解决发布协调&监控告警两大难题
 
 
8

DevOps&SRE 超越传统运维之道深圳站
 
时间:2017年5月6日  地点:深圳

数人云王璞:《SRE在传统企业中的落地实践》

腾讯大梁:《DevOps最后一棒,有效构建海量运营的持续反馈能力》
 
 
9

大牛的成长轨迹之架构&运维
 
时间:2017年4月15日  地点:北京

当当架构部张亮:从码农到大牛,技术与心境的双重提升
 
 
10

当西方的SRE遇上东方的互联网
 
时间:2017年3月4日  地点:北京

活学活用SRE,美团点评,前Google SRE线下分享视频

活学活用SRE,数人云,某金融线下分享视频
 
 
11

告别人肉运维
 
时间: 2017年2月25日  地点:上海

告别人肉运维,饿了么和数人云的经验都在这里了

拒绝删库到跑路,探究饿了么数据安全保障体系

DesignFor Failure——饿了么技术运营实践
 
 
12

容器之Mesos/K8S/Swarm三国演义深圳站
 
时间:2017年1月7日,地点:深圳

Kubernetes在腾讯游戏的应用实践

实录分享 | Mesos PMC带你回顾Mesos 2016

广发银行运维实践分享:Docker适配传统运维那些事
 
13

容器之Mesos/K8S/Swarm三国演义上海站
 
时间:2017年1月7日,地点:上海

.Net大户的选择:Windows Container在携程的应用

构建与定制:唯品会PaaS基于Kubernetes的实践

Docker在Bilibili的实战:由痛点推动的容器化



添加小数微信:xiaoshu062

备注公司、姓名、职位

小数将拉您进入相应技术群 查看全部
导读:

小数为大家汇总了数人云2017年举办的十几场技术meetup上的演讲实录。这些实录有关微服务、服务网格Service Mesh、DevOps、云原生、Kubernetes、SRE以及容器等等,分享嘉宾都是前沿技术公司技术专家和大咖,以及传统企业和互联网企业的落地实践。满满的干货,值得温习一遍又一遍!
 
 
 
1

Cloud Native架构下的K8S和微服务实践
 
时间:2018年1月27日,地点:深圳

PPT | 从架构到组件,深挖istio如何连接、管理和保护微服务2.0?
亿级用户万台服务器背后,vivo云服务容器化如何破茧化蝶?


2

服务网格:ServiceMesh is Coming
 
时间:2017年12月16日,地点:北京

ServiceMesh谁主沉浮?数人云资深架构师最新解读

WeiboMesh服务化实践如何应对明星劈腿的顶级流量?
 
3

论道云原生和微服务,剑指何方?
 
时间:2017年11月4日,地点:北京

5位大咖同台论道,中西方微服务有何异同?
 
 
4

将微服务进行到底
 
时间:2017年9月23日,地点:北京

90%产品服务化,细说豆瓣的5年变革之路
 
 
5

K8S GeekGathering 2017 上海站
 
时间:2017年9月10日 地点:上海

数人云架构师:微服务体系中的K8S&Mesos调度与服务发现
 
 
6

K8S、Mesos还不够? 8月19日更多Container+技术
 
时间:2017年8月19日  地点:北京

微软AzureContainer Service的容器化应用

当K8S遇上微服务-京东金融PaaS平台思考与实践
 
7

DevOps&SRE 超越传统运维之道上海站
 
时间:2017年7月15日 地点:上海

有心了,他写了一份DevOps&SRE参会笔记分享给你 | 附PPT下载

SRE遇上金融老干部,解决发布协调&监控告警两大难题
 
 
8

DevOps&SRE 超越传统运维之道深圳站
 
时间:2017年5月6日  地点:深圳

数人云王璞:《SRE在传统企业中的落地实践》

腾讯大梁:《DevOps最后一棒,有效构建海量运营的持续反馈能力》
 
 
9

大牛的成长轨迹之架构&运维
 
时间:2017年4月15日  地点:北京

当当架构部张亮:从码农到大牛,技术与心境的双重提升
 
 
10

当西方的SRE遇上东方的互联网
 
时间:2017年3月4日  地点:北京

活学活用SRE,美团点评,前Google SRE线下分享视频

活学活用SRE,数人云,某金融线下分享视频
 
 
11

告别人肉运维
 
时间: 2017年2月25日  地点:上海

告别人肉运维,饿了么和数人云的经验都在这里了

拒绝删库到跑路,探究饿了么数据安全保障体系

DesignFor Failure——饿了么技术运营实践
 
 
12

容器之Mesos/K8S/Swarm三国演义深圳站
 
时间:2017年1月7日,地点:深圳

Kubernetes在腾讯游戏的应用实践

实录分享 | Mesos PMC带你回顾Mesos 2016

广发银行运维实践分享:Docker适配传统运维那些事
 
13

容器之Mesos/K8S/Swarm三国演义上海站
 
时间:2017年1月7日,地点:上海

.Net大户的选择:Windows Container在携程的应用

构建与定制:唯品会PaaS基于Kubernetes的实践

Docker在Bilibili的实战:由痛点推动的容器化



添加小数微信:xiaoshu062

备注公司、姓名、职位

小数将拉您进入相应技术群

4大维度3大预测,基于容器生态扩张的DevSecOps为啥引关注?

dataman 发表了文章 • 0 个评论 • 116 次浏览 • 2018-02-08 10:22 • 来自相关话题

 





DevSecOps可能不是一个优雅的术语,但其结果是有吸引力的: 在开发的早期带来更强大的安全性。DevOps最终是要建立更好的软件,也意味着更安全的软件。
 
像任何IT术语一样,DevSecOps--由DevOps衍生而来,很容易被炒作和盗用。但是这个术语对拥抱DevOps文化的IT领导者以及实现其承诺的实践和工具而言,具有真正的意义。
 

 DevSecOps什么意思?
 
Datic公司首席技术官兼共同创始人RobertReeves说:“DevSecOps是开发,安全和运维的组合。它提醒我们,对于应用程序来说,安全和创建、部署到生产上同样重要。”
 
向非技术人员解释DevSecOps的一个简单方法:它有意识地更早地将安全性融入到开发过程中。
 
红帽安全战略家Kirsten Newcomer 最近告诉我们: “历史上,安全团队从开发团队中分离出来,每个团队都在不同的IT领域拥有深厚的专业知识  。“其实不需要这样。关心安全的企业也非常关心通过软件快速交付业务价值的能力,这些企业正在寻找方法,将安全性留在应用开发生命周期内。通过在整个CI / CD中集成安全实践,工具和自动化来采用DevSecOps。”
 
她说:“为了做到这一点,他们正在整合团队。安全专业人员将从应用开发团队一直嵌入到生产部署中。” “双方都看到了价值,每个团队都拓展了他们的技能和知识基础,成为更有价值的技术专家。正确的DevOps或DevSecOps ,提高IT安全性。”
 
IT团队的任务是更快,更频繁地交付服务。DevOps成为一个很好的推动因素,部分原因是它可以消除开发和运营团队之间的一些传统冲突,Ops通常在部署之前被排除在外,而Dev将其代码丢在无形的墙上,从来不进行二次管理,更没有任何的基础设施维护责任。说得委婉一些,在数字化时代,这种孤立的做法会产生问题。按照Reeves的说法,如果安全是孤立的,也会存在类似的问题。
 
Reeves说:“我们采用DevOps,它被证明可以通过扫除开发与运维之间的障碍来提高IT的性能。“就像不应该等到部署周期结束才开始运维一样,也不应该等到最后才考虑安全问题。”
 

 DevSecOps为什么会出现?
 
将DevSecOps看作是另一个流行语是一种诱惑,但对于安全意识强的IT领导者来说,这是一个实质性的概念。安全必须是软件开发流程中的“一等公民”,而并非最终步骤部署,或者更糟糕,只有在发生实际的安全事件后才受到重视。
SumoLogic公司安全与合规副总裁George Gerchow表示:“DevSecOps不仅仅是一个流行词,由于诸多原因它是IT的当前和未来状态。“最重要的好处是能够将安全性融入到开发和运营流程中,为实现敏捷性和创新提供保障。”
 
此外,在场景中出现的DevSecOps可能是DevOps自身正在成熟并深入挖掘IT内部的另一个标志。
 
“企业DevOps文化意味着开发人员能够以更快的速度向生产环境提供功能和更新,特别是当自组织团队更加乐于协作和衡量结果。”CYBRIC首席技术官兼联合创始人Mike Kail说。
 
在采用DevOps的同时,保持原有的安全实践的团队和公司会遇到更多的管理安全风险的痛苦,因为DevOps团队会部署地更快、更频繁。
 

 手动测试安全方法逐渐落后

 “目前,手动测试安全方法逐渐落后,利用自动化和协作将安全测试转移到软件开发生命周期,从而推动DevSecOps文化,这是IT领导者提高整体弹性和交付安全保证的唯一路径。”凯尔说。
 
(早期)对安全性测试的改变也让开发人员受益:在开发新服务或部署更新服务之前,他们并没有发现代码中的明显漏洞,而是经常在开发的早期阶段发现并解决潜在的问题,几乎没有安全人员的介入。
 
SAS首席信息安全官Brian Wilson表示:“正确的做法是,DevSecOps可以将安全性纳入开发生命周期,使开发人员能够更快,更方便地保护应用程序,不会造成安全干扰。
 
Wilson将静态(SAST)和源代码分析(SCA)工具集成到团队的持续交付中,帮助开发人员在代码中对潜在问题,以及第三方依赖的漏洞进行反馈。
 
Wilson说:“开发人员可以主动、反复地缓解app的安全问题,并重新进行安全扫描,无需安全人员参与。DevSecOps还可以帮助开发团队简化更新和修补程序。
 
DevSecOps并不意味着企业不再需要安全专家,就像DevOps并不意味着企业不再需要基础架构专家一样。它只是有助于减少瑕疵进入生产的可能性,或减缓部署。
 

 DevSecOps遭遇的危机
 
来自Sumo Logic公司的Gerchow分享了DevSecOps文化的实例:当最近的Meltdown和Spectre消息出现时,团队的DevSecOps方法能够迅速做出响应,以减轻风险,而对内外部客户没有任何明显的干扰。 对云原生和受高度监管的公司来说非常重要。
 
第一步,Gerchow的小型安全团队(具备开发技能)能够通过Slack与其主要云供应商之一合作,确保基础设施在24小时内完全修补好。
 
 “然后,我的团队立即开始了OS级别的修复,不需要给终端用户停机时间,也无需请求工程师,那样意味着要等待长时间的变更管理流程。所有这些变化都是通过Slack打开自动化Jira tickets进行的,并通过日志和分析解决方案进行监控,“Gerchow解释说。
 
这听起来像DevOps文化,正确的人员、流程和工具组合相匹配,但它明确地将安全作为该文化和组合的一部分。
 
Gerchow说:“在传统环境下,停机需要花费数周或数月的时间,因为开发、运营和安全这三项功能都是孤立的。凭借DevSecOps流程和理念,终端用户可以通过简单的沟通和当天的修复获得无缝的体验。”
 
 
02
2018DevSecOps三大预测
 
2018年企业的DevSecOps将迎来一些真正的变革。
 
对于DevSecOps来说,2017年是美好的一年,DevSecOps从一个半朦胧的概念演变成可行的企业功能。
 
容器和容器市场的迅速扩张在很大程度上推动了这一演变,容器市场本质上与DevOps和DevSecOps相互交织在一起。一般来说,快速增长和创新往往比科学更能预测趋势,但我仍然愿意尝试一下。
 
从Docker Hub和成熟的容器生态系统中获取了超过120亿张图片,就企业的DevSecOps而言,我们几乎看不到冰山的一角。不过,相信在2018年,我们将看到:基础变革的开始。我认为它会是这样的:
 

 >>>>1.企业领导者和IT利益相关者意识到DevSecOps正在改进DevOps
 
DevOps将开发团队和运维团队聚在一起,它推动协作文化不足为奇。加入安全举措可能听起来很简单,但多年来,安全问题一直是事后的事情,导致企业文化容易使安全团队与其他IT团队形成对立,包括开发团队。 
但是事情发生了变化。
在雅虎亏损3.5亿美元的商业环境下,暴露了其脆弱的安全状况,企业领导者将网络安全看作是一个运维sinkhole的时代已经结束。加强网络安全现在是企业的当务之急。但这种转变需要时间才能重新回到IT文化中。
DevOps和DevSecOps的崛起无疑为重塑应用程序安全性创造了一个难得且令人兴奋的机会,但是DevOps可能会导致转变速度发生变化。DevOps团队和应用程序架构师每天都能够认识到安全的重要性,并欢迎安全团队的加入,但他们之间仍然存在需要磨合的鸿沟。
为正确实施DevSecOps,安全团队需要与DevOps团队保持一致,企业领导者需要为此打造空间和预算。到2019年,希望企业领导人能够意识到推动一个重要的、合法的安全胜利的机会。
 

>>>>2.成功的组织模式将会出现,最可能的是,安全与DevOps团队之间的紧密协作。

虽然该预测并不特别具有启发性,但是相关的。了解DevSecOps需要来自安全和DevOps团队的平等协作,快速跟踪标准蓝图或实施模型,将DevSecOps集成(并最终自动化)到CI / CD进程中。
虽然不同企业有不同的需求,但大多数公司都使用相同的技术工具,特别是在使用容器的情况下。这就为统一的标准化提供了条件。此外,容器的开源特性可以促进相关信息的共享和标准开发。
到目前为止,由于DevOps团队拥有开发流程,他们一直在安全方面处于领先地位。然而,我认为,DevSecOps需要由安全团队领导, 他们是负责企业安全和风险的人,当安全事故发生时,他们会被解雇或被迫离开。
2018年,安全团队需要加强并展示团队的价值和技能。将安全性融入到IT结构中,而不是在网络安全问题成为事实之后才想起。现在我们有机会来实现这一目标。
 

>>>>3.安全团队仍然要缓慢适应DevOps的现实

过去,企业安全团队通常在不重视或不了解安全需要的文化中运营。难怪今天的电商环境是大多数企业相对容易被破坏的环境。 
强大的安全性不仅仅是外围的防火墙。尽管许多安全专家可能最终会看到这种转变,但可能不像DevOps团队所期望的那样灵活。当谈到容器(通常是appsec)时,即使是最有才华和最优秀的安全专家也会面临学习的瓶颈。更不用说已经被充分证明的网络安全技能短缺的现状。
虽然这些因素可能在短期内降低安全对DevOps和 DevSecOps的支持,但是我认为DevSecOps是解决技能短缺问题的一部分。将安全集成到应用程序交付过程中,并将其自动化比用回溯方法更有效率和更具成本效益,可以解决在部署应用程序之前解决安全漏洞。安全专业人士可以通过开放的态度,以新的方式发挥他们的才能,从而获得很多收益。 
2018年希望这个故事有一个快乐的结局。
 

原文链接:
1、3 predictions for devsecops in 2018https://www.infoworld.com/article/3243155/devops/3-predictions-for-devsecops-in-2018.html2、   Why DevSecOps matters to IT leadershttps://enterprisersproject.com/article/2018/1/why-devsecops-matters-it-leaders
 
 
 
推荐阅读:
企业级落地容器与DevOps,选用K8S都有哪些“姿势”
7大ChatOps&5种团队协作工具助力DevOps实践
如果没按这7种习惯,你可能实践的是假DevOps
这款分布式配置中心,会是微服务的降维打击利器吗?
从架构到组件,深挖istio如何连接、管理和保护微服务2.0?
 
 
添加小数微信:xiaoshu062
备注公司、姓名、职位
小数将拉您进入相应技术群
 
点击数人云了解更多信息 查看全部
 
v2-174b0611f0cdb3c1c3ac4bd4db13a3d3_hd.jpg


DevSecOps可能不是一个优雅的术语,但其结果是有吸引力的: 在开发的早期带来更强大的安全性。DevOps最终是要建立更好的软件,也意味着更安全的软件。
 
像任何IT术语一样,DevSecOps--由DevOps衍生而来,很容易被炒作和盗用。但是这个术语对拥抱DevOps文化的IT领导者以及实现其承诺的实践和工具而言,具有真正的意义。
 

 DevSecOps什么意思?
 
Datic公司首席技术官兼共同创始人RobertReeves说:“DevSecOps是开发,安全和运维的组合。它提醒我们,对于应用程序来说,安全和创建、部署到生产上同样重要。”
 
向非技术人员解释DevSecOps的一个简单方法:它有意识地更早地将安全性融入到开发过程中。
 
红帽安全战略家Kirsten Newcomer 最近告诉我们: “历史上,安全团队从开发团队中分离出来,每个团队都在不同的IT领域拥有深厚的专业知识  。“其实不需要这样。关心安全的企业也非常关心通过软件快速交付业务价值的能力,这些企业正在寻找方法,将安全性留在应用开发生命周期内。通过在整个CI / CD中集成安全实践,工具和自动化来采用DevSecOps。”
 
她说:“为了做到这一点,他们正在整合团队。安全专业人员将从应用开发团队一直嵌入到生产部署中。” “双方都看到了价值,每个团队都拓展了他们的技能和知识基础,成为更有价值的技术专家。正确的DevOps或DevSecOps ,提高IT安全性。”
 
IT团队的任务是更快,更频繁地交付服务。DevOps成为一个很好的推动因素,部分原因是它可以消除开发和运营团队之间的一些传统冲突,Ops通常在部署之前被排除在外,而Dev将其代码丢在无形的墙上,从来不进行二次管理,更没有任何的基础设施维护责任。说得委婉一些,在数字化时代,这种孤立的做法会产生问题。按照Reeves的说法,如果安全是孤立的,也会存在类似的问题。
 
Reeves说:“我们采用DevOps,它被证明可以通过扫除开发与运维之间的障碍来提高IT的性能。“就像不应该等到部署周期结束才开始运维一样,也不应该等到最后才考虑安全问题。”
 

 DevSecOps为什么会出现?
 
将DevSecOps看作是另一个流行语是一种诱惑,但对于安全意识强的IT领导者来说,这是一个实质性的概念。安全必须是软件开发流程中的“一等公民”,而并非最终步骤部署,或者更糟糕,只有在发生实际的安全事件后才受到重视。
SumoLogic公司安全与合规副总裁George Gerchow表示:“DevSecOps不仅仅是一个流行词,由于诸多原因它是IT的当前和未来状态。“最重要的好处是能够将安全性融入到开发和运营流程中,为实现敏捷性和创新提供保障。”
 
此外,在场景中出现的DevSecOps可能是DevOps自身正在成熟并深入挖掘IT内部的另一个标志。
 
“企业DevOps文化意味着开发人员能够以更快的速度向生产环境提供功能和更新,特别是当自组织团队更加乐于协作和衡量结果。”CYBRIC首席技术官兼联合创始人Mike Kail说。
 
在采用DevOps的同时,保持原有的安全实践的团队和公司会遇到更多的管理安全风险的痛苦,因为DevOps团队会部署地更快、更频繁。
 

 手动测试安全方法逐渐落后

 “目前,手动测试安全方法逐渐落后,利用自动化和协作将安全测试转移到软件开发生命周期,从而推动DevSecOps文化,这是IT领导者提高整体弹性和交付安全保证的唯一路径。”凯尔说。
 
(早期)对安全性测试的改变也让开发人员受益:在开发新服务或部署更新服务之前,他们并没有发现代码中的明显漏洞,而是经常在开发的早期阶段发现并解决潜在的问题,几乎没有安全人员的介入。
 
SAS首席信息安全官Brian Wilson表示:“正确的做法是,DevSecOps可以将安全性纳入开发生命周期,使开发人员能够更快,更方便地保护应用程序,不会造成安全干扰。
 
Wilson将静态(SAST)和源代码分析(SCA)工具集成到团队的持续交付中,帮助开发人员在代码中对潜在问题,以及第三方依赖的漏洞进行反馈。
 
Wilson说:“开发人员可以主动、反复地缓解app的安全问题,并重新进行安全扫描,无需安全人员参与。DevSecOps还可以帮助开发团队简化更新和修补程序。
 
DevSecOps并不意味着企业不再需要安全专家,就像DevOps并不意味着企业不再需要基础架构专家一样。它只是有助于减少瑕疵进入生产的可能性,或减缓部署。
 

 DevSecOps遭遇的危机
 
来自Sumo Logic公司的Gerchow分享了DevSecOps文化的实例:当最近的Meltdown和Spectre消息出现时,团队的DevSecOps方法能够迅速做出响应,以减轻风险,而对内外部客户没有任何明显的干扰。 对云原生和受高度监管的公司来说非常重要。
 
第一步,Gerchow的小型安全团队(具备开发技能)能够通过Slack与其主要云供应商之一合作,确保基础设施在24小时内完全修补好。
 
 “然后,我的团队立即开始了OS级别的修复,不需要给终端用户停机时间,也无需请求工程师,那样意味着要等待长时间的变更管理流程。所有这些变化都是通过Slack打开自动化Jira tickets进行的,并通过日志和分析解决方案进行监控,“Gerchow解释说。
 
这听起来像DevOps文化,正确的人员、流程和工具组合相匹配,但它明确地将安全作为该文化和组合的一部分。
 
Gerchow说:“在传统环境下,停机需要花费数周或数月的时间,因为开发、运营和安全这三项功能都是孤立的。凭借DevSecOps流程和理念,终端用户可以通过简单的沟通和当天的修复获得无缝的体验。”
 
 
02
2018DevSecOps三大预测
 
2018年企业的DevSecOps将迎来一些真正的变革。
 
对于DevSecOps来说,2017年是美好的一年,DevSecOps从一个半朦胧的概念演变成可行的企业功能。
 
容器和容器市场的迅速扩张在很大程度上推动了这一演变,容器市场本质上与DevOps和DevSecOps相互交织在一起。一般来说,快速增长和创新往往比科学更能预测趋势,但我仍然愿意尝试一下。
 
从Docker Hub和成熟的容器生态系统中获取了超过120亿张图片,就企业的DevSecOps而言,我们几乎看不到冰山的一角。不过,相信在2018年,我们将看到:基础变革的开始。我认为它会是这样的:
 

 >>>>1.企业领导者和IT利益相关者意识到DevSecOps正在改进DevOps
 
DevOps将开发团队和运维团队聚在一起,它推动协作文化不足为奇。加入安全举措可能听起来很简单,但多年来,安全问题一直是事后的事情,导致企业文化容易使安全团队与其他IT团队形成对立,包括开发团队。 
但是事情发生了变化。
在雅虎亏损3.5亿美元的商业环境下,暴露了其脆弱的安全状况,企业领导者将网络安全看作是一个运维sinkhole的时代已经结束。加强网络安全现在是企业的当务之急。但这种转变需要时间才能重新回到IT文化中。
DevOps和DevSecOps的崛起无疑为重塑应用程序安全性创造了一个难得且令人兴奋的机会,但是DevOps可能会导致转变速度发生变化。DevOps团队和应用程序架构师每天都能够认识到安全的重要性,并欢迎安全团队的加入,但他们之间仍然存在需要磨合的鸿沟。
为正确实施DevSecOps,安全团队需要与DevOps团队保持一致,企业领导者需要为此打造空间和预算。到2019年,希望企业领导人能够意识到推动一个重要的、合法的安全胜利的机会。
 

>>>>2.成功的组织模式将会出现,最可能的是,安全与DevOps团队之间的紧密协作。

虽然该预测并不特别具有启发性,但是相关的。了解DevSecOps需要来自安全和DevOps团队的平等协作,快速跟踪标准蓝图或实施模型,将DevSecOps集成(并最终自动化)到CI / CD进程中。
虽然不同企业有不同的需求,但大多数公司都使用相同的技术工具,特别是在使用容器的情况下。这就为统一的标准化提供了条件。此外,容器的开源特性可以促进相关信息的共享和标准开发。
到目前为止,由于DevOps团队拥有开发流程,他们一直在安全方面处于领先地位。然而,我认为,DevSecOps需要由安全团队领导, 他们是负责企业安全和风险的人,当安全事故发生时,他们会被解雇或被迫离开。
2018年,安全团队需要加强并展示团队的价值和技能。将安全性融入到IT结构中,而不是在网络安全问题成为事实之后才想起。现在我们有机会来实现这一目标。
 

>>>>3.安全团队仍然要缓慢适应DevOps的现实

过去,企业安全团队通常在不重视或不了解安全需要的文化中运营。难怪今天的电商环境是大多数企业相对容易被破坏的环境。 
强大的安全性不仅仅是外围的防火墙。尽管许多安全专家可能最终会看到这种转变,但可能不像DevOps团队所期望的那样灵活。当谈到容器(通常是appsec)时,即使是最有才华和最优秀的安全专家也会面临学习的瓶颈。更不用说已经被充分证明的网络安全技能短缺的现状。
虽然这些因素可能在短期内降低安全对DevOps和 DevSecOps的支持,但是我认为DevSecOps是解决技能短缺问题的一部分。将安全集成到应用程序交付过程中,并将其自动化比用回溯方法更有效率和更具成本效益,可以解决在部署应用程序之前解决安全漏洞。安全专业人士可以通过开放的态度,以新的方式发挥他们的才能,从而获得很多收益。 
2018年希望这个故事有一个快乐的结局。
 

原文链接:
1、3 predictions for devsecops in 2018https://www.infoworld.com/article/3243155/devops/3-predictions-for-devsecops-in-2018.html2、   Why DevSecOps matters to IT leadershttps://enterprisersproject.com/article/2018/1/why-devsecops-matters-it-leaders
 
 
 
推荐阅读:
企业级落地容器与DevOps,选用K8S都有哪些“姿势”
7大ChatOps&5种团队协作工具助力DevOps实践
如果没按这7种习惯,你可能实践的是假DevOps
这款分布式配置中心,会是微服务的降维打击利器吗?
从架构到组件,深挖istio如何连接、管理和保护微服务2.0?
 
 
添加小数微信:xiaoshu062
备注公司、姓名、职位
小数将拉您进入相应技术群
 
点击数人云了解更多信息

微服务迁移前,来听听这6个思考和经验

dataman 发表了文章 • 0 个评论 • 118 次浏览 • 2018-01-30 10:15 • 来自相关话题

 
 
 小数近期为大家推送了不少微服务方面的文章,之前的一份微服务调研报告《微服务2017年度报告出炉:4大客户画像,15%传统企业已领跑》受到广泛关注。今天推送的这篇技术文章,与您再来深入探讨下企业为什么要寻求微服务,会遇到哪些问题,做好哪些准备。


今天,对软件的需求变化比以往任何时候都快。这就要求有一个合适的架构来实现灵活的变更。然而,考虑到Web应用的角度,灵活性往往受到阻碍。随着时间的推移,各种意想不到的依赖关系会使架构看起来像一个大泥球(Big Ball of Mud,BBoM)。


类似BBoM的庞大单体架构显示出的复杂性急剧增加。这需要各个团队之间的协调努力,才不会导致生产力降低。作为对策,企业引入了Scrum敏捷方法来优化他们的软件工程流程。但是,经常缺乏技术自主权。




1、敏捷性和微服务

在敏捷软件开发中,一个理想的架构足够灵活,可以处理快速调整的需求。遵循敏捷宣言的原则,最好的架构以功能需求驱动的方式出现。但架构也需要前期设计的努力,以实现预期的灵活性。由于需求的不确定性,严格的瀑布式的前期大型设计(Big Design Upfront ,BDUF)被忽略了。BDUF不适合大量连贯工作量的敏捷思想,也称为the batch size。


微服务方法限制了batch size,因为每一个微服务只涵盖整个应用的一部分。所有部分共同涵盖不同的业务功能,例如在电商应用中显示产品的详细信息。重要的一点是,单一业务能力的责任转移到一个需要跨职能一致和需要DevOps文化的团队。


因此,微服务是一个模块化的概念,可以解释技术层面和组织层面。这个想法是围绕清晰分离的业务能力建模一个架构,每个业务能力都是作为一个微服务实现的。通过实施自己的架构与系统的其他部分分离,允许建立大规模的软件增量与小型和独立的团队。微服务最适宜的企业是,旨在缩短业务上线时间,但无法应对当前架构和组织结构快速变化需求的那些企业。


向微服务迁移有许多挑战。以下提供了从BBoM引入微服务的几点指南。



2、微服务迁移的六大影响因素

向微服务的迁移可以完全脱离,也依赖于单体(因素1)。关键的决定是,目标架构的微服务是否包含自己的前端(frontend)(因素2)。在这个阶段,技术和组织方面之间的相互作用已经变得明确。当涉及从巨石中分离出第一个微服务时,应该确保底层的新模型不会被旧的破坏(因素3)。运维中的迁移应该考虑风险,并采取适当的措施(因素4)。通过自动化过程来支持(因素5)。把适当的工作放在优先位置。所需的透明度通过敏捷的组织文化来建立。将敏捷转换与微服务迁移结合起来会带来额外的挑战(因素6)。


1改变
人们经常认为,完全重写应用程序是充满风险的。但是这个应用程序的发布并不是以一个Big Bang的方式来完成的。相反,可以选择渐进的方法。但是,巨石应用和微服务一起构成应用程序的“微服务 – 单体 - 混合”架构往往是不可避免的。特别是如果有竞争的压力,新的特性必须不断传递给客户,那么混合是唯一的解决方案。迁移是一个长期的过程,可以持续2年以上。


为了缩短应用程序处于混合状态的时间,建议将迁移视为变化的机会。在这种情况下,改变意味着实施新的要求,而且接受现有功能的遗漏。一方面,考虑迁移的应用程序是旧的应用程序的准确副本,减少迁移工作是明智的。另一方面,提供不适用于旧技术堆栈的新功能增强利益相关方的信任。这种迁移可以视为进步而并非停滞。


2系统分解有两个必须考虑的决定。
首先,是否通过使用现有的代码库或者完全重写功能来提取微服务。
其次,定义目标架构,并且必须做出决定,微服务是自带前端,还是多个微服务集成在一个UI单体中。

当使用现有的代码库时,该代码库的副本就是跳板。那么给定的部分已经表现出高度的自主性。而且,当项目范围局限于较少人数开发应用时,这种方法可能会取得成功。当挑战是将多个团队分离时,建议将微服务定义为自己的前端。


这需要进一步讨论如何解释微服务的层次。关于三层架构,可以区分两种微服务类型。一方面是只包含数据和应用程序层的微服务(图1)。另一方面还有从数据层到表现层的微服务。


当使用“2层微服务”时,在建立前端的这种多微服务时建立了一个UI单体。这带来了将微服务整合到同一个前端的耦合团队的风险。相比之下,提供自己的前端部分的“全栈微服务”(例如UI碎片)则为团队提供了更高程度的自主权(图2)。


3模型边界保护作为一个起点,建议从中等复杂度的单个上下文开始。这样做的时候,保护即将实现这个上下文的微服务底层模型很重要。因此,应该规定一条规则,即禁止通过数据层访问(如JDBC或直接API调用)从整体数据访问数据。相反,数据应该从后台异步传输到后台的微服务,同时还要在新旧模式之间进行转换。这可以看作两个数据存储的同步,并符合构建防腐层(ACL)的思想,这是一个域驱动设计(DDD)的概念。在这种情况下,ACL可以作为微服务和巨石的模型完整性保护器(图3)。

风险监测任何迁移都有风险。特别是在进行完全重写时,如果新应用程序与现有应用程序相比得到相同的结果,则应使用与业务相关的度量标准(如营业额)进行衡量。然后,通过逐渐将新应用交付给越来越多的客户,控制经济风险。在这一点上,应该考虑诸如Canary Releasing的部署策略。


另外,建议在生产环境中测试微服务,然后再将其推广给客户。这可以通过向微服务提供请求并完全观察他们的行为Shadow Traffic来实现。性能问题可以在不影响应用程序的情况下展开,因为各自的响应被省略。这种做法是由两位专家和文献描述的。


其他措施也可以支持降低云服务迁移过程中的风险。使用诸如特性切换之类的机制在旧的和新的实现之间切换。它们提供了灵活性,仅通过更改配置来控制这一点,而无需重新部署整个应用程序。


5自动化和测试为了减少TTM(上市时间),作为微服务的部署流水线,建议将价值流建模和自动化。在这里,要考虑从代码提交到部署构建的每一步。这确保部署可以经常进行。此外,这从一开始就支持高度的测试覆盖,因为测试也是该流水线的一部分。


在考虑自动化测试时,专家会参考所谓的自动化测试金字塔。测试金字塔由三个测试层组成:单元,服务和UI测试。每层测试的数量减少,导致金字塔形状--许多单元测试和少量UI测试。为了确保多个微服务如预期的那样相互整合,依靠UI测试是合理的。但UI测试对于开发和维护来说是脆弱和昂贵的。这就是为什么在没有UI的情况下单独进行测试非常重要:使用模拟对象自主地测试微服务。借助模拟对象,可以模拟与其他微服务或巨石应用的交互。相应的测试被称为,自动测试金字塔内的服务级别测试。


6敏捷转型引入敏捷方法并立即迁移到微服务是巨大的变化。因此,建议将其分成几个步骤,并寻求逐渐改变。否则动机和定向障碍的风险太高。通过引入Scrum这样的敏捷方法,理想的微服务出现,是随着时间的推移争取团队的自主性。

尽管Scrum主要是在一个跨职能和以产品为中心的团队中解决软件开发过程,大规模的组织也需要采用。Scrum没有提供解决多个敏捷团队协调的解决方案。还有一些坚定的观点认为,对于大型项目来说,应该避免使用灵活的方法来分割产品。随着时间的推移,出现了不同的Scrum和敏捷方法扩展方法。例如,LeSS(大规模Scrum),Nexus和SAFe(缩放敏捷框架)是根据其市场份额为大型组织提供敏捷性的相关方法。


在更大的组织环境中建立敏捷方法时,建议先从一个团队开始,然后再增加越来越多的团队。同样在LeSS中,这被描述为耗时,但却是以功能为中心的团队,同时打破功能孤岛的安全方式。




透明度

此外建议记录产生的非功能性工作,例如在积压工作中实施ACL,并合理安排其他要求。在SAFe中,引入了可以代表上述技术和机制的实施以及迁移工作的推动者的故事。它们确保了透明度,展现了业务与IT之间潜在的相互依赖关系。因此,应根据2位专家的建议,与企业和技术负责人进行优先排序。

图4:敏捷和微服务之路



3、总结

微服务包含组织层面和技术方面。这就是为什么引入微服务涉及两种情况下的措施。如果没有单体考虑,微服务的好处是脆弱的。从纯粹的技术角度来看,微服务可以使用瀑布式软件工程方法来实现。但是,为了充分发挥每个微服务的自主性,它们被嵌入到敏捷文化中。


特别是,拥有多个团队的组织可以从微服务的非技术方面获益。从数据层向前端分解一个系统,将团队分离开来。因此,如果多个团队使用一个前端开发应用程序,那么团队边界在架构中反映最好。这些团队可以自主地加速应用程序的部分。在单体应用程序和分层的团队中,这是更困难的。在这里,复杂的依赖需要协调跨越团队边界的活动。因此TTM下降。


由于敏捷团队由开发人员和非技术人员组成,因此IT和业务需要携手合作。微服务的出现是由于敏捷团队争取自主权。当团队决定转向微服务时,迁移本身没有任何价值,可以向客户交付新功能。尽管如此,微服务迁移工作仍需要优先考虑。这需要透明度。只有不断提高透明度,敏捷性和微服务才能彼此加速。否则,长期不会降低TTM的风险很高。


为了避免在引入微服务时构建未来的传统软件,建立敏捷思维和不断重新思考解决方案很重要。


原文链接:
6 Things to Consider for Microservice Migration

  查看全部

v2-342dd117dd4cd06bde68a2b67dc3857e_hd.jpg

 
 
 小数近期为大家推送了不少微服务方面的文章,之前的一份微服务调研报告《微服务2017年度报告出炉:4大客户画像,15%传统企业已领跑》受到广泛关注。今天推送的这篇技术文章,与您再来深入探讨下企业为什么要寻求微服务,会遇到哪些问题,做好哪些准备。


今天,对软件的需求变化比以往任何时候都快。这就要求有一个合适的架构来实现灵活的变更。然而,考虑到Web应用的角度,灵活性往往受到阻碍。随着时间的推移,各种意想不到的依赖关系会使架构看起来像一个大泥球(Big Ball of Mud,BBoM)。


类似BBoM的庞大单体架构显示出的复杂性急剧增加。这需要各个团队之间的协调努力,才不会导致生产力降低。作为对策,企业引入了Scrum敏捷方法来优化他们的软件工程流程。但是,经常缺乏技术自主权。




1、敏捷性和微服务

在敏捷软件开发中,一个理想的架构足够灵活,可以处理快速调整的需求。遵循敏捷宣言的原则,最好的架构以功能需求驱动的方式出现。但架构也需要前期设计的努力,以实现预期的灵活性。由于需求的不确定性,严格的瀑布式的前期大型设计(Big Design Upfront ,BDUF)被忽略了。BDUF不适合大量连贯工作量的敏捷思想,也称为the batch size。


微服务方法限制了batch size,因为每一个微服务只涵盖整个应用的一部分。所有部分共同涵盖不同的业务功能,例如在电商应用中显示产品的详细信息。重要的一点是,单一业务能力的责任转移到一个需要跨职能一致和需要DevOps文化的团队。


因此,微服务是一个模块化的概念,可以解释技术层面和组织层面。这个想法是围绕清晰分离的业务能力建模一个架构,每个业务能力都是作为一个微服务实现的。通过实施自己的架构与系统的其他部分分离,允许建立大规模的软件增量与小型和独立的团队。微服务最适宜的企业是,旨在缩短业务上线时间,但无法应对当前架构和组织结构快速变化需求的那些企业。


向微服务迁移有许多挑战。以下提供了从BBoM引入微服务的几点指南。



2、微服务迁移的六大影响因素

向微服务的迁移可以完全脱离,也依赖于单体(因素1)。关键的决定是,目标架构的微服务是否包含自己的前端(frontend)(因素2)。在这个阶段,技术和组织方面之间的相互作用已经变得明确。当涉及从巨石中分离出第一个微服务时,应该确保底层的新模型不会被旧的破坏(因素3)。运维中的迁移应该考虑风险,并采取适当的措施(因素4)。通过自动化过程来支持(因素5)。把适当的工作放在优先位置。所需的透明度通过敏捷的组织文化来建立。将敏捷转换与微服务迁移结合起来会带来额外的挑战(因素6)。


1改变
人们经常认为,完全重写应用程序是充满风险的。但是这个应用程序的发布并不是以一个Big Bang的方式来完成的。相反,可以选择渐进的方法。但是,巨石应用和微服务一起构成应用程序的“微服务 – 单体 - 混合”架构往往是不可避免的。特别是如果有竞争的压力,新的特性必须不断传递给客户,那么混合是唯一的解决方案。迁移是一个长期的过程,可以持续2年以上。


为了缩短应用程序处于混合状态的时间,建议将迁移视为变化的机会。在这种情况下,改变意味着实施新的要求,而且接受现有功能的遗漏。一方面,考虑迁移的应用程序是旧的应用程序的准确副本,减少迁移工作是明智的。另一方面,提供不适用于旧技术堆栈的新功能增强利益相关方的信任。这种迁移可以视为进步而并非停滞。


2系统分解有两个必须考虑的决定。
首先,是否通过使用现有的代码库或者完全重写功能来提取微服务。
其次,定义目标架构,并且必须做出决定,微服务是自带前端,还是多个微服务集成在一个UI单体中。

当使用现有的代码库时,该代码库的副本就是跳板。那么给定的部分已经表现出高度的自主性。而且,当项目范围局限于较少人数开发应用时,这种方法可能会取得成功。当挑战是将多个团队分离时,建议将微服务定义为自己的前端。


这需要进一步讨论如何解释微服务的层次。关于三层架构,可以区分两种微服务类型。一方面是只包含数据和应用程序层的微服务(图1)。另一方面还有从数据层到表现层的微服务。


当使用“2层微服务”时,在建立前端的这种多微服务时建立了一个UI单体。这带来了将微服务整合到同一个前端的耦合团队的风险。相比之下,提供自己的前端部分的“全栈微服务”(例如UI碎片)则为团队提供了更高程度的自主权(图2)。


3模型边界保护作为一个起点,建议从中等复杂度的单个上下文开始。这样做的时候,保护即将实现这个上下文的微服务底层模型很重要。因此,应该规定一条规则,即禁止通过数据层访问(如JDBC或直接API调用)从整体数据访问数据。相反,数据应该从后台异步传输到后台的微服务,同时还要在新旧模式之间进行转换。这可以看作两个数据存储的同步,并符合构建防腐层(ACL)的思想,这是一个域驱动设计(DDD)的概念。在这种情况下,ACL可以作为微服务和巨石的模型完整性保护器(图3)。

风险监测任何迁移都有风险。特别是在进行完全重写时,如果新应用程序与现有应用程序相比得到相同的结果,则应使用与业务相关的度量标准(如营业额)进行衡量。然后,通过逐渐将新应用交付给越来越多的客户,控制经济风险。在这一点上,应该考虑诸如Canary Releasing的部署策略。


另外,建议在生产环境中测试微服务,然后再将其推广给客户。这可以通过向微服务提供请求并完全观察他们的行为Shadow Traffic来实现。性能问题可以在不影响应用程序的情况下展开,因为各自的响应被省略。这种做法是由两位专家和文献描述的。


其他措施也可以支持降低云服务迁移过程中的风险。使用诸如特性切换之类的机制在旧的和新的实现之间切换。它们提供了灵活性,仅通过更改配置来控制这一点,而无需重新部署整个应用程序。


5自动化和测试为了减少TTM(上市时间),作为微服务的部署流水线,建议将价值流建模和自动化。在这里,要考虑从代码提交到部署构建的每一步。这确保部署可以经常进行。此外,这从一开始就支持高度的测试覆盖,因为测试也是该流水线的一部分。


在考虑自动化测试时,专家会参考所谓的自动化测试金字塔。测试金字塔由三个测试层组成:单元,服务和UI测试。每层测试的数量减少,导致金字塔形状--许多单元测试和少量UI测试。为了确保多个微服务如预期的那样相互整合,依靠UI测试是合理的。但UI测试对于开发和维护来说是脆弱和昂贵的。这就是为什么在没有UI的情况下单独进行测试非常重要:使用模拟对象自主地测试微服务。借助模拟对象,可以模拟与其他微服务或巨石应用的交互。相应的测试被称为,自动测试金字塔内的服务级别测试。


6敏捷转型引入敏捷方法并立即迁移到微服务是巨大的变化。因此,建议将其分成几个步骤,并寻求逐渐改变。否则动机和定向障碍的风险太高。通过引入Scrum这样的敏捷方法,理想的微服务出现,是随着时间的推移争取团队的自主性。

尽管Scrum主要是在一个跨职能和以产品为中心的团队中解决软件开发过程,大规模的组织也需要采用。Scrum没有提供解决多个敏捷团队协调的解决方案。还有一些坚定的观点认为,对于大型项目来说,应该避免使用灵活的方法来分割产品。随着时间的推移,出现了不同的Scrum和敏捷方法扩展方法。例如,LeSS(大规模Scrum),Nexus和SAFe(缩放敏捷框架)是根据其市场份额为大型组织提供敏捷性的相关方法。


在更大的组织环境中建立敏捷方法时,建议先从一个团队开始,然后再增加越来越多的团队。同样在LeSS中,这被描述为耗时,但却是以功能为中心的团队,同时打破功能孤岛的安全方式。




透明度

此外建议记录产生的非功能性工作,例如在积压工作中实施ACL,并合理安排其他要求。在SAFe中,引入了可以代表上述技术和机制的实施以及迁移工作的推动者的故事。它们确保了透明度,展现了业务与IT之间潜在的相互依赖关系。因此,应根据2位专家的建议,与企业和技术负责人进行优先排序。

图4:敏捷和微服务之路



3、总结

微服务包含组织层面和技术方面。这就是为什么引入微服务涉及两种情况下的措施。如果没有单体考虑,微服务的好处是脆弱的。从纯粹的技术角度来看,微服务可以使用瀑布式软件工程方法来实现。但是,为了充分发挥每个微服务的自主性,它们被嵌入到敏捷文化中。


特别是,拥有多个团队的组织可以从微服务的非技术方面获益。从数据层向前端分解一个系统,将团队分离开来。因此,如果多个团队使用一个前端开发应用程序,那么团队边界在架构中反映最好。这些团队可以自主地加速应用程序的部分。在单体应用程序和分层的团队中,这是更困难的。在这里,复杂的依赖需要协调跨越团队边界的活动。因此TTM下降。


由于敏捷团队由开发人员和非技术人员组成,因此IT和业务需要携手合作。微服务的出现是由于敏捷团队争取自主权。当团队决定转向微服务时,迁移本身没有任何价值,可以向客户交付新功能。尽管如此,微服务迁移工作仍需要优先考虑。这需要透明度。只有不断提高透明度,敏捷性和微服务才能彼此加速。否则,长期不会降低TTM的风险很高。


为了避免在引入微服务时构建未来的传统软件,建立敏捷思维和不断重新思考解决方案很重要。


原文链接:
6 Things to Consider for Microservice Migration

 

微服务落地践行渐进,4个Q&A一窥金融微服务现状

杨y 发表了文章 • 0 个评论 • 133 次浏览 • 2018-01-18 00:47 • 来自相关话题

1月13日,中国双态运维用户大会在北京举办。来自银行、保险、证券、政府、央企等多个行业的330多位企业用户参加,其中工商银行信息科技部副总经理张艳,国泰君安信息技术部总经理俞枫、海关总署科技发展司运行安全处处长张芳、平安科技系统运营部总经理陈亚殊等分别发表了演讲。本文为数人云CEO王璞在双态运维用户大会DevOps、容器与微服务分论坛上的演讲实录。演讲结束,与在座金融客户展开了精彩的Q&A分享。

容器、微服务、DevOps三者,业内的共识是密不可分。没有微服务,DevOps落地不下去,没有容器,DevOps也无法真正实现敏捷运维、自动化运维。DevOps、容器、微服务为更好的构建PaaS提供了方法论和技术手段。

1、PaaS之承上启下

PaaS作为云计算的承上启下要素,向上支撑各环境应用,向下跟IaaS、计算环境、计算资源对接,是企业云化的必由之路。>>>>PaaS三大技术趋势

1.应用容器化,容器正在成为云计算原生应用的标准交付方式。

2.微服务网格化,随着企业对微服务的认知越来越深入,下一代微服务着重把应用管理作为核心。因为企业应用一定要有很强的管理在微服务架构上,不能让应用去“裸奔”。数人云没有提微服务化,因为微服务化已经是不争的事实。应用微服务缺乏强大的管理,需要服务网格这样的下一代微服务技术。

3.行业生态化,PaaS技术本质上是支持应用的,应用跟业务紧密结合,所以PaaS最终是要和业务层面融合,行业需要生态化。>>>>PaaS落地三大要素:

PaaS要在企业客户方面落地不可或缺三要素:规模化、统一化、标准化。企业客户落地云计算平台、技术,本质上是希望提高效率,对业务有更好的敏捷支撑。

所有应用,比如容器应用、微服务应用,都实现标准化。标准化以后进行统一化管理,包括部署、发布、故障恢复、监控告警等都实现统一化管理。最后实现模块化,整个系统都是轻量的,微小模块化的。只有基于这三点的PaaS平台和云计算平台,才能够让IT系统真正实现敏捷轻量,提高IT对业务支撑的效果。

2、企业IT架构转型之开发&运维

企业客户目前在架构转型应用中面临的现状是,企业里大量传统应用,客户希望先实现轻量的单体架构,即摆脱很多中间件,摆脱外部服务,MVC架构、单体复杂架构等首先实现轻量化。

数人云日常接触的客户中,走的比较靠前的客户已经在用Spring Cloud、Dubbo等架构,部分客户相当数量的应用已经微服务化,不过处于中间状态,正在考虑评估微服务架构的客户比例还是最大。总之,企业目前的现状是为服务应用、轻量单体应用,以及传统的巨石应用并存。

在架构转型过程中,正确和常态的路径一定是一步步走过来,而不是传统架构丢掉直接上微服务。>>>>DevOps和容器@轻量单体应用架构

在单体应用架构下,DevOps、容器帮助企业实现敏捷IT。首先,持续集成持续交付CI/CD,只要应用是相对轻量的,就能加快中间件应用。CI/CD其中重要的一点是变更发布管理。


数人云某客户上了容器的应用都是轻量化的,基于 Tomcat 和微服务的应用。当基于容器实现快速发布以后,企业发现,所有发布里有一半的发布失败是由于配置不正确引起的。所以,如果没有发布变更管理,发布失败的中间环节有方方面面的因素。

当基于容器实现快速发布之后,容器对环境的异构做了一层屏蔽,这时如果出现处理的问题就是配置管理的问题了,由于涉及不同的环境和应用,配置环境变成应用发布很容易出错的环节。>>>>DevOps和容器@微服务应用架构

数人云做了企业客户微服务落地状况的调研(微服务2017年度报告出炉:4大客户画像,15%传统企业已领跑),在报告中,有15%左右的企业引入了Spring Cloud、Dubbo。微服务在企业里首当其冲的是敏捷开发,因为微服务是一种切实的敏捷开发的方法。


敏捷开发在IT界已经推广多年,但很多时候敏捷开发推的都是方法论,比如Scrum。微服务是一套切实能够落地到IT人员、开发人员开发过程中的实践方法,这是微服务首当其冲的好处,很多企业的开发部门对微服务非常欢迎。不过,15%还是偏小的一个采用比例,微服务还不是企业客户主流的IT架构。

开发人员都比较欢迎微服务,因为能够提升开发效率,落地敏捷开发,但微服务的阻碍还是不小的,微服务对开发运维来说,带来的复杂度急剧上升。传统运维管理的服务器数量、应用数量有限。企业决定采用微服务本身就表明业务很复杂,单体应用做传统的瀑布式开发效率太低,微服务将应用拆分成较小的模块,因此微服务应用一旦上线,程序的数量呈现爆炸式增长。


例如,数人云某个传统企业的客户,目前部署了微服务相关的应用,基于Spring Cloud、Spring Boot,跑在几千个容器上,几千个容器如果通过传统运维方式去管理的话几乎是不可能的。这就是很多微服务无法落地的原因——很多企业客户缺乏相应的运维能力,没有相应的平台、工具、方式、方法管理微服务应用。
 
>>>>微服务落地的必要条件


微服务应用落地,首当其冲是配套工具链的完善。开发人员采用微服务的影响相对改变小一些。采用SpringCloud或者Dubbo、gRPC等,只是开发框架上的并更。其他开发流程如代码托管、代码审查、测试等并不涉及,所以开发流程相对简单。但微服务对运维功能的要求就会复杂,相应的快速配置能力、完备的监控能力、快速部署能力等对传统运维来说都是缺失的,容器能够补足这方面的能力,让运维部门具有DevOps的能力。

关于微服务的拆分,其实是业务部门需要真正解决的问题。微服务对组织上也有变更,将团队化整为零。通常每个单独的微服务程序都由7-10人的小团队来负责维护,这些都是微服务落地的必要条件。
 
对于数人云来说,直接能够给客户提供的帮助,首先是工具链方面,数人云产品层面具备丰富的微服务配套工具链,从监控、日志、调度、故障自动化修复等等都有完备的工具链。在落地方法上,数人云搭建了自己的生态圈,和很多合作伙伴合作,例如跟埃森哲公司在合作,帮助企业客户落地微服务,进行业务的梳理。
 
>>>>容器和微服务共生


容器技术补齐了微服务相关的工具链,对企业全面向云计算转型提供了很大帮助。应用架构是微服务分布式的,相应的运维也要有自动化、敏捷运维的能力。微服务跑在容器上才能发挥它最好的特性。容器是目前最流行的应用环境,基于容器的微服务部署和更新更快,更轻量,服务之间的调用、服务发现、负载均衡等更灵活。


不过,微服务不是万能的。简单的业务场景单体应用其实足够,微服务一定是应用在复杂的业务场景下,只有复杂的业务场景才有很大的维护成本、维护压力,微服务是用来降低复杂业务场景的维护成本。>>>>基于容器云的微服务运行时管理体系

一个完整的微服务管理体系,除了开发框架之外,对运维部门来说,运维微服务应用最基本的路由、负载均衡等功能,容器可以提供,不过容器提供的只是一部分跟微服务相关的能力和工具链。周围还有一大批需要配套的工具,比如配置管理、API网关、注册发现、应用监控等等。这里的监控不是容器CPU内存的监控,而是业务逻辑的监控,更准确一点是全链路跟踪的全链路监控。容器满足了微服务运行时管理的需求,不过周边许多权限、网关、配置等尚无余力满足。

>>>>统一配置中心是微服务体系的核心

统一配置管理,是微服务落地时很核心的点。要在平台工具上落地微服务首先要具备快速配置能力,因为客户采用微服务和容器平台以后,很快会发现50%以上的发布失败是因为配置没搞对,因此配置管理是微服务里首当其冲的问题。

因为每个企业客户都有开发环境、测试环境、生产环境等很多环境,同一个应用不同版本在不同环境下的配置不同。几何级数的配置项、配置元素的增长会导致配置管理的复杂度急剧上升,需要统一的配置中心进行管理。数人云在帮助企业客户落地微服务时,首先会做的是把配置搞定,没有灵活快速的配置管理能力,微服务运行不起来。
 
>>>>变更发布管理(灰度发布 v.s. 蓝绿部署)

在发布管理方面,数人云帮助企业落地的发布管理主要是蓝绿部署,因为很多企业的应用本身不支持灰度发布。蓝绿部署也是切切实实的快速发布,发布用变更窗口的方式来实现。

例如,周五晚上12点起进行发布变更,12点就要停服务中心。蓝绿部署可以显著地缩短服务不可用的变更窗口。怎么做呢?客户在线上有两个版本,蓝版本和绿版本。现在负载均衡器将流量指向对外提供服务的绿版本,蓝版本作为备用的方案。同时,新程序往蓝版本上部署推送,更新时只需要把流量切换到蓝版本。发布流程最后简化为只需要进行流量的切换。流量可以快速切换,中间的窗口期只有短短几分钟,如果流量切换过来一切正常发布即完成,如果流量切换过来发现问题,可以再将流量切回去。这样开发人员、运维人员不必当场熬夜去修复,极大地减轻了发布的压力。

传统发布方式下,每次变更窗口有好几个应用排队发布,一个应用发布完成后才可以发布下一个应用,一旦中间某一个应用发布失败现场修复的压力非常大,短短的发布窗口需要几个小时内完成抢修,非常不可控,团队经常需要晚上熬夜排队。而结果往往等了半天,前面的应用没发布成功,后面的还得继续排队等。

3、金融行业之践行渐进

数人云在金融、能源、制造、快消、政企等行业的基础上,继续深耕强监管、强安全,高复杂度的金融行业。以某商业银行为例,数人云帮助落地了大规模微服务容器平台。该商业银行近年来互联网业务发展迅猛,原有系统架构无法支撑其未来规划。2016年6月开始全面实施应用微服务化,已实现蓝绿发布。


首先,营销系统全部是轻量化的应用,基于Spring Boot、Tomcat、SpringCloud等,跑在容器平台上。该银行对外营销频次非常高,通过线上微信公众号、手机APP、线上门户、合作伙伴等渠道,每月对外营销达上百场。

每次营销活动或多或少都对IT系统有变更,哪怕是配置变更,因此每次营销活动对IT系统都是一次不小的挑战。发布的时候仅仅靠容器是不够的,需要实现模板的批量发布。每次发布看起来只是一个个的容器程序,实则不然,其实是一组组一批批的容器,只有帮客户做到批量的应用发布,才能显著提升发布效率。

蓝绿部署方面,该银行密集的线上营销中,每一天会有一个重点营销活动,那么营销活动的流量如何分到特别的人群、区域?在后台应用的上千个实例中,并不是每一个实例都分配同等的流量,要通过流量分发,做线上流量控制。数人云借鉴Google做灰度发布的方式为客户提供图形化的流量控制,这和微服务实施后的限流分流是息息相关的。

另外,该银行客户的数据流量非常大,对日志收集带来非常大的的压力。数人云建议客户将应用程序的日志全部交给Kafka采集,Kafka可以做到很大数据流量的分布式消息应用。

分布式数据传输分布式消息应用很难保证每一个消息都可靠地传递。Kafka有两种模式:一种保证消息传递至少一次,但也可能多次,对很大的日志量来说偶尔丢一两条可以忽略不计。Kafka的并发量很大,可能带来偶尔很小的数据量丢失,也可能带来日志的乱序,这在分布式系统下都是可以容忍的,“鱼和熊掌不可兼得”。

关于快速建立支撑微服务体系,数人云有几点总结:
 
1.开发框架不能用重量级的应用体系,要么是轻量化单体架构的Tomcat等,要么采用Spring Cloud等微服务架构。

2.要有微服务平台,具备快速配置管理能力、部署能力、监控能力、应用管理能力等配套管理能力。很多企业的痛点是,开发人员快速学习微服务开发技术,基于Spring Cloud做业务系统后,业务系统无法上线,因为运维部门缺乏配套的工具、平台支撑微服务线上运行管理。

3.DevOps融合,平台管理需要把链条全打通,实现快速发布、快速上线、自动修复等。容器经过几年的普及企业已经相对了解,但容器本身是纯技术平台,基于容器、DevOps的落地还有很长的路要走。>>>>数人云微服务On PaaS 产品体系


数人云现在的重点是微服务、轻量单体应用。以前数人云帮企业客户落地重应用的容器平台,但后来发现价值不大,反而对企业来说,除了维护重的应用外还需要维护容器,容器平台并不能实现自动化运维。经过几年的实践和摸索,数人云跟企业客户达成的共识是,传统应用不经过改造无法上到云PaaS平台。

 轻量架构下的应用如何基于PaaS平台支撑?以敏捷开发为例,企业客户通常选择 Spring Cloud、gRPC 等主流的开发框架,然后在微服务工具链层面配置监控、报警、部署、快速发布等方方面面的能力,最下面承载的则是容器平台。


数人云现在还可以帮助客户落地服务网格化技术。它能够进行异构架构的兼容,gRPC就是服务网格的一部分,Google推的 Istio,Linkerd的Kubernetes 都支持 gRPC,gRPC成为通讯协议的一部分。基于通讯协议相应周边的管理,在服务网格这一层可以做灰度发布、A/B测试、流量控制、高级熔断、加密、白/黑名单机制、权限访问控制等等。


服务网格被称作下一代的微服务,因为用了服务网格以后,所有微服务管理的诉求都自动化地满足了。80%-90%的应用管理需求都在服务网格里自动涵盖。这对开发人员来讲,微服务开发的门槛急剧降低,不需要考虑未来应用上线时流量控制、灰度发布等等,只需要考虑业务。数人云微服务On PaaS 目的就是帮助企业客户降低微服务架构、上云转型的门槛。


 Q&A
 
Q1:感觉对DevOps的理解不太到位,能不能具体地讲一下?A1:DevOps准确来讲,现在业内还没有统一的认识。互联网公司的DevOps目前是比较统一的,比如Goolge,但是互联网公司的DevOps,我个人理解没办法在企业直接落地。




在Google,程序员不止要负责应用的开发,还要负责相应的测试,单元测试、集成测试等等。另外,应用的部署、发布、上线也是开发人员自己做。所以互联网公司讲DevOps,更多讲的是开发运维的融合。我之前在Google时,不仅要做代码开发,也要把测试的代码全写出来。

Google有一个理念,开发人员每写一行业务代码,测试代码要写十行。然后,开发人员利用各种发布平台定期发布,比如每周做发布,在Google 运维的人员叫“SRE”。SRE部门准备好各种平台,开发人员可以用这些平台做发布、监控、日志管理等工作。

Google目前有三万名左右的IT人员,其中SRE的运维人员只有一千多,比例很低。所以在Google运维人员不可能帮每一个开发人员或者业务部门做上线。像传统IT开发人员提工单给运维,在Google是不可能的。Google这种做法,它让开发做更多的事情,运维人员很少,只是负责维护平台。所以,Google一千多人管理着几百万台服务器,平均每人管两千台。


但传统企业目前不是这样,传统企业开发和运维之间壁垒比较大。数人云帮助客户落地DevOps 时,基于的理念是,不要破坏现有开发的流程。DevOps应该是开发和运维深度融合才能做到的。讲DevOps,首先要讲理念、组织的变革,但是要想把文化变革、组织变革打破要很长时间。

从落地的角度,DevOps更多落地在运维部门,很具象的工作就是,帮助运维部门去实现DevOps的能力,比如快速部署、快速上线,应用的快速配置,自动化管理能力、故障的自动化处理等等。把以前的运维工作尽可能的自动化,提高效率,这是狭义的DevOps理念,也是我们现在接触到的。数人云不会帮客户落地像互联网公司那样的DevOps,开发做很多事情,运维可做的很少,并不是这样的。

Q2:微服务适合复杂的场景,那么一个简单的促销是不是适合?微服务有多“微”呢?微服务和ESB 服务相比,有什么差别?A2:第一个促销场景,促销场景本身有些条件,促销很重要一点就是必须特别频繁,促销内容在平台要发生变化。比如,今天的促销内容和明天的不太一样,或者这周的促销和下周的不太一样,业务平台需要频繁变更,这时候微服务是适合的。

因为微服务是一种敏捷开发的落地实践方法,只要业务频繁变更,对开发的要求就必须敏捷开发,快速实现。所以,只要业务场景在不停地快速变化,促销又是互联网线上的方式,肯定是适合的。

关于复杂性,如果业务逻辑简单,逻辑变化少,并不适合微服务。比如数人云和很多银行客户合作,银行核心系统很复杂,但是银行系统并不是需求频繁变化的场景。很多银行在做“瘦核心系统”,就是银行核心系统的功能越来越单一,越来越瘦,并不是把复杂的周边的业务也放到银行核心系统里。银行核心系统虽然复杂,但业务不会频繁变化,也不一定要上到微服务场景下。复杂的业务系统,业务需求又不停变化,这种场景适合微服务。

第二个问题是和ESB 比,服务网格和 ESB 有很多相像的地方。ESB有业务逻辑串起来,很多不同的业务系统都上到ESB,互相的权限通过ESB打通。从功能角度讲,ESB和服务网格之间很相像,不同点在于ESB是传统架构下的,并没有考虑频繁迭代、流量集中爆发等问题。


但是微服务情况下,整个之间的互相请求、依赖、通讯等等都会进行统一的管理,这种情况下也很像ESB把不同业务之间的流量进行统一管理,但是服务网格更看重的是面向大规模的控制,那流量突发怎么做限流,或者突然故障怎么做熔断等等。最本质的问题是类似的,但是具体的问题表象和需求不同。

Q3:在实际部署过程中,PaaS平台在底层资源的调用一定要用分布式云架构,传统主机是否可以?两者在最后效果上有没有什么异同?A3:数人云当初两种情况都有,有些场景比如业务量比较大,企业客户为了减少复杂度,容器PaaS平台直接落地到物理服务器上。还有客户为了方便管理,把PaaS落地到IaaS上,两种情况都有。

这其中的考虑是,首先业务量大如果再引入虚拟化这一层会引来额外的复杂度,此时用物理服务器更好。其次,客户有很大规模的物理服务器,直接在上面部署PaaS,在物理服务器上去调用。


第三种,资源动态的调整或资源频繁调配,这个场景很常见,需要IaaS。比如银行客户,内部业务系统分不同的域,不同域的业务复杂性随时间变化经常会发生变化,需要不停地做资源动态的调整。如果用物理机太麻烦,企业客户会选择下面有一层IaaS来做。

基于PaaS也能做一部分的资源动态调配,但是调配维度不同。数人云帮客户落地PaaS时会做资源的整合。从划分的维度,PaaS平台是按照应用程序来划分,IaaS的资源划分是按照业务系统。

Q4:微服务重新开发,最佳的开发框架或者实践有什么可以分享的?第二,旧有的系统改造到微服务这块有没有什么经验?第三,DevOps以前也有很多像敏捷开发的方法论,它们之间有没有什么关系?A4:首先第一个问题,微服务的开发框架。企业客户在做选择时都希望降低风险,选最主流的框架,现在看最主流的开发框架就是Spring cloud,这也是业界的自然选择结果。其他语言也都有些微服务开发,但是用的人少一些。如果是Java应用,目前比较好的选择是Spring Cloud,也有很多客户用了Dubbo,其他架构都是偏小众的架构,主要还是看客户自己的需求。

第二个问题,传统业务要转到微服务架构上,一定要循序渐进。比如Java应用,首先Java中间件的应用,先脱掉,不要再基于这么重的Java中间件。目前相对流行的是Spring Boot这套逻辑。

有了轻量的单体化应用之后(基于Tomcat),往后走基于微服务的框架,上到Spring Boot,再上到Spring Cloud,这是比较平滑的方式。Spring Boot 在很企业客户中用的非常多,是很方便的一套单体开发架构。

企业客户目前的现状是老的应用很多,不会一次就改造完,传统的应用可以先选择一部分容易转的转到轻量单体架构上,然后再转到微服务框架上。目前企业客户是轻量的单体架构、微服务架构,以及大量传统的架构应用并存。老的架构应用目前上不到PaaS平台,只有轻量的单体化加微服务应用才能上到PaaS平台。

现在业内的共识是,微服务、容器、DevOps这三者是密不可分的。微服务更多是针对开发人员,是一种真正落地的云开发方法。很多企业客户也讲敏捷开发,派团队成员学习敏捷开发的方法论,但是敏捷开发仍然无法在企业当中落地。

这是因为,只学会了方法,但没办法落地到具体的编程,即开发环节上去,自然没办法做到敏捷开发。很多开发者回来写的程序依然是J2EE。J2EE 编程的理念和方法并不是敏捷开发的,是偏向于瀑布式的。

微服务是具体的开发环节上的敏捷开发方法,开发能力化整为零,每个团队做简单、具象、单一的逻辑。微服务首先是一个具像的敏捷开发方法,实践方法。

微服务在落地时,比如程序运行时,复杂度很高,因为不是一个程序,是一批程序一起运行,对运维的管理就比较复杂,这时候可以利用容器实现微服务应用的自动化管理。微服务一般都会上到容器,因为微服务应用不再是单体的部署方式,不再是部署到Java中间件上。基于微服务架构,几百个进程进来,用容器的方式实现快速部署动态调度,微服务部署到容器上,实现基础的轻量化运维。


轻量化运维,快速部署、自动化调度,逐步往DevOps方向走。DevOps更多强调自动化的运维能力,提高运维的效率,快速部署,出了问题自动化修复。需要用到工具和平台,这就是数人云现在帮客户去做的。


把微服务业务在运行时缺失的管理方式方法、工具平台,工具链补齐。首先是配置管理能力、完备的监控能力等等,普及之后运维人员就有能力来管微服务应用。这其实是DevOps里面最狭义的,让运维的能力变得轻量。


如果要真正实现DevOps,就像目前一些互联网公司做到的,开发和运维真正的深度融合在一起。企业目前的运维一般不具有编程能力,所以真正的DevOps还需要很长时间去落地。 查看全部

1月13日,中国双态运维用户大会在北京举办。来自银行、保险、证券、政府、央企等多个行业的330多位企业用户参加,其中工商银行信息科技部副总经理张艳,国泰君安信息技术部总经理俞枫、海关总署科技发展司运行安全处处长张芳、平安科技系统运营部总经理陈亚殊等分别发表了演讲。本文为数人云CEO王璞在双态运维用户大会DevOps、容器与微服务分论坛上的演讲实录。演讲结束,与在座金融客户展开了精彩的Q&A分享。

容器、微服务、DevOps三者,业内的共识是密不可分。没有微服务,DevOps落地不下去,没有容器,DevOps也无法真正实现敏捷运维、自动化运维。DevOps、容器、微服务为更好的构建PaaS提供了方法论和技术手段。

1、PaaS之承上启下

PaaS作为云计算的承上启下要素,向上支撑各环境应用,向下跟IaaS、计算环境、计算资源对接,是企业云化的必由之路。>>>>PaaS三大技术趋势

1.应用容器化,容器正在成为云计算原生应用的标准交付方式。

2.微服务网格化,随着企业对微服务的认知越来越深入,下一代微服务着重把应用管理作为核心。因为企业应用一定要有很强的管理在微服务架构上,不能让应用去“裸奔”。数人云没有提微服务化,因为微服务化已经是不争的事实。应用微服务缺乏强大的管理,需要服务网格这样的下一代微服务技术。

3.行业生态化,PaaS技术本质上是支持应用的,应用跟业务紧密结合,所以PaaS最终是要和业务层面融合,行业需要生态化。>>>>PaaS落地三大要素:

PaaS要在企业客户方面落地不可或缺三要素:规模化、统一化、标准化。企业客户落地云计算平台、技术,本质上是希望提高效率,对业务有更好的敏捷支撑。

所有应用,比如容器应用、微服务应用,都实现标准化。标准化以后进行统一化管理,包括部署、发布、故障恢复、监控告警等都实现统一化管理。最后实现模块化,整个系统都是轻量的,微小模块化的。只有基于这三点的PaaS平台和云计算平台,才能够让IT系统真正实现敏捷轻量,提高IT对业务支撑的效果。

2、企业IT架构转型之开发&运维

企业客户目前在架构转型应用中面临的现状是,企业里大量传统应用,客户希望先实现轻量的单体架构,即摆脱很多中间件,摆脱外部服务,MVC架构、单体复杂架构等首先实现轻量化。

数人云日常接触的客户中,走的比较靠前的客户已经在用Spring Cloud、Dubbo等架构,部分客户相当数量的应用已经微服务化,不过处于中间状态,正在考虑评估微服务架构的客户比例还是最大。总之,企业目前的现状是为服务应用、轻量单体应用,以及传统的巨石应用并存。

在架构转型过程中,正确和常态的路径一定是一步步走过来,而不是传统架构丢掉直接上微服务。>>>>DevOps和容器@轻量单体应用架构

在单体应用架构下,DevOps、容器帮助企业实现敏捷IT。首先,持续集成持续交付CI/CD,只要应用是相对轻量的,就能加快中间件应用。CI/CD其中重要的一点是变更发布管理。


数人云某客户上了容器的应用都是轻量化的,基于 Tomcat 和微服务的应用。当基于容器实现快速发布以后,企业发现,所有发布里有一半的发布失败是由于配置不正确引起的。所以,如果没有发布变更管理,发布失败的中间环节有方方面面的因素。

当基于容器实现快速发布之后,容器对环境的异构做了一层屏蔽,这时如果出现处理的问题就是配置管理的问题了,由于涉及不同的环境和应用,配置环境变成应用发布很容易出错的环节。>>>>DevOps和容器@微服务应用架构

数人云做了企业客户微服务落地状况的调研(微服务2017年度报告出炉:4大客户画像,15%传统企业已领跑),在报告中,有15%左右的企业引入了Spring Cloud、Dubbo。微服务在企业里首当其冲的是敏捷开发,因为微服务是一种切实的敏捷开发的方法。


敏捷开发在IT界已经推广多年,但很多时候敏捷开发推的都是方法论,比如Scrum。微服务是一套切实能够落地到IT人员、开发人员开发过程中的实践方法,这是微服务首当其冲的好处,很多企业的开发部门对微服务非常欢迎。不过,15%还是偏小的一个采用比例,微服务还不是企业客户主流的IT架构。

开发人员都比较欢迎微服务,因为能够提升开发效率,落地敏捷开发,但微服务的阻碍还是不小的,微服务对开发运维来说,带来的复杂度急剧上升。传统运维管理的服务器数量、应用数量有限。企业决定采用微服务本身就表明业务很复杂,单体应用做传统的瀑布式开发效率太低,微服务将应用拆分成较小的模块,因此微服务应用一旦上线,程序的数量呈现爆炸式增长。


例如,数人云某个传统企业的客户,目前部署了微服务相关的应用,基于Spring Cloud、Spring Boot,跑在几千个容器上,几千个容器如果通过传统运维方式去管理的话几乎是不可能的。这就是很多微服务无法落地的原因——很多企业客户缺乏相应的运维能力,没有相应的平台、工具、方式、方法管理微服务应用。
 
>>>>微服务落地的必要条件


微服务应用落地,首当其冲是配套工具链的完善。开发人员采用微服务的影响相对改变小一些。采用SpringCloud或者Dubbo、gRPC等,只是开发框架上的并更。其他开发流程如代码托管、代码审查、测试等并不涉及,所以开发流程相对简单。但微服务对运维功能的要求就会复杂,相应的快速配置能力、完备的监控能力、快速部署能力等对传统运维来说都是缺失的,容器能够补足这方面的能力,让运维部门具有DevOps的能力。

关于微服务的拆分,其实是业务部门需要真正解决的问题。微服务对组织上也有变更,将团队化整为零。通常每个单独的微服务程序都由7-10人的小团队来负责维护,这些都是微服务落地的必要条件。
 
对于数人云来说,直接能够给客户提供的帮助,首先是工具链方面,数人云产品层面具备丰富的微服务配套工具链,从监控、日志、调度、故障自动化修复等等都有完备的工具链。在落地方法上,数人云搭建了自己的生态圈,和很多合作伙伴合作,例如跟埃森哲公司在合作,帮助企业客户落地微服务,进行业务的梳理。
 
>>>>容器和微服务共生


容器技术补齐了微服务相关的工具链,对企业全面向云计算转型提供了很大帮助。应用架构是微服务分布式的,相应的运维也要有自动化、敏捷运维的能力。微服务跑在容器上才能发挥它最好的特性。容器是目前最流行的应用环境,基于容器的微服务部署和更新更快,更轻量,服务之间的调用、服务发现、负载均衡等更灵活。


不过,微服务不是万能的。简单的业务场景单体应用其实足够,微服务一定是应用在复杂的业务场景下,只有复杂的业务场景才有很大的维护成本、维护压力,微服务是用来降低复杂业务场景的维护成本。>>>>基于容器云的微服务运行时管理体系

一个完整的微服务管理体系,除了开发框架之外,对运维部门来说,运维微服务应用最基本的路由、负载均衡等功能,容器可以提供,不过容器提供的只是一部分跟微服务相关的能力和工具链。周围还有一大批需要配套的工具,比如配置管理、API网关、注册发现、应用监控等等。这里的监控不是容器CPU内存的监控,而是业务逻辑的监控,更准确一点是全链路跟踪的全链路监控。容器满足了微服务运行时管理的需求,不过周边许多权限、网关、配置等尚无余力满足。

>>>>统一配置中心是微服务体系的核心

统一配置管理,是微服务落地时很核心的点。要在平台工具上落地微服务首先要具备快速配置能力,因为客户采用微服务和容器平台以后,很快会发现50%以上的发布失败是因为配置没搞对,因此配置管理是微服务里首当其冲的问题。

因为每个企业客户都有开发环境、测试环境、生产环境等很多环境,同一个应用不同版本在不同环境下的配置不同。几何级数的配置项、配置元素的增长会导致配置管理的复杂度急剧上升,需要统一的配置中心进行管理。数人云在帮助企业客户落地微服务时,首先会做的是把配置搞定,没有灵活快速的配置管理能力,微服务运行不起来。
 
>>>>变更发布管理(灰度发布 v.s. 蓝绿部署)

在发布管理方面,数人云帮助企业落地的发布管理主要是蓝绿部署,因为很多企业的应用本身不支持灰度发布。蓝绿部署也是切切实实的快速发布,发布用变更窗口的方式来实现。

例如,周五晚上12点起进行发布变更,12点就要停服务中心。蓝绿部署可以显著地缩短服务不可用的变更窗口。怎么做呢?客户在线上有两个版本,蓝版本和绿版本。现在负载均衡器将流量指向对外提供服务的绿版本,蓝版本作为备用的方案。同时,新程序往蓝版本上部署推送,更新时只需要把流量切换到蓝版本。发布流程最后简化为只需要进行流量的切换。流量可以快速切换,中间的窗口期只有短短几分钟,如果流量切换过来一切正常发布即完成,如果流量切换过来发现问题,可以再将流量切回去。这样开发人员、运维人员不必当场熬夜去修复,极大地减轻了发布的压力。

传统发布方式下,每次变更窗口有好几个应用排队发布,一个应用发布完成后才可以发布下一个应用,一旦中间某一个应用发布失败现场修复的压力非常大,短短的发布窗口需要几个小时内完成抢修,非常不可控,团队经常需要晚上熬夜排队。而结果往往等了半天,前面的应用没发布成功,后面的还得继续排队等。

3、金融行业之践行渐进

数人云在金融、能源、制造、快消、政企等行业的基础上,继续深耕强监管、强安全,高复杂度的金融行业。以某商业银行为例,数人云帮助落地了大规模微服务容器平台。该商业银行近年来互联网业务发展迅猛,原有系统架构无法支撑其未来规划。2016年6月开始全面实施应用微服务化,已实现蓝绿发布。


首先,营销系统全部是轻量化的应用,基于Spring Boot、Tomcat、SpringCloud等,跑在容器平台上。该银行对外营销频次非常高,通过线上微信公众号、手机APP、线上门户、合作伙伴等渠道,每月对外营销达上百场。

每次营销活动或多或少都对IT系统有变更,哪怕是配置变更,因此每次营销活动对IT系统都是一次不小的挑战。发布的时候仅仅靠容器是不够的,需要实现模板的批量发布。每次发布看起来只是一个个的容器程序,实则不然,其实是一组组一批批的容器,只有帮客户做到批量的应用发布,才能显著提升发布效率。

蓝绿部署方面,该银行密集的线上营销中,每一天会有一个重点营销活动,那么营销活动的流量如何分到特别的人群、区域?在后台应用的上千个实例中,并不是每一个实例都分配同等的流量,要通过流量分发,做线上流量控制。数人云借鉴Google做灰度发布的方式为客户提供图形化的流量控制,这和微服务实施后的限流分流是息息相关的。

另外,该银行客户的数据流量非常大,对日志收集带来非常大的的压力。数人云建议客户将应用程序的日志全部交给Kafka采集,Kafka可以做到很大数据流量的分布式消息应用。

分布式数据传输分布式消息应用很难保证每一个消息都可靠地传递。Kafka有两种模式:一种保证消息传递至少一次,但也可能多次,对很大的日志量来说偶尔丢一两条可以忽略不计。Kafka的并发量很大,可能带来偶尔很小的数据量丢失,也可能带来日志的乱序,这在分布式系统下都是可以容忍的,“鱼和熊掌不可兼得”。

关于快速建立支撑微服务体系,数人云有几点总结:
 
1.开发框架不能用重量级的应用体系,要么是轻量化单体架构的Tomcat等,要么采用Spring Cloud等微服务架构。

2.要有微服务平台,具备快速配置管理能力、部署能力、监控能力、应用管理能力等配套管理能力。很多企业的痛点是,开发人员快速学习微服务开发技术,基于Spring Cloud做业务系统后,业务系统无法上线,因为运维部门缺乏配套的工具、平台支撑微服务线上运行管理。

3.DevOps融合,平台管理需要把链条全打通,实现快速发布、快速上线、自动修复等。容器经过几年的普及企业已经相对了解,但容器本身是纯技术平台,基于容器、DevOps的落地还有很长的路要走。>>>>数人云微服务On PaaS 产品体系


数人云现在的重点是微服务、轻量单体应用。以前数人云帮企业客户落地重应用的容器平台,但后来发现价值不大,反而对企业来说,除了维护重的应用外还需要维护容器,容器平台并不能实现自动化运维。经过几年的实践和摸索,数人云跟企业客户达成的共识是,传统应用不经过改造无法上到云PaaS平台。

 轻量架构下的应用如何基于PaaS平台支撑?以敏捷开发为例,企业客户通常选择 Spring Cloud、gRPC 等主流的开发框架,然后在微服务工具链层面配置监控、报警、部署、快速发布等方方面面的能力,最下面承载的则是容器平台。


数人云现在还可以帮助客户落地服务网格化技术。它能够进行异构架构的兼容,gRPC就是服务网格的一部分,Google推的 Istio,Linkerd的Kubernetes 都支持 gRPC,gRPC成为通讯协议的一部分。基于通讯协议相应周边的管理,在服务网格这一层可以做灰度发布、A/B测试、流量控制、高级熔断、加密、白/黑名单机制、权限访问控制等等。


服务网格被称作下一代的微服务,因为用了服务网格以后,所有微服务管理的诉求都自动化地满足了。80%-90%的应用管理需求都在服务网格里自动涵盖。这对开发人员来讲,微服务开发的门槛急剧降低,不需要考虑未来应用上线时流量控制、灰度发布等等,只需要考虑业务。数人云微服务On PaaS 目的就是帮助企业客户降低微服务架构、上云转型的门槛。


 Q&A
 
Q1:感觉对DevOps的理解不太到位,能不能具体地讲一下?A1:DevOps准确来讲,现在业内还没有统一的认识。互联网公司的DevOps目前是比较统一的,比如Goolge,但是互联网公司的DevOps,我个人理解没办法在企业直接落地。




在Google,程序员不止要负责应用的开发,还要负责相应的测试,单元测试、集成测试等等。另外,应用的部署、发布、上线也是开发人员自己做。所以互联网公司讲DevOps,更多讲的是开发运维的融合。我之前在Google时,不仅要做代码开发,也要把测试的代码全写出来。

Google有一个理念,开发人员每写一行业务代码,测试代码要写十行。然后,开发人员利用各种发布平台定期发布,比如每周做发布,在Google 运维的人员叫“SRE”。SRE部门准备好各种平台,开发人员可以用这些平台做发布、监控、日志管理等工作。

Google目前有三万名左右的IT人员,其中SRE的运维人员只有一千多,比例很低。所以在Google运维人员不可能帮每一个开发人员或者业务部门做上线。像传统IT开发人员提工单给运维,在Google是不可能的。Google这种做法,它让开发做更多的事情,运维人员很少,只是负责维护平台。所以,Google一千多人管理着几百万台服务器,平均每人管两千台。


但传统企业目前不是这样,传统企业开发和运维之间壁垒比较大。数人云帮助客户落地DevOps 时,基于的理念是,不要破坏现有开发的流程。DevOps应该是开发和运维深度融合才能做到的。讲DevOps,首先要讲理念、组织的变革,但是要想把文化变革、组织变革打破要很长时间。

从落地的角度,DevOps更多落地在运维部门,很具象的工作就是,帮助运维部门去实现DevOps的能力,比如快速部署、快速上线,应用的快速配置,自动化管理能力、故障的自动化处理等等。把以前的运维工作尽可能的自动化,提高效率,这是狭义的DevOps理念,也是我们现在接触到的。数人云不会帮客户落地像互联网公司那样的DevOps,开发做很多事情,运维可做的很少,并不是这样的。

Q2:微服务适合复杂的场景,那么一个简单的促销是不是适合?微服务有多“微”呢?微服务和ESB 服务相比,有什么差别?A2:第一个促销场景,促销场景本身有些条件,促销很重要一点就是必须特别频繁,促销内容在平台要发生变化。比如,今天的促销内容和明天的不太一样,或者这周的促销和下周的不太一样,业务平台需要频繁变更,这时候微服务是适合的。

因为微服务是一种敏捷开发的落地实践方法,只要业务频繁变更,对开发的要求就必须敏捷开发,快速实现。所以,只要业务场景在不停地快速变化,促销又是互联网线上的方式,肯定是适合的。

关于复杂性,如果业务逻辑简单,逻辑变化少,并不适合微服务。比如数人云和很多银行客户合作,银行核心系统很复杂,但是银行系统并不是需求频繁变化的场景。很多银行在做“瘦核心系统”,就是银行核心系统的功能越来越单一,越来越瘦,并不是把复杂的周边的业务也放到银行核心系统里。银行核心系统虽然复杂,但业务不会频繁变化,也不一定要上到微服务场景下。复杂的业务系统,业务需求又不停变化,这种场景适合微服务。

第二个问题是和ESB 比,服务网格和 ESB 有很多相像的地方。ESB有业务逻辑串起来,很多不同的业务系统都上到ESB,互相的权限通过ESB打通。从功能角度讲,ESB和服务网格之间很相像,不同点在于ESB是传统架构下的,并没有考虑频繁迭代、流量集中爆发等问题。


但是微服务情况下,整个之间的互相请求、依赖、通讯等等都会进行统一的管理,这种情况下也很像ESB把不同业务之间的流量进行统一管理,但是服务网格更看重的是面向大规模的控制,那流量突发怎么做限流,或者突然故障怎么做熔断等等。最本质的问题是类似的,但是具体的问题表象和需求不同。

Q3:在实际部署过程中,PaaS平台在底层资源的调用一定要用分布式云架构,传统主机是否可以?两者在最后效果上有没有什么异同?A3:数人云当初两种情况都有,有些场景比如业务量比较大,企业客户为了减少复杂度,容器PaaS平台直接落地到物理服务器上。还有客户为了方便管理,把PaaS落地到IaaS上,两种情况都有。

这其中的考虑是,首先业务量大如果再引入虚拟化这一层会引来额外的复杂度,此时用物理服务器更好。其次,客户有很大规模的物理服务器,直接在上面部署PaaS,在物理服务器上去调用。


第三种,资源动态的调整或资源频繁调配,这个场景很常见,需要IaaS。比如银行客户,内部业务系统分不同的域,不同域的业务复杂性随时间变化经常会发生变化,需要不停地做资源动态的调整。如果用物理机太麻烦,企业客户会选择下面有一层IaaS来做。

基于PaaS也能做一部分的资源动态调配,但是调配维度不同。数人云帮客户落地PaaS时会做资源的整合。从划分的维度,PaaS平台是按照应用程序来划分,IaaS的资源划分是按照业务系统。

Q4:微服务重新开发,最佳的开发框架或者实践有什么可以分享的?第二,旧有的系统改造到微服务这块有没有什么经验?第三,DevOps以前也有很多像敏捷开发的方法论,它们之间有没有什么关系?A4:首先第一个问题,微服务的开发框架。企业客户在做选择时都希望降低风险,选最主流的框架,现在看最主流的开发框架就是Spring cloud,这也是业界的自然选择结果。其他语言也都有些微服务开发,但是用的人少一些。如果是Java应用,目前比较好的选择是Spring Cloud,也有很多客户用了Dubbo,其他架构都是偏小众的架构,主要还是看客户自己的需求。

第二个问题,传统业务要转到微服务架构上,一定要循序渐进。比如Java应用,首先Java中间件的应用,先脱掉,不要再基于这么重的Java中间件。目前相对流行的是Spring Boot这套逻辑。

有了轻量的单体化应用之后(基于Tomcat),往后走基于微服务的框架,上到Spring Boot,再上到Spring Cloud,这是比较平滑的方式。Spring Boot 在很企业客户中用的非常多,是很方便的一套单体开发架构。

企业客户目前的现状是老的应用很多,不会一次就改造完,传统的应用可以先选择一部分容易转的转到轻量单体架构上,然后再转到微服务框架上。目前企业客户是轻量的单体架构、微服务架构,以及大量传统的架构应用并存。老的架构应用目前上不到PaaS平台,只有轻量的单体化加微服务应用才能上到PaaS平台。

现在业内的共识是,微服务、容器、DevOps这三者是密不可分的。微服务更多是针对开发人员,是一种真正落地的云开发方法。很多企业客户也讲敏捷开发,派团队成员学习敏捷开发的方法论,但是敏捷开发仍然无法在企业当中落地。

这是因为,只学会了方法,但没办法落地到具体的编程,即开发环节上去,自然没办法做到敏捷开发。很多开发者回来写的程序依然是J2EE。J2EE 编程的理念和方法并不是敏捷开发的,是偏向于瀑布式的。

微服务是具体的开发环节上的敏捷开发方法,开发能力化整为零,每个团队做简单、具象、单一的逻辑。微服务首先是一个具像的敏捷开发方法,实践方法。

微服务在落地时,比如程序运行时,复杂度很高,因为不是一个程序,是一批程序一起运行,对运维的管理就比较复杂,这时候可以利用容器实现微服务应用的自动化管理。微服务一般都会上到容器,因为微服务应用不再是单体的部署方式,不再是部署到Java中间件上。基于微服务架构,几百个进程进来,用容器的方式实现快速部署动态调度,微服务部署到容器上,实现基础的轻量化运维。


轻量化运维,快速部署、自动化调度,逐步往DevOps方向走。DevOps更多强调自动化的运维能力,提高运维的效率,快速部署,出了问题自动化修复。需要用到工具和平台,这就是数人云现在帮客户去做的。


把微服务业务在运行时缺失的管理方式方法、工具平台,工具链补齐。首先是配置管理能力、完备的监控能力等等,普及之后运维人员就有能力来管微服务应用。这其实是DevOps里面最狭义的,让运维的能力变得轻量。


如果要真正实现DevOps,就像目前一些互联网公司做到的,开发和运维真正的深度融合在一起。企业目前的运维一般不具有编程能力,所以真正的DevOps还需要很长时间去落地。
数人云使用技巧交流,问题反馈,最佳实践分享