云原生时代的微服务，适合所有人么？

微服务是一种优化资源的体系结构方法，这些资源为复杂、快速、分布式基础设施上的大规模服务和软件提供计算、存储和网络。大多数有IT历史的组织，传统上都是在虚拟技术栈上构建软件，这些技术栈由操作团队手动维护。今天，开发人员大规模使用云服务来构建应用程序架构和自动化工作负载。面向机器架构的时代正在过去——面向应用程序的基础设施正在流行。今天，这些资源提供了全堆栈的、开发人员构建应用程序体系结构所需的内容。开发团队需要为应用程序架构更全面地开放资源，这证明了DevOps工具在功能强大的分布式架构上运行的深层需求。

对技术工具、服务和平台的需求包含在构成微服务的内容。无限的计算、网络和存储资源的平衡，为运行任意数量的服务提供了机会和障碍。就像任何一种过度兴奋的、吸引技术社区注意的新方法一样，在围绕微服务的炒作中，往往没有提及复杂性。从表面上看，开发、部署和管理软件的完美方法可能要比最初出现的方法复杂得多。因此这是一个让公司深入了解业务目标、团队开发、工作流和用于构建应用程序架构的服务的旅程。通常，对于那些技术背景与微服务的现代方法不匹配的人来说，做出改变并不容易。微服务要求组织重新考虑运行其业务的现有软件体系结构，以及组织如何适应需要新的技术技能和文化转变来匹配的实践。这种实践有风险，并不是每个人都能做到。

尽管如此，大约90%的开发人员至少都在为一些工作负载考虑微服务架构。然而，当被更具体地问及它们在生产应用程序中的使用时，这个数字下降了。然而，与任何快速发展的新兴技术一样，要想理清所有的炒作，就要理解微服务如何实际应用于日常工作。这有助于从微服务的实际基础开始，然后权衡软件体系结构本身的好处和缺点。

微服务的定义

微服务是一种基于将应用程序构建为小型服务集合的软件开发体系结构方法。对于构成“小型服务”的代码量并没有标准定义。一些专家说，这与查询服务运行状况时的“大小”有关。如果一个服务需要多个team来管理，那么它就太大了。每个服务都有自己独特且定义明确的角色，在自己的流程中运行，并通过HTTP应用程序编程接口(API)或消息传递进行通信。每个微服务都可以独立于应用程序中的所有兄弟服务进行部署、升级、扩展和重新启动。它们通常由自动化系统编排，使实时应用程序的频繁更新成为可能，而不会影响最终用户。

个人可能更习惯使用应用程序的概念。但如今，一般的企业组织至少使用十几种不同的软件产品和集成。记录业务开销、进度跟踪和工资管理等，是组织现在使用运行在云服务上应用程序的几个例子。使用紧凑而专业的工具以提供优雅用户体验的方式完成每项工作是有意义的，类似于个人应用程序在社交网络上发布照片、视频和与他人联系时所获得的体验。微服务使用包含云服务的分布式体系结构，以一种松耦合的模式组合在一起来进行扩展。就像乐高积木一样，微服务中的组件可以在适当的位置构建一个统一的模型。

(微服务是小型、独立扩展和管理的服务。每个服务有其自己独特和良好定义的角色，运行自己的流程和通过HTTP API以或Messaging进行沟通)

首先，开发人员确定构建项目所需的独立服务“部分”，例如搜索、身份验证、消息传递和销售处理。然后，从服务、库和可用代码片段、从开源到交钥匙企业解决方案的大杂烩中进行选择，并将所有内容整合到一个功能应用程序中。

云原生浪潮

云原生微服务的概念源于容器体系结构的发展。

在基于容器的体系结构之前，开发人员需要构建技术堆栈，然后将其部署到云服务或健壮的企业体系结构上。这些应用程序是面向机器的，并使用监控软件及其在云服务和企业上的性能的一系列工具进行优化。这是超越面向服务架构(SOA)的一步，尽管有些人认为SOA只是由供应商重新命名以销售相关产品的微服务，这是有一定道理的。

