微信号:infoqchina

介绍:有内容的技术社区媒体

Q新闻丨微服务部署面临的挑战;React v15发布,版本大跃进;Netflix如何构建代码...

2016-04-24 10:40 Q新闻
欢迎收看Q新闻,实习主播小Q为您播报。本周最大的新闻当然是QCon北京2016胜利举行啦,咳咳,请看正题...


微服务部署面临哪些挑战?

以前,我们邀请几位嘉宾讨论了他们在开发微服务时遇到的挑战,比如Fred George或Dustin Huptas和Andreas Schmidt。近日,Usman Ismail参加了一场小组会议,讨论了微服务持续交付面临的挑战,并决定随后详述其中的部分重点内容。他首先讨论了微服务其中一个基本原则的缺点,即允许大型团队通过快速原型和迭代以一种更加敏捷的方式推进(软件)开发:

不过,微服务显著增加了开发团队的运维和工具负担。每个服务都需要一个部署管道、一个监控系统、自动报警、轮流电话值班,等等。对于大型团队,所有这些负担都可以视为提升特性开发效率的合理代价,是创建这些系统值得付出的努力。不过,在小型团队中,如果同一批人负责所有的服务,那么无论如何,为多个项目复制管道都是开销上的浪费。

接下来考虑的是运维负担。在Usman看来,使用微服务或单体架构,如果推出了一个服务或组件的不良版本,就需要回滚系统,而且如果遇到资源限制,则(常常)可以横向扩展。不过,使用微服务,你需要更多的监控和自动化才能检测出哪些服务需要回滚,并确定回滚一个服务对其他依赖它的服务产生什么影响,等等。

如果你有自动报警系统(你真应该有一个),那么你需要把报警信息发给服务所有者,并为多个服务维护一个电话值班时间表。在小型组织中,负责不同服务的人群之间会有很大的重叠。这就是说,我们必须针对这些服务协调时间表,以确保同一个人不会被许多服务钩住,让人们在轮流电话值班之外得到一些喘息。由于这些以及上一节中提到的原因,最好是开始引入多个微服务的开销之前有一个单体架构,并把所有的运维工作安排妥当。

然后当然是微服务一个基本特点——一个在传统单体应用中可能不会提到或者很少提到的特点:分布式。这引发了一个古老的问题,就是在分布式环境中调试,我们过去已经提到过许多次,在微服务这个术语被创造出来以前。原先,Joyent首席技术官Bryan Cantrill探讨过在生产环境中调试微服务。Usman认为,没有一个集中式的微服务日志是一种致命的缺陷:

而且,在规模比较大的情况下,有一个单独的监控系统(比如datadog、grahite)和一个单独的日志聚合系统(比如ELK、loggly或Splunk)是不可行的。在这种规模下,可视化指标和日志数据是一个大数据问题,最好在一个地方解决。

对于小组会议的最后一个重点,Usman提到了部署协调和版本管理。文章认为,微服务和单体应用的其中一个重大差别是前者是一棵服务依赖树,而后者是一个图:

例如,在单体模型中,一个典型的服务栈可能包含一个“Web组件组合(web array)”,它调用一个缓存层、数据库层,可能还有一些独立服务,比如身份验证,等等。在微服务模型中,你会有一个连通图或者服务网络,每个服务都依赖于几个其他的服务。有一点很重要,就是要确保这个图是一个有向无环图(DAG),否则你会陷入依赖地狱,可能还会遇到分布式堆栈溢出错误。

有趣的是,Usman的文章接下来总结了嘉宾们提出的一些指导原则:

参加小组会议的嘉宾,没有哪个人对他们的微服务系统十分满意,也就无法为如何构建这样一个系统提出任何类似指南的东西,不过,我们确实提出了一些经验法则或者一般的指导原则,包括下列这些。

