关于java:微服务思想Dubbo框架

2次阅读

共计 1138 个字符，预计需要花费 3 分钟才能阅读完成。

面向服务 的架构（SOA）是一个组件模型 (编程办法)，它将应用程序的不同性能单元（称为服务）进行拆分，并通过这些服务之间定义良好的接口和协定分割起来。接口是采纳中立的形式进行定义的，它应该独立于实现服务的硬件平台、操作系统和编程语言。这使得构建在各种各样的零碎中的服务能够以一种对立和通用的形式进行交互。

RPC 是 近程过程调用（Remote Procedure Call）的缩写模式。SAP 零碎 RPC 调用的原理其实很简略，有一些相似于三层构架的 C / S 零碎，第三方的客户程序通过接口调用 SAP 外部的规范或自定义函数，取得函数返回的数据进行解决后显示或打印。

本地过程调用: 如果须要实现业务逻辑, 则间接去调用本地的办法即可.
近程过程调用: 我想实现一个业务的调用, 然而该性能我没有方法间接调用, 须要通过第三方帮忙我实现业务规定.
具体用法: RPC 不关注具体的实现规定, 用户也不须要理解具体的协定. 谁调用谁实现.

阐明:

为了升高代码的耦合性, 将我的项目进行了拆分.依照功能模块拆分为若干个我的项目. 该我的项目称之为服务.(分布式思维).
如果采纳微服务的构造, 要求服务器如果呈现了故障应该 实现自动化的故障的迁徙(高可用 HA)

阐明: 因为 nginx 负载平衡 / 反向代理都须要人为的配置, 并且呈现了问题不能及时的实现故障的迁徙, 所以须要降级为微服务的架构的设计.

实现步骤:

服务提供者启动时,. 将本人的信息注册到注册核心中.
注册核心承受到了用户的申请之后, 更新服务列表信息.
当消费者启动时, 首先会链接注册核心, 获取服务列表数据.
注册核心将本人的服务列表信息同步给客户端(消费者)
消费者接管到服务列表数据之后, 将信息保留到本人的本地. 不便下次调用
当消费者接管到用户的申请时, 依据本人服务列表的信息进行负载平衡的操作, 抉择其中一个服务的提供者, 依据 IP:PORT 进行 RPC 调用.
当服务提供者宕机时, 注册核心会有心跳检测机制, 如果查看宕机, 则更新本地的服务列表数据, 并且全网播送告诉所有的消费者更新服务列表.

Apache Dubbo |ˈdʌbəʊ| 提供了六大外围能力：面向接口代理的高性能 RPC 调用，智能容错和负载平衡，服务主动注册和发现，高度可扩大能力，运行期流量调度，可视化的服务治理与运维。

调用原理图:

jar 包：

<dependency>
    <groupId>com.alibaba.boot</groupId>
    <artifactId>dubbo-spring-boot-starter</artifactId>
    <version>0.2.0</version>
</dependency>

正文完