微服务可以被认为是SOA的一种类型。容器只是使方法更加广泛可用，并降低了SOA带来的风险程度。在虚拟机(VM)上运行的SOA需要时间和投资来构建、部署和运行。VM运行在操作系统上，而操作系统也必须进行移植才能在SOA环境中运行。这是一项繁重的手工工作，并且几乎没有为寻找实际运行SOA本身的 好的方式而承担风险的空间。

由Docker领头，容器改变了游戏规则。Docker代表了SOA的发展和平台即服务(PaaS)的时代。Docker通过其简单、易用和低风险推动了采用率。它将Linux容器技术打包成开发人员可以访问和使用的内容。构建、运行和管理容器技术只需很少的开销——这与重量级的SOA世界形成了鲜明的对比，后者需要大量的投入，尤其是在网络和存储方面。

容器现在充当微服务的底层基础，通过API网关和gRPC等新方法连接。总体而言，容器使SOA可以通过简单地使技术更易于使用而大规模实施，所涉及的风险远远低于以往。微服务与DevOps、持续集成和持续交付(CI / CD)，以及容器的使用密切相关。事实上，“微服务”和“容器”这两个术语经常一起使用。但是，容器和微服务并不是一回事。微服务可以在容器内运行，但它也可以作为完全配置的虚拟机运行。也就是说，基于容器和开源的平台，如Docker和Kubernetes，是开发、部署和管理微服务的一种非常有效的方法。容器空间中已经存在许多成熟且健壮的工具、平台和其他服务，这使得容器化非常适合基于微服务的应用程序。

虽然容器和微服务独立存在并且用于不同的目的，但它们经常一起使用;它们甚至还被视为DevOps的好拍档 。容器是微服务的一种使能技术，这也是微服务通常在一个或多个容器中交付的原因。由于容器是隔离环境，因此无论用于创建每个微服务的编码语言如何，它们都可用于快速安全地部署微服务。一旦基于微服务的应用程序达到显著的规模，在没有容器的情况下几乎不可能管理它。运行在集群编排平台(如Kubernetes或Mesos)之上的容器化微服务，包括在云中、本地或混合模式，是当前对向外扩展的云原生应用程序的定义。

重要的是要注意虽然容器是将代码打包到微服务中的“严格”方式，但也可以将整个单体应用程序打包到容器中，而不需要创建微服务。随着云计算的进一步发展，以及更多组织从传统基础架构中解放出来和/或开始评估无服务器架构的用例，打包可以而且很可能会发生变化。事实上，许多微服务的支持者表示，它们只是多云和无服务器计算的跳板，这是一种利用资源自动化功能和填补应用程序架构空白的新兴方法。

有行业专家认为，将微服务和容器结合起来只是一个实施细节，而不是一个重要的抽象概念，除非在VM上有很多需要迁移到同一技术堆栈的传统应用程序。

微服务的好处

通过使小型自治团队能够独立开发，部署和扩展各自的服务，微服务基本上可以并行化开发 ——从而以指数方式加速生产周期。这种敏捷性是大型企业在多种报告中指出采用微服务所引用的首要原因，其次是改进的可扩展性。

微服务可以让开发人员不必浪费时间重新解决已经解决的技术问题。持续集成和部署基本上构建在微服务架构中。微服务可以直接把很多基础设施风险带出项目。随着基础设施变得几乎不可见，微服务团队可以进行通常以小时周期运行的快速迭代，从而持续降低错误功能的风险，同时增加价值。

换句话说，使用微服务，团队中的每个开发人员都可以忘记底层基础设施，专注于自己的项目。然后在生产中，如果单个项目模块不能完全正确地工作在一起，那么很容易对它们进行隔离、拆卸和重新配置，直到正确地工作为止。这些组件是松耦合的，就像乐高一样。这种方式提供了使用可互换的部件在应用程序体系结构中大规模运行的能力。它们的独立和独立结构也带来了安全性优势，因为更容易通过自动化和实施安全策略的现代安全平台进行控制。

