什么是微服务？关于轻量级软件开发的诠释

 

微服务定义

微服务将功能分解为由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 编译：陈琳华