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

微服务是一种优化资源的体系结构方法，这些资源为复杂、快速、分布式基础设施上的大规模服务和软件提供计算、存储和网络。大多数有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上有很多需要迁移到同一技术堆栈的传统应用程序。

微服务的好处

（编辑：ASP站长网）