计世网

什么是微服务?关于轻量级软件开发的诠释
作者:Lucas Carlson 编译:陈琳华 | 来源:计算机世界
2019-01-08
使用微服务架构可以将大型应用程序分解为能横向扩展的轻量级应用程序。

 

创新需要敏捷和速度。那些从未担心过"千年虫"(Y2K)计算机系统漏洞的酷公司正在抛弃那些笨重老旧的软件,投资者们需要的是新一代重大创新。大批客户也在抛弃这些老旧软件。

解决方案是分解那些单体的大型应用程序,并且不再创建新的类似的应用程序。实现的方法是使用微服务架构,这种技术可以将大型应用程序分解为能横向扩展的轻量级应用程序。

微服务定义

微服务将功能分解为由RESTful API松散耦合的独立应用程序。例如,eBay在2006年开发的独立Java servlet应用程序,用于处理用户、项目、账户、反馈、交易和70多项其他要素,其中每一个逻辑功能应用程序都是一个微服务。

这些微服务都是独立的,并且不共享数据层,每一个都有自己的数据库和负载均衡器,隔离是微服务架构的关键要素。不同的微服务需要不同的扩展技术,例如,有些微服务可能使用关系型数据库,而其他的可能使用NoSQL数据库。

微服务的好处

微服务架构可以将内部架构非常复杂的大型单体应用程序,分解成小型的可独立扩展的应用程序。每个微服务都很小,开发、更新和部署也不太复杂。

在考虑微服务时,为什么首先要将这些功能都构建到单个应用程序中呢?至少在理论上,你可以想象为:它们可以存在于单独的应用程序和数据孤岛中,这不会有什么大问题。例如,如果在拍卖中收到两份投标,但只有四分之一的销售收到反馈,那么在一天中的任何时间里,投标服务的活跃程度至少是反馈应用程序的八倍。如果将这些组合到一个应用程序中,你最终运行并更新的代码将比经常需要的代码更多。在本质上,将不同的功能组分隔成不同的应用程序,自有其道理。

而且,围绕微服务架构进行开发可获得一些隐性优势,例如可与PaaS、Docker和Linux容器等新技术紧密结合。

以微服务方式构建应用程序不仅可使应用程序更加灵活,更具可扩展性,它们还增加了构建应用程序的团队的可伸缩性。使用单一代码,你可以建立一支大型团队,虽然团队成员能够处理大段代码,但是他们始终彼此掣肘,随着代码整体数量的增长,开发速度会呈指数级下降。

不过,借助微服务架构,应用程序可由小型的、分散的开发团队进行构建,他们可以独立地工作和修改微服务。这样做的好处是升级服务和添加功能更加容易,软件和开发流程也将变得更加灵活。

微服务的挑战

但每种架构都有优点和缺点。虽然优点明显,但是微服务架构也带来了一系列难以解决的新问题--特别是记录、监控、测试和调试去中心化且松耦合的新应用程序。

如果有一个漏洞,那么哪个微服务应当对此负责呢?微服务之间的相互依存关系使得这个问题很难回答。微服务通常通过轻量级JSON REST API相互交换数据。与其前身XML-RPC和SOAP不同的地方是,REST接口的定义正变得越来越松散。虽然这些轻量级API更灵活,更容易扩展,但是它们增加了需要监控的新接口,这可能会产生中断或导致出现漏洞。

在单体应用程序中,你可以在代码中添加调试钩子,并在逻辑上逐步执行每个执行层,以发现问题区域。如果当数十个甚至数百个独立的微服务使用松散定义的API相互交换数据,那么在处理由这些微服务组成的网格时,你就不能再这么做了。

尽管如此,只要精心安排,这些困难是可以克服的。一些调试工具可以提供帮助,不过你可能需要根据其他部分的情况整合自己的解决方案。

微服务与容器和PaaS的关系

