微服务是一种架构方法，用于优化为复杂、快速、分布式基础设施上的大规模服务和软件提供计算、存储和网络的资源。大多数具有IT历史的组织传统上都在由运营团队手动维护的虚拟技术堆栈上构建软件。如今，开发人员大规模使用云服务来构建应用程序架构和自动化工作负载。面向机器的架构时代正在过去-面向应用程序的基础架构已经到来。今天，这些资源提供了开发人员构建应用程序架构所需的完整堆栈。开发团队需要更全面地开源应用程序架构，这表明对DevOps工具在强大的分布式架构上运行的迫切需求。对技术工具、服务和平台的要求包含在构成微服务的内容中。无限计算、网络和存储资源的平衡为运行任意数量的服务提供了机会和障碍。与任何吸引技术社区注意力的激动人心的新方法一样，在围绕微服务的炒作中通常不会提及复杂性。从表面上看，开发、部署和管理软件的完美方式可能比最初看起来要复杂得多。因此，这是一个让公司深入了解用于构建应用程序架构的业务目标、团队开发、工作流和服务的旅程。通常，对于那些技术背景与现代微服务方法不匹配的人来说，进行更改并不容易。微服务要求组织重新思考运行其业务的现有软件架构，以及组织如何适应需要新的技术技能和文化转变来匹配的实践。这种做法有风险，不是每个人都能做到。尽管如此，大约90%的开发人员仍在考虑为至少某些工作负载采用微服务架构。但是，当更具体地询问它们在生产应用程序中的使用时，这个数字下降了。然而，与任何快速发展的新兴技术一样，理清所有炒作需要了解微服务如何实际应用于日常工作。它有助于从微服务的实际基础开始，然后权衡软件架构本身的优缺点。微服务的定义微服务是一种基于将应用程序构建为小型服务集合的软件开发架构方法。对于构成“小服务”的代码量并没有标准的定义。有专家表示，在查询服务的健康度时，这与“大小”有关。如果一个服务需要多个团队来管理，那就太大了。每个服务都有自己独特且定义明确的角色，在自己的进程中运行，并通过HTTP应用程序编程接口(API)或消息传递进行通信。每个微服务都可以独立于应用程序中的所有同级服务进行部署、升级、扩展和重启。它们通常由自动化系统编排，可以在不影响最终用户的情况下频繁更新实时应用程序。个人可能更习惯于使用应用程序的概念。但是今天，普通企业组织至少使用十几种不同的软件产品和集成。记录业务开支、进度跟踪和工资单管理等是组织现在如何使用在云服务上运行的应用程序的几个例子。使用紧凑和专业的工具以提供优雅的用户体验的方式完成每项工作是有意义的，类似于您在社交网络上使用个人应用程序发布照片、视频和与他人联系时获得的体验。微服务使用分布式架构进行扩展，该架构包括以松耦合模式组合在一起的云服务。就像乐高积木一样，微服务中的组件可以就位以构建统一模型。（微服务是小型的、独立扩展和托管的服务。每个服务都有自己独特且定义明确的角色，运行自己的进程并通过HTTPAPI或消息传递进行通信）首先，开发人员确定构建项目所需的“独立服务”部分”，例如搜索、身份验证、消息传递和销售处理。然后，从一大堆服务、库和可用代码片段中进行选择，从开源到交钥匙企业解决方案，并将它们整合到一个功能性应用程序中。云原生浪潮云原生微服务的概念起源于容器架构的发展。在基于容器的架构出现之前，开发人员需要构建技术堆栈，然后将它们部署到云服务或健壮的企业架构中。这些应用程序是面向机器的，并使用一系列工具进行优化，这些工具可以监控软件及其在云服务和企业上的性能。它超越了面向服务的架构(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上有很多遗留应用需要迁移到同一个技术栈。微服务的优势微服务通过使小型自治团队能够独立开发、部署和扩展他们自己的服务，从本质上实现了并行开发，从而以指数方式加快了生产周期。这种敏捷性是大型企业在多个报告中采用微服务的首要原因，其次是改进的可扩展性。微服务使开发人员免于浪费时间重新解决已经解决的技术问题。持续集成和部署基本上构建在微服务架构中。微服务可以直接从项目中消除大量基础设施风险。随着基础设施变得几乎不可见，微服务团队可以进行通常以小时为周期运行的快速迭代，从而在增加价值的同时不断降低错误功能的风险。换句话说，有了微服务，团队中的每个开发人员都可以忘记底层基础设施，专注于自己的项目。然后在生产中，如果各个项目模块不能完全正确地协同工作，很容易隔离、拆除和重新配置它们，直到它们正常工作。组件是松散耦合的，就像乐高积木一样。这种方法提供了使用可互换部件在应用程序架构中大规模运行的能力。它们的自包含和独立结构也带来了安全优势，因为它们更容易通过自动化和强制执行安全策略的现代安全平台进行控制。随着组织的发展，工程团队可以更轻松地扩展和保持速度。微服务架构的主要好处不是技术，而是团队发展和人员管理。相反，当代码库增长到一定规模时，单体应用程序变得不适应和难以管理。管理这种规模的应用程序架构的团队绝不能让单体失败。如果整体架构失败，业务也会随之丢失。因此，编写防止应用程序泄漏的脚本并在主要版本升级之间构建各种补丁成为企业架构师的重要优先事项。能力是预先定义的，并按优先级排列以适应整体；客户被夹在中间，被迫做出可能是短期修复但会产生长期问题的决定，例如定制脚本会随着时间的推移而失败，并且依赖于具有公司基础架构记忆的人员。这本身就是一种糟糕的体验，因为新的软件升级可能无法解决客户遇到的问题。一个主要问题是（单体）应用程序会变得极其复杂。它太大了，任何一个开发人员都无法完全理解。因此修复错误和正确实现新功能将变得困难且耗时。更何况是恶性循环。如果代码库难以理解，则无法正确进行更改。许多组织已经到了这样一个阶段，即管理整体结构的整体结构的痛苦超过采用新的微服务方法。采用微服务对于此类组织来说是一个极好的选择，尽管它也有其自身的挑战。微服务的缺点微服务是经典单体应用程序的对立面，具有明显的优势。然而，与任何发展中的技术一样，早期采用曲线可能很陡峭。目前，这种方法最有效地被Netflix和PayPal等大公司采用，由于强大的内部资源和工程团队，它们已经能够转向微服务架构。Netlify首席执行官兼联合创始人MathiasBiilmann表示：“当你拥有一个非常庞大、足智多谋的企业时，各个团队可以管理每项服务并确保可重用性和可探索性，这非常棒。”然而，对于其他人来说，痛苦是真实存在的。据相关报道，只有1%的使用微服务的企业表示对架构没有任何挑战。运营开销、日志记录和监控挑战以及缺乏技能被认为是最大的挑战。摆脱单一的应用程序架构意味着失去将所有部分粘合在一起的固定工作流。最常见的是，采用微服务架构会增加运营成本，因为IT团队主要负责集成和维护许多不同服务的基础设施。团队必须努力在微服务愿景和使其发挥作用并取得成功的实际需求之间找到平衡点。将整体分解为微服务时，您会面临系统非常分散的风险，开发人员会花费大量时间和精力将服务和工具粘合在一起，并且缺乏可以跨项目工作的通用模式和平台。要真正利用微服务，需要能够构建能够实现一键式设置的“胶水”提供程序。”（迁移到微服务，通常会带来很多运维挑战，因为集成和维护许多不同服务的基础设施责任落在了IT团队身上）LAMP堆栈的出现可以作为一个很好的比较。Linux、ApachewebFreeServer、MySQL和PHP等工具为Web开发开辟了新的可能性。但是当公司围绕WordPress、Drupal和Joomla等项目构建集成工具时，LAMP架构才真正起飞。在真正的微服务方法中，团队只运行他们的小服务需要，仅此而已。但是，这种实施和编排工作超出了许多中小型组织的工程范围。将一个整体拆分为许多更小的、独立的服务，速度和敏捷性有很多优势，但也有很多挑战.微服务架构会增加支持和维护的运营开销，因为每个服务都有自己的语言和要求评论。它还使监控和安全变得更加复杂，因此需要更高级别的自动化和工具。由于现在服务之间的通信是通过网络进行的，因此它对服务发现、消息传递、缓存和容错提出了新的要求，这些要求会给系统带来压力，如果处理不当，可能会导致性能问题。虽然ServiceMesh解决了其中的许多问题，但在没有流量管理的情况下引入ServiceMesh服务会产生其自身的问题，从而导致更严重的性能问题。你可以提前做所有你想做的测试，这会让你对发布的代码有相当大的信心。但是当真正将其投入生产时，您会遇到各种问题，因为您并不真正了解代码在生产中的行为方式。流量管理实际上将部署与发布分离开来。部署意味着拥有新代码、新版本并将其投入生产，但尚未占用任何客户流量。您可以进行冒烟测试、内部测试，这些都在生产中运行。当发布一个版本时，你开始思考：你想为这个新版本的代码带来什么样的流量？如果您有能力将流量控制到非常精细的级别，则可以分段、控制并逐步推出新的代码更改。没有工程资源或技能来将稳定的基础架构与现有开源代码和工具相结合的组织将难以使微服务的好处超过挑战。运营和性能问题也可能困扰那些不就他们的服务（依赖性和版本兼容性）进行沟通的团队，并且在生产失败时不得不拉取已经编写的代码。幸运的是，微服务市场正在起飞。许多公司现在不仅自己生产微服务，还生产无缝连接它们所需的平台、工具和框架。微服务并不适合所有人分布式服务的基础设施已经成熟，但更高的效率只能来自更好的声明式系统，这些系统来自改进的自动化技术和改进的可观察性。这样做可能很棘手，因为没有微服务是完全相同的。他们的任何自定义工作流程就像雪花一样。不同之处在于底层架构以及它如何适应针对不同工作负载的微服务方法的持续开发。设置界限很重要，这样微服务就不会被视为灵丹妙药或有趣项目的分支，因为微服务需要更多的管理。大量构建微服务的开发者可以追溯到2014年到2016年的鼎盛时期，这些开发者一边喝茶一边聊天，决定如何构建新的微服务。那么，如果数十个团队决定创建自己的微服务，会发生什么情况呢？虽然管理是完全可能的，但它牺牲了效率，从而牺牲了优化过程和更好的性能。毫无疑问，微服务是有效的。然而，一个构建良好的整体式单体也可以扩展，在许多场景下仍然是一个不错的选择。例如，运行同一服务或工作者的多个实例不一定需要微服务。也完全有可能创建不可扩展的微服务。因此，在确定解决方案之前首先考虑您面临的问题非常重要。就基础设施和技术支持而言，生态系统现在正接近临界质量。微服务正迅速成为DevOps工具包中的一种工具，可以更好、更深入地利用资源。这反过来又创造了提供额外服务的新空间，进一步实现了声明式和优雅的工作流、工具和平台的潜力。过渡到微服务的业务和流程决策云原生微服务是一个真正令人兴奋的架构演变，尤其是在构建、部署和管理复杂的分布式应用程序方面。然而，大多数围绕微服务的讨论直接与技术相关：持续集成和部署、容器、编排器等。虽然技术实施很重要，但还有一些更重要的事情需要考虑。微服务必须符合组织的目标。开发人员可以构建微服务，但该架构只有在与业务目标保持一致时才有价值。因此，必须提出关键问题，从业务用例、现有团队、技能和职责开始——采用微服务的决定取决于组织的目标和愿景。组织中有实施复杂架构经验的人必须提出一个重要问题并在继续前进之前得到答案：我们是否适合微服务架构？ContainerSolutions的CEO兼联合创始人JamieDobson曾表示，客户开始想要使用微服务作为技术问题的解决方案，实际上通常是组织问题的技术解决方案。评估云原生服务。评估企业对云原生微服务的采用情况，更多的是与企业本身有关，而不是与企业的规模、行业甚至实际技术有关。首先，微服务从决策制定到执行的迁移应该由业务的组织和管理方式驱动：业务模型：软件能否使业务脱颖而出？如果是这样，随着组织需要更多的资源和服务功能，开发团队必须继续发展壮大。基于微服务的架构允许更快的迭代开发，并可用于跨多个团队的工作流程。依赖专有的统一解决方案的组织将不太适合微服务方法。从系统记录管理(ERP)到服务级别协议(SLA)类型的商业软件协议意味着，如果企业选择遵循将他们带入微服务讨论的路径，他们将经历根本性转变。对于完全依赖商业软件平台的组织，实施微服务的成本可能更高。微服务在敏捷性和可扩展性方面所需的工程支持和开销将超出其价值。文化和内部流程：微服务需要一套新的工具和流程，并打破旧的。对于负责管理单体应用的组织来说，突然改变工作流程可能是一个艰难的转变。接受DevOps原则是微服务成功的关键。但是，例如，一个团队可能会拒绝从传统的瀑布方法转向敏捷方法。微软首席云开发布道者BridgetKromhout曾表示，“如果你意识到相关人员有自己的习惯，并且他们可能在不久的将来退休，那么阻力并非完全没有道理，而且他们不会”不喜欢改变一切的想法，他们只是按照自己喜欢的方式看待事物。”微服务的根本复杂性在于应用架构本身：根据架构，每个服务都需要自己的支持团队、工具和基础设施。并非每家公司都在正确的地方采取行动。专家强调，并不是说这个架构是不可能出错的，只是这个过程会更长或更复杂。对于许多具有错误商业动机或文化的组织而言，成本将超过收益。BridgetKromhout再次强调：并非组织中的每个问题都可以通过实施正确的技术解决方案来解决，因为组织是复杂的系统，其中的人的行为方式可能无法预测。那么，微服务什么时候不适合企业呢？敏感行业：某些行业，如金融服务和医疗保健，面临需要与新技术协调的法律、报告和合规要求。可追溯性因素：一家经营了几十年的全球性公司，尤其是员工平均保留时间超过10年的公司，很可能更难适应新架构的根本变化。“停滞不前”的公司：这些是具有长决策链和严格等级制度的风险规避公司。因此，这些组织不太适合，甚至可能抵制采用新的反应式微服务范例所需的快速适应。NewRelic首席站点可靠性工程师JonathanOwens表示，考虑转向容器和微服务架构的组织应该问自己以下问题：您的运营团队为开发人员提供什么产品，以及该产品使用什么抽象层？它适合您的业务，还是容器更适合？容器是否足够好，以至于您愿意更改抽象层，从而更改运营团队提供的整个产品，以便使用它们？您准备好创建新角色来管理这个新抽象了吗？规模和可靠性？没有哪个组织会在一夜之间发生这样的变化。从理想化的新架构到第一个产品部署需要改变许多想法并创建新流程，这并不总是有趣的。寻找具有微服务专业知识的工程师来做出必要的工具和架构决策也很困难。这些专家包括难以捉摸的“全栈开发人员”，他们了解每一层的应用程序：从网络和托管环境，到数据建模、业务逻辑、API和用户界面以及用户体验(UI/UX)。这些人处于一个独特的位置，可以看到技术架构和组织是如何相互关联的。为了实现成功的微服务过渡，组织需要构建可扩展的技术架构，但维护该结构的团队同样重要。这就是为什么许多正在过渡到微服务的组织选择与专门帮助客户使用各种不同架构构建云原生应用程序的专业服务公司合作。这些顾问可以帮助评估组织对微服务的需求和适用性，或指导他们寻找更合适的替代方案。微服务是最合适的吗？对于出于业务原因采用微服务的组织，您可以自信地领导转型。领导项目的团队在组织中占有重要地位，可以开始制定适合现有工作流程的良好实践。团队可以采用服务来驱动应用程序架构的整体发展，并让组织准备好使用更多资源来运行微服务。准备工作需要技巧和人员管理。开发团队的正确服务将定义微服务。该团队的目标是使微服务成为构建其价值并不断优化开发人员体验的“基础”。NetlifyCTODavidCalavera说，评估应用程序的职责是定义微服务应用程序组件的第一步，他是一位微服务资深人士，之前曾在Docker和GitHub上工作。确定与微服务结构相关的应用程序职责的相互依赖性。Connascence是评估应用程序组件和互连的指标。因为两个或多个组件是并发的，如果你改变其中一个，你也必须改变另一个。考虑到这种关系可以更好地评估是否值得拥有不同的微服务，或者是否应该保留单体架构。除了相互依赖性之外，团队还必须记住，将这些组件分离到微服务中会在它们之间引入网络连接——这不可避免地会增加系统的复杂性。应用程序架构开发是个人和团队如何交互和沟通自身以及重叠编排的直接结果。在这一点上很明显，像Kubernetes这样的架构正变得越来越重要。随着更多开发人员的加入以及应用程序变得更加复杂，架构的整体复杂性也会增加。但正如您所见，这些应用程序架构并不适合所有人。“你不想以牺牲理想架构为代价来增加不必要的复杂性，”Calavera警告说。”
