Microservice架构模式简介

在讲解完这些子服务该如何展现给用户之后，我们就来讲解一下如何创建各个子服务所需要的公共服务。之前我们已经提到过，由于对公共服务的调用是一个跨进程调用，因此其相较于进程内调用效率非常低下。在这种情况下，我们需要尽量避免对该公共服务的重复调用。为了达到该目标，我们需要尽量使用户访问同一个子服务实例，并且在该用户的会话中缓存从公共服务中所得到的信息。

因此在同一个子服务的各个服务实例上，我们需要尽量使用负载平衡服务的Sticky Session的功能，并在一次公共服务调用中取得多项信息。例如在查看用户的权限时，我们不是返回用户是否具有特定权限，而是该用户拥有哪些权限。当然，这不仅仅需要从Microservice这种架构模式的方面来考虑，还需要同时兼顾安全，维护性等一系列问题。

简单地说，在兼顾其它方面的情况下，我们需要将公共服务API的粒度定得粗一些，同时也需要具有一定的灵活性，从而通过减少服务间调用来避免整个服务的性能瓶颈。

既然说到了API的粒度，那我们就需要讨论一下各个子服务所提供的API了。和公共服务一样，各个子服务所暴露的API也应该具有较粗的粒度以及较大的灵活性。除此之外，我们还需要让这些子服务所暴露的API具有尽量一致的样式，如定义一系列RESTful的API。在这种情况下，与这些服务进行交互的组成，如网页的UI，才能具有可以接受的维护性。

一个经验性的观点则是，Microservice架构模式中的“开”是各个服务的内部实现，而其中的“闭”则是各个服务之间相互沟通的方式。

如果您需要从头开始搭建一个服务，那么您需要首先考虑如何对这些服务进行划分，并在创建第一个服务的时候开始搭建出各个公共服务的雏形，同时确定各个服务之间沟通所需要遵守的协议。当越来越多的子服务被创建出来之后，您需要逐渐丰富各个公共服务所提供的功能，使其逐渐变为功能强大的，可重用的服务。