開源|ns4_frame分佈式服務框架開發指南

時間 2019-11-15

原文原文鏈接

導語：宜信於2019年3月29日正式開源nextsystem4（如下簡稱「NS4」）系列模塊。這次開源的NS4系列模塊是圍繞當前支付系統笨重、代碼耦合度高、維護成本高而產生的分佈式業務系統解決方案。NS4系列框架容許建立複雜的流程/業務流，對於業務服務節點的實現可串聯，可分佈式。其精簡、輕量，實現了「脫容器」（不依賴tomcat、jetty等容器）獨立運行。NS4系列框架的設計理念是將業務和邏輯進行分離，開發人員只需經過簡單的配置和業務實現就能夠實現邏輯複雜、性能高效、功能穩定的業務系統。【點擊查看框架總體介紹】java

NS4系列包括4個開源模塊，分別是：ns4_frame分佈式服務框架、ns4_gear_idgen ID 生成器組件（NS4框架Demo示例）、ns4_gear_watchdog 監控系統組件（服務守護、應用性能監控、數據採集、自動化報警系統）和ns4_chatbot通信組件。本文將詳細介紹ns4_frame分佈式服務框架開發指南。git

項目開源地址：https://github.com/newsettle/ns4_framegithub

1、框架介紹

ns4_frame本質上是兩個應用加三套開發框架組合起來的分佈式業務框架。redis

1.1 使用範圍

ns4_frame分佈式框架主要適用於業務類型爲消息流或者業務核心模型爲流式業務的業務系統。它支持消息分發、傳遞、追蹤，支持分步驟、分批次的消息處理，對於信息流、數據流等消息驅動型的業務尤其契合。緩存

1.2 項目結構

ns4_frame框架是一套MAVEN父子項目，由五個項目組成:tomcat

NS_MQ ：負責和底層消息隊列進行通訊，提供了對消息隊列進行操做的API。
NS_TRANSPORTER：經過調用NS_MQ提供的API,對業務消息進行收取、處理、轉發。
NS_CHAIN ：一個可選開發框架，負責對同一個jvm中的業務處理步驟進行鏈條式的整合，組成當前業務模塊的業務處理流程。
NS_CONTROLLER：一個業務消息轉發應用，負責將接收到的消息轉給對應的業務模塊進行處理，同時負責將業務模塊根據總體業務進行關聯。NS_CONTROLLER本質是一個獨立的應用系統，構建於 NS_TRANPORTOR和NS_CHAIN之上。
NS_DISPATCHER ：ns4_frame架構規定的消息入口，經過提供的http服務接受業務系統邊界外的http請求，並將請求轉化成業務系統內部通訊使用的消息協議格式。

2、基礎入⻔

2.1 開發環境配置

開發語言:JAVA服務器

JDK版本:JDK1.7架構

MAVEN版本:3.3以上併發

REDIS版本:3.0以上框架

以上是開發環境必備的組件和配置，其中java爲開發語言，maven爲項目編譯打包部署必備, redis做爲消息中間件使用。

2.2 運行

ns4_frame運行至少須要啓動三個jvm項目才能完整運行。啓動整個項目分爲以下三步:

第一步: ns4_frame消息入口是一個http接口，http服務是由NS_DISPATCHER項目提供的，因此咱們第一件事情就是要把NS_DISPATCHER運行起來。要運行NS_DISPATCHER，直接運行Bootstrap類的main方法便可。默認的NS_DISPATCHER會在本機(127.0.0.1)的8027端口上監聽http請求,若是收到http請求，默認會將http請求轉換成內部通訊消息，並存儲到本機(127.0.0.1)的 redis中，默認訪問的redis端口號是6379。
第二步: NS_CONTROLLER負責接收NS_DISPATCHER傳入的消息，並根據配置進行消息分發。因此咱們隨後須要運行NS_CONTROLLER項目(爲了方便，如下簡稱「CONTROLLER」) 。在CONTROLLER項目中咱們不能直接運行，須要配置一些東⻄。CONTROLLER要運行至少須要指定一個配置文件位置。這個配置文件須要經過java命令參數來指定。假設我如今指定java運行參數 -Dconfigfile=nscontroller.xml 這個參數本質上是給CONTROLLER底層的NS_TRANSPORTER使用的，它指明瞭 NS_TRANSPORTER必須得配置文件位置，使得CONTROLLER能順利利用 NS_TRANSPORTER進行消息收發。默認狀況下，CONTROLLER還會到classpath下去找關於NS_CHAIN須要的配置文件，默認路徑是classpath下的nschainconfig目錄，在這個目錄下全部的xml文件會被認做是NS_CHAIN須要的配置文件集合。當配置文件配置好後，能夠經過調用 com.creditease.ns.transporter.context.XmlAppTransporterContext的 main方法來啓動NS_CONTROLLER 。
第三步: 在這個步驟中咱們須要啓動本身的業務項目，在這個業務項目中，必須有如下三個前置條件:
- 業務項目須要創建在NS_TRANSPORTER框架之上。
- 業務項目的消息隊列名稱必須和CONTROLLER項目中配置的隊列名一致。
- 業務啓動必須經過 com.creditease.ns.transporter.context.XmlAppTransporterContext的 main方法來啓動。