随着组织的发展，工程团队可以更轻松地扩展和维持速度。微服务架构的主要好处不是技术，而在于团队开发和人员管理。相比之下，当代码库增长到一定规模时，单体应用程序变得无法适应和管理。管理这种规模的应用程序架构的团队绝不能让单体架构失效。如果整体架构失效了，那么业务也会随之流失。因此编写脚本以防止应用程序泄漏并在主要版本升级之间构建各种补丁成为企业架构师的重要优先事项。功能是预先定义好的，并按照优先级与整体相适应;客户则被夹在中间，并且做出的强制性决策可能是短期的解决方法，但会带来较长期的问题，例如定制化的脚本随着时间推移而失效，并且依赖于具有企业基础架构记忆的人员。这本身是一个糟糕的体验，因为新的软件升级可能无法解决客户遇到的问题。

一个主要问题是(单体)应用程序会变得极其复杂。它太大了，任何单个开发人员都无法完全理解。因此修复bug和正确实现新特性将变得困难且费时。更重要的是，这是一个恶性循环。如果代码库难以理解，那么将无法正确进行更改。许多组织已经达到了这样一个阶段，即管理单体应用整体结构的痛苦超过了采用新的微服务方法。微服务的采用是这类组织的优秀选择，尽管它也有自己的挑战。

微服务的缺点

微服务是经典单体应用的对立面，具有明显的优势。但是，与任何正在发展的技术一样，早期采用曲线可能很陡峭。目前，Netflix和PayPal等大公司最有效地采用了这种方法，由于强大的内部资源和工程团队，这些公司已经能够转向微服务架构。

Netlify首席执行官兼联合创始人Mathias Biilmann表示:“当你拥有一个非常庞大、资源丰富的企业，个人团队能够管理每项服务并确保可重用性和可探索性时，这是非常棒的。”然而，对于其他人来说，痛苦是真实存在的。根据有关报告，只有1%的企业使用微服务表示他们对架构没有任何挑战。操作开销、日志记录和监视方面的挑战以及缺乏技能被列为最主要的挑战。离开单一的应用程序体系结构意味着失去将所有部分粘合在一起的固定工作流。最常见的情况是，因为IT团队主要负责集成和维护许多不同服务的基础设施，采用微服务体系结构会增加操作成本。团队必须在微服务远景与实际需要之间艰难地找到平衡，才能使其发挥作用并取得成功。

当将整体分解为微服务时，将冒着一个非常分散的系统风险，开发人员需要花费大量的时间和精力将服务和工具粘合在一起，并且缺乏可以跨项目工作的常见模式和平台 。为了真正利用微服务，需要能够构建可以实现一键设置的“胶水”供应商。”

(迁移到微服务，通常为带来了大量运维挑战，因为集成和维护很多不同服务的基础设施责任落在了IT团队)

LAMP堆栈的出现可以作为一个很好的对比。Linux、Apache web服务器、MySQL和 PHP等免费工具为web开发开辟了新的可能性。但当公司围绕WordPress、Drupal和Joomla等项目构建集成工具时，LAMP体系结构才真正起飞。

在真正的微服务方法中，团队只运行他们需要的小服务，而不运行其它任何负载。但是，这种实施和编配工作已经超出了许多中小型组织的工程范围。将一个整体分割成许多更小的、独立的服务在速度和敏捷性方面有许多优势，但也有许多挑战。微服务架构可以增加支持和维护的运营开销，因为每个服务都有自己的语言和要求。这也使得监控和安全性变得更加复杂，因此需要更高水平的自动化和工具。而且由于服务之间的通信现在通过网络进行，因此它会对服务发现、消息传递、缓存和容错产生新的要求，这些要求可能会给系统带来压力，如果处理不当可能会导致性能问题。虽然Service Mesh解决了许多这样的问题，但是引入一个没有流量管理的Service Mesh服务，它自己就会产生一些问题，这些问题可能会导致更严重的性能问题。

可以提前做所有想做的测试，并且这会对要发布的代码相当有信心。但是当真正把它投入生产时，就会遇到各种各样的问题，因为实际上并不知道代码在生产中会如何表现。流量管理实际上是将部署与发布解耦。部署是指拥有新代码、新版本并将其投入生产，但还不占用任何客户流量。可以做烟雾测试、内部测试，这些测试都在生产中运行。当发布一个版本时，就会开始思考：要给这个新版本的代码带来什么样的流量?如果有能力把流量控制到非常精细的水平的话，可以分割、控制、并逐步推出新的代码更改。

