分佈式系統在業務需求的功能以外，還需要增加額外許多非功能的需求，這些非功能需求往往都是爲了一個多進程系統能穩定可靠運行而去設計和實現的。爲了保證成品APP直播源碼的開發效率，應該減少非功能以外的需求。
微服務框架：EJB、WebService
服務進程間的通訊，並不是簡單的收發消息就能完成的，這裏還涉及了消息的路由、編碼解碼、服務狀態的讀寫等。通過EJB分佈式對象調用技術，讓多個進程合作完成任務，通過講任務分配到各個服務器上，達到協作提供服務的目的。
WebService這種模型是把複雜的路由、編解碼等操作，簡化成常見的HTTP操作，是一種非常有效的抽象，開發人員只需要把多個WebService部署到Web服務器上就完成了分佈式系統的搭建。
不管是哪種方式，我們都已簡化成品APP直播源碼的分佈式調用爲目的。一般的微服務框架都會在路由階段，對整個集羣所有節點的狀態進行觀察。當集羣中的節點狀態發生變化的時候，微服務框架下的所有節點都會儘可能快的獲得這個變化，重新根據當前狀態規劃之後的服務路由方向。
異步編程工具：協程、Futrue、Lamda
分佈式系統編程中，不可避免的會遇到大量回調的API，因爲分佈式系統涉及非常多的網絡通信。任何一個業務命令，都可能被分解到多個進程，通過多次網絡通信來組合完成。回調這種異步編程模型，是非常不利於代碼閱讀的編程方法。
一種改善回調函數的寫法，叫做Future/Promise模型，一次性吧所有回調寫到一起，這是一種非常實用的編程模型。在沒有幹掉回調的基礎上，把分散的回調集中到一點上。
成品APP直播源碼不管使用哪一種異步編程方式，其編碼的複雜度，都比同步調用的代碼高，找我們編寫分佈式服務器代碼時，一定要仔細規劃代碼結構，避免出現隨意添加功能代碼，導致代碼的可讀性被破壞的情況。
本文已聲明雲豹原創，轉載請註明出處。