云原生

云原生（Cloud Native）这个概念最早是由 Pivotal 公司的 Matt Stine 提出的。
发展至今，云原生架构已然成为互联网行业的技术热点，并在很大程度上推动了 IT 成本的降低和企业的发展。

在云原生架构之前（即传统非云原生应用），底层平台负责向上层应用服务提供基本运行资源，而应用则需要满足业务需求和非业务需求，比如 PHP 开发中是采用 Openstack 或者 VMware vSphere 等虚拟化技术为 LMAP（Linux+MySQL+ Apache+PHP）应用提供硬件资源。

在 SOA、微服务时代，部分功能会以后端服务的方式存在，在应用中被简化为面向客户端的调用代码，然后应用将这些功能连同自身的业务实现代码一起打包，比如 Java 的 jar 包。
而云的出现，不但提供了各种资源，还提供了基础设施、中间件等各种能力，从而使得应用专注于业务需求的实现。

随着云原生技术理念在行业内进一步实践发展，云原生架构完成了 IT 架构在云计算时代的进化升级。
对企业而言，新旧 IT 架构的转型与企业数字化的迫切需求也为云原生技术提供了很好的契机，使得云原生技术在行业内的应用持续深化。

云计算的前世今生

云原生和云计算有着千丝万缕的联系，因此在介绍云原生之前，我们先看看过去几十年间云计算的发展演进历程，它大致分为三个阶段：虚拟化的出现、虚拟化在云计算中的应用以及容器化的出现。

阶段1：虚拟化技术

云计算与计算机相伴而生，起源可以追溯到 60 多年前，但直到 2000 年前后，云计算的基础——虚拟化技术才逐渐发展成熟。

那什么是虚拟化技术呢？具体来说，就是表示将计算机资源划分成逻辑组的技术。
注意，由此生成的仅仅是一个逻辑的视图。通过虚拟化技术，我们就可以在同一台物理机器上运行多个虚拟机，进而发挥物理硬件的最大效用。

阶段2：虚拟机的市场化应用

在虚拟化技术成熟之后，云计算市场才真正出现。2006 年，亚马逊 AWS 公开发布 S3 存储服务、SQS 消息队列及 EC2 虚拟机服务，正式宣告了现代云计算的到来。
针对云服务消费者的不同需求，主要有三种云服务模型： IaaS、PaaS 和 SaaS（如下图）。

• IaaS（Infrastructure-as-a-Service，基础设施即服务），是云服务的最底层，主要提供一些基础资源。
• PaaS（Platform-as-a-service，平台即服务），提供软件部署平台，其抽象了硬件和操作系统细节，使得应用可以无缝地扩展。开发者只需要关注自己的业务逻辑，不需要关注底层。
• SaaS（Software-as-a-service，软件即服务），是指软件的开发、管理、部署都交给第三方，提供商会为企业搭建信息化所需要的所有网络基础设施及软件、硬件运作平台。企业不需要关心技术问题，拿来即用。

阶段3：容器化和容器编排的兴起

容器化本质上就是虚拟化的改进版本，这种技术允许多个应用程序驻留在同一个服务器中。不过这二者之间也是有区别的，虚拟化是在硬件级别分离应用程序，而容器化则是在操作系统级别分离硬件程序。

我们知道Docker 对云计算领域产生了深远的影响，从虚拟机到容器，整个云计算市场发生了一次重大变革。
后续随着 Kubernetes 的成熟，以及它和 Docker 的融合，云计算进入 Kubernetes 时代。
PaaS 技术的主流路线也逐渐过渡到 “Kubernetes + Docker”，并于 2018 年左右开始占据统治地位。

总体来说，在这过去的二十年间，云计算几乎重新定义了整个行业的格局。
越来越多的企业开始降低对 IT 基础设施的直接资本投入，不再倾向于维护自建的数据中心，而是开始通过上云的方式来获取更强大的计算和存储能力，这使得公司（尤其是初创公司）可以更快地实践业务想法并迅速推送到市场。

云原生到底是什么

你可以对比篮球比赛来理解，篮球比赛分为上半场和下半场，在这里云原生就是云计算的 “下半场”。
在这“下半场”中，是否上云已经很少被提及了，因为云的概念已经渗入到各行各业了，特别是 2017 年以后，云计算技术已然成为企业发展“战术”的一部分了。

