近期接手一個針對醫療系統遠程會診平台的技術改造工作，這項工作中的一些技術問題頗具代表性，我會在此記錄這一工作的過程和技術細節，如果條件允許，會在 GitHub 上開源部分業務無關的純技術實現，敬請關注。（https://github.com/iccb1013）。
遠程會診平台的應用場景指的是鄉鎮或縣衛生所，在接診過程中，對疑難問題上報上級醫療機構，由上級醫療機構進行網絡診斷並回復診療意見，但是這一過程，並不是簡單的點對點的關系。
主要特點：
1） 包含多級機構：鄉鎮、縣、區、市、省。由任意一級向上級機構提出遠程會診請求，可以提供遠程會診服務的上級機構可能存在多個。
2） 部署環境復雜，此系統並非統一部署於服務器的雲服務，而是在各級別，都可能會部署區域性的服務器（也可以不部署），如縣一級部署服務器，服務於縣和鄉鎮，區、市都分別部署各自的服務器。客戶端不能跨級別與服務器進行連接。
3） 網絡環境復雜，對於醫療機構，其部署服務器和客戶端的網絡環境可能十分復雜，多層防火牆、專用網絡等，同時對於鄉鎮或縣等機構來說，網絡質量亦存在十分不穩定的情況。
從我目前收集的問題來，排除BUG和業務邏輯上問題，基礎結構上存在的主要問題是：
1）連接不穩定，對網絡環境有較大依賴。
2）響應速度慢，容易卡死。
3）主服務重啟后下面連接的所有服務都必須跟着重啟。
簡單分析：
1）既有的遠程會診平台使用的是基於 TCP 長連接的 WebService，現場環境較復雜時，跨過鄉鎮、區縣、市等地的機構時，還需要穿過各內部網絡，網絡環境較為敏感，依賴性較大。
2）現有的實現方式並沒有對多級層的網絡消息傳輸機制進行獨立的拆分實現，而是基於 WebService 連接直接實現各業務接口並集成在客戶端中進行使用，也就是硬編碼。
鑒於以下問題，新的技術架構有以下幾點目標：
1）所有連接支持 HTTP 無狀態或 TCP 長連接兩種方式，由服務端決定采用哪種方式連接。
2）使用 HTTP 方式連接時，消息的向上傳輸使用 WEB API 接口的方式進行調用，接收回復消息則使用 HTTP 輪循進行。使用 HTTP 方式可最大程度減小整體架構對網絡環境的敏感和依賴，同時極為方便系統規模進行橫向擴展。
3）使用 TCP 方式連接則可以獲得更高的性能，但是對網絡環境的要求更為嚴格，可以在網絡環境較好的節點服務器到 Client 端使用。
4）整體結構分為 主服務器、節點服務器、客戶端 三層，支持異構的方式連接，如：客戶端到節點服務器使用 TCP 方式，節點服務器到主服務器使用 HTTP 方式，或反之，或均采用同樣的連接方式都可以，可在現場配置。
5）文件的存儲使用獨立的文件服務器，可自建或使用公有雲服務。獨立的文件服務器可避免文件傳輸對主服務網絡帶寬的占用，剝離文件存儲相關的具體實現，同時獨立的 OSS 服務有較低的帶寬成本和存儲成本優勢。
6）對於消息的傳輸，使用命令封包的方式進行，技術架構不處理任何業務邏輯。命令封包中包括目標節點、目標 Client、要執行的命令和參數等信息，由客戶端發出后，經過節點服務器到主服務器，由主服務器分發給指定的目標。支持任意 Client 到任意 Client 的消息傳輸。在命令的傳輸中，當發起 Client 和目標 Client 在同一個節點服務器時，支持經過主服務器和不經過主服務器兩種方式，可配置需要配置。經過主服務器可實現全局的記錄存儲審計等功能。
7）所有的消息傳輸，都使用異步方式，不支持掛起等待的同步方式。當發起端的一條命令發出之后，發起端通過自己的命令接收器處理命令的回復，兩者分別運行於不同的線程。
8）與現有服務端實現和客戶端的集成，使用提供 SDK 開發包的方式進行，不進行任何代碼層面的混合編寫，以維持本架構的獨立性，便於后期升級維護，以及實有服務和客戶端本身在未來重構之后，能夠繼續無縫兼容本架構。
原文：http://blog.shengxunwei.com/Home/Post/db2c6373-2639-4717-8601-8361d54afbaa