分布式一致性模式
 数据共享分为拉和推两种模式，拉指消费者去供应商那边拉数据，推指供应商主动把数据推到消费者面前。 1. 拉-视图共享 对于一般的企业信息系统，数据量不大，并发需求也不大，我建议所有的微服务用同一个数据库实例，但是拆分在不同的Schema。这样的好处是在业务逻辑上数据库是独立的，也可以独立演进。然后数据库又可以集中管理。这个方案对于大型遗留系统拆分尤其适用，因为原本就是在一个库里面，为了业务更好的独立演进进行数据库Schema拆分，又能延续原有的数据库实例管理技术。由于不同的微服务实际运行在同一个数据库实例上，可以简单地建视图进行数据共享。 需要注意的是，不要拉整个表出去，根据需要选择几个字段。这种模式技术上简单，坏处有两个：一是由于视图同步的数据是实时的，应用可能基于实时同步数据的假设进行设计，会导致以后做分布式扩展的时候特别困难;二是视图很容易暴露出表结构，这需要特别加强对视图的设计和结构管理，让暴露出去的视图不要直接绑定在现有的表结构上。视图所需的字段是外部需要，而不是表上面有什么。这样视图就是接口，只不过是强耦合在特定的数据库实例上。 2. 拉-API获取 微服务最推荐的方式是服务方提供数据API，消费者需要的时候去拉取。好处是消费者和供应方技术上完全解耦，坏处是提高了开发成本。如果消费者使用API方式获取所需数据，建议使用异步Stream方式进行编程。 如果一次业务请求需要拉取多个数据源，不建议用同步的方式调用，因为会延长处理时间。建议使用reactiveX模式进行异步拉取和组装 。 3. 推-事件消息 发生事件时发送消息是DDD CQRS模式，即解决了消费者要拥有数据用的爽快的问题(根据需要建立本地数据结构、获取性能和方式), 也解决了数据库技术异构的问题。带来的问题是需要一个消息平台，并且消费者或者供应方都要耦合在一个消息平台技术上。对于大型遗留系统改造不是很友好，一方面遗留系统的消息平台往往不符合高并发大数据量的性能要求，另一方面对于新的微服务也不想依赖老的消息平台，而想要用 数据共享分为拉和推两种模式，拉指消费者去供应商那边拉数据，推指供应商主动把数据推到消费者面前。 1. 拉-视图共享 对于一般的企业信息系统，数据量不大，并发需求也不大，我建议所有的微服务用同一个数据库实例，但是拆分在不同的Schema。这样的好处是在业务逻辑上数据库是独立的，也可以独立演进。然后数据库又可以集中管理。这个方案对于大型遗留系统拆分尤其适用，因为原本就是在一个库里面，为了业务更好的独立演进进行数据库Schema拆分，又能延续原有的数据库实例管理技术。由于不同的微服务实际运行在同一个数据库实例上，可以简单地建视图进行数据共享。 需要注意的是，不要拉整个表出去，根据需要选择几个字段。这种模式技术上简单，坏处有两个：一是由于视图同步的数据是实时的，应用可能基于实时同步数据的假设进行设计，会导致以后做分布式扩展的时候特别困难;二是视图很容易暴露出表结构，这需要特别加强对视图的设计和结构管理，让暴露出去的视图不要直接绑定在现有的表结构上。视图所需的字段是外部需要，而不是表上面有什么。这样视图就是接口，只不过是强耦合在特定的数据库实例上。 2. 拉-API获取 微服务最推荐的方式是服务方提供数据API，消费者需要的时候去拉取。好处是消费者和供应方技术上完全解耦，坏处是提高了开发成本。如果消费者使用API方式获取所需数据，建议使用异步Stream方式进行编程。 如果一次业务请求需要拉取多个数据源，不建议用同步的方式调用，因为会延长处理时间。建议使用reactiveX模式进行异步拉取和组装 。 3. 推-事件消息 发生事件时发送消息是DDD CQRS模式，即解决了消费者要拥有数据用的爽快的问题(根据需要建立本地数据结构、获取性能和方式), 也解决了数据库技术异构的问题。带来的问题是需要一个消息平台，并且消费者或者供应方都要耦合在一个消息平台技术上。对于大型遗留系统改造不是很友好，一方面遗留系统的消息平台往往不符合高并发大数据量的性能要求，另一方面对于新的微服务也不想依赖老的消息平台，而想要用 （编辑：鹰潭站长网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |
