什么是 微服务

微服务架构是一种方法，其中单个应用程序由许多松散耦合且可独立部署的较小服务组成。

微服务（或微服务架构）是一种云原生架构方法，其中单个应用程序由许多松散耦合且可独立部署的较小组件或服务组成。

这些服务通常

虽然关于微服务的大部分讨论都围绕架构定义和特征展开，但它们的价值可以通过相当简单的业务和组织优势来更普遍地理解：

微服务也可以通过它们 不是 什么来理解。

与微服务架构最常进行的两个比较是单体架构和面向服务的架构 (SOA)。

微服务和单体架构之间的区别在于，微服务由许多较小的、松散耦合的服务组成一个应用程序，而不是大型、紧密耦合的应用程序的单体方法

微服务和 SOA 之间的区别可能不太清楚。

虽然可以在微服务和 SOA 之间进行技术对比，尤其是围绕 企业服务总线 (ESB) 的角色，但更容易将差异视为 范围之一 。

SOA 是企业范围内的一项努力，旨在标准化 组织中 所有 Web 服务相互通信和集成的方式，而微服务架构是特定于应用程序的。

微服务可能至少与开发人员一样受高管和项目负责人的欢迎。

这是微服务更不寻常的特征之一，因为架构热情通常是为软件开发团队保留的。

原因是微服务更好地反映了许多业务领导者希望构建和运行他们的团队和开发流程的方式。

换句话说，微服务是一种架构模型，可以更好地促进所需的操作模型。

在IBM 最近对 1,200 多名开发人员和 IT 主管进行的一项调查中，87% 的微服务用户同意微服务的采用是值得的。

也许微服务最重要的一个特点是，由于服务更小并且可以独立部署，它不再需要国会的法案来更改一行代码或在应用程序中添加新功能。

微服务向组织承诺提供一种解毒剂，以解决与需要大量时间的小改动相关的内心挫败感。

它不需要博士学位。

在计算机科学中看到或理解一种更好地促进速度和敏捷性的方法的价值。

但速度并不是以这种方式设计服务的唯一价值。

一种常见的新兴组织模型是围绕业务问题、服务或产品将跨职能团队聚集在一起。

微服务模型完全符合这一趋势，因为它使组织能够围绕一个服务或一组服务创建小型、跨职能的团队，并让他们以敏捷的方式运行。

微服务的松散耦合还为应用程序建立了一定程度的故障隔离和更好的弹性。

服务的小规模，加上清晰的边界和沟通模式，使新团队成员更容易理解代码库并快速为其做出贡献——在速度和员工士气方面都有明显的好处。

在传统的 n 层架构模式中，应用程序通常共享一个公共堆栈，其中一个大型关系数据库支持整个应用程序。

这种方法有几个明显的缺点——其中最重要的是应用程序的每个组件都必须共享一个公共堆栈、数据模型和数据库，即使对于某些元素的工作有一个清晰、更好的工具。

它造成了糟糕的架构，并且对于那些不断意识到构建这些组件的更好、更有效的方法是可用的开发人员来说是令人沮丧的。

相比之下，在微服务模型中，组件是独立部署的，并通过 REST、事件流和消息代理的某种组合进行通信——因此每个单独服务的堆栈都可以针对该服务进行优化。

技术一直在变化，由多个较小的服务组成的应用程序更容易和更便宜地随着更理想的技术发展而变得可用。

使用微服务，可以单独部署单个服务，但也可以单独扩展它们。由此产生的好处是显而易见的：如果做得正确，微服务比单体应用程序需要更少的基础设施，因为它们只支持对需要它的组件进行精确扩展，而不是在单体应用程序的情况下对整个应用程序进行扩展。

微服务的显着优势伴随着重大挑战。

从单体架构到微服务意味着更多的管理复杂性——更多的服务，由更多的团队创建，部署在更多的地方。

一项服务中的问题可能会导致或由其他服务中的问题引起。

日志数据（用于监控和解决问题）更加庞大，并且在服务之间可能不一致。

新版本可能会导致向后兼容性问题。

应用程序涉及更多的网络连接，这意味着出现延迟和连接问题的机会更多。

