社区微信群开通啦，扫一扫抢先加入社区官方微信群
社区微信群
目录
业界关于系统集成存在的驻留模式和工程实践主要有如下四种基本方式：文件传输FT、共享数据库SD、远程过程调用RPC和消息传递M。
集成部分所做的事情主要是将文件根据应用的不同需要做格式的转换。考虑这种集成方式，我们有几个重要的问题需要考虑：
（1）文件的格式：考虑到不同应用系统传递消息的具体样式不一致，A应用产生的文件如果能够给B应用直接使用是最好的了。常见的方法是传递XML或者JSON格式的文本。
（2）什么时候产生文件以及什么时候处理文件：避免应用系统之间信息的不同步或者信息错误。
具体如下图：
采用文件传输还有一个优点就是对于集成的系统来说它比较完美的屏蔽了集成的细节。每个系统只要关注符合标准格式的文件内容，具体实现和数据交换他们都不需要关心。
集成部分所做的事情主要是保证数据的一致性，实际中要考虑一下问题：
（1）对于多个应用来说，这个共享数据库需要能够适应他们所有的场景。
（2）不同的应用可能会同时访问相同的数据导致数据访问冲突，因此也会带来如死锁等问题。
具体如下图：
这种方案出现问题的根源在于用一种统一的数据模型来解决各种不同的应用需求是并不现实的。
集成部分所做的事情主要是，需要访问远程方法的时候，需要定义访问的接口，然后通过相关工具生成skeleton和stub。然后一端通过stub给另外一端发送消息。在应用A本地的代码中访问stub看起来还是和调用本地方法一样，这些细节都由stub给屏蔽了。
实际中需要注意的是：
（1）局限于一个平台，好比说我应用A是用java做的，那么如果要和另外一个系统通过RMI集成的话，那个系统也必须是java做的。
（2）紧耦合，如果另外一个系统出现故障也会对调用方产生很大影响。
（3）用RPC调用的时候默认期望消息是按照发送的顺序给接收方的。但是由于各种环境的影响会使得接收的结果乱序，这样也可能会导致系统执行出现问题。所以从可靠性来说还是存在着一定的不足。
具体如下图：
集成部分所做的事情主要是，所有应用之间要通信的消息都通过消息队列来传输，由消息队列来保证数据传输的异步性、稳定性等。总的来说，这看起来有点像网络连接结构。所有数据通过一条可靠的链路来进行通信。
具体如图：
消息队列算是一种兼顾了性能、可靠性和松耦合的一种理想集成方式。
对于微服务架构而言，我们的思路是尽量采用标准化的数据结构并降低系统集成的耦合度。微服务架构中服务之间的集成模式主要分为以下四类，具体如图所示：
通常基于业务逻辑的需要进行集成，RPC、REST、消息传递和服务总线都归于这一集成。
可用于服务之间的交互，共享数据库是一个选择，但也可以通过数据复制的方式实现集成。
微服务之间可以通过UI界面进行集成。
集成需求来自于外部服务的依赖和整合，而在集成方式上可以综合接口集成、数据集成和UI集成。
具体方式在前面也有提及，后面在技术应用的讲解中在详细讲解。
【1】https://www.jianshu.com/p/dfb96a974ab1.
【2】郑天民. 微服务设计原理与架构. 北京：人民邮电出版社，2018.
如果觉得我的文章对您有用，请随意打赏。你的支持将鼓励我继续创作！
