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
备注公司、姓名、职位
小数将拉您进入相应技术群
 
点击数人云了解更多信息

最佳实践 | 7大维度看国外企业为啥选择gRPC打造高性能微服务?

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

 gRPC作为Google开源的,一个高性能、通用的RPC框架,面向移动和HTTP/2设计,跨语言,跨平台,gRPC支持多种平台和多种语言。gRPC在企业环境中落地已屡见不鲜,小数今天带来一篇有关gRPC国外最佳实践的文章。


Bugsnag(注:一家云端bug监控服务商)每天处理数以亿计的错误信息,为了处理这些数据,考虑优先构建一个可扩展,性能强大的后端系统,并从中学到很多有挑战性的技术。最近,我们推出了新版本的仪表板,这个项目要求扩展系统,来处理服务呼叫的显著增加,这些呼叫是跟踪用户发布和会话所需的。


仪表板的发布在进行中,工程团队将Bugsnag的后端功能分解成称之为管道(pipeline)的微服务体系。将管道扩展到支持发布,意味着增加新的服务,并修改现有服务,也可预见到许多新的服务器和客户端的交互。为了处理上述架构的变化,需要采用一致性的方式来设计,实施和集成企业的服务。Bugsnag是一家多语言的公司,服务是用Java,Ruby,Go和Node.js等多语言编写,因此企业需要一种与平台无关的方法。


本文将介绍为什么我们最终选择了gRPC作为Pipeline的默认通信框架。
 
 
达到REST API设计的极限

现有系统传统上使用具有JSON有效载荷的REST API进行同步通信。这种选择是基于占压倒性比例的成熟度、熟悉度和工具的可用性做出的,但是随着跨洲际工程团队的增长,企业需要设计一致的,基于RESTful API的工具。


不幸的是,这感觉就像试图将简单的方法调用变成一个数据驱动的RESTful界面。这满足了RESTful接口的verb,header,URL标识符,资源的URL和有效载荷的神奇组合,并做了一个清洁,简单,看起来几乎不可能实现的功能界面。RESTful有很多规则和解释,在大多数情况下会导致REST ish接口,这需要花费额外的时间和精力来保持其纯度。


最终,考虑到RESTAPI的复杂性,我们找到了替代方案。希望微服务尽可能相互隔离,减少交互和解耦服务。它可以让企业在很短的时间内创造出一个可行的服务,并防止跳过hoops。


评估REST的替代方案


不要轻易选择通信框架。大型组织(如Netflix)可以拥有超过500+个微服务的后端系统。迁移这些服务以取代不充分的服务间通信会花费大量时间,从后勤和财务角度看这很不切实际。花时间从一开始就考虑正确的框架,可以省去很多未来的浪费。

我们花了大量的时间来制定评估标准和研究、选择。Bugsnag到底长什么样子呢?


技术标准

在研究可用选项时,使用了一些特定的标准来评估。要考虑的事情是基于微服务架构的最有效的方法。主要目标是自由地使用通信,消除通信的复杂性,了解每项服务的责任所在。
 
其中的一些技术问题是:
 
速度 - 对于大量的请求/响应API调用,需要将调用本身的延迟作为性能和用户响应速度的最小因素。延迟的主要组成部分是连接成本,传输成本和消息编码/解码时间。
 
基础架构兼容性 - 框架在基础架构中扮演的角色如何?主要是关于负载平衡和自动扩展?我们使用托管在Google云端平台上的Kubernetes服务,因此需要框架来兼容这种环境。
 
开发工具 - 在实现框架时,提供尽可能小的摩擦将会使开发人员更快捷。哪些工具可以帮助编码,本地测试端点,以及单元和集成测试的stubbing/mocking?当事情出错时,我们需要能够看到包括内容在内的请求信息。消息格式等因素也可以使调试更容易依赖于工具,例如JSON消息是人可读的,但是二进制消息将需要额外的努力来解码。
 
成熟度和采用 - 对于初创公司来说,资源是有限的,需要花费在公司的核心业务上,而不是修复,测试和增强第三方框架。诸如框架的普及,大规模使用的例子,社区的活跃程度以及框架本身的成熟度等因素都是稳定性的良好指标。需要强调的是,选择一个解决具体问题的框架,而并非选择最新最热的。
 
多平台支持 - 在真正的微服务思维中,使用最适合其目的的语言编写企业的服务,目前包括Java,Ruby,Go和Node。框架是否为现有的语言选择提供了一流的支持,同时提供了用其他语言编写新服务的选项?
 
代码量 - 框架应该有助于降低工程成本。企业需要编写和维护多少代码才能使其工作?与业务逻辑相比,这是多少样板代码?
 
 
安全 - 所有的内部通信都应该被认证和加密。我们需要能够使用所有通信的SSL / TLS(或等价物)。设计上的考虑,并非都与技术有关


服务API是最重要的接口之一,因为在开发过程中对设置服务期望至关重要。解决服务API的设计是一项艰巨的任务,当不同的团队负责所涉及的不同服务时,该任务会被放大。最大限度地减少由于预期不匹配而浪费的时间和精力,与缩短编码时间一样有价值。由于Bugsnag拥有跨地区的工程团队,因此沟通时间有限。必须通过简化沟通,确保事情不用那么多解释,否则错误很容易产生,事情很容易被拖延。


以下是在选择框架时的一些设计考虑因素:
 
强类型 - 消息是否是强类型的?如果通过服务边界发送的消息清晰可见,那么可以消除由于类型而造成的设计和运行时错误。
 
打开解释 - 能够直接从服务API规范生成客户端库,减少了误解的问题。
 
错误条件 - 有一套明确定义的错误代码可以更容易一致地交流问题。
 
文档 - 服务API应该是易读易懂的。定义服务API的格式应该尽可能清楚,准确地描述端点。
 
版本控制 - 更改是不可避免的,这是一个很好的选择,在某些时候,服务API将需要修改。所使用的消息传递格式和服务定义可以影响修改API并将其部署到生产的容易程度。是否有明确的路径来增加版本及其相应的库,并推出更改?
 
 
微服务最佳实践,为什么可扩展性是重要的


除了上面列出的标准外,还需要选择一个易于扩展的框架。随着微服务的发展,企业需要越来越多的“开箱即用”功能,发展的同时,为系统增加了更多的复杂性。
 
因此企业希望的功能包括:
 
异常处理 - 在请求级别提供一个处理异常的机制。它允许捕获有关请求的重要上下文元数据,例如发出请求的用户,可以用例外报告。我们使用Bugsnag轻松地监视这些异常。
 
智能重试 - 在特定条件下重试请求,例如仅在5xx状态码上。这包括支持各种退避策略,如指数退避。
 
服务发现配置 - 将通信框架连接到流行的服务发现应用程序(如Zookeeper,Eureka或Consul)的选项可以提供一种快速简便的解决方案,以绕过企业的架构来请求路由。
 
度量、跟踪和日志记录 - 可观察性对于复杂的分布式系统是必不可少的,但是应该小心监视的内容。在服务边界自动收集指标和跟踪信息可以快速回答常见问题,例如“我的服务对请求响应缓慢吗?”以及“请求失败的频率如何?”。
 
熔断 - 这种模式可以通过自动检测问题和快速失败来防止级联服务故障。也可以由长时间缓慢的请求来触发,以提供响应降级的服务而不是不断地超时。
 
 
缓存和批处理 - 通过使用缓存或批处理请求来加速请求。


大多数框架不会提供所有功能,但至少它们应该是可扩展的,以便在需要时添加。
 
什么是gRPC和协议缓冲区?

没有一个框架是万能的。我们探索的一些选项包括Facebook的Thrift,Apache Hadoop的Avro,Twitter的Finagle,甚至使用JSON模式。

我们的需求更接近于远程程序调用(RPC),给予所需要的细粒度控制。使用RPC的另一个吸引力是使用接口描述语言或IDL。IDL允许以独立于语言的格式描述服务API,将接口与任何特定的编程语言分离。他们可以提供一系列的好处,包括服务API的一个单一的事实来源,并可能被用来生成客户端和服务器代码来与这些服务进行交互。IDL的例子包括Thrift,Avro,CORBA,当然还有ProtocolBuffers。

最后,明确的获胜者是基于协议缓冲区的gRPC。
 
 
什么是gRPC?
 
我们选择了gRPC,因为它满足了我们的功能需求(包括未来的可扩展性),背后的活跃社区以及HTTP / 2框架的使用。

gRPC是由Google开发,设计用于传统的RPC调用。该框架使用最新的网络传输协议HTTP / 2,主要用于通过使用流的单个TCP连接来实现低延迟和多路复用请求。与REST over HTTP / 1.1相比,gRPC非常快速和灵活。

gRPC的性能对于设置管道来处理仪表板发布的大量增加至关重要。此外,HTTP / 2是下一个标准化的网络协议,可以利用为HTTP / 2开发的工具和技术(如Envoy代理),并为gRPC提供一流的支持。由于多路复用流支持,gRPC支持双向通信,不限于简单的请求/响应呼叫。

什么是Protobufs(协议缓冲区)?Protocol Buffers或protobufs是定义和序列化结构化数据为高效的二进制格式的一种方式,也是由Google开发的。二者的有效结合,也是我们选择gRPC的主要原因之一。

以前有许多与想修复的版本相关的问题。微服务意味着必须不断更新,需要适应并保持向前和向后兼容的接口,protobufs对此非常有用。由于是二进制格式,所以它们也是通过wire快速发送的小型有效载荷。

Protobuf消息使用关联的IDL进行描述,它提供了一个紧凑的,强类型的,向后兼容的格式来定义消息和RPC服务。我们使用最新的proto3规范,并在此处显示protobuf消息的实际示例。

所有字段proto3都是可选的。如果未设置字段,将始终使用默认值。这与字段编号相结合提供了一个API,可以非常抵抗打破变化。通过遵循一些简单的规则,向前和向后兼容性可以成为大多数API更改的默认值。

