Microservice架构模式简介

如果您已经拥有一个Monolith服务，并且希望通过采用Microservice架构模式来缓解当前Monolith模式服务所具有的一系列问题，那么您首先需要创建一个独立的服务，并通过一个粘合层来与该Monolith服务交互。在该过程中，您可能需要将Monolith服务的内部接口逐渐暴露出来，以供这个新的服务使用。而这就是在抽象公共服务的过程。

接下来，您就需要根据上一步中所得到的接口来逐步将Monolith服务中的公共服务剥离。在剥离过程中，您脑中需要记得的一句话还是：粗粒度，灵活的API。而其内部实现到底是什么样的，实际上并不会影响到您的剥离结果。

最后就是再从Monolith中剥离其它服务了。此时我们最需要考虑的就是在服务中具有鲜明特点的各个服务，如对资源的要求与整个Monolith服务格格不入，或者使用了和Monolith很难兼容的技术等。

最后一种情况就是多个服务集成的情况。在产品的逐渐迭代过程中，我们常常会遇到需要将多个产品集成成为一个产品以提高整体竞争力的情况。这常常发生在盈利产品和其它非盈利产品之间。而这正是实践Microservice架构模式的绝佳机会。此时我们仅仅需要暴露一系列Monolith服务中的接口并创建粘合层即可。

Microservice的优点与劣势

好，在前面我们已经讲解了很多有关Microservice架构模式的经验性方法和相关知识。那我们现在回顾一下Microservice所具有的一系列优点和劣势，以使您能够在采用Microservice架构模式之前全面地衡量该方案所可能得到的好处及遇到的困难。

首先，由于Microservice架构模式中的每个子服务都可以独立于其它服务执行，因此其常常具有更好的服务边界。而这个明确的服务边界则会带来一系列好处：在Microservice架构模式中，各个子服务执行所需要的业务逻辑都相对集中于子服务内。因此其实现代码相对容易理解，并且便于维护。另外各个子服务所具有的结构，运行流程及数据模型都能够更贴近于子服务所表示的业务逻辑，因此在代码的开发速度和维护性上得到了大大地增强。同时各个子服务可以选择最适合实现业务逻辑的技术，进而使得各个服务的开发变得更为容易。同时在出现新的更适合的技术时，我们可以较为容易地在各个子服务内部对原有的实现技术进行替换。