随着业务的扩展，系统也逐渐的庞大起来，系统的复杂性也随之增加，开发/维护成本也无限的进行扩张，这时候微服务构架应运而生。微服务的相关知识点这里也不在描述，感兴趣的同学可以在网上进行查询。
微服务解决了传统系统设计的耦合性问题，使庞大的系统进行划分为独立的服务，让每个独立的服务可以独立去解决各自的问题，大大减少了系统后期的维护成本，但是也增大前期的设计成本，因为前期如果设计出现问题，后期的开发将会面临各种不可控的问题。这里主要记录下自己对于微服务构架--服务之间处理数据的问题。
微服模式将传统系统拆分成N多服务之后，每个服务都拥有自己独立的数据库，每个服务各自维护自己的数据库，这样就会出现一个问题，服务之间的数据库如何处理？这里简单描述下比较常见的2种处理办法
1.传统模型下--添加字段冗余
服务A中的数据需要依赖服务B中的数据，这时候可以把服务B中的数据冗余在服务A数据中，查询的时候就可以直接查询服务A的数据，不需要进行跨库进行查询，可以节约很多开销。
这样处理违反正常的范式设计的，数据也没有办法保持一致性。
2.服务之间数据同步
服务A中的数据需要依赖服务B中的数据，这时候可以把服务B中的数据同步到服务A中，查询的时候可以直接查询服务A中的数据库，不需要跨库查询。
这样数据的及时性得不到保证，而且同步数据量过大也会增加服务的负担。
在查阅网上多种微服务数据库治理的方法后，感觉都达不到自己的期望。自己考虑后为什么不能用OOP思想去设计微服务的数据库？
我们把微服务中需要使用的数据库分为3类
1.private(私有)
私有是微服务中独享的数据
2.protected(保护)
保护就是使用受限的数据
3.public(公开)
公开是所有服务可以使用的数据
私有数据就是微服务中每个独立服务自己的数据，保护/公开数据是微服务中共享服务的数据。
1.如何处理私有数据，私有数据是服务单独进行维护，其他服务只能通过API进行调用；
2.如何处理保护数据，保护数据在共享服务中，微服务中其他服务据需要使用数据需要经过共享服务的验证，是否有权限使用该数据。其他服务如果需要编辑共享数据，在获取共享服务的验证后，共享服务会分发相应的事务锁给其他服务，其他服务编辑好数据后写MQ，共享服务订阅MQ后，根据事务锁进行数据处理；
3.如何处理公开数据，公开数据就是微服务中需要耦合查询后数据。处理方式保护数据；
上述就是自己对微服务中数据库治理的一些思路想法，欢迎搭建斧正！