面试题 02.08 环路检测
给定一个链表,如果它是有环链表,实现一个算法返回环路的开头节点
Dubbo
是一个基于java
的分布式服务框架,致力于提供高性能和透明化的RPC
远程服务调用方案,以及SOA
服务治理方案.
和大多数RPC
系统一样, dubbo
也是基于服务的想法打造的,特别是可以远程调用有参数和返回值的方法.
Dubbo |ˈdʌbəʊ| is a high-performance, java based RPC framework open-sourced by Alibaba. As in many RPC systems, dubbo is based around the idea of defining a service, specifying the methods that can be called remotely with their parameters and return types. On the server side, the server implements this interface and runs a dubbo server to handle client calls. On the client side, the client has a stub that provides the same methods as the server.
目前公司使用的是Dubbo
, 关于阿里两个框架的选择, InfoQ
上有谈:
InfoQ: 我们知道阿里内部现在基本上没有在使用 Dubbo,而是用了 Dubbo 之后开发的第三代 RPC 服务框架 HSF(High-speed Service Framework),那现在还将 Dubbo 重启维护,大家不免疑惑。
罗毅: Dubbo 和 HSF 都是阿里巴巴集团自研的 RPC 服务框架,在不同时期都很好的支持了集团业务的发展。目前,HSF2 主要服务于集团内部业务,而 Dubbo2 主要以开源的形式服务社会,它们之间的关系与 Google 内部使用的 Stubby 和开源的 gRPC 类似。
- 从功能及使用方式上来说,HSF2 和 Dubbo2 都是十分优秀的 RPC 框架,都能很好地满足搭建分布式服务化系统的诉求。内部坚持使用 HSF2 而不是开源版本的 Dubbo2 与业务属性和规模有关。
- 此外也出于以下几方面的考虑:内部统一技术框架、统一运维方面的诉求,应用迁移成本,内部服务注册发现、配置推送以及链路追踪等外围系统的集成度等。总的来说,HSF2 在服务治理、超大规模集群、多机房几个方面比 Dubbo2 更有优势,并且在使用层面保持了对 Dubbo2 的兼容性。
> 为什么我们还要重启 Dubbo 的维护呢?
- 道理和 Google 开源 gRPC 是一样的。开源不仅仅是赋能社会的方式,我们也可以通过社区反馈提升产品和技术能力。
- Dubbo2 作为一款优秀的开源产品,由于面向的用户群体非常广泛,这就决定了它的设计原则强调扩展性、使用轻量、以及对开源外围系统和协议的适配。通过开源社区的建议,目前 Dubbo 已经具备了一些特有功能,例如对 REST 的支持和对 Spring Boot 的集成。
- 值得注意的是,目前负责 Dubbo 的团队和内部负责 HSF 的是同一个团队,在聆听外部用户反馈之余,我们也会把大规模领域里的服务运维经验反哺回 Dubbo 社区,形成良性循环,做到真正意义上的内外统一。
Provider: 在启动时,向注册中心注册自己提供的服务,也就是暴露服务的服务提供方。
Consumer: 在启动时,向注册中心订阅自己所需的服务,也就是调用远程服务的服务消费方。
Registry: 服务注册与发现的注册中心。 注册中心返回服务提供者地址列表给消费者,如果有变更,注册中心将基于长连接推送变更数据给消费者; 服务消费者,从提供者地址列表中,基于软负载均衡算法,选一台提供者进行调用,如果调用失败,再选另一台调用目前使用zookeeper
Monitor: 统计服务的调用次调和调用时间的监控中心。服务消费者和提供者,在内存中累计调用次数和调用时间,定时每分钟发送一次统计数据到监控中心
Container: 服务运行容器,负责启动,加载,运行服务提供者。
当服务集群规模进一步扩大,带动IT治理结构进一步升级,需要实现动态部署,进行流动计算,现有分布式服务架构不会带来阻力。