这些原则可以总结为:

  • 微服务需要大量的基础设施用于开发和部署,因此要使用一个平台。“Kubernetes、Swarm、Mesos以及其他类似产品可以提供很大的帮助,但你仍然需要使监控、调试、“连续管道(continuous pipeline)”和服务发现机制一体化。”

  • 为了实现可再现、可靠的自动化,不要通过人工过程定义系统的任何东西。“任何东西都必须通过代码定义,可测试,可再现。例如,服务器/虚拟机的配置应该使用docker-machine、puppet、ansible等进行编排。

  • 开发或使用集中式监控、日志和报警。“单体服务就像一个深受喜爱的宠物,你知道它所有的怪癖和习惯,而微服务就像牲畜;你要它们全部都差不多一样,并作为一个普通的畜群进行管理,而不是一个个体。”

  • 务必确保向后向前兼容。

  • 将大型微服务部署可视化为一个网络。“监控和管理一个大型微服务部署同管理一个网络系统十分类似。”

所有的建议都是基于来自各类公司的嘉宾们的集体经验。那些建议一直随着时间演变,将来可能会随着经验的日益丰富而继续演变。在某种程度上,Usman最后的评论附和了Vijay Alagarasan去年在演讲“7种微服务反模式”中所讲的内容:

【微服务】并不是解决构建和运行大规模分布式软件基本问题的魔弹。微服务架构迫使你更谨慎地遵循最佳实践和自动化工作流。本次讨论的一个重要结论是,除非你愿意将大量的时间和资源从特性开发工作转到构建和维护一个服务框架上,否则最好避免进入微服务的世界。不过,如果你能够投入时间构建一个很棒的服务框架和工作流,那么你将完成重大转变,成为一个更敏捷、更有生产力的组织。

我们总是在寻求更深入的微服务经验,有好的经验,也有不好的经验,因此,或许你想自己对Usman的工作或讨论作出评判。

  • 英文原文链接:

  • http://www.infoq.com/news/2016/04/msa-deployment-challenges

React V15发布,版本大跃进?

Facebook最近发布了React 15的最终版,清理了许多DOM问题,提升了性能,增强了对SVG的支持。

在该版本中,React在渲染HTML方面有两项重大更新:移除data-reactid属性和文本中不必要的<span>元素。在早先的版本中,渲染的DOM元素可能是这样:

<div data-reactid=".0.0.5">     <div data-reactid=".0.0.5.0">Hello</div> </div>    

而现在,同样的HTML片段却是这样的:

<div>     <div>Hello</div> </div>    

在某些纯文本元素中去除<span>标签不仅可以让渲染的HTML更干净,也可以帮助修复开发者可能遇到过的非预期的CSS行为问题。

新版本完成了对所有SVG属性的支持,但是在候选(Release Candidate)版本的发布后,它发生了一些变化。在GitHub提交信息中, Paul O’Shannessy 称在团队讨论过如何让新用户更加方便地使用React之后对SVG白名单进行了更新:

候选版本让我们在HTML和SVG行为方面处于不一致状态。这样并不好,我们必须从React中学到很多教训,抛出更多的不一致是不好的。所以我们会暂时回退一步,但仍会通过之前的白名单继续对SVG提供完整的支持,并且我们会扩展这个白名单。

有意思的是,你会发现O'Shannessy编写了一个脚本,通过分析Mozilla Developer Network找出完整的SVG属性列表。

因为这是一次主要版本发布,所以做了一些突破性改变。除了新的DOM渲染变化,在0.14版本中引入的废弃的特性现在都已移除。

从v15.0版本开始,使用TypeScript 1.8.9版本的用户不能再编译TSX文件,这是由于新版本移除了一个废弃的特性。虽然有其他的变通方案,Facebook还是恢复了React.__spread API并正式弃用了它。Dan Abramov警示大家说,在下次主要发布中它将被弃用,因此任何用到这个API的工具集必须停止使用它。在下次发布中会有对该TypeScript问题的修复。

正如InfoQ早先报道过的那样,这是React首次使用新的版本命名方式。之前的版本编号形如 "0.14.7"。

