標籤: 包裝設計

一. 前言

今天我們繼續來分析用友系列的第二個產品–U8Cloud2.5 ,apilink方式的API.官網的API文檔地址如下：U8API文檔 因為我們主要是憑證對接，所以使用到的模塊有總賬、基礎檔案這兩個模塊。

Ps:2.5的財務系統如果不是最新補丁的話，要記得打補丁，不然後續的科目接口會有問題。

二. API參數

2.1 遠程訪問財務系統

如果我們對接的財務系統是公有雲的U8C的話，你會得到一個遠程的財務系統的地址，接着使用UClient工具，即 通過集成友戶通，為企業應用提供了統一的單點登陸支持，支持CA登陸、短信登陸、用戶名／密碼登陸，支持企業用戶系統與友戶通進行綁定，實現統一的用戶登陸服務 的這麼一個工具。

具體的添加應用的步驟為

2.2 全局請求頭

首先，我們必須要在網站內註冊賬號，API集市上有各個接口的詳細說明，我們需要獲取一個apicode參數，每個API模塊在點擊購買后系統會自動分配該模塊的apicode，所以這也就是我們需要兩個不同的apicode.

基本上U8cloud2.5的版本接口，需要涉及到的請求參數就是這個了，接着我們就可以愉快的進行開發工作了。

如圖，固定的全局請求頭參數有以下幾個：

1.authoration–驗證方式；默認是apicode

2.apicode—模塊的apicode.也就是我們上文中購買模塊后得到的參數.

3.system—系統類型. 1—測試. 2—正式.

4.trantype–翻譯類型； 默認為code.即採用編碼模式.

2.3 基礎檔案

基礎檔案，我們主要使用到的API接口有科目查詢.

會計主體賬簿編碼–我們可以從財務系統里獲取，具體的獲取方式如下

打開U8Client,使用正確的用戶名和密碼登錄財務系統.在企業建模平台–》基礎檔案–》組織機構–》會計主體 一欄，可以看到我們使用的會計主體賬簿編碼.如我們要使用的就是40001-9999

其中40001為公司編碼，9999為會計方案.可以看到是採用分頁形式來訪問的，所以如果我們要一次性獲取到所有的會計科目，可以採用以下方法。

        public AccountQueryResponse QueryAccount(string pk_subjscheme, string pageIndex, string glorgBookCode)
        {
            var request = new AccountQueryRequest();
            var pms = new Dictionary<string, object>();
            pms.Add("pk_subjscheme", pk_subjscheme);
            pms.Add("glorgbookcode", glorgBookCode);
            pms.Add("page_now", pageIndex);
            pms.Add("page_size", "100");
            request.SetPostParameters(pms);
            return _Client.Excute(request);
        }

        public List<U8AccountResult> GetAccountQueryResult(string pk_subjscheme, string pageIndex, string glorgBookCode)
        {
            var list = new List<U8AccountResult>();
            var response = QueryAccount(pk_subjscheme, pageIndex, glorgBookCode);
            if (response != null && response.status == "success" && response.data != null)
            {
                var result = JsonConvert.DeserializeObject<AccountQueryResult>(response.data);
                list = result.datas == null ? new List<U8AccountResult>() : result.datas.ToList().Select(x => new U8AccountResult
                {
                    balanorient = x.accsubjParentVO.balanorient,
                    subjcode = x.accsubjParentVO.subjcode,
                    subjname = x.accsubjParentVO.subjname,
                    dispname = x.accsubjParentVO.dispname,
                    remcode = x.accsubjParentVO.remcode,
                    subjId = x.accsubjParentVO.pk_accsubj,
                    endflag = x.accsubjParentVO.endflag,
                    subjectAssInfos = x.subjass == null ? new List<AccSubjectAssInfo>() : x.subjass.ToList().Select(t => new AccSubjectAssInfo
                    {
                        bdcode = t.bdcode,
                        bddispname = t.bddispname,
                        bdname = t.bdname
                    }).ToList()
                }).ToList();
            }
            return list;
        }

///獲取所有的會計科目
        public List<U8AccountResult> GetAllAccount(string pk_subjescheme, string glorgBookCode)
        {
            var pageNo = "1";
            var list = new List<U8AccountResult>();
            var response = QueryAccount(pk_subjescheme, pageNo, glorgBookCode);
            if (response != null && response.status == "success" && response.data != null)
            {
                var result = JsonConvert.DeserializeObject<AccountQueryResult>(response.data);
                var allCount = Math.Ceiling(Convert.ToDouble(result.allcount) / result.retcount);
                if (allCount >= 1)
                {
                    for (int i = 1; i <= allCount; i++)
                    {
                        var resultList = GetAccountQueryResult(pk_subjescheme, i.ToString(), glorgBookCode);
                        list.AddRange(resultList);
                    }
                }
            }
            return list;
        }