DevOps 方法可以解决其中的许多问题，但 DevOps 的采用也有其自身的挑战。

然而，这些挑战并没有阻止非采用者采用微服务——或者采用者深化他们的微服务承诺。

新的 IBM 调查数据 显示，56% 的当前非用户可能或非常可能在未来两年内采用微服务，78% 的当前微服务用户可能会增加他们在微服务上投入的时间、金钱和精力

微服务架构通常被描述为针对 DevOps 和持续集成/持续交付 (CI/CD) 进行了优化，在可以频繁部署的小型服务的上下文中，原因很容易理解。

但另一种看待微服务和 DevOps 之间关系的方式是，微服务架构实际上 需要 DevOps 才能成功。

虽然单体应用程序具有本文前面讨论过的一系列缺点，但它们的好处是它不是一个具有多个移动部件和独立技术堆栈的复杂分布式系统。

相比之下，鉴于微服务带来的复杂性、移动部件和依赖项的大量增加，在部署、监控和生命周期自动化方面没有大量投资的情况下使用微服务是不明智的。

虽然几乎任何现代工具或语言都可以在微服务架构中使用，但有一些核心工具已成为微服务必不可少的边界定义：

微服务的关键要素之一是它通常非常小。

（没有任意数量的代码可以确定某物是否是微服务，但名称中的“微”就在那里。）

当Docker在 2013 年迎来现代容器时代时，它还引入了与微服务最密切相关的计算模型。

由于单个容器没有自己的操作系统的开销，它们比传统的虚拟机更小更轻，并且可以更快地启动和关闭，使其成为微服务架构中更小、更轻的服务的完美匹配.

随着服务和容器的激增，编排和管理大量容器很快成为关键挑战之一。

Kubernetes是一个开源容器编排平台，已成为最受欢迎的编排解决方案之一，因为它做得非常好。

微服务通常通过 API 进行通信，尤其是在首次建立状态时。

虽然客户端和服务确实可以直接相互通信，但 API 网关通常是一个有用的中间层，尤其是当应用程序中的服务数量随着时间的推移而增长时。

API 网关通过路由请求、跨多个服务扇出请求以及提供额外的安全性和身份验证来充当客户端的反向代理。

有多种技术可用于实现 API 网关，包括 API 管理平台，但如果使用容器和 Kubernetes 实现微服务架构，则网关通常使用 Ingress 或最近的Istio 来实现。

虽然最佳实践可能是设计无状态服务，但状态仍然存在，服务需要了解它。

虽然 API 调用通常是为给定服务初始建立状态的有效方式，但它并不是保持最新状态的特别有效方式。

不断的轮询，“我们到了吗？” 保持服务最新的方法根本不切实际。

相反，有必要将建立状态的 API 调用与消息传递或事件流结合起来，以便服务可以广播状态的变化，而其他相关方可以监听这些变化并进行相应的调整。

这项工作可能最适合通用消息代理，但在某些情况下，事件流平台（例如Apache Kafka）可能更适合。

通过将微服务与事件驱动架构相结合，开发人员可以构建分布式、高度可扩展、容错和可扩展的系统，可以实时消费和处理大量事件或信息。

无服务器架构将一些核心云和微服务模式得出其合乎逻辑的结论。

在无服务器的情况下，执行单元不仅仅是一个小服务，而是一个函数，它通常可以只是几行代码。

将无服务器功能与微服务分开的界限很模糊，但通常认为功能比微服务还要小。

无服务器架构和功能即服务 (FaaS)平台与微服务的相似之处在于，它们都对创建更小的部署单元和根据需求精确扩展感兴趣。

微服务不一定与云计算完全相关，但它们如此频繁地结合在一起有几个重要原因——这些原因超越了微服务成为新应用程序的流行架构风格以及云成为新应用程序的流行托管目的地的原因。

微服务架构的主要优势之一是与单独部署和扩展组件相关的利用率和成本优势。

虽然这些优势在一定程度上仍然存在于本地基础设施中，但小型、独立可扩展的组件与按需、按使用付费的基础设施相结合是可以找到真正成本优化的地方。

其次，也许更重要的是，微服务的另一个主要好处是每个单独的组件都可以采用最适合其特定工作的堆栈。

