为什么我要开始开始研究微服务架构呢？

因为我最近见证着一个0行代码的系统发展到数万行代码无比臃肿的系统，本地重启应用的时间从毫秒级发展到10秒才能重启完成。并且随着需求的变更，系统会变得越来越复杂，模块间耦合只会越来越严重。也遇上一些系统，这系统某些模块为了加快响应预先加载大量数据到内存，如果整套系统做分布式处理，必然造成资源的浪费。而这些问题的一个可能的解决方案是微服务（注意微服务不是万能的，要根据实际确定是否采用）；

由于之前没有太多微服务架构的项目经验，只做过一些简单的一个系统拆分成多个系统的事情，拆开的系统通过http或者rabbitmq进行交互。所以现在决定深入研究一下微服务，研究必然需要站在大牛的肩膀上来吸收一些有用的理论，所以我买了一本《轻量级微服务架构 上集》这本书，下面记录下我读完每一章节的心得体会和一些摘要。

刚购买的书籍

全文概括

第一眼看了书籍的目录，发现用到的技术五分之三是我没接触过的，不过也正常，本书主要基于java和nodejs的技术栈来说明，而我深入研究的却是python方面的东西。不过本书起点不高，哪怕像我这种对java研究不深的人都能够轻易理解。而且本书采用的技术还算是比较新的技术，如用node.js代替nginx做反向代理，使用docker部署等。

什么是微服务

个人觉得，微服务就是把一个系统的各个模块独立成若干个小系统，这些小系统在代码上无依赖关系，只有在数据上有依赖关系，然后通过网络来进行数据交互。

微服务使用场景

技术使用场景是我每次决定上一个新的技术的时候考虑的问题，当然我对技术选型更关注的一个问题是稳定性和易用性，商用系统如果经常崩溃那就是灾难了，如果开发过程中找不到解决方案或者无法通过修改源码实现业务需求也是灾难性的。

下面这使用场景建议出处是作者在开源中国问答的回答

1. 应用变得越来越大时

2. 项目存在多种开发语言时

3. 感觉到经典架构模式太重时

4. 修改了一个 bug 需要平滑升级时

5. 想对系统进行细粒度监控时

为什么不延续旧的开发模式？

书中说到以下几个传统开发模式的缺点：

1. 做水平扩展的时候导致资源浪费

2. 随着模块越来越多，应用启动速度越来越慢，导致部署效率降低

3. 一个系统很难混杂多种开发语言，导致技术单一

微服务之间通讯

微服务由于存在调用关系，所以通讯避免不了，而网络通讯也无非是以下两种

1. 基于HTTP或者HTTPS调用（或者基于socket的其它协议）

2. 基于RPC调用

微服务优点

1. 能够把一个复杂的业务拆分成若干个简单的业务，使开发变得更加简单高效

2. 由于服务之间是隔离的，所以一个服务挂掉了不会影响别的服务，在安全性方面也有保证

微服务挑战

1. 由于拆分成很多系统，所以需要更高的运维技术支持，同时代码量必然增加

2. 由于微服务可能会散落在各台服务器，所以需要自动化部署，在某节点服务器崩溃的时候需要自动迁移应用

3. 由于系统之间调用多了，并且都是基于网络，资源消耗必然增加

我们需不需要上微服务呢？

下面仅仅是个人见解：

1. 如果开发的应用规模不大，还是传统模式开发，免得降低开发效率

2. 如果没有比较有水平的运维支持，还是不要上微服务了，系统多了维护必然是难题

3. 旧系统无需重构的时候，重构风险有点大，不是迫不得已还是别轻易动旧代码，反正本人已经受过不少重构的伤害了。

也许你会说，那微服务不是压根就没法用了吗，其实不然，换个角度想想，我们可以用伪微服务，例如我们把登录模块独立成一个oauth系统，然后别的系统都去调用也不错嘛。

一句建议：切勿一心用新技术，技术仅仅是为了解决各种业务上和系统上的问题而已，要合理采用各种技术。

总的来说《轻量级微服务架构 上集》还是值得看一下的，过几天再写一下后面章节的读书笔记。