标签:领域驱动设计 post 使用方法 rpc 迭代 降级 带来 idt ps技巧
什么是软件架构?
软件架构是一个包含各种组织的系统组织,这些组件包括 Web服务器, 应用服务器, 数据库,存储, 通讯层), 它们彼此或和环境存在关系。
什么是微服务架构?
微服务是指开发一个单个 小型的但有业务功能的服务,每个服务都有自己的处理和轻量通讯机制,可以部署在单个或多个服务器上。
微服务也指一种种松耦合的、有一定的有界上下文的面向服务架构。也就是说,如果每个服务都要同时修改,那么它们就不是微服务,因为它们紧耦合在一起;如果你需要掌握一个服务太多的上下文场景使用条件,那么它就是一个有上下文边界的服务,这个定义来自DDD领域驱动设计。
微服务架构的优缺点?
优点
缺点
SOA是一个组件模型,它将应用程序的不同功能单元(称为服务)通过这些服务之间定义良好的接口和契约联系起来。面向服务架构,它可以根据需求通过网络对松散耦合的粗粒度应用组件进行分布式部署、组合和使用。
soa基本架构图
1.注册中心: 保存服务提供方暴露的服务信息,常见的注册中心有zookeeper eureka 也可用redis 默认eureka
2.服务提供方:提供服务者
3.服务消费方:当需要调用远程服务接口时,必须在注册中心发现服务找到服务提供者,从而进行远程方法调
Dubbo是阿里开源的一个SOA服务治理解决方案,文档丰富,在国内的使用度非常高。 dubbo
调用中间层变成了可选组件,消费者可以直接访问服务提供者。
服务信息被集中到Registry中,形成了服务治理的中心组件。
通过Monitor监控系统,可以直观地展示服务调用的统计信息。
Consumer可以进行负载均衡、服务降级的选择。
但是对于微服务架构而言,Dubbo也并不是十全十美的:
Registry严重依赖第三方组件(zookeeper或者redis),当这些组件出现问题时,服务调用很快就会中断。
DUBBO只支持RPC调用。使得服务提供方与调用方在代码上产生了强依赖,服务提供者需要不断将包含公共代码的jar包打包出来供消费者使用。一旦打包出现问题,就会导致服务调用出错。
最为重要的是,DUBBO现在已经停止维护了,对于技术发展的新需求,需要由开发者自行拓展升级。这对于很多想要采用微服务架构的中小软件组织,显然是不太合适的。
与dubbo对比,spring cloud是借助以下组件来实现的:
上图来自于SpringCloud中文文档 包括了spring cloud现在有的所有组件,以及每个组件的作用。
后续会讲解常用组件(例如配置管理,服务发现,断路器,智能路由,微代理,控制总线)在这里先不做解释。
微服务需要的功能 | Dubbo | SpringCloud |
服务注册与发现 | Zookeeper | Eureka |
服务调用方式 | RPC | Restful API |
服务路由和过滤 | 有 | Zuul |
负载均衡 | 有 | Ribbon |
断路器 | 有 | Hystrix |
分布式配置 | 无 | Spring Cloud Config |
分布式消息 | 无 | Spring Cloud Bus |
集群选主 | 无 | Spring Cloud Cluster |
批量任务 | 无 | Spring Cloud Task |
服务跟踪 | 无 | Sleuth&Zipkin |
...... | ...... | ...... |
文档对比
标签:领域驱动设计 post 使用方法 rpc 迭代 降级 带来 idt ps技巧
原文地址:https://www.cnblogs.com/yanfeiLiu/p/9461859.html