完成以上的三個步驟，一個基本的ns4_frame系統就搭建好並運行起來了。

3、項目架構

3.1 層次劃分

上圖展現了ns4_frame每一個系統的層次結構。

底層是以redis做爲消息中間件，對消息中間件的操做被封裝入了NS_MQ項目，它向上層提供了對消息隊列的操做API接口。
在NS_MQ的上層是NS_TRANSPORTER,它本質是一套消息收發處理框架，它負責接收消息後反向回調業務代碼，並將消息交給業務層處理。當業務層處理完畢後，它負責將處理後的消息返回到redis中。
NS_CHAINS是一套開發輔助框架，它負責將一個模塊的業務處理步驟解耦成一個個零散的任務，並能夠隨意以任何順序作關聯。
NS_CONTROLLER是一個項目，它本質上是一個獨立的應用，它負責將總體業務分解成一個個節點，並經過配置將他們以必定的順序關聯起來，並經過消息機制，將這些節點結合起來造成一套業務系統。
NS_DISPATCHER也是一個項目，它是以NETTY框架做爲基礎，開發出的一個能提供基本的 http服務的獨立應用。同時它也是業務系統和外部通信的惟一邊界。

3.2 運行流程

ns4_frame整套系統本質上其實就是一套消息中間件服務加開發框架，總體的結構圖以下:

上圖顯示了一個ns4_frame總體分佈式項目的運行流程，一個消息的運轉流程按以下順序:

NS_DISPATCHER收到http請求，並將http請求轉化爲內部消息協議放入指定的消息隊列中(根據配置文件)。
NS_CONTORLLER從步驟1指定的隊列接收到消息，並根據配置的服務編排開始按照順序將消息發送到每一個服務步驟對應的消息隊列中。
業務系統收到步驟2中NS_CONTROLLER指定的消息隊列接收到消息並開始處理，處理完畢後，將結果返回。
NS_CONTROLLER收到業務系統的響應，開始根據配置好的服務，將返回的消息結果發送到下一個服務對應的消息隊列中。

4、NS_MQ框架介紹

4.1 核心類和接口

RedisMQTemplate類：封裝了全部和消息隊列的操做相關的API
MQConfig：存儲了全部和底層消息中間件相關的配置。

4.2 配置方案

默認的，在沒有作任何配置的狀況下，NS_MQ會自動訪問本機(127.0.0.1)的6379端口的redis，若是沒有，則會報異常。一般，NS_MQ會去找classpath下一個名爲ns_mq.properties的配置文件，這個配置文件中存儲着全部和底層消息中間件相關的屬性。

列舉一些關鍵的配置元素:

redis.type 1 表明redis單機 2 表明redis集羣默認爲1
redis.single/cluster.host redis單機或者集羣的主機地址(包含端口)
redis.single/cluster.maxTotal redis單機或者集羣的最大鏈接數
redis.single/cluster.miniIdle redis單機或者集羣的最小閒置鏈接數
redis.single/cluster.maxIdle redis單機或者集羣的最大閒置鏈接數
redis.single/cluster.connectionTimeout redis單機或者集羣的嘗試鏈接的超時時間(還沒有鏈接到服務須要等待的時間)
redis.single/cluster.socketTimeout redis單機或者集羣鏈接後socket閒置的超時時間

