在集群部署的情況下，應用程序需要做出調整，主要集中在四個方面：對httpsession的處理、對緩存的處理、共享的文件系統、synchronized關鍵字的失效。

對httpsession的處理

對httpsession的處理最為重要，因為對WEB程序而言，httpsession無疑是最重要的全局資源，它需要被多個web服務器所共享。

無共享的集群架構（SNA），在這樣的集群中，每個節點具備完全相同的功能，并且不需要知道其他節點存在與否。每個節點JVM進程不保持全局狀態，才能夠保證n個JVM節點的冪等性，那些所有涉及到全局狀態的，必須放在JVM進程之外，例如用戶ID可以使用cookie，session可以放入數據庫（這并不是一個好的選擇），文件可以放在共享存儲系統中。

也就是說httpsession的信息需要被保存在JVM進程之外，例如分布式緩存、數據庫。

這里是方案：

1、使用會話cookie保存web服務器產生的sessionid
   為什么是sessionid而不是userid，原因在于誰也不知道除去登錄外其他人會在httpsession里干些什么

2、自定義SessionMap<String,Serializable>同步保存httpsession內的信息
   自定義SessionMap同步httpsession，在操作httpsession時不用改變調用接口，不用東張西望

3、使用分布式緩存memcached保存自定義SessionMap<String,Serializable>

4、會話膠粘
   未失敗轉發的情況下沒必要在memcached和httpsession之間復制來復制去，眉來眼去

5、使用SnaFilter處理失敗轉發

6、使用HttpSessionListener實現SessionMap<String,Serializable>的過期
   利用容器session 機制的好處,httpsession過期的時候干掉memecached里的SessionMap

下面根據web請求的過程分情況討論該方案：

A、登錄

根據請求的url判斷是否是登錄請求

在線人數保存在memcached里

B、 正常請求

C、 失敗轉發

D、登出

根據請求的url判斷是否是登出請求

E、HttpSession過期

不hack memcached，使用HttpSessionListener，sessionDestroyed事件時根據sessionid刪除memcached里的sessionMap（如果存在）

關于在線人數的統計：在線人數存儲在memcached里，將在線人數與sessionMap綁定，往memcached里增加sessionMap時在線人數+1，刪除時-1.

項目情況：是一個大型公司的內部辦公系統，該系統有兩個和一般企業應用不太一樣的特點：一是用戶量非常多，人員數達到2W左右，另一個是采用分級管理的形式，各個分公司數據分開管理。

我們的定位：我們是作為業務平臺的提供商參與這個項目的，我們提供底層的開發平臺，系統集成商在此基礎上進行二次開發。

在項目從開發到部署的過程中遇到了很多的問題，也反映出很多問題。

一、怎么回事，跑得比貓還慢
項目開發完畢后部署在Ibm aix 小型機上，32G內存，16個cpu。應用服務器采用的是weblogic9.2，數據庫是oracle10.0.2。上線后發現系統運行的非常緩慢，甚 至比開發環境下的tomcat還要慢。于是開始排查原因，最開始是對SQL進行監控，優先考慮是數據庫訪問性能產生瓶頸。通過監控，發現很多業務需要執行 大量的SQL語句，查看客戶編寫的相關代碼，發現在查詢數據時循環執行了大量SQL。主要原因在于他們在代碼中循環調用了我們相關API，一個最典型的例 子是通過用戶ID查找用戶NAME，他們在業務表格里沒有保存用戶name，而是在查詢的時候通過用戶ID查找用戶name填充到頁面，幾乎每一個查詢都 是n+1。
 
另外由于平臺使用了hibernate，使得oo編程得非常爽快，導致開發人員完全忽略了相應的數據庫操作所帶來的壓力。很多業務邏輯直接通過PO疊加完成，把一些可以通過很少SQL完成的邏輯全部分散放置到PO里，導致了大量PO的交互和SQL語句。

開始優化SQL，優化的同時增加大量業務緩存。但優化完畢后運行緩慢的現象依舊存在，性能有了一定的提升但是不是非常明顯。繼續優化，其中考慮過 多頻繁訪問的數據使用內存數據庫的方式。但是優化過后在tomcat上效果明顯，部署到生產環境就問題依舊。于是考慮weblogic的配置問題，作為開 發平臺提供商，我們只是提供系統開發相關方面的支持，對于應用服務器和數據庫服務器只是做基本的配置系統可運行即可。但是在這個問題上系統集成商咬定是我 們平臺的問題不放，并且存在一個很嚴重的問題：他們使用的是盜版的weblogic，這樣根本就沒有相應的技術支持。

