某b專案是我首次採用was環境下架構和開發的手機wap應用，儘管做到了該項目的主程，但對此專案的全面構件依然有不清楚的地方，因此在這裡我只能簡單的談談開發中遇到的問題怎麼處理和應對辦法。
記得第一天接觸這個專案時，只記得些案例**（不知道那些是對的，那些是錯的）似曾相識，但不懂如何動手寫下第乙個helloword，因其中的基於介面開發的ejb的架構以前根本就沒接觸過。好了，沒辦法，於是只有硬著頭皮去嘗試第乙個基於介面開發的ejb的第乙個查詢方法（呵呵最簡單了吧）。因為一切都是新的，一沒有相對完整的資料可參考，二在無廣域網查資料，三沒人可問（人也是新的）。我心裡想，如果不能正常對接前端和所呼叫的各個介面方和協同各個部門，任務因我而耽擱，那豈不是藐視我的自尊心嗎？嗯，於是拿著些零碎的資料，一步一步的寫（含猜想），一步一步的測試，這樣的痛苦過程終於在第二天下午能交出第乙個實現查詢方法了；等等，這才是開始，並不能代表你寫出的東西真的實用。接下來，問題是乙個接乙個，第一是這個系統採用什麼架構？各種架構優劣......要搞架構啊，好傢伙，首先得弄清楚業務流程吧，第二得弄清楚技術流程吧，比如：was環境，ihs+was搭建吧，was包部署和發布吧，基於http和socket方式怎麼呼叫介面吧，弄清楚基於db2環境下的jdbc 方法吧，各種介面配置和集群對應的介面配置吧，還要弄清楚aixos相關的shell吧，還要弄清專案公升級會出現的各種調式和配置問題吧，還得弄清楚測試環境和生產環境的各種差異吧.....完了，一時間這些玩意都來了，你還不知道未來會遇到什麼不可**的情況，比如流程安全改造，漏洞安全改造.....你更不知道如何確定介面方有沒有問題......面對這些棘手的問題；這可不是玩的，那怎麼辦呢？當時，我沿用自己架構專案寫專案的一貫思維：第一這些問題儘管都是新的，但是他並沒有離開乙個程式設計師正常的邏輯，因此他並不是那麼苦難，只要把控每一步每乙個微小的問題，一步一步實現即可完全把控；第二，他就是乙個業務相對簡單的應用而已（比起之前的做的那些大型專案並不複雜）。好了，基於這2點自信上，這一深入下來就是近2個月的痛苦嘗試，2個月後終於功夫不負有心人，第一業務流程和技術流程的各個關聯微小的地方完全把握，第二與各個部門協同的非常順利。也就是通過了這段時間，完勝的把控了was集群下基於介面分布式架構和開發中的各種問題。
因這個專案，使我產生對舊技術線路動搖和新技術線路實施的靈感。
這是我做這個專案最大的成就之一。
分布式集群架構
策略優點 缺點格式 uuid 實現簡單不占用頻寬 無序 不可讀 查詢慢 32位db自增 無 遞迴 db單點故障 擴充套件有瓶頸 snowflake 不占用頻寬 低位趨勢遞增 依賴伺服器時間 18位redis 無單點故障 效能優於db遞增 占用頻寬 redis集群需要維護 12位關係型資料庫都實現資料...
基於zookeeper集群下的分布式佇列
在傳統的單程序程式設計中，我們使用佇列來儲存一些資料結構，用來在多執行緒之間共享或傳遞資料。分布式環境下，我們同樣需要乙個類似單程序佇列的元件，用來實現跨程序 跨主機 跨網路的資料共享和資料傳遞，這就是我們的分布式佇列。zookeeper可以通過順序節點實現分布式佇列。圖中左側代表zookeeper...
RabbitMQ分布式集群架構
設計集群的目的 1 集群配置方式 rabbitmq可以通過三種方法來部署分布式集群系統，分別是 cluster,federation,shovel federation 應用於廣域網，允許單台伺服器上的交換機或佇列接收發布到另一台伺服器上交換機或佇列的訊息，可以是單獨機器或集群。federation...