《微服务设计》读后感

这本书是2016年出版，到现在已经有4年时间。这几年，技术的浪潮一波未平一波又起，而此刻翻看这本书，是不是已经过时呢？看完后，我认为并没有。书中的一些观点，还是给我带了很多启发。以下是我的读后感。



首先这本书，并不适合新手阅读。这本书，并不是在讲解什么硬核的编程技能，相反，这本书偏理论，同时作者的文字写得也很简练，这会导致，读者在阅读这本书时，需要有一定的专业基础，最好有一些系统改造的经历，以及对分布式系统的构建也有些了解。不过，这本书的优点在于，篇幅不长，只有200页左右，章与章之间的联系不大，可以有选择性的阅读。



看完整本书，如果只想留下一句话，我认为是作者在本书最后一章说的那句：“微服务是一个旅程，而不是终点，我们要持续地改变和演进系统”。演进式的架构设计思想是本书最核心的思想。



本书主要围绕以下两个主题展开：

1. 什么是微服务？

2. 怎么构建微服务？

1. 什么是微服务

首先，当我们在谈“微服务”的时候，需要注意下语境，因为，有时它代表的是一个分布式系统解决方案，而有时它又代表着一个独立自治的应用。前者偏向的是系统架构，后者偏向的是独立应用。



书中，作者对“微服务”的定义是：一些协同工作的小而自治的服务。而我个人理解，由这些“小而自治的服务”组成的大分布式系统，可以说它是一种微服务架构。而通过作者的定义可以看出，微服务有两个关键的特性：

1. 足够小

2. 自治性



多小，才能算是足够小呢？有如下三种观点：

1. 第一种观点：该服务可以在两周内重写。

2. 第二种观点：小相对于大而言，当你认为，这个服务不能再进行拆分的时候，那就到了足够小。

3. 第三种观点：小到可以由一个团队独自维护。这跟亚马逊说的“两个披萨”原则有点类似。



自治性又是指什么呢？作者认为，核心在于独立部署。而独立部署可以引发出：独立的代码库、独立的应用、独立的数据库、标准的API交互等一系列事情。



而做微服务的好处又是什么？如果非要抽象总结的话，我认为是“高内聚、松耦合”，再具体点是指：

1. 技术栈可以独立选择

2. 整体系统的扩展性将更好

3. 每个服务的部署也比较方便，不再受制于其他服务

4. 团队组成比较简单，易于沟通和管理

2. 怎么构建微服务？

如何构建微服务，其实是一个非常大的话题，不过，我们可以把这个构建的过程，看成是一个微服务的生命周期，而它大概分成如下几个步骤：建模、开发与集成、测试、部署、监控。其实，本书也是围绕这几个方面在展开，而其中，最为重要的就是“建模”。



“建模”其实是对大的系统或业务进行归纳、抽象并拆分的过程。而拆分的前提是做职责划分，而职责划分的前提是你必须熟悉业务场景。当你不了解时，不要草率进行系统拆分，作者建议，如果你是从头开始构建一个系统，最好是先构建单个系统，当稳定以后再进行拆分。



如果非要给些建议的话，可以从如下两个方面考虑：

1. 从业务功能出发，把提供相同功能的划分在一起。需要注意的是，当多个功能依赖同一份数据时，这并不能说明这些功能一定要划分到同一个模块中。

2. 开始的时候，可以从大的方面，做粗粒度拆分。



当模块划分好以后，就需要构建模块之间的交互与模块内的设计，这就是开发与集成。不过，这里可以使用设计模式的思想去完成。当开发完成后，涉及到后续的测试与部署。因为大的系统被拆分，测试与部署的工作量也就成倍的增加，因此，微服务架构下，需要做到自动化的测试与部署。除此之外，监控也是必须要具备的。书中列举了一些“部署、测试、监控、安全”的介绍，我认为它并不深入，大都是宏观面的介绍，只能当做了解。这里就不展开这些话题的细节部分。



从上面可以看出，构建微服务应用并不轻松。首先，它就得需要一套完善的基础设备，包括：自动化部署、测试、监控、熔断、消息队列、RPC等等，而这些基础设施的建立，往往需要较大的长期投入，不过好在现在开源社区有一些全家桶的解决方案，同时云厂商也已经提供了一些商用服务，但是也得耗费人力和财力。所以，微服务也并不是一切场景都适用。这也正如：软件开发没有银弹，每个问题都需要特定的解决方案。

3. 总结

我认为微服务的最大好处是服务自治。它让单个服务自我运转、自我迭代，同时它又能把自己插拔到整个大的系统当中。而这种服务自治，一方面，它能很好的提高开发效率，另一方面，它又能很好的适应快速的需求变化。



其次，构建微服务需要从业务场景出发，做好模块划分，不要划分的过细，实在不行，可以先构建成单个系统，等稳定后在拆分。最后，想要使用微服务，你的需要一个一些强大的基础设施做支撑，例如：部署、测试、监控等。