数人云

数人云

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

dataman 发表了文章 • 0 个评论 • 37 次浏览 • 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 个评论 • 29 次浏览 • 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 个评论 • 49 次浏览 • 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 个评论 • 73 次浏览 • 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还需要很长时间去落地。

开发测试一山容得二虎,30条有关测试的故事和事故

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

软件工程规则和测试积累的最佳实践,能帮助企业显著节省时间,减少痛点。良好的测试实践既可以确保质量标准,也可以指导和塑造每个程序员的发展。

小数今天推送的这篇文章,文中的许多原则都与测试实践和理想有关,有一些还是Python特有的。正如本文作者所说,程序员的那些固执己见,强烈的意见表达和坚持,往往是激情的最好表现。

1. YAGNI:不要编写现在尚不需要,而将来可能需要的代码。现在的代码不可避免地会变成死代码或需要重写,因为未来的用例总是与设想的不同。如果把代码放在未来的用例中,在代码审查中要提出质疑。(例如,可以并且必须设计API来允许将来的用例,不过,这是另外一个问题。)

注解代码也是如此。如果一个注释代码块进入发行版,它就不应该存在。如果是可以恢复的代码,创建一个ticket,并引用代码删除的提交散列。YAGNI 是敏捷编程的核心元素。Kent Beck提供的极限编程解释(Extreme Programming Explained)就是最好的参考。


2.测试本身不需要测试。用于测试的基础架构,框架和库需要测试。除非确实需要,通常不要测试浏览器或外部库。测试你写的代码,而并非其他人的。

3.第三次编写相同代码时,是将其抽取到通用帮助器(并为其编写测试)的正确时机。测试中的辅助功能不需要测试; 当把它们分解出来并进行重用时,才需要测试。到第三次编写类似的代码时,会清楚地知道正在解决什么样的问题。

4.涉及到API设计:简单的事情简单化; 复杂的事情可能如果可能也简单化。首先设计一个简单的情况,如果可能,最好使用零配置或参数化。为更复杂和更灵活的用例添加选项或其他API方法。


5.快速失败。尽可能早地检查输入,并在无意义的输入或无效状态上失败,使用异常或错误响应,来确定问题。允许代码“创新”,也就是说,通常情况下,不要对输入验证进行类型检查。


6. 单元测试是对行为单元的测试,而不是对实现单元。改变实现,而不是改变行为或被迫改变任何测试,当然这点并不是总能实现。在可能的情况下,将测试对象视为黑盒子,通过公共 API 进行测试,而无需调用私有方法或修改状态。


对于一些复杂的场景,比如一些特定复杂状态下,测试行为找到一个难以理解的错误。编写测试确实有助于解决这个问题,因为它会迫使你在编写代码之前,考虑清楚代码的行为以及如何测试。测试首先鼓励更小,更模块化的代码单元。

7.对于单元测试(包括测试基础结构测试),应该测试所有的代码路径。100%的覆盖率是一个很好的起点。你不能涵盖所有可能的排列/组合状态。在有很好的理由时,代码路径才能被测试。缺少时间不是一个好的理由,这往往导致最终花费更多时间。好的理由包括:真正无法测试,在实践中不可能实现,或者在测试中其他地方被覆盖。没有测试的代码要承担责任。衡量覆盖率,并拒绝降低覆盖率的百分比是朝正确方向前进的一种方法。


8.代码是敌人:可能出错,需要维护。少写代码。删除代码。不要编写你不需要的代码。

9.随着时间的推移,代码注释不可避免地成为谎言。实际上,很少有人在事情发生变化时更新评论。通过良好的命名实践和已知的编程风格,努力使代码有可读性和自我记录。

不明确的代码确实需要注释,比如围绕一个模糊的错误或不可能的条件,或者必要的优化。

10.防守地写。要总是想可能出现什么问题,无效输入会发生什么,什么可能导致失败,这有助于在错误发生前发现错误。

11.如果逻辑无状态且无副作用,则易于进行单元测试。将逻辑分解成独立的函数,而不是混合成有状态和副作用的代码。将有状态和带副作用的代码分离成更小的函数,可以更容易地模拟和单元测试。副作用确实需要测试,测试一次并在其他地方进行模拟,是比较好的做法。

12.Globals are bad。功能优于类型,对象比复杂的数据结构更好。

13.使用 Python 内置类型和方法比编写自己的类型更快(除非用C编写)。如果考虑性能,尝试解决如何使用标准内置类型而不是自定义对象。

14. 依赖注入是一种有用的编程模式,可以清楚了解依赖关系。(让对象,方法等接收依赖关系作为参数,而不是自己实例化新的对象。)这是一种交换,使API签名更加复杂。如果完成依赖项需要使用10个参数,说明代码太多了。


15. 越需要模拟测试代码,它就会越糟糕。需要实例化和放置的代码越多,用来测试特定的行为,代码就越糟糕。测试的目标是小型可测试单元,和更高级别的集成和功能测试,来测试这些单元是否正确地协作。


16.面向外部的 API 是要“预先设计”的,它关系到未来用例。改变 API 对自己和用户来说都是一种痛苦,而创造向后兼容性是非常可怕的,尽管有时不可避免。精心设计面向外部的API,仍然坚持“简单的事情简单化”的原则。


17.如果一个函数或方法超过30行代码,就要考虑分解。好的最大模块大小约为500线。测试文件往往比这个更长。


18.不要在难以测试的对象构造函数中工作。不要把代码放在__init__.py中。程序员不希望在__init__.py找到代码。


19. DRY(Don’t Repeat Yourself不要重复自己)在测试中比在生产中重要得多。单个测试文件的可读性比可维护性更重要(突破可重用的块)。这是因为测试是单独执行和读取的,而不是作为大系统的一部分。过多的重复意味着可重用的组件可以方便地创建,但是与生产相比,测试的重要性低得多。


20.当看到需要并有机会时进行重构。编程是关于抽象的,抽象映射越接近问题域,代码就越容易理解和维护。随着系统有机地增长,需要为扩展用例而改变结构。系统超出抽象和结构,而不改变它们成为技术债务,这会更痛苦,更缓慢,更多bug。包括重构成本,包括对功能的预估。你把债务拖得越久,它积累的利息就越高。Michael Feathers 撰写了一本关于重构和测试的书籍,其中着重介绍了遗留代码。

21.正确的编写代码第一,速度第二。处理性能问题时,请务必在修复之前进行配置。瓶颈通常出乎你的意料。编写难懂的代码如果是为了速度更快,为此你进行了配置并证明这么做是值得的,那么也仅仅是速度上值得而已。编写一个测试,训练正在配置的代码,让它知道什么情况下会变得更简单,并且留在测试套件中,来防止性能下降。(通常情况下,添加计时代码总是会改变代码的性能特点,使性能变得经常差强人意。)


22.更小范围的单元测试在失败时会提供更有价值的信息。要判定错误,有一半的系统测试行为的测试需要依据更多的调查。一般来说,运行时间超过0.1秒的测试不是单元测试。没有所谓的慢单元测试。通过严格范围的单元测试测试行为,你的测试可以作为代码实际规范。理想情况下,如果有人想了解你的代码,应该能够将测试套件作为行为的“文档”。


23. “这里没有发明”并不像人们所说的那么糟糕。如果我们编写代码,我们知道它的作用,知道如何维护它,可以自由地扩展和修改它。这是遵循了YAGNI的原则:我们有需要用例的特定代码,而并非通用代码,通用代码会给我们不需要的部分带来复杂性。另一方面,代码是敌人,拥有更多的代码没有好处,当引入新的依赖关系时需要考虑权衡。


24.共享代码所有权是目标。孤立的知识没什么好,这意味着至少要讨论、记录贯彻设计决策和实施决策。代码审查时开始讨论设计决策是最糟糕,因为在编写代码之后进行彻底的更改太难克服了。当然,在Review时指出和修改设计错误,比永远不总结不思考要好得多。


25.  Generators rock! 与有状态的对象相比,它们用于迭代或重复执行通常更短,更容易理解。


26.让我们成为工程师!设计、建立强大和良好实施的系统,而不是增加有机怪物。编程是一个平衡的行为,我们并不总是建造火箭飞船,过度设计(onion architecture洋葱架构)与设计不足的代码同样令人痛苦。罗伯特•马丁(Robert Martin)所做的几乎任何事情都值得一读,“ 干净架构:软件结构和设计指南”( Clean Architecture: A Craftsman’s Guide to Software Structure and Design )是这方面的好资源。设计模式( Design Patterns)是每个工程师应该阅读的经典编程书籍。


27.间歇性地失败的测试会侵蚀测试套件的价值,以至于最终每个人都忽略测试运行的结果。修复或删除间歇性失败的测试是痛苦的,但值得努力。


28.一般来说,尤其是在测试中,等待一个具体的改变,而不是任意时间内sleeping。Voodoo sleeps 很难理解,而且会放慢测试套件。


29.至少要看到你的测试失败过一次。将一个蓄意的 bug 放入让它失败,或在测试行为完成之前运行测试。否则,你不知道你真的在测试。偶尔写写测试代码实际并不测试任何东西,或写永远不会失败的测试,都是很容易的。


30.最后,管理要点:持续的功能研发是开发软件的一个可怕方法。不让开发人员在工作感到骄傲, 就不会从中获得最大的利益。不解决技术债务,会拖慢开发速度,并导致更糟糕的、更多bug的产品。


原文作者:Michael Foord

原文链接:

https://opensource.com/article ... sting
  查看全部
软件工程规则和测试积累的最佳实践,能帮助企业显著节省时间,减少痛点。良好的测试实践既可以确保质量标准,也可以指导和塑造每个程序员的发展。

小数今天推送的这篇文章,文中的许多原则都与测试实践和理想有关,有一些还是Python特有的。正如本文作者所说,程序员的那些固执己见,强烈的意见表达和坚持,往往是激情的最好表现。

1. YAGNI:不要编写现在尚不需要,而将来可能需要的代码。现在的代码不可避免地会变成死代码或需要重写,因为未来的用例总是与设想的不同。如果把代码放在未来的用例中,在代码审查中要提出质疑。(例如,可以并且必须设计API来允许将来的用例,不过,这是另外一个问题。)

注解代码也是如此。如果一个注释代码块进入发行版,它就不应该存在。如果是可以恢复的代码,创建一个ticket,并引用代码删除的提交散列。YAGNI 是敏捷编程的核心元素。Kent Beck提供的极限编程解释(Extreme Programming Explained)就是最好的参考。


2.测试本身不需要测试。用于测试的基础架构,框架和库需要测试。除非确实需要,通常不要测试浏览器或外部库。测试你写的代码,而并非其他人的。

3.第三次编写相同代码时,是将其抽取到通用帮助器(并为其编写测试)的正确时机。测试中的辅助功能不需要测试; 当把它们分解出来并进行重用时,才需要测试。到第三次编写类似的代码时,会清楚地知道正在解决什么样的问题。

4.涉及到API设计:简单的事情简单化; 复杂的事情可能如果可能也简单化。首先设计一个简单的情况,如果可能,最好使用零配置或参数化。为更复杂和更灵活的用例添加选项或其他API方法。


5.快速失败。尽可能早地检查输入,并在无意义的输入或无效状态上失败,使用异常或错误响应,来确定问题。允许代码“创新”,也就是说,通常情况下,不要对输入验证进行类型检查。


6. 单元测试是对行为单元的测试,而不是对实现单元。改变实现,而不是改变行为或被迫改变任何测试,当然这点并不是总能实现。在可能的情况下,将测试对象视为黑盒子,通过公共 API 进行测试,而无需调用私有方法或修改状态。


对于一些复杂的场景,比如一些特定复杂状态下,测试行为找到一个难以理解的错误。编写测试确实有助于解决这个问题,因为它会迫使你在编写代码之前,考虑清楚代码的行为以及如何测试。测试首先鼓励更小,更模块化的代码单元。

7.对于单元测试(包括测试基础结构测试),应该测试所有的代码路径。100%的覆盖率是一个很好的起点。你不能涵盖所有可能的排列/组合状态。在有很好的理由时,代码路径才能被测试。缺少时间不是一个好的理由,这往往导致最终花费更多时间。好的理由包括:真正无法测试,在实践中不可能实现,或者在测试中其他地方被覆盖。没有测试的代码要承担责任。衡量覆盖率,并拒绝降低覆盖率的百分比是朝正确方向前进的一种方法。


8.代码是敌人:可能出错,需要维护。少写代码。删除代码。不要编写你不需要的代码。

9.随着时间的推移,代码注释不可避免地成为谎言。实际上,很少有人在事情发生变化时更新评论。通过良好的命名实践和已知的编程风格,努力使代码有可读性和自我记录。

不明确的代码确实需要注释,比如围绕一个模糊的错误或不可能的条件,或者必要的优化。

10.防守地写。要总是想可能出现什么问题,无效输入会发生什么,什么可能导致失败,这有助于在错误发生前发现错误。

11.如果逻辑无状态且无副作用,则易于进行单元测试。将逻辑分解成独立的函数,而不是混合成有状态和副作用的代码。将有状态和带副作用的代码分离成更小的函数,可以更容易地模拟和单元测试。副作用确实需要测试,测试一次并在其他地方进行模拟,是比较好的做法。

12.Globals are bad。功能优于类型,对象比复杂的数据结构更好。

13.使用 Python 内置类型和方法比编写自己的类型更快(除非用C编写)。如果考虑性能,尝试解决如何使用标准内置类型而不是自定义对象。

14. 依赖注入是一种有用的编程模式,可以清楚了解依赖关系。(让对象,方法等接收依赖关系作为参数,而不是自己实例化新的对象。)这是一种交换,使API签名更加复杂。如果完成依赖项需要使用10个参数,说明代码太多了。


15. 越需要模拟测试代码,它就会越糟糕。需要实例化和放置的代码越多,用来测试特定的行为,代码就越糟糕。测试的目标是小型可测试单元,和更高级别的集成和功能测试,来测试这些单元是否正确地协作。


16.面向外部的 API 是要“预先设计”的,它关系到未来用例。改变 API 对自己和用户来说都是一种痛苦,而创造向后兼容性是非常可怕的,尽管有时不可避免。精心设计面向外部的API,仍然坚持“简单的事情简单化”的原则。


17.如果一个函数或方法超过30行代码,就要考虑分解。好的最大模块大小约为500线。测试文件往往比这个更长。


18.不要在难以测试的对象构造函数中工作。不要把代码放在__init__.py中。程序员不希望在__init__.py找到代码。


19. DRY(Don’t Repeat Yourself不要重复自己)在测试中比在生产中重要得多。单个测试文件的可读性比可维护性更重要(突破可重用的块)。这是因为测试是单独执行和读取的,而不是作为大系统的一部分。过多的重复意味着可重用的组件可以方便地创建,但是与生产相比,测试的重要性低得多。


20.当看到需要并有机会时进行重构。编程是关于抽象的,抽象映射越接近问题域,代码就越容易理解和维护。随着系统有机地增长,需要为扩展用例而改变结构。系统超出抽象和结构,而不改变它们成为技术债务,这会更痛苦,更缓慢,更多bug。包括重构成本,包括对功能的预估。你把债务拖得越久,它积累的利息就越高。Michael Feathers 撰写了一本关于重构和测试的书籍,其中着重介绍了遗留代码。

21.正确的编写代码第一,速度第二。处理性能问题时,请务必在修复之前进行配置。瓶颈通常出乎你的意料。编写难懂的代码如果是为了速度更快,为此你进行了配置并证明这么做是值得的,那么也仅仅是速度上值得而已。编写一个测试,训练正在配置的代码,让它知道什么情况下会变得更简单,并且留在测试套件中,来防止性能下降。(通常情况下,添加计时代码总是会改变代码的性能特点,使性能变得经常差强人意。)


22.更小范围的单元测试在失败时会提供更有价值的信息。要判定错误,有一半的系统测试行为的测试需要依据更多的调查。一般来说,运行时间超过0.1秒的测试不是单元测试。没有所谓的慢单元测试。通过严格范围的单元测试测试行为,你的测试可以作为代码实际规范。理想情况下,如果有人想了解你的代码,应该能够将测试套件作为行为的“文档”。


23. “这里没有发明”并不像人们所说的那么糟糕。如果我们编写代码,我们知道它的作用,知道如何维护它,可以自由地扩展和修改它。这是遵循了YAGNI的原则:我们有需要用例的特定代码,而并非通用代码,通用代码会给我们不需要的部分带来复杂性。另一方面,代码是敌人,拥有更多的代码没有好处,当引入新的依赖关系时需要考虑权衡。


24.共享代码所有权是目标。孤立的知识没什么好,这意味着至少要讨论、记录贯彻设计决策和实施决策。代码审查时开始讨论设计决策是最糟糕,因为在编写代码之后进行彻底的更改太难克服了。当然,在Review时指出和修改设计错误,比永远不总结不思考要好得多。


25.  Generators rock! 与有状态的对象相比,它们用于迭代或重复执行通常更短,更容易理解。


26.让我们成为工程师!设计、建立强大和良好实施的系统,而不是增加有机怪物。编程是一个平衡的行为,我们并不总是建造火箭飞船,过度设计(onion architecture洋葱架构)与设计不足的代码同样令人痛苦。罗伯特•马丁(Robert Martin)所做的几乎任何事情都值得一读,“ 干净架构:软件结构和设计指南”( Clean Architecture: A Craftsman’s Guide to Software Structure and Design )是这方面的好资源。设计模式( Design Patterns)是每个工程师应该阅读的经典编程书籍。


27.间歇性地失败的测试会侵蚀测试套件的价值,以至于最终每个人都忽略测试运行的结果。修复或删除间歇性失败的测试是痛苦的,但值得努力。


28.一般来说,尤其是在测试中,等待一个具体的改变,而不是任意时间内sleeping。Voodoo sleeps 很难理解,而且会放慢测试套件。


29.至少要看到你的测试失败过一次。将一个蓄意的 bug 放入让它失败,或在测试行为完成之前运行测试。否则,你不知道你真的在测试。偶尔写写测试代码实际并不测试任何东西,或写永远不会失败的测试,都是很容易的。


30.最后,管理要点:持续的功能研发是开发软件的一个可怕方法。不让开发人员在工作感到骄傲, 就不会从中获得最大的利益。不解决技术债务,会拖慢开发速度,并导致更糟糕的、更多bug的产品。


原文作者:Michael Foord

原文链接:

https://opensource.com/article ... sting
 

微服务2017年度报告出炉:4大客户画像,15%传统企业已领跑

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

开篇:

如果在诸多热门云计算技术中,诸如容器、微服务、DevOps、OpenStack 等,找出一个最火的方向,那么非微服务莫属。尽管话题炙手可热,但对传统行业来说,微服务落地和方法论目前处于起步阶段。

本报告于2017年11月份展开,从驱动因素、落地现状、和容器关系、架构体系、未来趋势和落地方法论等方面对微服务进行了分析。希望能够为传统企业微服务决策、规划和实施提供依据和解决办法。

一、驱动因素

传统行业对IT效率的变革需求是微服务成长土壤,业务模式创新重塑导致系统更新频繁、应用复杂度急剧升高,传统架构不堪重负。

微服务架构具有明显的好处,尤其是在应对复杂业务系统的多变需求方面。在本次调研企业中,每个月都要进行业务系统更新的比例占63%,只有不到20%的企业半年以上更新一次系统。













加快互联网+步伐成为许多传统企业的必然选择。业务场景、用户习惯和行为在迅速变化,许多传统行业线上业务出现急速增长。

比如金融行业的移动支付、互联网理财等,汽车制造行业的营销、电商、售后服务等线上业务比例迅速提高。IT团队业务开发、迭代都以每月、甚至每周来计,需要7*24小时响应,这些给系统开发和运维带来极大挑战。

在IT对业务的响应和支撑方面,不同行业所面临的困扰略有不同,但总体差异不明显。调研显示,系统支撑方面排在前四的难题分别为:系统复杂性越来越高(28%),运维管理复杂度高,打造一支全栈运维团队困难(26%),线上访问压力大(19%),设备采购维护成本高(19%)。







在传统单体或SOA架构下,应用如果频繁升级更新,开发团队非常痛苦。企业的业务应用经过多年IT建设,系统非常庞大,要改动其中任何一小部分,都需要重新部署整个应用,敏捷开发和快速交付无从谈起。

传统企业在长期的IT建设过程中,通常大量使用外包团队,这导致采用的技术栈之间差异较大,统一管控和运维要求更高。需要运维7*24小时全天候值守、在线升级,并快速响应。

在此时脱颖而出的微服务技术,面对上述困惑几乎浑身优点:独立开发、独立部署、独立发布,去中心化管理,支持高并发高可用,支持丰富技术栈,企业可以根据需要灵活技术选型。

二、微服务落地现状

1、微服务客户画像

微服务架构在企业的使用情况可以分为四个层次:初级使用者、轻度使用者、中度使用者、以及重度使用者。初级使用者基本是传统架构,独立部署需求不突出,技术堆栈不成熟,需要较长的培育和成长期。轻度使用的企业边缘业务系统开始使用Spring Boot 或Spring Cloud等框架,但组件的使用尚不熟练。

中度使用者为使用Dubbo或Spring cloud时间较长,但还没有做周边配套的工具链。重度使用者是那些走在微服务架构改造前沿,具备微服务规划和体系,有自己研发实力的企业,通常是以技术见长的大型互联网公司。

2、15% 左右的调研企业引入了SpringCloud、Dubbo等微服务主流开发框架

此次调研中,6%的企业已经部分引入了Spring Cloud 开发框架,Spring Cloud 也被开发者认为是最好的开发框架。另外,9%的受访企业采用了 Dubbo 等其他微服务框架,也就是说引入了或考虑引入微服务架构的企业达15%。







此外,还有51%以上的企业在考虑往云原生方向转型。这是由于企业数字化转型背景下,IT要更好适应线上业务趋势的必然要求。加上国家政策层面对云服务的支持,传统企业云化是大势所趋。

