关于java:微服务必须具备的-3-个基本功能

作者：fredalxin\
地址：https://fredal.xin/talking-ms…

在咱们对微服务架构有了整体的意识，并且具备了服务化的前提后，一个残缺的微服务申请须要波及到哪些内容呢？

这其中包含了微服务框架所具备的三个基本功能：

• 服务的公布与援用
• 服务的注册与发现
• 服务的近程通信

服务的公布与援用

首先咱们面临的第一个问题是，如何公布服务和援用服务。具体一点就是，这个服务的接口名是啥，有哪些参数，返回值是什么类型等等，通常也就是接口形容信息。

常见的公布和援用的形式包含:

• RESTful API / 申明式 Restful API
• XML
• IDL

一般来讲，不论应用哪种形式，服务端定义接口与实现接口都是必要的，例如：

@exa(id = "xxx")
public interface testApi {@PostMapping(value = "/soatest/{id}")
    String getResponse(@PathVariable(value = "id") final Integer index, @RequestParam(value = "str") final String Data);
    }
    
}

具体实现如下:

public class testApiImpl implements testApi{

    @Override
    String getResponse(final Integer index, final String Data){return "ok";}
    
}

申明式 Restful API

这种常应用 HTTP 或者 HTTPS 协定调用服务，相对来说，性能稍差。

首先服务端如上定义接口并实现接口，随后服务提供者能够应用相似 restEasy 这样的框架通过 servlet 的形式公布服务，而服务消费者间接援用定义的接口调用。

除此之外还有一种相似 feign 的形式，即服务端的公布依赖于 springmvc controller，框架只基于客户端模板化 http 申请调用。这种状况下需接口定义与服务端 controller 协商一致，这样客户端间接援用接口发动调用即可。

XML

应用公有 rpc 协定的都会抉择 xml 配置的形式来形容接口，比拟高效，例如 dubbo、motan 等。

同样服务端如上定义接口并实现接口，服务端通过 server.xml 将文件接口裸露进来。服务消费者则通过 client.xml 援用须要调用的接口。

但这种形式对业务代码入侵较高，xml 配置有变更时候，服务消费者和服务提供者都须要更新。

IDL

IDL 是接口描述语言，罕用于跨语言之间的调用，最罕用的 IDL 包含 Thrift 协定以及 gRpc 协定。例如 gRpc 协定应用 Protobuf 来定义接口，写好一个 proto 文件后，利用语言对应的 protoc 插件生成对应 server 端与 client 端的代码，便可间接应用。

然而如果参数字段十分多，proto 文件会显得十分大难以保护。并且如果字段常常须要变更，例如删除字段，PB 就无奈做到向前兼容。

一些 tips

不论哪种形式，在接口变更的时候都须要告诉服务消费者。消费者对 api 的强依赖性是很难防止的，接口变更引起的各种调用失败也非常常见。所以如果有变更，尽量应用新增接口的形式，或者给每个接口定义好版本号吧。

在应用上，大多数人的抉择是对外 Restful，对内 Xml，跨语言 IDL。

一些问题

在理论的服务公布与援用的落地上，还会存在很多问题，大多和配置信息相干。例如一个简略的接口调用超时工夫配置，这个配置应该配在服务级别还是接口级别？是放在服务提供者这边还是服务消费者这边？

在实践中，大多数服务消费者会疏忽这些配置，所以服务提供者本身提供默认的配置模板是有必要的，相当于一个预约义的过程。每个服务消费者在继承服务提供者预约义好的配置后，还须要可能进行自定义的配置笼罩。

然而，比方说一个服务有 100 个接口，每个接口都有本身的超时配置，而这个服务又有 100 个消费者，当服务节点产生变更的时候，就会产生 100*100 次注册核心的音讯告诉，这是比拟可怕的，就有可能引起网络风暴。

服务的注册与发现

假如你曾经公布了服务，并在一台机器上部署了服务，那么消费者该怎么找到你的服务的地址呢？

兴许有人会说是 DNS，但 DNS 有许多缺点：

• 保护麻烦，更新提早
• 无奈在客户端做负载平衡
• 不能做到端口级别的服务发现

其实在分布式系统中，有个很重要的角色，叫注册核心，便是用于解决该问题。

应用注册核心寻址并调用的过程如下:

• 服务启动时，向注册核心注册本身，并定期发送心跳汇报存活状态。
• 客户端调用服务时，向注册核心订阅服务，并将节点列表缓存至本地，再与服务端建设连贯 (当然这儿能够 lazy load)。发动调用时，在本地缓存节点列表中，基于负载平衡算法选取一台服务端发动调用。
• 当服务端节点产生变更，注册核心能感知到后告诉到客户端。

注册核心的实现次要须要思考以下这些问题:

• 本身一致性与可用性
• 注册形式
• 存储构造
• 服务衰弱监测
• 状态变更告诉

一致性与可用性

一个老旧的命题，即分布式系统中的 CAP(一致性、可用性、分区容错性)。咱们晓得同时满足 CAP 是不可能的，那么便须要有取舍。常见的注册核心大抵分为 CP 注册核心以及 AP 注册核心。

CP 注册核心

比拟典型的就是 zookeeper、etcd 以及 consul 了，就义可用性来保障了一致性，通过 zab 协定或者 raft 协定来保障一致性。

AP 注册核心

就义一致性来保障可用性，感觉只能列出 eureka 了。eureka 每个服务器独自保留节点列表，可能会呈现不统一的状况。

从实践上来说，仅用于注册核心，AP 型是远比 CP 型适合的。可用性的需要远远高于一致性，一致性只有保障最终统一即可，而不统一的时候还能够应用各种容错策略进行补救。

保障高可用性其实还有很多方法，例如集群部署或者多 IDC 部署等。Consul 就是多 IDC 部署保障可用性的典型例子，它应用了 wan gossip 来放弃跨机房状态同步。

注册形式

有两种与注册核心交互的形式，一种是通过利用内集成 sdk，另一种则是通过其余形式在利用外间接与注册核心交互。

利用内

这应该就是最常见的形式了，客户端与服务端都集成相干 sdk 与注册核心进行交互。例如抉择 zookeeper 作为注册核心，那么就能够应用 curator sdk 进行服务的注册与发现。

利用外

consul 提供了利用外注册的解决方案，consul agent 或者第三方 Registrator 能够监听服务状态，从而负责服务提供者的注册或销毁。而 Consul Template 则能够做到定时从注册核心拉取节点列表，并刷新 LB 配置（例如通过 Nginx 的 upstream），这样就相当于实现了服务消费者端的负载平衡。

存储构造

注册核心存储相干信息个别采取目录化的层次结构，个别分为服务 - 接口 - 节点信息。

同时注册核心个别还会进行分组，分组的概念很广，能够是依据机房划分也能够依据环境划分。

节点信息次要会包含节点的地址 (ip 和端口号)，还有一些节点的其余信息，比方申请失败的重试次数、超时工夫的设置等等。

当然很多时候，其实可能会把接口这一层给去掉，因为思考到接口数量很多的状况下，过多的节点会造成很多问题，比方之前说的网络风暴。

服务衰弱监测

服务存活状态监测也是注册核心的一个必要性能。在 zookeeper 中，每个客户端都会与服务端放弃一个长连贯，并生成一个 session，在 session 过期周期内，通过客户端定时向服务端发送心跳包来检测链路是否失常，服务端则重置下次 session 的过期工夫，如果 session 过期周期内都没有检测到客户端的心跳包，那么就会认为它曾经不可用了，将其从节点列表中移除。

状态变更告诉

在注册核心具备服务衰弱检测能力后，还须要将状态变更告诉到客户端。在 zookeeper 中，能够通过监听器 watcher 的 process 办法来获取服务变更。

服务的近程通信

在下面，服务消费者曾经正确援用了服务，并发现了该服务的地址，那么如何向这个地址发动申请呢？要解决服务间的近程通信问题，咱们须要思考一些问题：

• 网络 I / O 的解决
• 传输协定
• 序列化形式

网络 I / O 的解决

简略来说，就是客户端是怎么解决申请？服务端又是怎么解决申请的？

先从客户端来说，咱们创立连贯的机会能够是从注册核心获取到节点信息的时候，但更多时候，咱们会抉择在第一次申请发动调用的时候去创立连贯。此外，咱们往往会为该节点保护一个连接池，进行连贯复用。

如果是异步的状况下，咱们还须要为每一个申请编号，并保护一个申请池，从而在响应返回时找到对应的申请。当然这并不是必须的，很多框架会帮咱们干好这些事件，比方 rxNetty。

从服务端来说，解决申请的形式就能够追溯到 unix 的 5 种 IO 模型了。咱们能够间接应用 Netty、MINA 等网络框架来解决服务端申请，或者如果你有非常的趣味，能够本人实现一个通信框架。

传输协定

最常见的当然是间接应用 Http 协定，应用单方无需关注和理解协定内容，不便间接，但天然性能上会有所折损。

还有就是目前比拟炽热的 http2 协定，领有二进制数据、头部压缩、多路复用等许多低劣个性。但从本身的实际上看，http2 要走到生产仍有一段距离，一个最简略的例子，降级到 http2 后所有的 header names 都变成小写，同时不是 case-insenstive 了，这时候就会有兼容性问题。

当然如果谋求更高效与可控的传输，能够定制公有协定并基于 tcp 进行传输。公有协定的定制须要通信单方都理解其个性，设计上还须要留神预留好扩大字段，以及解决好粘包分包等问题。

序列化形式

在网络传输的前后，往往都须要在发送端进行编码，在服务端进行解码，这样次要是为了在网络传输时候缩小数据传输量。

罕用的序列化形式包含文本类的，例如 XML/JSON，还有二进制类型的，例如 Protobuf/Thrift 等。在抉择序列化的思考上，一是性能，Protobuf 的压缩大小和压缩速度都会比 JSON 快很多，性能也更好。二是兼容性上，相对来说，JSON 的前后兼容性会强一些，能够用于接口常常变动的场景。

在此还是须要强调，应用每一种序列化都须要理解过其个性，并在接口变更的时候拿捏好边界。例如 jackson 的 FAIL_ON_UNKNOW_PROPERTIES 属性、kryo 的 CompatibleFieldSerializer、jdk 序列化会严格比拟 serialVersionUID 等等。

近期热文举荐：

1.1,000+ 道 Java 面试题及答案整顿 (2021 最新版)

2. 终于靠开源我的项目弄到 IntelliJ IDEA 激活码了，真香！

3. 阿里 Mock 工具正式开源，干掉市面上所有 Mock 工具！

4.Spring Cloud 2020.0.0 正式公布，全新颠覆性版本！

5.《Java 开发手册（嵩山版）》最新公布，速速下载！

感觉不错，别忘了顺手点赞 + 转发哦！