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

从单体应用到微服务读后感.微服务介绍什么是微服务应用微服务是围绕一个业务领域建 模的可独立部署的服务。通过网络彼此交互。微服务是一种 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,以判 断一个迁移是否值得。微服务带来的好处主要有以下几点，但请 注意，带来的这些好处大部分都可以通过其它方式获得。提升团 队自治性非常多的企业证明了团队自治带来的好处。自治的团队 通常不会很大，确保团队内成员彼此都非常熟悉，自治团队在一 个较小的范围内工作。业界有一些关于团队规模的范例，如亚马 逊的两个披萨模型。如果正确使用团队自治性，会激发团队成员 成长并提升效率。当团队拥有微服务的全部控制权，就会提升团 队在整个组织中的自治性。自治性不是微服务独有的，有很多方 式可以获得自治。团队的自治主要涉及分配给团队的职责，而与 使用什么样的架构关系不大。比如可以通过将代码仓库中的一部 分授权给一个团队来促进团队的自治。加快上市时间将变更的执 行和部署聚焦到各自独立的微服务中，可以做到不用和其它服务 协调发布时间，同时多个团队可以并行的处理待办任务列表，这 让功能面世的时间大幅度加快。当然，不使用微服务也可以做到 加快上市时间。如优化上线流程等也会起到一定的效果。通过对 现有上线流程的分析，判断是否可以通过调整任务执行的顺序， 或者采用并行的方式来加快流程执行的速度。为负载更有效的扩 缩每个微服务都可以独立的进行扩缩，这样会更加有效。因为我 们只需要扩展对处理当前复杂有瓶颈的部分。当负载降低，可以 对这部分再进行缩容。如果不使用微服务，有很多方法可以应对 负载升高的情况。最简单的就是使用配置更高的机器。另外，传 统的通过多个单体应用的拷贝来进行水平扩展的方