Microservice架构模式简介

独立性也意味着扩展性的增强。在Microservice架构模式中，各个子服务可以根据自身的负载独立地进行扩容，如Scale Up或Scale Out等。不仅如此，我们还可以根据子服务自身的特性为其准备特定的硬件设备，使得其运行在更适合的服务器上。同时这种独立性还可以使得各个子服务可以被重用。

同时这种独立性也可以增加整个服务的容错能力。例如如果一个子服务由于种种原因无法继续提供服务，其它子服务仍然可以独立地处理用户的请求。

另外，各个子服务的独立部署能力也可以大大地提高Continuous Delivery的运行效率。毕竟在这种情况下，软件开发人员只需要重新部署更改过的子服务就可以了。

由于Microservice架构模式中的各个子服务无论是在代码量方面还是最终生成的WAR包方面都较Monolith架构所搭建的服务小，因此在IDE支持，启动速度方面都具有相当的优势。同时，这种小粒度的服务已经可以由一个几个人所组成的小组来完成，而不再需要通过来自世界各地的不同小组协同开发，进而大大降低了沟通成本，提高了开发的效率。

但是反过来，Microservice架构模式中各个子服务的独立性也会导致一系列问题。最明显的就是需要多个子服务相互配合的情况。由于这些子服务是不同的进程，因此在这些进程之间保持数据的一致性，或添加一个新的跨子服务的用户用例实际上都是一件非常麻烦的事情。而且对这些独立服务在整个系统中是否能够工作的测试需要运行大量的集成测试。而如果需要快速地对这些子服务进行开发和迭代，那么我们就需要每个开发人员都能够专业并高效地使用一系列自动化工具。这实际上也是一个不低的要求。

除此之外，基于性能考虑，各个子服务所提供的接口将是粗粒度的，却具有较高灵活性的API。但是这种API拥有一个较明显的缺陷，那就是越灵活的API，其使用起来的难度就越大。因此对于服务的用户而言，其上手的难度则相对增加了。