* 3、微服务四大技术优势受青睐*

从IT技术发展趋势看,无论硬件、软件、还是基础架构都在朝着轻量化的方向发展。微服务通过化整为零的概念,将复杂的IT部署分解成更小、更独立的微服务。 相对传统的建设方法,传统企业更看重微服务如下四方面的优势:技术选型灵活,更轻松采用新架构和语言(28%)降低系统内部服务冗余,提升开发效率(27%)独立部署(22%)更好的容错机制(20%)







在涉及复杂项目时,和单体架构的对比中,微服务从多个角度显示出了压倒性的优势。

4、制造业开始发力、金融小试牛刀

这里所说制造业,是大制造的概念,包括制造、汽车、大型制造以及航空业等。这些行业往引入Spring Cloud、Dubbo等微服务开发框架的企业占比超过15%。制造业开始初步尝试微服务架构。 能看出制造业向“智造”转型的影响,今天的制造业结合了物联网、传感器、云计算、大数据等技术,人工智能技术正在工业、汽车驾驶等领域应用。大量新兴业务场景出现,服务变得复杂,产业的弯道超车带来了明显的微服务需求。
 







其次,需求明显的为金融行业,包括银行、保险、证券等。尤其是一些国有银行、股份制银行以及城商行等大行都走在架构改造的前列。在自己的创新业务,如手机银行、微信银行、互联网理财等业务上试水微服务架构。在核心业务系统方面,则相当谨慎。一方面是由于监管和政策的原因,另一方面,银行开发体系庞大,IT架构变革将是一件非常复杂的事情。

5、微服务推进障碍

微服务不是完美架构,会带来系统的各种复杂度,以及运维要求更高等诸多难点 微服务并不是一项横空出世的技术,事实上MicroService的概念已经诞生多年。除了组件和技术不成熟,企业业务模式不急迫的因素外,微服务本身也有自己的劣势。







本次调研,有近一半的企业会谈到对微服务的顾虑。比如部署以后的复杂度,后期运维管理的不友好等等。对于团队来说,搭建微服务架构上手难,运维效率低,运维成本高。另外,还可能带来团队之间沟通上的冲突,微服务需要与DevOps同步推进。微服务被分割成一个个独立的业务模块后,服务间通信接口设计非常重要。如何科学地将系统部署到服务器上,保证各个服务高效运行,更是难点。

微服务推进过程中有许多障碍。对微服务自身复杂度的担忧、缺少具备相关经验的专家、难以招募专业人才和使用相关工具是三个最普遍的障碍。其中对微服务复杂度的顾虑,排名前三的是运维要求和成本高,分布式架构的网络延迟、容错等挑战,以及较强的部署依赖性。

三、Docker与微服务

在接受调研的企业中,2017年在生产环境中采用Docker的比例为9%,测试环境使用达22%。而且规模越大的企业,尤其是服务器规模在500台以上的,是Docker容器的主要采用者。另外,正在考虑评估中的占到被调研企业的一半以上。企业的关注度急剧升高,Docker使用正在快速普及。





 

容器和微服务相辅相成,两大技术成熟的时间点非常契合。容器技术的成熟为微服务提供了得天独厚的客观条件。轻量化的容器是微服务的最佳运行环境,微服务应用只有在容器环境下才能保障运维效率的提升。同时,微服务应用架构对外在组件的管理会变得困难,需要用容器平台去管理中间件,才能发挥出更大价值。

四、微服务化是一个体系,从架构、工具到团队协同

1、企业微服务架构改造需要包括周边配套工具链在内的一整套微服务体系

采用微服务架构改造应用系统,不仅仅是选择开发框架本身,还要建设一套完整的体系架构。既要实现应用模块之间的解耦,还要实现统一管理。

微服务化体系,包括开发框架、以及周边配套工具链和组件,比如服务注册、服务发现、API网关、负载均衡、服务治理、配置中心、安全管理、与容器的结合、监控管理等等。一整套的体系建设是微服务真正的难点所在。

落地过程中,受访企业关注的功能包括,API网关(33%)、服务治理(27%)、配置中心(21%)、分布式任务调度(17%)、应用监控与报警(11%)、高并发(7%)等。这些组件可以根据自身的业务特性选择使用。







2、微服务落地方法论:咨询+产品工具+实施

在IT建设中,企业都希望将开发人员的精力放在自身业务系统的开发上,而工具的整合和使用则主要借助外部供应商的力量来做。软件外包商都有自己的发展历程,迅速改变技术架构不太现实。

另外,传统企业都有大量原有IT系统,掉头和转向不可能丢掉历史包袱,全部推翻重新建设。因此,企业一方面有架构之痛,另一方面不得不总是在业务系统快速上线和新架构选择之间平衡。

对于企业来说,最实际的微服务落地路径是,首先纳入微服务咨询,引入外部行业技术专家角色,站在企业架构的总体高度,帮助企业进行微服务体系规划,落地roadmap,然后借助一些产品和工具进行落地实施。

在本次调研中,有的企业鉴于微服务的优势和业务快速变化的需要,会在新项目建设时直接选择微服务架构进行开发,落地方法也不例外。

3、企业践行微服务的三种类型

目前微服务落地的企业可以分为:温柔型的变革者、业务倒逼型的强硬者、观望型的探索者。

具体来说,温柔的变革者从边缘非核心业务探索尝试新兴技术。渐进式实施、创新灵活多变业务是这类型客户微服务切入的关键词。也是大部分传统企业在切入微服务时,选择的路径。

本次参与调研的企业多是如此,在切入微服务时,选择了诸如测试流程、API网关、开发平台升级、测试环境快速部署等非核心业务进行技术验证。







业务倒逼型是那些企业核心业务系统在日常支撑中承受着巨大压力,必须进行架构改造,否则业务运转举步维艰。观望型的探索者,是那些出于业务考量,要看到行业标杆案例,明确收益和价值,以及技术风险和可靠性充分把握的情况下,才会投入资源开始改造。

4.微服务落地需要从上到下推动和密切团队协同

微服务应用的构建依赖组织结构的变化,它按照业务,而不是技术来划分组织,在推进过程中会受到从上到下的压力,因此必须有决策层的支持和推动。同时,需要团队更好的协同,小团队作战,打破团队间的高墙,减少沟通成本。上了微服务的受访企业对搭建一支敏捷团队都感受很迫切。

五、Service Mesh下一代微服务抢滩登陆

预计两年内服务网格技术将呈现爆发之势

本次的受访者中,有42%表示听说过 ServiceMesh 这一新兴技术理念,但只有6%的受访者对该技术有过一些研究。







微服务带来的复杂度让企业头疼,尤其是服务间通信,如何保证服务间通信的端到端性能和可靠性,催生了下一代微服务Service mesh。2017年,ServiceMesh 经过技术拥趸、技术社区和媒体的反复布道,迅速被业界了解。

Service Mesh 是服务间通信层,可以提供安全、快速、可靠的服务间通讯。在过去的一年中,Service Mesh 已经成为微服务技术栈里的一个关键组件,被誉为“下一代微服务”。

Conduit、Istio 等Service Mesh技术在市场上已形成激烈的竞争,国内外企业开始纷纷站队。国外,一些有高负载业务流量的公司都在他们的生产应用里加入了Service Mesh。国内前沿技术公司开始围绕SpringCloud等开发体系,为客户提供成熟的解决方案和工具产品。同时,探索基于 ServiceMesh 的新方案,积极拥抱Istio/Conduit。

当然对于传统企业来说,技术的先进性是为了保障业务需求的快速变化和发展,而不是一味追求新兴。受访企业表示,一方面会主动关注新技术的最新动向,另一方面在考虑落地时,也要关注新技术的可靠性和有例可循,有无业界最佳实践背书。

六、结论

微服务的核心使命是简化开发,提高IT系统对业务的支撑能力。通过本次调研,我们可以得出如下一些结论:

1.传统行业新兴业务对IT效率的变革需求,业务模式创新重塑要求IT快速响应,是今天微服务炙手可热的主要驱动因素。从目前微服务落地的状态预估有两年左右的培育和成长期。







评估一家企业是否需要上微服务,主要考察这五大关键要素:数据量和业务复杂度,团队规模,应对业务流量变化,是否需要足够的容错容灾,以及功能重复度和差错成本。

2. 实施微服务的理想技术条件包括:进程隔离、数据库表隔离,以及通过公开接口访问。







3. 微服务架构在企业的使用可以分为四个层次:初级使用者、轻度使用者、中度使用者,以及重度使用者。







以技术见长的大型互联网公司首先引领了微服务的风潮,国内制造、金融等大型龙头企业中也有佼佼者开始规划微服务体系,且具备较强的研发实力。大部分企业还处在初步尝试,不成体系,寻找技术和专家力量探讨解决方案的阶段。

4.微服务和容器共生:容器和微服务相辅相成,天生一对。Docker的成熟,让微服务推广和落地更加可靠、方便。随着Docker和微服务架构组件等相关技术的逐步成熟,微服务架构将逐步落地传统企业。 







5.微服务落地方法论:微服务主要用来解决系统的复杂性问题,企业客户对于如何实施微服务并不清晰,同时有诸多顾虑。受企业客户青睐的落地方法是:微服务咨询+产品工具+实施。 







6.微服务落地策略:微服务正成为许多企业构建应用时的首选。微服务并不缺乏受众,有的企业将微服务用于新应用开发,有的关注将单体应用迁移到微服务架构。微服务改造循序渐进,快速演化只会适得其反。另外,落地过程中注意开发和运维部门的协同,进行组织内管理创新。 







关于调研对象

本次调研我们总计收到了来自182家企业受访者的调研问卷,并现场调研部分受访企业。覆盖制造/航空、金融、互联网、地产、交通物流和零售等行业,受访者包括CIO、CTO等IT高管,及开发、基础架构部门IT人员。

参考资料: 
1.The State of Microservices Survey 2017 – Eight Trends You Need to Know 
https://dzone.com/articles/the ... trend 
2、Microservices: Breaking Down the Monolith 
https://dzone.com/guides/micro ... olith 
3.微服务企业级落地将会带来哪些转变? 
http://mp.weixin.qq.com/s/3LkU4OwpgSPdFFY5__dheQ 
4.深度剖析微服务架构的九大特征 
http://developer.51cto.com/art/201608/516401.htm 查看全部
开篇:

如果在诸多热门云计算技术中,诸如容器、微服务、DevOps、OpenStack 等,找出一个最火的方向,那么非微服务莫属。尽管话题炙手可热,但对传统行业来说,微服务落地和方法论目前处于起步阶段。

本报告于2017年11月份展开,从驱动因素、落地现状、和容器关系、架构体系、未来趋势和落地方法论等方面对微服务进行了分析。希望能够为传统企业微服务决策、规划和实施提供依据和解决办法。

一、驱动因素

传统行业对IT效率的变革需求是微服务成长土壤,业务模式创新重塑导致系统更新频繁、应用复杂度急剧升高,传统架构不堪重负。

微服务架构具有明显的好处,尤其是在应对复杂业务系统的多变需求方面。在本次调研企业中,每个月都要进行业务系统更新的比例占63%,只有不到20%的企业半年以上更新一次系统。


1.jpg


2.jpg



加快互联网+步伐成为许多传统企业的必然选择。业务场景、用户习惯和行为在迅速变化,许多传统行业线上业务出现急速增长。

比如金融行业的移动支付、互联网理财等,汽车制造行业的营销、电商、售后服务等线上业务比例迅速提高。IT团队业务开发、迭代都以每月、甚至每周来计,需要7*24小时响应,这些给系统开发和运维带来极大挑战。

在IT对业务的响应和支撑方面,不同行业所面临的困扰略有不同,但总体差异不明显。调研显示,系统支撑方面排在前四的难题分别为:系统复杂性越来越高(28%),运维管理复杂度高,打造一支全栈运维团队困难(26%),线上访问压力大(19%),设备采购维护成本高(19%)。

3.jpg



在传统单体或SOA架构下,应用如果频繁升级更新,开发团队非常痛苦。企业的业务应用经过多年IT建设,系统非常庞大,要改动其中任何一小部分,都需要重新部署整个应用,敏捷开发和快速交付无从谈起。

传统企业在长期的IT建设过程中,通常大量使用外包团队,这导致采用的技术栈之间差异较大,统一管控和运维要求更高。需要运维7*24小时全天候值守、在线升级,并快速响应。

在此时脱颖而出的微服务技术,面对上述困惑几乎浑身优点:独立开发、独立部署、独立发布,去中心化管理,支持高并发高可用,支持丰富技术栈,企业可以根据需要灵活技术选型。

二、微服务落地现状

1、微服务客户画像


微服务架构在企业的使用情况可以分为四个层次:初级使用者、轻度使用者、中度使用者、以及重度使用者。初级使用者基本是传统架构,独立部署需求不突出,技术堆栈不成熟,需要较长的培育和成长期。轻度使用的企业边缘业务系统开始使用Spring Boot 或Spring Cloud等框架,但组件的使用尚不熟练。

中度使用者为使用Dubbo或Spring cloud时间较长,但还没有做周边配套的工具链。重度使用者是那些走在微服务架构改造前沿,具备微服务规划和体系,有自己研发实力的企业,通常是以技术见长的大型互联网公司。

2、15% 左右的调研企业引入了SpringCloud、Dubbo等微服务主流开发框架

此次调研中,6%的企业已经部分引入了Spring Cloud 开发框架,Spring Cloud 也被开发者认为是最好的开发框架。另外,9%的受访企业采用了 Dubbo 等其他微服务框架,也就是说引入了或考虑引入微服务架构的企业达15%。

image005.jpg



此外,还有51%以上的企业在考虑往云原生方向转型。这是由于企业数字化转型背景下,IT要更好适应线上业务趋势的必然要求。加上国家政策层面对云服务的支持,传统企业云化是大势所趋。

* 3、微服务四大技术优势受青睐*

从IT技术发展趋势看,无论硬件、软件、还是基础架构都在朝着轻量化的方向发展。微服务通过化整为零的概念,将复杂的IT部署分解成更小、更独立的微服务。 相对传统的建设方法,传统企业更看重微服务如下四方面的优势:技术选型灵活,更轻松采用新架构和语言(28%)降低系统内部服务冗余,提升开发效率(27%)独立部署(22%)更好的容错机制(20%)


image006.jpg


在涉及复杂项目时,和单体架构的对比中,微服务从多个角度显示出了压倒性的优势。

4、制造业开始发力、金融小试牛刀

这里所说制造业,是大制造的概念,包括制造、汽车、大型制造以及航空业等。这些行业往引入Spring Cloud、Dubbo等微服务开发框架的企业占比超过15%。制造业开始初步尝试微服务架构。 能看出制造业向“智造”转型的影响,今天的制造业结合了物联网、传感器、云计算、大数据等技术,人工智能技术正在工业、汽车驾驶等领域应用。大量新兴业务场景出现,服务变得复杂,产业的弯道超车带来了明显的微服务需求。
 

image007.jpg



其次,需求明显的为金融行业,包括银行、保险、证券等。尤其是一些国有银行、股份制银行以及城商行等大行都走在架构改造的前列。在自己的创新业务,如手机银行、微信银行、互联网理财等业务上试水微服务架构。在核心业务系统方面,则相当谨慎。一方面是由于监管和政策的原因,另一方面,银行开发体系庞大,IT架构变革将是一件非常复杂的事情。

5、微服务推进障碍

微服务不是完美架构,会带来系统的各种复杂度,以及运维要求更高等诸多难点 微服务并不是一项横空出世的技术,事实上MicroService的概念已经诞生多年。除了组件和技术不成熟,企业业务模式不急迫的因素外,微服务本身也有自己的劣势。

image008.jpg



本次调研,有近一半的企业会谈到对微服务的顾虑。比如部署以后的复杂度,后期运维管理的不友好等等。对于团队来说,搭建微服务架构上手难,运维效率低,运维成本高。另外,还可能带来团队之间沟通上的冲突,微服务需要与DevOps同步推进。微服务被分割成一个个独立的业务模块后,服务间通信接口设计非常重要。如何科学地将系统部署到服务器上,保证各个服务高效运行,更是难点。

微服务推进过程中有许多障碍。对微服务自身复杂度的担忧、缺少具备相关经验的专家、难以招募专业人才和使用相关工具是三个最普遍的障碍。其中对微服务复杂度的顾虑,排名前三的是运维要求和成本高,分布式架构的网络延迟、容错等挑战,以及较强的部署依赖性。

三、Docker与微服务

在接受调研的企业中,2017年在生产环境中采用Docker的比例为9%,测试环境使用达22%。而且规模越大的企业,尤其是服务器规模在500台以上的,是Docker容器的主要采用者。另外,正在考虑评估中的占到被调研企业的一半以上。企业的关注度急剧升高,Docker使用正在快速普及。

image009.jpg

 

容器和微服务相辅相成,两大技术成熟的时间点非常契合。容器技术的成熟为微服务提供了得天独厚的客观条件。轻量化的容器是微服务的最佳运行环境,微服务应用只有在容器环境下才能保障运维效率的提升。同时,微服务应用架构对外在组件的管理会变得困难,需要用容器平台去管理中间件,才能发挥出更大价值。

四、微服务化是一个体系,从架构、工具到团队协同

1、企业微服务架构改造需要包括周边配套工具链在内的一整套微服务体系

采用微服务架构改造应用系统,不仅仅是选择开发框架本身,还要建设一套完整的体系架构。既要实现应用模块之间的解耦,还要实现统一管理。

微服务化体系,包括开发框架、以及周边配套工具链和组件,比如服务注册、服务发现、API网关、负载均衡、服务治理、配置中心、安全管理、与容器的结合、监控管理等等。一整套的体系建设是微服务真正的难点所在。

落地过程中,受访企业关注的功能包括,API网关(33%)、服务治理(27%)、配置中心(21%)、分布式任务调度(17%)、应用监控与报警(11%)、高并发(7%)等。这些组件可以根据自身的业务特性选择使用。


image010.jpg


2、微服务落地方法论:咨询+产品工具+实施

在IT建设中,企业都希望将开发人员的精力放在自身业务系统的开发上,而工具的整合和使用则主要借助外部供应商的力量来做。软件外包商都有自己的发展历程,迅速改变技术架构不太现实。

另外,传统企业都有大量原有IT系统,掉头和转向不可能丢掉历史包袱,全部推翻重新建设。因此,企业一方面有架构之痛,另一方面不得不总是在业务系统快速上线和新架构选择之间平衡。

对于企业来说,最实际的微服务落地路径是,首先纳入微服务咨询,引入外部行业技术专家角色,站在企业架构的总体高度,帮助企业进行微服务体系规划,落地roadmap,然后借助一些产品和工具进行落地实施。

在本次调研中,有的企业鉴于微服务的优势和业务快速变化的需要,会在新项目建设时直接选择微服务架构进行开发,落地方法也不例外。

3、企业践行微服务的三种类型

目前微服务落地的企业可以分为:温柔型的变革者、业务倒逼型的强硬者、观望型的探索者。

具体来说,温柔的变革者从边缘非核心业务探索尝试新兴技术。渐进式实施、创新灵活多变业务是这类型客户微服务切入的关键词。也是大部分传统企业在切入微服务时,选择的路径。

本次参与调研的企业多是如此,在切入微服务时,选择了诸如测试流程、API网关、开发平台升级、测试环境快速部署等非核心业务进行技术验证。


image011.jpg


业务倒逼型是那些企业核心业务系统在日常支撑中承受着巨大压力,必须进行架构改造,否则业务运转举步维艰。观望型的探索者,是那些出于业务考量,要看到行业标杆案例,明确收益和价值,以及技术风险和可靠性充分把握的情况下,才会投入资源开始改造。

4.微服务落地需要从上到下推动和密切团队协同

微服务应用的构建依赖组织结构的变化,它按照业务,而不是技术来划分组织,在推进过程中会受到从上到下的压力,因此必须有决策层的支持和推动。同时,需要团队更好的协同,小团队作战,打破团队间的高墙,减少沟通成本。上了微服务的受访企业对搭建一支敏捷团队都感受很迫切。

五、Service Mesh下一代微服务抢滩登陆

预计两年内服务网格技术将呈现爆发之势

本次的受访者中,有42%表示听说过 ServiceMesh 这一新兴技术理念,但只有6%的受访者对该技术有过一些研究。

image012.jpg



微服务带来的复杂度让企业头疼,尤其是服务间通信,如何保证服务间通信的端到端性能和可靠性,催生了下一代微服务Service mesh。2017年,ServiceMesh 经过技术拥趸、技术社区和媒体的反复布道,迅速被业界了解。

Service Mesh 是服务间通信层,可以提供安全、快速、可靠的服务间通讯。在过去的一年中,Service Mesh 已经成为微服务技术栈里的一个关键组件,被誉为“下一代微服务”。

Conduit、Istio 等Service Mesh技术在市场上已形成激烈的竞争,国内外企业开始纷纷站队。国外,一些有高负载业务流量的公司都在他们的生产应用里加入了Service Mesh。国内前沿技术公司开始围绕SpringCloud等开发体系,为客户提供成熟的解决方案和工具产品。同时,探索基于 ServiceMesh 的新方案,积极拥抱Istio/Conduit。

当然对于传统企业来说,技术的先进性是为了保障业务需求的快速变化和发展,而不是一味追求新兴。受访企业表示,一方面会主动关注新技术的最新动向,另一方面在考虑落地时,也要关注新技术的可靠性和有例可循,有无业界最佳实践背书。

六、结论

微服务的核心使命是简化开发,提高IT系统对业务的支撑能力。通过本次调研,我们可以得出如下一些结论:

1.传统行业新兴业务对IT效率的变革需求,业务模式创新重塑要求IT快速响应,是今天微服务炙手可热的主要驱动因素。从目前微服务落地的状态预估有两年左右的培育和成长期。


image013.jpg


