Microservice架构模式简介

在使用Microservice架构模式的情况下，软件开发人员可以通过编译并重新部署单个子服务的方式来验证自己的更改，而不再需要重新编译整个应用，从而节省了大量的时间。同时由于每个子服务是独立的，因此各个服务内部可以自行决定最为合适的实现技术，使得这些子服务的开发变得更为容易。最后如果当前系统的容量不够了，那么我们只需要找到成为系统瓶颈的子服务，并扩展该子服务的容量即可：

Microservice经验谈

以上就是对Miscroservice架构模式的介绍，是不是很简单？实际上，这是一个正在发展的架构模式。在众多讨论中，关于该模式的标准实现，以及最佳实践等众多话题并没有完全达成一致。因此我在这里介绍的，是各个论坛讨论中基本达成一致意见的一系列经验。而各位在实现自己的Microservice架构模式时，一方面可以借鉴这些经验，另一方面也可以根据项目本身需求调整Microservice架构模式的实现方法。

转变你的视角

无论是在编写一个服务，还是在编写一个桌面应用，我们常常会首先尝试将需要实现的功能分割为一系列组件，并围绕着这些组件设计完成业务逻辑所需要的工作流及数据流。这种设计方法将导致实现业务逻辑的所有组件都运行在同一个进程之内，并且各个业务逻辑的实现也在同一个进程之内运行：

但是在Microservice架构模式中，我们需要更高一层的分割：在尝试将需要实现的功能分割成为一系列组件之前，我们首先需要考虑如何将需要实现的功能交由彼此相互独立的一系列服务来完成。例如在一个电子商务网站中，对用户购买商品这一业务流程的支持就可以交由三个服务来完成：在用户浏览商品的时候，其使用的是商品浏览服务；在用户将商品添加到购物车并生成订单的时候，其使用的是订单服务；而在用户进行网上支付的时候，其使用的则是付款服务。根据这种分割思路，我们的应用将运行在三个独立的进程之中：

同时这三种服务各自的侧重点并不相同：商品浏览服务中，对数据库的读操作比写操作多得多，因此对读操作进行优化将非常显著地提高服务的运行性能；而订单服务则是写操作居多，因此我们需要对订单的写入性能进行优化；付款服务涉及到用户的财产，因此其对安全要求会偏高一些。这种差异可能导致最适合实现这三个服务的技术各不相同。由于这些服务是完全独立的，因此我们完全可以根据子服务的需求来决定所需要使用的技术，而不再需要考虑这些类库是否与已有系统兼容。