【Java微服务】一书第一章关键语句

概述

---

最近读了【Java微服务】一书，只有第一章看的比较认真，其他章节，如果对微服务已经有些了解的，可以大概浏览器一下就行。事实上，这本书写的最好的就是第一章。

下面把第一章中我觉得比较重要的语句摘录下来。

---

重要语句

---

可扩展性

随着整体式应用程序所有的部件都被打包在一起，它在扩展时是庞大的，需要扩展一切。例如，在餐馆订座应用程序中，即使你想要只扩展餐桌预定服务，也要扩展整个应用程序，而不能单独扩展餐桌预定服务。它未能以最佳方式利用资源。

微服务提供了只扩展那些需要扩展的服务的灵活性，它允许对资源的最优利用。

微服务开发使用REST式的web服务开发，REST服务器端是无状态的，使得在这个意义上，它是可扩展的，这意味着服务器之间没有太多的通信，从而它可水平扩展。

---

在出故障时回滚版本

---

很多人可能都曾遇到过由于一个功能故障，致使整个版本延迟发布的痛苦。

微服务给我们提供仅回滚那些出故障的功能的灵活性。假设在某个生产版本中发布新的功能、增强功能和bug修复后，你发现支付服务中有缺陷需要立即修复。由于你已经使用基于微服务的架构，可以仅回滚付款服务而不是回滚整个版本。这不仅允许你妥善处理故障，还有助于迅速向客户交付功能或者修补程序。

---

采用新技术的问题

---

整体式应用很难在开发的后期或在产品出于成熟的状态后引进新技术。技术在逐年进步。例如，你的系统可能会使用Java设计，几年后，因为业务需要或为了利用新技术的优势，你又想使用Ruby或Node JS开发新服务。整体式应用很难利用这些新技术。

微服务是小型、自包含的功能，所以它提供了低风险地尝试一项新技术的机会。而对整体式系统而言，绝对不能这样。

---

减轻开发工作量–可以做得更好

---

一般来说，大型整体式应用程序的代码是开发人员最难理解的，并且新开发人员需要相当长的时间，才能成为生产力。甚至把大型整体式应用程序加载到IDE中都是麻烦的，它会降低IDE运行速度，使开发人员的生产力降低。

大型整体式应用程序中的更改很难实施，并花费更多时间。这是由于有大量的代码库，并且，如果未恰当并彻底的执行影响分析，存在bug的风险会很高。因此，执行全面影响分析成为开发人员实施更改之前的先决条件。随着代码更改量的增加，与代码更改相关联的风险呈指数级上升。