当您自己管理堆栈扩散时，可能会导致严重的复杂性和开销，但是将支持堆栈作为云服务使用可以大大减少管理挑战。

换句话说，虽然推出自己的微服务基础设施并非不可能，但不可取，尤其是刚开始时。

在微服务架构中，有许多常见且有用的设计、通信和集成模式有助于解决一些更常见的挑战和机遇，包括：

例如，在桌面上使用的应用程序将具有与移动设备不同的屏幕尺寸、显示和性能限制。

BFF 模式允许开发人员使用该界面的最佳选项为每个用户界面创建和支持一种后端类型，而不是尝试支持适用于任何界面但可能会对前端性能产生负面影响的通用后端。

例如，在电子商务网站上，产品对象可能通过产品名称、类型和价格来区分。

聚合是应被视为一个单元的相关实体的集合。

因此，对于电子商务网站，订单将是买家订购的产品（实体）的集合（集合）。

这些模式用于以有意义的方式对数据进行分类。

在微服务架构中，服务实例会因伸缩、升级、服务故障甚至服务终止而动态变化。

这些模式提供了发现机制来应对这种短暂性。

负载平衡可以通过使用 健康 检查和服务故障作为重新平衡流量的触发器来使用服务发现模式。

适配器模式的目的是帮助翻译不兼容的类或对象之间的关系。

依赖第三方 API 的应用程序可能需要使用适配器模式来确保应用程序和 API 可以通信。

这个色彩缤纷的名字指的是藤蔓（微服务）如何随着时间的推移慢慢地超越并扼杀一棵树（单体应用程序）。

虽然有很多模式可以很好地完成微服务，但同样数量的模式可以很快让任何开发团队陷入困境。

其中一些——改写为微服务“不要”——如下：

一旦应用程序变得太大且难以轻松更新和维护，微服务是一种管理复杂性的方法。

只有当您感觉到单体架构的痛苦和复杂性开始蔓延时，才值得考虑如何将该应用程序重构为更小的服务。

在你感受到那种痛苦之前，你甚至没有真正拥有需要重构的单体。

尝试在没有 a) 适当的部署和监控自动化或 b) 托管云服务来支持您现在庞大的异构基础设施的情况下进行微服务，会带来很多不必要的麻烦。

省去你自己的麻烦，这样你就可以把时间花在担心状态上。

最好倾向于更大的服务，然后只在它们开始开发微服务解决的特征时才将它们分开——即部署更改变得困难和缓慢，通用数据模型变得过于复杂，或者不同部分服务有不同的负载/规模要求。

微服务和 SOA 之间的区别在于，微服务项目通常涉及重构应用程序以便更易于管理，而 SOA 关注的是改变 IT 服务在企业范围内的工作方式。

一个演变成 SOA 项目的微服务项目可能会因自身的重量而崩溃。

你最好从一个你可以处理的速度开始，避免复杂性，并尽可能多地使用现成的工具。

无服务器架构（Serverless）是一种将应用与基础设施彻底分离的架构理念，开发人员无需关心基础设施的运维工作，只需专注于应用逻辑的开发，真正实现了弹性伸缩与按需付费。当前各大云服务商和头部互联网企业的内部业务 Serverless 化升级改造已经开始小范围试水；中小企业基于 Serverless 的业务应用也初见端倪，已然可见初具规模的企业级应用，未来可期。Serverless 生态已初具规模，可以预见，Serverless 将成为下一代云计算服务形态的趋势。

在此背景下， 云函数（SCF）、弹性微服务（TEM）和弹性容器服务（EKS）联合其他相关产品，在 2021 年 Serverless 平台技术能力评估中，共同获得国内首批 Serverless 平台技术能力最高先进级认证。

今年 7 月，在中国信息通信研究院、中国通信标准化协会联合主办的 “2021 可信云大会” 上， 腾讯云拿下了 5 项大奖和 10 项可信云认证，在云存储、Serverless 等各细分领域评测中，获得 54 项可信云认证，数量位居中国云厂商第一 。腾讯云云函数（SCF）、弹性微服务（TEM）和弹性容器服务（EKS）深度参与了此次 Serverless 标准制定和实施过程，腾讯云的 Serverless 产品矩阵所提供的平台技术能力也得到了同行的一致认可。