protobuf格式还允许定义RPC服务本身。服务端点与消息结构共存,在单个protobuf文件中提供RPC服务的自包含定义。对于我们的跨洲际的工程团队来说,这非常有用,他们可以从一个文件中了解服务如何工作,生成客户端并开始使用它。以下是我们的服务之一:

该框架能够生成代码来使用protobuf文件与这些服务进行交互,这是另一个优势,它可以自动生成需要的所有类。这个生成的代码负责消息建模,并提供一个存根类,其中包含与您的服务端点相关的重复方法调用。

支持多种语言,包括C ++,Java,Python,Go,Ruby,C#,Node,Android,Objective-C和PHP。但是,使用protobuf文件维护和同步生成的代码是个问题。我们已经能够通过使用Protobuf文件自动生成客户端库来解决这个问题,会在即将发布的下一篇博客文章中分享更多的内容。


gRPC最好的特性之一是支持中间件模式,被称为拦截器。它允许扩展所有的gRPC实现(这对企业来说很重要),能够轻松访问所有请求,从而实现自己的微服务最佳实践。gRPC还内置了对一系列认证机制的支持,包括SSL / TLS。gRPC社区我们正处于gRPC采用的开始阶段,期待社区提供更多的工具和技术。很高兴能够加入这个充满活力的社区,并对未来的项目有一些想法,我们希望看到这些项目是开放源代码或我们自己写的。gRPC工具的当前状态


gRPC比较新,缺乏可用的开发工具,特别是与经验丰富的REST over HTTP / 1.1协议相比。搜索教程和示例时,这一点尤其明显,因为只有少数有用的信息。二进制格式也使消息不透明,需要努力解码。虽然有一些选择,例如JSON代码转换器可以帮助,但预计需要做一些基础工作,以便为gRPC提供顺畅的开发体验。我们喜欢用Apiary 来记录外部API。使用服务协议缓冲区(protobuf)文件自动生成交互式文档的等价物,将是理想的有效的内部通信gRPCAPI。

protobuf文件的静态分析在运行时能捕获更多的bug。使用Checkstyle作为Java代码,并且把它用作类似于protobuf的文件。

自定义拦截器可以提供跟踪,日志记录和错误监视功能。我们希望开源我们的Bugsnag gRPC拦截器,以自动捕获并向Bugsnag报告错误。gRPC的增长和采用在过去几年中,gRPC的普及度大幅增长,Square,Lyft,Netflix,Docker,Cisco和CoreOS等公司大规模采用。Netflix Ribbon是基于RPC调用使用REST的微服务通信框架的事实标准。今年,他们宣布,由于其多语言支持和更好的可扩展性/可组合性,他们正在向gRPC过渡。该框架最近也于2017年3月加入了CNCF基金会,支持重量级的Kubernetes和Prometheus。gRPC社区非常活跃,与开源gRPC生态系统 列出了许多gRPC激动人心的项目。
 
 
另外,gRPC有我们认同的原则
 
Lyft在转向gRPC方面做了大量的讨论,这与我们的经验非常相似:使用Protocol Buffers和gRPC生成统一的API。值得一试。

gRPC现在还处于初期阶段,存在一些明显的磨合问题,但未来前景光明。总的来说,我们对gRPC如何整合到后端系统非常乐观,并且很高兴见证这个框架的发展。



原文链接:

https://blog.bugsnag.com/grpc- ... erral





  查看全部

v2-132a2ab6614fbc037bbb063a944e72ec_hd.jpg

 gRPC作为Google开源的,一个高性能、通用的RPC框架,面向移动和HTTP/2设计,跨语言,跨平台,gRPC支持多种平台和多种语言。gRPC在企业环境中落地已屡见不鲜,小数今天带来一篇有关gRPC国外最佳实践的文章。


Bugsnag(注:一家云端bug监控服务商)每天处理数以亿计的错误信息,为了处理这些数据,考虑优先构建一个可扩展,性能强大的后端系统,并从中学到很多有挑战性的技术。最近,我们推出了新版本的仪表板,这个项目要求扩展系统,来处理服务呼叫的显著增加,这些呼叫是跟踪用户发布和会话所需的。


仪表板的发布在进行中,工程团队将Bugsnag的后端功能分解成称之为管道(pipeline)的微服务体系。将管道扩展到支持发布,意味着增加新的服务,并修改现有服务,也可预见到许多新的服务器和客户端的交互。为了处理上述架构的变化,需要采用一致性的方式来设计,实施和集成企业的服务。Bugsnag是一家多语言的公司,服务是用Java,Ruby,Go和Node.js等多语言编写,因此企业需要一种与平台无关的方法。


本文将介绍为什么我们最终选择了gRPC作为Pipeline的默认通信框架。
 
 
达到REST API设计的极限

现有系统传统上使用具有JSON有效载荷的REST API进行同步通信。这种选择是基于占压倒性比例的成熟度、熟悉度和工具的可用性做出的,但是随着跨洲际工程团队的增长,企业需要设计一致的,基于RESTful API的工具。


不幸的是,这感觉就像试图将简单的方法调用变成一个数据驱动的RESTful界面。这满足了RESTful接口的verb,header,URL标识符,资源的URL和有效载荷的神奇组合,并做了一个清洁,简单,看起来几乎不可能实现的功能界面。RESTful有很多规则和解释,在大多数情况下会导致REST ish接口,这需要花费额外的时间和精力来保持其纯度。


最终,考虑到RESTAPI的复杂性,我们找到了替代方案。希望微服务尽可能相互隔离,减少交互和解耦服务。它可以让企业在很短的时间内创造出一个可行的服务,并防止跳过hoops。


评估REST的替代方案


不要轻易选择通信框架。大型组织(如Netflix)可以拥有超过500+个微服务的后端系统。迁移这些服务以取代不充分的服务间通信会花费大量时间,从后勤和财务角度看这很不切实际。花时间从一开始就考虑正确的框架,可以省去很多未来的浪费。

我们花了大量的时间来制定评估标准和研究、选择。Bugsnag到底长什么样子呢?


技术标准

在研究可用选项时,使用了一些特定的标准来评估。要考虑的事情是基于微服务架构的最有效的方法。主要目标是自由地使用通信,消除通信的复杂性,了解每项服务的责任所在。
 
其中的一些技术问题是:
 
  • 速度 - 对于大量的请求/响应API调用,需要将调用本身的延迟作为性能和用户响应速度的最小因素。延迟的主要组成部分是连接成本,传输成本和消息编码/解码时间。

 
  • 基础架构兼容性 - 框架在基础架构中扮演的角色如何?主要是关于负载平衡和自动扩展?我们使用托管在Google云端平台上的Kubernetes服务,因此需要框架来兼容这种环境。

 
  • 开发工具 - 在实现框架时,提供尽可能小的摩擦将会使开发人员更快捷。哪些工具可以帮助编码,本地测试端点,以及单元和集成测试的stubbing/mocking?当事情出错时,我们需要能够看到包括内容在内的请求信息。消息格式等因素也可以使调试更容易依赖于工具,例如JSON消息是人可读的,但是二进制消息将需要额外的努力来解码。

 
  • 成熟度和采用 - 对于初创公司来说,资源是有限的,需要花费在公司的核心业务上,而不是修复,测试和增强第三方框架。诸如框架的普及,大规模使用的例子,社区的活跃程度以及框架本身的成熟度等因素都是稳定性的良好指标。需要强调的是,选择一个解决具体问题的框架,而并非选择最新最热的。

 
  • 多平台支持 - 在真正的微服务思维中,使用最适合其目的的语言编写企业的服务,目前包括Java,Ruby,Go和Node。框架是否为现有的语言选择提供了一流的支持,同时提供了用其他语言编写新服务的选项?

 
  • 代码量 - 框架应该有助于降低工程成本。企业需要编写和维护多少代码才能使其工作?与业务逻辑相比,这是多少样板代码?

 
 
  • 安全 - 所有的内部通信都应该被认证和加密。我们需要能够使用所有通信的SSL / TLS(或等价物)。设计上的考虑,并非都与技术有关



服务API是最重要的接口之一,因为在开发过程中对设置服务期望至关重要。解决服务API的设计是一项艰巨的任务,当不同的团队负责所涉及的不同服务时,该任务会被放大。最大限度地减少由于预期不匹配而浪费的时间和精力,与缩短编码时间一样有价值。由于Bugsnag拥有跨地区的工程团队,因此沟通时间有限。必须通过简化沟通,确保事情不用那么多解释,否则错误很容易产生,事情很容易被拖延。


以下是在选择框架时的一些设计考虑因素:
 
  • 强类型 - 消息是否是强类型的?如果通过服务边界发送的消息清晰可见,那么可以消除由于类型而造成的设计和运行时错误。

 
  • 打开解释 - 能够直接从服务API规范生成客户端库,减少了误解的问题。

 
  • 错误条件 - 有一套明确定义的错误代码可以更容易一致地交流问题。

 
  • 文档 - 服务API应该是易读易懂的。定义服务API的格式应该尽可能清楚,准确地描述端点。

 
  • 版本控制 - 更改是不可避免的,这是一个很好的选择,在某些时候,服务API将需要修改。所使用的消息传递格式和服务定义可以影响修改API并将其部署到生产的容易程度。是否有明确的路径来增加版本及其相应的库,并推出更改?

 
 
微服务最佳实践,为什么可扩展性是重要的


除了上面列出的标准外,还需要选择一个易于扩展的框架。随着微服务的发展,企业需要越来越多的“开箱即用”功能,发展的同时,为系统增加了更多的复杂性。
 
