猶記得當年的喜悅。故事有些長，就長話短說了。
背景
2017年，由個人主導的《xx門診電子病歷系統》在北京xxx第一次正式上線，這個系統集成了n家院內系統，如LIS、HIS、PACS等。涉及的交互，復雜無比。當時通過各個廠商討論后，采用了進程間通信、api/webservice數據交互的方式，改造程序，完美的將程序集成在一起，讓用戶在一個系統中能夠快速的工作，替代以往多客戶端來回切換的工作方式。
而想要快速推廣這種方式，需要厚實的功底。很可惜，我們的團隊，並沒有這種大牛。在開發之初，我就想到了以后可能需要和不同的醫院作對接。因此，早期在搭建時，就設計了接口加反射的方式來實現不同醫院的集成開發，實質是只要繼承接口，實現接口即可。
問題就在這兒，並不是所有第三方提供的集成方式都穩定無比，也不是說我們的程序也能夠穩定無比。
有些災難性錯誤壓根就不能捕捉。
隨着系統逐步的推廣上線了20多家時，我們研發越來越感到厚重。所有的問題，會越來越明確，越來越有統一性。
這個當中就有今天所說的災難性崩潰處理。
處理過程
1.全局異常捕捉日志細化，然並卵，如delphi程序、c++程序並不能捕捉到
2.嘗試反射出崩潰轉存的文件，然並卵，我們這隊伍並沒有通用懂得匯編語言的人員。
3.要求第三方提供穩定的版本，依然，不是所有的人都能控制的。
4.折中方案，成功。
成功處理方案
我們都知道，通常一個exe程序就是一個進程。而我們程序因集成了很多第三方程序，進程中含有與第三方交互的地方很多。因此，引起崩潰，不能控制。
對此，我想到的就是將一個進程拆成多個進程的方式。不穩定的集成統統拆到子exe程序中，主程序與子程序間交互，崩潰的永遠是子進程，主進程依然穩定運行。此方案，經過多現場改造后，很大的解決了現場壓力。
意外收獲
今天，看到博客園推薦的一篇文章，其實思想與我的想法一致。但是，他的做法更顯功底，更有魅力。感謝博客園，感謝大家的奉獻！
大家可以看看：https://www.cnblogs.com/cwsheng/p/14616685.html