問題的解決：最后是找了一個BEA曾經的開發人員，問題實際非常的簡單，現場部署的weblogic默認是運行在32位機器上，與64位機器存 在一定的不兼容。通過替換相應的jar包，問題得到了解決，主要是IO方面。替換完畢后，速度提升了進30% 。該開發人員說，如果沒有lisence，根本就不會得到這些替換的jar包。

二、內存耗盡了
訪問速度的問題解決了，系統的使用量很快上來，馬上遇到新的問題：內存耗盡了。嚴重到幾乎每天都要out of memory一次。這種問題在客戶現場頻繁出現。

本地測試，tomcat，sun jdk 通過Jprofiler監測內存使用情況。在并發訪問門戶的情況下，內存確實存在暴漲的情況，100并發，內存使用立刻上升了150m左右，繼續并發 100，再增長150m。但是很快在抵達高峰時會有一次gc發生，內存使用穩定在200m，內存里大量char[]數組對象。疲勞測試，內存使用曲線并沒 有出現逐漸上升泄露的情況。換weblogic和jrocket測試，gc發生的更加頻繁，內存使用穩定。
 
但是現場依舊頻繁當機，內存根本釋放不了，一直逐漸增長，典型的內存泄露。對系統緩存、單態對象包括spring管理的對象、IO流進行了統一 排查，依舊沒有找到內存泄露的原因。使用IBM 工具分析heapdump文件，結果還是大量的char[]數組對象占據內存，查找應用，找不到相關業務對象引用。
 
問題解決：問題解決是一篇偶爾搜到的oracle論壇的帖子，這里http://forums.oracle.com/forums/message.jspa?messageID=1040570 。原因在于oracle10的數據庫驅動對statement最后執行的結果集有著引用，并且不會釋放，目的在于通過內存而換取更好的性能。數據庫連接采 用的是weblogic的連接池，關于connection有個相關的statement cache設定，設定一個connection能夠被緩存的statement個數，最大是1024，而現場就被設定為了1024！connection pool的connection個數被設置為了500 。真是個恐怖的設置。在將1024改為10后，內存使用量轟然倒地，穩定在1g左右。這個設置是在前面系統訪問速度存在問題時由系統集成商的開發人員設置 上去的，他們將所有和優化相關的參數全部開到了最大。這個問題要是用戶購買的是正版的weblogic和oracle的話，相信也會很快得到解決。

三、線程阻塞
內存泄露的問題解決后，線程阻塞的問題浮出水面。系統集成商報告是線程死鎖，通過分析工具其實是線程阻塞，主要問題在于系統用到了 synchronized關鍵字，對工作流相關API全部使用了synchronized，原因在這里：http: //ronghao.javaeye.com/blog/205731 。分析發現一個工作項提交的操作在連接數據庫時被掛起了20分鐘！造成了大量線程的排隊阻塞。被掛起的原因有很多種。我們采用的方法是將接口拆分和設置事 務timeout時間。但是這顯然不是一個好方法。最后是去掉所有的synchronized關鍵字，將同步的問題交由數據庫解決，問題解決。

四、反思
1、系統集成商為什么不購買正版？
2、開發平臺提供商究竟在項目開發中處于一種什么樣的位置？開發平臺是否對所有軟件開發問題都要負責？
3、開發平臺是越封裝越快樂嗎？還是越封裝越丑陋？

更具體的細節在這里：

 AIX+weblogic性能診斷記錄

從事工作流以及相關開發已經三年。提到工作流，很多人都會想到BPM，想到業務流程。對于業務流程，我的理解經過了一個過程，從最開始對工作流抱有的不切實際的期望，到對BPM的一些看法，再到目前的趨于實際。有一些感觸，也有一些理解。對于業務流程管理而言，我想說的是：BPM向左，工作流向右，都不靠譜，或者說它們實際所能描述的流程和這里的業務流程根本就風牛馬不相及，不是一個概念，唯一的相同點是只不過都叫流程而已。

一、什么是業務流程

業務流程是一個技術術語，它具有準確的定義：有組織的活動，相互聯系，為客戶創造價值。

這句話很好理解。甚至可以說任何企業的活動都是以業務為主線，以流程為線索串聯起來的。企業的規章制度、操作手冊等都與業務流程有著契合點。

二、業務流程對于企業的意義

業務流程對于企業的意義不僅僅在于對企業關鍵業務的一種描述，更在于對企業的業務運營有著指導意義，這種意義體現在對資源的優化、對企業組織機構的優化以及對管理制度的一系列改變。這種優化的目的實際也是企業所追求的目標：降低企業的運營成本，提高對市場需求的響應速度，爭取企業利潤的最大化。

三、業務流程也是一個體系

