讀

本文主要總結了在ICBU的核心溝通場景下服務端在此次性能優化過程中做的工作，供大家參考討論。

一、背景與效果

ICBU的核心溝通場景有了10年的“積累”，核心場景的界面響應耗時被拉的越來越長，也讓性能優化工作提上了日程，先說結論，經過這一波前后端齊心協力的優化努力，兩個核心界面90分位的數據，FCP平均由2.6s下降到1.9s，LCP平均由2.8s下降到2s。本文主要著眼于服務端在此次性能優化過程中做的工作，供大家參考討論。

二、措施一：流式分塊傳輸（核心）

2.1. HTTP分塊傳輸介紹

分塊傳輸編碼（Chunked Transfer Encoding）是一種HTTP/1.1協議中的數據傳輸機制，它允許服務器在不知道整個內容大小的情況下，就開始傳輸動態生成的內容。這種機制特別適用于生成大量數據或者由于某種原因數據大小未知的情況。

在分塊傳輸編碼中，數據被分為一系列的“塊”（chunk）。每一個塊都包括一個長度標識（以十六進制格式表示）和緊隨其后的數據本身，然后是一個CRLF（即"\r\n"，代表回車和換行）來結束這個塊。塊的長度標識會告訴接收方這個塊的數據部分有多長，使得接收方可以知道何時結束這一塊并準備好讀取下一塊。

當所有數據都發送完畢時，服務器會發送一個長度為零的塊，表明數據已經全部發送完畢。零長度塊后面可能會跟隨一些附加的頭部信息（尾部頭部），然后再用一個CRLF來結束整個消息體。

我們可以借助分塊傳輸協議完成對切分好的vm進行分塊推送，從而達到整體HTML界面流式渲染的效果，在實現時，只需要對HTTP的header進行改造即可：

public void chunked(HttpServletRequest request, HttpServletResponse response) {

    try (PrintWriter writer=response.getWriter()) {

    // 設置響應類型和編碼

    oriResponse.setContentType(MediaType.TEXT_HTML_VALUE + ";charset=UTF-8");

    oriResponse.setHeader("Transfer-Encoding", "chunked");

    oriResponse.addHeader("X-Accel-Buffering", "no");

    

    // 第一段

    Context modelMain=getmessengerMainContext(request, response, aliId);

    flushVm("/velocity/layout/Main.vm", modelMain, writer);




    // 第二段

    Context modelSec=getmessengerSecondContext(request, response, aliId, user);

    flushVm("/velocity/layout/Second.vm", modelSec, writer);




    // 第三段

    Context modelThird=getmessengerThirdContext(request, response, user);

    flushVm("/velocity/layout/Third.vm", modelThird, writer);

} catch (Exception e) {

    // logger

}

}




private void flushVm(String templateName, Context model, PrintWriter writer) throws Exception {

    StringWriter tmpWri=new StringWriter();

    // vm渲染

    engine.mergeTemplate(templateName, "UTF-8", model, tmpWri);

    // 數據寫出

    writer.write(tmpWri.toString());

    writer.flush();

}

2.2. 頁面流式分塊傳輸優化方案

我們現在的大部分應用都是springmvc架構，瀏覽器發起請求，后端服務器進行數據準備與vm渲染，之后返回html給瀏覽器。

從請求到達服務端開始計算，一次HTML請求到頁面加載完全要經過網絡請求、網絡傳輸與前端資源渲染三個階段：

HTML流式輸出，思路是對HTML界面進行拆分，之后由服務器分批進行推送，這樣做有兩個好處：

• 服務端分批進行數據準備，可以減少首次需要準備的數據量，極大縮短準備時間。
• 瀏覽器分批接收數據，當接收到第一部分的數據時，可以立刻進行js渲染，提升其利用率。

這個思路對需要加載資源較多的頁面有很明顯的效果，在我們此次的界面優化中，頁面的FCP與LCP均有300ms-400ms的性能提升，在進行vm界面的數據拆分時，有以下幾個技巧：