近几年，云原生不仅火而且还有点被过度消费，很多软件都打着云原生的旗号。
但究其本质，云原生本身并不能称为是一种架构，它首先是一种基础设施，运行在其上的应用称作云原生应用，只有符合云原生设计哲学的应用架构才叫云原生应用架构。

鉴于云原生的重要性，在讲解云原生的具体定义之前，我们首先介绍下云原生出现的背景以及它背后的诉求，这样你才能知其然并知其所以然。

云原生出现的背景

移动互联网时代是业务高速发展的时期，不同于传统的应用，移动互联网提供了新的用户体验，即以移动端为中心，通过软件对各行各业进行渗透。
在巨大的用户基数下，快速变更和不断创新的需求给软件开发方式带来巨大推动力，传统软件开发方式受到巨大挑战。
面对业务的快速迭代以及团队规模的不断扩大，降低沟通协作成本并加快产品的交付速度、为用户呈现更好的体验是各个互联网公司都在努力的方向。

在这样的背景下，微服务和云原生的概念开始流行。
系统架构与团队的组织架构密切相关（如下图所示），其实半个世纪前提出的康威定律——组织内人与人的沟通方式决定了他们如何参与系统设计——也早就说明了这一点，这奠定了微服务架构的理论基础。
通过服务的拆分，每个小团队对应一个服务，增加了内聚性，减少了开会的频次，提高了沟通效率。
快速交付意味着更新的频次也高了，更新也容易造成服务的故障问题，这时更新与高可用之间需要权衡。
而云原生架构的基础设施和工具可以减少更新导致的故障问题，保证服务的高可用。

云原生解决了哪些问题

企业在数字化转型中普遍面临 IT 系统架构缺乏弹性、业务交付周期长、运维效率低、高可靠性低等痛点和挑战。具体来说，主要有以下的诉求：

• 产品快速迭代，更快的上线速度；
• 系统的高可用，故障时能够自动恢复与回滚；
• 快速解决问题，细致的故障探测和发现；
• 避免雪崩，故障时能自动隔离；
• 系统的弹性伸缩，简便快速的水平扩容。

将软件迁移到云上是应对这些挑战的自然演化方式，在过去二十年间，IaaS 、PaaS 和 SaaS 让应用的构建和部署越来越轻、越来越快，而底层基础设施和平台则越来越强大，以不同形态的云对上层应用提供强力支撑。
云计算的第一个浪潮是关于成本和业务敏捷性，这使得云计算的基础设施更加廉价。

很多企业倾向于使用微服务架构来开发应用。微服务开发快速，职责单一，能够更快速地被客户所采纳。
同时，这些应用能够通过快速迭代的方式得到进化，并赢得客户的认可。
而云原生可以打通微服务开发、测试、部署、发布的整个流程环节，所以企业可以通过云原生的一系列技术，如基于容器的敏捷基础设施、微服务架构、DevOps 等解决企业面临的那些 IT 痛点，满足其背后的诉求。

不断更新的云原生定义

自从云原生被提出以来，云原生的定义就一直在持续地更新，这也说明了云原生的概念随着技术的发展而不断地被深刻认知。

作为云原生应用的提出者，Matt Stine 于 2015 年在其《迁移到云原生应用架构》一书中探讨了云原生应用架构的几个主要特征：符合 12 因素应用、面向微服务架构、敏捷架构、基于 API 的协作和抗脆弱性。

Pivotal公司推出了 Pivotal Cloud Foundry 云原生应用平台和 Spring 开源 Java 开发框架，成为云原生应用架构中的先驱者和探路者。
在 Pivotal 的官方网站上，对云原生的介绍主要包括 4 个要点：DevOps、持续集成、微服务架构和容器化（如下图所示）。

云原生计算基金会（CNCF）最开始（2015 年成立之初）对云原生的定义则包含应用容器化、面向微服务架构和应用支持容器的编排调度这三个方面。

发展到 2018 年，云原生生态不断壮大， Cloud Native Landscape 中的云原生项目涉及领域也不断变大，同时 CNCF 基金会中的会员以及容纳的项目越来越多。

显然之前的定义已经和当前的景观图不符，为了实现云原生生态的发展，CNCF 于 2018 年 6 月通过了对云原生重新定义的提案，v1.0 版本定义如下：

