一次正常的服务调用的流程
- 首先服务提供者（就是提供服务的一方）按照一定格式的服务描述，向注册中心注册服务，声明自己能够提供哪些服务以及服务的地址是什么，完成服务发布。
- 接下来服务消费者（就是调用服务的一方）请求注册中心，查询所需要调用服务的地址，然后以约定的通信协议向服务提供者发起请求，得到请求结果后再按照约定的协议解析结果。
- 而且在服务的调用过程中，服务的请求耗时、调用量以及成功率等指标都会被记录下来用作监控，调用经过的链路信息会被记录下来，用于故障定位和问题追踪。在这期间，如果调用失败，可以通过重试等服务治理手段来保证成功率。
微服务架构下，服务调用主要依赖下面几个基本组件：
- 服务描述
- 注册中心
- 服务框架
- 服务监控
- 服务追踪
- 服务治理
服务描述
对外提供了一个服务，那么这个服务的服务名叫什么？调用这个服务需要提供哪些信息？调用这个服务返回的结果是什么格式的？该如何解析？这些就是服务描述要解决的问题。
常用的服务描述方式包括 RESTful API、XML 配置以及 IDL 文件三种。
注册中心
就是说你提供了一个服务，如何让外部想调用你的服务的人知道。
一般来讲，注册中心的工作流程是：
- 服务提供者在启动时，根据服务发布文件中配置的发布信息向注册中心注册自己的服务。
- 服务消费者在启动时，根据消费者配置文件中配置的服务信息向注册中心订阅自己所需要的服务。
- 注册中心返回服务提供者地址列表给服务消费者。
- 当服务提供者发生变化，比如有节点新增或者销毁，注册中心将变更通知给服务消费者。
服务框架
通过注册中心，服务消费者就可以获取到服务提供者的地址，有了地址后就可以发起调用。但在发起调用之前你还需要解决以下几个问题。
- 服务通信采用什么协议？
- 数据传输采用什么方式？同步, 异步, 单连接, 多路复用
- 数据压缩采用什么格式？
服务监控
通常来讲，服务监控主要包括三个流程。
- 指标收集. 请求耗时, 请求是否成功
- 数据处理. 指标计算, 每秒服务请求量, 平均耗时, 成功率
- 数据展示
服务追踪
除了需要对服务调用情况进行监控之外，你还需要记录服务调用经过的每一层链路，以便进行问题追踪和故障定位。
服务追踪的工作原理大致如下：
- 服务消费者发起调用前，会在本地按照一定的规则生成一个 requestid，发起调用时，将 requestid 当作请求参数的一部分，传递给服务提供者。
- 服务提供者接收到请求后，记录下这次请求的 requestid，然后处理请求。如果服务提供者继续请求其他服务，会在本地再生成一个自己的 requestid，然后把这两个 requestid 都当作请求参数继续往下传递。
- 以此类推，通过这种层层往下传递的方式，一次请求，无论最后依赖多少次服务调用、经过多少服务节点，都可以通过最开始生成的 requestid 串联所有节点，从而达到服务追踪的目的。
服务治理
服务监控能够发现问题，服务追踪能够定位问题所在，而解决问题就得靠服务治理了。服务治理就是通过一系列的手段来保证在各种意外情况下，服务调用仍然能够正常进行。
在生产环境中，你应该经常会遇到下面几种状况:
- 单机故障. 自动摘除故障节点
- 单 IDC 故障. 自动切换故障 IDC
- 依赖服务不可用. 熔断
其他服务治理手段:
- 自动括缩容
总结
不管你是采用开源方案还是自行研发，都必须吃透每个组件的工作原理并能在此基础上进行二次开发。
精选留言
oddrock
微服务架构下要解决的服务描述、服务注册与发现、服务框架、服务监控、服务跟踪、服务治理其实在soa下基本都同样存在。
soa下服务描述用wsdl，服务注册与发现用uddl，服务框架、服务监控和服务跟踪、治理基本都依赖esb，治理还要部分依赖负载均衡。
同样情况在单体简单的多，服务描述就是api，服务注册与发现就是引用jar，监控、跟踪、治理在单体情况下基本不存在，最多用jvm监控工具来监控
我的理解如上，还请老师指正
作者回复: 看来对soa很了解
若有收获，就点个赞吧
0 人点赞