没有工程资源或技能将稳定的基础架构与现有的开源代码和工具结合在一起的组织，很难 让微服务的好处大于挑战。操作和性能问题也可能困扰那些没有就其服务(依赖关系和版本兼容性)进行沟通的团队，并且必须在生产失败时撤回已经写入的代码。幸运的是，微服务市场正在起飞。许多公司现在不仅生产微服务本身，还生产无缝连接它们所需的平台、工具和框架。

微服务不适合所有人

分布式服务的基础架构已经成熟，但是更高的效率只能来自于更好的声明式系统，这些声明式系统来自于改进的自动化技术和改进的可观察性。因为没有任何微服务是完全相同的，这么做可能很棘手。它们的任何自定义工作流程就像雪花一样。不同之处在于底层的体系结构，以及如何适应针对不同工作负载的微服务方法的不断开发。

设置边界很重要，这样微服务就不会被认为是万灵药或有趣项目的分支，因为微服务需要更多的管理。开发者大批量地构建微服务要追溯回2014年至2016年的鼎盛时期，这些开发者在喝茶聊天的时候决定了新的微服务该怎么构建。因此现在如果有几十个团队决定创建自己的微服务，会发生什么?虽然管理是完全可能的，但是会牺牲效率，从而影响优化和获得更好性能的过程。

毫无疑问，微服务是有效的。但是，一个构建良好的单体应用整体架构也可以扩展，并且在许多场 景中仍然是很好的选择 。例如，运行相同服务或工作程序的多个实例不一定需要微服务。创建不可伸缩的微服务也是完全可能的。因此在确定解决方案之前，首先考虑面临的问题是很重要的。

就基础设施和技术支持而言，生态体系现已接近关键的规模。微服务正迅速成为DevOps工具包中的一个工具，从而更好、更深入地利用资源。这进而创建了新的空间来交付额外的服务，从而进一步实现声明性的和优雅的工作流、工具和平台的潜力。

向着微服务过渡的业务和流程决策

云原生微服务是一种真正令人兴奋的架构演化，尤其是在构建、部署和管理复杂分布式应 用程序方面。然而，大多数围绕微服务的讨论直接涉及到技术：持续集成和部署、容器、 编排器等等。虽然技术实现很重要，但是还有一些更重要的事情需要考虑。

微服务必须与组织的目标相适应。开发人员可以构建微服务，但是体系结构只有与业务目标相结合时才有价值。因此必须提出关键问题，从业务用例、现有团队、技能和职责开始——采用微服务的决策取决于组织的目标和远景。组织中具有实现复杂体系结构经验的人员必须提出一个重要的问题，并在继续前进之前得到答案：我们是否适合微服务体系结构?

Container Solutions的CEO和联合创始人Jamie Dobson曾表示，客户找过来希望使用微服务作为技术问题的解决方案，实际上却常常是组织问题的技术解决方案。

评估云原生服务。评估企业采用云原生微服务与企业本身的关系，而与企业的规模、行业甚至实际技术关系不大。首先，从决策到执行的微服务迁移应该由企业的组织和管理方式驱动：

商业模式：软件可以差异化业务吗?如果是这样，开发团队必须继续增长和扩展，因为组织需要更多的资源和服务功能。基于微服务的体系结构允许更快的迭代开发，可以在跨多个团队的工作流中使用。依赖专有的、统一解决方案的组织将不太适合微服务方法。系统记录管理(ERP)到服务级别协议(SLA)类的商业软件协议意味着，如果企业选择遵循将它们带入微服务讨论的路径，那么它们将发生根本性的转变。对于完全依赖于商业软件平台的组织来说，实现微服务的成本可能会更高。微服务所需的在敏捷性和可伸缩性方面的工程支持和开销成本将超过它们的价值。

文化和内部流程：微服务需要一套新的工具和流程，并打破旧的工具和流程。对于负责管理单体的组织来说，突然改变工作流可能是一个困难的转变。接受DevOps原则是微服务成功的关键。然而，举例来说，团队可能会抗拒从传统的瀑布方法转向敏捷方法。微软首席云开发布道师Bridget Kromhout曾表示，“如果你意识到所涉及的人有着他们自己的习惯而且他们也许在不远的未来就要退休了，那么这种抵制并不是完全不合理的，而且他们不喜欢一切改变的想法，他们只是以他们喜欢的方式看待问题。”