云原生技术有利于各组织在公有云、私有云和混合云等新型动态环境中，构建和运行可弹性扩展的应用。云原生的代表技术包括容器、服务网格、微服务、不可变基础设施和声明式API。

这些技术能够构建容错性好、易于管理和便于观察的松耦合系统。结合可靠的自动化手段，云原生技术使工程师能够轻松地对系统作出频繁和可预测的重大变更。

云原生计算基金会（CNCF）致力于培育和维护一个厂商中立的开源生态系统，来推广云原生技术。我们通过将最前沿的模式民主化，让这些创新为大众所用。

这个定义不同于以往的严谨定义，并未深挖云原生的实质。CNCF 是一个厂商中立的组织，因此 CNCF 主要目的在于形成云原生工具生态，更加侧重工程实践。

上面定义所述的五个代表技术，基本都和 k8s 有关联。k8s 是云原生基金会的第一个孵化项目，事实上是在围绕 k8s 建立云原生生态。
其中，容器是 k8s 的底层引擎；服务网格则是建立在 k8s 上的针对请求的扩展功能；不可变基础设施是现代运维的基石；
声明式 API 是 k8s 的编码方式；微服务是一种软件架构，云原生中的微服务扩大了云原生的版图。

云原生，并不是一种具体的技术或者框架，而是一类思想的集合，其中的技术要点包括服务网格、微服务和容器化（如容器化 Docker）等；
管理要点则包括 DevOps、康威定律等。因此，可以说云原生在一定层面上重构了互联网产品的开发模式。

云原生的基础架构

云原生中既有指导云原生开发的方法论，也包含实践的具体技术。
我们介绍过CNCF 给出的云原生定义中包括微服务、容器、服务网格、不可变基础设施和声明式 API 等代表技术，构建云原生应用就主要靠这些关键技术。
下面我们就来具体介绍下这 5 个关键技术。

微服务

单体应用开发简单，但随着业务复杂度的提升，单体应用的弊端逐渐显现，开发效率和系统应用的可扩展性等方面出现严重问题。
微服务架构的出现就解决了这个问题，它根据领域模型将巨大的单体分成界限清晰的微服务，并保持每个服务独立可以迭代（如下图）。

相比传统的单体应用架构，微服务架构具有服务高度自治、高效迭代、易于扩展和支持多语言编程等优点。

但是从另一个角度来看，微服务架构的灵活、开发的敏捷也带来了一些新的问题，如数量众多的微服务运维、分布式系统固有的复杂性，以及分布式事务、服务之间的调用等。
单体应用可能只需部署至“一个”应用服务器集群，而微服务架构则需要开发维护“很多个”独立的服务，并且还可能需要支持多种语言和环境，这当中的构建、测试、部署和运行成本提高了不少。

容器

为了解决微服务架构下大量应用部署的问题，由此引入了容器。
容器是一种轻量级的虚拟化技术，能够在单一主机上提供多个隔离的操作系统环境，通过一系列的命名空间隔离进程，每个容器都有唯一的可写文件系统和资源配额。

容器化功能比较强大，不仅能解决虚拟机所能够解决的问题，同时也能够解决虚拟机由于资源要求过高而无法解决的问题。
它具有的特点主要包括：隔离应用依赖、创建应用镜像并进行复制、创建容易分发的即启即用的应用、支持实例简单、快速地扩展等。

Docker 是当前流行的开源应用容器引擎，基于 Docker 容器化技术，用户可以将微服务及其所需的所有配置、依赖关系和环境变量打包成容器镜像，并轻松移植到全新的安装了 Docker 的服务器节点上，运维人员无须关心底层操作系统，且无须重新配置环境，这使得容器成为部署单个微服务的最理想工具。

但仅仅有容器还是不够的，毕竟人肉部署成本高且易出错。

因此容器技术又被分为了运行和编排两层。运行层主要是指容器的基础设施，包括存储、网络、CPU 等。
编排层主要是容器集群的管理，包括容器调度、服务注册与发现、资源的管理等；其相关工具有 Kubernetes 、Swarm 等，用以解决容器的管理和调度问题。
其中，由 Google 开源的 Kubernetes 目前基本算是统一了容器编排的市场，实现了容器集群的自动化部署、扩缩容和维护等功能。

