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