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