论文部分内容阅读
使用微服务架构将大型应用程序分解为可横向扩展的轻量级应用程序。
你正在为几十万行遗留的C 续命吧。咳咳，我们要糊弄谁？数百万行的Vectran只是IBM在上世纪七十年代开发的一种短命的Fortran变体。但是，嘿，如果它们还没坏呢？除非它们坏了。每当有人试图添加功能时，它们就会崩溃。尝试修复漏洞会产生更多的漏洞。但是如果你不碰它们，它们就会一直工作下去。
问题在于创新需要敏捷和速度。那些从未担心过“千年虫”（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都有类似的体验。 为了更便捷地部署微服务，许多公司还开发了公共工具。
无论你是遇到了维护遗留代码的问题并且一筹莫展，还是已经开始使用全新的应用程序，现在正是尝试用微服务方式进行应用程序开发的好时机。
你正在为几十万行遗留的C 续命吧。咳咳，我们要糊弄谁？数百万行的Vectran只是IBM在上世纪七十年代开发的一种短命的Fortran变体。但是，嘿，如果它们还没坏呢？除非它们坏了。每当有人试图添加功能时，它们就会崩溃。尝试修复漏洞会产生更多的漏洞。但是如果你不碰它们，它们就会一直工作下去。
问题在于创新需要敏捷和速度。那些从未担心过“千年虫”（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都有类似的体验。 为了更便捷地部署微服务，许多公司还开发了公共工具。
无论你是遇到了维护遗留代码的问题并且一筹莫展，还是已经开始使用全新的应用程序，现在正是尝试用微服务方式进行应用程序开发的好时机。