有一种常见的误解是,如果要使用微服务,那么你就需要使用PaaS或Linux容器。其实事实根本不是这么回事。你可以在没有微服务的情况下使用PaaS和Linux容器,也可以在没有PaaS或Linux容器的情况下使用微服务。它们彼此并不需要对方。

不过,它们之间确实能够很好地相互补充。无论是Heroku等公有云,还是Cloud Foundry或者OpenShift等私有云,PaaS环境都可以优化运行许多小型应用程序。像将330万行C ++应用程序移植到PaaS平台的事情永远都不会发生。

如果将应用程序分解为小的、可独立扩展的自足型应用程序,那么这些小型应用程序通常都非常适合在PaaS环境中运行。

同样,Linux容器更适合如微服务这样小型的无状态应用程序,而不是大型的单体应用程序。

毕竟,虚拟机和Linux容器之间最大和最明显的区别之一是缺少状态。虚拟机可通过配置保持其状态,而Linux容器的架构在本质上已经不再与基础映像有任何差异。你可以在Linux容器中安装状态文件夹,但是除非你提交更改,否则容器本身不会进行更改。

微服务架构的横向扩展理念促进了无共享、无状态应用程序的观念。它们不存储或修改底层文件系统。这就是为什么人们容易将微服务与Linux容器混为一谈,原因在于两者都不保留状态。

微服务与SOA的关系

微服务与SOA(面向服务的架构)关系密切,但又存在明显差异。从表面上看,SOA与SOAP和XML-RPC相关联,而微服务则与JSON相关联。但在某些方面,相关的API格式有着明显的外观差异。

同样,SOA使用企业服务总线,而微服务使用更轻量级的发布-订阅服务总线。尽管后者更为轻便,但原理是相似的。

微服务架构和SOA之间最大的区别在于微服务必须是可独立部署的,而SOA服务通常在部署整体中实现。

微服务是否适合你?

重要的是,你要记住,微服务是对"撞到看不见的天花板"的应对举措。在某些时候,传统的单体应用程序架构无法再进行扩展。几乎每个成功的软件项目都会遇到这些情况:数据库会变得异常庞大,或是代码行数多达数百万行,亦或是你再也无法快速添加功能。

如果你还没有"撞到看不见的天花板"。也就是说,如果传统的应用程序仍然运行良好,并且不需要太多改变。那么,只是为了部署微服务而部署,你将无法从中获得什么好处。

毕竟,微服务的开发过程不同于常规,并且具有难度。让所有这些新服务保持运行,有时会让人感觉像在空中将十几个球抛来抛去。部署Kubernetes等编排工具可以做一些调整,复杂的微服务架构有着自己的词典,它们能够涵盖你需要采用的所有新软件模式。

然而,微服务并不像SOA那样令人生畏。实际上,微服务实践甚至可以在最小的软件项目中实现,并且不需要抛弃所有旧代码重新开始。

如果你有一个大型应用程序失控了,但软件生命周期还有很长时间,创新速度也已经停滞不前,那么微服务可能正是你需要的东西。或者,如果你刚刚开始起步,那么从一开始就考虑构建基于微服务的应用程序是非常明智的。

eBay表示,微服务架构让他们具备了进行大规模扩展的能力,提高了代码的可扩展性和可维护性,促进了业务快速创新,创建了更快的产品交付模式,甚至连安全性也得到了增强。谷歌、亚马逊、推特、PayPal和Netflix都有类似的体验,为了更便捷地部署微服务,其中许多公司还开发了公共工具。

无论你是遇到了维护传统代码的问题并且一筹莫展,还是已经开始使用全新的应用程序,现在正是尝试用微服务方式进行应用程序开发的好时机。

作者Lucas Carlson不仅是企业家,还是作家兼开源工程师。

原文网址:https://www.infoworld.com/article/3237697/application-development/what-are-microservices-lightweight-software-development-explained.html

责任编辑:周星如