通过本次 Serverless 标准，为大家带来以下几方面关于 Serverless 发展趋势的解读：

当我们把 Serverless 理念和这些产品结合时，Serverless 化的文件系统（CFS）、数据库（TDSQL-C）、网关（API Gatgeway）和中间件（TDMQ）等可大幅度降低 Serverless 应用的开发和运维成本，让开发者真正聚焦于业务的核心能力，把核心的研发力量和IT投资最大化企业的核心差异化竞争力。通过最终的需求驱动，我们可以预见到，各个云服务产品的 Serverless 化或许是未来云计算发展的必经之路。

过去场景化的 FaaS 是 Serverless 较为主流的应用形态，落地案例也以轻量级的站点、SSR 和云上“云上粘合剂”居多。在本次 Serverless 标准制定过程中，对于如何评估企业实际的 Serverless 落地形式大家展开了丰富的讨论和交流。我们认为 Serverless 的应用形态可以是 FaaS、微服务甚至是单体应用；运行环境可以是原生的运行时，也可以是容器镜像；具体落地时，可以用来对外提供 API 接口，也可以用来运行 音视频转码、直播推流 等计算任务，还可以用来完成 站点压测、AI 推理 等任务。

但是现有存量系统的 Serverless 化无法一蹴而就，这是一个不断设计和矫正的过程，应用 Serverless 化也需要经历迁移、优化和云原生架构改造的几个阶段，不同阶段之间需要有一个较为平滑的切换过程，借助于云函数的 Web Function 的功能可以让迁移过程更加平滑，只有实际负载运行在 Serverless 上之后，才能基于生产环境的实际运行结果、采集定量的指标持续进行 Serverless 应用的优化和云原生改造，进一步发挥出 Serverless 的价值。

当构建应用所依赖的服务逐渐向云上迁移的时候，开发环境也进一步“云”化，和本地开发相比也面临一些新的挑战，比如代码生效时间、本地测试、远程调试和离线开发等等，这些都是影响开发者效率的关键环节。在本次的 「Serverless 平台技术能力」标准中，单独把对于工具链的支持作为衡量 Serverless 平台技术能力的重要维度之一。一个成熟的 Serverless 开发者平台需要能够提供比较友好的IDE支持，让开发者使用熟悉的开发工具进行 Serverless 应用的开发，降低开发者的切换成本；除此之外从本地或者远程测试的时候，需要有良好的工具支持，可以方便地发起调用，触发应用执行并快速返回结果，当结果不符合预期的时候也需要有一系列监控、日志等排障手段帮助开发者快速定位问题。

作为 Serverless 社区最流行的一站式开发者工具， Serverless Framework 拥有百万级别的活跃应用程序以及 50000+ 的日下载量。Serverless Framework 早在 2019 年就已经和腾讯达成了大中华区独家的战略合作，和腾讯云的云函数等 Serverless 产品深度集成，同时社区也有大量开箱即用的插件和模板，帮助开发者快速上手 Serverless 应用开发。除此之外，云开发也是国内最大的微信小程序应用开发平台， 四川天府 健康 通、深圳机场智慧航旅服务等小程序应用都是运行在腾讯云的 Serverless 平台之上。

云函数（Serverless Cloud Function，SCF）是腾讯云为企业和开发者们提供的无服务器执行环境，帮助您在无需购买和管理服务器的情况下运行代码。只需编写核心代码并设置代码运行的条件，即可在腾讯云基础设施上弹性、安全地运行代码。

只需简单修改监听端口，即可将目前流行的 Node.js 框架直接部署上云，享受 Serverless 技术带来的免运维、低成本、按需扩缩容的众多优势。

突破传统 FaaS 形态产品的执行时长的限制， 首家支持运行长达 24 小时的长时任务的 FaaS 产品 ，支持体积较大的音视频文件处理、直播推流、数据分析等多种场景。

业界首发支持分配 120GB(122,880MB) 大内存环境，可以更加轻松地处理具有更高内存或更密集计算需求的工作负载，如音视频处理、大数据分析等。

