SOA 思维
概念
soa 思维即为面向服务开发;
倒退步骤: 面向对象思维 –> 面向接口开发 –> 面向切面开发 –> 面向服务开发
概括:SOA 思维要求依照业务将服务进行拆分, 之后依照同一的中立的接口进行交互.
结构图
相比拟于上一篇文章的 httpclient 的近程调用,soa 中将前端的 service 中 httpclient 局部以及后端的 controller 部门简化为一个公共中立的接口方便使用与调用.
RPC
概念
RPC 为近程过程调用 – 简略了解:一个节点申请另一个节点提供的服务
1. 本地过程调用: 本地调用办法执行业务
2. 近程过程调用: 在服务之间, 由第三方实现本人的工作的过程.
微服务调用原理
必要两点:
1. 依据业务拆分的思维 进行了 分布式 的设计
2. 当服务产生异样时能够 主动的实现故障的迁徙 (高可用) 无需人为的干涉.
传统服务调用形式
因为 nginx 做负载平衡时须要依赖配置文件. 然而 当服务器新增 / 缩小时. 都须要手动的批改配置文件. 不能自动化的实现. 所以临时达不到微服务的规范.
微服务调用形式
步骤:
**1. 当服务的提供者启动时, 会将本人的服务信息 (服务名称 /IP/ 端口号) 进行记录
2. 服务注册核心须要记录提供者的信息 保护服务列表
3. 当服务消费者启动时会链接注册核心.
4. 从注册核心中获取服务列表信息, 不便下次调用
5. 当消费者调用服务时, 会依据负载平衡的机制筛选其中的一个服务提供者进行拜访.
6. 当服务提供者宕机时, 因为注册核心有心跳检测机制, 会保护服务列表. 当宕机的提供者标识为 down
7. 当服务列表保护之后, 会全网播送告诉所有服务器的消费者更新服务列表信息.**
对于集群阐明
集群为何是奇数台
准则: 搭建集群必须满足公式 现有的节点数量 > N/2
为什么集群的最小单位是 3 台:
假如:
1 台 1-1=0 > 1/2 false
2 台 2-1=1 > 2/2 false
3 台 3-1=2 > 3/2 true 3 台是搭建集群的最小单位.
4 台 4-1=3 > 4/2 true 只有大概 3 台都能够搭建集群.
集群中最多容许宕机的台数为多少:
3 台最多容许宕机几台 — 最多宕机 1 台
4 台最多容许宕机几台 — 最多宕机 1 台
从实用性的角度思考问题 发现搭建奇数台和偶数台的容灾能力雷同. 所以选用奇数台.
zookeeper
总结:Zookeeper 负责服务的协调调度. 当客户端发动申请时, 返回正确的服务器地址.
zookeeper 即为微服务中咱们所要应用的注册核心, 以下简称 zk, 装置运行 / 搭建集群过程不做赘述, 请自行查阅.
zk 集群选举的原理
原理阐明: zk 集群的选举依据最大值优先的规定, 进行选举. 如果集群一旦超过半数以上的票数批准, 则入选主机, 同时选举完结.
题目: 有 1,2,3,4,5,6,7 节点顺次启动.
问题 1: 谁当主机? 4 当主机
问题 2: 哪几台永远不能入选主机? 1 2 3
Dubbo 框架介绍
官网简介
Apache Dubbo |ˈdʌbəʊ| 是一款高性能、轻量级的开源 Java RPC 框架，它提供了三大外围能力： 面向接口的近程办法调用，智能容错和负载平衡，以及服务主动注册和发现。
个性
工作原理
和上文中微服务调用过程基本一致
入门案例
1. 定义第三方的公共接口我的项目:
消费者和提供者都会依赖此接口来进行传输, 其中须要定义 pojo 类以及 service 接口
2. 提供者阐明:
1). 编辑 Dubbo 的 service 接口的实现类:
实现公共接口我的项目的 service 接口 (前提我的项目要依赖)
实现类注解要写 Dubbo 的 @Service 而不是 spring 的注解
2). 编辑 YML 配置文件:
端口号 / 数据源 /MP/Dubbo 配置(包门路 / 利用名称(一个服务一个名称)/ 注册核心 / 协定)
3. 消费者阐明:
1). 编辑 controller:
注入 service: 利用 dubbo 的形式 @Reference 为接口创立代理对象, 利用 rpc 调用; 而不是 @Autowired
2). 编辑 YML 配置文件:
端口号 /Dubbo 配置(包门路 / 利用名称(一个服务一个名称)/ 注册核心)
4. 启动测试业务
Dubbo 题目
问题 1: 如果将其中的一个服务的提供者敞开, 问 用户拜访是否受影响 — 不受任何影响
问题 2: 如果将 dubbo 中的注册核心全副敞开, 问用户拜访是否受到影响 — 不受影响, 因为消费者将服务列表数据保留到本地.