⼏种不同的微服务数据库架构设计⽅案
总DB的架构设计
优点：
在软件开发的初期，所有微服务的开发只需要进⾏⼀次数据库的开发，⼤幅提⾼开发速度。单⼀数据库的开发、维护都易于操作。
缺点：
开发时间耦合——例如，⼀个负责订单服务的开发者需要和其他服务的开发者协调模式发⽣的变化，因为其他服务也要访问同样的表。这种耦合和额外的协调⼯作会拖延开发⼯作的进展。
运⾏时间耦合——由于所有的服务访问同⼀数据库，他们便可能会互相⼲扰。例如，如果长时间运⾏的客户服务事务锁定了订单表，那么订单服务就会被阻塞。
系统容错性下降——由于只有⼀个数据库，整个系统的所有数据交互都要通过这个数据库进⾏，⼀旦某个微服务发⽣错误，数据库发⽣了阻塞，那么其他没有错误的微服务都将因为数据库阻塞从⽽⽆法正常运⾏。
单⼀数据库可能满⾜不了所有服务的数据存储和访问需求。
分布式和微服务的关系稳定性不⾼：⼀个微不⾜道的⼩问题，可以导致整个应⽤挂掉。
扩展性不够：⽆法满⾜⾼并发情况下的业务需求。
分DB的架构设计
优点：
数据库服务简单，每个专⽤数据库只关注⼀个业务功能。
每个微服务可由不同团队开发。每个微服务配套⼀个数据库，因此可由不同的开发团队进⾏开发，可⼤⼤提升开发效率。
数据库可根据不同的微服务类型进⾏选择，例如需要⼤型的数据管理时使⽤oracle数据库，若只管理少许数据时可使⽤Mysql数据库，甚⾄是SQLlite数据库，根据需求去选择数据库。
各个服务之间相互独⽴，若某⼀个或者⼏个服务发⽣阻塞时，不会对其他的服务造成影响，在⼀定程度上保证系统全局⼤部分功能的正常运⾏。
缺点：
运维开销
更多的服务也就意味着更多的运维，产品团队需要保证所有的相关服务都有完善的监控等基础设施，传统的架构开发者只需要保证⼀个应⽤正常运⾏，⽽现在却需要保证⼏⼗甚⾄上百道⼯序⾼效运转，这是⼀个艰巨的任务。
DevOps要求
使⽤微服务架构后，开发团队需要保证⼀个Tomcat集可⽤，保证⼀个数据库可⽤，这就意味着团队需要⾼品质的DevOps和⾃动化技术。⽽现在，这样的全栈式⼈才很少。对于⼀个完整的系统有若⼲个微服务对应的数据库，会⼤量需求这类⼈员。
隐式接⼝
服务和服务之间通过接⼝来“联系”，当某⼀个服务更改接⼝格式时，可能涉及到此接⼝的所有服务都需要做调整。
重复劳动
在很多服务中可能都会使⽤到同⼀个功能，⽽这⼀功能点没有⾜够⼤到提供⼀个服务的程度，这个时候可能不同的服务团队都会单独开发这⼀功能，重复的业务逻辑，这违背了良好的软件⼯程中的很多原则。
分布式系统的复杂性
微服务通过REST API或消息来将不同的服务联系起来，这在之前可能只是⼀个简单的远程过程调⽤。
分布式系统也就意味着开发者需要考虑⽹络延迟、容错、消息序列化、不可靠的⽹络、异步、版本控制、负载等，⽽⾯对如此多的微服务都需要分布式时，整个产品需要有⼀整套完整的机制来保证各个服务可以正常运转。
事务、异步、测试⾯临挑战
跨进程之间的事务、⼤量的异步处理、多个微服务之间的整体测试都需要有⼀整套的解决⽅案，⽽现在看起来，这些技术并没有成熟。
通⽤DB与分DB结合的结构设计
优点：
这种结构将上⽂中提到的两种⽅法进⾏结合，对于⽐较基础和通⽤的数据将他们放⼊通⽤数据库中，可以减少使⽤这些基础数据时的重复开发，并且在后期的运维开销也会相应降低。
缺点：
共⽤⼀个数据库的微服务之间会具备上⽂提到的单⼀DB架构设计的缺点。
分DB的微服务之间，会具有分DB架构设计的缺点。
总结： 单⼀DB与总DB的优缺点与微服务的属性和数量息息相关，因此不能简单地断定哪个⽅法是⽐较出⾊的，应该与实际开发相结合。通⽤DB加上负载均衡与分DB结合的结构设计
优点：
这是对多个微服务共⽤⼀个数据库的改良，当某个服务发⽣错误引起DB阻塞时，其他的服务可以通过后备数据库进⾏正常运⾏。缺点：
后备数据库与通⽤数据库之间的数据⼀致性需要保证，这将会消耗⼀定的硬件资源。

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。