就这样 Kubernetes 与 Docker 相互配合、相辅相成，其中 Docker 是作为 Kubernetes 内部使用的低级别组件，而 Kubernetes 又可以高效管理调度 Docker 集群。

服务网格

微服务架构实践主要有侵入式架构和非侵入式架构两种实现形式。
侵入式架构是指服务框架嵌入程序代码，开发者组合各种组件，如 RPC、负载均衡、熔断等，实现微服务架构。
非侵入式架构则是以代理的形式与应用程序部署在一起，代理接管应用程序的网络且对应用程序透明，这时开发者只需要关注自身业务即可，这种方式以服务网格（Service Mesh） 为代表。

服务网格产品的存在和具体工作模式，对运行于其上的云原生应用来说是透明无感知的，
但是在运行时这些能力都动态赋能给了应用，从而帮助应用在轻量化的同时依然可以继续提供原有的功能（如下图所示）。

服务网格的一般架构

服务网格提供了分布式环境中几大核心问题的解决方案，比如服务间通信、限流、统一认证等功能，使得微服务的开发者更加关注业务，降低了微服务的门槛。

服务网格目前的发展也比较火热，有多款开源软件，Linkerd 最早加入 CNCF，其他还有 Istio、Envoy、Dubbo Mesh 等。
同时，为了让服务网格有更好的底层支撑，我们又将其运行在 Kubernetes 上。
Kubernetes 对于资源的动态调度有极强的能力，用户可以快速编排出复杂环境、复杂依赖关系的应用程序，同时开发者又无须过分关心应用程序的监控、扩展性、服务发现和分布式追踪这些烦琐的事情，从而更专注于程序开发。

不可变基础设施与 DevOps

Chad Fowler 于 2013 年提出了不可变基础设施(Immutable Infrastructure) 的构想，主要强调基础设施的状态性质。
具体来说：一旦创建基础设施的实例，其将会变成只读状态，如果后续需要修改和升级，则需要使用新的实例替换旧实例。
这种模式使得 DevOps 更加容易实践，可以为运维人员减少配置管理的负担。

而 DevOps 是一组过程、方法与系统的统称，用于促进开发、技术运营和质量保障（QA）部门之间的沟通、协作与整合。
DevOps 在一定程度上可以解决开发者与运维人员之间的协作问题，增强开发团队与运维部门之间的沟通和交流。

DevOps 是开发、运维和 QA 三者的交集

你可能对精益软件开发中的敏捷、Scrum 不陌生，Scrum 是敏捷的一种具体实践，而 DevOps 则很好地补充了敏捷。
DevOps 的目标是缩短开发周期，增加部署频率，更可靠地发布升级系统应用。
DevOps 和云原生架构的结合能够实现精益产品开发流程，帮助软件产品及其开发持续改进，适应快速变化的市场，从而为企业提供更小的试错成本。

声明式 API

声明式设计（Declarative) 是指通过向工具描述自己想要让事物达到的目标状态，然后由这个工具自己内部去计算如何令这个事物达到目标状态。
简言之，声明式设计中，描述的是目标状态，即 How；与之相对的是过程式设计（Imperative），所描述的是一系列的动作，即 What。
这一系列的动作如果被正确执行，最终结果就是这个事物达到了你期望的目标状态。

声明式 API 和命令式 API 是两种不同的编程方式：在声明式 API 中，你声明了系统要执行的操作，然后系统将不断向该状态驱动；
而在命令式 API 中，你可以直接发出服务器要执行的命令，如 “运行实例”“停止实例”等。
SQL 就是一种常见的声明式编程语言，开发者可以自行指定获取所需的数据。
在声明式语言中，描述一般为“创建三个 Web 实例的集群”，而不是把创建 Web 实例的命令运行三次组成一个集群。

声明式设计是一种设计理念，同时也是一种工作模式，它使得你的系统更加健壮。
分布式系统环境可能会出现各种不确定的故障，面对这些组件故障，如果使用声明式 API ，查看对应组件的 API 服务器状态，再确定需要执行的操作即可；
而使用命令式 API 时，恢复组件则会变得比较困难。

云原生应用的特征：云原生与“12 因素”

Heroku于 2012 年提出“12因素”（12-Factors）的云应用设计理念，（HeroKu 曾于2009 年推出公有云 PaaS），这些设计理念指导开发者利用云平台来开发易于维护、更具可靠性和扩展性的云原生应用。

