文档介绍：
《从单体应用到微效劳》读后感
《从单体应用到微效劳》读后感
目的：共同学****共同进步、辞别码农，成为受人敬仰的、有态度的程序猿。回绝不知其所以然的复制粘贴、回绝人云亦云。用最严谨的态度、最专业的方法、最可靠的知识来，探究技术内幕下列图所示：
单体应用
什么是单体应用呢?单体应用的特征是系统的所有功能共同组成一个唯一的部署单元。通常单体应用分为三类：
单进程单体应用
模块化的单体应用
分布式的单体应用：分布式的单体应用由多个效劳组成，但是这些效劳必须同时部署。这种方式拥有分布式系统和单体系统的所有缺点，并且对于单纯的分布式系统和单体系统而言没有任何优势。所有的效劳都混乱的耦合在一起。一个效劳的变更就可能导致系统不可用。
第三方黑盒系统：我们可以将第三方的系统都视为单体应用。
单体系统的挑战
单体应用由于实现和部署耦合，更加的脆弱。假如有很多人在一起工作，可能会引发混乱。一些开发人员可能同时修改同一段代码，团队之间的工作互相依赖。微效劳提供的概念边界会更加容易地解决这些问题。
单体系统的优势
单体应用的部署拓扑比分布式系统简单的多，这样会让开发流程更加简单；并且在监控、排错和系统测试方面也要简单许多；单体系统内部的代码可以更简单的复用，这在微效劳中，可能意味着代码拷贝或者共享代码等权衡。很多人将单体系统视作老土的架构，视为应该被抛弃的架构，这是绝对是不正确的观点。
内聚和耦合
内聚的目的是将相关的代码放在一起，一起应对变更；而耦合那么表示对一个局部的修改会对其它局部造成影响。高内聚、低耦合会让架构保持稳定。单体应用通常是高耦合、低内聚的，各种不相关的代码都耦合在一起。当需要代码调整的时候，通常很困难。同时，松耦合在单体应用中实际并不存在，因为任何变动都需要将整个应用一起打包部署。在微效劳中，假如要想做的松耦合，一方面是保证自身的修改不需要改变其它局部，另一方面是保证接口的稳定。
我们需要慎重的考虑系统中的耦合，耦合可分为以下4类：
实现耦合：这是一种危害最大的耦合类型，但通常比拟容易处理。例如A效劳的实现依赖于B效劳如何实现，当B效劳需要修改时，A效劳需要同时修改。典型的例子是共享数据库，当A和B共享同一个数据库时，A对数据库的变更会直接影响B。
临时耦合：这种耦合发生在运行时，一般发生在分布式环境中的同步调用时。例如A效劳要同步地调用B效劳获取信息，而B效劳此时又需要同步地调用C效劳，这就构成一个临时耦合。这里问题是，恳求假设要成功，这三个效劳必须都正常运行并且可以互相调用。解决时可以考虑使用缓存或者异步消息。
部署耦合：不管代码是不是模块化的，假如在发布的时候需要打成一个包统一部署，这时就是部署耦合。部署耦合带来的问题一方面是需要协调各个团队的发布方案，另一方面，每次部署都会有风险，越大的部署范围风险也会越大。并且少量的代码更容易实现自动发布。
领域耦合：每个微效劳都处在一个领域限界上下文中，当它们之间的概念有交互时，就形成了领域耦合。例如效劳A中需要理解效劳B中的一个领域概念。实际上，效劳A中所需要的概念可能与效劳B中的不一样，例如仓库效劳需要访问订单效劳中的订单信息，实际上仓库效劳需要的订单信息可能只是订单编号，它不需要理解订单效劳中订单信息的全部业务概念。因此，仓库效劳应该维护一个在自己限界上下文内的订单信息实体。
领域驱动设计
前面介绍了我们为什么要围绕业务领域建模。那么详细如何做呢?这就是领域驱动设计〔DDD〕解决的问题。DDD介绍了一系列的思想来在程序中表示问题域。设计微效劳的重要概念有：
聚合：聚合是一个自包含的单元，表达了一个实际的业务概念。通常聚合拥有一个生命周期，这会让聚合的实现类似一个状态机。我们需要保证一个业务概念的状态转移完全被包含在一个聚合之中。一个微效劳会处理一个或多个聚合的生命周期和数据存储。将一个系统划分成聚合可能需要考虑众多因素，例如：性能问题、实现的难易程度等。这也意味着聚合可能会对聚合进展重新划分。在实际中，事件风暴非常有用。
限界上下文：限界上下文通常代表了组织中的一个较大范围的边界。这个边界内有单一的职责。从实现角度来看，一个限界上下文中有一个或多个聚合。这些聚合中的一些可能会对外暴露，另一些那么被内部隐藏。
将聚合和限界上下文映射成效劳
聚合和限界上下文都提供了高内聚的单元，并且提供设计良好的接口。聚合涉及一个单一领域概念的自包含状态机，而限界上下文那么代表一组相关的聚合。聚合和限界上下文都可以作为微效劳的边界。考虑到初期尽量减少效劳的数量，建议使用范围更大的限界上下文来作为微效劳边界，熟悉后，可以进一步使用聚合拆