因此企业希望的功能包括:
 
  • 异常处理 - 在请求级别提供一个处理异常的机制。它允许捕获有关请求的重要上下文元数据,例如发出请求的用户,可以用例外报告。我们使用Bugsnag轻松地监视这些异常。

 
  • 智能重试 - 在特定条件下重试请求,例如仅在5xx状态码上。这包括支持各种退避策略,如指数退避。

 
  • 服务发现配置 - 将通信框架连接到流行的服务发现应用程序(如Zookeeper,Eureka或Consul)的选项可以提供一种快速简便的解决方案,以绕过企业的架构来请求路由。

 
  • 度量、跟踪和日志记录 - 可观察性对于复杂的分布式系统是必不可少的,但是应该小心监视的内容。在服务边界自动收集指标和跟踪信息可以快速回答常见问题,例如“我的服务对请求响应缓慢吗?”以及“请求失败的频率如何?”。

 
  • 熔断 - 这种模式可以通过自动检测问题和快速失败来防止级联服务故障。也可以由长时间缓慢的请求来触发,以提供响应降级的服务而不是不断地超时。

 
 
  • 缓存和批处理 - 通过使用缓存或批处理请求来加速请求。



大多数框架不会提供所有功能,但至少它们应该是可扩展的,以便在需要时添加。
 
什么是gRPC和协议缓冲区?

没有一个框架是万能的。我们探索的一些选项包括Facebook的Thrift,Apache Hadoop的Avro,Twitter的Finagle,甚至使用JSON模式。

我们的需求更接近于远程程序调用(RPC),给予所需要的细粒度控制。使用RPC的另一个吸引力是使用接口描述语言或IDL。IDL允许以独立于语言的格式描述服务API,将接口与任何特定的编程语言分离。他们可以提供一系列的好处,包括服务API的一个单一的事实来源,并可能被用来生成客户端和服务器代码来与这些服务进行交互。IDL的例子包括Thrift,Avro,CORBA,当然还有ProtocolBuffers。

最后,明确的获胜者是基于协议缓冲区的gRPC。
 
 
什么是gRPC?
 
我们选择了gRPC,因为它满足了我们的功能需求(包括未来的可扩展性),背后的活跃社区以及HTTP / 2框架的使用。

gRPC是由Google开发,设计用于传统的RPC调用。该框架使用最新的网络传输协议HTTP / 2,主要用于通过使用流的单个TCP连接来实现低延迟和多路复用请求。与REST over HTTP / 1.1相比,gRPC非常快速和灵活。

gRPC的性能对于设置管道来处理仪表板发布的大量增加至关重要。此外,HTTP / 2是下一个标准化的网络协议,可以利用为HTTP / 2开发的工具和技术(如Envoy代理),并为gRPC提供一流的支持。由于多路复用流支持,gRPC支持双向通信,不限于简单的请求/响应呼叫。

什么是Protobufs(协议缓冲区)?Protocol Buffers或protobufs是定义和序列化结构化数据为高效的二进制格式的一种方式,也是由Google开发的。二者的有效结合,也是我们选择gRPC的主要原因之一。

以前有许多与想修复的版本相关的问题。微服务意味着必须不断更新,需要适应并保持向前和向后兼容的接口,protobufs对此非常有用。由于是二进制格式,所以它们也是通过wire快速发送的小型有效载荷。

Protobuf消息使用关联的IDL进行描述,它提供了一个紧凑的,强类型的,向后兼容的格式来定义消息和RPC服务。我们使用最新的proto3规范,并在此处显示protobuf消息的实际示例。

所有字段proto3都是可选的。如果未设置字段,将始终使用默认值。这与字段编号相结合提供了一个API,可以非常抵抗打破变化。通过遵循一些简单的规则,向前和向后兼容性可以成为大多数API更改的默认值。

protobuf格式还允许定义RPC服务本身。服务端点与消息结构共存,在单个protobuf文件中提供RPC服务的自包含定义。对于我们的跨洲际的工程团队来说,这非常有用,他们可以从一个文件中了解服务如何工作,生成客户端并开始使用它。以下是我们的服务之一:

该框架能够生成代码来使用protobuf文件与这些服务进行交互,这是另一个优势,它可以自动生成需要的所有类。这个生成的代码负责消息建模,并提供一个存根类,其中包含与您的服务端点相关的重复方法调用。

支持多种语言,包括C ++,Java,Python,Go,Ruby,C#,Node,Android,Objective-C和PHP。但是,使用protobuf文件维护和同步生成的代码是个问题。我们已经能够通过使用Protobuf文件自动生成客户端库来解决这个问题,会在即将发布的下一篇博客文章中分享更多的内容。


gRPC最好的特性之一是支持中间件模式,被称为拦截器。它允许扩展所有的gRPC实现(这对企业来说很重要),能够轻松访问所有请求,从而实现自己的微服务最佳实践。gRPC还内置了对一系列认证机制的支持,包括SSL / TLS。gRPC社区我们正处于gRPC采用的开始阶段,期待社区提供更多的工具和技术。很高兴能够加入这个充满活力的社区,并对未来的项目有一些想法,我们希望看到这些项目是开放源代码或我们自己写的。gRPC工具的当前状态


gRPC比较新,缺乏可用的开发工具,特别是与经验丰富的REST over HTTP / 1.1协议相比。搜索教程和示例时,这一点尤其明显,因为只有少数有用的信息。二进制格式也使消息不透明,需要努力解码。虽然有一些选择,例如JSON代码转换器可以帮助,但预计需要做一些基础工作,以便为gRPC提供顺畅的开发体验。我们喜欢用Apiary 来记录外部API。使用服务协议缓冲区(protobuf)文件自动生成交互式文档的等价物,将是理想的有效的内部通信gRPCAPI。

protobuf文件的静态分析在运行时能捕获更多的bug。使用Checkstyle作为Java代码,并且把它用作类似于protobuf的文件。

自定义拦截器可以提供跟踪,日志记录和错误监视功能。我们希望开源我们的Bugsnag gRPC拦截器,以自动捕获并向Bugsnag报告错误。gRPC的增长和采用在过去几年中,gRPC的普及度大幅增长,Square,Lyft,Netflix,Docker,Cisco和CoreOS等公司大规模采用。Netflix Ribbon是基于RPC调用使用REST的微服务通信框架的事实标准。今年,他们宣布,由于其多语言支持和更好的可扩展性/可组合性,他们正在向gRPC过渡。该框架最近也于2017年3月加入了CNCF基金会,支持重量级的Kubernetes和Prometheus。gRPC社区非常活跃,与开源gRPC生态系统 列出了许多gRPC激动人心的项目。
 
 
另外,gRPC有我们认同的原则
 
Lyft在转向gRPC方面做了大量的讨论,这与我们的经验非常相似:使用Protocol Buffers和gRPC生成统一的API。值得一试。

gRPC现在还处于初期阶段,存在一些明显的磨合问题,但未来前景光明。总的来说,我们对gRPC如何整合到后端系统非常乐观,并且很高兴见证这个框架的发展。



原文链接:

https://blog.bugsnag.com/grpc- ... erral





 

PPT下载 | 亿级用户万台服务器背后,vivo云服务容器化如何破茧化蝶?

dataman 发表了文章 • 0 个评论 • 41 次浏览 • 2018-02-02 14:50 • 来自相关话题

2018年数人云Meetup第一站,联合vivo在深圳举办 Building Microservice 系列活动第一期。本次技术沙龙vivo、中兴通讯、华为、数人云共同派出技术大咖,为开发者们带来有关微服务、容器化、配置中心、服务网格等领域的实战与干货分享。

数人云Meetup每月一期,欢迎大家来面基、学习。本文为vivo云计算架构师袁乐林分享的“vivo云服务容器化实践”现场演讲实录。

今天讲的内容主要是介绍技术背景,产品的技术架构,我们关键技术的实践,前车之鉴,以及对下一代云服务架构的设想。

技术背景

vivo这些年的业务增长非常快,用户数已经上亿,服务器到了万级,业务域好几百,后端系统的复杂度在迅速攀升,不光是运维方面、架构体系复杂度也非常高,vivo技术架构也是到了破茧化蝶的时候。

我们做过容器、虚拟机与物理机性能对比测试。上面这张图是当时做的性能测试架构图。得出了一些测试结论:
1.容器化app(4c8g)在性能上略优于非容器化app测试指标
2.容器化app(32c64g)性能相较于裸跑同物理机有近4%左右性能损耗,其中TPS有3.85%损耗,平均响应时间3.95%(1毫秒)的增加,对业务请求无影响。
3.容器化app在12h的稳定性测试中表现正常
4.容器化app在cpu相对配额,cpu绑定以及绝对配额场景下,业务性能CPU相对配额 > CPU绑定 > 绝对配额。
5.容器化app在组部件异常,单计算节点,控制异常场景下,容器运行正常。
综上所述,容器化app性能上接近物理机,在多测试场景下,表现相对稳定可靠。同时,对计算密集型app,相对权重配额能实现CPU资源利用率最大化。

vivo容器化云服务框架

正是因为这个性能测试数据的支撑,就有了vivo容器化云服务框架,我们给它取名 Kiver,提供轻量级、高可靠的容器化生产方案。

在这个框架之上vivo一共有八个云服务,按照后来统计数据来看,MySQL加上其他两个服务占到80%的比例,这也非常符合“二八”原则。

vivo整个云服务容器化产品的架构,左边是运维自动化的工具集,比如日志、监控等,日志在业界应用非常广泛,我们用采集容器的数据、容器的监控指标。

这里有两个日志,上面是中间件的业务日志平台,所有业务基于中间件日志规范,输出日志后都会送到这里面收集起来,但是这个业务日志平台功能目前比较薄弱,对新增加的一些组件,比如ECTD等不支持。vivo又引入了现在容器领域比较常见的日志方案EFK,今后会规划把两个日志整合到一起。

vivo在运维方面做了一些工具,如 vivo MachineCtl和 KiverCtl,两个工具主要实现宿主机的自动化,简单来说可以把宿主机操作系统自动化地装起来,装完之后变成Kiver的计算节点或者控制节点。还有KiverPerfermance,是我们内嵌的一个小的性能测试插件。

再来看右边,是vivo的基础设施,物理机和交换机,网络设备和防火墙等,上面是Docker,Docker容器虚拟化技术把物理机上面的相关资源虚拟化用起来。

右边有 Ceph 块存储,实现数据备份,上面是vivo自研的DevOps平台,做了调度框架,右边是用harbor做的镜像仓库,再往上就是云服务Portal,前面所说的那些云服务,同时也可以跑长生命周期应用。
宿主机自动化实践