评估一家企业是否需要上微服务,主要考察这五大关键要素:数据量和业务复杂度,团队规模,应对业务流量变化,是否需要足够的容错容灾,以及功能重复度和差错成本。

2. 实施微服务的理想技术条件包括:进程隔离、数据库表隔离,以及通过公开接口访问。

image014.jpg



3. 微服务架构在企业的使用可以分为四个层次:初级使用者、轻度使用者、中度使用者,以及重度使用者。

image015.jpg



以技术见长的大型互联网公司首先引领了微服务的风潮,国内制造、金融等大型龙头企业中也有佼佼者开始规划微服务体系,且具备较强的研发实力。大部分企业还处在初步尝试,不成体系,寻找技术和专家力量探讨解决方案的阶段。

4.微服务和容器共生:容器和微服务相辅相成,天生一对。Docker的成熟,让微服务推广和落地更加可靠、方便。随着Docker和微服务架构组件等相关技术的逐步成熟,微服务架构将逐步落地传统企业。 


image016.jpg


5.微服务落地方法论:微服务主要用来解决系统的复杂性问题,企业客户对于如何实施微服务并不清晰,同时有诸多顾虑。受企业客户青睐的落地方法是:微服务咨询+产品工具+实施。 

image017.jpg



6.微服务落地策略:微服务正成为许多企业构建应用时的首选。微服务并不缺乏受众,有的企业将微服务用于新应用开发,有的关注将单体应用迁移到微服务架构。微服务改造循序渐进,快速演化只会适得其反。另外,落地过程中注意开发和运维部门的协同,进行组织内管理创新。 

image018.jpg



关于调研对象

本次调研我们总计收到了来自182家企业受访者的调研问卷,并现场调研部分受访企业。覆盖制造/航空、金融、互联网、地产、交通物流和零售等行业,受访者包括CIO、CTO等IT高管,及开发、基础架构部门IT人员。

参考资料: 
1.The State of Microservices Survey 2017 – Eight Trends You Need to Know 
https://dzone.com/articles/the ... trend 
2、Microservices: Breaking Down the Monolith 
https://dzone.com/guides/micro ... olith 
3.微服务企业级落地将会带来哪些转变? 
http://mp.weixin.qq.com/s/3LkU4OwpgSPdFFY5__dheQ 
4.深度剖析微服务架构的九大特征 
http://developer.51cto.com/art/201608/516401.htm

容器之后的下一个明星,关于无服务器(Serverless)架构你要搞懂的8件事

杨y 发表了文章 • 0 个评论 • 78 次浏览 • 2018-01-04 06:52 • 来自相关话题

无服务器计算,虽然神秘,但一定会成为IT行业最有力的工具之一。这种可能改变游戏规则的技术虽然不是全新的,但就像之前的容器技术一样,有一些神化和误解。
1
1什么是无服务器(Serverless)计算?
无服务器计算允许企业构建、运行应用和服务而不用去考虑服务器。无服务器应用不需要管理任何服务器,而且任何类型的应用或后端服务都可以构建为无服务器应用。运行应用以及应用高可用所需要的一切,都由云服务商来提供。
无服务器应用程序有四大优势:
1)不需要管理服务– 不需要提供或维护任何的服务器,不需要安装任何的软件或运行时。
2)弹性扩缩–应用程序扩缩能自动完成或是通过调整其资源使用量来调整容量,而不是通过增减服务器的数量。
3)高可用-无服务器应用程序内置高可用和容错。无需考虑高可用,运行应用的服务默认提供高可用。
4)没有闲置损耗-不需要对计算和存储之类的服务预留容量。如果代码没有运行,就不会收费。
构建无服务器应用程序意味着开发者可以专注在产品代码上,而无须管理和操作云端或本地的服务器或运行时。
2无服务器(Serverless)计算如何工作?
与使用虚拟机或一些底层的技术来部署和管理应用程序相比,无服务器计算提供了一种更高级别的抽象。因为它们有不同的抽象和“触发器”的集合。
拿计算来讲,这种抽象有一个特定函数和抽象的触发器,它通常是一个事件。以数据库为例,这种抽象也许是一个表,而触发器相当于表的查询或搜索,或者通过在表中做一些事情而生成的事件。
比如一款手机游戏,允许用户在不同的平台上为全球顶级玩家使用高分数表。当请求此信息时,请求从应用程序到API接口。API接口或许会触发 aws 的Lambda函数,或者无服务器函数,这些函数再从数据库表中获取到数据流,返回包含前五名分数的一定格式的数据。
一旦构建完成,应用程序的功能就可以在基于移动和基于 web 的游戏版本中重用。
这跟设置服务器不同,不是必须要有Amazon EC2实例或服务器,然后等待请求。环境由事件触发,而响应事件所需的逻辑只在响应时执行。这意味着,运行函数的资源只有在函数运行时被创建,产生一种非常高效的方法来构建应用程序。
3适用于哪些场景?
无服务器计算适合于任何事件驱动的各种不同的用例。这包括物联网,移动应用,基于网络的应用程序和聊天机器人。事件是由人的动作(比如按下按钮),传感器或者系统中的数据流产生。
这方面的一个例子是,Thomson Reuters(人名)使用AWS Lambda来加载和处理数据流,而无需提供或管理任何服务器。Thomson Reuters建立了一个解决方案,使其能够捕捉、分析和可视化其产品所生成的分析数据,提供帮助产品团队不断改进用户体验的见解。
AWS Lambda只在通过与其他AWS服务、Kinesis和AmazonS3集成的新数据条目触发时运行代码。
在事件驱动下,当代码运行时,公司只收取计算处理的费用,这是非常节约成本的。
4不适用哪些场景?
对于已经构建的遗留应用程序来说,这不一定是一个完全的解决方案。如果是一个单体应用或者应用需要运行在操作系统级别,这样的应用就不适合在无服务器平台上运行。这并不意味着这样的应用没法实现无服务器架构,它只是意味着需要重新构建应用程序。
一个很好的例子是web应用程序,可以在应用程序服务器(如Tomcat)中将其作为一个大型的单体job运行。如果要将应用程序分解为复合函数集,则可以使用无服务器模型实现所有的新功能。随着时间的推移,旧版本应用程序的使用级别越来越小,这些新的无服务器组件的使用率随着使用量的增加而增加。对于这样的客户,都有一个过渡模型,客户可以遵循这种过渡模式,将传统的基于机器的应用程序架构迁移到基于功能的架构。
5无服务器(Serverless)计算贵吗?
并不贵。只需要支付企业所使用的部分,没有任何与无服务器计算相关的成本。特别对于小的用例,应用程序使用随时间变化大的企业是非常划算的。
对于希望管理工作负载和操作的客户来说,它也非常划算,因为它可以使客户避免成本,例如容量规划或部署工具。许多AWS的客户,现在正在尝试用服务器来提高敏捷度,同时也节省了成本。健康零食公司Graze有许多使用for AWS的方法,包括将分析数据实时上传至亚马逊RedShift、管理备份和检查GitHub拉请求,希望在未来几个月内将其使用量增加两到三倍。
6无服务器(Serverless)的行业炒作
无服务器计算得到了开发人员的积极响应。在以资源有效的方式交付应用程序时,它提供了更多的选项和可能性。
很多大型的企业,比如Netflix,已经在探索无服务器计算,希望解放开发人员的时间。Netflix使用AWS Lambda来构建基于规则的自我管理基础设施,并替换低效的流程,减少错误的速率,为开发人员节省宝贵的时间。
以前,云开发者必须使用那些耗费大量人力和时间的机器。无服务器技术允许开发人员在几分钟内运行测试和产品。开发人员直接控制部署时间以及如何部署,通过建模框架控制应用架构。还允许发布自己的产品并亲自体验。
2
容器和无服务器(Serverless)
无服务器计算和容器之间正在酝酿一场战斗——当尘埃落定时,谁会倒下?会是容器吗?
如前所述,无服务器具备一些明显的优势。比如节省成本,提高IT支出的效率,减少资源和维护需求,允许开发人员和IT人员专注于高价值的任务等等。这也是为什么人们会对这项技术充满热情的原因。但是,通往无服务器的路径并不轻松。
SetfiveConsulting 的合伙人 Ashish Datta 说,将基于容器的架构迁移到无服务器通常需要重新架构系统的重要部分。
“与从虚拟机到容器的转换相比,从容器到无服务器的转换更有戏剧性,因为容器和无服务器之间的计算环境发生了根本性的变化。”
相反,从虚拟机到容器的迁移更为直接,因为这实际上只是部署哲学的变化。
Stackery CEO Nate Taggart说,最大的障碍是企业无法轻易地迁移到无服务器架构上。
“(无服务器应用程序)必须是为无服务器基础设施设计的。这对于新的开发来说可能是相当经济的,但是迁移遗留应用程序将是很繁重的,在某些情况下甚至是不可能的。
今天的无服务器产品有资源的限制,Taggert解释道,包括内存、计算和时间限制;有限的语言支持;以及在请求之间管理状态的特殊考虑。所有这些都必须“从一开始就融入到应用程序设计中”,Taggert说。
PubNub的产品营销总监James Riseman说,迁移到无服务器架构还需要对现有基础设施进行重大的反思。
“无服务器计算需要一个非常现代的、组件化的架构。系统和应用程序必须被分解成离散的逻辑函数,而要保证这样的质量企业会失去控制。” JamesRiseman 表示。
无服务器的另一个问题是定价。“公司是按照每笔交易或每秒钟计费,而不是按照传统的基础设施条款,”Siseman说。“这使得定价更加难以预测。”
除了地址迁移需求之外,转向无服务器计算还会导致思维模式的改变。
“最大的障碍之一是,需要考虑在离散的单元中计算资源,而不是始终占用进行计算。”这与对内存使用量和运行时等框架的限制相吻合,比如Amazon Lambda这样的框架。“Atta说道。
1对手还是盟友?
撇开正反两方面的因素不说,在面对面的交锋中,容器和无服务器是相互排斥的解决方案。但是每个人都说这样想是错误的。
SwymSystems CEO兼首席顾问Todd Millecam 表示,这是一种苹果和橘子的比较。“两者都有使用,如果观察大多数无服务器技术的运行方式,它们只是在后台运行容器。”
无服务器和容器是互相补充而并非重叠的角色。Taggart说,虽然两者都可以用于计算任务,但每个任务都有其优缺点。无服务器是一种理想的、可预测的、具有小型资源需求和短期事务的工作负载。
容器对于长时运行的流程和可预测的工作负载具有优势。容器在应用程序设计方面也提供了更多的灵活性,但需要对底层基础架构进行更多的管理。
 “作为一个无服务器操作控制台产品,我们有一个几乎完全没有服务器的后端,”Taggart补充说,但是仍然使用容器来处理某些工作负载,在这些工作负载中,它们是更好的工作工具
2Serverless是未来吗?
看来,关于容器式微的谣言被夸大了。
Datta说,不同的架构和应用程序总是需要不同程度的抽象,同样,不同的团队也会对做出不同的权衡。
正如容器没有取代虚拟机,虚拟机也没有取代裸金属的服务器。抽象不会成为“更接近金属”的解决方案的生死存亡的威胁。
无服务器,应该被看作是技术的进化。大多数观察者警告说,无服务器仍然不成熟,还没有建立架构模型和健壮的开发工具。这意味着将企业应用程序的命运与特定的云供应商绑定,将带来自身的风险。
因此,尽管它有巨大的潜力,但可能需要数年才能在企业中获得广泛的应用。
同时,无服务器将会对创业公司产生重大影响。
 “无服务器计算提供了一种托管代码的方法,并以很低廉的成本在web上可用。在拥有活跃的用户基础之前,无服务器是构建web应用程序的一种划算的方式。”Millecam说道。
不过,数字机构POP CTO Jake Bennett 表示,随着无服务计算技术的成熟,架构师会发现无服务器将越来越难以抗拒。“无服务器计算解决了太多被忽视的问题。将对可伸缩性问题的关注转移给第三方供应商,是每个开发人员的梦想,让别人关心服务器维护是IT运维人员的一种幻想。”
 
原文链接:
1、Everything you need to know about Serverless Computing
https://www.tuicool.com/articles/yMZVfev
2、Serverless and containers: Is a throw down under way?
https://www.tuicool.com/articles/BvUziyY 查看全部

无服务器计算,虽然神秘,但一定会成为IT行业最有力的工具之一。这种可能改变游戏规则的技术虽然不是全新的,但就像之前的容器技术一样,有一些神化和误解。
1
1什么是无服务器(Serverless)计算?
无服务器计算允许企业构建、运行应用和服务而不用去考虑服务器。无服务器应用不需要管理任何服务器,而且任何类型的应用或后端服务都可以构建为无服务器应用。运行应用以及应用高可用所需要的一切,都由云服务商来提供。
无服务器应用程序有四大优势:
1)不需要管理服务– 不需要提供或维护任何的服务器,不需要安装任何的软件或运行时。
2)弹性扩缩–应用程序扩缩能自动完成或是通过调整其资源使用量来调整容量,而不是通过增减服务器的数量。
3)高可用-无服务器应用程序内置高可用和容错。无需考虑高可用,运行应用的服务默认提供高可用。
4)没有闲置损耗-不需要对计算和存储之类的服务预留容量。如果代码没有运行,就不会收费。
构建无服务器应用程序意味着开发者可以专注在产品代码上,而无须管理和操作云端或本地的服务器或运行时。
2无服务器(Serverless)计算如何工作?
与使用虚拟机或一些底层的技术来部署和管理应用程序相比,无服务器计算提供了一种更高级别的抽象。因为它们有不同的抽象和“触发器”的集合。
拿计算来讲,这种抽象有一个特定函数和抽象的触发器,它通常是一个事件。以数据库为例,这种抽象也许是一个表,而触发器相当于表的查询或搜索,或者通过在表中做一些事情而生成的事件。
比如一款手机游戏,允许用户在不同的平台上为全球顶级玩家使用高分数表。当请求此信息时,请求从应用程序到API接口。API接口或许会触发 aws 的Lambda函数,或者无服务器函数,这些函数再从数据库表中获取到数据流,返回包含前五名分数的一定格式的数据。
一旦构建完成,应用程序的功能就可以在基于移动和基于 web 的游戏版本中重用。
这跟设置服务器不同,不是必须要有Amazon EC2实例或服务器,然后等待请求。环境由事件触发,而响应事件所需的逻辑只在响应时执行。这意味着,运行函数的资源只有在函数运行时被创建,产生一种非常高效的方法来构建应用程序。
3适用于哪些场景?
无服务器计算适合于任何事件驱动的各种不同的用例。这包括物联网,移动应用,基于网络的应用程序和聊天机器人。事件是由人的动作(比如按下按钮),传感器或者系统中的数据流产生。
这方面的一个例子是,Thomson Reuters(人名)使用AWS Lambda来加载和处理数据流,而无需提供或管理任何服务器。Thomson Reuters建立了一个解决方案,使其能够捕捉、分析和可视化其产品所生成的分析数据,提供帮助产品团队不断改进用户体验的见解。
AWS Lambda只在通过与其他AWS服务、Kinesis和AmazonS3集成的新数据条目触发时运行代码。
在事件驱动下,当代码运行时,公司只收取计算处理的费用,这是非常节约成本的。
4不适用哪些场景?
对于已经构建的遗留应用程序来说,这不一定是一个完全的解决方案。如果是一个单体应用或者应用需要运行在操作系统级别,这样的应用就不适合在无服务器平台上运行。这并不意味着这样的应用没法实现无服务器架构,它只是意味着需要重新构建应用程序。
一个很好的例子是web应用程序,可以在应用程序服务器(如Tomcat)中将其作为一个大型的单体job运行。如果要将应用程序分解为复合函数集,则可以使用无服务器模型实现所有的新功能。随着时间的推移,旧版本应用程序的使用级别越来越小,这些新的无服务器组件的使用率随着使用量的增加而增加。对于这样的客户,都有一个过渡模型,客户可以遵循这种过渡模式,将传统的基于机器的应用程序架构迁移到基于功能的架构。
5无服务器(Serverless)计算贵吗?
并不贵。只需要支付企业所使用的部分,没有任何与无服务器计算相关的成本。特别对于小的用例,应用程序使用随时间变化大的企业是非常划算的。
对于希望管理工作负载和操作的客户来说,它也非常划算,因为它可以使客户避免成本,例如容量规划或部署工具。许多AWS的客户,现在正在尝试用服务器来提高敏捷度,同时也节省了成本。健康零食公司Graze有许多使用for AWS的方法,包括将分析数据实时上传至亚马逊RedShift、管理备份和检查GitHub拉请求,希望在未来几个月内将其使用量增加两到三倍。
6无服务器(Serverless)的行业炒作
无服务器计算得到了开发人员的积极响应。在以资源有效的方式交付应用程序时,它提供了更多的选项和可能性。
很多大型的企业,比如Netflix,已经在探索无服务器计算,希望解放开发人员的时间。Netflix使用AWS Lambda来构建基于规则的自我管理基础设施,并替换低效的流程,减少错误的速率,为开发人员节省宝贵的时间。
以前,云开发者必须使用那些耗费大量人力和时间的机器。无服务器技术允许开发人员在几分钟内运行测试和产品。开发人员直接控制部署时间以及如何部署,通过建模框架控制应用架构。还允许发布自己的产品并亲自体验。
2
容器和无服务器(Serverless)
无服务器计算和容器之间正在酝酿一场战斗——当尘埃落定时,谁会倒下?会是容器吗?
如前所述,无服务器具备一些明显的优势。比如节省成本,提高IT支出的效率,减少资源和维护需求,允许开发人员和IT人员专注于高价值的任务等等。这也是为什么人们会对这项技术充满热情的原因。但是,通往无服务器的路径并不轻松。
SetfiveConsulting 的合伙人 Ashish Datta 说,将基于容器的架构迁移到无服务器通常需要重新架构系统的重要部分。
“与从虚拟机到容器的转换相比,从容器到无服务器的转换更有戏剧性,因为容器和无服务器之间的计算环境发生了根本性的变化。”
相反,从虚拟机到容器的迁移更为直接,因为这实际上只是部署哲学的变化。
Stackery CEO Nate Taggart说,最大的障碍是企业无法轻易地迁移到无服务器架构上。
“(无服务器应用程序)必须是为无服务器基础设施设计的。这对于新的开发来说可能是相当经济的,但是迁移遗留应用程序将是很繁重的,在某些情况下甚至是不可能的。
今天的无服务器产品有资源的限制,Taggert解释道,包括内存、计算和时间限制;有限的语言支持;以及在请求之间管理状态的特殊考虑。所有这些都必须“从一开始就融入到应用程序设计中”,Taggert说。
PubNub的产品营销总监James Riseman说,迁移到无服务器架构还需要对现有基础设施进行重大的反思。
“无服务器计算需要一个非常现代的、组件化的架构。系统和应用程序必须被分解成离散的逻辑函数,而要保证这样的质量企业会失去控制。” JamesRiseman 表示。
无服务器的另一个问题是定价。“公司是按照每笔交易或每秒钟计费,而不是按照传统的基础设施条款,”Siseman说。“这使得定价更加难以预测。”
除了地址迁移需求之外,转向无服务器计算还会导致思维模式的改变。
“最大的障碍之一是,需要考虑在离散的单元中计算资源,而不是始终占用进行计算。”这与对内存使用量和运行时等框架的限制相吻合,比如Amazon Lambda这样的框架。“Atta说道。
1对手还是盟友?
撇开正反两方面的因素不说,在面对面的交锋中,容器和无服务器是相互排斥的解决方案。但是每个人都说这样想是错误的。
SwymSystems CEO兼首席顾问Todd Millecam 表示,这是一种苹果和橘子的比较。“两者都有使用,如果观察大多数无服务器技术的运行方式,它们只是在后台运行容器。”
无服务器和容器是互相补充而并非重叠的角色。Taggart说,虽然两者都可以用于计算任务,但每个任务都有其优缺点。无服务器是一种理想的、可预测的、具有小型资源需求和短期事务的工作负载。
容器对于长时运行的流程和可预测的工作负载具有优势。容器在应用程序设计方面也提供了更多的灵活性,但需要对底层基础架构进行更多的管理。
 “作为一个无服务器操作控制台产品,我们有一个几乎完全没有服务器的后端,”Taggart补充说,但是仍然使用容器来处理某些工作负载,在这些工作负载中,它们是更好的工作工具
2Serverless是未来吗?
看来,关于容器式微的谣言被夸大了。
Datta说,不同的架构和应用程序总是需要不同程度的抽象,同样,不同的团队也会对做出不同的权衡。
正如容器没有取代虚拟机,虚拟机也没有取代裸金属的服务器。抽象不会成为“更接近金属”的解决方案的生死存亡的威胁。
无服务器,应该被看作是技术的进化。大多数观察者警告说,无服务器仍然不成熟,还没有建立架构模型和健壮的开发工具。这意味着将企业应用程序的命运与特定的云供应商绑定,将带来自身的风险。
因此,尽管它有巨大的潜力,但可能需要数年才能在企业中获得广泛的应用。
同时,无服务器将会对创业公司产生重大影响。
 “无服务器计算提供了一种托管代码的方法,并以很低廉的成本在web上可用。在拥有活跃的用户基础之前,无服务器是构建web应用程序的一种划算的方式。”Millecam说道。
不过,数字机构POP CTO Jake Bennett 表示,随着无服务计算技术的成熟,架构师会发现无服务器将越来越难以抗拒。“无服务器计算解决了太多被忽视的问题。将对可伸缩性问题的关注转移给第三方供应商,是每个开发人员的梦想,让别人关心服务器维护是IT运维人员的一种幻想。”
 
原文链接:
1、Everything you need to know about Serverless Computing
https://www.tuicool.com/articles/yMZVfev
2、Serverless and containers: Is a throw down under way?
https://www.tuicool.com/articles/BvUziyY

中国开源云联盟第二次全会7月26日在北京召开

杨y 发表了文章 • 0 个评论 • 200 次浏览 • 2017-07-25 17:50 • 来自相关话题

