知识点分解

核心类对象

DataSource

引言

用Spring进行Web应用开发时，我们经常会做datasource的配置。而且datasource的配法风格各异。那么他们到底有哪些异同点呢？

DataSource作用

DataSource是javax.sql包中的类，是Java原生rt.jar包中的类。

1
2
3
4
5
6
7

public interface DataSource  extends CommonDataSource, Wrapper {

  Connection getConnection() throws SQLException;

  Connection getConnection(String username, String password)
    throws SQLException;
}

• Dubbo Consumer的启动过程和Provider一样，以DubboNamespaceHandler为起点，去解析代码配置中的ReferenceBean。

1

public class ReferenceBean<T> extends ReferenceConfig<T> implements FactoryBean, ApplicationContextAware, InitializingBean, DisposableBean {

原文地址：Roy T. Fielding: REST APIs must be hypertext-driven

I am getting frustrated by the number of people calling any HTTP-based interface a REST API. Today’s example is the SocialSite REST API. That is RPC. It screams RPC. There is so much coupling on display that it should be given an X rating.

我是越来越失望了，许多人把任何基于HTTP的接口叫做REST API，眼前的例子就是SocialSite REST API。那是RPC，实实在在的RPC。它与显示如此耦合，再差也莫过于此

引言

在互联网高度普及的今天，作为一名Web开发者，如果你还没听说过“REST”这个技术名词，出门都不好意思跟人打招呼。尽管如此，对于REST这个泊来品的理解，大多数人仍然停留在“盲人摸象”的阶段。

有人认为，在Web Controller层写的API就是REST API。而且，从开发角度对于URI的命名、HTTP Mehthod的选择没有建立起规范的意识。这样是不优雅的！（没有对错之分）

作为带着问题学习总结的我，未打算通过本篇文档全面的阐述清楚REST，而是尽量的总结一些理论和思考，一起探讨！

历史背景

MySQL 5.0版本之前，一个表一次只能选择并使用一个索引。

MySQL 5.1版本开始，引入了Index Merge Optimization技术，使得MySQL支持一个表一次查询同时使用多个索引。

官方文档：MySQL Index Merge Optimization

Index Merge Optimization支持三种合并算法

• The Index Merge Intersection Access Algorithm
  • 对应SQL 中的 AND 场景
• The Index Merge Union Access Algorithm
  • 对应SQL中的 OR 场景（where条件是等值判断）
• The Index Merge Sort-Union Access Algorithm
  • 对应SQL中的 OR 场景（where条件是范围查询）

慢查询案例

1

DELETE FROM settlement_invoice_attachment g1 WHERE demand_id in (SELECT id FROM settlement_invoice_demand g2 WHERE statement_id = 1802065000000074956)

乍眼一看，上述SQL如此简单，且demand_id和statement_id字段都是建了索引，即使是Review也会认为是OK没问题的。

然而，实际情况却是个慢查询，情况如下：

explain明细

前言

Dubbo Provider暴露服务的流程中，需要掌握几个核心抽象对象

• 过程中的重要类
  • ServiceConfig：记录了Dubbo Service所有相关的配置信息。ServiceConfig作用
  • DubboProtocol：以Dubbo协议的方式暴露服务，并以此为中心维护所有相关的动态服务数据。
  • RegisterProtocol: 内部会加载具体的注册中心Register,例如：ZookeeperRegister。完成服务向注册中心注册的动作。
  • ServiceConfig#loadRegistries：解析获得注册中心地址列表

• 过程中的重要对象
  • com.alibaba.dubbo.common.URL: 服务发布的地址
  • Invoker: 对原Service Interface进行了代理封装，屏蔽了具体Service Interface的差异，方便统一管理和调用。
  • Exporter： 一个ServiceBean每向一个注册中心Register注册一次，就会生成已各Exporter。Exporter用于连接暴露服务的Url与本地Invoker的对应关系。
  • ExporterMap: 记录着服务地址和Exporter的对应关系

场景

其实，纠结只出现在例如保存表单的场景，如果服务端因各种业务上的原因（校验不通过，状态不满足等）导致保存未成功，并要返回对应的提示信息，此时服务端回应此HTTP 请求时，是用 “200 + json” 还是用“400 + 错误信息”？

在公司内不同项目间，两种风格都有，且小伙伴们各执己见。

相信大家对于Dubbo Provider/Consumer的配置非常熟练，但这背后的实现原理清楚吗？如果有不太清楚的朋友，可以再往下阅读下。