下面我们讲一下vivo的实践。现在物理机一旦上了规模之后,装操作系统就成为一件大事,我们提供了 vivoMachineCtl,这个工具是一个命令行给运维人员使用,可以实现宿主机集中化的参数配置和自动化。

利用 vivoMachineCtl,首先和物理机管理卡做一个交互,交互之后拿到物理机的MAC地址,这里有个BMC,也有厂商叫iDrac卡,它可以取得这台服务器网卡的MAC地址,创建以MAC地址命名的Bootfile,指明现在需要装什么操作系统,和其他一些参数。再进一步给它一个ipmi消息对服务器复位,然后服务器开始重启。

重启之后,服务器第一次会发dhcp请求,拿到IP地址,之后会走一个pxe的协议,拿到bootfile,下载Bootfile所指明的小系统和内存文件系统文件下来,加载到物理机中,然后开始进行操作系统安装。这就是操作系统安装的过程。操作系统安装完成之后,把安装类和文件系统切换成正在启动的文件系统,在post阶段到集中化的配置中心,把相关的配置拉下来,包括IP地址,主机名和网关等信息,这是宿主机的自动化部署。

KiverCtl实际上就是把操作系统的宿主机变成计算节点或者控制节点。计算节点有如下几个功能:第一,基本的包安装,第二,Docker、Netplugin初始化,启动kiver-guard/flume/cadvisor容器,完成日志和监控指标的采集。

控制节点上面有Etcd和Netmaster,也会可选地把Prometheus/alertmanager/grafana/启动起来。vivoMachineCtl和KiverCtl实现了云服务器节点从物理机到宿主机的转变。

业务日志集成到日志平台实践

这是vivo日志采集的实践,在宿主机上做日志分区,容器运行起来之后挂这个目录,每个容器起来之后会创建一个自己的文件目录。外面有kiver-guard,用来侦听内核文件系统的新日志文件创建的通知。

根据通知会创建软件链接,链接到上一级Flume监控的日志目录,由Flume推到kafka。大数据平台会来消费这里的数据,业务日志平台也会消费这个数据,然后持久化到ES里,最后由中间件日志平台来实现对日志的检索和展示。

为什么要这么做?当时用的flume版本不支持自动收集递归子目录下日志新增内容的收集,完整的文件可以收集进去,但是日志文件在递归子目录下有不停地追加是输不进去的。

kiver-guard本身也是一个容器,它起来之后把宿主机日志目录挂上去,在容器里面侦听日志目录下的create事件。

不管这些日志路径有多深或者在哪里,都可以链接出来。做链接的时候有一点需要注意,要确保链接过来之后文件名称是唯一的。有些容器被删除了,或者日志被轮转删除了,同样也会针对Delete事件,侦测到delete是件之后删除上层flume监控日志路径的对应链接。

基础组件日志收集实践

基础组件日志采用Etcd、Ceph、CentOS、Netmaster等一些网上比较热门的EFK组件,开箱即用。
监控与告警实践

这是监控和告警实践,在容器领域比较常见,vivo采用的是Promethus和Alertmanager。Promethus采用双节点,双拉(拉两遍),两个Promethus之间没有做主从,为了解决高可用问题,挂了一个另外一个还在。

之后接短信邮件中心,后面接Grafana作为监控面板,前面用了telegraf。我们做的东西不仅仅有容器,还有其他的组件像Ceph。我们用Cadvisor收集容器监控指标。

我们对集群健康做监控,也对集群资源使用情况进行监控,集群的健康性采用telegraf可以调用外部shell脚本的特性。我们在控制节点写了脚本,用来检查Etcd的健康情况,也和各个节点进行通讯,检查各个节点是不是健康。之后会返回数值,给出集群健康状态码。

这个就是前面讲的自定义的一些监控指标,这是集群的健康检查,这是集群的资源利用率,大致两条数据链进来。一个脚本由telegraf去拉,推到Prometheus里面,最后展现在Grafana上面。另一个,由DevOps框架把数据写到Mysql里面,再由Grafana定义Mysql的软件源。

这边拉出来的自定义的健康指标支持返回码,这个返回码需要翻译成文字,实际上Grafana已经具备这个特性,我们可以去做一个映射,比如1代表监控,2代表网络问题等等,它可以自动翻译来。
数据持久化实践

说到云服务大家都会关注这个问题,数据怎么做到持久化,做到不丢。容器启动的时候会挂在宿主机上面的一个数据目录,和日志类似,有容器的启动进程,直接写脚本也可以,创造二级目录。

用主机名,是在容器默认的主机名,就是它的默认ID号。如果这个ID已经存在就不用创建,说明容器是起用一个旧的容器,最后建立软链接到数据目录。这样确保每个容器日志数据都持久化到宿主机,还可以确保容器重启后数据不丢。

第二,数据本身有一个单独的备份系统,它会每天晚上凌晨2点跑一遍,把Mysql数据推到Ceph块存储当中,实现数据的可靠性。
集群可靠性实践

这是容器集群可靠性实践,最典型的是三个副本,副本能够实现数据和服务的可靠性。

失效重试,在集群各节点提供一个crontab定时任务,每隔一段时间探测一次docker服务进程健康状况,若不健康,则拉起Docker服务进程。同时我们开启了docker的Restartalways选项,确保容器服务异常退出后,能被重新拉起来。

关于隔离,首先是分区隔离,宿主机业务日志目录/app/log独立分区,避免日志量过大时侵占宿主机系统分区或者业务分区磁盘。

第二,资源隔离,flume当时是跑进程的,我们做的第一件事情是进行容器化,之后做配额,限制能使用的资源使用量,避免大日志传输时侵占宿主机过多资源。

第三,故障隔离,开启dockerlive-restore选项,保障docker服务进程不影响容器服务。
前车之辙

我们犯过一些错误,不负责物理机运营的童鞋可能感受不明显。如果磁盘引导分区被破坏,就可能导致操作系统被重装,这个问题是很严重的。原因也很简单,服务器一般有多引导的选项,比如磁盘、网络、CD,一般在顺序上磁盘第一,网络第二。

但如果磁盘引导分区坏了,服务器会认为没有操作系统,然后就从第二个上引导。这时候不幸的事情是,在你的网络环境里如果之前刚好装过操作系统,采用了第三方开源的部署服务器,而没有把之前的文件删掉,那么它就会把那些操作重新装上。

解决办法很简单,我们提供了定时任务,对两个小时前创建的引导文件,能看见它的创建时间、访问时间,并进行强制性删除。

第二个前车之辙,在收集Ceph日志时碰到困难,当时是用fluent-plugin-ceph插件来做。具体的情况是,第一,官方配置文档不正确,因为提交者没按官方文档格式编码,导致看到的配置是一行,拿回来根本不知道怎么办。第二,它和td-agent1.0 版本不兼容。摸索出的解决方法就是图片上显示的办法。

下一代云服务架构

这是我们下一代云服务架构,与上一代的主要区别在于,把编排框架换成了Kubernetes。目前AI这块已经用起来了,AI部分在线上大概有一百台物理机,跑Job任务,短任务每天可以跑到三万个,一次性可以调动3000个容器,未来会把这个些换成Kubnernetes,包括我们的AI、云服务都会跑在Kubernetes上。
XaaS on Kubernetes

如果把云服务跑到Kubernetes上,第一个要做的事情,可能会采用ceph块存储做后面的数据和数据持久化。目前vivo已经有了数据ceph块存储,但功能还不强大。第二,要解决pod漂移调度问题,如果不用ceph块存储,pod失效调度到其他节点上有问题,调过去没用的,没有数据。
第三,也是最常见的一个,固定POD IP,看到网上有人讨论这个事情,觉得容器坏了,没必要把容器固定起来,因为有违微服务的原则。这种观点不太对,有一些场景,比如在vivo的企业IT架构里面,很多东西都跟IP挂钩,比如安全策略,它不是跟域名挂钩,而是PODIP挂钩,交换机、防火墙等很多的配置都跟这个相关。所以vivo要干的很重要的事情,就是把POD IP固定。
目前业界对这块也有一些实践,比如京东最近有这方面的分享,把PODIP放在一个APP的IP 小池子里面,小池子里面还有IP的话,就从小池子里拿,没有的话就从大池子里去申请。

在微信公众号后台回复“127”,即可获取本次演讲PPT《vivo云服务容器化实践》。
点击数人云阅读更多技术干货 查看全部
2018年数人云Meetup第一站,联合vivo在深圳举办 Building Microservice 系列活动第一期。本次技术沙龙vivo、中兴通讯、华为、数人云共同派出技术大咖,为开发者们带来有关微服务、容器化、配置中心、服务网格等领域的实战与干货分享。

数人云Meetup每月一期,欢迎大家来面基、学习。本文为vivo云计算架构师袁乐林分享的“vivo云服务容器化实践”现场演讲实录。

今天讲的内容主要是介绍技术背景,产品的技术架构,我们关键技术的实践,前车之鉴,以及对下一代云服务架构的设想。

技术背景

vivo这些年的业务增长非常快,用户数已经上亿,服务器到了万级,业务域好几百,后端系统的复杂度在迅速攀升,不光是运维方面、架构体系复杂度也非常高,vivo技术架构也是到了破茧化蝶的时候。

我们做过容器、虚拟机与物理机性能对比测试。上面这张图是当时做的性能测试架构图。得出了一些测试结论:
1.容器化app(4c8g)在性能上略优于非容器化app测试指标
2.容器化app(32c64g)性能相较于裸跑同物理机有近4%左右性能损耗,其中TPS有3.85%损耗,平均响应时间3.95%(1毫秒)的增加,对业务请求无影响。
3.容器化app在12h的稳定性测试中表现正常
4.容器化app在cpu相对配额,cpu绑定以及绝对配额场景下,业务性能CPU相对配额 > CPU绑定 > 绝对配额。
5.容器化app在组部件异常,单计算节点,控制异常场景下,容器运行正常。
综上所述,容器化app性能上接近物理机,在多测试场景下,表现相对稳定可靠。同时,对计算密集型app,相对权重配额能实现CPU资源利用率最大化。

