Dubbo先啟動客戶端再啟動服務端，線上收銀系統崩了
線上發生事故了
前天晚上上線一波，發生了一個挺有意思的事，昨天復盤了一下，今天分享一下。
晚上的時候，我負責的系統和收銀系統同時上線一波(用的是Dubbo)。然后很神奇的事情發生了，收銀系統用@Reference注解注入我的接口，然后這個接口的實現類居然為空。
其實我們當時沒排查出來是什么原因?
「重啟了一下就好了，畢竟重啟大法好。」 但本著不能給用戶充錢的路上造成阻礙，還是要排查一波這個代理對象為空是如何造成的。
「線上dubbo的版本為2.8.9，注意包名是(com.alibaba)」
為了方便大家理解我說的內容，簡單說一下RPC框架的執行流程。
- Server將服務信息注冊到Registry，Client從Registry拉取Server的信息。
- Client通過代理對象(Client Stub)發送發送網絡請求，Server通過代理對象(Server Stub)執行本地方法
- 網絡傳輸過程中有編解碼和序列化的過程
「在Dubbo中Client Stub和Server Stub都是Invoker對象」
我們繼續，注入的接口實現類居然能為空?我就看了一下他寫的代碼，只用了一個@Reference注解，沒有設置任何屬性。
- @Documented
- @Retention(RetentionPolicy.RUNTIME)
- @Target({ElementType.FIELD, ElementType.METHOD, ElementType.ANNOTATION_TYPE})
- public @interface Reference {
- // 省略其他屬性
- boolean check() default true;
- }
那么check=true，即沒有服務提供者的時候，服務消費者都不能正常啟動，因為會拋出IllegalStateException異常。既然能正常啟動，那這個代理對象正常創建了啊，不可能為null啊
- // 2.8.9版本
- // ReferenceConfig#createProxy
- Boolean c = check;
- if (c == null && consumer != null) {
- c = consumer.isCheck();
- }
- if (c == null) {
- c = true; // default true
- }
- if (c && !invoker.isAvailable()) {
- throw new IllegalStateException("Failed to check the status of the service " + interfaceName + ". No provider available for the service " + (group == null ? "" : group + "/") + interfaceName + (version == null ? "" : ":" + version) + " from the url " + invoker.getUrl() + " to the consumer " + NetUtils.getLocalHost() + " use dubbo version " + Version.getVersion());
- }
「然后我同事說有沒有可能是客戶端先啟動，沒有服務提供者導致代理對象為空的?」
我說不可能的，客戶端先啟動，check屬性為true，不可能啟動成功的!再說每次上線，新服務正常啟動后，才會關閉舊服務的，服務提供者一定會有的。
「為什么會發生這種情況，是真心搞不懂，只能google “@Reference 注入對象為null”」
答案基本一致，沒有服務提供者導致代理對象為空的，只要把@Reference的check屬性設置為false即可，至于原因沒一篇文章說過
「接下來就是驗證網上的方法了」
- 先啟動producer，再啟動consumer，正常調用
- 先啟動consumer(check=true)，再啟動producer，代理對象為空，完美復現
- 先啟動consumer(check=false)，再啟動producer，正常調用
「和我的想法不一致，學dubbo的時候沒聽過必須先啟動producer再啟動consumer才能正常調用啊?」
我就拿出我學dubbo時用的例子測試了一波，dubbo的版本為2.7.3注意包名是(org.apache)
先啟動producer，再啟動consumer，正常調用
先啟動consumer(check=true)，此時沒有producer，啟動失敗
先啟動consumer(check=false)，再啟動producer，正常調用
「這才符合我的想法啊」
揭秘真相
既然@Reference注入的對象為null，那說明Spring Bean的生命周期中屬性賦值階段有問題
再來分析一下@Reference注解的注入邏輯，和@Autowired，@Resource之類的注入邏輯基本差不多。
當你加入Dubbo的spring boot starter時，會往容器中注入ReferenceAnnotationBeanPostProcessor，看一下這個類的繼承關系
其中最主要的部分你只需要知道這個類重寫了 InstantiationAwareBeanPostProcessor#postProcessPropertyValues(這個方法在后面的版本中被postProcessProperties方法替代)，而這個方法正是用來屬性賦值的，看上面的Bean生命周期圖
- public class ReferenceAnnotationBeanPostProcessor {
- // 省略了繼承類和方法
- // 這個方法給@Reference屬性賦值
- @Override
- public PropertyValues postProcessPropertyValues(
- PropertyValues pvs, PropertyDescriptor[] pds, Object bean, String beanName) throws BeanCreationException {
- InjectionMetadata metadata = findReferenceMetadata(beanName, bean.getClass(), pvs);
- try {
- metadata.inject(bean, beanName, pvs);
- } catch (BeanCreationException ex) {
- throw ex;
- } catch (Throwable ex) {
- throw new BeanCreationException(beanName, "Injection of @Reference dependencies failed", ex);
- }
- return pvs;
- }
- }
接著執行到ReferenceFieldElement#inject方法，@Reference引入的對象會被包轉為ReferenceBean
- private class ReferenceFieldElement extends InjectionMetadata.InjectedElement {
- @Override
- protected void inject(Object bean, String beanName, PropertyValues pvs) throws Throwable {
- Class<?> referenceClass = field.getType();
- // 獲取 referenceBean 的邏輯在這
- referenceBean = buildReferenceBean(reference, referenceClass);
- ReflectionUtils.makeAccessible(field);
- // 通過反射注入對象
- field.set(bean, referenceBean.getObject());
- }
- }
經過一系列方法調用執行到如下方法
- // AbstractAnnotationConfigBeanBuilder#build
- public final B build() throws Exception {
- checkDependencies();
- B bean = doBuild();
- configureBean(bean);
- if (logger.isInfoEnabled()) {
- logger.info(bean + " has been built.");
- }
- return bean;
- }
此時日志中會打印ReferenceBean對象，這個對象繼承了AbstractConfig，所以會執行AbstractConfig#toString方法
- public abstract class AbstractConfig implements Serializable {
- @Override
- public String toString() {
- try {
- StringBuilder buf = new StringBuilder();
- buf.append("<dubbo:");
- buf.append(getTagName(getClass()));
- Method[] methods = getClass().getMethods();
- for (Method method : methods) {
- try {
- String name = method.getName();
- if ((name.startsWith("get") || name.startsWith("is"))
- && !"getClass".equals(name) && !"get".equals(name) && !"is".equals(name)
- && Modifier.isPublic(method.getModifiers())
- && method.getParameterTypes().length == 0
- && isPrimitive(method.getReturnType())) {
- int i = name.startsWith("get") ? 3 : 2;
- String key = name.substring(i, i + 1).toLowerCase() + name.substring(i + 1);
- Object value = method.invoke(this, new Object[0]);
- if (value != null) {
- buf.append(" ");
- buf.append(key);
- buf.append("=\"");
- buf.append(value);
- buf.append("\"");
- }
- }
- } catch (Exception e) {
- logger.warn(e.getMessage(), e);
- }
- }
- buf.append(" />");
- return buf.toString();
- } catch (Throwable t) {
- logger.warn(t.getMessage(), t);
- return super.toString();
- }
- }
- }
「好家伙，打印的時候把get方法全執行了一遍，然后執行ReferenceBean#getObject方法異常了(就是那個沒有服務提供者拋出的異常)，但是被try Catch了」
因為ReferenceBean是一個FactoryBean，所以需要調用getObject方法才能獲取創建的對象
- private class ReferenceFieldElement extends InjectionMetadata.InjectedElement {
- @Override
- protected void inject(Object bean, String beanName, PropertyValues pvs) throws Throwable {
- Class<?> referenceClass = field.getType();
- // 獲取 referenceBean 的邏輯在這
- referenceBean = buildReferenceBean(reference, referenceClass);
- ReflectionUtils.makeAccessible(field);
- // 通過反射注入對象
- field.set(bean, referenceBean.getObject());
- }
- }
「接著調用ReferenceBean#getObject方法，好了，這就是服務導出的邏輯了!」 不細說了，后續單開文章寫，會執行到ReferenceConfig#get方法
- // ReferenceConfig#get
- public synchronized T get() {
- if (destroyed) {
- throw new IllegalStateException("Already destroyed!");
- }
- if (ref == null) {
- init();
- }
- return ref;
- }
「此時代理對象為null，執行init方法，initialized默認為false，執行一次變為true(AbstractConfig執行toString方法的時候哈)，所以第二次執行，直接return，此時代理對象為null，完事!」
- private void init() {
- if (initialized) {
- return;
- }
- initialized = true;
- // 省略部分代碼
- }
「我學習用的版本為什么能正常工作?」
- public final C build() throws Exception {
- checkDependencies();
- C configBean = doBuild();
- configureBean(configBean);
- if (logger.isInfoEnabled()) {
- logger.info("The configBean[type:" + configBean.getClass().getSimpleName() + "] has been built.");
- }
- return configBean;
- }
就是打印的時候不會執行getObject方法了
「為什么@Reference的check屬性設置為false就能正常調用?」
因為第一次調用成功執行完ReferenceBean#getObject方法，ref已經賦值為代理對象了，第二次執行就能將這個代理對象返回
- // ReferenceConfig#get
- public synchronized T get() {
- if (destroyed) {
- throw new IllegalStateException("Already destroyed!");
- }
- if (ref == null) {
- init();
- }
- return ref;
- }
至于我們的線上系統為什么沒獲取到服務提供者，我估計很大概率是由于網絡的原因
解決方案
- @Reference注解的check屬性設置為false(默認為true)，因為當你的check屬性為true并且沒有服務提供者時，不會起任何作用，只會注入一個空對象，后續當有服務提供者可用時，這個對象始終為空。當check為false時，會注入一個代理對象，當有服務提供者時，這個代理對象會刷新，就能正常發起調用
- 選擇能正常執行的版本
本文轉載自微信公眾號「Java識堂」，可以通過以下二維碼關注。轉載本文請聯系Java識堂公眾號。
