《从单体应用到微服务》读后感
目标：共同学习、共同进步、告别码农，成为受人敬仰的、有态度的程序猿。拒绝不知其所以然的复制粘贴、拒绝人云亦云。用最严谨的态度、最专业的方法、最可靠的知识来源，探究技术内幕，死磕到底！！！
内容简介
原书名字是《Monolith To Microservices》，是大神Sam Newman的新书，目前还没有中文版本。原本是想写一个简短的读后感的，但是写着写着，发现书中的内容真的是太经典了，浅尝辄止的描述完全不能体现本书的价值。于是就改成了用我自己的语言对书中每一章的内容进行了精炼。因此这个读后感也可以作为原书的精简版来看，只不过用的是我自己的语言总结的。也是由于这个原因，这篇文章越写字数越多，最后接近三万字，花费的时间也很多。为了便于阅读，分成4部分来发。
注：本文中的图片截自原书
第一章、微服务介绍
什么是微服务应用?
微服务是围绕一个业务领域建模的可独立部署的服务。通过网络彼此交互。微服务是一种SOA架构，并且它是技术不可知论的，即：微服务并不要求使用特定的技术。这点需要重点强强调下，因为很多人采用微服务都是技术驱动的，这种认识不是非常合适。微服务通过网络端点互相访问，这让微服务具有分布式系统的特点。下面罗列一些微服务的核心思想：
独立可部署性
这本书认为微服务最重要的特性就是独立可部署性。这要求微服务在部署自身的时候，不依赖任何其它服务。为了保证独立可部署性，因此需要服务之间松耦合、服务之间使用稳定的协议交互数据。
围绕一个业务领域建模
传统的单体应用中，我们最常用的架构是分层架构，如将系统分为展示层、业务层和数据层。根据康威定律：任何设计系统的组织，都会产生这样一个设计，即该设计的结构与该组织的沟通结构相一致。因此在分层架构中，不同技术角色的人员被分配在一起工作，如前端组、后端组和DBA组等。这是一种以技术视角设计的架构。在微服务中，则是围绕业务领域的，将一个大的业务领域划分成若干尽可能独立的子域，每个子域自己可以是分层架构的。根据康威逆定律，这样的架构势必也会影响到组织的沟通方式的变化。
拥有自己数据的所有权
微服务的核心思想之一是不使用共享的数据库，每个服务唯一的拥有自身数据的控制权。这可以让服务决定公开哪些数据和隐藏哪些数据。这进一步要求了微服务之间需要维护稳定的接口协议。对数据的控制会促进服务做到高内聚，而通过隐藏自身数据又可以促进服务间的松耦合。
微服务带来的优势
微服务带来的优势很多。天生的可独立部署性可以促进系统的伸缩性和鲁棒性，并且可以混合使用多种技术。通过服务和团队的划分，每个服务都是独立演进的，也就是说，所有的服务都可以并行开发，服务的开发团队也将专注于一个特定的业务领域，不受其它业务领域的影响。
虽然微服务带来了很多优势，但是这并不代表可以免费的使用微服务。另一方面，微服务的优势中，针对某个方面可能还有其它替代方面，而并非只能使用微服务来获得。因此在应用微服务架构时，非常重要的一点是需要明确自身想从微服务中获得哪些好处。
微服务带来的问题
计算机的价格越来越低，这让SOA架构广泛的被应用。使用SOA可以将系统分布在多台计算机上。但这带来的挑战是服务之间的网络通信问题。网络连接是不稳定的，尤其是考虑延迟的时候，延迟会让整个系统变得不可预测，除此之外，还需要额外处理网络错误的情况。分布式的部署结构会让一切变得复杂起来。某种意义上说，单体应用也存在一些分布式的场景，例如：数据库在一台服务器上，另一台服务器上的程序从数据库服务器读取数据，而客户端使用一台电脑访问程序获取数据。在这个场景中已经出现了3台电脑间的网络通信。单体应用和微服务在分布式上的差别主要在分布的程度上，微服务会使用更多的主机、更多的网络通信。开始的时候，微服务的规模较小，问题可能看起来并不十分严重，但随着微服务规模的逐渐增多，出现问题的频率和难度也会逐步上升。为了解决微服务带来的分布式问题，将会花费很多的真金XXX。这也是在打算使用微服务架构时需要考虑的一点：是否值得?
用户界面
使用微服务架构的一个误区是只对服务端程序进行微服务架构，而依然采用单体应用来作为展示层提供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，以判断一个迁移是否值得。
微服务带来的好处主要有以下几点，但请注意，带来的这些好处大部分都可以通过其它方式获得。
提升团队自治性
非常多的企业证明了团队自治带来的好处。自治的团队通常不会很大，确保团队内成员彼此都非常熟悉，自治团队在一个较小的范围内工作。业界有一些关于团队规模的范例，如亚马逊的“两个披萨”模型。如果正确使用团队自治性，会激发团队成员成长并提升效率。当团队拥有微服务的全部控制权，就会提升团队在整个组织中的自治性。
自治性不是微服务独有的，有很多方式可以获得自治。团队的自治主要涉及分配给团队的职责，而与使用什么样的架构关系不大。比如可以通过将代码仓库中的一部分授权给一个团队来促进团队的自治。
加快上市时间
将变更的执行和部署聚焦到各自独立的微服务中，可以做到不用和其它服务协调发布时间，同时多个团队可以并行的处理待办任务列表，这让功能面世的时间大幅度加快。
当然，不使用微服务也可以做到加快上市时间。如“优化上线流程”等也会起到一定的效果。通过对现有上线流程的分析，判断是否可以通过调整任务执行的顺序，或者采用并行的方式来加快流程执行的速度。
为负载更有效的扩缩
每个微服务都可以独立的进行扩缩，这样会更加有效。因为我们只需要扩展对处理当前复杂有瓶颈的部分。当负载降低，可以对这部分再进行缩容。
如果不使用微服务，有很多方法可以应对负载升高的情况。最简单的就是使用配置更高的机器。另外，传统的通过多个单体应用的拷贝来进行水平扩展的方案也是非常有效的，虽然它对于数据库的瓶颈没有帮助。
本文档由网友提供，仅限参考学习，如有不妥或产生版权问题，请联系我们及时删除。
客服请联系：31998589@qq.com 微信：skillupvip
评论 (1)
点赞 (1)
收藏 (0)