Apache Dubbo
软件架构演进过程
软件架构的发展经历了由单体架构、垂直架构、SOA架构到微服务架构的演进过程
单体架构
架构说明: 全部功能集中在一个项目内。(电商可以理解为用户管理、订单管理都是横向的)
架构优点:架构简单,前期开发成本低、开发周期短,适合小型项目。
架构缺点:
- 全部功能集成在一个工程中,对于大型项目不易开发、扩展和维护。
- 技术栈受限,只能使用一种语言开发。
- 系统性能扩展只能通过扩展集群节点,成本高。
垂直架构
架构说明:按照业务进行切割,形成小的单体项目。(同电子商城,可以物流系统和CRM系统(也叫客户关系管理系统) 然后功能再具体垂直细分)
架构优点: 不同的系统可以用不同的编程语言编写。
架构缺点:
- 功能集中在一个项目中,不利于开发、扩展、维护。
- 系统扩张只能通过集群的方式。
- 项目之间功能冗余、耦合性强。
SOA架构
SOA全称为Service-Oriented Architecture,即面向服务的架构。它可以根据需求通过网络对应用组件(服务)进行分布式部署、组合和使用。一个服务通常以独立的形式存在操作系统进程中。
架构说明:将重复功能或模块抽取成组件的形式,对外提供服务,在项目与服务之间使用ESB(企业服务总线)的形式作为通信的桥梁。
架构优点: 重复功能或模块抽取为服务,提高开发效率。可重用性高、可维护性高。
架构缺点:
- 各系统之间业务不同,很难确认功能或模块是重复的。
- 抽取服务粒度大(这个粒度有点不懂 后面微服务也提到了 具体项目可能会理解更深一点)
- 系统和服务耦合度高
微服务架构
架构说明:将系统服务层完全独立出来,抽取为一个一个的微服务。 抽取的粒度更细,遵循单一原则。采用轻量级框架协议传输。
架构优点:有利于提高开发效率。适用于互联网时代,产品迭代周期更短。
架构缺点:粒度太细导致服务太多,维护成本高。 分布式系统开发的技术成本高,对团队的挑战大。(总的来讲就是技术要求高)
Apache Dubbo概述
简介
Apache Dubbo是一款高性能的Java RPC框架。
Dubbo提供了三大核心能力:面向接口的远程方法调用,智能容错和负载均衡,以及服务自动注册和发现。
RPC
RPC即远程过程调用。比如两台服务器A和B,A服务器上部署一个应用,B服务器上部署一个应用,A服务器上的应用想调用B服务器上的应用提供的方法,由于两个应用不在一个内存空间,不能直接调用,所以需要通过网络来表达调用的语义和传达调用的数据。(有点感觉像是通过网络调用写好的API)
RPC并不是一个具体的技术,而是指整个网络远程调用过程。
Dubbo架构
节点 | 角色名称 |
---|---|
Provider | 暴露服务的服务提供方 |
Consumer | 调用远程服务的服务消费方 |
Registry | 服务注册与发现的注册中心 |
Monitor | 统计服务的调用次数和调用时间的监控中心 |
Container | 服务运行容器 |
Dubbo官网地址:http://dubbo.apache.org(可以直接去看官方的架构图 还是挺清晰的)
服务注册中心Zookeeper
对应Dubbo架构里面的Registry,zookeeper是官方推荐的服务注册中心
安装过程要折腾一下,这里我把它放在阿里云的linux系统上,启动服务
问题思考
通过实践黑马网课的入门案例,会碰到一些问题(有些回答太专业了 了解即可)
Q:Dubbo入门案例中我们是将HelloService接口从服务提供者工程(dubbodemo_provider)复制到服务消费者工程(dubbodemo_consumer)中,这种做法是否合适?
A:这种做法显然是不好的,同一个接口被复制了两份,不利于后期维护。更好的方式是单独创建一个maven工程,将此接口创建在这个maven工程中。需要依赖此接口的工程只需要在自己工程的pom.xml文件中引入maven坐标即可。
Q:在服务消费者工程(dubbodemo_consumer)中只是引用了HelloService接口,并没有提供实现类,Dubbo是如何做到远程调用的?
A:Dubbo底层是基于代理技术为HelloService接口创建代理对象,远程调用是通过此代理对象完成的。可以通过开发工具的debug功能查看此代理对象的内部结构。另外,Dubbo实现网络传输底层是基于Netty框架完成的。
Q:上面的Dubbo入门案例中我们使用Zookeeper作为服务注册中心,服务提供者需要将自己的服务信息注册到Zookeeper,服务消费者需要从Zookeeper订阅自己所需要的服务,此时Zookeeper服务就变得非常重要了,那如何防止Zookeeper单点故障呢?
A:Zookeeper其实是支持集群模式的,可以配置Zookeeper集群来达到Zookeeper服务的高可用,防止出现单点故障。
总结
主要还是对linux操作系统不够熟悉很多命令都不太懂,部署环境以及注册中心花了不少时间,以及第一次做RPC,感觉很多地方掌握的还不是很到位,希望后面能慢慢捡起来。