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

从单体应用到微服务读后感 目标：共同学习、共同进步、离别码农，成为受人敬仰的、有态度的程序猿。拒绝不知其因此然的复制粘贴、拒绝人云亦云。用最严谨的态度、最专业的方法、最可靠的知识，探究技术内幕，死磕到底！内容介绍原书名字是monolithTomicroservices，是大神SamNewman的新书，现在还没有汉字版本。原本是想写一个简短的读后感的，不过写着写着，发觉书中的内容真的是太经典了，浅尝辄止的描述完全不能表现本书的价值。于是就改成了用我自己的语言对书中每一章的内容进行了精炼。所以这个读后感也能够作为原书的精简版来看，只不过用的是我自己的语言总结的。也是因为这个原因，这篇越写字数越多，最终靠近三万字，花费的时间也很多。为了便于阅读，分成4部分来发。注：本文中的图片截自原书第一章、微服务介绍什么是微服务应用?微服务是围绕一个业务领域建模的可独立布署的服务。经过网络相互交互。微服务是一个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系统，这类系统对可用性的要求很高，一旦出现宕机，影响范围将会很广泛。经过使用微服务，将一个系统依据功效解耦成若干个独立的服务，也就是说，当一个功效出现问题时，不会影响其它服务的功效。这里需要注意的是，微服务提供的鲁棒性不是无偿的，而且因为服务布署在不一样的机器上，这也会增加调用失败的风险。假如不使用微服务，经过拷贝多个单体应用进行负载均衡也能够有效的提升系统的鲁棒性。其次，系统的不稳定通常全部是人为的，假如系统存在大家工的操作，则使用自动化的手段在很大程度上处理问题。扩展开发人员的数量人月神话中提到，只有将工作分割成互不影响的小块，才能够经过增加人数来加紧公布进度。微服务经过明确的边界，限制了其本身的范围和对其它服务的依靠。所以能够支持大量的开发人员。仅仅使用微服务通常是不够的，还需要结合团体自治和服务全部权。另一个不使用微服务的方法是实现模块化的单体应用，不一样的团体拥有单体中的不一样模块。只要它们对外暴露的接口是稳定的，那么就能够独自的演化。拥抱新技术单体应用限制了新技术的使用，因为通常它只使用一个开发语言，使用特定的布署平台、运维系统和一个数据库。而微服务中的每一个独立的服务全部能够依据本身的特点进行技术选型。成熟的微服务组织通常会限制可使用的技术栈。在这一点上，单体应用没有太好的措施。什么时候不应该使用微服务?在部分场景中是不适合使用微服务的，以下：不了解的领域：服务边界假如划分有误，则带来的代价可能是很高昂的，可能会造成服务间的高度耦合，则要比单体应用愈加糟糕。假如对业务领域尚不了解，不应盲目标进行服务拆分，而是应该先学习领域知识。初创系统：很多企业在系统初始阶段就会考虑使用微服务架构，但在实际实现时，全部会先采取单体应用。微服务对于扩张来说是一个很好的选择，但在初始阶段，功效尚处于试验阶段，会依据用户的需求不停调整。部分功效可能会重写，另部分功效可能会删掉。其次，初始阶段的资金有限，应该将关注点放在产品本身上，单体应用易于开发和测试，布署拓扑也很简单，相比微服务不需要花费太多的资源和精力。通常来说，一个已经存在的“棕域”系统相比一个新的“绿域”系统来说，愈加轻易拆分。用户自己安装和管理的软件：假如软件打包后分发给用户自行安装和管理，那么不应该使用微服务。因为微服务的安装和运维很复杂，用户可能没有安装和管理微服务架构应用的能力。没有充足理由的情况下：这个前面也提到过，微服务作为一个分布式系统，使用起来将见面临很多的挑战，所以，一定是在经过深思熟虑后，确定微服务带来的优点大于缺点时，才能够使用。怎样开始微服务?要在组织中推广微服务，首先要做的是让其它人清楚的明白你期望从微服务中取得什么，当她们认同以后，要做的就是探讨怎样实现。通常需要先引入部分成熟的模型来帮助组织变革。下面介绍johnkotter的“组织变革八步法”，整个过程以下图所表示：创立变革的紧迫感：组织中的好主意有很多，微服务可能只是其中之一。所以需要让大家明白现在就是实现微服务的最好时机，要做到这点的最好实践是结合目前组织中的实际场景，结合目前的痛点，而不是干巴巴的说：“我们要使用微服务”，任何时候，微服务全部不是目标。创立一个有足够力量的引导联盟：要推进一个变革，一个人是远远不够的。需要在组织中分辨哪些人能够帮助你，这些人可能是同事、领导或其它部门的相关方，让这些人加入到你的队伍中，让她们成为推进变革的一份子。这可能包括到包含IT岗位的任何岗位。创立一个愿景和实现策略：愿景说明了你想从变更中取得什么，而策略则说明了你将怎样实现变革。策略可能会不停调整，所以微服务不一定是唯一的方法。推广变革愿景：宏大的愿景看起来很棒，不过在推广的时候没人会相信。所以能够在开始的时候分享一个小的愿景。在推广方法上，提议使用面对面的方法，其它方法能够结合使用。给予职员广泛的行动权力：当你完成了愿景的推广，大家全部满怀激动的心情后，接下来会怎样呢?大家可能继续忙各自的工作。在使用微服务的时候围绕已存在的基础设施的步骤可能是一个很实际的问题。比如你需要公布一个新的服务，不过硬件采购的步骤很长。所以需要赋能职员，帮助她们扫清障碍，做她们该做的事情。创立短期成效：假如实现的周期太长，大家可能会丧失对愿景的信心，所以需要将整个周期拆分成很多小的胜利。当使用微服务对功效解耦后，这可能愈加轻易实现。巩固收益并产生更多改变：当取得部分小胜利后，要趁热打铁。对步骤和策略进行继续的优化，寻求怎样能够驱动变革继续进行。比如在微服务拆分后，接下来可能意味着对数据库的解耦。将新方法融入文化：伴随变革的深入，和不停对成功或失败经验进行分享，团体会越来越熟悉新的工作方法，最终会形成组织特有的文化沉淀下来。逐步迁移的主要性逐步的迁移有利于在过程中学习微服务，当出现问题的时候，影响的范围也是有限的。把迁移分为多个小步骤，也能够帮助分析每一步的结果，总结每一步的经验教训。也有利于实现上文提到的快速的小胜利。当确定使用微服务的时候，能够先挑选一到两个业务领域，用微服务实现它们，并将它们公布到生产环境，然后观察它工作的怎样。这里列出部分逐步迁移的好处：只有生产环境才算数：只有将拆分好的微服务公布到生产环境在表示这个服务实现完成。因为微服务解耦后会带来很多问题，如：排错、调用链、延迟、级联错误等。很多问题只有在生产环境中才能发觉。假如做错了，逐步迁移会使你能够快速定位问题和回滚。变更成本：在向微服务迁移时，会犯很多错误，逐步迁移不会降低犯错误的可能性，不过当错误发生，其造成的成本损失是可控的。可逆和不可逆的决议：有些决议是不可逆的，这意味着一旦它开始实施，就再也无法回到起点了。这类决议需要很谨慎的评定，利用方法论，长时间的论证。而另一类决议在实施后，假如发觉不适宜，能够回到初始的地方重新来过，这类决议能够快速指定，而且能够授权给个人或小的团体。更轻易进行试验：调整代码的成本较低，有很多工具能够使用，不过调整数据库的成本就会很高。高成本的变更的风险也会是很高的，所以最好的措施是进行部分小的试验来观察可能发生的问题，逐步迁移会让这些试验的影响范围是可控的。领域驱动设计接下来我们将讨论怎样进行微服务的拆分，使用的思想是领域驱动设计。在使用领域驱动设计建立领域模型后，这个模型能够帮助我们定义服务边界，和引导我们分辨实现服务的优先级。经过限界上下文之间的依靠关系，对其它限界上下文依靠越少的服务在实现的时候就会越轻易，这些也是我们有限选择实现的。实际上，有部分方法能够帮助我们决议，以下：计划走多远?开始的时候，一下子要对系统的整体领域模型全部进行分析，往往不知道怎样入手，也会让人心生畏惧。其实，在将单体应用解耦的时候，只需要了解足够的有关从什么地方开始解耦的信息就够了。缺乏全局的了解确实会带来部分风险，不过开始的时候并不是很主要，因为开始的时候只需要获取怎样进行下一步的信息就能够了，在解耦过程中需要不停结合新的领域只是对领域模型进行重新定义。事件风暴事件风暴能够帮助技术相关方和非技术相关方共同定义一个共享的领域模型。事件风暴是自下而上的，首先参加者一起定义领域事件系统中真实发生的事件。然后用这些事件组成聚合，再将聚合组成限界上下文。事件风暴的输出不但仅是领域模型，最终要的是对领域模型的一致性了解。所以需要相关方在一起工作，这是使用这个方法最大的挑战。使用模型排序优先级经过分析上下游服务的依靠关系，就能够明白哪些服务相对轻易拆分，哪些会愈加困难。这能够作为服务实现次序的排序原因。但需要注意的是，领域模型表示了系统的逻辑概念，即使从逻辑上看没有依靠，但可能在物理层面存在关系，所以依然需要在深入的从实当代码中分析是否存在依靠。另一个决定优先级的原因是业务本身，因为我们需要实现快速的成功，因此需要选择能够实现这个目标的适当的业务。模型分组在实际选择要实现的服务时，大部分人可能会选择最轻易解耦的部分，但我们的另一个关注点是取得快速的成功，这意味着我们应该选择能够为系统带来立竿见影效果的部分，而这些部分通常全部是关键业务，可能并不轻易拆分。这时我们能够根据难易程度和效果将候选服务进行分组，以下图所表示：X轴表示效果，越向右效果越显著。y轴表示实现的难度，越向上越轻易。显然，我们最终应该选择在图的右上方的候选服务。有时候我们在实现的时候会发觉，原本认为简单的服务实际实现起来很困难，反之亦然。这是很正常的，这也意味着需要重新对服务进行排序后选择新的服务进行实现。重新组织团体使架构和组织保持一致是充足发挥微服务架构优势的关键，但这在组织中通常并不轻易。下面提出部分对此有帮助的想法：转变结构传统上，IT组织的结构是围绕关键能力的。比如java开发人员在一起，测试人员在一起，DBA和其它DBA在一起。在开发系统的时候，每个只能团体中的人只完成系统生命周期中的一部分任务。这也造成过程中需要各个部门之间相互协调。在微服务的架构中，每个服务包括多个软件层次，也会包括多个职能。所以当今的组织开始向Devops转变，测试人员不再是一个单独的部门，而是作为公布团体中的一员，和开发团体更紧密的合作。经过将不一样职能的人员放在一个公布团体中，授予她们足够的权限，这能够促进她们为服务的公布提供多种帮助。没有范式组织方法没有一个范式能够适合全部企业，它会收到企业环境、工作文化和详细的人的影响。所以，盲目拷贝其余企业的组织方法是很危险的。其它企业的成功经验能够用来参考，不过要清楚它可能不会在你的场景中成功。做出一个改变假如你不能拷贝其它企业的组织结构，那应该怎么做呢?首先能够先罗列日常包括的工作和步骤，然后将它们和目前企业的组织结构映射起来。然后分析哪些职能需要跨越组织结构来工作，结合愿景重新绘制一个理想的结构图。将两个图进行对比，然后计划迁移方案。改变技能从单体向微服务迁移，需要对组织中原有的能力进行更新。一个有效的方法是，首先罗列出全部需要的能力，然后让职员对自己进行评价，评定自己目前的能力。这里需要关键强调的是，自我评价是非公开的，只是用于她们的导师了解每个人的特点。然后依据职员的爱好兴趣针对性的进行培训。改变现有些人员的技能只是一个方面，假如追求短期成效，能够在团体中增加拥有该技能的专业人员。怎么衡量迁移是否成功?假如没有衡量成功的标准，那么迁移将永无止境。在向微服务迁移时，即便做好完全的准备，也会犯错。那么怎么才能知道迁移工作起作用了呢?基于期望取得的成效，应该指定部分可追踪的指标往返答这个问题。然后设置部分检验点，每抵达一个检验点，就检视一下方向是否正确，使用指标衡量是否起到预期的作用，而且分析是否应该尝试其它方法。下面是部分提议：设置定时的检验点任何一个迁移，全部需要设置定时的检验点，在迁移过程中停下来看看是否正确实现。检验点能够是正式的也能够是非正式的，内容包含：1 重申期望从微服务中取得什么；2 审查定量的指标；3 接收定性的反馈大家是否以为做了正确的事情；4 确定以后的改善方向。定量衡量定量的指标能够直观的反应出迁移的情况。比如：布署的次数、失败率等。不过要注意数据的时效性，过期的数据可能会造成错误的决议。部分指标可能在短期内没有改变，甚至会变得更糟，这愈加需要逐步的实施迁移。定性衡量不论定量分析的数据怎样，全部应该关注于当事人的感受，她们是否享受这个过程是很主要的。假如大家的感受是负面的，应该立刻做出调整。避免淹没成本谬误缄默成本谬误发生在，当大家为之前的方法投入了很多后，即使已经有证据显示这个方法行不通，但因为已经投入了很多，依然继续实施。有时情况可能因为坚持而最终得到改进，但另部分时候只是在浪费资源。通常，下注越大，越难以回头。这又是一个逐步迁移的好处。开启新的方法在迁移的时候，有多个选项和路径。对每一个方法而言，全部不会完全平滑，所以可能会在使用一个方法后发觉这种方法并不是最好的，然后更换另一个方法实现。提议尝试将这种改变融入到文化之中，采取这种不停进取的文化，勇于尝试新的东西，那么在需要更改方向的时候会变得愈加自然。总结这一章介绍了为何需要使用微服务架构，和哪些原因能够用来对实现次序进行排序。当企业在决议是否需要向微服务迁移时，需要回复三个问题：期望从微服务中取得什么?是否考虑过微服务之外的其它替换方案?怎么衡量迁移起到了成效?迁移过程可能会花费很长的时间，但实际工作中，用户不会给我们这么多的时间。迁移只有在公布到生产环境后才能表示一个阶段的结束。这就需要一系列的技术手段来让微服务应用和单体应用协同工作。接下来的内容就会对这些技术进行介绍。