《从单体应用到微服务》读后感

从单体应用到微服务读后感.微服务介绍什么是微服务应用微服务是围绕一个业务领域建 模的可独立部署的服务。通过网络彼此交互。微服务是一种SOA 架构，并且它是技术不可知论的，即微服务并不要求使用特定的 技术。这点需要重点强强调下，因为很多人采用微服务都是技术 驱动的，这种认识不是非常合适。微服务通过网络端点互相访 问，这让微服务具有分布式系统的特点。下面罗列一些微服务的 核心思想独立可部署性这本书认为微服务最重要的特性就是独立 可部署性。这要求微服务在部署自身的时候，不依赖任何其它服 务。为了保证独立可部署性，因此需要服务之间松耦合.服务之间 使用稳定的协议交互数据。围绕一个业务领域建模传统的单体应 用中，我们最常用的架构是分层架构，如将系统分为展示层.业务 层和数据层。根据康威定律任何设计系统的组织，都会产生这样一个设 计，即该设计的结构与该组织的沟通结构相一致。因此在分层架 构中，不同技术角色的人员被分配在一起工作，如前端组.后端组 和DBA组等。这是一种以技术视角设计的架构。在微服务中，则 是围绕业务领域的，将一个大的业务领域划分成若干尽可能独立 的子域，每个子域自己可以是分层架构的。根据康威逆定律，这样的架构势必也会影响到组织的沟通方 式的变化。拥有自己数据的所有权微服务的核心思想之一是不使 用共享的数据库，每个服务唯一的拥有自身数据的控制权。这可 以让服务决定公开哪些数据和隐藏哪些数据。这进一步要求了微 服务之间需要维护稳定的接口协议。对数据的控制会促进服务做 到高内聚，而通过隐藏自身数据又可以促进服务间的松耦合。微 服务带来的优势微服务带来的优势很多。天生的可独立部署性可 以促进系统的伸缩性和鲁棒性，并且可以混合使用多种技术。通 过服务和团队的划分，每个服务都是独立演进的，也就是说，所 有的服务都可以并行开发，服务的开发团队也将专注于一个特定 的业务领域，不受其它业务领域的影响。虽然微服务带来了很多 优势，但是这并不代表可以免费的使用微服务。另一方面，微服 务的优势中，针对某个方面可能还有其它替代方面，而并非只能 使用微服务来获得。因此在应用微服务架构时，非常重要的一点 是需要明确自身想从微服务中获得哪些好处。微服务带来的问题 计算机的价格越来越低，这让SOA架构广泛的被应用。使用SOA 可以将系统分布在多台计算机上。但这带来的挑战是服务之间的 网络通信问题。网络连接是不稳定的，尤其是考虑延迟的时候， 延迟会让整个系统变得不可预测，除此之外，还需要额外处理网 络错误的情况。分布式的部署结构会让一切变得复杂起来。某种 意义上说，单体应用也存在一些分布式的场景，例如数据库在一 台服务器上，另一台服务器上的程序从数据库服务器读取数据， 而客户端使用一台电脑访问程序获取数据。在这个场景中已经出 现了 3台电脑间的网络通信。单体应用和微服务在分布式上的差 别主要在分布的程度上，微服务会使用更多的主机.更多的网络通 信。开始的时候，微服务的规模较小，问题可能看起来并不分严 重，但随着微服务规模的逐渐增多，出现问题的频率和难度也会 逐步上升。为了解决微服务带来的分布式问题，将会花费很多的 真金白银。这也是在打算使用微服务架构时需要考虑的一点是否 值得用户界面使用微服务架构的一个误区是只对服务端程序进行 微服务架构，而依然采用单体应用来作为展示层提供UI访问。单 体的展示层使得从用户视角来看，服务无法独立的发布，这是不 正确的。根据上面围绕业务领域建模中讲述的，每个微服务都应该负 责自身业务领域的所有分层，包括UI层.业务层和数据层。因此 在用户界面上也应和微服务的拆分保持一致。这可能需要一些专 门的技术来实现，如微前端。技术微服务是一个技术不可知论的 架构，因此，如何实现微服务并没有技术上的要求。只要服务问 基于网络可以互相通信就可以了，不必使用K8S. Docker.公有云等 也可以实现微服务。在编程语言上也可以使用任何一种语言进行 实现。但是微服务是非常复杂的，主要是因为它带来的分布式问 题，这些问题可能是之前使用单体应用从来没遇到过的问题。因 此，不应盲目的跟风新技术，应该使用自己最熟悉的技术来实现 微服务应用。大小微服务应该有多大，这应该是最常被讨论的问 题。要解答这个问题，首先需要定义大小的衡量标准。常用的衡 量标准如代码行数，但这在微服务中是没有意义的，因为微服务 是技术不可知论的，而使用不同的编程语言实现同样的逻辑，代 码行数差别是非常大的。书中引述了一位微服务专家对微服务大 小的建议是尽可能小的接口。实际上，微服务的大小在不同的上 下文和人群中的感受是不一样的，因此不必过于纠结微服务大小 的问题。在考虑大小的时候，最应该考虑的是以下两个问题1）你 可以处理多少个服务。随着服务的增多，系统也会变得更加复 杂，需要团队学习更多的知识来应对；2）服务的边界如何定义。 不合适的边界划分最终可能会导致恐怖的耦合混乱。所有权传统 的IT企业采用职能型的组织架构，软件的生命周期分别由不同的 部门负责，如需求部门负责采集用户需求，开发部门收到需求部 门输出的需求文档后进行软件开发。这种方式如下图所示图片现 在越来越多的企业将组织方式调整为矩阵型，提高沟通效率，加 快开发速度。而微服务架构是围绕业务领域建模的，这非常适合 矩阵型组织的沟通方式。组织可以使用微服务所代表的业务领域 对组织进行划分，根据微服务的特性，团队之间也会减少跨团队的共享.最小化 发布时的竞争。如下图所示单体应用什么是单体应用呢单体应用 的特征是系统的所有功能共同组成一个唯一的部署单元。通常单 体应用分为三类单进程单体应用模块化的单体应用分布式的单体 应用分布式的单体应用由多个服务组成，但是这些服务必须同时 部署。这种方式拥有分布式系统和单体系统的所有缺点，并且对 于单纯的分布式系统和单体系统而言没有任何优势。所有的服务 都混乱的耦合在一起。一个服务的变更就可能导致系统不可用。 第三方黑盒系统我们可以将第三方的系统都视为单体应用。单体 系统的挑战单体应用由于实现和部署耦合，更加的脆弱。如果有 很多人在一起工作，可能会引发混乱。一些开发人员可能同时修 改同一段代码，团队之间的工作互相依赖。微服务提供的概念边 界会更加容易地解决这些问题。单体系统的优势单体应用的部署 拓扑比分布式系统简单的多，这样会让开发流程更加简单；并且 在监控.排错和系统测试方面也要简单许多；单体系统内部的代码 可以更简单的复用，这在微服务中，可能意味着代码拷贝或者共 享代码等权衡。很多人将单体系统视作老士的架构，视为应该被 抛弃的架构，这是绝对是不正确的观点。内聚和耦合内聚的目的 是将相关的代码放在一起，一起应对变更；而耦合则表示对一个 部分的修改会对其它部分造成影响。高内聚.低耦合会让架构保持 稳定。单体应用通常是高耦合.低内聚的，各种不相关的代码都耦 合在一起。当需要代码调整的时候，通常很困难。同时，松耦合 在单体应用中实际并不存在，因为任何变动都需要将整个应用一 起打包部署。在微服务中，如果要想做的松耦合，一方面是保证 自身的修改不需要改变其它部分，另一方面是保证接口的稳定。我们需要谨慎的考虑系统中的耦合，耦合可分为以下4类实现耦 合这是一种危害最大的耦合类型，但通常比较容易处理。例如A 服务的实现依赖于B服务如何实现，当B服务需要修改时，A服务 需要同时修改。典型的例子是共享数据库，当A和B共享同一个 数据库时，A对数据库的变更会直接影响B。临时耦合这种耦合发 生在运行时，一般发生在分布式环境中的同步调用时。例如A服 务要同步地调用B服务获取信息，而B服务此时又需要同步地调 用C服务，这就构成一个临时耦合。这里问题是，请求若要成 功，这三个服务必须都正常运行并且可以相互调用。解决时可以 考虑使用缓存或者异步消息。部署耦合不管代码是不是模块化 的，如果在发布的时候需要打成一个包统一部署，这时就是部署 耦合。部署耦合带来的问题一方面是需要协调各个团队的发布计 划，另一方面，每次部署都会有风险，越大的部署范围风险也会 越大。并且少量的代码更容易实现自动发布。领域耦合每个微服 务都处在一个领域限界上下文中，当它们之间的概念有交互时， 就形成了领域耦合。例如服务A中需要理解服务B中的一个领域 概念。实际上，服务A中所需要的概念可能与服务B中的不一 样，例如仓库服务需要访问订单服务中的订单信息，实际上仓库 服务需要的订单信息可能只是订单编号，它不需要理解订单服务 中订单信息的全部业务概念。因此，仓库服务应该维护一个在自 己限界上下文内的订单信息实体。领域驱动设计前面介绍了我们 为什么要围绕业务领域建模。那么具体如何做呢这就是领域驱动 设计(DDD)解决的问题。DDD介绍了 一系列的思想来在程序中表 示问题域。设计微服务的重要概念有聚合聚合是一个自包含的单 元，表达了一个实际的业务概念。通常聚合拥有一个生命周期， 这会让聚合的实现类似一个状态机。我们需要保证一个业务概念 的状态转移完全被包含在一个聚合之中。一个微服务会处理一个 或多个聚合的生命周期和数据存储。将一个系统划分成聚合可能 需要考虑众多因素，例如性能问题.实现的难易程度等。这也意味 着聚合可能会对聚合进行重新划分。在实际中，事件风暴非常有 用。限界上下文限界上下文通常代表了组织中的一个较大范围的 边界。这个边界内有单一的职责。从实现角度来看，一个限界上 下文中有一个或多个聚合。这些聚合中的一些可能会对外暴露， 另一些则被内部隐藏。将聚合和限界上下文映射成服务聚合和限 界上下文都提供了高内聚的单元，并且提供设计良好的接口。聚 合涉及一个单一领域概念的自包含状态机，而限界上下文则代表 一组相关的聚合。聚合和限界上下文都可以作为微服务的边界。 考虑到初期尽量减少服务的数量，建议使用范围更大的限界上下 文来作为微服务边界，熟悉后，可以进一步使用聚合拆分。第二 章.规划迁移是否应该使用微服务微服务不应作为一个目标，使用 微服务也不会让你获得胜利。采用微服务的决定一定是经过深思 熟虑的。从单体应用迁移到微服务应用应该有充分的理由，例如 获得当前单体应用不具备的能力。在考虑想微服务架构迁移之 前，需要明确三个问题你希望从微服务中获得什么除了微服务， 还有什么其它的解决方案你怎么衡量微服务带来的成效微服务不 是免费的，它可能会引起组织系统性的变化，需要引入更多的运 维组件，改变现有的开发方式等等。因此需要充分考虑ROI,以判 断一个迁移是否值得。微服务带来的好处主要有以下几点，但请 注意，带来的这些好处大部分都可以通过其它方式获得。提升团 队自治性非常多的企业证明了团队自治带来的好处。自治的团队 通常不会很大，确保团队内成员彼此都非常熟悉，自治团队在一 个较小的范围内工作。业界有一些关于团队规模的范例，如亚马 逊的两个披萨模型。如果正确使用团队自治性，会激发团队成员 成长并提升效率。当团队拥有微服务的全部控制权，就会提升团 队在整个组织中的自治性。自治性不是微服务独有的，有很多方 式可以获得自治。团队的自治主要涉及分配给团队的职责，而与 使用什么样的架构关系不大。比如可以通过将代码仓库中的一部 分授权给一个团队来促进团队的自治。加快上市时间将变更的执 行和部署聚焦到各自独立的微服务中，可以做到不用和其它服务 协调发布时间，同时多个团队可以并行的处理待办任务列表，这 让功能面世的时间大幅度加快。当然，不使用微服务也可以做到 加快上市时间。如优化上线流程等也会起到一定的效果。通过对 现有上线流程的分析，判断是否可以通过调整任务执行的顺序， 或者采用并行的方式来加快流程执行的速度。为负载更有效的扩 缩每个微服务都可以独立的进行扩缩，这样会更加有效。因为我 们只需要扩展对处理当前复杂有瓶颈的部分。当负载降低，可以 对这部分再进行缩容。如果不使用微服务，有很多方法可以应对 负载升高的情况。最简单的就是使用配置更高的机器。另外，传 统的通过多个单体应用的拷贝来进行水平扩展的方案也是非常有 效的，虽然它对于数据库的瓶颈没有帮助。提升鲁棒性例如多租 户的SaaS系统，这类系统对可用性的要求很高，一旦出现宕机， 影响范围将会非常广泛。通过使用微服务，将一个系统根据功能解耦成若干个独立的服务，也就是说，当一个功能 出现问题时，不会影响其它服务的功能。这里需要注意的是，微 服务提供的鲁棒性不是免费的，并且由于服务部署在不同的机器 上，这也会增加调用失败的风险。如果不使用微服务，通过拷贝 多个单体应用进行负载均衡也可以有效的提升系统的鲁棒性。另 一方面，系统的不稳定通常都是人为的，如果系统存在很多人工 的操作，则使用自动化的手段在很大程度上解决问题。扩展开发 人员的数量人月神话中提到，只有将工作分割成互不影响的小 块，才能够通过增加人数来加快发布进度。微服务通过明确的边 界，限制了其自身的范围和对其它服务的依赖。因此可以支持大 量的开发人员。仅仅使用微服务通常是不够的，还需要结合团队 自治和服务所有权。另一种不使用微服务的方法是实现模块化的 单体应用，不同的团队拥有单体中的不同模块。只要它们对外暴 露的接口是稳定的，那么就可以独自的演化。拥抱新技术单体应 用限制了新技术的使用，因为通常它只使用一种开发语言，使用 特定的部署平台.运维系统和一种数据库。而微服务中的每一个独 立的服务都可以根据自身的特点进行技术选型。成熟的微服务组织通常会限 制可使用的技术栈。在这一点上，单体应用没有太好的办法。什 么时候不应该使用微服务在一些场景中是不适合使用微服务的， 如下不了解的领域服务边界如果划分有误，则带来的代价可能是 非常高昂的，可能会导致服务间的高度耦合，则要比单体应用更 加糟糕。如果对业务领域尚不了解，不应盲目的进行服务拆分， 而是应该先学习领域知识。初创系统很多企业在系统初始阶段就 会考虑使用微服务架构，但在实际实现时，都会先采用单体应 用。微服务对于扩张来说是一个很好的选择，但在初始阶段，功 能尚处于试验阶段，会根据用户的需求不断调整。一些功能可能会重写，另一些功 能可能会删掉。另一方面，初始阶段的资金有限，应该将关注点 放在产品本身上，单体应用易于开发和测试，部署拓扑也非常简 单，相比微服务不需要花费太多的资源和精力。通常来说，一个 已经存在的棕域系统相比一个新的绿域系统来说，更加容易拆 分。客户自己安装和管理的软件如果软件打包后分发给客户自行 安装和管理，那么不应该使用微服务。因为微服务的安装和运维 非常复杂，客户可能没有安装和管理微服务架构应用的能力。没 有充分理由的情况下这个前面也提到过，微服务作为一个分布式 系统，使用起来将会面临非常多的挑战，因此，一定是在经过深 思熟虑后，确定微服务带来的优点大于缺点时，才可以使用。如 何开始微服务要在组织中推广微服务，首先要做的是让其他人清 楚的明白你希望从微服务中获得什么，当他们认同之后，要做的 就是探讨如何实现。通常需要先引入一些成熟的模型来帮助组织 变革。下面介绍John Kotter的组织变革八步法，整个过程如下 图所示创建变革的紧迫感组织中的好主意有很多，微服务可能只 是其中之一。因此需要让大家明白现在就是实现微服务的最佳时 机，要做到这点的最佳实践是结合当前组织中的实际场景，结合 当前的痛点，而不是干巴巴的说我们要使用微服务，任何时候， 微服务都不是目标。创建一个有足够力量的引导联盟要推动一个 变革，一个人是远远不够的。需要在组织中分辨哪些人可以帮助 你，这些人可能是同事.领导或者其它部门的相关方，让这些人加 入到你的队伍中，让他们成为推动变革的一份子。这可能涉及到 包含IT岗位的任何岗位。创建一个愿景和实现策略愿景说明了你 想从变更中获得什么，而策略则说明了你将如何实现变革。策略 可能会不断调整，因此微服务不一定是唯一的方式。推广变革愿 景宏大的愿景看起来很棒，但是在推广的时候没人会相信。因此 可以在开始的时候分享一个小的愿景。在推广方式上，建议使用 面对面的方式，其它方式可以结合使用。赋予员工广泛的行动权 力当你完成了愿景的推广，大家都满怀激动的心情后，接下来会 怎样呢大家可能继续忙各自的工作。在使用微服务的时候围绕已 存在的基础设施的流程可能是一个非常实际的问题。例如你需要 发布一个新的服务，但是硬件采购的流程非常长。因此需要赋能 员工，帮助他们扫清障碍，做他们该做的事情。创建短期成效如 果实现的周期太长，人们可能会丧失对愿景的信心，因此需要将 整个周期拆分成很多小的胜利。当使用微服务对功能解耦后，这 可能更加容易实现。巩固收益并产生更多变化当取得一些小胜利 后，要趁热打铁。对流程和策略进行继续的优化，寻找如何能够 驱动变革继续进行。例如在微服务拆分后，接下来可能意味着对 数据库的解耦。将新方式融入文化随着变革的深入，以及不断对 成功或失败经验进行分享，团队会越来越熟悉新的工作方式，最 终会形成组织特有的文化沉淀下来。逐步迁移的重要性逐步的迁 移有助于在过程中学习微服务，当出现问题的时候，影响的范围 也是有限的。把迁移分为多个小步骤，也可以帮助分析每一步的 成果，总结每一步的经验教训。也有助于实现上文提到的快速的 小胜利。当确定使用微服务的时候，可以先挑选一到两个业务领 域，用微服务实现它们，并将它们发布到生产环境，然后观察它 工作的怎样。这里列出一些逐步迁移的好处只有生产环境才算数 只有将拆分好的微服务发布到生产环境在表示这个服务实现完 成。因为微服务解耦后会带来很多问题，如排错.调用链.延迟.级 联错误等。很多问题只有在生产环境中才能发现。如果做错了， 逐步迁移会使你能够快速定位问题和回滚。变更成本在向微服务 迁移时，会犯很多错误，逐步迁移不会减少犯错误的可能性，但 是当错误发生，其造成的成本损失是可控的。可逆和不可逆的决 策有些决策是不可逆的，这意味着一旦它开始执行，就再也无法 回到起点了。这类决策需要非常谨慎的评估，运用方法论，长时 间的论证。而另一类决策在执行后，如果发现不合适，可以回到 初始的地方重新来过，这类决策可以快速指定，并且可以授权给 个人或者小的团体。更容易进行实验调整代码的成本较低，有很 多工具可以使用，但是调整数据库的成本就会非常高。高成本的 变更的风险也会是很高的，因此最好的办法是进行一些小的实验 来观察可能发生的问题，逐步迁移会让这些实验的影响范围是可 控的。领域驱动设计接下来我们将讨论如何进行微服务的拆分， 使用的思想是领域驱动设计。在使用领域驱动设计建立领域模型 后，这个模型可以帮助我们定义服务边界，以及引导我们分辨实 现服务的优先级。通过限界上下文之间的依赖关系，对其它限界 上下文依赖越少的服务在实现的时候就会越容易，这些也是我们 有限选择实现的。实际上，有一些方法可以帮助我们决策，如下 打算走多远开始的时候，一下子要对系统的整体领域模型都进行 分析，往往不知道如何入手，也会让人心生畏惧。其实，在将单 体应用解耦的时候，只需要了解足够的关于从什么地方开始解耦 的信息就够了。缺少全局的理解确实会带来一些风险，但是开始 的时候并不是非常重要，因为开始的时候只需要获取如何进行下 一步的信息就可以了，在解耦过程中需要不断结合新的领域只是 对领域模型进行重新定义。事件风暴事件风暴可以帮助技术相关 方和非技术相关方共同定义一个共享的领域模型。事件风暴是自 下而上的，首先参与者一起定义领域事件系统中真实发生的事 件。然后用这些事件组成聚合，再将聚合组成限界上下文。事件 风暴的输出不仅仅是领域模型，最终要的是对领域模型的一致性 理解。因此需要相关方在一起工作，这是使用这个方法最大的挑 战。使用模型排序优先级通过分析上下游服务的依赖关系，就可 以明白哪些服务相对容易拆分，哪些会更加困难。这可以作为服 务实现顺序的排序因素。但需要注意的是，领域模型表达了系统 的逻辑概念，虽然从逻辑上看没有依赖，但可能在物理层面存在 关系，因此仍然需要在进一步的从实现代码中分析是否存在依 赖。另一个决定优先级的因素是业务本身，因为我们需要实现快 速的成功，所以需要选择能够实现这个目标的恰当的业务。模型 分组在实际选择要实现的服务时，大部分人可能会选择最容易解 耦的部分，但我们的另一个关注点是取得快速的成功，这意味着 我们应该选择能够为系统带来立竿见影效果的部分，而这些部分 通常都是核心业务，可能并不容易拆分。这时我们可以按照难易 程度和效果将候选服务进行分组，如下图所示X轴表示效果，越 向右效果越明显。Y轴表示实现的难度，越向上越容易。显然，我 们最终应该选择位于图的右上方的候选服务。有时候我们在实现 的时候会发现，原本以为简单的服务实际实现起来很困难，反之 亦然。这是很正常的，这也意味着需要重新对服务进行排序后选 择新的服务进行实现。重新组织团队使架构和组织保持一致是充 分发挥微服务架构优势的关键，但这在组织中通常并不容易。下 面提出一些对此有帮助的想法转变结构传统上，IT组织的结构是 围绕核心能力的。例如Java开发人员在一起，测试人员在一起， DBA和其它DBA在一起。在开发系统的时候，每个只能团队中的人 只完成系统生命周期中的一部分任务。这也导致过程中需要各个 部门之间相互协调。在微服务的架构中，每个服务涉及多个软件 层次，也会涉及多个职能。因此当今的组织开始向DevOps转变， 测试人员不再是一个单独的部门，而是作为发布团队中的一员， 和开发团队更紧密的合作。通过将不同职能的人员放在一个发布 团队中，授予他们足够的权限，这可以促进他们为服务的发布提 供各种帮助。没有范式组织方式没有一个范式可以适合所有企 业，它会收到企业环境.工作文化以及具体的人的影响。因此，盲 目拷贝别的企业的组织方式是很危险的。其它企业的成功经验可 以用来参考，但是要清楚它可能不会在你的场景中成功。做出一 个改变如果你不能拷贝其它企业的组织结构，那应该怎么做呢首 先可以先罗列日常涉及的工作和流程，然后将它们和当前企业的 组织结构映射起来。然后分析哪些职能需要跨越组织结构来工 作，结合愿景重新绘制一个理想的结构图。将两个图进行对比， 然后规划迁移方案。改变技能从单体向微服务迁移，需要对组织 中原有的能力进行更新。一个有效的方法是，首先罗列出所有需 要的能力，然后让员工对自己进行评价，评估自己当前的能力。 这里需要重点强调的是，自我评价是非公开的，只是用于他们的 导师了解每个人的特点。然后根据员工的兴趣爱好针对性的进行培训。改变现有人员的技 能只是一个方面，如果追求短期成效，可以在团队中增加拥有该 技能的专业人员。怎么衡量迁移是否成功如果没有衡量成功的标 准，那么迁移将永无止境。在向微服务迁移时，即便做好完全的 准备，也会犯错。那么怎么才能知道迁移工作起作用了呢基于希 望获得的成效，应该指定一些可追踪的指标来回答这个问题。然 后设置一些检查点，每到达一个检查点，就检视一下方向是否正 确，使用指标衡量是否起到预期的作用，并且分析是否应该尝试 其它方式。下面是一些建议设置定期的检查点任何一个迁移，都 需要设置定期的检查点，在迁移过程中停下来看看是否正确实 现。检查点可以是正式的也可以是非正式的，内容包括1）重申希 望从微服务中获得什么；2）审查定量的指标；3）接受定性的反 馈大家是否觉得做了正确的事情；4）确定今后的改进方向。定量 衡量定量的指标可以直观的反映出迁移的情况。例如部署的次数. 失败率等。但是要注意数据的时效性，过期的数据可能会造成错 误的决策。一些指标可能在短期内没有变化，甚至会变得更糟， 这更加需要逐步的实施迁移。定性衡量无论定量分析的数据如 何，都应该关注于当事人的感受，他们是否享受这个过程是非常 重要的。如果大家的感受是负面的，应该立即做出调整。避免沉 没成本谬误沉默成本谬误发生在，当人们为之前的方法投入了非 常多后，即使已经有证据显示这个方法行不通，但因为已经投入 了很多，仍然继续执行。有时情况可能因为坚持而最终得到改 善，但另一些时候只是在浪费资源。通常，下注越大，越难以回 头。这又是一个逐步迁移的好处。开启新的方式在迁移的时候， 有多种选项和路径。对每一种方式而言，都不会完全平滑，因此 可能会在使用一个方式后发现这种方式并不是最好的，然后更换 另一个方式实现。建议尝试将这种变化融入到文化之中，采用这 种不断进取的文化，敢于尝试新的东西，那么在需要更改方向的 时候会变得更加自然。总结这一章介绍了为什么需要使用微服务 架构，以及哪些因素可以用来对实现顺序进行排序。当企业在决 策是否需要向微服务迁移时，需要回答三个问题希望从微服务中 获得什么是否考虑过微服务之外的其它替代方案怎么衡量迁移起 到了成效迁移过程可能会花费很长的时间，但实际工作中，客户 不会给我们这么多的时间。迁移只有在发布到生产环境后才能表 示一个阶段的结束。这就需要一系列的技术手段来让微服务应用 和单体应用协同工作。接下来的内容就会对这些技术进行介绍。