微服务的基本复杂性在于应用程序体系结构本身：根据体系结构，每个服务都需要自己的支持团队、工具和基础设施。并不是每家公司都在正确的位置采取行动。专家强调，并不是说错误地采用这种体系结构是不可能的，只是这个过程会更长或更复杂。对于许多有着错误商业动机或文化的组织来说，成本将高于收益。Bridget Kromhout再次强调：不能通过实施正确的技术解决方案来解决组织中的每一个问题，因为组织是复杂的系统，其中也有可能以不可预知方式行事的人。

那么，什么时候微服务不适合企业呢?

敏感行业：某些行业，例如金融服务和医疗保健，面临法律、报告和合规要求，需要与新技术相协调。可追溯性因素：与更年轻、更紧凑或更敏捷的组织相比，一家在商业领域经营数十年的全球性公司，尤其是平均员工保留时间超过10年的公司，很可能更难适应向全新架构的巨变。“停滞不前”的公司：这些是规避风险的公司，决策链很长，层次结构僵化。因此当采用一种新的响应性微服务范例时，这些组织并不十分适合，甚至可能会对所需的快速适应产生抵触。

New Relic的首席站点可靠性工程师Jonathan Owens表示，考虑转向容器和微服务架构的组织应该问自己以下问题：您的运营团队向开发人员提供了什么产品，该产品使用了什么抽象层? 该产品是否适合您的业务，还是容器更合适? 容器是否更好，以至于您愿意更改抽象层，从而更改运营团队提供的整个产品，以便使用它们?您是否已准备好创建新角色来管理此新抽象的规模和可靠性?

没有哪个组织会在一夜之间发生这样的变化。从一个理想化的新架构到第一个产品部署的过程需要改变许多想法并创建新的流程，这并不总是很有趣。寻找具有微服务专业知识且能够做出必要的工具和架构决策的工程师也很困难。这些专家包括难以捉摸的“全栈开发人员”，他们了解每一层的应用程序：从网络和托管环境，到数据建模、业务逻辑、API和用户界面以及用户体验(UI / UX)。这些人处于独特的位置，可以看到技术体系结构和组织是如何相互关联的。要实现成功的微服务转换，组织需要一个按比例构建的技术体系结构，但维护该结构的团队也同样重要。

这就是为什么许多正在向微服务过渡的组织选择与专业服务公司合作，这些公司专门帮助客户使用各种不同的架构来构建云原生应用程序。这些顾问可以帮助评估组织对微服务的需求和适用性，或指导他们采用更合适的替代方案。

微服务最适合吗?

对于由业务原因而采用微服务的组织，可以满怀信心地带领团队转型。领导项目的团队在组织中具有重要地位，并可以开始设置适合 现有工作流的优秀实践 。团队可以采用服务来推动应用程序体系结构的整体开发，并为组织使用更多资源运行微服务做好准备。

做准备时需要技巧和人员管理。适合开发团队的服务将定义微服务。团队的目标是使微服务成为一个建立在其价值基础上的“底座”，并不断优化开发人员的体验。

评估应用程序的职责是定义微服务应用程序组件的第一步，Netlify首席技术官David Calavera曾表示，他是Docker和GitHub先前工作的微服务老手。确定应用程序职责的相互依赖关系，这关系到微服务的结构。Connascence是一个评估应用程序组件和互连的衡量标准。因为两个或多个组件是并发的，所以如果改变其中一个组件，还必须更改另一个组件。

考虑到这种关系，可以更好地评估是否值得拥有不同的微服务，或者是否应该保留的单体架构。除了相互依赖之外，团队必须牢记将这些组件分离到微服务中会引入它们之间的网络连接——这不可避免地增加了系统的复杂性。

应用程序体系结构开发是个人和团队如何就他们自己以及重叠的编排进行交互和通信的直接结果。很明显在这一点上，像Kubernetes这样的架构正变得越来越重要。随着越来越多的开发人员添加进来，应用程序变得越来越复杂，体系结构的总体复杂性也随之增加。但是正如所看到的，这些应用程序架构并不适合所有人。

Calavera警告说:“您不希望以牺牲理想架构为代价来增加不必要的复杂性。”