为什么要使用微服务_免费论文全文下载

申明:本网站内容仅用于学术交流，如有侵犯您的权益，请及时告知我们，本站将立即删除有关内容。

当今的应用程序需要不断地修改、扩展和更新，以满足不断变化的业务需求。微服务让您轻松可靠的应对这些变化

我现在还在用成百上千行的老C++应用程序。哦，我是在�_人吗？这是数百万行的Vectran，是IBM在上世纪70年代开发的存在时间很短的一个FORTRAN语言变种。但它还在用，对吗？
除非它自己出问题。每当有人想添加功能时，就会出问题。即使想要修复漏洞，也会产生更多的漏洞。但如果不碰它，它就会一直工作下去。
问题在于创新需要敏捷和速度。所有那些从未担心过Y2K的炫酷公司，都不再使用老旧软件。投资者要求的是创新突破，要让客户们趋之若鹜。
好消息是，您不是单打独斗。信不信由您，即使是最炫酷的公司也面临类似的问题。Netflix、eBay、亚马逊、推特、PayPal，还有很多公司都还没有开始采用架构很容易扩展，且快速敏捷的应用程序。
2006年，eBay在SD论坛上做了一次报告，介绍了其体系结构。公司承认，开发了整段的330万行C++ ISAPI DLL，编译成一个150MB大小的二进制文件。eBay开发人员对每一类方法的数量进行了编译器限制，预计每年可以增加1200个新功能，其可用性高达99.94%。
eBay是怎样克服其负担过重的老架构的？PayPal、推特、亚马逊和Netflix也是这样做的：废掉了他们整段式的应用程序。他们使用微服务重新设计自己的基础设施，这一技术把大型应用程序分解成能够横向扩展的轻量级应用程序。
打破磐石
微服务把功能分解成通过REST API松耦合在一起的独立的应用程序。例如，eBay开发了不同的java servlet应用程序，用于处理用户、项目、账户、反馈、交易，以及2006年以来就在使用的70多个其他要素。这些逻辑功能应用程序中的每一个现在都被认为是一种微服务。现在，eBay大概运行着数百个微服务。
这些微服务每一个都是独立的。它们不共享数据层。每个都有自己的数据库和负载均衡器。隔离是微服务架构的关键因素；不同的微服务需要不同的扩展技术。例如，一些微服务可能使用关系型数据库，而其他的可能使用NoSQL数据库。
微服务的常见问题
随着开发人员和管理人员涉足微服务，很多同样的问题反复出现。下面列出了一些最常见的问题及其回答。
如果每一服务都应该有自己的数据库，那么怎样把不同数据库之间的数据关联起来呢？
人们在开发微服务架构时遇到的第一个问题是，怎样释放连接表。如果您要开发的应用程序比本文中简单的博客示例更复杂，那么这个问题就变得非常明显了。
简单的解决方案是使用应用程序级连接而不是数据库级连接。这往往导致比单条SQL命令更多的数据库查询，但可以在微服务层里采用高速缓存来缓解这个问题。毕竟，每个微服务都可以有自己的高速缓存技术。从长远来看，这种方法不如直接连接数据库简单，但它的可扩展性肯定要好一些。
一个更复杂的解决方案是您微服务架构中置入一个事件驱动的发布-订阅消息总线。消息总线支持各种微服务与应用程序中发生的事件进行通信。这种架构是开发非常丰富和复杂微服务应用的基础，因为不必再依靠随时马上能用的服务API。
怎样对微服务进行流程编排？
运行数十个或者数百个小的微服务来代替一个大的整段应用程序的运营开销非常惊人。毫无疑问，持续跟踪所有相互关联的微服务会增加复杂性。好在这些问题的流程编排新解决方案变得越来越稳定和可靠。
无论是Kubernetes、Mesos、Swarm，还是Nomad，这些流程编排工具基本上都做同样的事情：他们让您以声明的方式来构建DevOps平台。
传统的DevOps工具非常适合启动、管理和监控各个应用程序，但DevOps工具和流程编排服务之间的区别在于流程编排服务是用于管理复杂的微服务环境，在这种环境中，运行的服务之间会相互关联。
其基础是，所有这些流程编排工具都只是对消息总线进行作业调度。如果您已经在架构中使用了消息总线，那么您可能希望在消息总线之上开发流程编排引擎。
怎样分解现有的应用程序？
您可能没有奢望使用微服务架构从头开始重建您的应用程序。关键是您不需要。
如果正在使用的老应用程序仍然非常重要，您想把它分解成微服务，但是希望逐步进行，那么可以从构建仿微服务开始。
仿微服务与普通的微服务基本一样，只是数据存储还没有与应用程序的其它部分相隔离。例如，如果有一个复杂的定制博客应用程序，您可以创建一个仿Article微服务，这是一个独立的应用程序，其唯一的功能就是完成Article REST API。然而，底层Article数据库仍然在同一个大型关系型数据库模型中。这样，数据就不会被复制了。
最终，当有足够多的仿微服务被搭建出来后，您可以把数据存储分解成一个个独立的单元。
微服务不就是SOA（面向服务的架构）吗？
微服务与SOA表面看起来大同小异，但存在明显的不同。表面上，SOA使用的是SOAP和XML-RPC，而微服务与JSON相关联。但在某些方面，API格式更为美观。
同样的，SOA使用企业服务总线，而微服务使用更轻便的发布-订阅服务总线。同样道理，原理是相似的，只是更轻便一些。
Bob Rhubart说过，“微服务必须独立部署，而SOA服务往往需要整段的部署”，这是很能说明问题的。
微服务的理念在根本上就是要废掉整段式的应用程序和数据库。它是要搭建高度分布的、自治的、横向可扩展的应用程序。微服务的标志是轻量级的组件和独立可部署特性。轻量级API。轻量级服务总线。轻量级数据存储。 后台进程会怎样？
随着大数据分析的兴起，长时间运行的后台进程变得越来越普遍。幸运的是，微服务非常适合这类问题。
如果您已经在自己的��用程序架构中采用了发布-订阅消息总线，那么后台进程只是另一个不需要端口绑定的微服务。它们可以通过订阅消息总线连接到总线上，然后等待，直至事件被触发。
通过这种方式，开发团队能够更灵活地构建应用程序。如果是整段式的代码，您就需要有一大帮人一起处理一大段代码，工作起来总是相互掣肘。大段的代码会越来越长，开发速度呈指数下降。而采用微服务架构，应用程序是由小规模、分散开的开发团队搭建的，他们可以相互独立地工作，修改微服务。这样，很容易更新服务，添加功能。软件和开发过程都变得更加敏捷。
由于所有这些原因，微服务变得越来越受欢迎。但是每种架构都有其优点和缺点。微服务架构也有一系列难以解决的新问题。
本文中，在介绍这一开发应用程序的现代方法时，我们将探讨微服务的优缺点。然后我们将介绍怎样构建一个基于微服务的博客应用程序来说明微服务实际是怎样工作的。最后，我们将解决一些关于微服务最常见的问题，回答最关键的问题：您应该使用微服务吗？
最后一个问题的答案可能会让您大吃一惊。
微服务的优缺点
微服务的理念是将内部架构非常复杂的大规模整段式的应用程序分解成更小的、独立的、可扩展应用程序。例如，如果您是eBay，您可能希望“用户反馈微服务”比“招标微服务”更小，而且不复杂。
在考虑这个问题时，为什么首先要把这些功能构建到一个应用程序中呢？至少在理论上，您可以想象它们可以在独立的应用程序和数据单元中，不会有什么大问题。例如，如果平均拍卖收到两份投标书，但只有四分之一的销售收到反馈，那么在任何时候，投标服务至少比反馈应用程序活跃八倍。
通过这种方式，把不同的功能组分隔成单独的应用程序就很有意义了。然而，能够独立构建和扩展您应用程序的不同部分虽然是优点，但也随之而来一系列的新问题――特别是记录、监控、测试和调试您分散的、松散耦合的新应用程序。
如果有一个漏洞，应该由其中的哪一个微服务负责呢？微服务之间的相互依存关系使得这一问题很难回答。微服务之间一般通过轻量级JSON REST API相互通信。与以前的XML-RPC和SOAP不同，REST接口趋于更松散的定义。这些轻量级的API更灵活，更容易扩展，但它们也增加了一个需要监视的新接口，这可能会产生中断或者导致漏洞。
在过去整段式的应用程序中，您可以在代码中添加调试钩子，并在逻辑上逐步遍历每个执行层以发现问题区域。当您处理由几十个甚至数百个不同的应用程序构成的网格，而且这些应用程序通过松散定义的API互相进行通信，此时，您就不能这么“奢侈”了。
尽管如此，经过周密的计划，您还是能克服这些困难的。目前，可供选择的货架式微服务调试工具还不多。您可能需要根据其他的局部的情况，把自己的解决方案拼接在一起。但是当您围绕微服务理念进行开发时，实际是有隐藏的好处，例如与PaaS、Docker和Linux容器等新技术相结合等。
微服务、容器和PaaS
现在有一个常见的误解，如果使用微服务，就需要使用PaaS或者Linux容器，或者类似的东西。这根本不是真的。您可以使用没有微服务的PaaS和Linux容器，也可以使用没有PaaS或者Linux容器的微服务。他们互相都不需要对方。
但在很多方面，它们确实是相辅相成的。PaaS环境，无论是Heroku等公有云，还是Cloud Foundry或者OpenShift等私有云，都非常适合运行很多较小的应用程序。把330百万行C++应用程序导入到PaaS平台的这类事情将不会再发生。
如果您把应用程序分解成小段的应用程序，每一段都是相对独立的，自己能够独立扩展，那么这些小段的应用程序就非常适合在PaaS环境中运行。
出于这一原因，考虑采用微服务架构有助于加速您发展路线图中其他技术的应用。同样的，Linux容器更适合小规模、无状态应用程序，而不是整段式的大规模应用程序。
毕竟，虚拟机和Linux容器之间最大、最明显的区别是缺少状态。可以配置虚拟机使其保持状态不变，而Linux容器架构本质上抛弃了与基本镜像的任何差异。采用Linux容器，您可以在其中安装有状态文件夹，但容器本身不会改变――除非您确认进行更改。
微服务架构的横向扩展理念促进了无共享、无状态应用程序这一概念的发展。也就是说，它们不存储或者修改底层文件系统。这就是为什么人们把微服务和Linux容器合起来使用的原因：它们都不保留状态。
微服务为应用程序开发提供了很好的方法――只要您清楚问题和缺点所在。这一技术趋势今后会持续下去。通过这种技术，很多技术大腕们解决了过去10年中应用程序大规模增长的问题。
怎样看待微服务应用程序的开发
如果您以前从来没有开发过微服务架构，那首先要改变思维方式。很多开发人员从数据库布局开始应用程序的设计。他们建立了大量的表，包括复杂的连接表。然后在数据库基础上构建应用程序逻辑。最后，把用户体验放在应用程序逻辑之上。这就像一个三层蛋糕一样，这种构建应用程序的方法一开始时能很好地工作。
这种架构的问题是，当把新功能加到应用程序中时，新表和连接表也被加到了数据库中。然后，把新功能嫁接到现有代码中。随着时间的推移，这变成了一个巨大的“老鼠窝”。
开发微服务应用程序最简单的方法是从前端开始，向后工作。彻底转变传统的架构方法。
为了说明这种逆向的方法，让我们考虑一个简单的博客应用程序。传统上，您可以通过创建一个包含文章表、注释表、作者表等数据库的博客应用程序来开始构建博客应用程序。文章可能会有各种作者，因此，您要为文章和作者建立一个连接表。 采用微服务，您可以从博客主页模型开始，考虑其中的各个要素。评论不在博客的主页上，所以在这一时点没有必要定义它们。您甚至不需要构建评论数据库，可以以后进行。
首先，您创建一个名为Article的独立的REST API微服务。通过集成Backbone、Angular或者Ember等JavaScript客户机，前端模型成为函数代码。所有这三个JavaScript客户机都能够自然的与REST API协同工作，可以把数据放入到以前只是模型的设计中。
Article REST API微服务是一个轻量级的应用程序，其重点放在存储和检索文章数据的核心功能上。在微服务应用程序开发的这一阶段，您不用担心认证或者安全模型。以后再对其他的微服务进行分层处理。不要让很多不必要的功能成为微服务的负担――毕竟，所谓微服务，“微”是重点。
这一阶段最重要的是，由于每个微服务的功能范围有限，最终您能够非常灵活的选择数据存储方案。不采用大型的、复杂的数据库设计，关系型数据库变得不太相关，MongoDB、Couchbase、Cassandra、Redis和Riak等NoSQL数据库可能会工作得更好一些。理论上，每个微服务可以使用一种完全适合自己、不同的底层数据存储机制。
开发好了自己的Article REST API，并向前端客户机提供动态数据后，您就需要处理评论了。您可以建立一个新的独立的Comment REST API微服务，专门针对评论采用垃圾信息过滤器和身份识别技术。Comment微服务完全封装了所有各种各样的评论代码，您的前端客户机现在可以根据需要从这个新API中获取动态数据了。
最后，您可能想建立一个Author微服务，用于处理创建新文章时所需的身份认证和权限。Author服务会有一个控制面板前端，允许博客作者登录，编写新博客文章。Author微服务可以被集成到前端客户机和Author微服务中。在文章创建过程中，Article微服务向Author微服务发起API调用，确保作者有编写新博客文章的权限。
过去，是通过关系型数据库中的连接表来进行权限检查的。轻量级服务间API调用有时可以代替连接表。
前端微服务应用程序现在来自三个独立的微服务，其中两个互相之间有通信。这一应用程序中的所有一切都是分散的。每个微服务都有自己的数据库，而不是一个大规模的关系型数据库。每个微服务都可以独立扩展。您可以为Article微服务数十个应用程序服务器建立一个负载平衡器，而Author微服务只需要一个例化，没有负载平衡器。
微服务背后分散式、松散耦合的理念非常适合利用第三方服务。例如，不用开发自己的Comment微服务，您可以使用Disqus。不用开发自己的认证微服务，而是使用Janrain。
这种开发应用程序的微服务方式咋看起来有些奇怪，但微服务架构已经证明它是替代老的整段式大规模应用程序可行的方案。如果您决定沿着这条路走下去，那么您就会站在巨人的肩膀上。
微服务适合您吗？
我前面提到过，对是否应使用微服务这一问题的答案可能会让您大吃一惊。答案并不总是肯定的。正如微服务顾问Chris Richardson所说，“这并不简单，而您使用微服务的原因就是要解决复杂性。”
微服务是“撞到玻璃天花板”后的反应，记住这一点是很重要的。在某种程度上，传统的整段式应用程序架构无法再扩展了。每一个成功的软件项目都遇到了这种情况。要么数据库增长得太大，要么有高达数百万行的代码，导致您根本无法快速添加功能。
如果您还没有“撞到玻璃天花板上”――也就是说，您的老程序还能很好的工作，不需要有太大的改�樱�如果自己愿意主动采用微服务，除了一大堆头疼的问题，可能不会有太多收获。
毕竟，微服务的开发过程很怪，而且很难。让所有这些新服务运行，有时感觉就像杂技里面把数十个球在空中抛来抛去。可以采用Kubernetes等声明流程编排工具进行适当的调整。复杂的微服务架构都有自己的词典系统，覆盖了您要采用的所有新的软件模式。
然而，微服务还没有像SOA当初那样让人感到畏缩。实际上，即使是最小的软件项目也可以采用微服务――您不必扔掉所有的老代码从新开始，可以从建立仿微服务开始。
如果您的大规模应用程序已经很难掌控，其软件生命周期非常长，创新的步伐陷于停顿，那么微服务可能就是您所需要的。或者，如果您是刚刚开始，一开始就考虑开发基于微服务的应用程序是非常明智的。
eBay曾说过，采用微服务架构，公司能够很好地进行扩展，提高了代码的可扩展性和可维护性，促使业务快速创新，产品交付更快，甚至增强了安全性。谷歌、亚马逊、推特，PayPal和Netflix都有类似的体验。很多这类公司还开发了工具，更方便的采用微服务。
不论您正困扰于怎样维护老代码的问题，不知道该怎样办，还是开始一个全新的应用，现在都是尝试采用微服务方法来开发应用的好时机。
Lucas Carlson是一名企业家、作者和开源工程师。如果需要了解详细信息，请访问lucascarlson.net。
原文网址：
http：//www.infoworld.com/article/3200034/application-development/why-you-should-use-microservices.html

本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系，我们将在24小时内删除。QQ:522-52-5970