由工业和信息化部信息化和软件服务业司指导,中国开源云联盟第二次全体成员会议(以下简称“二次全会”)将于2017年7月26日在北京召开。

2016年4月,中国开源云联盟(COSCL)正式挂靠于中国电子技术标准化研究院,在工信部的领导下,在全体联盟成员单位的共同支持下,联盟已形成多项工作成果,包括发布团体标准一项、技术白皮书两份、组织开展第三届OpenStack开源技术黑客松活动以及组织开展2016年中国优秀开源案例评选活动等。

此次联盟全会将聚焦云计算变革与创新,深度探讨开源技术为IT领域带来的全局性持续转变,工业和信息化部 信息化和软件服务司领导将出席会议,与100余家联盟单位共同规划中国开源云联盟下一步工作,会上也将有多项联盟成果进行发布。

中国开源云联盟第二次全会会议议程

2017年第1次(总第2次)


指导单位:中华人民共和国工业和信息化部信息化和软件服务业司

主办单位:中国开源云联盟、中国电子技术标准化研究院

协办单位:华为、中标软件、X·SKY、数人云、九州云、去哪儿网

会议时间:2017年7月26日

会议地点:北京万寿宾馆






(注:议程以当天发布为准)



关于数人云


数人云成立于2014年,创始团队来自谷歌、红帽和惠普,作为领先的云计算开源技术实践者,数人云致力于帮助传统企业提升IT对业务的支撑能力,帮助客户统一管理资源和应用,加速应用交付、提升运维效率,建设新一代基于云计算技术的IT架构体系。


数人云重点聚焦打造基于容器的最轻量级PaaS平台,在实现应用全生命周期管理的同时,管理海量监控、日志等产生的各类数据,自动分配应用资源、对业务运行状况进行自动分析,提升企业的IT工业化程度,构建灵动新IT。


2016年数人云加入中国开源云联盟,2017年成为Linux基金会成员,并加入OCI(The Open Container Initiative)联盟,携手与国内外云计算伙伴共同推动云计算领域容器等开源技术的落地与发展。


关于中国开源云联盟

中国开源云联盟(简称“COSCL”)由Intel、新浪网、中标软件和上海交大于2012年8月共同发起创立,是中国最早专注于OpenStack的专业联盟,一直致力于在中国推动OpenStack技术开发、操作系统支持、性能优化、规模部署等工作。


2016年,在工业和信息化部信息化和软件服务业司的指导下,中国开源云联盟正式挂靠中国电子技术标准化研究院,推进联盟后续工作。中国电子技术标准化研究院作为工信部直属的电子信息领域标准化研究机构,一直致力于联合产业界推动开源软件技术和开源标准化工作的发展,探索开源标准与国家标准、国际标准的有机结合,并努力推动开源标准化工作思路和模式的创新。 查看全部

924663e96e42fc508f69f4359ba852ef.jpg


由工业和信息化部信息化和软件服务业司指导,中国开源云联盟第二次全体成员会议(以下简称“二次全会”)将于2017年7月26日在北京召开。

2016年4月,中国开源云联盟(COSCL)正式挂靠于中国电子技术标准化研究院,在工信部的领导下,在全体联盟成员单位的共同支持下,联盟已形成多项工作成果,包括发布团体标准一项、技术白皮书两份、组织开展第三届OpenStack开源技术黑客松活动以及组织开展2016年中国优秀开源案例评选活动等。

此次联盟全会将聚焦云计算变革与创新,深度探讨开源技术为IT领域带来的全局性持续转变,工业和信息化部 信息化和软件服务司领导将出席会议,与100余家联盟单位共同规划中国开源云联盟下一步工作,会上也将有多项联盟成果进行发布。

中国开源云联盟第二次全会会议议程

2017年第1次(总第2次)



指导单位:中华人民共和国工业和信息化部信息化和软件服务业司

主办单位:中国开源云联盟、中国电子技术标准化研究院

协办单位:华为、中标软件、X·SKY、数人云、九州云、去哪儿网

会议时间:2017年7月26日

会议地点:北京万寿宾馆

1111.png


(注:议程以当天发布为准)



关于数人云


数人云成立于2014年,创始团队来自谷歌、红帽和惠普,作为领先的云计算开源技术实践者,数人云致力于帮助传统企业提升IT对业务的支撑能力,帮助客户统一管理资源和应用,加速应用交付、提升运维效率,建设新一代基于云计算技术的IT架构体系。


数人云重点聚焦打造基于容器的最轻量级PaaS平台,在实现应用全生命周期管理的同时,管理海量监控、日志等产生的各类数据,自动分配应用资源、对业务运行状况进行自动分析,提升企业的IT工业化程度,构建灵动新IT。


2016年数人云加入中国开源云联盟,2017年成为Linux基金会成员,并加入OCI(The Open Container Initiative)联盟,携手与国内外云计算伙伴共同推动云计算领域容器等开源技术的落地与发展。


关于中国开源云联盟

中国开源云联盟(简称“COSCL”)由Intel、新浪网、中标软件和上海交大于2012年8月共同发起创立,是中国最早专注于OpenStack的专业联盟,一直致力于在中国推动OpenStack技术开发、操作系统支持、性能优化、规模部署等工作。


2016年,在工业和信息化部信息化和软件服务业司的指导下,中国开源云联盟正式挂靠中国电子技术标准化研究院,推进联盟后续工作。中国电子技术标准化研究院作为工信部直属的电子信息领域标准化研究机构,一直致力于联合产业界推动开源软件技术和开源标准化工作的发展,探索开源标准与国家标准、国际标准的有机结合,并努力推动开源标准化工作思路和模式的创新。

五个小技巧,快速创建Docker镜像

宁静胡同 发表了文章 • 0 个评论 • 697 次浏览 • 2017-01-06 14:51 • 来自相关话题

毫无疑问,容器是DevOps世界一个突破性的技术。镜像创建对于部署和发布环节都非常重要。那么如何效率地创建和使用镜像来提升部署速度呢?以下是作者的经验和分享,大家不妨一试——


1. 尽可能多地缓存网络下载

通常部署需要从Internet下载成百上千MB的数据。因此部署常受到网速慢或者断网的困扰。

而缓存得越多,部署得就会越快。最终的目标是实现Docker镜像离线一键部署。


2. 把Docker镜像看做Plain OS Golden Image

Docker很强力,但是我们也有很多VM或者裸机部署。为了避免供应商锁定,通常需要选择是否用Docker支持部署,最好两种场景都实施部署持续集成。

举例来说,如果使用kitchen来做持续集成。默认情况下,使用自定义Docker镜像来测试。当IMAGE_NAME指定为ubuntu:14.04时,可以很肯定ubuntu:14.04系统对于部署非常适用。


3. 审核Docker镜像里所有包和服务的安装

从镜像起一个Docker容器,然后列出并检查所有安装的包/服务。

为什么要这么做?首先我们希望Docker镜像尽可能地小,镜像交付就会很快速。其次,包/服务越多,问题也会越多,例如包冲突,TCP端口占有问题。一些服务的安装后脚本甚至会改变关键性的全局配置文件或者留下不可预期的flagfile。所以最好让Docker镜像保持傻傻的单纯。


4. Docker构建的最后清理关闭所有服务

