关于服务的集成——微服务设计学习篇

前言

微服务之间如何集成应该可以说是微服务相关技术中最重要的知识之一。具体可以表示成服务之间的调用方式、通信协议、序列化协议等。 如果服务集成做得好，你的微服务可以最大程度地保持自治，你可以独立地修改和发布，相反，前期考虑得不周全的话，会给你带来灾难。

一、对于集成技术的期望

服务集成的方式方法如此非常的多样化，我们如何在纷杂的技术中选出最适合的？

首先，我们要知道我们想要从这些集成技术中得到什么？我们期望的效果是怎么样的。这样，我们才能有目的去选型。虽然根据业务不同会有不同的考虑，但是我们总希望得到这么几点的好处：

1. 避免破坏性的修改

我们不希望当我们对某一个服务进行修改发布的时候，需要对该服务的消费者们也进行修改发布。我们希望选用的技术能够尽量避免破坏性修改的发生。比如，一个微服务在一个响应中添加了某个字段，已有的消费者不应该受到影响。

2. 服务通信的技术无关性

干我们这一行的，应该最清楚这个领域唯一不变的就是不断地变化。

新的工具、框架、语言层出不穷。比如现在的你是一个Java开发者，可能几年后你会想尝试Go语言这种更适合云原生应用的语言来构建微服务。

微服务灵活开放的特性来自于构建微服务的技术异构性，但是集成技术的选用不当，就会对微服务的具体实现技术产生限制。保证微服务之间通信方式的技术无关性是非常重要的。这就意味着，不应该选择那种对微服务的具体实现技术有限制的集成方式。

3. 服务易于消费方使用

消费方应该能很容易地使用我们的服务。如果消费方使用该服务比登天还难，那么无论该微服务多漂亮都没有任何意义。

理想情况下，消费方应该可以使用任何技术来实现，从另一方面来说，提供一个客户端库也可以简化消费方的使用。但是通常这种库与其他我们想要得到的东西不可兼得。举个例子，使用客户端库对于消费方来说很方便，但是会造成耦合的增加。

（这一点常常会前面两点冲突起来）

4. 隐藏内部实现细节

服务的内部实现细节应该最大程度地隐藏起来，不暴露出来。这也是从解耦的角度出发的。

所有倾向于暴露内部实现细节的技术都不应该被采用。

二、服务通信方式

服务之间的方式可以分为同步通信和异步通信两种方式。

如果使用同步通信，发起一个远程服务调用后，调用方会阻塞自己并等待整个操作的完成。如 RPC，HTTP调用。

如果使用异步通信，调用方不需要等待操作完成就可以返回，甚至可能不需要关心这个操作完成与否。如MQ