Cloud Foundry使用指南1、避免使用本地檔案系統2、HTTP Session的非持久化與不可複制性3、HTTP和HTTPS端口的局限性

正常的應用，大多數可以不經過任何修改即可部署于cloudfoundry雲平台之上，但是在一些特殊情況下，總是不可避免地會出現一些細小的問題，如果在應用設計之初，就考慮到針對雲平台的一些特殊情況，遵守雲平台的規範，就會使應用更适應雲平台環境，不止是cf平台，也包括其他的雲平台，下邊列舉幾條在應用設計之初應該考慮的情況：

部署于cloudfoundry雲平台的應用，在設計之時，應該避免對本地（伺服器端）檔案進行讀寫，原因如下：

應用執行個體的本地檔案系統依賴于目前應用執行個體的生命周期，這就意味着，當應用執行個體停止、重新開機或者崩潰的時候，原本配置設定與本執行個體的存儲空間會被平台回收重新整理病重新用于配置設定給新的應用執行個體，其中的所有資料即使是應用本身對這部分做出的修改也會被清除。

在cloudfoundry環境中，所有的執行個體都是運作在一個“資訊孤島”之中，warden元件為每個執行個體構造了一個完全獨立的運作環境，包括本地檔案系統、記憶體等，即使是同一應用的不同執行個體，也是如此；而對于用戶端來說，不同的用戶端可能連到了不同的執行個體上，這就會出現什麼現象，當一個用戶端在應用的本地檔案系統中寫入了資料，另一個用戶端同步讀取，也會有可能讀取不到任何資料，當然，如果剛好這兩個用戶端是連到了同一個執行個體上，而且執行個體在寫入資料後沒有發生類似重新開機、停止、崩潰的事件，那資料的讀取還是正常的。

若有需求需要存儲的資料需要貫穿應用執行個體的不同的生命周期，或者需要在不同的應用執行個體之間共享，最好的選擇就是使用資料庫或者blob等存儲服務，例如，可以使用部署于cloudfoundry環境上的mongodb服務來存儲非結構化的資料，使用其他關系型資料庫如mysql來存儲結構化資料，另外，也可以使用如

amazon s3, google cloud storage, dropbox，box等公共服務，如果單是需要不同執行個體之間進行通訊或者資料共享，可以考慮使用redis或者rabbitmq等。

在用戶端cookie開啟的情況下，cloudfoundry完全能夠通過http請求支援session的關聯和綁定，如果一個應用有多個執行個體，那麼針對于某一用戶端來說，它的所有請求，都會被路由到同一個應用執行個體，這就不會出現session丢失的情況，這就允許伺服器端可以對每個用戶端進行一些session臨時資料的存儲并在有效期内共享。

cloudfoundry平台本身不提供session資料持久化和複制，如果一個應用執行個體出現崩潰或者停止、重新開機之類的事件，臨時存儲在httpsession中的資料将會丢失，這和上一條規範“避免本地檔案系統讀寫”是密切相關的，當用戶端與崩潰或者停止後重新開機的應用執行個體重建立立連接配接時，目标執行個體已經是一個全新的執行個體，而不是之前的執行個體，是以之前的session資訊也已經不存在了。

對于那些在執行個體重新開機後仍然需要可用或者說可以在不同執行個體之間共享的session資料，解決辦法同上上一條規範：将資料儲存在cloudfoundry的其他服務如redis、mysql或者其他開放的存儲服務中。

運作在cloudfoundry上的應用隻能通過配置的url接收資料，端口使用标準的http端口-80和https端口-443。

cloudfoundry v2版本中的mysql、redis、mongodb等服務可以通過cloudfoundry合作夥伴提供的用戶端工具直接連接配接，而配置連接配接參數和認證參數可以通過檢視綁定了該服務的應用的env.log檔案或者cloudfoundry

api接口獲得。