allCount為總條數，retCount為當次請求的分頁條數，默認最大值為100，即接口每次只能返回100條數據，超過100條的數據量，我們就要採用分頁的形式來獲取了。

這裏，有兩個隱藏的坑需要注意一下

1.如果沒有打過類似“patch_會計科目查詢api查詢條件增加會計主體賬簿編碼”這樣的補丁，我們無法傳入會計主體賬簿編碼，就默認返回該集團下所有公司的會計科目，這樣顯然達不到我們的目的。

2.返回的會計科目中沒有輔助核算明細，這對於我們傳輸憑證也是有影響的。所以這兩個補丁，如果我們在對接的過程中發現有接口有問題，那麼就要聯繫總部的老師幫忙打相應的補丁了.

2.4 總賬

總賬模塊，主要是我們的憑證傳輸了.

我們先來看憑證的保存,憑證保存要傳入相應的憑證json串.

        public GL_VoucherInsertResponse InsertVoucher(List<object> models)
        {
            var request = new GL_VoucherInsertRequest();
            var pms = new Dictionary<string, object>();
            pms.Add("voucher", models);
            request.SetPostParameters(pms);
            return _Client.Excute(request);
        }
///憑證新增結果
        public List<U8GLVoucherResult> GetVoucherInsertResult(List<object> models)
        {
            var list = new List<U8GLVoucherResult>();
            var response = InsertVoucher(models);
            if (response != null && response.status == "success")
            {
                if (response.data != null && !response.data.IsNullOrEmpty())
                {
                    var result = JsonConvert.DeserializeObject<List<VoucherResult>>(response.data);
                    list = result.Select(x => new U8GLVoucherResult
                    {
                        explanation = x.explanation,
                        glorgbook_code = x.glorgbook_code,
                        glorgbook_name = x.glorgbook_name,
                        no = x.no,
                        pk_glorgbook = x.pk_glorgbook,
                        pk_voucher = x.pk_voucher,
                        totalcredit = x.totalcredit,
                        totaldebit = x.totaldebit,
                        pk_vouchertype = x.pk_vouchertype,
                        vouchertype_code = x.vouchertype_code,
                        vouchertype_name = x.vouchertype_name,
                        prepareddate = Convert.ToDateTime(x.prepareddate),
                        errorMsg = ""
                    }).ToList();
                }
            }
            else
            {
                list.Add(new U8GLVoucherResult { errorMsg = response.errormsg });
            }
            return list;
        }

借貸方,憑證字主要用於我們新增后回執進行憑證記錄的.

接着我們來看憑證保存的實體類.

 public class U8VoucherModel
    {
        /// <summary>
        /// 是否差異憑證
        /// </summary>
        public bool ISDIFFLAG { get; set; }
        /// <summary>
        /// 附單據數
        /// </summary>
        public string attachment { get; set; }
        public Detail[] details { get; set; }
        /// <summary>
        /// 憑證摘要
        /// </summary>
        public string explanation { get; set; }
        /// <summary>
        /// 憑證號
        /// </summary>
        public string no { get; set; }
        /// <summary>
        /// 公司
        /// </summary>
        public string pk_corp { get; set; }
        /// <summary>
        /// 賬簿
        /// </summary>
        public string pk_glorgbook { get; set; }
        /// <summary>
        /// 制單人編碼
        /// </summary>
        public string pk_prepared { get; set; }
        /// <summary>
        /// 憑證類別簡稱
        /// </summary>
        public string pk_vouchertype { get; set; }
        /// <summary>
        /// 制單日期
        /// </summary>
        public string prepareddate { get; set; }
        /// <summary>
        /// 憑證類型
        /// </summary>
        public int voucherkind { get; set; }
    }

    public class Detail
    {
        /// <summary>
        /// 原幣貸方金額
        /// </summary>
        public string creditamount { get; set; }
        /// <summary>
        /// 貸方數量
        /// </summary>
        public string creditquantity { get; set; }
        /// <summary>
        /// 原幣借方金額
        /// </summary>
        public string debitamount { get; set; }
        /// <summary>
        /// 借方數量
        /// </summary>
        public string debitquantity { get; set; }
        /// <summary>
        /// 分錄號
        /// </summary>
        public string detailindex { get; set; }
        /// <summary>
        /// 匯率
        /// </summary>
        public string excrate1 { get; set; }
        /// <summary>
        /// 摘要
        /// </summary>
        public string explanation { get; set; }
        /// <summary>
        /// 本幣貸方金額
        /// </summary>
        public string localcreditamount { get; set; }
        /// <summary>
        /// 本幣借方金額
        /// </summary>
        public string localdebitamount { get; set; }
        /// <summary>
        /// 科目
        /// </summary>
        public string pk_accsubj { get; set; }
        /// <summary>
        /// 幣別編碼
        /// </summary>
        public string pk_currtype { get; set; }
        /// <summary>
        /// 單價
        /// </summary>
        public string price { get; set; }
        public Ass[] ass { get; set; }
        public Cashflow[] cashflow { get; set; }
    }

    public class Ass
    {
        /// <summary>
        /// 輔助核算類型編碼
        /// </summary>
        public string checktypecode { get; set; }
        /// <summary>
        /// 輔助核算值編碼
        /// </summary>
        public string checkvaluecode { get; set; }
    }

    public class Cashflow
    {
        public string cashflow_code { get; set; }
        public string currtype_code { get; set; }
        public int money { get; set; }
    }