根据最新的团队会议备忘录,社区将会看到更多小版本的发布和补丁,以及改进的变更日志。

  • 英文原文链接:

  • http://www.infoq.com/news/2016/04/react-15-released

Netflix 是如何构建代码的?

三名Netflix工程师Ed Bukoski、Brian Moyles和Mike McGarr在一篇博文中(http://techblog.netflix.com/2016/03/how-we-build-code-at-netflix.html)解释了Netflix如何持续交付向7500万观众提供电视节目和电影的代码。

Immutable Server模式是Netflix部署的基础。每次部署都会创建一个全新的亚马逊机器镜像(AMI)。

Netflix的微服务架构让Netflix团队可以松耦合。变更推送速度让每个团队都很舒服。

Netflix不要求任何团队使用任何工具集,但他们要负责维护他们实现的工具。在Netflix,有团队会集中提供工具,作为“铺好的路”的一部分,以减少大多数Netflix工程师的认知负担。

这个“铺好路”的代码交付过程由几个步骤组成。代码使用Nebula在本地构建和测试。变更提交到中心Git版本库。一个Jenkins作业构建、测试并打包应用程序用于部署。这些程序包使用Netflix的全球持续交付平台Spinnaker部署到亚马逊机器镜像(AMI)。

构建

Nebula是Gradle构建系统的一组插件,它可以构建、测试并打包Java应用程序。Netflix的大多数代码都是用Java编写的。这些插件扩展了Gradle的自动化功能,包括依赖管理、发布管理以及打包。一个项目的构建文件声明了用到的依赖和插件。

集成

下一步是将本地构建、测试并打包的源代码推送到Git版本库。具体的流程由团队选择。

提交完成后,会触发一个Jenkins作业构建、测试并打包代码用于部署。程序包类型会根据构建对象是一个库还是一个应用程序作出恰当的选择。

部署

Netflix “Bakery”暴露了一个API用于创建AMI。具体的镜像使用Aminator创建。用户指明将什么基础镜像和程序包放入该AMI。基础镜像是一个Linux环境,包含与Netflix生态系统集成所需的约定、工具和服务。

当Jenkins集成任务执行成功后,它会触发Spinnaker管道。Spinnaker读取Nebula程序包,并使用Bakery API创建AMI。

然后,Spinnaker会向数以十计、百计或千计的实例提供该AMMI。

第一次部署是到测试环境,部署会执行自动化集成测试。在通过这些测试后,Spinnaker为团队提供了自定义生产环境部署过程的灵活性,例如多区域部署、金丝雀发布或者红/黑部署。

该自动化过程非常高效,举例来说,Janitor Monkey云弹性和维护服务从代码检入到多区域部署只要16分钟就可以完成。

未来方向

在Netflix,语言无关的需求与日俱增。非JVM语言需要包含进构建过程。

部署时间有一大部分是“烘焙(baking)”过程,Netflix正设法减少这部分时间。

此外,Netflix还在研究容器是否能够帮助他们应对上述两个挑战。

容器还可以改进当前的构建、烘焙和部署过程,进而改善开发测试周期。可以在本地部署的容器,无需修改就可以部署到生产环境,这对于确定一个Bug是否是由环境差异导致的非常有帮助。这让工程师可以专注于新特性。

延展阅读(点击标题):


本文系InfoQ原创首发,未经授权谢绝转载。

 
InfoQ 更多文章 年前挖的坑都填了吗?技术债务偿还计划 程序员VS武林高手:技术为外功,思维乃内力 腾讯游戏大数据服务场景与应用(附PPT) 偷师饿了么:怎样用HTTP/2优化iOS APP网络层次架构? 作为高颜值的女程序员是一种怎样的体验?
猜您喜欢 送书福利丨大数据必读的十本精选好书 应用宝基于Robotium自动化测试(上) 尚学堂丨JAVA常用英语单词(上) 免费课程报名|产品经理必修课:支付专家帮你打通支付的奇经八脉 【独家访问】2048开发方谈Cocos2d-x