方法论和核心思想

“12 因素”适用于任何语言开发的后端应用，并提供了很好的方法论和核心思想。“12 因素”为构建 SaaS 应用提供了如下的方法论：

• 使用声明式格式来搭建自动化，从而使新的开发者花费最少的学习成本来加入这个项目；
• 和底层操作系统保持简洁的契约，在各个系统中提供最大的可移植性；
• 适合在现代的云平台上部署，避免对服务器和系统管理的额外需求；
• 最小化开发和生产之间的分歧，持续部署以实现最大灵活性；
• 可以在工具、架构和开发实践不发生重大变化的前提下实现扩展。

编码、部署和运维原则

“12 因素”理论适用于以任意语言编写，并使用任意后端服务（数据库、消息队列、缓存等）的应用程序，它是关于如何编码、部署和运维的原则。
这些是软件交付生命周期里最常见的场景，为多数开发者和 DevOps 整合团队所熟知（如下图）。

"12因素"的内容

• 编码有关：基准代码、构建发布运行、开发/生产环境等价 ，与源码管理相关；
• 部署有关：显式依赖、配置、独立进程、后端服务、端口绑定，与微服务该如何部署以及如何处理依赖相关；
• 运维原则：并发、易处理、日志、管理进程，与如何简化微服务的运维相关。

具体内容

12 因素的具体内容如下所示。

• Codebase：基准代码。一份基准代码，多份部署。在统一的代码库中为代码配置、测试和脚本部署建立独立的项目和模块。
• Dependencies：显式声明依赖关系。通过 Bundler、NPM 等工具隔离依赖性，不依赖于部署环境。
• Config：在环境中存储配置。通过操作系统级的环境变量将配置信息或其他可能存在的不同信息（如开发环境、预生产环境、生产环境）应用到各个部署环境中。
• Backing services：把后端服务当作附加资源。数据库、缓存等均被作为附加资源在不同环境中被同等调用，每个不同的后端服务都是一份资源。
• Build, release, run：严格分离构建和运行。基准代码进行部署需要三个步骤，构建阶段，将代码仓库转化为可执行包的过程；发布阶段，将构建的结果和当前部署所需的配置相结合，并能够立刻在运行环境中投入使用；运行阶段，是指针对选定的发布版本在执行环境中启动一系列应用程序的进程。
• Processes：进程。以一个或多个无状态进程运行应用。
• Port binding：通过端口绑定提供服务。互联网应用可以通过端口绑定来提供服务并随时监听所有发送至该端口的请求。
• Concurrency：并发。通过进程模型进行扩展。
• Disposability：易处理、快速启动和优雅终止可最大化健壮性。
• Dev/prod parity：开发环境与生产环境等价。保持开发、预发布、线上环境的相似性来实现持续交付与部署。
• Logs：日志。把日志当作事件流，允许执行环境通过集中式服务来收集、聚合、检索和分析日志。
• Admin processes：管理进程。后台管理任务当作一次性进程运行，如数据库迁移。

“12因素”对于构建 Web 应用程序或 SaaS 平台具有指导作用。
虽说提出之后已有八年之久，可能有些细节跟不上最新的体系架构，但“12 因素”依旧是目前最为系统的云原生应用开发指南。
你在开发时可以依旧参考它，但也不用拘泥于教条规则。

服务端架构的演进

事情总在发展，大型软件系统架构也随着软件开发技术、基础配套设备和硬件性能等因素的改变而不断演化着。
一般来说，早期的软件大多数是单体架构，接着使用分层技术演化为垂直架构，然后 SOA 面向服务架构和微服务架构相继登场，最终随着云技术的应用和推广而孕育出云原生架构的思想。

下面我们就来一一介绍这些架构设计的基础理念和优缺点。

单体架构

在 Web 应用程序发展的早期，大部分工程是将所有的服务端功能模块打包成单个巨石型（Monolith）应用，譬如很多企业的 Java 应用程序打包为 war 包，最终会形成如下图所示的架构。

单体架构的应用程序

单体架构的应用开发简单，技术单一，测试、部署相对简单明了。但其缺陷也是非常明显的，进行局部改动就需要重新部署，而且编译时间过长。
除此之外，单体架构的技术栈也不易扩展，只能不断地在原有基础上进行局部优化，比如说应用的某一场景需要处理高并发，使用 Go 语言较为合适，但是单体架构并不支持多语言技术栈，这时也就只好作罢。