整個憑證對接下來，其實坑不是很多，主要在於前期接口文檔的研究，參數的獲取以及測試接口連通性上面.

三.結束語

希望文章能在你開發API接口對接的路上一些幫助和解疑，也希望同樣做API對接的小夥伴，我們可以多多交流。祝你在開發的道路上勇往直前。

我是程序猿貝塔，一個分享自己對接過財務系統API經歷和生活感悟的程序員。

本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理

【其他文章推薦】

※廣告預算用在刀口上，台北網頁設計公司幫您達到更多曝光效益

※別再煩惱如何寫文案,掌握八大原則!

※教你寫出一流的銷售文案?

※超省錢租車方案

※廣告預算用在刀口上，台北網頁設計公司幫您達到更多曝光效益

※產品缺大量曝光嗎?你需要的是一流包裝設計!

本文收錄在個人博客：www.chengxy-nds.top，技術資源共享，一起進步

最近公司貌似融到資了！開始發了瘋似的找渠道推廣，現在終於明白為啥前一段大肆的招人了，原來是在下一盤大棋，對員工總的來看是個好事，或許是時候該跟boss提一提漲工資的話題了。

不過，漲工資還沒下文，隨之而來的卻是一車一車的需求，每天都有新渠道接入，而且每個渠道都要提供個性化支持，開發量陡增。最近都沒什麼時間更文，準點下班都成奢望了！

由於推廣渠道的激增，而每一個下單來源在下單時都做特殊的邏輯處理，可能每两天就會加一個來源，已經把之前的下單邏輯改的面目全。出於長遠的考慮，我決定對現有的邏輯進行重構，畢竟長痛不如短痛。

傳統的實現方式

我們看下邊的偽代碼，大致就是重構前下單邏輯的代碼，由於來源比較少，簡單的做if-else邏輯判斷足以滿足需求。

現在每種訂單來源的處理邏輯都有幾百行代碼，看着已經比較臃腫，可我愣是遲遲沒動手重構，一方面業務方總像催命鬼一樣的讓你趕工期，想快速實現需求，這樣寫是最快；另一方面是不敢動，面對古董級代碼，還是想求個安穩。

但這次來源一下子增加幾十個，再用這種方式做已經無法維護了，想象一下那種臃腫的if-else代碼，別說開發想想都頭大！

public class OrderServiceImpl implements IOrderService {
    @Override
    public String handle(OrderDTO dto) {
        String type = dto.getType();
        if ("1".equals(type)) {
            return "處理普通訂單";
        } else if ("2".equals(type)) {
            return "處理團購訂單";
        } else if ("3".equals(type)) {
            return "處理促銷訂單";
        }
        return null;
    }
}

策略模式的實現方式

思來想去基於當前業務場景重構，還是用策略模式比較合適，它是oop中比較著名的設計模式之一，對方法行為的抽象。

策略模式定義了一個擁有共同行為的算法族，每個算法都被封裝起來，可以互相替換，獨立於客戶端而變化。

一、策略模式的使用場景：

• 針對同一問題的多種處理方式，僅僅是具體行為有差別時；
• 需要安全地封裝多種同一類型的操作時；
• 同一抽象類有多個子類，而客戶端需要使用if-else 或者 switch-case 來選擇具體子類時。

這個是用策略模式修改後代碼：

@Component
@OrderHandlerType(16)
public class DispatchModeProcessor extends AbstractHandler{

	@Autowired
	private OrderStencilledService orderStencilledService;
	
	@Override
	public void handle(OrderBO orderBO) {
		
		/**
    	 * 訂單完結廣播通知(1 - 支付完成)
    	 */
    	orderStencilledService.dispatchModeFanout(orderBO);
		
    	/**
    	 *  SCMS 出庫單
    	 */
    	orderStencilledService.createScmsDeliveryOrder(orderBO.getPayOrderInfoBO().getLocalOrderNo());
	}
}

每個訂單來源都有自己單獨的邏輯實現類，而每次需要添加訂單來源，直接新建實現類，修改@OrderHandlerType(16)的數值即可，再也不用去翻又臭又長的if-lese。

不僅如此在分配任務時，每個人負責開發幾種訂單來源邏輯，都可以做到互不干擾，而且很大程度上減少了合併代碼的衝突。

二、具體的實現過程：

1、定義註解

定義一個標識訂單來源的註解@OrderHandlerType