vivo容器化云服务框架

正是因为这个性能测试数据的支撑,就有了vivo容器化云服务框架,我们给它取名 Kiver,提供轻量级、高可靠的容器化生产方案。

在这个框架之上vivo一共有八个云服务,按照后来统计数据来看,MySQL加上其他两个服务占到80%的比例,这也非常符合“二八”原则。

vivo整个云服务容器化产品的架构,左边是运维自动化的工具集,比如日志、监控等,日志在业界应用非常广泛,我们用采集容器的数据、容器的监控指标。

这里有两个日志,上面是中间件的业务日志平台,所有业务基于中间件日志规范,输出日志后都会送到这里面收集起来,但是这个业务日志平台功能目前比较薄弱,对新增加的一些组件,比如ECTD等不支持。vivo又引入了现在容器领域比较常见的日志方案EFK,今后会规划把两个日志整合到一起。

vivo在运维方面做了一些工具,如 vivo MachineCtl和 KiverCtl,两个工具主要实现宿主机的自动化,简单来说可以把宿主机操作系统自动化地装起来,装完之后变成Kiver的计算节点或者控制节点。还有KiverPerfermance,是我们内嵌的一个小的性能测试插件。

再来看右边,是vivo的基础设施,物理机和交换机,网络设备和防火墙等,上面是Docker,Docker容器虚拟化技术把物理机上面的相关资源虚拟化用起来。

右边有 Ceph 块存储,实现数据备份,上面是vivo自研的DevOps平台,做了调度框架,右边是用harbor做的镜像仓库,再往上就是云服务Portal,前面所说的那些云服务,同时也可以跑长生命周期应用。
宿主机自动化实践

下面我们讲一下vivo的实践。现在物理机一旦上了规模之后,装操作系统就成为一件大事,我们提供了 vivoMachineCtl,这个工具是一个命令行给运维人员使用,可以实现宿主机集中化的参数配置和自动化。

利用 vivoMachineCtl,首先和物理机管理卡做一个交互,交互之后拿到物理机的MAC地址,这里有个BMC,也有厂商叫iDrac卡,它可以取得这台服务器网卡的MAC地址,创建以MAC地址命名的Bootfile,指明现在需要装什么操作系统,和其他一些参数。再进一步给它一个ipmi消息对服务器复位,然后服务器开始重启。

重启之后,服务器第一次会发dhcp请求,拿到IP地址,之后会走一个pxe的协议,拿到bootfile,下载Bootfile所指明的小系统和内存文件系统文件下来,加载到物理机中,然后开始进行操作系统安装。这就是操作系统安装的过程。操作系统安装完成之后,把安装类和文件系统切换成正在启动的文件系统,在post阶段到集中化的配置中心,把相关的配置拉下来,包括IP地址,主机名和网关等信息,这是宿主机的自动化部署。

KiverCtl实际上就是把操作系统的宿主机变成计算节点或者控制节点。计算节点有如下几个功能:第一,基本的包安装,第二,Docker、Netplugin初始化,启动kiver-guard/flume/cadvisor容器,完成日志和监控指标的采集。

控制节点上面有Etcd和Netmaster,也会可选地把Prometheus/alertmanager/grafana/启动起来。vivoMachineCtl和KiverCtl实现了云服务器节点从物理机到宿主机的转变。

业务日志集成到日志平台实践

这是vivo日志采集的实践,在宿主机上做日志分区,容器运行起来之后挂这个目录,每个容器起来之后会创建一个自己的文件目录。外面有kiver-guard,用来侦听内核文件系统的新日志文件创建的通知。

根据通知会创建软件链接,链接到上一级Flume监控的日志目录,由Flume推到kafka。大数据平台会来消费这里的数据,业务日志平台也会消费这个数据,然后持久化到ES里,最后由中间件日志平台来实现对日志的检索和展示。

为什么要这么做?当时用的flume版本不支持自动收集递归子目录下日志新增内容的收集,完整的文件可以收集进去,但是日志文件在递归子目录下有不停地追加是输不进去的。

kiver-guard本身也是一个容器,它起来之后把宿主机日志目录挂上去,在容器里面侦听日志目录下的create事件。

不管这些日志路径有多深或者在哪里,都可以链接出来。做链接的时候有一点需要注意,要确保链接过来之后文件名称是唯一的。有些容器被删除了,或者日志被轮转删除了,同样也会针对Delete事件,侦测到delete是件之后删除上层flume监控日志路径的对应链接。

基础组件日志收集实践

基础组件日志采用Etcd、Ceph、CentOS、Netmaster等一些网上比较热门的EFK组件,开箱即用。
监控与告警实践

这是监控和告警实践,在容器领域比较常见,vivo采用的是Promethus和Alertmanager。Promethus采用双节点,双拉(拉两遍),两个Promethus之间没有做主从,为了解决高可用问题,挂了一个另外一个还在。

之后接短信邮件中心,后面接Grafana作为监控面板,前面用了telegraf。我们做的东西不仅仅有容器,还有其他的组件像Ceph。我们用Cadvisor收集容器监控指标。

我们对集群健康做监控,也对集群资源使用情况进行监控,集群的健康性采用telegraf可以调用外部shell脚本的特性。我们在控制节点写了脚本,用来检查Etcd的健康情况,也和各个节点进行通讯,检查各个节点是不是健康。之后会返回数值,给出集群健康状态码。

这个就是前面讲的自定义的一些监控指标,这是集群的健康检查,这是集群的资源利用率,大致两条数据链进来。一个脚本由telegraf去拉,推到Prometheus里面,最后展现在Grafana上面。另一个,由DevOps框架把数据写到Mysql里面,再由Grafana定义Mysql的软件源。

这边拉出来的自定义的健康指标支持返回码,这个返回码需要翻译成文字,实际上Grafana已经具备这个特性,我们可以去做一个映射,比如1代表监控,2代表网络问题等等,它可以自动翻译来。
数据持久化实践

说到云服务大家都会关注这个问题,数据怎么做到持久化,做到不丢。容器启动的时候会挂在宿主机上面的一个数据目录,和日志类似,有容器的启动进程,直接写脚本也可以,创造二级目录。

用主机名,是在容器默认的主机名,就是它的默认ID号。如果这个ID已经存在就不用创建,说明容器是起用一个旧的容器,最后建立软链接到数据目录。这样确保每个容器日志数据都持久化到宿主机,还可以确保容器重启后数据不丢。

第二,数据本身有一个单独的备份系统,它会每天晚上凌晨2点跑一遍,把Mysql数据推到Ceph块存储当中,实现数据的可靠性。
集群可靠性实践

这是容器集群可靠性实践,最典型的是三个副本,副本能够实现数据和服务的可靠性。

失效重试,在集群各节点提供一个crontab定时任务,每隔一段时间探测一次docker服务进程健康状况,若不健康,则拉起Docker服务进程。同时我们开启了docker的Restartalways选项,确保容器服务异常退出后,能被重新拉起来。

关于隔离,首先是分区隔离,宿主机业务日志目录/app/log独立分区,避免日志量过大时侵占宿主机系统分区或者业务分区磁盘。

第二,资源隔离,flume当时是跑进程的,我们做的第一件事情是进行容器化,之后做配额,限制能使用的资源使用量,避免大日志传输时侵占宿主机过多资源。

第三,故障隔离,开启dockerlive-restore选项,保障docker服务进程不影响容器服务。
前车之辙

我们犯过一些错误,不负责物理机运营的童鞋可能感受不明显。如果磁盘引导分区被破坏,就可能导致操作系统被重装,这个问题是很严重的。原因也很简单,服务器一般有多引导的选项,比如磁盘、网络、CD,一般在顺序上磁盘第一,网络第二。

但如果磁盘引导分区坏了,服务器会认为没有操作系统,然后就从第二个上引导。这时候不幸的事情是,在你的网络环境里如果之前刚好装过操作系统,采用了第三方开源的部署服务器,而没有把之前的文件删掉,那么它就会把那些操作重新装上。

解决办法很简单,我们提供了定时任务,对两个小时前创建的引导文件,能看见它的创建时间、访问时间,并进行强制性删除。

第二个前车之辙,在收集Ceph日志时碰到困难,当时是用fluent-plugin-ceph插件来做。具体的情况是,第一,官方配置文档不正确,因为提交者没按官方文档格式编码,导致看到的配置是一行,拿回来根本不知道怎么办。第二,它和td-agent1.0 版本不兼容。摸索出的解决方法就是图片上显示的办法。

下一代云服务架构

这是我们下一代云服务架构,与上一代的主要区别在于,把编排框架换成了Kubernetes。目前AI这块已经用起来了,AI部分在线上大概有一百台物理机,跑Job任务,短任务每天可以跑到三万个,一次性可以调动3000个容器,未来会把这个些换成Kubnernetes,包括我们的AI、云服务都会跑在Kubernetes上。
XaaS on Kubernetes

如果把云服务跑到Kubernetes上,第一个要做的事情,可能会采用ceph块存储做后面的数据和数据持久化。目前vivo已经有了数据ceph块存储,但功能还不强大。第二,要解决pod漂移调度问题,如果不用ceph块存储,pod失效调度到其他节点上有问题,调过去没用的,没有数据。
第三,也是最常见的一个,固定POD IP,看到网上有人讨论这个事情,觉得容器坏了,没必要把容器固定起来,因为有违微服务的原则。这种观点不太对,有一些场景,比如在vivo的企业IT架构里面,很多东西都跟IP挂钩,比如安全策略,它不是跟域名挂钩,而是PODIP挂钩,交换机、防火墙等很多的配置都跟这个相关。所以vivo要干的很重要的事情,就是把POD IP固定。
目前业界对这块也有一些实践,比如京东最近有这方面的分享,把PODIP放在一个APP的IP 小池子里面,小池子里面还有IP的话,就从小池子里拿,没有的话就从大池子里去申请。

