从单体应用到微服务读后感 目标：共同学习、共同进步、离别码农，成为受人敬仰的、有态度的程序猿。拒绝不知其因此然的复制粘贴、拒绝人云亦云。用最严谨的态度、最专业的方法、最可靠的知识，探究技术内幕，死磕到底！内容介绍原书名字是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，以判定一个迁移是否值得。微服务带来的好处关键有以下几点，但请注意，带来的这些好处大部分全部能够经过其它方法取得。提升团体自治性很多的企业证实了团体自治带来的好处。自治的团体通常不会很大，确保团体内组员相互全部很熟悉，自治团体在一个较小的范围内工作。业界有部分有关团体规模的范例，如亚马逊的“两个披萨”模型。假如正确使用团体自治性，会激发团体组员成长并提升效率。当团体拥有微服务的全部控制权，就会提升团