@Target(ElementType.TYPE)
@Retention(RetentionPolicy.RUNTIME)
@Documented
@Inherited
public @interface OrderHandlerType {
	int value() default 0;
}

2、抽象業務處理器

向上抽象出來一個具體的業務處理器

public abstract class AbstractHandler {
	abstract public void handle(OrderBO orderBO);
}

3、項目啟動掃描 handler 入口

@Component
@SuppressWarnings({"unused","rawtypes"})
public class HandlerProcessor implements BeanFactoryPostProcessor {
	
	private String basePackage = "com.ecej.order.pipeline.processor";
	
    public static final Logger log = LoggerFactory.getLogger(HandlerProcessor.class);
	
	@Override
	public void postProcessBeanFactory(ConfigurableListableBeanFactory beanFactory) throws BeansException {
		
		Map<Integer,Class> map = new HashMap<Integer,Class>();
		
		ClassScaner.scan(basePackage, OrderHandlerType.class).forEach(x ->{
			int type = x.getAnnotation(OrderHandlerType.class).value();
			map.put(type,x);
		});
		
		beanFactory.registerSingleton(OrderHandlerType.class.getName(), map);
		
		log.info("處理器初始化{}", JSONObject.toJSONString(beanFactory.getBean(OrderHandlerType.class.getName())));
	}
}

4、掃描需要用到的工具類

public class ClassScaner {
	private ResourcePatternResolver resourcePatternResolver = new PathMatchingResourcePatternResolver();

	private final List<TypeFilter> includeFilters = new ArrayList<TypeFilter>();

	private final List<TypeFilter> excludeFilters = new ArrayList<TypeFilter>();

	private MetadataReaderFactory metadataReaderFactory = new CachingMetadataReaderFactory(resourcePatternResolver);
	
	/**
	 * 添加包含的Fiter
	 * @param includeFilter
	 */
	public void addIncludeFilter(TypeFilter includeFilter) {
		this.includeFilters.add(includeFilter);
	}

	/**
	 * 添加排除的Fiter
	 * @param includeFilter
	 */
	public void addExcludeFilter(TypeFilter excludeFilter) {
		this.excludeFilters.add(excludeFilter);
	}
	
	/**
	 * 掃描指定的包，獲取包下所有的Class
	 * @param basePackage 包名
	 * @param targetTypes 需要指定的目標類型,可以是pojo,可以是註解
	 * @return Set<Class<?>>
	 */
	public static Set<Class<?>> scan(String basePackage,
			Class<?>... targetTypes) {
		ClassScaner cs = new ClassScaner();
		for (Class<?> targetType : targetTypes){
			if(TypeUtils.isAssignable(Annotation.class, targetType)){
				cs.addIncludeFilter(new AnnotationTypeFilter((Class<? extends Annotation>) targetType));
			}else{
				cs.addIncludeFilter(new AssignableTypeFilter(targetType));
			}
		}
		return cs.doScan(basePackage);
	}
	
	/**
	 * 掃描指定的包，獲取包下所有的Class
	 * @param basePackages 包名,多個
	 * @param targetTypes 需要指定的目標類型,可以是pojo,可以是註解
	 * @return Set<Class<?>>
	 */
	public static Set<Class<?>> scan(String[] basePackages,
			Class<?>... targetTypes) {
		ClassScaner cs = new ClassScaner();
		for (Class<?> targetType : targetTypes){
			if(TypeUtils.isAssignable(Annotation.class, targetType)){
				cs.addIncludeFilter(new AnnotationTypeFilter((Class<? extends Annotation>) targetType));
			}else{
				cs.addIncludeFilter(new AssignableTypeFilter(targetType));
			}
		}
		Set<Class<?>> classes = new HashSet<Class<?>>();
		for (String s : basePackages){
			classes.addAll(cs.doScan(s));
		}
		return classes;
	}
	
	/**
	 * 掃描指定的包，獲取包下所有的Class
	 * @param basePackages 包名
	 * @return Set<Class<?>>
	 */
	public Set<Class<?>> doScan(String [] basePackages) {
		Set<Class<?>> classes = new HashSet<Class<?>>();
		for (String basePackage :basePackages) {
			classes.addAll(doScan(basePackage));
		}
		return classes;
	}
	