業務流程通常的表現形式是流程圖（不是唯一形式），畢竟圖形是最易于理解的一種形式，但似乎我們太關注于流程圖本身而忽略了其他。除了流程圖之外，業務流程還應該包括目標和指導方針，這才是一個完整的業務流程。在梳理業務使用業務流程描述時首先要想到的是該流程所要達到的目標，能為客戶創造什么價值，脫離開業務目標或者說純粹為描述業務而描述業務是沒有意義的。同時在制定業務流程時也要考慮到該業務流程的指導方針，同一個業務可能有很多種業務流程的描述形式，具體哪一種是最合適的，這里就必須有一個指導方針來進行約束。

四、業務流程的特征

1、層次性、逐層抽象

業務流程是有層次性的，這種層次體現在由上至下、由整體到部分、由宏觀到微觀、由抽象到具體的邏輯關系。

這樣一個層次關系符合人們的思維習慣，有利于企業業務模型的建立。一般來說，我們可以先建立主要業務流程的總體運行過程（其中包括了整個企業的大的戰略），然后對其中的每項活動進行細化，落實到各個部門的業務過程，建立相對獨立的子業務流程以及為其服務的輔助業務流程。

業務流程之間的層次關系一定程度上也反映了企業部門之間的層次關系。不同層級的部門有著對業務流程不同的分級管理權限。決策層、管理者、使用者可以清晰的查看到下屬和下屬部門的業務流程。

為使得所建立的業務流程能夠更順暢的運行，業務流程的改進與企業組織結構的優化是一個相互制約、相互促進的過程。

2、以人為本

組織中最重要的部分是人員的工作方式以及構成他們每日操作的工作流程。

人是業務流程的驅動者，組織中的每一個人都會在業務流程中充當一個角色。通過良好的業務流程，每一個人都會有自己清晰的職責，要求具有良好的溝通協作意識和團隊意識，明確自己在一個個業務流程中所擔當的角色。

同時對于參與其中的業務流程，每個人員都要有自己的反饋。

首先，每個人員都能查看到這些業務流程，他們需要充分理解這些業務流程、流程的業務意義和目的，這些業務流程通過切合他們理解能力的方式（切合業務的圖形、說明文字、相應的制度、規范、標準等等）得以展現。

其次，對于流程運行中存在的問題或瓶頸，每個人員都要積極反饋（提出修改的建議，或者在權限范圍內直接修改）以促進流程的持續改進，業務流程的管理和變動不僅僅是業務分析人員或管理人員的職責，每一個員工都要參與其中，否則只有失敗。管理人員和決策層更重要的職責是制定出業務流程的規則和約束，在這個規則和約束范圍內，員工可以根據變化的商業環境對業務流程做出迅速修改，這樣不必等到領導了解情況后再做出決策從而失去機會。

3、對流程運行效益的分析

從企業投資者的角度來講，好的業務流程設計必然是能夠為企業帶來最高利潤的設計。因此，對業務流程的效益分析是評價業務流程的一個重要方面。財務數據是最關鍵的數據，但這種分析不一定完全是由數據支撐的，有些是不能量化的，比如人員效率等等。

五、業務流程管理

良好的業務流程管理是保證企業靈活運營的關鍵（業務流程管理又何嘗不是一種業務流程？）。

1、業務分析

實際這也是業務流程管理最重要的部分。它需要對企業業務有著強大的分析能力，因為業務分析對企業的運營有著重大的指導意義，只有具備了這樣的業務分析能力，才能把握住企業運轉的真實流程，而且這種分析能力往往帶有對整個行業的深刻理解和前瞻性。沒有異議，業務分析在于人，與IT無關。

2、業務流程的持續改進

不僅僅是流程管理人員（管理決策層）根據運行效益的分析和商業環境的分析對流程進行重整。還包括每個員工對其參與的流程的持續反饋和持續改進。柔性的業務流程。

3、IT系統與業務流程的關系

IT系統與業務流程并沒有直接的關系。正如06z在SOA帖子里表達的：soa95%以上的工作是在做業務流程的分析解構和重整，技術層面的支持只占5%不到。在落實到技術層面，你覺得一個soa產品究竟應該包括些什么內容呢？這些內容又能有多少是能夠輔助大家對業務流程進行分析和測試，對業務元素進行重整和再分配？如果你們真的有這個能力，你們覺得是在這里繼續開發軟件過苦日子，還是去開拓商業咨詢呢？我的觀點是：SOA很美好，但是一落地就變成了小丑。所謂的業務流程管理軟件同理。

