Microservice架构模式简介

因此在集中的公共服务中，我们需要使用较为细粒度的模型。该细粒度模型需要具有较高的灵活性，以能够无损地表示各个服务中的相应模型。

相信您现在已经能够看出，虽然说Microservice架构模式将单个子服务的实现简化了，但是复杂化了数据的处理。因此相较于我们以往所编写的应用，Microservice架构模式会在数据相关的一些特性上遇到一系列麻烦。

一个较为常见的麻烦就是保持多个子服务之间数据的一致性。我们知道，在服务中，保持一致性的工作常常是由事务来完成的。而如果希望在Microservice架构模式实现中保持子服务之间数据的一致性，我们可能就需要使用分布式事务了。但是分布式事务本身就是一个非常复杂并且难以操作的东西，因此就现在而言，这种问题实际上是非常难以解决的。但是反过来讲，事务本身也是表示一种逻辑上的强耦合，因此我们需要真正反思的则是这些需要使用事务来保持数据一致性的子服务是否应该属于同一个服务。当然，我们可以在某种程度上借鉴NoSQL数据库中的一些做法。例如在一个服务更新了数据以后，我们使用一种异步机制来保持数据的一致性，就好像很多NoSQL数据库不保证用户的数据立即可读一样。

另一个较为常见的麻烦就是粒度的问题。我们在前面已经说过，在Microservice的各个子服务之间进行服务间调用效率是十分低下的。为了减少多次服务间调用，各个子服务所提供的API的粒度需要尽量地粗，却需要尽量地保持灵活性。最好的情况就是可以通过一次服务间调用来得到所有想要的信息。

项目管理

除了上面所讨论的一系列技术因素之外，Microservice架构模式的开发还存在着一系列项目管理上的难题。

首先，由于Microservice架构模式中的各个子服务可能使用了不同的技术搭建，例如有些子服务是由Java开发的，有些则是由Python开发的，而且它们所使用的Servlet容器并不相同，因此由Microservice架构模式所搭建的应用可能需要非常复杂的环境设置。这对于传统的运维人员来说是非常困难的一个任务。而相对于这些运维人员而言，负责各个子服务开发的开发人员才是有关该服务运行及部署的专家。因此在Microservice架构模式中，开发及运维的职责均发生了变化：开发人员不仅仅需要负责子服务代码的编写，还需要考虑该子服务的日常运维。而运维人员需要向开发人员给出一些运维相关的建议，并在总的方向上掌控产品的日常运维。