**：
一、中介軟體技術在系統設計規劃方面的經驗總結
1.1、中介軟體應用架構的選擇
這種架構選擇的焦點就是業務邏輯到底是放在前台應用中還是放在後台中介軟體應用中。其實，引入中介軟體平台的原因之一就是業務邏輯的集中管理，出現這種爭論的原因主要是開發商對這種業務邏輯集中的理解不深，在應用設計的過程中仍然沒有擺脫以前兩層結構的影響，再加上因為業務邏輯集中會增加程式開發量，才出現了這種情況。我們認為，把業務邏輯集中在中介軟體伺服器上不僅對於業務邏輯的集中管理有好處，而且對於系統的後期執行維護、軟體的公升級管理都有著明顯的優勢。當然,在開發的工作量方面，業務邏輯集中時工作量大很多。
二、中介軟體技術在系統維護方面的經驗總結在中介軟體的日常維護中，我們了解了一些tuxedo的基本知識，摸索了一套行之有效的故障排除方法，積累了一些常見故障的排除經驗，現在與大家介紹如下：
2.1、license數的問題tuxedo的license由文字檔案lic.txt來控制，位於udataobj目錄下，分為sdk/rtk兩種，兩種license不能合併使用。它控制的是併發使用者數並且有10%的冗餘，這裡的併發使用者數是指在某一時刻前台程式已經發起tpinit還沒有作tpterm的連線數，所以在tuxedo中介軟體的使用中存在著長連線和短連線的問題。長連線是指tpinit後就開始一系列的服務呼叫，只在系統重啟或系統非常空閒的時候才做tpterm，而短連線是指每次服務呼叫前作tpinit，呼叫結束後立即作tpterm呼叫。因為短連線下的服務呼叫需要額外的連線時間消耗，這對系統響應時間會有影響，而長連線又會占用系統的併發使用者數。所以在系統設計時需要針對不同的應用情況做出不同的設計，比如針對介面型別的應用因為服務呼叫比較頻繁，進行連線的時間就會佔比較大的比重，這時就需要使用長連線，而對於前台應用型別的應用，連線過程的時間對於業務操作的時間來說是可以忽略的，這時就要用短連線來節約license資源。
2.2、客戶端連線的問題當客戶端無法連線中介軟體時，我們需要確認的是
1、 客戶端的wsnaddr是否設定或是否設定正確。
2、 系統配置檔案中的maxwsclients和maxaccess是否正確設定。
3、 wsl是否啟動，wsh的個數是否足夠。
4、 是否有防火牆，如果有防火牆存在，則需要在wsl的配置中作相應的位址對映和埠指定。
5、 作業系統是否有足夠的scoket資源使用。
解決了這些問題後，一般就可以解決客戶端連線不上的問題了。
在tuxedo中，引數tmtrace對故障的定位和排除很有作用，它是乙個環境境變數。我們一般在系統監控的工作終端上將此引數設定為on，在前台報系統故障的時候，我們直接進入故障模組將故障重現，然後在終端機器的c:\或者tuxedo的安裝目錄下開啟乙個ulog檔案，在此檔案中會發現tpcall服務的失敗資訊，根據這個資訊查詢對應的server和service的對應表，很快就可以找到問題服務。採用這種方式，維護人員不需要了解程式的具體流程就可以定位錯誤解決故障。
在tuxedo的服務端，有幾類檔案需要關注，這些檔案包括ulog檔案、xa介面的trc檔案、資料庫連線故障的sqlnet.log、標準輸出檔案stdout（也可以被應用程式自己定義）。在這些檔案中包含著豐富的系統執行錯誤告警資訊。ulog記載關於中介軟體的啟停記錄和系統本身的一些配置執行告警資訊。xa的trc檔案記錄的是xa介面方面的一些的錯誤資訊，關於分布式事務的一些錯誤在這個檔案中都有記錄。sqlnet.log記錄了應用程式和資料庫連線故障的資訊，只要有當前日期時間的這個檔案存在，應用和資料庫的連線就會存在問題。標準輸出檔案stdout記錄了應用程式本身的執行資訊。這些檔案的跟蹤檢查對於及時主動的發現故障有著重要的意義。
2.3、事務控制的問題1、事務邊界的問題：在這裡我們要遵循誰發起發起事務，誰就結束的原則，這裡的誰主要是指中介軟體的前台和後台。我們知道在tuxedo中事務的發起既可以在前台程式中發起，也可以在後台程式中發起。無論放在前台還是放在後台都有其優缺點。事務放在前台增加了網路傳輸的流量，當時可以保證異常情況下前後臺操作的一致性，事務放在後台可以減少網路流量，但是對於異常情況下前後臺操作的一致性很難保證。我們採用的是事務放在前台程式中。但是無論放在前台還是後台，都要遵循誰發起，誰結束的原則。
2、xa介面使用的注意事項：首先是xa資源檔案的配置，在oracle資料庫中一般用到的是libclntsh.a，我們可以先make sample，提取其中用到的連線庫加入到rm檔案中即可。其次在oracle8i之前要對xa進行授權，要在oracle的dba使用者下執行grant select on dba_pending_transactions to public。
3、事務掛起的問題：在使用xa的情況下，我們經常會遇到這種情況，server程序還在，可就是不做事。在相關的日誌檔案中總是報「當前的程序已經在乙個本地事務中了」的錯誤，這時只有重啟該server，才能排除故障。其實這是乙個事務控制的問題，它產生的根本原因是在開啟全域性事務前，該server執行了乙個本地的事務並且沒有提交或回滾。在程式**上表現為如下三種原因：
（1）、在呼叫該server的某個帶dml語句的service前沒有加tpbegin。
（2）、在呼叫tpbegin後沒有判斷返回值。
（3）、tpbegin後的tpcall服務呼叫沒有判斷返回值，在全域性事務超時後沒有能夠及時的退出後續的呼叫，導致下乙個tpcall產生了乙個本地事務。
此外，還會有一模擬較特殊的問題，那就是tms服務掛起的問題，利用tmadmin中的pq命令發現tms的佇列中有很多請求存在，在這種情況下，一般只能等待其執行完成，情況嚴重時，則需要調整相應的資料庫引數，在oracle中該引數應該設為max_commit_propagation_delay>=90000。
在實際的執行維護中，我們發現即使把資料庫引數調整了，有時還會有tms掛起的故障發生。針對這件事情我們專門作了研究，tms之所以掛起是因為tms在等待資料庫中dx獨佔鎖的釋放，這種獨佔鎖加鎖的物件一般都是oracle的系統物件，而這種獨佔鎖的產生一般是在全域性事務中執行著dml語句，當這種dml語句執行比較慢時，就會引起tms的鎖等待現象。此外，我們還發現，一般的查詢語句是不會產生鎖的（ops的lm_lock鎖除外），但是如果將查詢放入乙個全域性事務中時，它就會產生乙個共享的dx鎖，如果這個在全域性事務中的查詢的呼叫是通過oracle的工具包dbms_sql來進行的話，那就會產生乙個dx的排他鎖。基於這些結果，我們建議在程式的開發過程中要遵循能不用xa全域性事務的情況下就不用，能將查詢放到事務之外的就不要放到事務之內，能不用oracle工具包進行開發的就不要用。我們也按照這個原則要求我們的開發商，取得了比較好的效果。
4、事務超時設定的問題
中介軟體應用系統的事務超時控制很重要，不設定超時時間對系統來說簡直就是一種災難。我們曾經就有過因為超時時間的設定沒設和設定不當造成了嚴重的系統故障，最直接的故障就是系統報全域性事務數不夠的錯誤，無法開啟新的事務，從而導致前台業務的終止。tuxedo的超時主要有三種，乙個是在**中的tpbegin超時（值為其引數）t1，他控制整個事務的完成時間，第二個為xa連線的超時（配置檔案中的open_info中的sestm ）t2，他控制同一連線中對於分布式事務鎖的等待超時時間，還有乙個為資料庫中等待資料庫物件非分布式事務鎖釋放的超時時間（_dirstributed_lock_timeout）t3。這三個超時共同作用並且有如下的關係 t1
2.4、服務不能正常啟動的問題在實際的維護工作中，經常會出現服務不能正常啟動的現象。明明所有的服務都已經關閉了，tmboot就是起不來。這種原因一般是因為系統的ipc資源沒有釋放。ipc資源是作業系統用來進行程序間通訊的系統資源，主要包括訊號燈、共享記憶體、訊息佇列。在unix作業系統下通過ipcs命令可以清楚的看到ipc資源的使用情況。當服務無法啟動的時觀察ipcs就會發現tuxedo執行環境的使用者下的ipc資源沒有被釋放，這時使用ipcrm命令清除相應的ipc資源，再啟動服務就可以了。
express中的中介軟體
一 中介軟體結構 path 是路由的url，預設引數 意義是路由到這個路徑時使用這個中介軟體 function 中介軟體函式 這個中介軟體函式可以理解為就是function request,response,next 這裡安裝是指涉及到第三方中介軟體的使用時，需要先安裝好，然後在使用。二 中介軟體分...
訊息中介軟體應用場景
訊息佇列中介軟體是分布式系統中重要的元件，主要實現非同步訊息，應用解耦，流量削峰及訊息通訊等功能。下面舉例說明在實際應用中訊息佇列是如何使用的。以使用者註冊，並且需要註冊郵件和簡訊為例。使用者註冊後，需要傳送註冊郵件和註冊簡訊。傳統的做法有兩種 序列和並行方式。如下圖所示 1 序列方式 將註冊資訊寫...
13 2 7 中介軟體
中介軟體顧名思義，是介於request與response處理之間的一道處理過程，相對比較輕量級，並且在全域性上改變django的輸入與輸出。因為改變的是全域性，所以需要謹慎實用，用不好會影響到效能。如果你想修改請求，例如被傳送到view中的httprequest物件。或者你想修改view返回的htt...