博客系列的第四个部分

编者按︰平台即服务(PaaS)技术活跃在微服务运动的最前沿。这里是最近发布在ActiveState博客上的一系列关于微服务文章的第四部分,它涵盖了PaaS提供的主要功能, 这些功能简化了微服务开发。

图片 1

这是不断扩大的“微服务和PaaS”博客系列的第四个部分,该博客系列介绍了微服务正在被快速用于现代云计算项目中。第一和第二部分介绍了微服务的概念并讨论了微服务的先驱们率先发起的模式和做法 ,尤其是Netflix,其代表出席了最近召开的微服务会议,而该会议正是这一博客系列的成因。

Stackato是ActiveState的创新型企业私有平台即服务(PaaS),并且是用于开发和部署应用程序到云的安全而可靠的方式。Stackato 利用最好的开源,建立在云铸造 PaaS 和利用Docker为其 Linux容器(LXC)服务。

第三部分提出了微服务采用者所面对的一系列挑战和隐患的列表。这个列表之强大,有点令人怯步;它指出了思维方式的重大变化、组织结构的重大调整、以及整体发展做法的变更,这些变化需发生于使用微服务之前。

幸运的是,模具等配套技术的发展速度几乎与微服务做法本身的发展一样快。平台即服务(PaaS)处于这种演变的前沿。出于很好的理由,它现在被许多人认为是微服务工具集中的一个重要组成部分。

下面是一些由PaaS提供的关于各种特性的总结,这些特性大大简化了微服务的发展。

1、多语种的语言、框架、持久层

微服务的一大好处是,他们不把一个团队或一个组织限制在一个单一的开发语言或框架之中。每一种服务都可以使用适合于任务、数据或团队的语言和框架进行构建。

但是必须下载、安装、配置和单独设置每个语言堆栈。要求每个开发人员或团队要手动做这介绍相当复杂,这破坏了整体的开发流程。

PaaS 完全消除了提供开发堆栈所需的任何手动步骤,无论是在Spring上的Java、在Rails上的Ruby、还是在Django上的Python。

这些功能,以及更多的功能都是在微服务部署时则立即可用。

同样,微服务应该使用持久层,其对这项工作很有意义。关系(MySQL)、NoSQL(MongoDB)和缓存(Redis)数据库都各自有自己的优势,而PaaS让它们每一个均能立即配置和连接到微服务,无需人为干预。

2、一致性测试环境

测试微服务是棘手的,而有效完成的做法现在还只是刚刚兴起。不管微服务测试的现状如何,可以很肯定地说,如果在微服务的开发、测试、部署到生产的环境之间有不一致的情况,一定会出现混乱。每个环境必须相同这一点是至关重要的。细微的差异会导致不一致的测试结果,将造成严重破坏。

PaaS为微服务开发的每一处如开发、分期、QA、生产等,提供了一个可预见的和一致的开发环境。此外在微云中,比如Stackato所提供的微云,在笔记本或桌面上进行完全云栈运行时,同质化使得它在任何时候可以扩展到所有的开发人员和团队成员。

3、日志

正如我之前讨论过的,在复杂的云应用程序中处理日志是一种痛苦。对于以微服务为基础的应用程序、每个微服务实例生成其自己的日志而言,尤其如此。

PaaS对减少这种痛苦大有帮助。它通过提供自动日志聚合机制,使多个市微服实例的多个日志能够自动聚合和重定向到任意数量的日志聚合服务。PaaS负责确保日志“起到作用”,并确保所有应用程序的所有日志可以很容易地引导到一个集中的目标如Loggly或Splunk,或只是简单地引导到本地PaaS托管日志应用。

4、监测

和日志一样,监控对于以微服务为基础的应用程序的成功运营至关重要。但是,手动监测解决方案的日子已经过去了。有了短期微服实例的快速启动、停止以及在网络中移动,最重要的是实现任何监控解决方案完全自动化,无需人为的干预。

PaaS通常会提供内置监测来跟踪常用度量标准,如CPU负载、内存使用。除了提供这些功能,Stackato也允许与Nagios、New Relic等专门的外部监测工具和服务进行简单的集成,并通过非常容易的可自动化的REST接口公开管理和控制已经部署的微服务以响应监测事件。