• 注意界面資源加載的依賴關系，前序界面不能依賴后序界面的變量。
• 將偏靜態與核心的資源前置，后端服務器可以快速完成數據準備并返回第一段html供前端加載。

2.3. 注意事項

此次優化的應用與界面本身歷史包袱很重，在進行流式改造的過程中，我們遇到了不少的阻力與挑戰，在解決問題的過程也學到了很多東西，這部分主要對遇到的問題進行整理。

1. 二方包或自定義的HTTP請求 filter 會改寫 response 的 header，導致分塊傳輸失效。如果應用中有這種情況，我們在進行流式推送時，可以獲取到最原始的response，防止被其他filter影響：

/**

 * 防止filter或者其他代理包裝了response并開啟緩存

 * 這里獲取到真實的response

 *

 * @param response

 * @return

 */

private static HttpServletResponse getResponse(HttpServletResponse response) {

    ServletResponse resp=response;

    while (resp instanceof ServletResponseWrapper) {

        ServletResponseWrapper responseWrapper=(ServletResponseWrapper) resp;

        resp=responseWrapper.getResponse();

    }

    return (HttpServletResponse) resp;

}

2. 谷歌瀏覽器禁止跨域名寫入cookie，我們的應用界面會以iframe的形式嵌入其他界面，谷歌瀏覽器正在逐步禁止跨域名寫cookie，如下所示：

為了確保cookie能正常寫入，需要指定cookie的SameSite=None。

3. VelocityEngine模板引擎的自定義tool。

我們的項目中使用的模板引擎為VelocityEngine，在流式分塊傳輸時，需要手動渲染vm：

private void flushVm(String templateName, Context model, PrintWriter writer) throws Exception {

    StringWriter tmpWri=new StringWriter();

    // vm渲染

    engine.mergeTemplate(templateName, "UTF-8", model, tmpWri);

    // 數據寫出

    writer.write(tmpWri.toString());

    writer.flush();

}

需要注意的是VelocityEngine模板引擎支持自定義tool，在vm文件中是如下的形式，當vm引擎渲染到對應位置時，會調用配置好的方法進行解析：

<title>$tool.do("xx", "$!{arg}")</title>

如果用注解的形式進行vm渲染，框架本身會幫我們自動做tools的初始化。但如果我們想手動渲染vm，那么需要將這些tools初始化到context中：

/**

 * 初始化 toolbox.xml 中的工具

 */

private Context initContext(HttpServletRequest request, HttpServletResponse response) {

    ViewToolContext viewToolContext=null;

    try {

        ServletContext servletContext=request.getServletContext();

        viewToolContext=new ViewToolContext(engine, request, response, servletContext);

        VelocityToolsRepository velocityToolsRepository=VelocityToolsRepository.get(servletContext);

        if (velocityToolsRepository !=null) {

            viewToolContext.putAll(velocityToolsRepository.getTools());

        }

    } catch (Exception e) {

        LOGGER.error("createVelocityContext error", e);

        return null;

    }

}

對于比較古老的應用，VelocityToolsRepository需要將二方包版本進行升級，而且需要注意，velocity-spring-boot-starter升級后可能存在tool.xml文件失效的問題，建議可以采用注解的形式實現tool，并且注意tool對應java類的路徑。

@DefaultKey("assetsVersion")

public class AssertsVersionTool extends SafeConfig {

    public String get(String key) {

        return AssetsVersionUtil.get(key);

    }

}

4. Nginx 的 location 配置

server {

   location ~ ^/chunked {

        add_header X-Accel-Buffering  no;

        proxy_http_version 1.1;

    

        proxy_cache off; # 關閉緩存

        proxy_buffering off; # 關閉代理緩沖

        chunked_transfer_encoding on; # 開啟分塊傳輸編碼

        proxy_pass http://backends;

    } 

}