	/**
	 * 掃描指定的包，獲取包下所有的Class
	 * @param basePackages 包名
	 * @return Set<Class<?>>
	 */
	public Set<Class<?>> doScan(String basePackage) {
		Set<Class<?>> classes = new HashSet<Class<?>>();
		try {
			String packageSearchPath = ResourcePatternResolver.CLASSPATH_ALL_URL_PREFIX
					+ ClassUtils.convertClassNameToResourcePath(
							SystemPropertyUtils.resolvePlaceholders(basePackage))+"/**/*.class";
			Resource[] resources = this.resourcePatternResolver.getResources(packageSearchPath);
			for (int i = 0; i < resources.length; i++) {
				Resource resource = resources[i];
				if (resource.isReadable()) {
					MetadataReader metadataReader = this.metadataReaderFactory.getMetadataReader(resource);
					if ((includeFilters.size() == 0 && excludeFilters.size() == 0)|| matches(metadataReader)) {
						try {
							classes.add(Class.forName(metadataReader.getClassMetadata().getClassName()));
						} catch (ClassNotFoundException ignore) {}
					}
				}
			}
		} catch (IOException ex) {
			throw new RuntimeException("I/O failure during classpath scanning", ex);
		}
		return classes;
	}
	
	/**
	 * 處理 excludeFilters和includeFilters
	 * @param metadataReader
	 * @return boolean
	 * @throws IOException
	 */
	private boolean matches(MetadataReader metadataReader) throws IOException {
		for (TypeFilter tf : this.excludeFilters) {
			if (tf.match(metadataReader, this.metadataReaderFactory)) {
				return false;
			}
		}
		for (TypeFilter tf : this.includeFilters) {
			if (tf.match(metadataReader, this.metadataReaderFactory)) {
				return true;
			}
		}
		return false;
	}
}

5、根據類型實例化抽象類

@Component
public class HandlerContext {

	@Autowired
	private ApplicationContext beanFactory;

	public  AbstractHandler getInstance(Integer type){
		
		Map<Integer,Class> map = (Map<Integer, Class>) beanFactory.getBean(OrderHandlerType.class.getName());
		
		return (AbstractHandler)beanFactory.getBean(map.get(type));
	}
	
}

6、調用入口

我這裡是在接受到MQ消息時，處理多個訂單來源業務，不同訂單來源路由到不同的業務處理類中。

@Component
@RabbitListener(queues = "OrderPipelineQueue")
public class PipelineSubscribe{
 
	private final Logger LOGGER = LoggerFactory.getLogger(PipelineSubscribe.class);
	
	@Autowired
	private HandlerContext HandlerContext;
	
	@Autowired
	private OrderValidateService orderValidateService;
	
    @RabbitHandler
    public void subscribeMessage(MessageBean bean){
    	
    	OrderBO orderBO = JSONObject.parseObject(bean.getOrderBO(), OrderBO.class);
    	
    	if(null != orderBO &&CollectionUtils.isNotEmpty(bean.getType()))
    	{
    		for(int value:bean.getType())
    		{
       		 AbstractHandler handler = HandlerContext.getInstance(value);
       		 handler.handle(orderBO);
    		}
		}
	}
}

接收實體 MessageBean 類代碼

public class MessageBean implements Serializable {
    private static final long serialVersionUID = 5454831432308782668L;
    private String cachKey;
    private List<Integer> type;
    private String orderBO;

    public MessageBean(List<Integer> type, String orderBO) {
        this.type = type;
        this.orderBO = orderBO;
    }
}

以上設計模式方式看着略顯複雜，很些小夥伴提出質疑：“你為了個if-else，弄的如此的麻煩，又是自定義註解，又弄這麼多類不麻煩嗎？” 還有一些小夥伴糾結於性能問題，策略模式的性能可能確實不如if-else。

但我覺得吧增加一點複雜度、犧牲一丟丟性能，換代碼的整潔和可維護性還是值得的。不過，一個人一個想法，怎麼選還是看具體業務場景吧！

策略模式的優缺點

優點

• 易於擴展，增加一個新的策略只需要添加一個具體的策略類即可，基本不需要改變原有的代碼，符合開放封閉原則
• 避免使用多重條件選擇語句，充分體現面向對象設計思想 策略類之間可以自由切換，由於策略類都實現同一個接口，所以使它們之間可以自由切換
• 每個策略類使用一個策略類，符合單一職責原則 客戶端與策略算法解耦，兩者都依賴於抽象策略接口，符合依賴反轉原則
• 客戶端不需要知道都有哪些策略類，符合最小知識原則

缺點

• 策略模式，當策略算法太多時，會造成很多的策略類
• 客戶端不知道有哪些策略類，不能決定使用哪個策略類，這點可以通過封裝common公共包解決，也可以考慮使IOC容器和依賴注入的方式來解決。

以下是訂單來源策略類的一部分，不得不說策略類確實比較多。

總結

凡事都有他的兩面性，if-else多層嵌套和也都有其各自的優缺點：

• if-else的優點就是簡單，想快速迭代功能，邏輯嵌套少且不會持續增加，if-else更好些，缺點也是顯而易見，代碼臃腫繁瑣不便於維護。

• 策略模式 將各個場景的邏輯剝離出來維護，同一抽象類有多個子類，需要使用if-else 或者 switch-case 來選擇具體子類時，建議選策略模式，他的缺點就是會產生比較多的策略類文件。