5、自动缩放

云应用程序必须扩展以适应可变使用负载。微服务架构允许分离组件,这样引起瓶颈的单个微服务可以单独缩放而不必扩展整个应用。这是一个功能强大的方法,但扩展多个微服务比扩展单个应用程序实例更加复杂。

自动缩放是PaaS光彩夺目的另一个领域。特定的微服务可以响应由内部或外部的仪器提供的指标而自动缩放,以应对加载事件的发生,无需人为的干预。使用了PaaS,自动缩放的复杂性以及处理这些复杂的负担就烟消云散了。

6、服务发现

服务发现、命名和路由微服务的模式正处于起步阶段。为完成这一点,PaaS产品如Stackato提供了基本的构建块,如允许服务定位(URI)和证书能够被注入到应用环境中,也提供了外部发布和访问它们的方法。

7、即时回滚和版本控制

正如我在这个博客系列的第一部分所讨论过的,永恒不变的服务模式用于并排部署多个服务版本。这是一种有效的技术,以一种允许新功能安全推出的方式使微服务进行持续开发和交付。

一个相关的做法是使用PaaS带有的内置版本和回滚机制,在部署完一个新的服务版本之后,如果出现问题它可以立即回滚到以前的任何版本。例如,Stackato会记录一个微服务或应用程序被部署的每一个版本,并公开用户界面和API以便在这些版本之间立即回滚和向前滚动。该用户界面需要人工干预,虽然API允许这个过程轻易地自动响应监控事件。

8、可用性和故障恢复能力

单片应用程序的失败往往会带来整个系统的瘫痪。相反,一个微服务系统是由多个独立的松散耦合的微服务组成。它可以进行设计,使一个微服务的失败不会影响到系统的其他部分。它可以在这样的降级模式中继续运行:某应用程序有破损的服务(也许破损的是相关用户界面)被禁用,但该应用程序的其他部分仍然保持功能。

显然,所有的服务能够在任何时候保持运营最好不过,而且一些服务可能是系统运行的必要条件。这需要一个高可用性(HA)的环境以保证多个微服务实例横跨可用的区域运行,以便能够应对灾难性故障的影响。

HA本身是一种艺术和科学,但PaaS很能从开发人员屏蔽HA的复杂性。例如,Stackato允许创建多个可用性区域,可以跨机架或数据中心,并能保证一个或多个微服务实例总是在这些区域中运行。提供一个通用的和简单的可用性平台去解放开发团队以使他们专注于应用程序上而不是在探究上,这还有很长的一段路要走。

9、摆脱杂草

在微服务的管件中有无数的其他领域的需要,而处理这些事项徒增了复杂性和成本,这阻碍了整体开发流程。这样的例子包括:

规范应用程序实例的路由网络流量

负载平衡

多节点群集配置与管理

与基础设施层(IaaS)接口

服务命名和URI映射

PaaS考虑到了这些管件细节,以使开发团队不必陷入杂草之中。

10、需求/自助服务

PaaS的一个好处是它的“自助”特性,允许按需提供资源,不需要提交服务票证,也不需要以任何方式涉及其他人。这提升了开发的速度,简化了整体的开发流程,并允许自由实验的开发者可以加速集群和服务而无需过程担保。这种自服务能力对于微服务导向的开发组织而言是必不可少的。

PaaS适合微服务

Adrian Cockroft在其所作的微服务介绍中广泛而清楚地表示,出于上述理由等,PaaS是整个微服务故事的关键。PaaS不仅规范环境,显著降低了复杂性,而且也为组织移动到微服务所需的主要变化提供了基础。

极少数发组织像Netflix一样,拥有能够推动全公司范围内发起的调整其整个软件体系结构、组织和思维移向微服务的方法和资源。正如AsDonnie Berkholz与Bernard Golden的炉边谈话中所言,改变组织结构图本身是一个庞大的事业,除非降低开发障碍的模具已经到位,否则这不会发生。

Donnie所指的模具正在演变为PaaS,它为目标团队成功交付微服务提供了一个强大的和自服务方法。Stackato是来自ActiveState的世界级企业PaaS,它是PaaS提供简化微服务开发的一个经典案例。

本文作者John Wetherill,由寄云科技翻译。