如果使用同步通信,发起一个远程服务调用后,调用方会阻塞自己并等待整个操作的完成。如果使用异步通信,调用方不需要等待操作完成就可以返回,甚至可能不需要关心这个操作完成与否。
同步通信听起来合理,因为可以知道事情到底成功与否。
异步通信对于运行时间比较长的任务来说比较有用,否则就需要在客户端和服务器之间开启一个长连接,而这是非常不实际的。当你需要低延迟的时候,通常会使用异步通信,否则会由于阻塞而降低运行的速度。对于移动网络及设备而言,发送一个请求之后假设一切工作正常(除非被告知不正常),这种方式可以在很大程度上保证在网络很卡的情况下用户界面依然很流畅。
这两种不同的通信模式有着各自的协作风格,即请求/响应或者基于事件。对于请求/响应来说,客户端发起一个请求,然后等待响应。这种模式能够与同步通信模式很好地匹配,但异步通信也可以使用这种模式。我可以发起一个请求,然后注册一个回调,当服务端操作结束之后,会调用该回调。
对于一般规模的组织来说,如果某个软件非常特殊,并且它是你的战略性资产的话,那就自己构建;如果不是这么特别的话,那就购买。
普通的CMS提供的主要功能是内容的创建与管理。大多数CMS甚至连页面布局都做不好,它们通常只提供一些可拖拽的工具,然而这并不能满足你的需求,你还需要一些懂HTML和CSS的人来好好调整CMS模版。在其之上开发定制化代码将会是非常糟糕的体验。你可以选择在CMS上面套一层自己的服务作为对外的网站,这时CMS就成为了一个服务,其职责是管理内容的创建和获取。在自己写的那个前端服务中,你可以按照自己的方式来写代码和做集成。
你通常难以完全控制遗留系统和COTS平台,所以当你使用它们时要考虑如果需要移除或者绕过它们的话,应该如何操作。一个有用的模式叫作绞杀者模式,与在CMS系统前面套一层自己的代码非常类似,绞杀者可以捕获并拦截对老系统的调用。这里你就可以决定,是把这些调用路由到现存的遗留代码中还是导向新写的代码中。这种方式可以帮助我们逐步对老系统进行替换,从而避免影响过大的重写。标签:集成,异步,调用,服务,代码,通信,模式,设计,CMS From: https://www.cnblogs.com/hellosnow/p/17519128.html