通过 Web Function、容器化镜像等方式平滑把应用迁移至云函数之上，支持托管 H5 页面、API、SSR 应用、小程序等多种形态的应用形式，缩短研发周期，快速收集市场反馈从而加速产品迭代。

无需运维虚拟机或者其他计算集群，利用云函数提供的极致弹性、按量计费等特性，高效、低成本地进行音视频的录制、转码、混流、剪辑和推流等操作，让企业聚焦于音视频处理逻辑本身，从而不断提升内容质量，优化视听体验。

可以通过触发器连接其他的云服务，如对象存储（COS）、日志服务（CLS）等其他服务，当上游的数据发送变化的时候自动触发函数执行计算逻辑，典型的使用场景包括：CDN 刷新和预热、中间件消息转存、文件备份等。

支持定时、消息队列等多种形式触发函数执行输出处理逻辑，进行数据采集、数据清洗、ETL 等数据处理操作，处理之后的数据可以直接存储至下游的数据仓库、业务数据库或者 BI 分析系统等。

腾讯云弹性微服务 (Tencent Cloud Elastic Microservice, TEM) 是面向微服务应用的 Serverless PaaS 平台，实现 Serverless 与微服务的完美结合，应用零改造上云，按量付费，免运维，提供开箱即用的微服务应用托管服务。

弹性微服务拥抱开源，支持 Spring Cloud 等微服务应用零改造上云，提供应用运行托管、服务注册发现、微服务治理、多维度监控等能力，满足 Consul、Eureka 等多种注册中心需求。弹性微服务帮助您创建和管理云资源，并提供秒级弹性伸缩，您可按需使用、按量付费，极大降低资源和运维成本，让您充分聚焦企业核心业务逻辑，助力业务成功。

弹性微服务通过应用托管、服务注册与发现、服务治理、调用链与多维度监控等功能力，为客户提供开箱即用的微服务解决方案。帮助企业用户快速构建微服务应用，大幅提升运维效率，降低服务治理的复杂度与技术门槛，让企业聚焦核心业务本身，助力客户成功。

在业务呈现潮汐特性、突发流量等场景下，容易出现访问响应超时、错误率提升等问题。腾讯云弹性微服务提供秒级弹性伸缩能力，帮助企业客户轻松应对流量高峰。

腾讯云弹性微服务帮助客户持续集成与交付，实现微服务应用快速迭代。从代码开发到应用交付，弹性微服务提供 IDE 插件、灰度发布等多发布策略的能力，助力企业客户快速验证业务价值。

弹性容器服务 EKS（Elastic Kubernetes Service）是腾讯云容器团队的推出的 Serverless 化 Kubernetes 服务 ，无须用户购买节点，直接部署工作负载。其完全兼容原生 Kubernetes，支持使用原生方式购买及管理资源，按照容器真实使用的资源量计费。

无论是自建 K8s 集群，还是腾讯云 TKE 托管集群，只要网络互通，即可通过部署 EKS 虚拟节点的方式，几乎无成本扩展集群资源池。在扩容 Pod 时可自动或手动快速将 Pod 调度到「虚拟节点」对应的腾讯云公有云资源上。

相比传统的通过扩缩服务器去调度资源（流程重，耗时久），虚拟节点提供一种直接调度 Pod 的能力，可以更快、更高效的弹性。

使用弹性容器服务 EKS 来运行微服务，免除用户对计算节点的运维工作。服务可根据负载情况自动伸缩，使用最合理的资源量来承载应用，降低资源使用成本。

使用弹性容器服务 EKS 运行离线计算任务，只需准备容器镜像，即可快速部署任务负载。另外，弹性容器服务 EKS 仅收取任务真实运行时间所使用算力的费用，任务结束 Pod 自动释放即结束计费。

弹性容器服务 EKS 支持使用 CPU、GPU 以及 vGPU 来运行在线推理服务，丰富的资源规格和弹性伸缩的负载，使运行服务更高效、更经济。

立即体验腾讯云 Serverless Demo，领取 Serverless 新用户礼包 腾讯云 Serverless 新手体验

---