微服务

Dubbo调用过程

• 面向服务的架构体系有三个角色

• 注册中心，服务消费方，服务提供方

• Dubbo框架

• 服务启动

• 会将服务提供者能够提供的服务列表注册到注册中心，这样注册中心可以知道，哪些服务器上启动了哪些可以供外界调用的服务，每个服务对应多个服务器列表

• 服务调用过程

• 服务消费方，通过接口进行服务间的相互调用。

• 通过接口代理，将接口请求传递到服务框架客户端，框架客户端获取本地的服务提供者列表，如果本地没有服务提供者列表则需要到远程的注册中心获取。

• 根据负载均衡策略，从服务提供者列表中计算出需要调用的节点，与其建立网络通信

• 服务提供方，解析请求的数据包，得到需要调用的类及其具体方法，该类处理完成后，将响应的数据包返回給服务消费方

• 服务消费方解析响应数据包，得到需要的处理结果

• 版本管理

• 服务升级后，旧的版本保留半年，如果半年以后服务消费方还在调用旧版本，调用失败的后果由服务消费方承担。

微服务设计

• 服务边界划分

• 不同业务相互解耦，彼此完全透明

• 例如下单，可能小程序，H5，PC，客户端，后台，都需要用到，此时入口应该收敛到订单服务。

• 由订单服务定制参数，返回值等信息。之后如果发生业务变更，入口非常清晰，相互兼容即可

• 业务层和数据层分离

• 业务层充斥了大量复杂逻辑，如果因为代码原因发生死循环或者其他阻塞性BUG，导致服务不可用，此时业务层和数据层混合在一起就意味着，其他服务调用该服务时，无法获取对应数据库的数据。甚至可能导致集体服务雪崩

• 可以拆分数据层和业务层，彼此相互独立。数据层只负责对应数据库的数据处理，不调用任何服务，只接受其他服务调用，业务全部放在业务层。就算业务层崩溃，也不影响其他服务获取数据

• 服务间做好参数、异常校验

• 一个接口查询一天的数据量，功能完全正常，但如果查询一年可能就会阻塞，甚至直接导致服务不可用

• 因为无法控制上层传递到底什么参数，所以自身接口一定要做参数，明确自身可以处理数据量的极限，不要因为上层服务不规范调用把自身服务打挂。