1 項目背景

所在業務在早期沒有營銷費用，買家購買商品的折扣優惠是由賣家提供的。全部訂單的終於價格是由賣家和業務方確定的，整個購買流程非常easy。

如今此業務收受到公司重視，業務團隊能申請到營銷費用。業務團隊能主動補貼折扣優惠。一件東西進行促銷時，用戶購買此物品後。由業務方出錢補貼折扣的費用。而賣家不須要考慮優惠折扣。實現這樣的營銷需求須要和第三方的團隊合作。比如商家營銷團隊、賬務團隊。

2 項目管理

團隊協作

項目開始的時候。我方向這2個團體介紹業務背景，提產品需求，開頭非常順利：業務邊界範圍的界定、接口交付時間、聯調測試時間、系統上線時間。

1周之後獲知：賬務團隊又一次安排了開發負責人。然後和這個開發同事溝通之後，才發現之前討論的需求他全然不了解，然後又一次開始討論產品需求和實現方案，結果之前定的時間點所有廢棄。由於負責的同事說實現的方案非常復雜，第一次無語了。。。

然後我發開始消減產品復雜度。。。又一次定時間評審需求、確定每一個進度的時間點。

總結：核心業務假設依賴第三方的團隊。在項目初期應該盡量他們溝通，確認項目初期是否有已經開展、是否有不清楚的細節。盡管在項目開始的時候又一次安排開發負責人的情況非常少。但確實存在。並且又一次評估復雜度之後。發現對deadline影響非常大。

對於這樣的問題除了項目初期盡量暴露出來之外，發生的時候，要和產品需求方又一次確定需求中是否有些模塊可以折中成簡單的規則，比如：每一個商家的每一個訂單的轉賬補貼由實時結算的方式改為 每一個商家補貼日結+提供日結明細流水的方式。由於這樣的方法可以繼續復用賬務系統現有的日結邏輯，不須要匯款系統新開發實時結算模塊。

基於這個教訓，我們之後和營銷系統、賬務系統每隔2天都會互相通報進度。分批次提供或者要求提供 API接口。在自己業務系統通過mock方式完畢全部的流程後。分批開發、聯調接口，這樣可以在比統一交互時間點更早的時間進行聯調和自測。兩方系統API接口可以並行的聯調、測試、開發，充分利用時間。

測試環境不穩定：在業務主流程開發聯調完畢之後，賬務系統同事通知說他們的測試環境不穩定，可是我們自以為他們會將這個問題搞定，等了一天之後發現依舊不穩定。就順便問了下他們什麽時候能搞定，結果才知道：和國足踢進世界杯一樣。希望渺茫。⊙﹏⊙b！

！

！之前還想再等等，假設再等下去。那就餐具了。我們果斷去他們的工位上開始溝通測試方案，用一天的時間現場自測、磨合，之後開始業務測試----在聊天工具上溝通測試中的問題，之後測試非常順利。

需求變更

在項目中。PM是不能接受需求有太大的變化----推斷根據是在當前的技術實現的復雜度。而不是依賴於產品功能的描寫敘述。

所以能被接受的需求變更，一般屬於產品功能的簡化需求。

在跨團隊合作中，一個需求簡單的變化，假設沒有同步給合作團隊，非常有可能造成項目的延期。

這樣的變化即使由產品方通知了合作團隊，技術團隊也要再次溝通確認，合作方的技術團隊非常有可能由於這個小小的需求變動將技術實現方案大改，並且不會主動通知。PM要時刻關註這樣的變化，並且保證全部團隊時刻了解最新的產品需求。

這次項目中，暫時決定有個功能在此活動不會被使用（業務方來不及統計數據），可是隨後的活動都會被使用，可是未及時同步到位，結果遭到合作方的吐槽，說是假設這樣，此版本號就能夠不開發這個功能了，延期到下個版本號。

只是最後全部的功能都按時上線，\(^o^)/~。

這樣的問題歸根結底是一定要把溝通放在第一位。

2 系統設計

模塊和耦合

做好業務邊界的劃分，保證新業務功能模塊和當前系統的關聯關系最少，易於從邏輯上或者物理結構上進行切分。獨立的業務模塊僅僅處理一件事件，並且將這個事情處理的非常完美。

並且易於之後應用於其它業務場景，做功能擴展也不會歷史業務包袱。

健壯性

健壯性分為業務實現的健壯性和系統服務的健壯性。

業務實現的健壯性體如今業務的冪等性、事務性、容錯性等方面。

和REST架構風格中POST/PUT類型接口的實現原則一樣，最好每一個接口要有冪等性的特征，query類型的接口天然支持冪等性，可是ADD/UPDATE/DELETE類型的接口須要一些特征參數來實現這些原則。一個完畢的交易業務由多個子流程A、B、C等子流程組成的。

假設C流程失敗了，應該怎樣處理當前交易業務呢？

有2種場景：

1、 假設當前交易是另外一個交易的附屬流程。由於前置條件符合業務場景，則次交易流程是不同意失敗的，那麽事務在這樣的場景是不合適的，僅僅能通過業務狀態來重試，保證終於成功。

2、 另外一種方式也非經常見：假設C失敗，通過事務/分布式事務來將A、B的操作所有回滾，此次業務操作失敗。

假設2種方式都是可選的，第1種方式比較合理，由於可重試的實現方式，不會由於某個流程臨時性錯誤：數據庫連接失敗、線程池任務加入失敗等等，而影響其它業務流程，同一時候這些接口能暴露到管理界面便於之後的人工幹預、系統自己主動的補償操作。

通過業務健壯性來保證給提供使用方的服務的終於狀態肯定是符合預期結果的。

系統服務的健壯性體如今良好的錯誤通知和恢復策略。系統中單個節點宕機或者一段時間內服務不可用或者壓力過大。不應該導致整個服務集群不可用。

所謂的Load Balance、Failover、Failback、Throttle(Sampler) 這些軟硬技術策略可以發揮非常大作用。

自我監控

監控分為業務監控和系統應用環境的監控。

業務系統監控主要關註業務接口的RT/QPS、成功和失敗次數，核心業務的成交量等。

在某個時間段內的假設有數據指標波動較大，有可能是某些業務接口出現故障了；或者一些偶發的錯誤報警也須要關註，這些偶然的也有可能是代碼邏輯的bug或者。系統快達到瓶頸導致的。

系統應用環境的監控就非經常見了系統的Load、CPU、MEM、磁盤IO、網卡流量、JVM等。

管理入口

業務管理界面：之前一直強調系統的冪等性、容錯性。既能夠通過系統自己主動重試來達到終於一致性。也能夠便於暴露接口到管理頁面，由管理人員人工幹預進行補償操作或者數據訂正。本次系統基本上全部的服務接口都暴露到管理上，非常easy做數據訂正和業務重試。

配置項管理界面：高可配置性是一個系統可以非常easy做到服務的高可靠性、易擴展性。

通過改動配置可以停用/啟用不重要的流程，啟用/停用壓力過大的服務。。。這次系統上線開始做活動，由於新版功能上線怕賬務計算錯誤。通過配置暫時停止劃款操作，賬務總額確認通過後，才啟用這個業務配置。

3 總結

每次的項目都會有不如意的地方。在項目流程上的：溝通不順暢、人員變動、需求被強制大改。有些是依賴的第三方系統的細節不透明，首次使用之後，常常會在遇到狀況才發現某些隱藏規則

項目流程管理&&架構總結