Microservice架构模式简介

因此在一个基于Microservice架构模式的服务中，常常会出现一个前端服务。该服务所提供的页面会与各个服务沟通。但是它实际上与各个子服务之间却不需要通讯：

或许您会说，在这种情况下，我们的各个子服务就没有UI了。而UI服务不仅仅需要处理所有的前端业务逻辑，而且随着时间的推移，其可能会变成另外一个庞然大物。除此之外，如果希望整个平台能够允许第三方服务接入，那么这种打包在一起的UI服务将变成整个平台扩展性的阻碍。

是的。如果需要解决这个问题，那么您就需要在应用中尝试借鉴Service Locator模式。此时我们需要的则是一个UI框架，其允许用户通过特定方式在应用中插入各个子服务所提供的UI，并允许您通过一些机制来发现已经在平台中注册的具有特定功能的API，并允许您对该API进行调用。我相信，随着Microservice架构模式的不断发展，会有越来越多的支持这种扩展方式的UI类库出现。

另外一种模式则是Message Broker。简单地说，Message Broker就是一个消息的中转平台。该平台允许其它组成向其中注册消息，也允许其它组成侦听消息。当一个组成将一个消息发送到了Message Broker之上后，其它侦听该消息的各个组成则会根据消息中所包含的信息更新自己的状态。

反过来，如果您的服务需要支持移动设备，如手机，iPad等，我们就不能让这些移动设备一个一个地访问子服务了。这是因为这些移动设备的带宽一般来说都非常小，而且用户常常处于信号不是很好的地方，因此在向这些子服务一个个地发送请求将快速消耗掉它们所拥有的有限的带宽。为了解决这个问题，我们常常需要在这些子服务前搭建一个代理服务。该代理服务会将用户请求根据业务逻辑拆分为对各个子服务的请求，并将各个子服务所返回的结果归纳为一个响应返回给用户：

当然，上面所介绍的仅仅是当前论坛讨论中所常常提到的一种搭建基于Microservice架构模式应用的方式。或许在不久的将来，您会看到设计得越来越精巧的各种模式出现。