5、NS_TRANSPORTER框架介紹

5.1 框架架構

上圖展現了整個NS_TRANSPORTER的總體架構，整套框架收發處理消息分爲以下三個步驟:

首先由接收消息的線程(Fetcher線程)經過NS_MQ從底層消息中間件獲取消息並放入到本地消息緩存。
消息處理線程(Handler線程)從本地消息緩存中取出消息，並調用業務層的方法實現對消息進行處理，處理完畢後，將處理後的消息放到本地發送緩存。
發送線程(Sender線程)從本地發送緩存取出消息後，將消息經過NS_MQ將消息放入底層消息中間件。

5.2 核心類和接口

ServiceMessage：對各個模塊之間傳遞的消息的java封裝，包含了模塊間通訊須要知道的任何信息；
Worker：業務層須要實現此接口的doWork方法,實現此接口的對象會被NS_TRANSPORTER的Handler線程回調用來對ServiceMessage中的信息進行處理。
ActionWorker：已經部分封裝好的抽象類，實現了Worker接口，業務層能夠直接繼承這個抽象類，簡化開發。

5.3 配置方案

默認的，NS_TRANSPORTER會去找名爲configfile的系統變量，這個系統變量的值就是NS_TRANSPOTER須要的配置文件所在的路徑，NS_TRANSPORTER會找到這個xml配置文件，並在解析相關的配置後啓動。

NS_TRANSPORTER相關的配置文件模板以下:

<queues>
     <prefix></prefix>
     <launchers>
           <launcher>
<class name="類的全名" method="method方法名" property="" />
<class name="類的全名" static-method="method方法名" /> </launcher>
     </launchers>
       <inqueues>
           <queue>
               <name></name>
<fetchernum></fetchernum> <buffersize></buffersize> <handlersize></handlersize> <serviceClass></serviceClass> <sendernum></sendernum>
           </queue>
     </inqueues>
</queues>

以上xml模板中有以下幾個關鍵元素須要注意：

Launcher：用來定義在整個框架徹底運行以前須要執行的方法。
queue：在這個元素下 name元素表示須要監聽的底層消息中間件的隊列名。
Fetchernum：表示監聽消息隊列並獲取消息的線程數，默認是1。
buffersize：表示本地接收/發送消息隊列的大小默認是100。
handlersize：表示處理消息的線程數，默認是10。
Serviceclass：表示具體的處理消息的業務類，這個類必須實現了Worker接口。
Sendernum：表示從本地發送消息隊列中獲取消息後發送到底層消息中間件的線程數。

6、NS_CHAIN框架介紹

6.1 框架架構

因爲NS_CHAIN本質是一個純開發框架，故暫時忽略此框架的框架架構。

6.2 核心類和接口

暫略

6.3 配置方案

本節將詳細介紹NS_CHAINS的配置。

NS_CHAINS啓動時會去找系統變量chainconfig，這個變量的值就是NS_CHAINS配置文件所在的路徑。NS_CHAINS支持配置目錄(目錄下的全部xml格式文件都被視做NS_CHAINS框架的配置文件)和配置文件。

對於NS_CHAINS的配置格式咱們大體列舉出關鍵要素以下:

catalog：這個至關於一個完整的服務或者一個命名空間，是NS_CHAINS對外服務的基本單位，NS_CHAINS外部系統只能看到catalog。
Command：這是NS_CHAINS任務執行的最小單位，全部執行任務均可以以command的形式被調用執行。
Chain：這是一個command的容器，能夠將多個command的任務組合成一個執行鏈路。
Group：這個一個command的組合，它能夠將多個command組合成一個總體，並按照配置順序執行。
同時NS_CHAINS的配置具備完整的邏輯語法，支持if條件判斷，while循環結構和順序結構。

7、NS_DISPATCHER應用介紹

7.1 框架架構

NS_DISPATCHER本質是一個獨立的創建在Netty框架上的一個能提供http服務的獨立應用，因此框架結構此處從略。

7.2 核心類和接口

NS_DISPATCHER是以NETTY框架爲基礎的，因此其核心類就是以下的幾個協議處理器:

HttpDispatcherServerHandler：主要負責解析傳入的http請求，並封裝成對應的java對象交給 HttpRPCHandler作進一步處理。
HttpRPCHandler：主要接收上一步封裝好的java對象，並取出對應的請求參數、請求內容等，封裝成系統內部傳輸用的協議對象，並能夠以同步請求響應模式/異步發送模式將協議對象放入底層消息中間件。

7.3 配置方案

NS_DISPATCHER啓動會去找ns_dispatcher.properties文件，下面介紹配置的關鍵元素:

http.port：指定了http服務的監聽端口。
dispatcher.pool.num：指定了dispatcher的併發線程數，dispatcher的性能和這個參數有很是大的關係。
dispatcher.queuename：封裝好的內部協議消息要放入的隊列的名字，NS_DISPATCHER也支持https，因此，若是在ns_dispatcher.properties文件中有以下幾個選項，那麼NS_DISPATCHER也會啓動對應的https服務。
ca.path：指明瞭可信任證書的路徑。
key.path：指明瞭公鑰的路徑。
https.port：指明瞭https服務監聽的端口。

8、NS_CONTROLLER應用介紹

8.1 框架架構

NS_CONTROLLER本質是創建在NS_TRANSPORTER和NS_CHAINS上的獨立應用，核心就是 NS_TRANSPORTER的架構加NS_CHAINS的輔助，故再也不重複列舉其架構。

8.2 核心類和接口

DefaultPublishCommand：這是NS_CONTROLLER對於NS_CHAINS的一個擴展，它支持同步發送消息，並等待消息的響應，並能夠設置等待響應的超時時間。同時，還支持異步發送消息，不須要等待消息的響應。

8.3 配置方案

遵循NS_TRANSPORTER和NS_CHAINS的配置規則，因此再也不贅述。注意：在NS_CONTROLLER中對於NS_CHAINS的配置作了一些功能擴展，主要是添加了publish的配置元素，這個隨後能夠提供配置模板。

9、項目部署

9.1 部署方案

若是要部署整個ns4_frame項目，請按照如下步驟進行:

部署NS_DISPATCHER項目：NS_DISPATCHER項目是一個Maven項目，首先須要經過mvn:package deploy將整個項目打成一個zip包上傳到服務器，而後解壓成一個目錄。在這個目錄中，有以下幾個子目錄：bin、config、lib、logs。其中，bin目錄中包含了DISPATCHER的啓動腳本；config目錄存放了NS_DISPATCHER必須的配置文件；lib目錄存放了NS_DISPATCHER所須要的全部jar包；logs目錄存放了全部NS_DISPATCHER打印的日誌。
部署NS_CONTROLLER項目：NS_CONTROLLER項目也是一個Maven項目，須要經過mvn:package deploy將整個項目打成一個zip包。目錄結構同NS_DISPATCHER項目，此處再也不贅述。
部署業務代碼：業務代碼請自行按照各個團隊的規則部署。

10、運行日誌

10.1 日誌分類

ns4_frame項目將日誌大體分紅了四類:

*fram.log：系統日誌，屬於整個ns4_frame底層系統內部的日誌，包括系統的啓動，線程的啓動關閉等信息。
*biz.log：業務日誌，全部業務相關的日誌通通會被導向到這裏。
*flow.log：消息流日誌，這裏記錄了系統全部消息的流轉信息。
*mq.log：這裏記錄全部對底層消息中間件進行操做的信息。

10.2 如何查看日誌

業務報錯：若是業務報錯，基本全部的報錯信息都會在*biz.log中查到。
消息流轉: 若是是消息發送響應的問題，基本上在*flow.log中能夠查到或者推斷出相關的信息。
底層消息中間件交互: 若是消息流轉沒法推斷出問題，或者沒法查到對應的消息，就須要轉到*mq.log中進行查詢。

11、其餘

11.1 常⻅問題

ns4_frame系統本質是一個以消息爲通訊機制的分佈式系統，常常出現的問題分紅如下兩部分:

業務異常

因爲業務自己是由底層NS_TRANSPORTER回調來執行的，當業務出現異常的時候，極可能因爲沒有合適的被catch到，從而被底層的NS_TRANSPOTER框架捕獲。對於沒有在*biz.log和stdoout.log中查找到的問題，能夠去查看下*flow.log的日誌，看是否出現了異常被底層NS_TRANSPOTER捕獲了。