文档介绍：《从单体应用到微服务》读后感
《从单体应用到微服务》读后感
目标：共同学****共同进步、告别码农，成为受人敬仰的、有态度的程序猿。拒绝不知其所以然的复制粘贴、拒绝人云亦云。用最严谨的态度、最专业可能是之前使用单体应用从来没遇到过的问题。因此，不应盲目的跟风新技术，应该使用自己最熟悉的技术来实现微服务应用。
大小
微服务应该有多大，这应该是最常被讨论的问题。要解答这个问
题，首先需要定义大小的衡量标准。常用的衡量标准如代码行数，
但这在微服务中是没有意义的，因为微服务是技术不可知论的，而
使用不同的编程语言实现同样的逻辑，代码行数差别是非常大的。
书中引述了一位微服务专家对微服务大小的建议是：“尽可能小的
接口”。实际上，微服务的大小在不同的上下文和人群中的感受是
不一样的，因此不必过于纠结微服务大小的问题。在考虑大小的时
候，最应该考虑的是以下两个问题： 1）你可以处理多少个服务。随
着服务的增多，系统也会变得更加复杂，需要团队学****更多的知识来应对；
2）服务的边界如何定义。不合适的边界划分最终可能会导致恐怖的耦合混乱。
所有权
传统的 IT 企业采用职能型的组织架构，软件的生命周期分别由不同的部门负责，如需求部门负责采集用户需求，开发部门收到需求部门输出的需求文档后进行软件开发。这种方式如下图所示：
图片
现在越来越多的企业将组织方式调整为矩阵型，提高沟通效率，加快开发速度。而微服务架构是围绕业务领域建模的，这非常适合矩阵型组织的沟通方式。组织可以使用微服务所代表的业务领域对组织进行划分，根据微服务的特性，团队之间也会减少跨团队的共享、最小化发布时的竞争。如下图所示：
单体应用
什么是单体应用呢 ?单体应用的特征是系统的所有功能共同组成一个唯一的部署单元。通常单体应用分为三类：
单进程单体应用
模块化的单体应用
分布式的单体应用：分布式的单体应用由多个服务组成，但是这些服务必须同时部署。这种方式拥有分布式系统和单体系统的所有缺点，并且对于单纯的分布式系统和单体系统而言没有任何优势。所有的服务都混乱的耦合在一起。一个服务的变更就可能导致系统不可用。
第三方黑盒系统：我们可以将第三方的系统都视为单体应用。
单体系统的挑战
单体应用由于实现和部署耦合，更加的脆弱。如果有很多人在一起工作，可能会引发混乱。一些开发人员可能同时修改同一段代码，团队之间的工作互相依赖。微服务提供的概念边界会更加容易地解决这些问题。
单体系统的优势
单体应用的部署拓扑比分布式系统简单的多，这样会让开发流程更加简单；
并且在监控、排错和系统测试方面也要简单许多；
单体系统内部的代码可以更简单的复用，这在微服务中，可能意味着代码拷贝或者共享代码等权衡。很多人将单体系统视作老土的架构，视为应该被抛弃的架构，这是绝对是不正确的观点。
内聚和耦合
内聚的目的是将相关的代码放在一起，一起应对变更；
而耦合则表示对一个部分的修改会对其它部分造成影响。高内聚、低耦合会让架构保持稳定。单体应用通常是高耦合、低内聚的，各种不相关的代码都耦合在一起。当需要代码调整的时候，通常很困难。同时，松耦合在单体应用中实际并不存在，因为任何变动都需要将整个应用一起打包部署。在微服务中，如果要想做的松耦合，一方面是保证自身的修改不需要改变其它部分，另一方面是保证接口的稳定。
我们需要谨慎的考虑系统中的耦合，耦合可分为以下 4 类：
实现耦合：这是一种危害最大的耦合类型，但通常比较容易处理。例如 A 服务的实现依赖于 B 服务如何实现，当 B 服务需要修改时， A 服务需要同时修改。典型的例子是共享数据库，当 A 和 B 共享同一个数据库时， A对数据库的变更会直接影响 B。
临时耦合：这种耦合发生在运行时，一般发生在分布式环境中的同步调用时。例如 A 服务要同步地调用 B 服务获取信息，而 B 服务此时又需要同步地调用 C服务，这就构成一个临时耦合。这里问题
是，请求若要成功，这三个服务必须都正常运行并且可以相互调用。
解决时可以考虑使用缓存或者异步消息。
部署耦合：不管代码是不是模块化的，如果在发布的时候需要打成一个包统一部署，这时就是部署耦合。部署耦合带来的问题一方面是需要协调各个团队的发布计划，另一方面，每次部署都会有风险，越大的部署范围风险也会越大。并且少量的代码更容易实现自动发布。