兩種實現方式各有利弊，如何選擇還是要依據具體業務場景，還是那句話設計模式不是為了用而用，一定要用在最合適的位置。

閑聊

平常和粉絲私下聊天，好多人對於學設計模式的感受：設計模式背了一大堆，可平常開發還不是成天寫if-else業務邏輯，根本就用不到。

學設計模式也不是用不到，只是有時候沒有合適它的場景而已，像我們今天說的這種業務場景，用設計模式就可以完美的解決嘛。

學了N多技術可工作用不到是一種很常見的事情，一個穩定的項目使用一種技術會有諸多考量的，新技術會不會提升系統複雜度？它有哪些性能瓶頸？這些都必須考慮到，畢竟項目穩定才是最重要，誰也不敢輕易冒險嘗試。

而我們學習技術可不僅為了眼下項目中是否會用到，是要做一個技術積累，做長遠打算，人往高處走，沒點能力可不行。

原創不易，燃燒秀髮輸出內容，希望你能有一丟丟收穫！

整理了幾百本各類技術电子書，送給小夥伴們。關公眾號回復【666】自行領取。和一些小夥伴們建了一個技術交流群，一起探討技術、分享技術資料，旨在共同學習進步，如果感興趣就掃碼加入我們吧！

本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理

【其他文章推薦】

※別再煩惱如何寫文案,掌握八大原則!

※網頁設計一頭霧水該從何著手呢? 台北網頁設計公司幫您輕鬆架站!

※超省錢租車方案

※教你寫出一流的銷售文案?

※網頁設計最專業,超強功能平台可客製化

※產品缺大量曝光嗎?你需要的是一流包裝設計!

相信絕大部分開發者都接觸過用戶註冊的流程，通常情況下大概的流程如下所示：

1. 接收用戶提交註冊信息
2. 持久化註冊信息（數據庫+redis）
3. 發送註冊成功短信（郵件）
4. 寫操作日誌（可選）

偽代碼如下：

public async Task<IActionResult> Reg([FromBody] User user)
{
    _logger.LogInformation("持久化數據開始");
    await Task.Delay(50);
    _logger.LogInformation("持久化結束");
    _logger.LogInformation("發送短信開始");
    await Task.Delay(100);
    _logger.LogInformation("發送短信結束");
    _logger.LogInformation("操作日誌開始");
    await _logRepository.Insert(new Log { Txt = "註冊日誌" });
    _logger.LogInformation("操作日誌結束");
    return Ok("註冊成功");
}

在以上的代碼中，我使用Task.Delay方法阻塞主線程，用以模擬實際場景中的執行耗時。以上流程應該是包含了絕大部分註冊流程所需要的操作。對於任何開發者來講，以上業務流程沒任何難度，無非是順序的執行各個流程的代碼即可。

稍微有點開發經驗的應該會將以上的流程進行拆分，但有些人可能就要問了，為什麼要拆分呢？拆分之後的代碼應該怎麼寫呢？下面我們就來簡單聊下如此場景的正確打開方式。

首先，註冊成功的依據應該是是否成功的將用戶信息持久化（至於是先持久化到數據庫，異或是先寫到redis不在本篇文章討論的範疇），至於發送註冊短信（郵件）以及寫日誌的操作應該不能成為影響註冊是否成功的因素，而發送短信/郵件等相關操作通常情況下也是比較耗時的，所以在對此接口做性能優化時，可優先考慮將短信/郵件以及寫日誌等相關操作與主流程（持久化數據）拆分，使其不阻塞主流程的執行，從而達到提高響應速度的目的。

知道了為什麼要拆，但具體如何拆分呢？怎樣才能用最少的改動，達到所需的目的呢？

條條大路通羅馬，所以要達成我們的目的也是有很多方案的，具體選擇哪種方案需要根據具體的業務場景，業務體量等多種因素綜合考慮，下面我將一一介紹分析相關方案。

在正式介紹可用方案前，筆者想先介紹一種很多新手容易錯誤使用的一種方案（因為筆者就曾經天真的使用過這種錯誤的方案）。

提到異步，絕大部分.net開發者應該第一想到的就是Task，async，await等，的確，async，await的語法糖簡化了.net開發者異步編程的門檻，減少了很多代碼量。通常一個返回Task類型的方法，在被調用時，會在方法的前面加上await，表示需要等待此方法的執行結果，再繼續執行後面的代碼。但如果不加await時，則不會等待方法的執行結果，進而也不會阻塞主線程。所以，有些人可能就會將發送短信/郵件以及寫日誌的操作如下方式進行改造。

public async Task<IActionResult> Reg1([FromBody] User user)
{
    _logger.LogInformation("持久化數據開始");
    await Task.Delay(50);
    _logger.LogInformation("持久化結束");
    _ = Task.Run(async () =>
     {
         _logger.LogInformation("發送短信開始");
         await Task.Delay(100);
         _logger.LogInformation("發送短信結束");
         _logger.LogInformation("操作日誌開始");
         await _logRepository.Insert(new Log { Txt = "註冊日誌" });
         _logger.LogInformation("操作日誌結束");
     });
    return Ok("註冊成功");
}

