肖哥弹架构博客

在Dubbo的官网上，Dubbo描述自己是一个高性能的RPC框架。今天我想聊聊Dubbo的另一个很棒的特性, 就是它的可扩展性。 如同罗马不是一天建成的，任何系统都一定是从小系统不断发展成为大系统的，想要从一开始就把系统设计的足够完善是不可能的，相反的，我们应该关注当下的需求，然后再不断地对系统进行迭代。在代码层面，要求我们适当的对关注点进行抽象和隔离，在软件不断添加功能和特性时，依然能保持良好的结构和可维护性，同时允许第三方开发者对其功能进行扩展。在某些时候，软件设计者对扩展性的追求甚至超过了性能。

有必要比较详细点的介绍下服务端的线程策略来加深用户在选择服务端异步的判断依据，同时有必要引出协程这一在服务端异步中常常会用到的“秘密武器”。

在不谈及 dubbo 时，我们大多数人对 URL 这个概念并不会感到陌生。统一资源定位器 (RFC1738――Uniform Resource Locators (URL)）应该是最广为人知的一个 RFC 规范，它的定义也非常简单

Dubbo的Hash映射模型与大部分网上资料描述的环形队列Hash映射模型是存在一些区别的。于我而言，环形队列Hash映射模型，不足以让我对一致性Hash有足够彻底的了解。直到看懂了Dubbo的一致性Hash的实现，才觉得豁然开朗。

Dubbo是一款 RPC 服务框架，提供了面向接口代理的服务编程模型，同时屏蔽了底层的远程通信细节，具备服务治理功能，例如：服务发现、流量调度等解决方案。

在 Dubbo 中，我们可以通过两种方式引用远程服务。第一种是使用服务直连的方式引用服务，第二种方式是基于注册中心进行引用。服务直连的方式仅适合在调试或测试服务的场景下使用，不适合在线上环境使用。因此，本文我将重点分析通过注册中心引用服务的过程。从注册中心中获取服务配置只是服务引用过程中的一环，除此之外，服务消费者还需要经历 Invoker 创建、代理类创建等步骤。

Dubbo 的扩展点加载从 JDK 标准的 SPI (Service Provider Interface) 扩展点发现机制加强而来。Dubbo 改进了 JDK 标准的 SPI 的以下问题：- JDK 标准的 SPI 会一次性实例化扩展点所有实现，如果有扩展实现初始化很耗时，但如果没用上也加载，会很浪费资源。- 如果扩展点加载失败，连扩展点的名称都拿不到了。比如：JDK 标准的 ScriptEngine，通过 `getName()` 获取脚本类型的名称，但如果 RubyScriptEngine 因

随着微服务架构的推广和普及，服务之间的耦合度在逐步降低。在演化的过程中，伴随着应用组织架构的变化以及基础设施的衍进，服务和应用之间的边界变得更为模糊。Java 作为一门面向对象的编程语言，Java 接口（interface）作为服务之间通讯的一等公民，配合文档（JavaDoc）便于开发人员理解和维护。基于相同的编程哲学，Apache Dubbo 作为传统的 RPC 服务治理框架，通过接口实现分布式服务。然而对于微服务治理而言，应用（或“服务”）才是基础设施的核心要素。面对云原生（Cloud Native）技

SPICodec工作在一种协议上，encode是将通信对象编码到ByteBufferWrapper中，decode是将从网络上读取的ChannelBuffer解码为Object，也就是通信对象。

RPC 协议扩展，封装远程调用细节。当用户调用refer()所返回的Invoker对象的invoke()方法时，协议需相应执行同 URL 远端export()传入的Invoker对象的invoke()方法。其中，refer()返回的Invoker由协议实现，协议通常需要在此Invoker中发送远程请求，export()传入的Invoker由框架实现并传入，协议不需要关心。协议不关心业务接口的透明代理，以Invoker为中心，由外层将Invoker转换为业务接口。

同构微服务体系企业内部的微服务都是基于相同服务框架开发研发的产品，比如全部采用 Dubbo微服务支撑产品。异构微服务体系公司微服务可能使用多个不同的服务框架所建设，多个不同技术栈微服务体系的共存在大型组织还是非常普遍，例如：Dubbo，Sofa-rpc, Brpc等造成异构形式的原因很多，可能是遗留系统带来的，也可能是公司正在做技术栈迁移，或者就是不同业务部门为了满足各自特殊需求而做的独立选型2.2 异构微服务共存。

在 Dubbo 中，我们可以通过两种方式引用远程服务。第一种是使用服务直连的方式引用服务，第二种方式是基于注册中心进行引用。服务直连的方式仅适合在调试或测试服务的场景下使用，不适合在线上环境使用。因此，本文我将重点分析通过注册中心引用服务的过程。从注册中心中获取服务配置只是服务引用过程中的一环，除此之外，服务消费者还需要经历 Invoker 创建、代理类创建等步骤。本篇文章对服务引用的过程进行了较为详尽的分析，还有一些逻辑暂时没有分析到，比如 Directory、Cluster。

关注本人的公众号Solomon肖哥弹架构获取更多精彩内容在当今互联网高速发展的时代，电商平台常常面临着亿级流量的考验。特别是在大型促销活动如“双11”、“618”期间，系统如何在瞬时涌入的巨大流量下保持稳定、高效地运行，是每个程序员和技术团队梦寐以求的挑战。本文将深入探讨构建高并发电商平台的难点与解决方案，带领读者一步步提升技术水平。假设我们正在为一家知名的电商平台设计一个能够承受亿级流量的订单系统。该系统需要处理用户浏览、下单、支付、库存扣减等关键操作，同时保证数据的一致性和系统的高可用性。数据一致性保证

分布式ID生成是构建大规模分布式系统的基础。百度的UID-Generator和美团点评的Leaf都展示了如何通过巧妙的设计来满足这一需求。它们不仅提供了全局唯一、趋势有序的ID，还保证了系统的高可用性和高并发处理能力。

SPI 全称为 Service Provider Interface，是一种服务发现机制。SPI 的本质是将接口实现类的全限定名配置在文件中，并由服务加载器读取配置文件，加载实现类。这样可以在运行时，动态为接口替换实现类。正因此特性，我们可以很容易的通过 SPI 机制为我们的程序提供拓展功能。SPI 机制在第三方框架中也有所应用，比如 Dubbo 就是通过 SPI 机制加载所有的组件。不过，Dubbo 并未使用 Java 原生的 SPI 机制，而是对其进行了增强，使其能够更好的满足需求。

跟大家“弹弹” Dubbo扩展点加载设计关注本人的公众号获取更多精彩内容。

Dubbo 服务提供方（Provider）在服务暴露的过程中，将元信息以 JSON 的格式同步到注册中心，包括服务配置的全部参数，以及服务的方法信息（方法名，入参出参的格式）。在服务自省引入之前，该元数据被 Dubbo 2.7.0元数据中心。

在信息时代的网络环境下，如何保证业务数据的正确性，成为重要的核心点，而数据库产品在业务数据中提供了一套完整的策略机制（原子性，一致性，隔离性，持久性），业务程序不管与数据库是单次单表交互（程序数据与数据表可能构成一个业务的原子性）还是多次多表交互（业务数据分散在多表中通过多次协议交换），事务充当了业务数据完整性很重要的角色。本地事务 ：大部分数据库自身携带事务特征，业务不需要切入业务事务的保障。分布式事务 ：各自的数据库只能保证本库的表事务，而涉及多库之间的业务数据表一致，显得难以控制实现极其复杂，如.