Microservice架构模式简介

然而使用特定技术并不会绕过开发中所能遇到的所有难点。由于在Microservice架构中，各个子服务都集中精力处理本身的业务逻辑，而所有的公共功能都交由公共服务来完成，因此公共服务在保持和各个子服务的松耦合性的同时还需要提供一个足够通用的，能够在一定程度上满足所有当前和未来子服务要求的解决方案。而这也是导致Microservice架构模式在开发初期会具有较低效率的另外一个原因。

而在开发的后期，随着Monolith模式中应用的功能逐渐变大，增加一个新的功能会影响到该应用中的很多地方，因此其开发效率会越来越差。反过来，由于Microservice架构模式中的各个子服务所依赖的公共服务已经完成，而且子服务本身可以选择适合自己的实现技术，因此子服务的实现通常只需要关注自身的业务逻辑即可。这也是Microservice架构模式在后期具有较高效率的原因。

当我们再次通过Microservice架构模式搭建应用的时候，其在开发时的效率劣势也将消失，原因就是因为在前一次基于Microservice架构模式开发的时候，我们已经创建过一次公共服务，因此在这个新的应用中，我们将这些公共服务拿来并稍事改动即可：

从上图中可以看到，虽然我们仍然需要花一些时间来对公共服务进行一些修改，但是此时所导致的效率下降已经不再那么明显了。也就是说，就算是在前期，我们已经拥有了较高的开发效率。

而且随着Microservice架构模式的不断流行，在网络上会有越来越多的用户共享自己的公共服务解决方案。那么第一次按照Microservice架构模式编写应用所导致的性能下降也会逐渐变得越来越小。

模型匹配

OK。在介绍了共享服务之后，我们就可以讨论Microservice架构模式中的另外一个问题：模型匹配了。在Microservice中，各个服务是彼此独立的，而且是关注于自身业务逻辑的。因此在看待一个事物的时候，Microservice可能拥有不同的视角，进而造成了各个子服务中的对应模型并不匹配。