然後使用jmeter分別壓測改造前和改造后的接口，結果如下：

有沒有被驚訝到？就這樣一個簡單的改造，吞吐量就提高了三四倍。既然已經提高了三四倍，那為什麼說這是一種錯誤的改造方法嗎？各位看官且往下看。

熟悉.netcore的大佬，應該都知道.netcore的依賴注入的生命周期吧。通常情況下，注入的生命周期包括：Singleton，Scope，Transient。
在以上的流程中，假如寫操作日誌的實例的生命周期是Scope，當在Task中調用Controller獲取到的實例的方法時，因為Task.Run並沒有阻塞主線程，當調用Action return后，當前請求的scope注入的對象會被回收，如果對象被回收之後，Task.Run還未執行完，則會報System.ObjectDisposedException: Cannot access a disposed object. 異常。意思是，不能訪問一個已disposed的對象。正確的做法是使用IServiceScopeFactory創建一個新的作用域，在新的作用域中獲取獲取日誌倉儲服務的實例。這樣就可以避免System.ObjectDisposedException異常了。
改造后的示例代碼如下：

public async Task<IActionResult> Reg1([FromBody] User user)
{
    _logger.LogInformation("持久化數據開始");
    await Task.Delay(50);
    _logger.LogInformation("持久化結束");
    _ = Task.Run(async () =>
    {
        using (var scope = _scopeFactory.CreateScope())
        {
            var sp = scope.ServiceProvider;
            var logRepository = sp.GetService<ILogRepository>();
            _logger.LogInformation("發送短信開始");
            await Task.Delay(100);
            _logger.LogInformation("發送短信結束");

            _logger.LogInformation("操作日誌開始");
            await logRepository.Insert(new Log { Txt = "註冊日誌" });
            _logger.LogInformation("操作日誌結束");
        }
    });
    return Ok("註冊成功");
}

雖然得到了正解，但上述的代碼着實有點多，如果一個項目有多個相似的業務場景，就要考慮對CreateScope相關的操作進行封裝。

下面就來一一介紹下筆者覺得實現此業務場景的幾種方案。
1.消息隊列
2.Quartz任務調度組件
3.Hangfire任務調度組件
4.Weshare.TransferJob(推薦)
首先說下消息隊列的方式。準確的說，消息隊列應該是這種場景的最優解決方案，消息隊列的其中一個比較重要的特性就是解耦，從而提高吞吐量。但並不是所有的應用程序都需要上消息隊列。有些業務場景使用消息隊列時，往往會給人一種”殺雞用牛刀”的感覺。

其次Quartz和Hangfire都是任務調度框架，都提供了可實現以上業務場景的邏輯，但Quartz和Hangfire都需要持久化作業數據。雖然Hangfire提供了內存版本，但經過我的測試，發現Hangfire的內存版本特別消耗內存，所以不太推薦使用任務調度框架來實現類似於這樣的業務邏輯。

最後，也就是本文的重點，筆者結合了消息隊列和任務調度的思想，實現了一個輕量級的轉移作業到後台執行的組件。此組件完美的解決了Scope生命周期實例獲取的問題，一行代碼將不需要等待的操作轉移到後台線程執行。
接入步驟如下：
1.使用nuget安裝Weshare.TransferJob
2.在Stratup中注入服務。

services.AddTransferJob();

3.通過構造函數或其他方法獲取到IBackgroundRunService的實例。
4.調用實例的Transfer方法將作業轉移到後台線程。

_backgroundRunService.Transfer(log=>log.Insert(new Log(){Txt = "註冊日誌"}));

就是這麼簡單的實現了這樣的業務場景，不僅簡化了代碼，而且大大提高了系統的吞吐量。

下面再來一起分析下Weshare.TransferJob的核心代碼（畢竟文章要點題）。各位器宇不凡的看官請繼續往下看。
下面的代碼是AddTransferJob方法的實現：

public static IServiceCollection AddTransferJob(this IServiceCollection services)
{
    services.AddSingleton<IBackgroundRunService, BackgroundRunService>();
    services.AddHostedService<TransferJobHostedService>();
    return services;
}

聰明”絕頂”的各位看官應該已經發現上述代碼的關鍵所在。是的， 你沒有看錯，此組件的就是利用.net core提供的HostedService在後台執行被轉移的作業的。
我們再來一起看看TransferJobHostedService的代碼：

public class TransferJobHostedService:BackgroundService
{
    private IBackgroundRunService _runService;
    public TransferJobHostedService(IBackgroundRunService runService)
    {
        _runService = runService;
    }
    protected override async Task ExecuteAsync(CancellationToken stoppingToken)
    {
        while (!stoppingToken.IsCancellationRequested)
        {
            await _runService.Execute(stoppingToken);
        }
    }
}