在微信公众号后台回复“127”,即可获取本次演讲PPT《vivo云服务容器化实践》。
点击数人云阅读更多技术干货

大家好 新人报道

回复

aai99704 发起了问题 • 1 人关注 • 0 个回复 • 68 次浏览 • 2018-01-31 16:43 • 来自相关话题

微服务迁移前,来听听这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

 

这款分布式配置中心,会是微服务的降维打击利器吗?

回复

dataman 发起了问题 • 0 人关注 • 0 个回复 • 75 次浏览 • 2018-01-25 14:22 • 来自相关话题

docker + kubernetes=共生?相爱相杀?

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

 





2017年的云计算市场,有一个领域获得了空前的关注 -- Kubernetes。 Kubernetes可以追溯到2014年,当时Google公开发布了该项目的开源代码。2017年,Kubernetes广受欢迎,几乎所有的主要IT供应商都支持这个平台。
 
小数今天推送的这篇文章,为您揭示Kubernetes与Docker容器之间是怎样的关系?对企业客户又意味着什么?
 
 
1
 
Kubernetes是一个开源项目,提供容器编排,部署和管理功能。自 2015 年 7月以来,它一直是由Linux基金会下的云原生计算基金会(CNCF)运营。尽管Kubernetes不再只是Google的一个项目,Google仍然贡献了远大于比其他任何机构的代码量。
 
 将AIX应用程序迁移到云的最佳实践
Kubernetes 2017年如此耀眼,2018年Kubernetes将继续成为一支重要的力量。要理解这点,首先要认识到这项技术和云计算的完美契合之处。 
 
在过去三,四年中,越来越多的企业选择使用Docker容器来部署云工作负载。Docker容器提供的既是运行容器化应用程序的运行时,也是封装和交付容器应用的格式。容器提供了直接在虚拟机管理程序内部改善可移植性和效率的承诺。
 
随着容器使用量的增长,需要对容器集群进行编排,调度和控制。这就是Kubernetes适合的地方。Kubernetes提供了大规模运行容器的编排系统和管理平台。还提供了一系列API抽象,使其他技术可以插入,使平台具有很强的可扩展性,并且能够支持各种不同的供应商部署用例。
 
比其核心编排能力更重要的是,Kubernetes在2017年成为实现多云世界的事实平台。虽然AWS在2017年继续主导公有云,但企业仍然希望能够在多个云上部署和运行应用程序。
 
容器提供了运行应用程序的基本包装,可以在任何支持容器的云上部署。有了Kubernetes,就有了一个平台,可以帮助企业在运行Kubernetes的云或本地部署管理容器的部署和编排。
 云中的Kubernetes
 
一颗种子总会发芽,结出硕果。在作为开源技术的短短3年时间里,Kubernetes成为基于容器的工作负载的默认编排引擎。虽然捐赠的是1.0版本,但是谷歌在大规模运行容器方面有十年的研究和经验。
 
 
Google是否在内部使用Kubernetes?来自Kubernetes博客:“Google上的许多开发人员都是以前在Borg项目上的开发人员。我们已经将Borg的最佳创意融入了Kubernetes,并试图解决用户在多年来与Borg确定的一些痛点。”
 
谷歌在一些内部项目中使用Kubernetes的声音很清晰,且很快就会改变一些现有的关键产品。即使未来需要更好的展示,Kubernetes也可以轻松定制 – 最大的好处是可以根据需要将自定义组件与现有组件进行混合和匹配。
 
以下是Google在过去几年 Kubernetes 的搜索量增长情况:
 
 

 
Google在Kubernetes上运行的Linux容器(LXC)并不是那么容易处理,而且需要掌握更多的专业知识。
 
2017年初,Kubernetes 只支持谷歌云平台(GCP)和谷歌Kubernetes引擎(GKE),但是在一年中,扩展到包括所有三家主要的公有云供应商。
 
二月份,微软正式加入支持Kubernetes的行列,宣布 Azure容器服务支持Kubernetes。去年11月,Kubernetes在亚马逊弹性容器服务(Amazon EKS)首次亮相。
 
除了公有云支持外,CNCF在9月份还宣布了Kubernetes认证服务提供商计划。该计划现在有25个合作伙伴公司开发和销售自己的Kubernetes发行版并提供管理服务。为了确保不同Kubernetes供应商和平台之间的互操作性,CNCF于2017年11月推出了认证Kubernetes计划,目前拥有42个成员公司。
 
 Docker
Kubernetes部署大多使用Docker作为默认的容器引擎,除此之外还有CoreOS的rkt等。就其本身而言,Docker有一个叫做Swarm的自身的编排系统,首次亮相于2014年12月。
 
在许多企业的容器部署中,多数情况是Docker容器引擎正在被使用,Kubernetes被选择作为编排工具,而不是Swarm。10月17日,在与Kubernetes进行了三年的市场竞争之后,Docker Inc.宣布也将支持Kubernetes。
 
要清楚的是,Docker公司并没有放弃自己的Swarm容器编排系统; 相反,它同时支持Swarm和Kubernetes,让企业可以选择想要使用的平台。
 
在接受eWEEK 视频采访时,Docker首席执行官史蒂夫·辛格(Steve Singh)解释了为什么选择拥抱Kubernetes。Singh说:“Kubernetes为我们所做的事情是消除了任何潜在的混乱和冲突。我们有爱Kubernetes的客户,也有爱Docker Swarm的客户,不应该强迫客户在两者之间做出选择,而是让他们选择想要使用他们的东西。 ”
 
 
Kubernetes之前的Docker 让容器变得更酷,更易用。由Docker公司推出的Docker 在LXC功能的扩展之外,增加了多种功能。包括跨机器的可移植部署,版本控制,组件重用以及现在的 Docker Hub ,它提供了“开发测试流水线自动化,100,000个免费应用程序,公共和私有注册中心”。
 
以下是Google for Docker搜索量增长的图表:
 

 
 Kubernetes 1.9和超越
2017年,Kubernetes更新了四个主要版本,增加了新的特性和功能。第一个主要版本是3月27日推出的Kubernetes 1.6,带来了新的可扩展性和稳定性功能。Kubernetes 1.7于6月29日发布,提供了帮助管理和保护容器基础设施的新功能。第三个版本是1.8更新,于9月28日推出,并支持基于角色的访问控制(Role-Based Access Control,RBAC)。
 
Kubernetes 1.9是2017年的最后一次重大更新,于12月15日正式推出。Kubernetes 1.9的亮点是Apps Workloads API,它为 Kubernetes 中长时间运行无状态和有状态工作负载提供了基础。
 
这是Kubernetes转型的一年,2017开源的努力始于一家公有云供应商,终于年底支持所有三家主要的公有云提供商。该项目也从Docker竞争对手的角色转到被Docker拥抱。多云的承诺长久以来只是一个承诺。作为一个可以在任何公有云提供商上启用容器应用程序工作负载的抽象层,随着Kubernetes 2017年的兴起,2018多云承诺将成为现实。
 
 
2
 
Kubernetes正在巩固自己作为事实上的容器编排引擎的地位,而Docker帮助实现了这一点。尽管Docker一直是领先的容器技术,但容器编排市场还没这么清晰。2017年末,随着包括Docker在内的主要云平台提供商支持Kubernetes和一些令人惊讶的CNCF成员资格的增加,这种情况发生了变化。
 
 正确的时机
“时机就是一切”,对于Kubernetes来说,这似乎是正确的。通过让容器更易用,Docker正在推动Kubernetes的发展。事实上,它已经成为每个公司发展的共生关系 。使用Kubernetes的人越多,使用Docker的也会越多,反之亦然。
 
根据 Portworx2017年度容器采购调查 (2017年2月至3月完成),有两项统计数据显示:
“对于拥有超过5000名员工的公司,Kubernetes的使用率为48%,主要编排工具占33%。”
“79%的样本选择Docker作为主要容器技术。”
 
为了进一步加持 Kubernetes 领导者地位,大型云计算和软件供应商们纷纷加入,以支持Docker容器的工作负载。
 
 Kubernetes商业化产品
自从开源以来,Kubernetes有很多商业化产品,在过去的几个月,这个list上取得了重大且令人印象深刻的突破。
 
以Google(Google ContainerEngine),Red Hat(OpenShift),CoreOS(Tectonic),Canonical和 Apprenda 为长期商业供应商(长期以月计)。微软和VMware也已经提供了对Kubernetes的支持,最近已经全面all-in 推出。
 
 2017 Kubernetes 得胜之年
2017年下半年,主要云服务商将Kubernetes添加到其核心产品中。值得注意的公告包括:
亚马逊网络服务(AWS)于八月份以白金会员 (最高级别) 加入了CNCF。虽然AWS加入CNCF与 Kubernetes 没有直接关系,但AWS拥有大量客户在运行容器和Kubernetes。
 
之后,10月份,Cloud Foundry基金会宣布了由Kubernetes提供支持的Cloud Foundry Container Runtime(CFCR),而Pivotal Cloud Foundry(与VMware合作 )则 于10月份在VMworld 宣布了Pivotal Container Service(PKS)。Pivotal和VMware都作为CNCF的白金会员注册; 再次,可用的最高水平。
 
VMware正在与Kubernetes合作的事实是一个明确的信号,Kubernetes和容器希望保持相关性。许多人质疑容器和云计算是否会取代虚拟机。虽然专家认为他们在企业中存在共存的空间,但可以看看VMware这位虚拟化之王的明显转变。
 
在十月之后,Microsoft 将 Azure容器服务 (ACS)更名 为AKS,K代表Kubernetes。这与他们以前的观点有很大的转变,即 ACS的好处之一是它支持多种编排工具 。
 
即使是Docker Inc.也已经屈服,最近在其Docker企业版框架中添加了本地Kubernetes支持。这对Kubernetes来说是一个重大的胜利,并将推动Docker自己的编排平台Docker Swarm的未来发展。
 
Docker甚至委托独立基准测试来对比Swarm和Kubernetes 。两者肯定都有用例,但Kubernetes得到Google支持的事实是经过了战斗性测试的(还记得 PokémonGO吗 ? ),并且拥有巨大的社区支持,企业把它看作标准的容器编排引擎。 
 
 