如果不这么做,服务会在Docker镜像的最后阶段被杀掉。在/var/lock/*下的服务的lockfile如果没有被正确使用,当测试新建镜像的部署时,服务可能会启动失败,导致测试无效。


5. 添加验证步骤,确保镜像正常

当有改变发生时,我们时不时需要重构Docker镜像。为了确保一切正常,我们可以在Docker构建过程中添加自动验证逻辑。


这是一个简单的例子,实践了上述提到的技巧。
########## How To Use Docker Image ###############
## docker run -t -d --privileged -p 8022:22 \
## denny/mydockertest:v1 /usr/sbin/sshd -D
##
##################################################

FROM denny/sshd:v1
MAINTAINER Deny <denny@dennyzhang.com>
ARG devops_branch=master
ARG working_dir=/root/chef
##################################################
# Install basic packages
RUN apt-get -yqq update && \
apt-get -yqq install curl && \
apt-get -yqq install openssh-server && \
apt-get install -y sudo lsb-release && \
# Install chef
curl -L https://www.opscode.com/chef/install.sh | bash && \
# clean up files to make this docker layer smaller
rm -rf /var/chef/cache/*.plugin && \
rm -rf /usr/share/doc && \
apt-get clean && apt-get autoclean
##################################################
# checkout code
RUN bash /root/git_update.sh ${working_dir} \
git@github.com:DennyZhang/chef_community_cookbooks.git \
${devops_branch} && \
echo "cookbook_path [\"${working_dir}/${devops_branch}/mdmdevops/community_cookbooks\", \
\"${working_dir}/${devops_branch}/mdmdevops/cookbooks\"]" \
> /root/client.rb

# Chef all-in-one deployment. This step takes minutes
RUN echo "{\"run_list\": [\"recipe[all-in-one::predownload]\"]}" \
> /root/client.json && \
chef-solo --config /root/client.rb -j /root/client.json && \
# Clean up to make docker image smaller
rm -rf /tmp/* /var/tmp/* && \
rm -rf /var/chef/cache/jdk-*.tar.gz && \
rm -rf /var/chef/cache/*.plugin && \
rm -rf /usr/share/doc && \
apt-get clean && apt-get autoclean
##################################################

# Shutdown services
RUN service couchbase-server stop || true && \
service elasticsearch stop || true && \
service nagios3 stop || true && \
service apache2 stop || true && \
service haproxy stop || true && \
service nagios-nrpe-server stop || true && \
rm -rf /run/apache2/apache2.pid && \
rm -rf /var/log/apache2/* && \
rm -rf /usr/local/var/run/vagrant_ubuntu_trusty_64.pid && \
rm -rf /root/docker.rb /root/docker.json

# Verify docker image
RUN test -f /var/chef/cache/couchbase-server-enterprise_4.1.0-ubuntu14.04_amd64.deb && \
test -f /var/chef/cache/elasticsearch-2.3.3.deb && \
test -f /etc/apt/sources.list.d/ruby2.1-repo.list && \
test -f /etc/apt/sources.list.d/haproxy-repo.list && \
dpkg -s haproxy | grep "1.6.5"

# Clean up to make docker image smaller
RUN rm -rf /tmp/* /var/tmp/* /var/chef/cache/jdk-*.tar.gz && \
rm -rf /var/chef/cache/*.plugin && \
rm -rf /usr/share/doc && \
apt-get clean && apt-get autoclean

EXPOSE 22
CMD ["/usr/sbin/sshd", "-D"]
##################################################



作者:Denny Zhang
文章来源:https://dennyzhang.github.io/d ... .html 查看全部

毫无疑问,容器是DevOps世界一个突破性的技术。镜像创建对于部署和发布环节都非常重要。那么如何效率地创建和使用镜像来提升部署速度呢?以下是作者的经验和分享,大家不妨一试——




1. 尽可能多地缓存网络下载

通常部署需要从Internet下载成百上千MB的数据。因此部署常受到网速慢或者断网的困扰。

而缓存得越多,部署得就会越快。最终的目标是实现Docker镜像离线一键部署。


2. 把Docker镜像看做Plain OS Golden Image

Docker很强力,但是我们也有很多VM或者裸机部署。为了避免供应商锁定,通常需要选择是否用Docker支持部署,最好两种场景都实施部署持续集成。

举例来说,如果使用kitchen来做持续集成。默认情况下,使用自定义Docker镜像来测试。当IMAGE_NAME指定为ubuntu:14.04时,可以很肯定ubuntu:14.04系统对于部署非常适用。


3. 审核Docker镜像里所有包和服务的安装

从镜像起一个Docker容器,然后列出并检查所有安装的包/服务。

为什么要这么做?首先我们希望Docker镜像尽可能地小,镜像交付就会很快速。其次,包/服务越多,问题也会越多,例如包冲突,TCP端口占有问题。一些服务的安装后脚本甚至会改变关键性的全局配置文件或者留下不可预期的flagfile。所以最好让Docker镜像保持傻傻的单纯。


4. Docker构建的最后清理关闭所有服务

如果不这么做,服务会在Docker镜像的最后阶段被杀掉。在/var/lock/*下的服务的lockfile如果没有被正确使用,当测试新建镜像的部署时,服务可能会启动失败,导致测试无效。


5. 添加验证步骤,确保镜像正常

当有改变发生时,我们时不时需要重构Docker镜像。为了确保一切正常,我们可以在Docker构建过程中添加自动验证逻辑。


这是一个简单的例子,实践了上述提到的技巧。
########## How To Use Docker Image ###############
## docker run -t -d --privileged -p 8022:22 \
## denny/mydockertest:v1 /usr/sbin/sshd -D
##
##################################################

FROM denny/sshd:v1
MAINTAINER Deny <denny@dennyzhang.com>
ARG devops_branch=master
ARG working_dir=/root/chef
##################################################
# Install basic packages
RUN apt-get -yqq update && \
apt-get -yqq install curl && \
apt-get -yqq install openssh-server && \
apt-get install -y sudo lsb-release && \
# Install chef
curl -L https://www.opscode.com/chef/install.sh | bash && \
# clean up files to make this docker layer smaller
rm -rf /var/chef/cache/*.plugin && \
rm -rf /usr/share/doc && \
apt-get clean && apt-get autoclean
##################################################
# checkout code
RUN bash /root/git_update.sh ${working_dir} \
git@github.com:DennyZhang/chef_community_cookbooks.git \
${devops_branch} && \
echo "cookbook_path [\"${working_dir}/${devops_branch}/mdmdevops/community_cookbooks\", \
\"${working_dir}/${devops_branch}/mdmdevops/cookbooks\"]" \
> /root/client.rb

# Chef all-in-one deployment. This step takes minutes
RUN echo "{\"run_list\": [\"recipe[all-in-one::predownload]\"]}" \
> /root/client.json && \
chef-solo --config /root/client.rb -j /root/client.json && \
# Clean up to make docker image smaller
rm -rf /tmp/* /var/tmp/* && \
rm -rf /var/chef/cache/jdk-*.tar.gz && \
rm -rf /var/chef/cache/*.plugin && \
rm -rf /usr/share/doc && \
apt-get clean && apt-get autoclean
##################################################

# Shutdown services
RUN service couchbase-server stop || true && \
service elasticsearch stop || true && \
service nagios3 stop || true && \
service apache2 stop || true && \
service haproxy stop || true && \
service nagios-nrpe-server stop || true && \
rm -rf /run/apache2/apache2.pid && \
rm -rf /var/log/apache2/* && \
rm -rf /usr/local/var/run/vagrant_ubuntu_trusty_64.pid && \
rm -rf /root/docker.rb /root/docker.json

# Verify docker image
RUN test -f /var/chef/cache/couchbase-server-enterprise_4.1.0-ubuntu14.04_amd64.deb && \
test -f /var/chef/cache/elasticsearch-2.3.3.deb && \
test -f /etc/apt/sources.list.d/ruby2.1-repo.list && \
test -f /etc/apt/sources.list.d/haproxy-repo.list && \
dpkg -s haproxy | grep "1.6.5"

# Clean up to make docker image smaller
RUN rm -rf /tmp/* /var/tmp/* /var/chef/cache/jdk-*.tar.gz && \
rm -rf /var/chef/cache/*.plugin && \
rm -rf /usr/share/doc && \
apt-get clean && apt-get autoclean

EXPOSE 22
CMD ["/usr/sbin/sshd", "-D"]
##################################################



作者:Denny Zhang
文章来源:https://dennyzhang.github.io/d ... .html

DevOps 新年计划清单:对失败的准备 say no

宁静胡同 发表了文章 • 0 个评论 • 523 次浏览 • 2016-12-28 19:30 • 来自相关话题

随着2016年接近尾声,又到了为明年做准备的时候啦。今天的文章里邀请了国外三位嘉宾Andrew Phillips, Tim Buntel,和 TJ Randall,看看业界的思想者们对于DevOps世界新一年有哪些展望,为大家提供一些参考。

1.新浪潮——“下一代平台”将要来临

在2017年,将会有一种聚焦于容器编排框架的“下一代平台”项目,以及将工具重组的PaaS平台,例如OpenShift 或者 Cloud Foundry。对于跨机资源管理和调度框架的需求会持续增长,生态链上的供应商会甩掉身上的重负、快速地跟随上这个趋势。同时在容器标准化上会有一个更清晰的认识,容器自动化也会成为一种必需。

2.应用新定义将成为约定俗成的标准

未来将不再定义应用为“虚拟化设备概念”,就此开启从“为每个应用版本制作亚马逊机器镜像”到软件交付的新阶段。

3.迎刃而上的企业需求

随着下一代平台的实现以及容器自动化,在企业需求上面将会有更多关注点,比如接口控制,审计跟踪和网络技术,在编排层实现“虚拟防火墙”。我们也会看到一波波的案例,充分感受到“它们比看起来的要困难得多”。

4.数据科学/大数据遍地开花

数据科学/大数据项目数量会有一个提升,围绕着测试、持续集成和持续交付将会有各自不同的挑战。更多的商业关注会提高大家对于集群管理工具的接受度,因为多数大数据框架都是运行在它们之上的。

5.软件开发强调分析与监测

自动化进程会产生大量的数据,而自动操作的软件发布越来越多。管理发布的关键信息量十分庞大,散布在一堆工具里。团队需要简化数据来做商业报告,为了更深入地进行使用操作、工作情况的调查,要明确和强调其中不寻常的数据。

6.Serverless Architecture,不再纸上谈兵

PaaS我们已经听了很多年,在这一层之下,Serverless Architecture可以让代码运行而不需要提供或者管理服务器。不再需要提供服务器,也不需要应用一直运行,Serverless Architecture还提供了完全自动化的的水平扩展能力。它们并不是很新的东西(比如AWS Lambda 2014年就出来了),明年有望实现更广泛的使用,而不再只是会议上的一个话题了。

7.企业的应用迁移之路

在古董、过渡和现代应用栈之间的巨大鸿沟,让企业在人员招聘、员工分配和预算上都承受了巨大的压力。新平台面向用户的解决方案有越来越多的成功案例——比如云计算和容器方面——会让公司在新架构应用迁移上投入更多。

8.敏捷驱动和瀑布式交付模式的完美结合

Pipeline和发布编排会成为应用交付进程中非开发人员最时髦的流行词,这些方法会在交付过程中提供企业需要的一致性,以及IT团队需要更快交付解决方案的灵活性。

Benjamin Franklin 曾经说过, “By failingto prepare, you are preparing to fail” 。 
2017 将会成为行业内有巨大变革的一年—— 
你,准备好了吗?

作者:Divesh Rupani 文章来源:https://blog.xebialabs.com/201 ... 2017/ 查看全部
随着2016年接近尾声,又到了为明年做准备的时候啦。今天的文章里邀请了国外三位嘉宾Andrew Phillips, Tim Buntel,和 TJ Randall,看看业界的思想者们对于DevOps世界新一年有哪些展望,为大家提供一些参考。

1.新浪潮——“下一代平台”将要来临

在2017年,将会有一种聚焦于容器编排框架的“下一代平台”项目,以及将工具重组的PaaS平台,例如OpenShift 或者 Cloud Foundry。对于跨机资源管理和调度框架的需求会持续增长,生态链上的供应商会甩掉身上的重负、快速地跟随上这个趋势。同时在容器标准化上会有一个更清晰的认识,容器自动化也会成为一种必需。

2.应用新定义将成为约定俗成的标准

未来将不再定义应用为“虚拟化设备概念”,就此开启从“为每个应用版本制作亚马逊机器镜像”到软件交付的新阶段。

3.迎刃而上的企业需求

随着下一代平台的实现以及容器自动化,在企业需求上面将会有更多关注点,比如接口控制,审计跟踪和网络技术,在编排层实现“虚拟防火墙”。我们也会看到一波波的案例,充分感受到“它们比看起来的要困难得多”。

4.数据科学/大数据遍地开花

数据科学/大数据项目数量会有一个提升,围绕着测试、持续集成和持续交付将会有各自不同的挑战。更多的商业关注会提高大家对于集群管理工具的接受度,因为多数大数据框架都是运行在它们之上的。

5.软件开发强调分析与监测

自动化进程会产生大量的数据,而自动操作的软件发布越来越多。管理发布的关键信息量十分庞大,散布在一堆工具里。团队需要简化数据来做商业报告,为了更深入地进行使用操作、工作情况的调查,要明确和强调其中不寻常的数据。

6.Serverless Architecture,不再纸上谈兵

PaaS我们已经听了很多年,在这一层之下,Serverless Architecture可以让代码运行而不需要提供或者管理服务器。不再需要提供服务器,也不需要应用一直运行,Serverless Architecture还提供了完全自动化的的水平扩展能力。它们并不是很新的东西(比如AWS Lambda 2014年就出来了),明年有望实现更广泛的使用,而不再只是会议上的一个话题了。

7.企业的应用迁移之路

在古董、过渡和现代应用栈之间的巨大鸿沟,让企业在人员招聘、员工分配和预算上都承受了巨大的压力。新平台面向用户的解决方案有越来越多的成功案例——比如云计算和容器方面——会让公司在新架构应用迁移上投入更多。

8.敏捷驱动和瀑布式交付模式的完美结合

Pipeline和发布编排会成为应用交付进程中非开发人员最时髦的流行词,这些方法会在交付过程中提供企业需要的一致性,以及IT团队需要更快交付解决方案的灵活性。

Benjamin Franklin 曾经说过, “By failingto prepare, you are preparing to fail” 。 
2017 将会成为行业内有巨大变革的一年—— 
你,准备好了吗?

作者:Divesh Rupani 文章来源:https://blog.xebialabs.com/201 ... 2017/

数人云可否用于devops?

回复

prometheus 回复了问题 • 4 人关注 • 4 个回复 • 1089 次浏览 • 2015-11-18 18:20 • 来自相关话题

显示出现错位怎么办?

回复

dataman 回复了问题 • 2 人关注 • 1 个回复 • 807 次浏览 • 2015-11-18 15:30 • 来自相关话题

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

dataman 发表了文章 • 0 个评论 • 37 次浏览 • 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 个评论 • 29 次浏览 • 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 个评论 • 49 次浏览 • 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 个评论 • 73 次浏览 • 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还需要很长时间去落地。

开发测试一山容得二虎,30条有关测试的故事和事故

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

软件工程规则和测试积累的最佳实践,能帮助企业显著节省时间,减少痛点。良好的测试实践既可以确保质量标准,也可以指导和塑造每个程序员的发展。

小数今天推送的这篇文章,文中的许多原则都与测试实践和理想有关,有一些还是Python特有的。正如本文作者所说,程序员的那些固执己见,强烈的意见表达和坚持,往往是激情的最好表现。

1. YAGNI:不要编写现在尚不需要,而将来可能需要的代码。现在的代码不可避免地会变成死代码或需要重写,因为未来的用例总是与设想的不同。如果把代码放在未来的用例中,在代码审查中要提出质疑。(例如,可以并且必须设计API来允许将来的用例,不过,这是另外一个问题。)

注解代码也是如此。如果一个注释代码块进入发行版,它就不应该存在。如果是可以恢复的代码,创建一个ticket,并引用代码删除的提交散列。YAGNI 是敏捷编程的核心元素。Kent Beck提供的极限编程解释(Extreme Programming Explained)就是最好的参考。


2.测试本身不需要测试。用于测试的基础架构,框架和库需要测试。除非确实需要,通常不要测试浏览器或外部库。测试你写的代码,而并非其他人的。

3.第三次编写相同代码时,是将其抽取到通用帮助器(并为其编写测试)的正确时机。测试中的辅助功能不需要测试; 当把它们分解出来并进行重用时,才需要测试。到第三次编写类似的代码时,会清楚地知道正在解决什么样的问题。

4.涉及到API设计:简单的事情简单化; 复杂的事情可能如果可能也简单化。首先设计一个简单的情况,如果可能,最好使用零配置或参数化。为更复杂和更灵活的用例添加选项或其他API方法。


5.快速失败。尽可能早地检查输入,并在无意义的输入或无效状态上失败,使用异常或错误响应,来确定问题。允许代码“创新”,也就是说,通常情况下,不要对输入验证进行类型检查。


6. 单元测试是对行为单元的测试,而不是对实现单元。改变实现,而不是改变行为或被迫改变任何测试,当然这点并不是总能实现。在可能的情况下,将测试对象视为黑盒子,通过公共 API 进行测试,而无需调用私有方法或修改状态。


对于一些复杂的场景,比如一些特定复杂状态下,测试行为找到一个难以理解的错误。编写测试确实有助于解决这个问题,因为它会迫使你在编写代码之前,考虑清楚代码的行为以及如何测试。测试首先鼓励更小,更模块化的代码单元。

7.对于单元测试(包括测试基础结构测试),应该测试所有的代码路径。100%的覆盖率是一个很好的起点。你不能涵盖所有可能的排列/组合状态。在有很好的理由时,代码路径才能被测试。缺少时间不是一个好的理由,这往往导致最终花费更多时间。好的理由包括:真正无法测试,在实践中不可能实现,或者在测试中其他地方被覆盖。没有测试的代码要承担责任。衡量覆盖率,并拒绝降低覆盖率的百分比是朝正确方向前进的一种方法。


8.代码是敌人:可能出错,需要维护。少写代码。删除代码。不要编写你不需要的代码。

9.随着时间的推移,代码注释不可避免地成为谎言。实际上,很少有人在事情发生变化时更新评论。通过良好的命名实践和已知的编程风格,努力使代码有可读性和自我记录。

不明确的代码确实需要注释,比如围绕一个模糊的错误或不可能的条件,或者必要的优化。

10.防守地写。要总是想可能出现什么问题,无效输入会发生什么,什么可能导致失败,这有助于在错误发生前发现错误。

11.如果逻辑无状态且无副作用,则易于进行单元测试。将逻辑分解成独立的函数,而不是混合成有状态和副作用的代码。将有状态和带副作用的代码分离成更小的函数,可以更容易地模拟和单元测试。副作用确实需要测试,测试一次并在其他地方进行模拟,是比较好的做法。

12.Globals are bad。功能优于类型,对象比复杂的数据结构更好。

13.使用 Python 内置类型和方法比编写自己的类型更快(除非用C编写)。如果考虑性能,尝试解决如何使用标准内置类型而不是自定义对象。

14. 依赖注入是一种有用的编程模式,可以清楚了解依赖关系。(让对象,方法等接收依赖关系作为参数,而不是自己实例化新的对象。)这是一种交换,使API签名更加复杂。如果完成依赖项需要使用10个参数,说明代码太多了。


15. 越需要模拟测试代码,它就会越糟糕。需要实例化和放置的代码越多,用来测试特定的行为,代码就越糟糕。测试的目标是小型可测试单元,和更高级别的集成和功能测试,来测试这些单元是否正确地协作。


16.面向外部的 API 是要“预先设计”的,它关系到未来用例。改变 API 对自己和用户来说都是一种痛苦,而创造向后兼容性是非常可怕的,尽管有时不可避免。精心设计面向外部的API,仍然坚持“简单的事情简单化”的原则。


17.如果一个函数或方法超过30行代码,就要考虑分解。好的最大模块大小约为500线。测试文件往往比这个更长。


18.不要在难以测试的对象构造函数中工作。不要把代码放在__init__.py中。程序员不希望在__init__.py找到代码。


19. DRY(Don’t Repeat Yourself不要重复自己)在测试中比在生产中重要得多。单个测试文件的可读性比可维护性更重要(突破可重用的块)。这是因为测试是单独执行和读取的,而不是作为大系统的一部分。过多的重复意味着可重用的组件可以方便地创建,但是与生产相比,测试的重要性低得多。


20.当看到需要并有机会时进行重构。编程是关于抽象的,抽象映射越接近问题域,代码就越容易理解和维护。随着系统有机地增长,需要为扩展用例而改变结构。系统超出抽象和结构,而不改变它们成为技术债务,这会更痛苦,更缓慢,更多bug。包括重构成本,包括对功能的预估。你把债务拖得越久,它积累的利息就越高。Michael Feathers 撰写了一本关于重构和测试的书籍,其中着重介绍了遗留代码。

21.正确的编写代码第一,速度第二。处理性能问题时,请务必在修复之前进行配置。瓶颈通常出乎你的意料。编写难懂的代码如果是为了速度更快,为此你进行了配置并证明这么做是值得的,那么也仅仅是速度上值得而已。编写一个测试,训练正在配置的代码,让它知道什么情况下会变得更简单,并且留在测试套件中,来防止性能下降。(通常情况下,添加计时代码总是会改变代码的性能特点,使性能变得经常差强人意。)


22.更小范围的单元测试在失败时会提供更有价值的信息。要判定错误,有一半的系统测试行为的测试需要依据更多的调查。一般来说,运行时间超过0.1秒的测试不是单元测试。没有所谓的慢单元测试。通过严格范围的单元测试测试行为,你的测试可以作为代码实际规范。理想情况下,如果有人想了解你的代码,应该能够将测试套件作为行为的“文档”。


23. “这里没有发明”并不像人们所说的那么糟糕。如果我们编写代码,我们知道它的作用,知道如何维护它,可以自由地扩展和修改它。这是遵循了YAGNI的原则:我们有需要用例的特定代码,而并非通用代码,通用代码会给我们不需要的部分带来复杂性。另一方面,代码是敌人,拥有更多的代码没有好处,当引入新的依赖关系时需要考虑权衡。


24.共享代码所有权是目标。孤立的知识没什么好,这意味着至少要讨论、记录贯彻设计决策和实施决策。代码审查时开始讨论设计决策是最糟糕,因为在编写代码之后进行彻底的更改太难克服了。当然,在Review时指出和修改设计错误,比永远不总结不思考要好得多。


25.  Generators rock! 与有状态的对象相比,它们用于迭代或重复执行通常更短,更容易理解。


26.让我们成为工程师!设计、建立强大和良好实施的系统,而不是增加有机怪物。编程是一个平衡的行为,我们并不总是建造火箭飞船,过度设计(onion architecture洋葱架构)与设计不足的代码同样令人痛苦。罗伯特•马丁(Robert Martin)所做的几乎任何事情都值得一读,“ 干净架构:软件结构和设计指南”( Clean Architecture: A Craftsman’s Guide to Software Structure and Design )是这方面的好资源。设计模式( Design Patterns)是每个工程师应该阅读的经典编程书籍。


27.间歇性地失败的测试会侵蚀测试套件的价值,以至于最终每个人都忽略测试运行的结果。修复或删除间歇性失败的测试是痛苦的,但值得努力。


28.一般来说,尤其是在测试中,等待一个具体的改变,而不是任意时间内sleeping。Voodoo sleeps 很难理解,而且会放慢测试套件。


29.至少要看到你的测试失败过一次。将一个蓄意的 bug 放入让它失败,或在测试行为完成之前运行测试。否则,你不知道你真的在测试。偶尔写写测试代码实际并不测试任何东西,或写永远不会失败的测试,都是很容易的。


30.最后,管理要点:持续的功能研发是开发软件的一个可怕方法。不让开发人员在工作感到骄傲, 就不会从中获得最大的利益。不解决技术债务,会拖慢开发速度,并导致更糟糕的、更多bug的产品。


原文作者:Michael Foord

原文链接:

https://opensource.com/article ... sting
  查看全部
软件工程规则和测试积累的最佳实践,能帮助企业显著节省时间,减少痛点。良好的测试实践既可以确保质量标准,也可以指导和塑造每个程序员的发展。

小数今天推送的这篇文章,文中的许多原则都与测试实践和理想有关,有一些还是Python特有的。正如本文作者所说,程序员的那些固执己见,强烈的意见表达和坚持,往往是激情的最好表现。

1. YAGNI:不要编写现在尚不需要,而将来可能需要的代码。现在的代码不可避免地会变成死代码或需要重写,因为未来的用例总是与设想的不同。如果把代码放在未来的用例中,在代码审查中要提出质疑。(例如,可以并且必须设计API来允许将来的用例,不过,这是另外一个问题。)

注解代码也是如此。如果一个注释代码块进入发行版,它就不应该存在。如果是可以恢复的代码,创建一个ticket,并引用代码删除的提交散列。YAGNI 是敏捷编程的核心元素。Kent Beck提供的极限编程解释(Extreme Programming Explained)就是最好的参考。


2.测试本身不需要测试。用于测试的基础架构,框架和库需要测试。除非确实需要,通常不要测试浏览器或外部库。测试你写的代码,而并非其他人的。

3.第三次编写相同代码时,是将其抽取到通用帮助器(并为其编写测试)的正确时机。测试中的辅助功能不需要测试; 当把它们分解出来并进行重用时,才需要测试。到第三次编写类似的代码时,会清楚地知道正在解决什么样的问题。

4.涉及到API设计:简单的事情简单化; 复杂的事情可能如果可能也简单化。首先设计一个简单的情况,如果可能,最好使用零配置或参数化。为更复杂和更灵活的用例添加选项或其他API方法。


5.快速失败。尽可能早地检查输入,并在无意义的输入或无效状态上失败,使用异常或错误响应,来确定问题。允许代码“创新”,也就是说,通常情况下,不要对输入验证进行类型检查。


6. 单元测试是对行为单元的测试,而不是对实现单元。改变实现,而不是改变行为或被迫改变任何测试,当然这点并不是总能实现。在可能的情况下,将测试对象视为黑盒子,通过公共 API 进行测试,而无需调用私有方法或修改状态。


对于一些复杂的场景,比如一些特定复杂状态下,测试行为找到一个难以理解的错误。编写测试确实有助于解决这个问题,因为它会迫使你在编写代码之前,考虑清楚代码的行为以及如何测试。测试首先鼓励更小,更模块化的代码单元。

7.对于单元测试(包括测试基础结构测试),应该测试所有的代码路径。100%的覆盖率是一个很好的起点。你不能涵盖所有可能的排列/组合状态。在有很好的理由时,代码路径才能被测试。缺少时间不是一个好的理由,这往往导致最终花费更多时间。好的理由包括:真正无法测试,在实践中不可能实现,或者在测试中其他地方被覆盖。没有测试的代码要承担责任。衡量覆盖率,并拒绝降低覆盖率的百分比是朝正确方向前进的一种方法。


8.代码是敌人:可能出错,需要维护。少写代码。删除代码。不要编写你不需要的代码。

9.随着时间的推移,代码注释不可避免地成为谎言。实际上,很少有人在事情发生变化时更新评论。通过良好的命名实践和已知的编程风格,努力使代码有可读性和自我记录。

不明确的代码确实需要注释,比如围绕一个模糊的错误或不可能的条件,或者必要的优化。

10.防守地写。要总是想可能出现什么问题,无效输入会发生什么,什么可能导致失败,这有助于在错误发生前发现错误。

11.如果逻辑无状态且无副作用,则易于进行单元测试。将逻辑分解成独立的函数,而不是混合成有状态和副作用的代码。将有状态和带副作用的代码分离成更小的函数,可以更容易地模拟和单元测试。副作用确实需要测试,测试一次并在其他地方进行模拟,是比较好的做法。

12.Globals are bad。功能优于类型,对象比复杂的数据结构更好。

13.使用 Python 内置类型和方法比编写自己的类型更快(除非用C编写)。如果考虑性能,尝试解决如何使用标准内置类型而不是自定义对象。

14. 依赖注入是一种有用的编程模式,可以清楚了解依赖关系。(让对象,方法等接收依赖关系作为参数,而不是自己实例化新的对象。)这是一种交换,使API签名更加复杂。如果完成依赖项需要使用10个参数,说明代码太多了。


15. 越需要模拟测试代码,它就会越糟糕。需要实例化和放置的代码越多,用来测试特定的行为,代码就越糟糕。测试的目标是小型可测试单元,和更高级别的集成和功能测试,来测试这些单元是否正确地协作。


16.面向外部的 API 是要“预先设计”的,它关系到未来用例。改变 API 对自己和用户来说都是一种痛苦,而创造向后兼容性是非常可怕的,尽管有时不可避免。精心设计面向外部的API,仍然坚持“简单的事情简单化”的原则。


17.如果一个函数或方法超过30行代码,就要考虑分解。好的最大模块大小约为500线。测试文件往往比这个更长。


18.不要在难以测试的对象构造函数中工作。不要把代码放在__init__.py中。程序员不希望在__init__.py找到代码。


19. DRY(Don’t Repeat Yourself不要重复自己)在测试中比在生产中重要得多。单个测试文件的可读性比可维护性更重要(突破可重用的块)。这是因为测试是单独执行和读取的,而不是作为大系统的一部分。过多的重复意味着可重用的组件可以方便地创建,但是与生产相比,测试的重要性低得多。


20.当看到需要并有机会时进行重构。编程是关于抽象的,抽象映射越接近问题域,代码就越容易理解和维护。随着系统有机地增长,需要为扩展用例而改变结构。系统超出抽象和结构,而不改变它们成为技术债务,这会更痛苦,更缓慢,更多bug。包括重构成本,包括对功能的预估。你把债务拖得越久,它积累的利息就越高。Michael Feathers 撰写了一本关于重构和测试的书籍,其中着重介绍了遗留代码。

21.正确的编写代码第一,速度第二。处理性能问题时,请务必在修复之前进行配置。瓶颈通常出乎你的意料。编写难懂的代码如果是为了速度更快,为此你进行了配置并证明这么做是值得的,那么也仅仅是速度上值得而已。编写一个测试,训练正在配置的代码,让它知道什么情况下会变得更简单,并且留在测试套件中,来防止性能下降。(通常情况下,添加计时代码总是会改变代码的性能特点,使性能变得经常差强人意。)


22.更小范围的单元测试在失败时会提供更有价值的信息。要判定错误,有一半的系统测试行为的测试需要依据更多的调查。一般来说,运行时间超过0.1秒的测试不是单元测试。没有所谓的慢单元测试。通过严格范围的单元测试测试行为,你的测试可以作为代码实际规范。理想情况下,如果有人想了解你的代码,应该能够将测试套件作为行为的“文档”。


23. “这里没有发明”并不像人们所说的那么糟糕。如果我们编写代码,我们知道它的作用,知道如何维护它,可以自由地扩展和修改它。这是遵循了YAGNI的原则:我们有需要用例的特定代码,而并非通用代码,通用代码会给我们不需要的部分带来复杂性。另一方面,代码是敌人,拥有更多的代码没有好处,当引入新的依赖关系时需要考虑权衡。


24.共享代码所有权是目标。孤立的知识没什么好,这意味着至少要讨论、记录贯彻设计决策和实施决策。代码审查时开始讨论设计决策是最糟糕,因为在编写代码之后进行彻底的更改太难克服了。当然,在Review时指出和修改设计错误,比永远不总结不思考要好得多。


25.  Generators rock! 与有状态的对象相比,它们用于迭代或重复执行通常更短,更容易理解。


26.让我们成为工程师!设计、建立强大和良好实施的系统,而不是增加有机怪物。编程是一个平衡的行为,我们并不总是建造火箭飞船,过度设计(onion architecture洋葱架构)与设计不足的代码同样令人痛苦。罗伯特•马丁(Robert Martin)所做的几乎任何事情都值得一读,“ 干净架构:软件结构和设计指南”( Clean Architecture: A Craftsman’s Guide to Software Structure and Design )是这方面的好资源。设计模式( Design Patterns)是每个工程师应该阅读的经典编程书籍。


27.间歇性地失败的测试会侵蚀测试套件的价值,以至于最终每个人都忽略测试运行的结果。修复或删除间歇性失败的测试是痛苦的,但值得努力。


28.一般来说,尤其是在测试中,等待一个具体的改变,而不是任意时间内sleeping。Voodoo sleeps 很难理解,而且会放慢测试套件。


29.至少要看到你的测试失败过一次。将一个蓄意的 bug 放入让它失败,或在测试行为完成之前运行测试。否则,你不知道你真的在测试。偶尔写写测试代码实际并不测试任何东西,或写永远不会失败的测试,都是很容易的。


30.最后,管理要点:持续的功能研发是开发软件的一个可怕方法。不让开发人员在工作感到骄傲, 就不会从中获得最大的利益。不解决技术债务,会拖慢开发速度,并导致更糟糕的、更多bug的产品。


原文作者:Michael Foord

原文链接:

https://opensource.com/article ... sting
 

微服务2017年度报告出炉:4大客户画像,15%传统企业已领跑

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

开篇:

如果在诸多热门云计算技术中,诸如容器、微服务、DevOps、OpenStack 等,找出一个最火的方向,那么非微服务莫属。尽管话题炙手可热,但对传统行业来说,微服务落地和方法论目前处于起步阶段。

本报告于2017年11月份展开,从驱动因素、落地现状、和容器关系、架构体系、未来趋势和落地方法论等方面对微服务进行了分析。希望能够为传统企业微服务决策、规划和实施提供依据和解决办法。

一、驱动因素

传统行业对IT效率的变革需求是微服务成长土壤,业务模式创新重塑导致系统更新频繁、应用复杂度急剧升高,传统架构不堪重负。

微服务架构具有明显的好处,尤其是在应对复杂业务系统的多变需求方面。在本次调研企业中,每个月都要进行业务系统更新的比例占63%,只有不到20%的企业半年以上更新一次系统。













加快互联网+步伐成为许多传统企业的必然选择。业务场景、用户习惯和行为在迅速变化,许多传统行业线上业务出现急速增长。

比如金融行业的移动支付、互联网理财等,汽车制造行业的营销、电商、售后服务等线上业务比例迅速提高。IT团队业务开发、迭代都以每月、甚至每周来计,需要7*24小时响应,这些给系统开发和运维带来极大挑战。

在IT对业务的响应和支撑方面,不同行业所面临的困扰略有不同,但总体差异不明显。调研显示,系统支撑方面排在前四的难题分别为:系统复杂性越来越高(28%),运维管理复杂度高,打造一支全栈运维团队困难(26%),线上访问压力大(19%),设备采购维护成本高(19%)。







在传统单体或SOA架构下,应用如果频繁升级更新,开发团队非常痛苦。企业的业务应用经过多年IT建设,系统非常庞大,要改动其中任何一小部分,都需要重新部署整个应用,敏捷开发和快速交付无从谈起。

传统企业在长期的IT建设过程中,通常大量使用外包团队,这导致采用的技术栈之间差异较大,统一管控和运维要求更高。需要运维7*24小时全天候值守、在线升级,并快速响应。

在此时脱颖而出的微服务技术,面对上述困惑几乎浑身优点:独立开发、独立部署、独立发布,去中心化管理,支持高并发高可用,支持丰富技术栈,企业可以根据需要灵活技术选型。

二、微服务落地现状

1、微服务客户画像

微服务架构在企业的使用情况可以分为四个层次:初级使用者、轻度使用者、中度使用者、以及重度使用者。初级使用者基本是传统架构,独立部署需求不突出,技术堆栈不成熟,需要较长的培育和成长期。轻度使用的企业边缘业务系统开始使用Spring Boot 或Spring Cloud等框架,但组件的使用尚不熟练。

中度使用者为使用Dubbo或Spring cloud时间较长,但还没有做周边配套的工具链。重度使用者是那些走在微服务架构改造前沿,具备微服务规划和体系,有自己研发实力的企业,通常是以技术见长的大型互联网公司。

2、15% 左右的调研企业引入了SpringCloud、Dubbo等微服务主流开发框架

此次调研中,6%的企业已经部分引入了Spring Cloud 开发框架,Spring Cloud 也被开发者认为是最好的开发框架。另外,9%的受访企业采用了 Dubbo 等其他微服务框架,也就是说引入了或考虑引入微服务架构的企业达15%。







此外,还有51%以上的企业在考虑往云原生方向转型。这是由于企业数字化转型背景下,IT要更好适应线上业务趋势的必然要求。加上国家政策层面对云服务的支持,传统企业云化是大势所趋。

* 3、微服务四大技术优势受青睐*

从IT技术发展趋势看,无论硬件、软件、还是基础架构都在朝着轻量化的方向发展。微服务通过化整为零的概念,将复杂的IT部署分解成更小、更独立的微服务。 相对传统的建设方法,传统企业更看重微服务如下四方面的优势:技术选型灵活,更轻松采用新架构和语言(28%)降低系统内部服务冗余,提升开发效率(27%)独立部署(22%)更好的容错机制(20%)







在涉及复杂项目时,和单体架构的对比中,微服务从多个角度显示出了压倒性的优势。

4、制造业开始发力、金融小试牛刀

这里所说制造业,是大制造的概念,包括制造、汽车、大型制造以及航空业等。这些行业往引入Spring Cloud、Dubbo等微服务开发框架的企业占比超过15%。制造业开始初步尝试微服务架构。 能看出制造业向“智造”转型的影响,今天的制造业结合了物联网、传感器、云计算、大数据等技术,人工智能技术正在工业、汽车驾驶等领域应用。大量新兴业务场景出现,服务变得复杂,产业的弯道超车带来了明显的微服务需求。
 







其次,需求明显的为金融行业,包括银行、保险、证券等。尤其是一些国有银行、股份制银行以及城商行等大行都走在架构改造的前列。在自己的创新业务,如手机银行、微信银行、互联网理财等业务上试水微服务架构。在核心业务系统方面,则相当谨慎。一方面是由于监管和政策的原因,另一方面,银行开发体系庞大,IT架构变革将是一件非常复杂的事情。

5、微服务推进障碍

微服务不是完美架构,会带来系统的各种复杂度,以及运维要求更高等诸多难点 微服务并不是一项横空出世的技术,事实上MicroService的概念已经诞生多年。除了组件和技术不成熟,企业业务模式不急迫的因素外,微服务本身也有自己的劣势。







本次调研,有近一半的企业会谈到对微服务的顾虑。比如部署以后的复杂度,后期运维管理的不友好等等。对于团队来说,搭建微服务架构上手难,运维效率低,运维成本高。另外,还可能带来团队之间沟通上的冲突,微服务需要与DevOps同步推进。微服务被分割成一个个独立的业务模块后,服务间通信接口设计非常重要。如何科学地将系统部署到服务器上,保证各个服务高效运行,更是难点。

微服务推进过程中有许多障碍。对微服务自身复杂度的担忧、缺少具备相关经验的专家、难以招募专业人才和使用相关工具是三个最普遍的障碍。其中对微服务复杂度的顾虑,排名前三的是运维要求和成本高,分布式架构的网络延迟、容错等挑战,以及较强的部署依赖性。

三、Docker与微服务

在接受调研的企业中,2017年在生产环境中采用Docker的比例为9%,测试环境使用达22%。而且规模越大的企业,尤其是服务器规模在500台以上的,是Docker容器的主要采用者。另外,正在考虑评估中的占到被调研企业的一半以上。企业的关注度急剧升高,Docker使用正在快速普及。





 

容器和微服务相辅相成,两大技术成熟的时间点非常契合。容器技术的成熟为微服务提供了得天独厚的客观条件。轻量化的容器是微服务的最佳运行环境,微服务应用只有在容器环境下才能保障运维效率的提升。同时,微服务应用架构对外在组件的管理会变得困难,需要用容器平台去管理中间件,才能发挥出更大价值。

四、微服务化是一个体系,从架构、工具到团队协同

1、企业微服务架构改造需要包括周边配套工具链在内的一整套微服务体系

采用微服务架构改造应用系统,不仅仅是选择开发框架本身,还要建设一套完整的体系架构。既要实现应用模块之间的解耦,还要实现统一管理。

微服务化体系,包括开发框架、以及周边配套工具链和组件,比如服务注册、服务发现、API网关、负载均衡、服务治理、配置中心、安全管理、与容器的结合、监控管理等等。一整套的体系建设是微服务真正的难点所在。

落地过程中,受访企业关注的功能包括,API网关(33%)、服务治理(27%)、配置中心(21%)、分布式任务调度(17%)、应用监控与报警(11%)、高并发(7%)等。这些组件可以根据自身的业务特性选择使用。







2、微服务落地方法论:咨询+产品工具+实施

在IT建设中,企业都希望将开发人员的精力放在自身业务系统的开发上,而工具的整合和使用则主要借助外部供应商的力量来做。软件外包商都有自己的发展历程,迅速改变技术架构不太现实。

另外,传统企业都有大量原有IT系统,掉头和转向不可能丢掉历史包袱,全部推翻重新建设。因此,企业一方面有架构之痛,另一方面不得不总是在业务系统快速上线和新架构选择之间平衡。

对于企业来说,最实际的微服务落地路径是,首先纳入微服务咨询,引入外部行业技术专家角色,站在企业架构的总体高度,帮助企业进行微服务体系规划,落地roadmap,然后借助一些产品和工具进行落地实施。

在本次调研中,有的企业鉴于微服务的优势和业务快速变化的需要,会在新项目建设时直接选择微服务架构进行开发,落地方法也不例外。

3、企业践行微服务的三种类型

目前微服务落地的企业可以分为:温柔型的变革者、业务倒逼型的强硬者、观望型的探索者。

具体来说,温柔的变革者从边缘非核心业务探索尝试新兴技术。渐进式实施、创新灵活多变业务是这类型客户微服务切入的关键词。也是大部分传统企业在切入微服务时,选择的路径。

本次参与调研的企业多是如此,在切入微服务时,选择了诸如测试流程、API网关、开发平台升级、测试环境快速部署等非核心业务进行技术验证。







业务倒逼型是那些企业核心业务系统在日常支撑中承受着巨大压力,必须进行架构改造,否则业务运转举步维艰。观望型的探索者,是那些出于业务考量,要看到行业标杆案例,明确收益和价值,以及技术风险和可靠性充分把握的情况下,才会投入资源开始改造。

4.微服务落地需要从上到下推动和密切团队协同

微服务应用的构建依赖组织结构的变化,它按照业务,而不是技术来划分组织,在推进过程中会受到从上到下的压力,因此必须有决策层的支持和推动。同时,需要团队更好的协同,小团队作战,打破团队间的高墙,减少沟通成本。上了微服务的受访企业对搭建一支敏捷团队都感受很迫切。

五、Service Mesh下一代微服务抢滩登陆

预计两年内服务网格技术将呈现爆发之势

本次的受访者中,有42%表示听说过 ServiceMesh 这一新兴技术理念,但只有6%的受访者对该技术有过一些研究。







微服务带来的复杂度让企业头疼,尤其是服务间通信,如何保证服务间通信的端到端性能和可靠性,催生了下一代微服务Service mesh。2017年,ServiceMesh 经过技术拥趸、技术社区和媒体的反复布道,迅速被业界了解。

Service Mesh 是服务间通信层,可以提供安全、快速、可靠的服务间通讯。在过去的一年中,Service Mesh 已经成为微服务技术栈里的一个关键组件,被誉为“下一代微服务”。

Conduit、Istio 等Service Mesh技术在市场上已形成激烈的竞争,国内外企业开始纷纷站队。国外,一些有高负载业务流量的公司都在他们的生产应用里加入了Service Mesh。国内前沿技术公司开始围绕SpringCloud等开发体系,为客户提供成熟的解决方案和工具产品。同时,探索基于 ServiceMesh 的新方案,积极拥抱Istio/Conduit。

当然对于传统企业来说,技术的先进性是为了保障业务需求的快速变化和发展,而不是一味追求新兴。受访企业表示,一方面会主动关注新技术的最新动向,另一方面在考虑落地时,也要关注新技术的可靠性和有例可循,有无业界最佳实践背书。

六、结论

微服务的核心使命是简化开发,提高IT系统对业务的支撑能力。通过本次调研,我们可以得出如下一些结论:

1.传统行业新兴业务对IT效率的变革需求,业务模式创新重塑要求IT快速响应,是今天微服务炙手可热的主要驱动因素。从目前微服务落地的状态预估有两年左右的培育和成长期。







评估一家企业是否需要上微服务,主要考察这五大关键要素:数据量和业务复杂度,团队规模,应对业务流量变化,是否需要足够的容错容灾,以及功能重复度和差错成本。

2. 实施微服务的理想技术条件包括:进程隔离、数据库表隔离,以及通过公开接口访问。







3. 微服务架构在企业的使用可以分为四个层次:初级使用者、轻度使用者、中度使用者,以及重度使用者。







以技术见长的大型互联网公司首先引领了微服务的风潮,国内制造、金融等大型龙头企业中也有佼佼者开始规划微服务体系,且具备较强的研发实力。大部分企业还处在初步尝试,不成体系,寻找技术和专家力量探讨解决方案的阶段。

4.微服务和容器共生:容器和微服务相辅相成,天生一对。Docker的成熟,让微服务推广和落地更加可靠、方便。随着Docker和微服务架构组件等相关技术的逐步成熟,微服务架构将逐步落地传统企业。 







5.微服务落地方法论:微服务主要用来解决系统的复杂性问题,企业客户对于如何实施微服务并不清晰,同时有诸多顾虑。受企业客户青睐的落地方法是:微服务咨询+产品工具+实施。 







6.微服务落地策略:微服务正成为许多企业构建应用时的首选。微服务并不缺乏受众,有的企业将微服务用于新应用开发,有的关注将单体应用迁移到微服务架构。微服务改造循序渐进,快速演化只会适得其反。另外,落地过程中注意开发和运维部门的协同,进行组织内管理创新。 







关于调研对象

本次调研我们总计收到了来自182家企业受访者的调研问卷,并现场调研部分受访企业。覆盖制造/航空、金融、互联网、地产、交通物流和零售等行业,受访者包括CIO、CTO等IT高管,及开发、基础架构部门IT人员。

参考资料: 
1.The State of Microservices Survey 2017 – Eight Trends You Need to Know 
https://dzone.com/articles/the ... trend 
2、Microservices: Breaking Down the Monolith 
https://dzone.com/guides/micro ... olith 
3.微服务企业级落地将会带来哪些转变? 
http://mp.weixin.qq.com/s/3LkU4OwpgSPdFFY5__dheQ 
4.深度剖析微服务架构的九大特征 
http://developer.51cto.com/art/201608/516401.htm 查看全部
开篇:

如果在诸多热门云计算技术中,诸如容器、微服务、DevOps、OpenStack 等,找出一个最火的方向,那么非微服务莫属。尽管话题炙手可热,但对传统行业来说,微服务落地和方法论目前处于起步阶段。

本报告于2017年11月份展开,从驱动因素、落地现状、和容器关系、架构体系、未来趋势和落地方法论等方面对微服务进行了分析。希望能够为传统企业微服务决策、规划和实施提供依据和解决办法。

一、驱动因素

传统行业对IT效率的变革需求是微服务成长土壤,业务模式创新重塑导致系统更新频繁、应用复杂度急剧升高,传统架构不堪重负。

微服务架构具有明显的好处,尤其是在应对复杂业务系统的多变需求方面。在本次调研企业中,每个月都要进行业务系统更新的比例占63%,只有不到20%的企业半年以上更新一次系统。


1.jpg


2.jpg



加快互联网+步伐成为许多传统企业的必然选择。业务场景、用户习惯和行为在迅速变化,许多传统行业线上业务出现急速增长。

比如金融行业的移动支付、互联网理财等,汽车制造行业的营销、电商、售后服务等线上业务比例迅速提高。IT团队业务开发、迭代都以每月、甚至每周来计,需要7*24小时响应,这些给系统开发和运维带来极大挑战。

在IT对业务的响应和支撑方面,不同行业所面临的困扰略有不同,但总体差异不明显。调研显示,系统支撑方面排在前四的难题分别为:系统复杂性越来越高(28%),运维管理复杂度高,打造一支全栈运维团队困难(26%),线上访问压力大(19%),设备采购维护成本高(19%)。

3.jpg



在传统单体或SOA架构下,应用如果频繁升级更新,开发团队非常痛苦。企业的业务应用经过多年IT建设,系统非常庞大,要改动其中任何一小部分,都需要重新部署整个应用,敏捷开发和快速交付无从谈起。

传统企业在长期的IT建设过程中,通常大量使用外包团队,这导致采用的技术栈之间差异较大,统一管控和运维要求更高。需要运维7*24小时全天候值守、在线升级,并快速响应。

在此时脱颖而出的微服务技术,面对上述困惑几乎浑身优点:独立开发、独立部署、独立发布,去中心化管理,支持高并发高可用,支持丰富技术栈,企业可以根据需要灵活技术选型。

二、微服务落地现状

1、微服务客户画像


微服务架构在企业的使用情况可以分为四个层次:初级使用者、轻度使用者、中度使用者、以及重度使用者。初级使用者基本是传统架构,独立部署需求不突出,技术堆栈不成熟,需要较长的培育和成长期。轻度使用的企业边缘业务系统开始使用Spring Boot 或Spring Cloud等框架,但组件的使用尚不熟练。

中度使用者为使用Dubbo或Spring cloud时间较长,但还没有做周边配套的工具链。重度使用者是那些走在微服务架构改造前沿,具备微服务规划和体系,有自己研发实力的企业,通常是以技术见长的大型互联网公司。

2、15% 左右的调研企业引入了SpringCloud、Dubbo等微服务主流开发框架

此次调研中,6%的企业已经部分引入了Spring Cloud 开发框架,Spring Cloud 也被开发者认为是最好的开发框架。另外,9%的受访企业采用了 Dubbo 等其他微服务框架,也就是说引入了或考虑引入微服务架构的企业达15%。

image005.jpg



此外,还有51%以上的企业在考虑往云原生方向转型。这是由于企业数字化转型背景下,IT要更好适应线上业务趋势的必然要求。加上国家政策层面对云服务的支持,传统企业云化是大势所趋。

* 3、微服务四大技术优势受青睐*

从IT技术发展趋势看,无论硬件、软件、还是基础架构都在朝着轻量化的方向发展。微服务通过化整为零的概念,将复杂的IT部署分解成更小、更独立的微服务。 相对传统的建设方法,传统企业更看重微服务如下四方面的优势:技术选型灵活,更轻松采用新架构和语言(28%)降低系统内部服务冗余,提升开发效率(27%)独立部署(22%)更好的容错机制(20%)


image006.jpg


在涉及复杂项目时,和单体架构的对比中,微服务从多个角度显示出了压倒性的优势。

4、制造业开始发力、金融小试牛刀

这里所说制造业,是大制造的概念,包括制造、汽车、大型制造以及航空业等。这些行业往引入Spring Cloud、Dubbo等微服务开发框架的企业占比超过15%。制造业开始初步尝试微服务架构。 能看出制造业向“智造”转型的影响,今天的制造业结合了物联网、传感器、云计算、大数据等技术,人工智能技术正在工业、汽车驾驶等领域应用。大量新兴业务场景出现,服务变得复杂,产业的弯道超车带来了明显的微服务需求。
 

image007.jpg



其次,需求明显的为金融行业,包括银行、保险、证券等。尤其是一些国有银行、股份制银行以及城商行等大行都走在架构改造的前列。在自己的创新业务,如手机银行、微信银行、互联网理财等业务上试水微服务架构。在核心业务系统方面,则相当谨慎。一方面是由于监管和政策的原因,另一方面,银行开发体系庞大,IT架构变革将是一件非常复杂的事情。

5、微服务推进障碍

微服务不是完美架构,会带来系统的各种复杂度,以及运维要求更高等诸多难点 微服务并不是一项横空出世的技术,事实上MicroService的概念已经诞生多年。除了组件和技术不成熟,企业业务模式不急迫的因素外,微服务本身也有自己的劣势。

image008.jpg



本次调研,有近一半的企业会谈到对微服务的顾虑。比如部署以后的复杂度,后期运维管理的不友好等等。对于团队来说,搭建微服务架构上手难,运维效率低,运维成本高。另外,还可能带来团队之间沟通上的冲突,微服务需要与DevOps同步推进。微服务被分割成一个个独立的业务模块后,服务间通信接口设计非常重要。如何科学地将系统部署到服务器上,保证各个服务高效运行,更是难点。

微服务推进过程中有许多障碍。对微服务自身复杂度的担忧、缺少具备相关经验的专家、难以招募专业人才和使用相关工具是三个最普遍的障碍。其中对微服务复杂度的顾虑,排名前三的是运维要求和成本高,分布式架构的网络延迟、容错等挑战,以及较强的部署依赖性。

三、Docker与微服务

在接受调研的企业中,2017年在生产环境中采用Docker的比例为9%,测试环境使用达22%。而且规模越大的企业,尤其是服务器规模在500台以上的,是Docker容器的主要采用者。另外,正在考虑评估中的占到被调研企业的一半以上。企业的关注度急剧升高,Docker使用正在快速普及。

image009.jpg

 

容器和微服务相辅相成,两大技术成熟的时间点非常契合。容器技术的成熟为微服务提供了得天独厚的客观条件。轻量化的容器是微服务的最佳运行环境,微服务应用只有在容器环境下才能保障运维效率的提升。同时,微服务应用架构对外在组件的管理会变得困难,需要用容器平台去管理中间件,才能发挥出更大价值。

四、微服务化是一个体系,从架构、工具到团队协同

1、企业微服务架构改造需要包括周边配套工具链在内的一整套微服务体系

采用微服务架构改造应用系统,不仅仅是选择开发框架本身,还要建设一套完整的体系架构。既要实现应用模块之间的解耦,还要实现统一管理。

微服务化体系,包括开发框架、以及周边配套工具链和组件,比如服务注册、服务发现、API网关、负载均衡、服务治理、配置中心、安全管理、与容器的结合、监控管理等等。一整套的体系建设是微服务真正的难点所在。

落地过程中,受访企业关注的功能包括,API网关(33%)、服务治理(27%)、配置中心(21%)、分布式任务调度(17%)、应用监控与报警(11%)、高并发(7%)等。这些组件可以根据自身的业务特性选择使用。


image010.jpg


2、微服务落地方法论:咨询+产品工具+实施

在IT建设中,企业都希望将开发人员的精力放在自身业务系统的开发上,而工具的整合和使用则主要借助外部供应商的力量来做。软件外包商都有自己的发展历程,迅速改变技术架构不太现实。

另外,传统企业都有大量原有IT系统,掉头和转向不可能丢掉历史包袱,全部推翻重新建设。因此,企业一方面有架构之痛,另一方面不得不总是在业务系统快速上线和新架构选择之间平衡。

对于企业来说,最实际的微服务落地路径是,首先纳入微服务咨询,引入外部行业技术专家角色,站在企业架构的总体高度,帮助企业进行微服务体系规划,落地roadmap,然后借助一些产品和工具进行落地实施。

在本次调研中,有的企业鉴于微服务的优势和业务快速变化的需要,会在新项目建设时直接选择微服务架构进行开发,落地方法也不例外。

3、企业践行微服务的三种类型

目前微服务落地的企业可以分为:温柔型的变革者、业务倒逼型的强硬者、观望型的探索者。

具体来说,温柔的变革者从边缘非核心业务探索尝试新兴技术。渐进式实施、创新灵活多变业务是这类型客户微服务切入的关键词。也是大部分传统企业在切入微服务时,选择的路径。

本次参与调研的企业多是如此,在切入微服务时,选择了诸如测试流程、API网关、开发平台升级、测试环境快速部署等非核心业务进行技术验证。


image011.jpg


业务倒逼型是那些企业核心业务系统在日常支撑中承受着巨大压力,必须进行架构改造,否则业务运转举步维艰。观望型的探索者,是那些出于业务考量,要看到行业标杆案例,明确收益和价值,以及技术风险和可靠性充分把握的情况下,才会投入资源开始改造。

4.微服务落地需要从上到下推动和密切团队协同

微服务应用的构建依赖组织结构的变化,它按照业务,而不是技术来划分组织,在推进过程中会受到从上到下的压力,因此必须有决策层的支持和推动。同时,需要团队更好的协同,小团队作战,打破团队间的高墙,减少沟通成本。上了微服务的受访企业对搭建一支敏捷团队都感受很迫切。

五、Service Mesh下一代微服务抢滩登陆

预计两年内服务网格技术将呈现爆发之势

本次的受访者中,有42%表示听说过 ServiceMesh 这一新兴技术理念,但只有6%的受访者对该技术有过一些研究。

image012.jpg



微服务带来的复杂度让企业头疼,尤其是服务间通信,如何保证服务间通信的端到端性能和可靠性,催生了下一代微服务Service mesh。2017年,ServiceMesh 经过技术拥趸、技术社区和媒体的反复布道,迅速被业界了解。

Service Mesh 是服务间通信层,可以提供安全、快速、可靠的服务间通讯。在过去的一年中,Service Mesh 已经成为微服务技术栈里的一个关键组件,被誉为“下一代微服务”。

Conduit、Istio 等Service Mesh技术在市场上已形成激烈的竞争,国内外企业开始纷纷站队。国外,一些有高负载业务流量的公司都在他们的生产应用里加入了Service Mesh。国内前沿技术公司开始围绕SpringCloud等开发体系,为客户提供成熟的解决方案和工具产品。同时,探索基于 ServiceMesh 的新方案,积极拥抱Istio/Conduit。

当然对于传统企业来说,技术的先进性是为了保障业务需求的快速变化和发展,而不是一味追求新兴。受访企业表示,一方面会主动关注新技术的最新动向,另一方面在考虑落地时,也要关注新技术的可靠性和有例可循,有无业界最佳实践背书。

六、结论

微服务的核心使命是简化开发,提高IT系统对业务的支撑能力。通过本次调研,我们可以得出如下一些结论:

1.传统行业新兴业务对IT效率的变革需求,业务模式创新重塑要求IT快速响应,是今天微服务炙手可热的主要驱动因素。从目前微服务落地的状态预估有两年左右的培育和成长期。


image013.jpg


评估一家企业是否需要上微服务,主要考察这五大关键要素:数据量和业务复杂度,团队规模,应对业务流量变化,是否需要足够的容错容灾,以及功能重复度和差错成本。

2. 实施微服务的理想技术条件包括:进程隔离、数据库表隔离,以及通过公开接口访问。

image014.jpg



3. 微服务架构在企业的使用可以分为四个层次:初级使用者、轻度使用者、中度使用者,以及重度使用者。

image015.jpg



以技术见长的大型互联网公司首先引领了微服务的风潮,国内制造、金融等大型龙头企业中也有佼佼者开始规划微服务体系,且具备较强的研发实力。大部分企业还处在初步尝试,不成体系,寻找技术和专家力量探讨解决方案的阶段。

4.微服务和容器共生:容器和微服务相辅相成,天生一对。Docker的成熟,让微服务推广和落地更加可靠、方便。随着Docker和微服务架构组件等相关技术的逐步成熟,微服务架构将逐步落地传统企业。 


image016.jpg


5.微服务落地方法论:微服务主要用来解决系统的复杂性问题,企业客户对于如何实施微服务并不清晰,同时有诸多顾虑。受企业客户青睐的落地方法是:微服务咨询+产品工具+实施。 

image017.jpg



6.微服务落地策略:微服务正成为许多企业构建应用时的首选。微服务并不缺乏受众,有的企业将微服务用于新应用开发,有的关注将单体应用迁移到微服务架构。微服务改造循序渐进,快速演化只会适得其反。另外,落地过程中注意开发和运维部门的协同,进行组织内管理创新。 

image018.jpg



关于调研对象

本次调研我们总计收到了来自182家企业受访者的调研问卷,并现场调研部分受访企业。覆盖制造/航空、金融、互联网、地产、交通物流和零售等行业,受访者包括CIO、CTO等IT高管,及开发、基础架构部门IT人员。

参考资料: 
1.The State of Microservices Survey 2017 – Eight Trends You Need to Know 
https://dzone.com/articles/the ... trend 
2、Microservices: Breaking Down the Monolith 
https://dzone.com/guides/micro ... olith 
3.微服务企业级落地将会带来哪些转变? 
http://mp.weixin.qq.com/s/3LkU4OwpgSPdFFY5__dheQ 
4.深度剖析微服务架构的九大特征 
http://developer.51cto.com/art/201608/516401.htm

容器之后的下一个明星,关于无服务器(Serverless)架构你要搞懂的8件事

杨y 发表了文章 • 0 个评论 • 78 次浏览 • 2018-01-04 06:52 • 来自相关话题

无服务器计算,虽然神秘,但一定会成为IT行业最有力的工具之一。这种可能改变游戏规则的技术虽然不是全新的,但就像之前的容器技术一样,有一些神化和误解。
1
1什么是无服务器(Serverless)计算?
无服务器计算允许企业构建、运行应用和服务而不用去考虑服务器。无服务器应用不需要管理任何服务器,而且任何类型的应用或后端服务都可以构建为无服务器应用。运行应用以及应用高可用所需要的一切,都由云服务商来提供。
无服务器应用程序有四大优势:
1)不需要管理服务– 不需要提供或维护任何的服务器,不需要安装任何的软件或运行时。
2)弹性扩缩–应用程序扩缩能自动完成或是通过调整其资源使用量来调整容量,而不是通过增减服务器的数量。
3)高可用-无服务器应用程序内置高可用和容错。无需考虑高可用,运行应用的服务默认提供高可用。
4)没有闲置损耗-不需要对计算和存储之类的服务预留容量。如果代码没有运行,就不会收费。
构建无服务器应用程序意味着开发者可以专注在产品代码上,而无须管理和操作云端或本地的服务器或运行时。
2无服务器(Serverless)计算如何工作?
与使用虚拟机或一些底层的技术来部署和管理应用程序相比,无服务器计算提供了一种更高级别的抽象。因为它们有不同的抽象和“触发器”的集合。
拿计算来讲,这种抽象有一个特定函数和抽象的触发器,它通常是一个事件。以数据库为例,这种抽象也许是一个表,而触发器相当于表的查询或搜索,或者通过在表中做一些事情而生成的事件。
比如一款手机游戏,允许用户在不同的平台上为全球顶级玩家使用高分数表。当请求此信息时,请求从应用程序到API接口。API接口或许会触发 aws 的Lambda函数,或者无服务器函数,这些函数再从数据库表中获取到数据流,返回包含前五名分数的一定格式的数据。
一旦构建完成,应用程序的功能就可以在基于移动和基于 web 的游戏版本中重用。
这跟设置服务器不同,不是必须要有Amazon EC2实例或服务器,然后等待请求。环境由事件触发,而响应事件所需的逻辑只在响应时执行。这意味着,运行函数的资源只有在函数运行时被创建,产生一种非常高效的方法来构建应用程序。
3适用于哪些场景?
无服务器计算适合于任何事件驱动的各种不同的用例。这包括物联网,移动应用,基于网络的应用程序和聊天机器人。事件是由人的动作(比如按下按钮),传感器或者系统中的数据流产生。
这方面的一个例子是,Thomson Reuters(人名)使用AWS Lambda来加载和处理数据流,而无需提供或管理任何服务器。Thomson Reuters建立了一个解决方案,使其能够捕捉、分析和可视化其产品所生成的分析数据,提供帮助产品团队不断改进用户体验的见解。
AWS Lambda只在通过与其他AWS服务、Kinesis和AmazonS3集成的新数据条目触发时运行代码。
在事件驱动下,当代码运行时,公司只收取计算处理的费用,这是非常节约成本的。
4不适用哪些场景?
对于已经构建的遗留应用程序来说,这不一定是一个完全的解决方案。如果是一个单体应用或者应用需要运行在操作系统级别,这样的应用就不适合在无服务器平台上运行。这并不意味着这样的应用没法实现无服务器架构,它只是意味着需要重新构建应用程序。
一个很好的例子是web应用程序,可以在应用程序服务器(如Tomcat)中将其作为一个大型的单体job运行。如果要将应用程序分解为复合函数集,则可以使用无服务器模型实现所有的新功能。随着时间的推移,旧版本应用程序的使用级别越来越小,这些新的无服务器组件的使用率随着使用量的增加而增加。对于这样的客户,都有一个过渡模型,客户可以遵循这种过渡模式,将传统的基于机器的应用程序架构迁移到基于功能的架构。
5无服务器(Serverless)计算贵吗?
并不贵。只需要支付企业所使用的部分,没有任何与无服务器计算相关的成本。特别对于小的用例,应用程序使用随时间变化大的企业是非常划算的。
对于希望管理工作负载和操作的客户来说,它也非常划算,因为它可以使客户避免成本,例如容量规划或部署工具。许多AWS的客户,现在正在尝试用服务器来提高敏捷度,同时也节省了成本。健康零食公司Graze有许多使用for AWS的方法,包括将分析数据实时上传至亚马逊RedShift、管理备份和检查GitHub拉请求,希望在未来几个月内将其使用量增加两到三倍。
6无服务器(Serverless)的行业炒作
无服务器计算得到了开发人员的积极响应。在以资源有效的方式交付应用程序时,它提供了更多的选项和可能性。
很多大型的企业,比如Netflix,已经在探索无服务器计算,希望解放开发人员的时间。Netflix使用AWS Lambda来构建基于规则的自我管理基础设施,并替换低效的流程,减少错误的速率,为开发人员节省宝贵的时间。
以前,云开发者必须使用那些耗费大量人力和时间的机器。无服务器技术允许开发人员在几分钟内运行测试和产品。开发人员直接控制部署时间以及如何部署,通过建模框架控制应用架构。还允许发布自己的产品并亲自体验。
2
容器和无服务器(Serverless)
无服务器计算和容器之间正在酝酿一场战斗——当尘埃落定时,谁会倒下?会是容器吗?
如前所述,无服务器具备一些明显的优势。比如节省成本,提高IT支出的效率,减少资源和维护需求,允许开发人员和IT人员专注于高价值的任务等等。这也是为什么人们会对这项技术充满热情的原因。但是,通往无服务器的路径并不轻松。
SetfiveConsulting 的合伙人 Ashish Datta 说,将基于容器的架构迁移到无服务器通常需要重新架构系统的重要部分。
“与从虚拟机到容器的转换相比,从容器到无服务器的转换更有戏剧性,因为容器和无服务器之间的计算环境发生了根本性的变化。”
相反,从虚拟机到容器的迁移更为直接,因为这实际上只是部署哲学的变化。
Stackery CEO Nate Taggart说,最大的障碍是企业无法轻易地迁移到无服务器架构上。
“(无服务器应用程序)必须是为无服务器基础设施设计的。这对于新的开发来说可能是相当经济的,但是迁移遗留应用程序将是很繁重的,在某些情况下甚至是不可能的。
今天的无服务器产品有资源的限制,Taggert解释道,包括内存、计算和时间限制;有限的语言支持;以及在请求之间管理状态的特殊考虑。所有这些都必须“从一开始就融入到应用程序设计中”,Taggert说。
PubNub的产品营销总监James Riseman说,迁移到无服务器架构还需要对现有基础设施进行重大的反思。
“无服务器计算需要一个非常现代的、组件化的架构。系统和应用程序必须被分解成离散的逻辑函数,而要保证这样的质量企业会失去控制。” JamesRiseman 表示。
无服务器的另一个问题是定价。“公司是按照每笔交易或每秒钟计费,而不是按照传统的基础设施条款,”Siseman说。“这使得定价更加难以预测。”
除了地址迁移需求之外,转向无服务器计算还会导致思维模式的改变。
“最大的障碍之一是,需要考虑在离散的单元中计算资源,而不是始终占用进行计算。”这与对内存使用量和运行时等框架的限制相吻合,比如Amazon Lambda这样的框架。“Atta说道。
1对手还是盟友?
撇开正反两方面的因素不说,在面对面的交锋中,容器和无服务器是相互排斥的解决方案。但是每个人都说这样想是错误的。
SwymSystems CEO兼首席顾问Todd Millecam 表示,这是一种苹果和橘子的比较。“两者都有使用,如果观察大多数无服务器技术的运行方式,它们只是在后台运行容器。”
无服务器和容器是互相补充而并非重叠的角色。Taggart说,虽然两者都可以用于计算任务,但每个任务都有其优缺点。无服务器是一种理想的、可预测的、具有小型资源需求和短期事务的工作负载。
容器对于长时运行的流程和可预测的工作负载具有优势。容器在应用程序设计方面也提供了更多的灵活性,但需要对底层基础架构进行更多的管理。
 “作为一个无服务器操作控制台产品,我们有一个几乎完全没有服务器的后端,”Taggart补充说,但是仍然使用容器来处理某些工作负载,在这些工作负载中,它们是更好的工作工具
2Serverless是未来吗?
看来,关于容器式微的谣言被夸大了。
Datta说,不同的架构和应用程序总是需要不同程度的抽象,同样,不同的团队也会对做出不同的权衡。
正如容器没有取代虚拟机,虚拟机也没有取代裸金属的服务器。抽象不会成为“更接近金属”的解决方案的生死存亡的威胁。
无服务器,应该被看作是技术的进化。大多数观察者警告说,无服务器仍然不成熟,还没有建立架构模型和健壮的开发工具。这意味着将企业应用程序的命运与特定的云供应商绑定,将带来自身的风险。
因此,尽管它有巨大的潜力,但可能需要数年才能在企业中获得广泛的应用。
同时,无服务器将会对创业公司产生重大影响。
 “无服务器计算提供了一种托管代码的方法,并以很低廉的成本在web上可用。在拥有活跃的用户基础之前,无服务器是构建web应用程序的一种划算的方式。”Millecam说道。
不过,数字机构POP CTO Jake Bennett 表示,随着无服务计算技术的成熟,架构师会发现无服务器将越来越难以抗拒。“无服务器计算解决了太多被忽视的问题。将对可伸缩性问题的关注转移给第三方供应商,是每个开发人员的梦想,让别人关心服务器维护是IT运维人员的一种幻想。”
 
原文链接:
1、Everything you need to know about Serverless Computing
https://www.tuicool.com/articles/yMZVfev
2、Serverless and containers: Is a throw down under way?
https://www.tuicool.com/articles/BvUziyY 查看全部

无服务器计算,虽然神秘,但一定会成为IT行业最有力的工具之一。这种可能改变游戏规则的技术虽然不是全新的,但就像之前的容器技术一样,有一些神化和误解。
1
1什么是无服务器(Serverless)计算?
无服务器计算允许企业构建、运行应用和服务而不用去考虑服务器。无服务器应用不需要管理任何服务器,而且任何类型的应用或后端服务都可以构建为无服务器应用。运行应用以及应用高可用所需要的一切,都由云服务商来提供。
无服务器应用程序有四大优势:
1)不需要管理服务– 不需要提供或维护任何的服务器,不需要安装任何的软件或运行时。
2)弹性扩缩–应用程序扩缩能自动完成或是通过调整其资源使用量来调整容量,而不是通过增减服务器的数量。
3)高可用-无服务器应用程序内置高可用和容错。无需考虑高可用,运行应用的服务默认提供高可用。
4)没有闲置损耗-不需要对计算和存储之类的服务预留容量。如果代码没有运行,就不会收费。
构建无服务器应用程序意味着开发者可以专注在产品代码上,而无须管理和操作云端或本地的服务器或运行时。
2无服务器(Serverless)计算如何工作?
与使用虚拟机或一些底层的技术来部署和管理应用程序相比,无服务器计算提供了一种更高级别的抽象。因为它们有不同的抽象和“触发器”的集合。
拿计算来讲,这种抽象有一个特定函数和抽象的触发器,它通常是一个事件。以数据库为例,这种抽象也许是一个表,而触发器相当于表的查询或搜索,或者通过在表中做一些事情而生成的事件。
比如一款手机游戏,允许用户在不同的平台上为全球顶级玩家使用高分数表。当请求此信息时,请求从应用程序到API接口。API接口或许会触发 aws 的Lambda函数,或者无服务器函数,这些函数再从数据库表中获取到数据流,返回包含前五名分数的一定格式的数据。
一旦构建完成,应用程序的功能就可以在基于移动和基于 web 的游戏版本中重用。
这跟设置服务器不同,不是必须要有Amazon EC2实例或服务器,然后等待请求。环境由事件触发,而响应事件所需的逻辑只在响应时执行。这意味着,运行函数的资源只有在函数运行时被创建,产生一种非常高效的方法来构建应用程序。
3适用于哪些场景?
无服务器计算适合于任何事件驱动的各种不同的用例。这包括物联网,移动应用,基于网络的应用程序和聊天机器人。事件是由人的动作(比如按下按钮),传感器或者系统中的数据流产生。
这方面的一个例子是,Thomson Reuters(人名)使用AWS Lambda来加载和处理数据流,而无需提供或管理任何服务器。Thomson Reuters建立了一个解决方案,使其能够捕捉、分析和可视化其产品所生成的分析数据,提供帮助产品团队不断改进用户体验的见解。
AWS Lambda只在通过与其他AWS服务、Kinesis和AmazonS3集成的新数据条目触发时运行代码。
在事件驱动下,当代码运行时,公司只收取计算处理的费用,这是非常节约成本的。
4不适用哪些场景?
对于已经构建的遗留应用程序来说,这不一定是一个完全的解决方案。如果是一个单体应用或者应用需要运行在操作系统级别,这样的应用就不适合在无服务器平台上运行。这并不意味着这样的应用没法实现无服务器架构,它只是意味着需要重新构建应用程序。
一个很好的例子是web应用程序,可以在应用程序服务器(如Tomcat)中将其作为一个大型的单体job运行。如果要将应用程序分解为复合函数集,则可以使用无服务器模型实现所有的新功能。随着时间的推移,旧版本应用程序的使用级别越来越小,这些新的无服务器组件的使用率随着使用量的增加而增加。对于这样的客户,都有一个过渡模型,客户可以遵循这种过渡模式,将传统的基于机器的应用程序架构迁移到基于功能的架构。
5无服务器(Serverless)计算贵吗?
并不贵。只需要支付企业所使用的部分,没有任何与无服务器计算相关的成本。特别对于小的用例,应用程序使用随时间变化大的企业是非常划算的。
对于希望管理工作负载和操作的客户来说,它也非常划算,因为它可以使客户避免成本,例如容量规划或部署工具。许多AWS的客户,现在正在尝试用服务器来提高敏捷度,同时也节省了成本。健康零食公司Graze有许多使用for AWS的方法,包括将分析数据实时上传至亚马逊RedShift、管理备份和检查GitHub拉请求,希望在未来几个月内将其使用量增加两到三倍。
6无服务器(Serverless)的行业炒作
无服务器计算得到了开发人员的积极响应。在以资源有效的方式交付应用程序时,它提供了更多的选项和可能性。
很多大型的企业,比如Netflix,已经在探索无服务器计算,希望解放开发人员的时间。Netflix使用AWS Lambda来构建基于规则的自我管理基础设施,并替换低效的流程,减少错误的速率,为开发人员节省宝贵的时间。
以前,云开发者必须使用那些耗费大量人力和时间的机器。无服务器技术允许开发人员在几分钟内运行测试和产品。开发人员直接控制部署时间以及如何部署,通过建模框架控制应用架构。还允许发布自己的产品并亲自体验。
2
容器和无服务器(Serverless)
无服务器计算和容器之间正在酝酿一场战斗——当尘埃落定时,谁会倒下?会是容器吗?
如前所述,无服务器具备一些明显的优势。比如节省成本,提高IT支出的效率,减少资源和维护需求,允许开发人员和IT人员专注于高价值的任务等等。这也是为什么人们会对这项技术充满热情的原因。但是,通往无服务器的路径并不轻松。
SetfiveConsulting 的合伙人 Ashish Datta 说,将基于容器的架构迁移到无服务器通常需要重新架构系统的重要部分。
“与从虚拟机到容器的转换相比,从容器到无服务器的转换更有戏剧性,因为容器和无服务器之间的计算环境发生了根本性的变化。”
相反,从虚拟机到容器的迁移更为直接,因为这实际上只是部署哲学的变化。
Stackery CEO Nate Taggart说,最大的障碍是企业无法轻易地迁移到无服务器架构上。
“(无服务器应用程序)必须是为无服务器基础设施设计的。这对于新的开发来说可能是相当经济的,但是迁移遗留应用程序将是很繁重的,在某些情况下甚至是不可能的。
今天的无服务器产品有资源的限制,Taggert解释道,包括内存、计算和时间限制;有限的语言支持;以及在请求之间管理状态的特殊考虑。所有这些都必须“从一开始就融入到应用程序设计中”,Taggert说。
PubNub的产品营销总监James Riseman说,迁移到无服务器架构还需要对现有基础设施进行重大的反思。
“无服务器计算需要一个非常现代的、组件化的架构。系统和应用程序必须被分解成离散的逻辑函数,而要保证这样的质量企业会失去控制。” JamesRiseman 表示。
无服务器的另一个问题是定价。“公司是按照每笔交易或每秒钟计费,而不是按照传统的基础设施条款,”Siseman说。“这使得定价更加难以预测。”
除了地址迁移需求之外,转向无服务器计算还会导致思维模式的改变。
“最大的障碍之一是,需要考虑在离散的单元中计算资源,而不是始终占用进行计算。”这与对内存使用量和运行时等框架的限制相吻合,比如Amazon Lambda这样的框架。“Atta说道。
1对手还是盟友?
撇开正反两方面的因素不说,在面对面的交锋中,容器和无服务器是相互排斥的解决方案。但是每个人都说这样想是错误的。
SwymSystems CEO兼首席顾问Todd Millecam 表示,这是一种苹果和橘子的比较。“两者都有使用,如果观察大多数无服务器技术的运行方式,它们只是在后台运行容器。”
无服务器和容器是互相补充而并非重叠的角色。Taggart说,虽然两者都可以用于计算任务,但每个任务都有其优缺点。无服务器是一种理想的、可预测的、具有小型资源需求和短期事务的工作负载。
容器对于长时运行的流程和可预测的工作负载具有优势。容器在应用程序设计方面也提供了更多的灵活性,但需要对底层基础架构进行更多的管理。
 “作为一个无服务器操作控制台产品,我们有一个几乎完全没有服务器的后端,”Taggart补充说,但是仍然使用容器来处理某些工作负载,在这些工作负载中,它们是更好的工作工具
2Serverless是未来吗?
看来,关于容器式微的谣言被夸大了。
Datta说,不同的架构和应用程序总是需要不同程度的抽象,同样,不同的团队也会对做出不同的权衡。
正如容器没有取代虚拟机,虚拟机也没有取代裸金属的服务器。抽象不会成为“更接近金属”的解决方案的生死存亡的威胁。
无服务器,应该被看作是技术的进化。大多数观察者警告说,无服务器仍然不成熟,还没有建立架构模型和健壮的开发工具。这意味着将企业应用程序的命运与特定的云供应商绑定,将带来自身的风险。
因此,尽管它有巨大的潜力,但可能需要数年才能在企业中获得广泛的应用。
同时,无服务器将会对创业公司产生重大影响。
 “无服务器计算提供了一种托管代码的方法,并以很低廉的成本在web上可用。在拥有活跃的用户基础之前,无服务器是构建web应用程序的一种划算的方式。”Millecam说道。
不过,数字机构POP CTO Jake Bennett 表示,随着无服务计算技术的成熟,架构师会发现无服务器将越来越难以抗拒。“无服务器计算解决了太多被忽视的问题。将对可伸缩性问题的关注转移给第三方供应商,是每个开发人员的梦想,让别人关心服务器维护是IT运维人员的一种幻想。”
 
原文链接:
1、Everything you need to know about Serverless Computing
https://www.tuicool.com/articles/yMZVfev
2、Serverless and containers: Is a throw down under way?
https://www.tuicool.com/articles/BvUziyY

中国开源云联盟第二次全会7月26日在北京召开

杨y 发表了文章 • 0 个评论 • 200 次浏览 • 2017-07-25 17:50 • 来自相关话题

由工业和信息化部信息化和软件服务业司指导,中国开源云联盟第二次全体成员会议(以下简称“二次全会”)将于2017年7月26日在北京召开。

2016年4月,中国开源云联盟(COSCL)正式挂靠于中国电子技术标准化研究院,在工信部的领导下,在全体联盟成员单位的共同支持下,联盟已形成多项工作成果,包括发布团体标准一项、技术白皮书两份、组织开展第三届OpenStack开源技术黑客松活动以及组织开展2016年中国优秀开源案例评选活动等。

此次联盟全会将聚焦云计算变革与创新,深度探讨开源技术为IT领域带来的全局性持续转变,工业和信息化部 信息化和软件服务司领导将出席会议,与100余家联盟单位共同规划中国开源云联盟下一步工作,会上也将有多项联盟成果进行发布。

中国开源云联盟第二次全会会议议程

2017年第1次(总第2次)


指导单位:中华人民共和国工业和信息化部信息化和软件服务业司

主办单位:中国开源云联盟、中国电子技术标准化研究院

协办单位:华为、中标软件、X·SKY、数人云、九州云、去哪儿网

会议时间:2017年7月26日

会议地点:北京万寿宾馆






(注:议程以当天发布为准)



关于数人云


数人云成立于2014年,创始团队来自谷歌、红帽和惠普,作为领先的云计算开源技术实践者,数人云致力于帮助传统企业提升IT对业务的支撑能力,帮助客户统一管理资源和应用,加速应用交付、提升运维效率,建设新一代基于云计算技术的IT架构体系。


数人云重点聚焦打造基于容器的最轻量级PaaS平台,在实现应用全生命周期管理的同时,管理海量监控、日志等产生的各类数据,自动分配应用资源、对业务运行状况进行自动分析,提升企业的IT工业化程度,构建灵动新IT。


2016年数人云加入中国开源云联盟,2017年成为Linux基金会成员,并加入OCI(The Open Container Initiative)联盟,携手与国内外云计算伙伴共同推动云计算领域容器等开源技术的落地与发展。


关于中国开源云联盟

中国开源云联盟(简称“COSCL”)由Intel、新浪网、中标软件和上海交大于2012年8月共同发起创立,是中国最早专注于OpenStack的专业联盟,一直致力于在中国推动OpenStack技术开发、操作系统支持、性能优化、规模部署等工作。


2016年,在工业和信息化部信息化和软件服务业司的指导下,中国开源云联盟正式挂靠中国电子技术标准化研究院,推进联盟后续工作。中国电子技术标准化研究院作为工信部直属的电子信息领域标准化研究机构,一直致力于联合产业界推动开源软件技术和开源标准化工作的发展,探索开源标准与国家标准、国际标准的有机结合,并努力推动开源标准化工作思路和模式的创新。 查看全部

924663e96e42fc508f69f4359ba852ef.jpg


由工业和信息化部信息化和软件服务业司指导,中国开源云联盟第二次全体成员会议(以下简称“二次全会”)将于2017年7月26日在北京召开。

2016年4月,中国开源云联盟(COSCL)正式挂靠于中国电子技术标准化研究院,在工信部的领导下,在全体联盟成员单位的共同支持下,联盟已形成多项工作成果,包括发布团体标准一项、技术白皮书两份、组织开展第三届OpenStack开源技术黑客松活动以及组织开展2016年中国优秀开源案例评选活动等。

此次联盟全会将聚焦云计算变革与创新,深度探讨开源技术为IT领域带来的全局性持续转变,工业和信息化部 信息化和软件服务司领导将出席会议,与100余家联盟单位共同规划中国开源云联盟下一步工作,会上也将有多项联盟成果进行发布。

中国开源云联盟第二次全会会议议程

2017年第1次(总第2次)



指导单位:中华人民共和国工业和信息化部信息化和软件服务业司

主办单位:中国开源云联盟、中国电子技术标准化研究院

协办单位:华为、中标软件、X·SKY、数人云、九州云、去哪儿网

会议时间:2017年7月26日

会议地点:北京万寿宾馆

1111.png


(注:议程以当天发布为准)



关于数人云


数人云成立于2014年,创始团队来自谷歌、红帽和惠普,作为领先的云计算开源技术实践者,数人云致力于帮助传统企业提升IT对业务的支撑能力,帮助客户统一管理资源和应用,加速应用交付、提升运维效率,建设新一代基于云计算技术的IT架构体系。


数人云重点聚焦打造基于容器的最轻量级PaaS平台,在实现应用全生命周期管理的同时,管理海量监控、日志等产生的各类数据,自动分配应用资源、对业务运行状况进行自动分析,提升企业的IT工业化程度,构建灵动新IT。


2016年数人云加入中国开源云联盟,2017年成为Linux基金会成员,并加入OCI(The Open Container Initiative)联盟,携手与国内外云计算伙伴共同推动云计算领域容器等开源技术的落地与发展。


关于中国开源云联盟

中国开源云联盟(简称“COSCL”)由Intel、新浪网、中标软件和上海交大于2012年8月共同发起创立,是中国最早专注于OpenStack的专业联盟,一直致力于在中国推动OpenStack技术开发、操作系统支持、性能优化、规模部署等工作。


2016年,在工业和信息化部信息化和软件服务业司的指导下,中国开源云联盟正式挂靠中国电子技术标准化研究院,推进联盟后续工作。中国电子技术标准化研究院作为工信部直属的电子信息领域标准化研究机构,一直致力于联合产业界推动开源软件技术和开源标准化工作的发展,探索开源标准与国家标准、国际标准的有机结合,并努力推动开源标准化工作思路和模式的创新。

五个小技巧,快速创建Docker镜像

宁静胡同 发表了文章 • 0 个评论 • 697 次浏览 • 2017-01-06 14:51 • 来自相关话题

毫无疑问,容器是DevOps世界一个突破性的技术。镜像创建对于部署和发布环节都非常重要。那么如何效率地创建和使用镜像来提升部署速度呢?以下是作者的经验和分享,大家不妨一试——


1. 尽可能多地缓存网络下载

通常部署需要从Internet下载成百上千MB的数据。因此部署常受到网速慢或者断网的困扰。

而缓存得越多,部署得就会越快。最终的目标是实现Docker镜像离线一键部署。


2. 把Docker镜像看做Plain OS Golden Image

Docker很强力,但是我们也有很多VM或者裸机部署。为了避免供应商锁定,通常需要选择是否用Docker支持部署,最好两种场景都实施部署持续集成。

举例来说,如果使用kitchen来做持续集成。默认情况下,使用自定义Docker镜像来测试。当IMAGE_NAME指定为ubuntu:14.04时,可以很肯定ubuntu:14.04系统对于部署非常适用。


3. 审核Docker镜像里所有包和服务的安装

从镜像起一个Docker容器,然后列出并检查所有安装的包/服务。

为什么要这么做?首先我们希望Docker镜像尽可能地小,镜像交付就会很快速。其次,包/服务越多,问题也会越多,例如包冲突,TCP端口占有问题。一些服务的安装后脚本甚至会改变关键性的全局配置文件或者留下不可预期的flagfile。所以最好让Docker镜像保持傻傻的单纯。


4. Docker构建的最后清理关闭所有服务

如果不这么做,服务会在Docker镜像的最后阶段被杀掉。在/var/lock/*下的服务的lockfile如果没有被正确使用,当测试新建镜像的部署时,服务可能会启动失败,导致测试无效。


5. 添加验证步骤,确保镜像正常

当有改变发生时,我们时不时需要重构Docker镜像。为了确保一切正常,我们可以在Docker构建过程中添加自动验证逻辑。


这是一个简单的例子,实践了上述提到的技巧。
########## How To Use Docker Image ###############
## docker run -t -d --privileged -p 8022:22 \
## denny/mydockertest:v1 /usr/sbin/sshd -D
##
##################################################

FROM denny/sshd:v1
MAINTAINER Deny <denny@dennyzhang.com>
ARG devops_branch=master
ARG working_dir=/root/chef
##################################################
# Install basic packages
RUN apt-get -yqq update && \
apt-get -yqq install curl && \
apt-get -yqq install openssh-server && \
apt-get install -y sudo lsb-release && \
# Install chef
curl -L https://www.opscode.com/chef/install.sh | bash && \
# clean up files to make this docker layer smaller
rm -rf /var/chef/cache/*.plugin && \
rm -rf /usr/share/doc && \
apt-get clean && apt-get autoclean
##################################################
# checkout code
RUN bash /root/git_update.sh ${working_dir} \
git@github.com:DennyZhang/chef_community_cookbooks.git \
${devops_branch} && \
echo "cookbook_path [\"${working_dir}/${devops_branch}/mdmdevops/community_cookbooks\", \
\"${working_dir}/${devops_branch}/mdmdevops/cookbooks\"]" \
> /root/client.rb

# Chef all-in-one deployment. This step takes minutes
RUN echo "{\"run_list\": [\"recipe[all-in-one::predownload]\"]}" \
> /root/client.json && \
chef-solo --config /root/client.rb -j /root/client.json && \
# Clean up to make docker image smaller
rm -rf /tmp/* /var/tmp/* && \
rm -rf /var/chef/cache/jdk-*.tar.gz && \
rm -rf /var/chef/cache/*.plugin && \
rm -rf /usr/share/doc && \
apt-get clean && apt-get autoclean
##################################################

# Shutdown services
RUN service couchbase-server stop || true && \
service elasticsearch stop || true && \
service nagios3 stop || true && \
service apache2 stop || true && \
service haproxy stop || true && \
service nagios-nrpe-server stop || true && \
rm -rf /run/apache2/apache2.pid && \
rm -rf /var/log/apache2/* && \
rm -rf /usr/local/var/run/vagrant_ubuntu_trusty_64.pid && \
rm -rf /root/docker.rb /root/docker.json

# Verify docker image
RUN test -f /var/chef/cache/couchbase-server-enterprise_4.1.0-ubuntu14.04_amd64.deb && \
test -f /var/chef/cache/elasticsearch-2.3.3.deb && \
test -f /etc/apt/sources.list.d/ruby2.1-repo.list && \
test -f /etc/apt/sources.list.d/haproxy-repo.list && \
dpkg -s haproxy | grep "1.6.5"

# Clean up to make docker image smaller
RUN rm -rf /tmp/* /var/tmp/* /var/chef/cache/jdk-*.tar.gz && \
rm -rf /var/chef/cache/*.plugin && \
rm -rf /usr/share/doc && \
apt-get clean && apt-get autoclean

EXPOSE 22
CMD ["/usr/sbin/sshd", "-D"]
##################################################



作者:Denny Zhang
文章来源:https://dennyzhang.github.io/d ... .html 查看全部

毫无疑问,容器是DevOps世界一个突破性的技术。镜像创建对于部署和发布环节都非常重要。那么如何效率地创建和使用镜像来提升部署速度呢?以下是作者的经验和分享,大家不妨一试——




1. 尽可能多地缓存网络下载

通常部署需要从Internet下载成百上千MB的数据。因此部署常受到网速慢或者断网的困扰。

而缓存得越多,部署得就会越快。最终的目标是实现Docker镜像离线一键部署。


2. 把Docker镜像看做Plain OS Golden Image

Docker很强力,但是我们也有很多VM或者裸机部署。为了避免供应商锁定,通常需要选择是否用Docker支持部署,最好两种场景都实施部署持续集成。

举例来说,如果使用kitchen来做持续集成。默认情况下,使用自定义Docker镜像来测试。当IMAGE_NAME指定为ubuntu:14.04时,可以很肯定ubuntu:14.04系统对于部署非常适用。


3. 审核Docker镜像里所有包和服务的安装

从镜像起一个Docker容器,然后列出并检查所有安装的包/服务。

为什么要这么做?首先我们希望Docker镜像尽可能地小,镜像交付就会很快速。其次,包/服务越多,问题也会越多,例如包冲突,TCP端口占有问题。一些服务的安装后脚本甚至会改变关键性的全局配置文件或者留下不可预期的flagfile。所以最好让Docker镜像保持傻傻的单纯。


4. Docker构建的最后清理关闭所有服务

如果不这么做,服务会在Docker镜像的最后阶段被杀掉。在/var/lock/*下的服务的lockfile如果没有被正确使用,当测试新建镜像的部署时,服务可能会启动失败,导致测试无效。


5. 添加验证步骤,确保镜像正常

当有改变发生时,我们时不时需要重构Docker镜像。为了确保一切正常,我们可以在Docker构建过程中添加自动验证逻辑。


这是一个简单的例子,实践了上述提到的技巧。
########## How To Use Docker Image ###############
## docker run -t -d --privileged -p 8022:22 \
## denny/mydockertest:v1 /usr/sbin/sshd -D
##
##################################################

FROM denny/sshd:v1
MAINTAINER Deny <denny@dennyzhang.com>
ARG devops_branch=master
ARG working_dir=/root/chef
##################################################
# Install basic packages
RUN apt-get -yqq update && \
apt-get -yqq install curl && \
apt-get -yqq install openssh-server && \
apt-get install -y sudo lsb-release && \
# Install chef
curl -L https://www.opscode.com/chef/install.sh | bash && \
# clean up files to make this docker layer smaller
rm -rf /var/chef/cache/*.plugin && \
rm -rf /usr/share/doc && \
apt-get clean && apt-get autoclean
##################################################
# checkout code
RUN bash /root/git_update.sh ${working_dir} \
git@github.com:DennyZhang/chef_community_cookbooks.git \
${devops_branch} && \
echo "cookbook_path [\"${working_dir}/${devops_branch}/mdmdevops/community_cookbooks\", \
\"${working_dir}/${devops_branch}/mdmdevops/cookbooks\"]" \
> /root/client.rb

# Chef all-in-one deployment. This step takes minutes
RUN echo "{\"run_list\": [\"recipe[all-in-one::predownload]\"]}" \
> /root/client.json && \
chef-solo --config /root/client.rb -j /root/client.json && \
# Clean up to make docker image smaller
rm -rf /tmp/* /var/tmp/* && \
rm -rf /var/chef/cache/jdk-*.tar.gz && \
rm -rf /var/chef/cache/*.plugin && \
rm -rf /usr/share/doc && \
apt-get clean && apt-get autoclean
##################################################

# Shutdown services
RUN service couchbase-server stop || true && \
service elasticsearch stop || true && \
service nagios3 stop || true && \
service apache2 stop || true && \
service haproxy stop || true && \
service nagios-nrpe-server stop || true && \
rm -rf /run/apache2/apache2.pid && \
rm -rf /var/log/apache2/* && \
rm -rf /usr/local/var/run/vagrant_ubuntu_trusty_64.pid && \
rm -rf /root/docker.rb /root/docker.json

# Verify docker image
RUN test -f /var/chef/cache/couchbase-server-enterprise_4.1.0-ubuntu14.04_amd64.deb && \
test -f /var/chef/cache/elasticsearch-2.3.3.deb && \
test -f /etc/apt/sources.list.d/ruby2.1-repo.list && \
test -f /etc/apt/sources.list.d/haproxy-repo.list && \
dpkg -s haproxy | grep "1.6.5"

# Clean up to make docker image smaller
RUN rm -rf /tmp/* /var/tmp/* /var/chef/cache/jdk-*.tar.gz && \
rm -rf /var/chef/cache/*.plugin && \
rm -rf /usr/share/doc && \
apt-get clean && apt-get autoclean

EXPOSE 22
CMD ["/usr/sbin/sshd", "-D"]
##################################################



作者:Denny Zhang
文章来源:https://dennyzhang.github.io/d ... .html

DevOps 新年计划清单:对失败的准备 say no

宁静胡同 发表了文章 • 0 个评论 • 523 次浏览 • 2016-12-28 19:30 • 来自相关话题

随着2016年接近尾声,又到了为明年做准备的时候啦。今天的文章里邀请了国外三位嘉宾Andrew Phillips, Tim Buntel,和 TJ Randall,看看业界的思想者们对于DevOps世界新一年有哪些展望,为大家提供一些参考。

1.新浪潮——“下一代平台”将要来临

在2017年,将会有一种聚焦于容器编排框架的“下一代平台”项目,以及将工具重组的PaaS平台,例如OpenShift 或者 Cloud Foundry。对于跨机资源管理和调度框架的需求会持续增长,生态链上的供应商会甩掉身上的重负、快速地跟随上这个趋势。同时在容器标准化上会有一个更清晰的认识,容器自动化也会成为一种必需。

2.应用新定义将成为约定俗成的标准

未来将不再定义应用为“虚拟化设备概念”,就此开启从“为每个应用版本制作亚马逊机器镜像”到软件交付的新阶段。

3.迎刃而上的企业需求

随着下一代平台的实现以及容器自动化,在企业需求上面将会有更多关注点,比如接口控制,审计跟踪和网络技术,在编排层实现“虚拟防火墙”。我们也会看到一波波的案例,充分感受到“它们比看起来的要困难得多”。

4.数据科学/大数据遍地开花

数据科学/大数据项目数量会有一个提升,围绕着测试、持续集成和持续交付将会有各自不同的挑战。更多的商业关注会提高大家对于集群管理工具的接受度,因为多数大数据框架都是运行在它们之上的。

5.软件开发强调分析与监测

自动化进程会产生大量的数据,而自动操作的软件发布越来越多。管理发布的关键信息量十分庞大,散布在一堆工具里。团队需要简化数据来做商业报告,为了更深入地进行使用操作、工作情况的调查,要明确和强调其中不寻常的数据。

6.Serverless Architecture,不再纸上谈兵

PaaS我们已经听了很多年,在这一层之下,Serverless Architecture可以让代码运行而不需要提供或者管理服务器。不再需要提供服务器,也不需要应用一直运行,Serverless Architecture还提供了完全自动化的的水平扩展能力。它们并不是很新的东西(比如AWS Lambda 2014年就出来了),明年有望实现更广泛的使用,而不再只是会议上的一个话题了。

7.企业的应用迁移之路

在古董、过渡和现代应用栈之间的巨大鸿沟,让企业在人员招聘、员工分配和预算上都承受了巨大的压力。新平台面向用户的解决方案有越来越多的成功案例——比如云计算和容器方面——会让公司在新架构应用迁移上投入更多。

8.敏捷驱动和瀑布式交付模式的完美结合

Pipeline和发布编排会成为应用交付进程中非开发人员最时髦的流行词,这些方法会在交付过程中提供企业需要的一致性,以及IT团队需要更快交付解决方案的灵活性。

Benjamin Franklin 曾经说过, “By failingto prepare, you are preparing to fail” 。 
2017 将会成为行业内有巨大变革的一年—— 
你,准备好了吗?

作者:Divesh Rupani 文章来源:https://blog.xebialabs.com/201 ... 2017/ 查看全部
随着2016年接近尾声,又到了为明年做准备的时候啦。今天的文章里邀请了国外三位嘉宾Andrew Phillips, Tim Buntel,和 TJ Randall,看看业界的思想者们对于DevOps世界新一年有哪些展望,为大家提供一些参考。

1.新浪潮——“下一代平台”将要来临

在2017年,将会有一种聚焦于容器编排框架的“下一代平台”项目,以及将工具重组的PaaS平台,例如OpenShift 或者 Cloud Foundry。对于跨机资源管理和调度框架的需求会持续增长,生态链上的供应商会甩掉身上的重负、快速地跟随上这个趋势。同时在容器标准化上会有一个更清晰的认识,容器自动化也会成为一种必需。

2.应用新定义将成为约定俗成的标准

未来将不再定义应用为“虚拟化设备概念”,就此开启从“为每个应用版本制作亚马逊机器镜像”到软件交付的新阶段。

3.迎刃而上的企业需求

随着下一代平台的实现以及容器自动化,在企业需求上面将会有更多关注点,比如接口控制,审计跟踪和网络技术,在编排层实现“虚拟防火墙”。我们也会看到一波波的案例,充分感受到“它们比看起来的要困难得多”。

4.数据科学/大数据遍地开花

数据科学/大数据项目数量会有一个提升,围绕着测试、持续集成和持续交付将会有各自不同的挑战。更多的商业关注会提高大家对于集群管理工具的接受度,因为多数大数据框架都是运行在它们之上的。

5.软件开发强调分析与监测

自动化进程会产生大量的数据,而自动操作的软件发布越来越多。管理发布的关键信息量十分庞大,散布在一堆工具里。团队需要简化数据来做商业报告,为了更深入地进行使用操作、工作情况的调查,要明确和强调其中不寻常的数据。

6.Serverless Architecture,不再纸上谈兵

PaaS我们已经听了很多年,在这一层之下,Serverless Architecture可以让代码运行而不需要提供或者管理服务器。不再需要提供服务器,也不需要应用一直运行,Serverless Architecture还提供了完全自动化的的水平扩展能力。它们并不是很新的东西(比如AWS Lambda 2014年就出来了),明年有望实现更广泛的使用,而不再只是会议上的一个话题了。

7.企业的应用迁移之路

在古董、过渡和现代应用栈之间的巨大鸿沟,让企业在人员招聘、员工分配和预算上都承受了巨大的压力。新平台面向用户的解决方案有越来越多的成功案例——比如云计算和容器方面——会让公司在新架构应用迁移上投入更多。

8.敏捷驱动和瀑布式交付模式的完美结合

Pipeline和发布编排会成为应用交付进程中非开发人员最时髦的流行词,这些方法会在交付过程中提供企业需要的一致性,以及IT团队需要更快交付解决方案的灵活性。

Benjamin Franklin 曾经说过, “By failingto prepare, you are preparing to fail” 。 
2017 将会成为行业内有巨大变革的一年—— 
你,准备好了吗?

作者:Divesh Rupani 文章来源:https://blog.xebialabs.com/201 ... 2017/
数人云使用技巧交流,问题反馈,最佳实践分享