垂直分层架构

单体架构在系统用户访问量逐渐增大的情况下，若仅仅依靠扩展物理机配置或者增加机器来优化系统的性能，往往收效甚微。
单体架构中不同业务模块的差异就会显现，比如有些模块是 IO 密集型，有些是计算密集型。
这些模块所需要的机器数量和性能各有差异，这时为了提升机器利用率和性能，垂直分层架构就诞生了。

垂直分层架构是将大应用拆分成一个个单体结构的应用。
换句话说，垂直架构就是彼此存在依赖关系的组件组成的架构，比如分层——用户界面层依赖业务逻辑，而业务逻辑依赖数据库访问（如下图所示）。
垂直分层是一个典型的对复杂系统进行结构化思考和抽象聚合的通用性方法。

垂直分层架构的应用程序

这样处理后，垂直分层架构就解决了很多问题：将系统拆分实现了流量分担，解决了部分并发问题；
拆分之后，服务间相互独立；性能方面，可以针对单个服务模块进行优化；易于水平扩展，多实例提升容错率。

但其缺点也是明显的，垂直分层架构的系统拆分，使得集群搭建变得复杂；涉及的服务间调用，服务之间耦合度变高，调用关系错综复杂，难以维护调用关系。

SOA 面向服务架构

当垂直架构拆分的应用越来越多时，就会出现多个应用都依赖的业务逻辑组件，并且各个应用进行交互的需要也越来越频繁。
此时，就需要将部分通用的业务组件独立出来，并定义好服务间交互的接口，向外提供能力，让其他服务调用。SOA 面向服务架构这就“应运而生”了。

SOA 面向服务架构是一种软件体系结构，它将应用程序的不同服务通过定义良好的接口和契约联系起来，这些接口独立定义，不依赖实现服务的编程语言、操作系统。应用程序的不同组件通过网络上的通信协议向其他组件提供服务。
通信可以是简单的数据传递，也可以是两个或多个服务彼此协调连接。

SOA面向服务架构

SOA 面向服务架构中主要有两个角色：服务提供者和使用者。
如上图所示，服务消费者可以通过发送消息来调用订单、购买、账号的服务，这些消息由服务总线转换后发送给对应的服务，实现 SOA 服务之间的交互通信。

SOA 面向服务架构主要适用于大型软件服务企业对外提供服务的场景，至于一般业务场景就并不适用了，因为其服务的定义、注册和调用都需要较为烦琐的编码或者配置实现，并且业务总线也容易导致系统的单点风险并拖累整体性能。

微服务架构

随着互联网浪潮的来临，越来越多的中小微企业推出面向普通大众的网站或者应用。
这些企业不同于大型软件服务企业，没有能力也无须构建 SOA 所依赖的 ESB 企业服务总线。
于是继承 SOA 众多优点和理念的微服务架构于 2014 年由 Matrin Fowler 提出，其理念是将业务系统彻底地组件化和服务化，形成多个可以独立开发、部署和维护的服务或者应用的集合，以应对更快的需求变更和更短的开发迭代周期。

微服务也是一种架构风格，它提倡将大型复杂软件应用划分成多个微服务，这些服务之间互相协调、配合，可独立部署；
服务之间松耦合，每个服务代表着一个小的业务能力（如下图所示）。

总体来说，微服务架构有如下的特点：

• 微服务遵循单一原则，每个微服务负责一个独立上下文边界；
• 微服务架构提供的服务之间采用 RESTful 等轻量协议传输，相比 ESB 更轻量；
• 每个服务都有自己独立的业务开发活动和周期；
• 微服务一般使用容器技术独立部署，运行在自己的独立进程中，合理分配其所需的系统资源，这样开发者就可以更加方便地制定每个服务的优化方案，提高系统可维护性。

但是，微服务架构也会遇到这样或那样的问题。比如，微服务架构拆分的服务实例过多的话，服务治理成本将会极大升高，不利于系统维护；
服务之间相互依赖，有可能形成复杂的依赖链条，往往单个服务异常，其他服务都会受到影响，出现服务雪崩效应；
服务实例之间交互需要处理分布式事务、调用幂等性和重试等问题，开发成本高，对团队挑战大。