这对企业意味着什么?
Kubernetes和Docker一直在坚持。随着公司迁移到云端,他们会发现他们有一些需求PaaS或IaaS最适合,还有一些其他需求容器(有些人称之为CaaS)会更适合。
 
为了享受到上云带来的好处,企业正在转向DevOps和云原生开发。采用DevOps时,企业开始使用运行在容器中的微服务,将应用程序构建为独立的组件。这些团队将会变得更小( 亚马逊CTO Werner Vogels 创造了“双比萨团队”(two-pizza team)一词),并且能够独立于应用的其他组件更新其“服务”的功能。
 
通过将开发工作分解为专注于解耦服务的小型团队,企业可以扩展开发工作,并更快地为客户/用户提供价值。现在,已然不是每六个月更新一次的代码库,而是按需随时进行更新。
 
自动化是复杂的抽象,为了使这项工作自动化,提供一个简单,可重复的方式来安全地交付和部署软件,团队会更频繁地执行。
 
技术的抽象和多样使监控成为难题的重要部分。企业拥有数千个独立移动的部件,其中许多可能显示为传统监控解决方案的黑盒子。随着企业迈向云原生,越来越多的应用程序正在云中运行,专门设计并运行良好的监控方法至关重要。
 
2018年将发生什么?Kubernetes给业务需求和企业客户能够带来的改变已经明晰,作为构建和运行云原生应用的平台乘胜追击,能够在多大比例的企业实现软着陆呢?大概套用那句老话是最准确的:前途是光明的,道路是曲折的。
 
 
原文链接:
1、2018 is the year of Kubernetes – with some help from Docker
https://www.tuicool.com/articles/QBFjAf6
2、2017 Year in Review: Kubernetes Enables a Multi-Cloud World
http://www.eweek.com/cloud/2017-year-in-review-kubernetes-enables-a-multi-cloud-world 查看全部
 

微信图片_20180123105002.jpg

2017年的云计算市场,有一个领域获得了空前的关注 -- Kubernetes。 Kubernetes可以追溯到2014年,当时Google公开发布了该项目的开源代码。2017年,Kubernetes广受欢迎,几乎所有的主要IT供应商都支持这个平台。
 
小数今天推送的这篇文章,为您揭示Kubernetes与Docker容器之间是怎样的关系?对企业客户又意味着什么?
 
 
1
 
Kubernetes是一个开源项目,提供容器编排,部署和管理功能。自 2015 年 7月以来,它一直是由Linux基金会下的云原生计算基金会(CNCF)运营。尽管Kubernetes不再只是Google的一个项目,Google仍然贡献了远大于比其他任何机构的代码量。
 
 将AIX应用程序迁移到云的最佳实践
Kubernetes 2017年如此耀眼,2018年Kubernetes将继续成为一支重要的力量。要理解这点,首先要认识到这项技术和云计算的完美契合之处。 
 
在过去三,四年中,越来越多的企业选择使用Docker容器来部署云工作负载。Docker容器提供的既是运行容器化应用程序的运行时,也是封装和交付容器应用的格式。容器提供了直接在虚拟机管理程序内部改善可移植性和效率的承诺。
 
随着容器使用量的增长,需要对容器集群进行编排,调度和控制。这就是Kubernetes适合的地方。Kubernetes提供了大规模运行容器的编排系统和管理平台。还提供了一系列API抽象,使其他技术可以插入,使平台具有很强的可扩展性,并且能够支持各种不同的供应商部署用例。
 
比其核心编排能力更重要的是,Kubernetes在2017年成为实现多云世界的事实平台。虽然AWS在2017年继续主导公有云,但企业仍然希望能够在多个云上部署和运行应用程序。
 
容器提供了运行应用程序的基本包装,可以在任何支持容器的云上部署。有了Kubernetes,就有了一个平台,可以帮助企业在运行Kubernetes的云或本地部署管理容器的部署和编排。
 云中的Kubernetes
 
一颗种子总会发芽,结出硕果。在作为开源技术的短短3年时间里,Kubernetes成为基于容器的工作负载的默认编排引擎。虽然捐赠的是1.0版本,但是谷歌在大规模运行容器方面有十年的研究和经验。
 
 
Google是否在内部使用Kubernetes?来自Kubernetes博客:“Google上的许多开发人员都是以前在Borg项目上的开发人员。我们已经将Borg的最佳创意融入了Kubernetes,并试图解决用户在多年来与Borg确定的一些痛点。”
 
谷歌在一些内部项目中使用Kubernetes的声音很清晰,且很快就会改变一些现有的关键产品。即使未来需要更好的展示,Kubernetes也可以轻松定制 – 最大的好处是可以根据需要将自定义组件与现有组件进行混合和匹配。
 
以下是Google在过去几年 Kubernetes 的搜索量增长情况:
 
 

 
Google在Kubernetes上运行的Linux容器(LXC)并不是那么容易处理,而且需要掌握更多的专业知识。
 
2017年初,Kubernetes 只支持谷歌云平台(GCP)和谷歌Kubernetes引擎(GKE),但是在一年中,扩展到包括所有三家主要的公有云供应商。
 
二月份,微软正式加入支持Kubernetes的行列,宣布 Azure容器服务支持Kubernetes。去年11月,Kubernetes在亚马逊弹性容器服务(Amazon EKS)首次亮相。
 
除了公有云支持外,CNCF在9月份还宣布了Kubernetes认证服务提供商计划。该计划现在有25个合作伙伴公司开发和销售自己的Kubernetes发行版并提供管理服务。为了确保不同Kubernetes供应商和平台之间的互操作性,CNCF于2017年11月推出了认证Kubernetes计划,目前拥有42个成员公司。
 
 Docker
Kubernetes部署大多使用Docker作为默认的容器引擎,除此之外还有CoreOS的rkt等。就其本身而言,Docker有一个叫做Swarm的自身的编排系统,首次亮相于2014年12月。
 
在许多企业的容器部署中,多数情况是Docker容器引擎正在被使用,Kubernetes被选择作为编排工具,而不是Swarm。10月17日,在与Kubernetes进行了三年的市场竞争之后,Docker Inc.宣布也将支持Kubernetes。
 
要清楚的是,Docker公司并没有放弃自己的Swarm容器编排系统; 相反,它同时支持Swarm和Kubernetes,让企业可以选择想要使用的平台。
 
在接受eWEEK 视频采访时,Docker首席执行官史蒂夫·辛格(Steve Singh)解释了为什么选择拥抱Kubernetes。Singh说:“Kubernetes为我们所做的事情是消除了任何潜在的混乱和冲突。我们有爱Kubernetes的客户,也有爱Docker Swarm的客户,不应该强迫客户在两者之间做出选择,而是让他们选择想要使用他们的东西。 ”
 
 
Kubernetes之前的Docker 让容器变得更酷,更易用。由Docker公司推出的Docker 在LXC功能的扩展之外,增加了多种功能。包括跨机器的可移植部署,版本控制,组件重用以及现在的 Docker Hub ,它提供了“开发测试流水线自动化,100,000个免费应用程序,公共和私有注册中心”。
 
以下是Google for Docker搜索量增长的图表:
 

 
 Kubernetes 1.9和超越
2017年,Kubernetes更新了四个主要版本,增加了新的特性和功能。第一个主要版本是3月27日推出的Kubernetes 1.6,带来了新的可扩展性和稳定性功能。Kubernetes 1.7于6月29日发布,提供了帮助管理和保护容器基础设施的新功能。第三个版本是1.8更新,于9月28日推出,并支持基于角色的访问控制(Role-Based Access Control,RBAC)。
 
Kubernetes 1.9是2017年的最后一次重大更新,于12月15日正式推出。Kubernetes 1.9的亮点是Apps Workloads API,它为 Kubernetes 中长时间运行无状态和有状态工作负载提供了基础。
 
这是Kubernetes转型的一年,2017开源的努力始于一家公有云供应商,终于年底支持所有三家主要的公有云提供商。该项目也从Docker竞争对手的角色转到被Docker拥抱。多云的承诺长久以来只是一个承诺。作为一个可以在任何公有云提供商上启用容器应用程序工作负载的抽象层,随着Kubernetes 2017年的兴起,2018多云承诺将成为现实。
 
 
2
 
Kubernetes正在巩固自己作为事实上的容器编排引擎的地位,而Docker帮助实现了这一点。尽管Docker一直是领先的容器技术,但容器编排市场还没这么清晰。2017年末,随着包括Docker在内的主要云平台提供商支持Kubernetes和一些令人惊讶的CNCF成员资格的增加,这种情况发生了变化。
 
 正确的时机
“时机就是一切”,对于Kubernetes来说,这似乎是正确的。通过让容器更易用,Docker正在推动Kubernetes的发展。事实上,它已经成为每个公司发展的共生关系 。使用Kubernetes的人越多,使用Docker的也会越多,反之亦然。
 
根据 Portworx2017年度容器采购调查 (2017年2月至3月完成),有两项统计数据显示:
“对于拥有超过5000名员工的公司,Kubernetes的使用率为48%,主要编排工具占33%。”
“79%的样本选择Docker作为主要容器技术。”
 
为了进一步加持 Kubernetes 领导者地位,大型云计算和软件供应商们纷纷加入,以支持Docker容器的工作负载。
 
 Kubernetes商业化产品
自从开源以来,Kubernetes有很多商业化产品,在过去的几个月,这个list上取得了重大且令人印象深刻的突破。
 
以Google(Google ContainerEngine),Red Hat(OpenShift),CoreOS(Tectonic),Canonical和 Apprenda 为长期商业供应商(长期以月计)。微软和VMware也已经提供了对Kubernetes的支持,最近已经全面all-in 推出。
 
 2017 Kubernetes 得胜之年