可以這樣理解：業務流程管理是一個很大的命題，IT系統通過信息化對它的子集進行支撐，這里的IT系統包括的范圍很廣泛，包括了所有的企業應用軟件（所有的企業應用軟件都可以看作是對企業某部分的業務流程進行的描述）。業務流程管理的核心在于業務流程的分析解構和重整，這點是所有軟件都不可企及的，關鍵在于人。至于BPM還是工作流，它們本來就有它們自己的適用范圍，硬要把它提升到業務流程管理的高度來宣傳，那就真的和小丑一樣，滑稽而可笑。

關注下篇：BPM是干什么的

用js編寫自己的組件，測試一直是個頭疼的問題。最開始大量使用alert，firebug出現后天突然藍了。但人的欲望總是沒有止境的，在面對越來越多的后臺數據交互以及特定于不同業務數據不同的展現形式時，仿佛一夜回到解放前。

說說我現在的困境：

目前要做的是工作流的提交頁面，也就是對當前辦理工作的用戶展現后續任務，根據不同的情況由用戶選擇或是引擎自動計算。這是最簡單的情況，后續包括參與者的選擇計算、時間服務設定以及Comment等等。
現在根據業務邏輯分為了四種情況：
1、串行
2、分支選擇
3、M選N選擇
4、復雜的分支組合
四種情況需要準備不同的業務測試數據，同時頁面展現也是不同的。我采用的方式如下圖：


針對每種情況都建立相應的測試文件夾，在各自文件夾下準備各自的業務測試數據以及測試頁面。并且一個testcase往往需要很多的業務測試數據（和通用組件還是不太一樣）。清晰還是清晰，但是問題在于這種測試還是人肉，做不到自動化測試，同時為了業務數據能夠順利插入不得不hack一些代碼。當增加或改動部分代碼后就要人肉返測一次，預計代碼還會大量膨脹，相應的測試文件還會增加。真是苦海無邊，無心睡眠。想想cc和junit真是幸福的像花一樣。

我佛慈悲，不知道大家有什么好的方法沒有？

收回

收回是工作流參與者對自己“已辦任務”（對已完成的工作項）的一種操作，即參與者主動對已辦理過的工作項進行重新辦理。

為什么要收回？

參與者完成任務后，發現自己辦理有錯誤等情況后，需要將此任務收回重新辦理。

工作項的參與方式

目前有四種方式：共同參與、競爭參與、順序參與、基于角色的共同參與。

下面會針對這四種方式進行討論。

工作項收回模式

1、未觸發下一節點的工作項的收回

即當前任務節點并未完成，依舊處于執行狀態

1.1共同參與

如圖：在節點A未結束之前，workitem1、workitem2和workitem3正常完成后可以任意收回。在只產生一個workitem的情況下，不存在未觸發下一節點的收回情況。

1.2順序參與

如圖：workitem1、workitem2和workitem3順序完成，workitem1在workitem2簽收（包括掛起和手工終止）前可以收回，同樣，workitem2在workitem3簽收（包括掛起和手工終止）前也可以收回。在只產生一個workitem的情況下，不存在未觸發下一節點的收回情況。

1.3競爭參與

因為只會產生一個workitem，該workitem完成后會立刻觸發下一節點，所以不存在未觸發下一節點的收回情況。

1.4基于角色的共同參與

與1.1相同。

2、已觸發下一節點的工作項的收回

 

2.1共同參與

問題1：多個工作項時誰可以執行收回操作？

workitem1、workitem2和workitem3都可以執行收回操作。第一個工作項的收回將會導致節點B實例的刪除，同時節點A重新恢復執行狀態。

問題2：節點B處于什么狀態節點A的工作項可以執行收回操作？

由A觸發的節點B處于正在執行的狀態，節點B所產生的工作項：

a共同參與   工作項均未簽收、掛起或手工終止

b順序參與    第一個工作項未簽收、掛起或手工終止

c 競爭參與   工作項均未簽收、掛起或手工終止

d角色        同共同參與

問題3：工作項收回產生的影響？

節點A重新執行，收回的工作項重新執行。節點B重新恢復未觸發狀態，B所產生的工作項全部刪除。

2.2順序參與

問題1：多個工作項時誰可以執行收回操作？

workitem1、workitem2和workitem3根據順序可以依次執行收回操作。

2.3競爭參與

情況簡單，只有一個工作項，所以可以直接收回。

2.4基于角色的共同參與

同2.1

工作流收回模式

后續觸發節點只能是人工節點（可以是多個，至少一個），否則不支持收回。目前不支持父子流程之間的收回。

一個典型的同步匯聚情況：

節點1首先執行完畢，但是因為是同步匯聚，所以它不會觸發實際的流轉；而節點2的完成則會觸發節點3的執行。在這種情況下，節點2的工作項可以執行收回操作，而節點1的工作項因為后續沒有觸發節點而不能收回。