5. ngnix配置本身可能存在對流式輸出的不兼容，這個問題是很難枚舉的，我們遇到的問題是如下配置，需要將SC_Enabled關閉。

SC_Enabled on;

SC_AppName gangesweb;

SC_OldDomains //b.alicdn.com;

SC_NewDomains //b.alicdn.com;

SC_OldDomains //bg.alicdn.com;

SC_NewDomains //bg.alicdn.com;

SC_FilterCntType  text/html;

SC_AsyncVariableNames asyncResource;

SC_MaxUrlLen    1024;

詳見：https://github.com/dinic/styleCombine3

6. ngnix緩沖區大小，在我們優化的過程中，某個應用并沒有指定緩沖區大小，取的默認值，我們的改造導致http請求的header變大了，導致報錯upstream sent too big header while reading response header from upstream

proxy_buffers       128 32k;

proxy_buffer_size   64k;

proxy_busy_buffers_size 128k;

client_header_buffer_size 32k;

large_client_header_buffers 4 16k;

如果頁面在瀏覽器上有問題時，可以通過curl命令在服務器上直接訪問，排查是否為ngnix的問題：

curl --trace - 'http://127.0.0.1:7001/chunked' \

-H 'cookie: xxx'

7. ThreadLocal與StreamingResponseBody

在開始，我們使用StreamingResponseBody來實現的分塊傳輸：

@GetMapping("/chunked")

public ResponseEntity<StreamingResponseBody> streamChunkedData() {

    StreamingResponseBody stream=outputStream -> {

    

        // 第一段

        Context modelMain=getmessengerMainContext(request, response, aliId);

        flushVm("/velocity/layout/Main.vm", modelMain, writer);

    

        // 第二段

        Context modelSec=getmessengerSecondContext(request, response, aliId, user);

        flushVm("/velocity/layout/Second.vm", modelSec, writer);

    

        // 第三段

        Context modelThird=getmessengerThirdContext(request, response, user);

        flushVm("/velocity/layout/Third.vm", modelThird, writer);

            }

        };

        

        return ResponseEntity.ok()

                .contentType(MediaType.TEXT_HTML)

                .body(stream);

                

    }

}

但是我們在運行時發現vm的部分變量會渲染失敗，卡點了不少時間，后面在排查過程中發現應用在處理http請求時會在ThreadLocal中進行用戶數據、request數據與部分上下文的存儲，而后續vm數據準備時，有一部分數據是直接從中讀取或者間接依賴的，而StreamingResponseBody本身是異步的（可以看如下的代碼注釋），這就導致新開辟的線程讀不到原線程ThreadLocal的數據，進而渲染錯誤：

/**

 * A controller method return value type for asynchronous request processing

 * where the application can write directly to the response {@code OutputStream}

 * without holding up the Servlet container thread.

 *

 * <p><strong>Note:</strong> when using this option it is highly recommended to

 * configure explicitly the TaskExecutor used in Spring MVC for executing

 * asynchronous requests. Both the MVC Java config and the MVC namespaces provide

 * options to configure asynchronous handling. If not using those, an application

 * can set the {@code taskExecutor} property of

 * {@link org.springframework.web.servlet.mvc.method.annotation.RequestMappingHandlerAdapter

 * RequestMappingHandlerAdapter}.

 *

 * @author Rossen Stoyanchev

 * @since 4.2

 */

@FunctionalInterface

public interface StreamingResponseBody {




  /**

   * A callback for writing to the response body.

   * @param outputStream the stream for the response body

   * @throws IOException an exception while writing

   */

  void writeTo(OutputStream outputStream) throws IOException;




}

三、措施二：非流量中間件優化

在性能優化過程中，我們發現在流量高峰期，某個服務接口的平均耗時會顯著升高，結合arths分析發現，是由于在流量高峰期，對于配置中心的調用被限流了。原因是配置中心的使用不規范，每次都是調用getConfig方法從配置中心服務端拉取的數據。