2017年下半年,主要云服务商将Kubernetes添加到其核心产品中。值得注意的公告包括:
亚马逊网络服务(AWS)于八月份以白金会员 (最高级别) 加入了CNCF。虽然AWS加入CNCF与 Kubernetes 没有直接关系,但AWS拥有大量客户在运行容器和Kubernetes。
 
之后,10月份,Cloud Foundry基金会宣布了由Kubernetes提供支持的Cloud Foundry Container Runtime(CFCR),而Pivotal Cloud Foundry(与VMware合作 )则 于10月份在VMworld 宣布了Pivotal Container Service(PKS)。Pivotal和VMware都作为CNCF的白金会员注册; 再次,可用的最高水平。
 
VMware正在与Kubernetes合作的事实是一个明确的信号,Kubernetes和容器希望保持相关性。许多人质疑容器和云计算是否会取代虚拟机。虽然专家认为他们在企业中存在共存的空间,但可以看看VMware这位虚拟化之王的明显转变。
 
在十月之后,Microsoft 将 Azure容器服务 (ACS)更名 为AKS,K代表Kubernetes。这与他们以前的观点有很大的转变,即 ACS的好处之一是它支持多种编排工具 。
 
即使是Docker Inc.也已经屈服,最近在其Docker企业版框架中添加了本地Kubernetes支持。这对Kubernetes来说是一个重大的胜利,并将推动Docker自己的编排平台Docker Swarm的未来发展。
 
Docker甚至委托独立基准测试来对比Swarm和Kubernetes 。两者肯定都有用例,但Kubernetes得到Google支持的事实是经过了战斗性测试的(还记得 PokémonGO吗 ? ),并且拥有巨大的社区支持,企业把它看作标准的容器编排引擎。 
 
 

这对企业意味着什么?
Kubernetes和Docker一直在坚持。随着公司迁移到云端,他们会发现他们有一些需求PaaS或IaaS最适合,还有一些其他需求容器(有些人称之为CaaS)会更适合。
 
为了享受到上云带来的好处,企业正在转向DevOps和云原生开发。采用DevOps时,企业开始使用运行在容器中的微服务,将应用程序构建为独立的组件。这些团队将会变得更小( 亚马逊CTO Werner Vogels 创造了“双比萨团队”(two-pizza team)一词),并且能够独立于应用的其他组件更新其“服务”的功能。
 
通过将开发工作分解为专注于解耦服务的小型团队,企业可以扩展开发工作,并更快地为客户/用户提供价值。现在,已然不是每六个月更新一次的代码库,而是按需随时进行更新。
 
自动化是复杂的抽象,为了使这项工作自动化,提供一个简单,可重复的方式来安全地交付和部署软件,团队会更频繁地执行。
 
技术的抽象和多样使监控成为难题的重要部分。企业拥有数千个独立移动的部件,其中许多可能显示为传统监控解决方案的黑盒子。随着企业迈向云原生,越来越多的应用程序正在云中运行,专门设计并运行良好的监控方法至关重要。
 
2018年将发生什么?Kubernetes给业务需求和企业客户能够带来的改变已经明晰,作为构建和运行云原生应用的平台乘胜追击,能够在多大比例的企业实现软着陆呢?大概套用那句老话是最准确的:前途是光明的,道路是曲折的。
 
 
原文链接:
1、2018 is the year of Kubernetes – with some help from Docker
https://www.tuicool.com/articles/QBFjAf6
2、2017 Year in Review: Kubernetes Enables a Multi-Cloud World
http://www.eweek.com/cloud/2017-year-in-review-kubernetes-enables-a-multi-cloud-world

实录分享|微服务落地践行渐进,4个Q&A一窥金融微服务现状(附PPT下载)

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

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 目的就是帮助企业客户降低微服务架构、上云转型的门槛。
 

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,开发做很多事情,运维可做的很少,并不是这样的。


 Q&A
Q2:微服务适合复杂的场景,那么一个简单的促销是不是适合?微服务有多“微”呢?微服务和ESB 服务相比,有什么差别?A2:第一个促销场景,促销场景本身有些条件,促销很重要一点就是必须特别频繁,促销内容在平台要发生变化。比如,今天的促销内容和明天的不太一样,或者这周的促销和下周的不太一样,业务平台需要频繁变更,这时候微服务是适合的。


因为微服务是一种敏捷开发的落地实践方法,只要业务频繁变更,对开发的要求就必须敏捷开发,快速实现。所以,只要业务场景在不停地快速变化,促销又是互联网线上的方式,肯定是适合的。

 
关于复杂性,如果业务逻辑简单,逻辑变化少,并不适合微服务。比如数人云和很多银行客户合作,银行核心系统很复杂,但是银行系统并不是需求频繁变化的场景。很多银行在做“瘦核心系统”,就是银行核心系统的功能越来越单一,越来越瘦,并不是把复杂的周边的业务也放到银行核心系统里。银行核心系统虽然复杂,但业务不会频繁变化,也不一定要上到微服务场景下。复杂的业务系统,业务需求又不停变化,这种场景适合微服务。


第二个问题是和ESB 比,服务网格和 ESB 有很多相像的地方。ESB有业务逻辑串起来,很多不同的业务系统都上到ESB,互相的权限通过ESB打通。从功能角度讲,ESB和服务网格之间很相像,不同点在于ESB是传统架构下的,并没有考虑频繁迭代、流量集中爆发等问题。


但是微服务情况下,整个之间的互相请求、依赖、通讯等等都会进行统一的管理,这种情况下也很像ESB把不同业务之间的流量进行统一管理,但是服务网格更看重的是面向大规模的控制,那流量突发怎么做限流,或者突然故障怎么做熔断等等。最本质的问题是类似的,但是具体的问题表象和需求不同。 Q&A 
Q3:在实际部署过程中,PaaS平台在底层资源的调用一定要用分布式云架构,传统主机是否可以?两者在最后效果上有没有什么异同?A3:数人云当初两种情况都有,有些场景比如业务量比较大,企业客户为了减少复杂度,容器PaaS平台直接落地到物理服务器上。还有客户为了方便管理,把PaaS落地到IaaS上,两种情况都有。


这其中的考虑是,首先业务量大如果再引入虚拟化这一层会引来额外的复杂度,此时用物理服务器更好。其次,客户有很大规模的物理服务器,直接在上面部署PaaS,在物理服务器上去调用。

 
第三种,资源动态的调整或资源频繁调配,这个场景很常见,需要IaaS。比如银行客户,内部业务系统分不同的域,不同域的业务复杂性随时间变化经常会发生变化,需要不停地做资源动态的调整。如果用物理机太麻烦,企业客户会选择下面有一层IaaS来做。


基于PaaS也能做一部分的资源动态调配,但是调配维度不同。数人云帮客户落地PaaS时会做资源的整合。从划分的维度,PaaS平台是按照应用程序来划分,IaaS的资源划分是按照业务系统。


 Q&A 
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 目的就是帮助企业客户降低微服务架构、上云转型的门槛。
 

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,开发做很多事情,运维可做的很少,并不是这样的。


 Q&A
Q2:微服务适合复杂的场景,那么一个简单的促销是不是适合?微服务有多“微”呢?微服务和ESB 服务相比,有什么差别?A2:第一个促销场景,促销场景本身有些条件,促销很重要一点就是必须特别频繁,促销内容在平台要发生变化。比如,今天的促销内容和明天的不太一样,或者这周的促销和下周的不太一样,业务平台需要频繁变更,这时候微服务是适合的。


因为微服务是一种敏捷开发的落地实践方法,只要业务频繁变更,对开发的要求就必须敏捷开发,快速实现。所以,只要业务场景在不停地快速变化,促销又是互联网线上的方式,肯定是适合的。

 
关于复杂性,如果业务逻辑简单,逻辑变化少,并不适合微服务。比如数人云和很多银行客户合作,银行核心系统很复杂,但是银行系统并不是需求频繁变化的场景。很多银行在做“瘦核心系统”,就是银行核心系统的功能越来越单一,越来越瘦,并不是把复杂的周边的业务也放到银行核心系统里。银行核心系统虽然复杂,但业务不会频繁变化,也不一定要上到微服务场景下。复杂的业务系统,业务需求又不停变化,这种场景适合微服务。


第二个问题是和ESB 比,服务网格和 ESB 有很多相像的地方。ESB有业务逻辑串起来,很多不同的业务系统都上到ESB,互相的权限通过ESB打通。从功能角度讲,ESB和服务网格之间很相像,不同点在于ESB是传统架构下的,并没有考虑频繁迭代、流量集中爆发等问题。


但是微服务情况下,整个之间的互相请求、依赖、通讯等等都会进行统一的管理,这种情况下也很像ESB把不同业务之间的流量进行统一管理,但是服务网格更看重的是面向大规模的控制,那流量突发怎么做限流,或者突然故障怎么做熔断等等。最本质的问题是类似的,但是具体的问题表象和需求不同。 Q&A 
Q3:在实际部署过程中,PaaS平台在底层资源的调用一定要用分布式云架构,传统主机是否可以?两者在最后效果上有没有什么异同?A3:数人云当初两种情况都有,有些场景比如业务量比较大,企业客户为了减少复杂度,容器PaaS平台直接落地到物理服务器上。还有客户为了方便管理,把PaaS落地到IaaS上,两种情况都有。


这其中的考虑是,首先业务量大如果再引入虚拟化这一层会引来额外的复杂度,此时用物理服务器更好。其次,客户有很大规模的物理服务器,直接在上面部署PaaS,在物理服务器上去调用。

 
第三种,资源动态的调整或资源频繁调配,这个场景很常见,需要IaaS。比如银行客户,内部业务系统分不同的域,不同域的业务复杂性随时间变化经常会发生变化,需要不停地做资源动态的调整。如果用物理机太麻烦,企业客户会选择下面有一层IaaS来做。


基于PaaS也能做一部分的资源动态调配,但是调配维度不同。数人云帮客户落地PaaS时会做资源的整合。从划分的维度,PaaS平台是按照应用程序来划分,IaaS的资源划分是按照业务系统。


 Q&A 
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还需要很长时间去落地。

 

微服务落地践行渐进,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还需要很长时间去落地。