最近做应用发布的工作比较多，考虑到白天会有第三方平台（跨境购）推送订单过来，一般白天也不做部署更新。如果白天要做部署，应该如何做呢？

方案一：本身工程结构不做调整，增加一个第三方平台接口路由中转。

由于第三方平台接口相对是稳定的，意味着接口路由器也是稳定的，接口路由器，有点像Channel Interface（Not every body known this），本身仅请第三方请求做中转，并将请求持久化下来。在做更新的时候，万一有订单、商品等请求过来，可以使用接口路由器重发报文。这样子，应用站点就可以任性的随时更新了，不用等到一个特定时间去部署更新。而且，怎么选时间去部署，都有丢报文的风险。

方案二：调整工程，抽离引擎代码、业务代码，大DLL分解成小Dll，拆分，拆分

这种做法与接口路由是有神似的地方，找出变化点，抽离出来。目前来看，工程build之后一个大大的api dll，内部系统、brother系统、第三方系统接口全在一起，内部做个小调整，部署还要影响第三方系统接口的正常访问。这个是一个问题点。另外，针对第三方平台的工程组成，至少分离出报文接收+报文处理，报文接收的调整可能性非常小，实时更新报文处理组件的时候，如造成异常，还能找到报文。

调整自然有好有坏，这么拆拆拆，会拆出一堆小工程出来。一堆小组件，一堆小引擎。

方案三：部署自动化，Package可以不断的发布到一个缓冲池里，凌晨的时候自动释放。

这种方式，要求精心制作Package，能用自动验证Package是否正常发布，毕竟是自动完成。这种方式有点穿越，站在了不同的时间轴上。对于研发来说，发布，上传了Package，应用程序并不实时更新，但是可以当成“完成了”发布。这种方案同样需要研发一套Package标准+更新引擎。

方案四：大名为“云部署”、“云应用”

将Package部署包制作完之后，放到一个应用市场中，研发人员不管更新了，由业务人员依据业务情况更新。这种方案同样需要研发一套Package标准+更新引擎。这种方案，在软件客户超过1个，比较省心。如果达到几十上百，那应该是不错的部署更新方案了。