這個類的代碼也很簡單，重寫了BackgroundService類的ExecuteAsync，循環調用IBackgroundRunService實例的Execute方法。所以，最最關鍵的代碼是IBackgroundRunService的實現類中。
詳細代碼如下：

public class BackgroundRunService : IBackgroundRunService
{
    private readonly SemaphoreSlim _slim;
    private readonly ConcurrentQueue<LambdaExpression> queue;
    private ILogger<BackgroundRunService> _logger;
    private readonly IServiceProvider _serviceProvider;
    public BackgroundRunService(ILogger<BackgroundRunService> logger, IServiceProvider serviceProvider)
    {
        _slim = new SemaphoreSlim(1);
        _logger = logger;
        _serviceProvider = serviceProvider;
        queue = new ConcurrentQueue<LambdaExpression>();
    }
    public async Task Execute(CancellationToken cancellationToken)
    {
        try
        {
            await _slim.WaitAsync(cancellationToken);
            if (queue.TryDequeue(out var job))
            {
                using (var scope = _serviceProvider.GetRequiredService<IServiceScopeFactory>().CreateScope())
                {
                    var action = job.Compile();
                    var isTask = action.Method.ReturnType == typeof(Task);
                    var parameters = job.Parameters;
                    var pars = new List<object>();
                    if (parameters.Any())
                    {
                        var type = parameters[0].Type;
                        var param = scope.ServiceProvider.GetRequiredService(type);
                        pars.Add(param);
                    }
                    if (isTask)
                    {
                        await (Task)action.DynamicInvoke(pars.ToArray());
                    }
                    else
                    {
                        action.DynamicInvoke(pars.ToArray());
                    }
                }
            }
        }
        catch (Exception e)
        {
            _logger.LogError(e.ToString());
        }
    }
    public void Transfer<T>(Expression<Func<T, Task>> expression)
    {
        queue.Enqueue(expression);
        _slim.Release();
    }
    public void Transfer(Expression<Action> expression)
    {
        queue.Enqueue(expression);
        _slim.Release();
    }
}

納尼？嫌代碼多看不懂？那咱們一起來剖析下吧。
首先，此類有三個較重要的私有變量，對應的類型分別是SemaphoreSlim， ConcurrentQueue ，IServiceProvider。
其中SemaphoreSlim是為了控制後台作業執行的順序的，在構造函數中初始化了此對象的信號量為1，表示在後台服務的ExecuteAsync方法的循環中每次只能有一個作業執行。
ConcurrentQueue 的對象是用來存儲被轉移到後台服務執行的作業的邏輯，所以使用LambdaExpression作為隊列的類型。
IServiceProvider是為了解決依賴注入的生命周期的。

然後在Execute方法中，第一行代碼如下：

await _slim.WaitAsync(cancellationToken);

作用是等待一個信號量，當沒有可用的信號量時，會阻塞線程的執行，這樣在後台服務的ExecuteAsync方法的死循環就不會一直執行下去，只有獲取到信號量才會繼續執行。
當獲取到信號量后，則說明有新的作業等待執行，所以此時則需要從隊列中讀出要執行的LambdaExpression表達式，創建一個新的Scope后，編譯此表達式樹，判斷返回類型，獲取泛型的具體類型，最後獲取到泛型對應的實例，執行對應的方法。

另外，Transfer方法就是暴露給調用者的方法，用於將表達式樹寫到隊列中，同時釋放信號量。

到此為止，Weshare.TransferJob的實現原理已分析完畢，由於此組件的原理只是將任務轉移到後台進行執行，所以並不是適合對事務有要求的場景。正如本文開頭所假設的場景，TransferJob最適合的場景還是那些和主操作關聯性較低的、失敗或成功並不會影響業務的正常運行。
同時，此組件的定位就是小而美，像延遲執行、定時執行的功能在最初的規劃中其實是有的，後來發現這些功能quartz已經有了，所以沒必要重複造這樣的輪子。
後期會根據使用場景，嘗試加入異常重試機制，以及異常通知回調機制。

最後，不知道有沒有較真的看官想計算下代碼量是否超過120行。
為了證明我不是標題黨，現將此組件進行開源，地址是：
https://github.com/fuluteam/WeShare.TransferJob

橋豆麻袋，筆者辛苦敲的代碼，難道各位看官想白嫖嗎? 點個贊再走唄。點完贊還有力氣的話，如果git上能點個star的話，那也是最好不過的。小生這廂先行謝過。

本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理

【其他文章推薦】

※教你寫出一流的銷售文案?

※廣告預算用在刀口上，台北網頁設計公司幫您達到更多曝光效益

※回頭車貨運收費標準

※別再煩惱如何寫文案,掌握八大原則!

※超省錢租車方案

※產品缺大量曝光嗎?你需要的是一流包裝設計!