在讀取配置中心的配置時，更標準的使用方法是由配置中心主動推送變更，客戶端監聽配置信息緩存到本地，這樣，每次讀取配置其實讀取的是機器的本地緩存，可以參考如下的方式：

public static void registerDynamicConfig(final String dataIdKey, final String groupName) {

    IOException initError=null;




    try {

        String e=Diamond.getConfig(dataIdKey, groupName, DEFAULT_TIME_OUT);

        if(e !=null) {

            getGroup(groupName).put(dataIdKey, e);

        }




        logger.info("Diamond config init: dataId=" + dataIdKey + ", groupName=" + groupName + "; initValue=" + e);

    } catch (IOException e) {

        logger.error("Diamond config init error: dataId=" + dataIdKey, e);

        initError=e;

    }




    Diamond.addListener(dataIdKey, groupName, new ManagerListener() {

        @Override

        public Executor getExecutor() {

            return null;

        }




        @Override

        public void receiveConfigInfo(String s) {

            String oldValue=(String)DynamicConfig.getGroup(groupName).get(dataIdKey);

            DynamicConfig.getGroup(groupName).put(dataIdKey, s);

            DynamicConfig.logger.warn(

                "Receive config update: dataId=" + dataIdKey + ", newValue=" + s + ", oldValue=" + oldValue);

        }

    });

    if(initError !=null) {

        throw new RuntimeException("Diamond config init error: dataId=" + dataIdKey, initError);

    }

}

四、措施三：數據直出

1. 靜態圖片直出，頁面上有靜態的loge圖片，原本為cdn地址，在瀏覽器渲染時，需要建聯并會搶占線程，對于這類不會發生發生變化的圖片，可以直接替換為base64的形式，js可以直接加載。
2. 加載數據直出，這部分需要根據具體業務來分析，部分業務數據是瀏覽器運行js腳本在本地二次請求加載的，由于低端機以及本地瀏覽器的能力限制，如果需要加載的數據很多，就很導致js線程的擠占，拖慢整體的時間，因此，可以考慮在服務器將部分數據預先加載好，隨http請求一起給瀏覽器，減少這部分的卡點。

數據直出有利有弊，對于頁面的加載性能有正向影響的同時，也會同時導致HTTP的response增大以及服務端RT的升高。數據直出與流式分塊傳輸相結合的效果可能會更好，當服務端分塊響應HTTP請求時，本身的response就被切割成多塊，單次大小得到了控制，流式分塊傳輸下，服務端分批執行數據準備的策略也能很好的緩沖RT增長的問題。

五、措施四：本地緩存

以我們遇到的一個問題為例，我們的云盤文件列表需要在后端準備好文件所屬人的昵稱，這是在后端服務器由用戶id調用會員的rpc接口實時查詢的。分析這個場景，我們不難發現，同一時間，IM場景下的文件所屬人往往是其中歸屬在聊天的幾個人名下的，因此，可以利用HashMap作為緩存rpc查詢到的會員昵稱，避免重復的查詢與調用。

六、措施五：下線歷史債務

針對有歷史包袱的應用，歷史債務導致的額外耗時往往很大，這些歷史代碼可能包括以下幾類：

• 未下線的實驗或者分流接口調用；

• 時間線拉長，這部分的代碼殘骸在所難免，而且積少成多，累計起來往往有幾十上百毫秒的資源浪費，再加上業務開發時，大家往往沒有額外資源去評估這部分的很多代碼是否可以下線，因此可以借助性能優化的契機進行治理。

• 已經廢棄的vm變量與重復變量治理。

• 對vm變量的盤點過程中發現有很多之前在使用但現在已經廢棄的變量。當然，這部分變量的需要前后端同學共同梳理，防止下線線上依舊依賴的變量。

作者:樹塔

來源-微信公眾號:阿里云開發者

出處:https://mp.weixin.qq.com/s/06eND-fUGQ7Y6gwJxmvwQQ