微服务下的数据架构

LD is tigger forever，CG are not brothers forever， throw the pot and shine forever.
Modesty is not false, solid is not naive, treacherous but not deceitful, stay with good people, and stay away from poor people.
talk is cheap, show others the code and KPI， Keep progress，make a better result.
Survive during the day and develop at night。

目录

概 述

总DB的架构设计
在软件开发的初期，所有微服务的开发只需要进行一次数据库的开发，大幅提高开发速度。单一数据库的开发、维护都易于操作。

开发时间耦合——例如，一个负责订单服务的开发者需要和其他服务的开发者协调模式发生的变化，因为其他服务也要访问同样的表。这种耦合和额外的协调工作会拖延开发工作的进展。
运行时间耦合——由于所有的服务访问同一数据库，他们便可能会互相干扰。例如，如果长时间运行的客户服务事务锁定了订单表，那么订单服务就会被阻塞。

系统容错性下降——由于只有一个数据库，整个系统的所有数据交互都要通过这个数据库进行，一旦某个微服务发生错误，数据库发生了阻塞，那么其他没有错误的微服务都将因为数据库阻塞从而无法正常运行。

单一数据库可能满足不了所有服务的数据存储和访问需求。

稳定性不高：一个微不足道的小问题，可以导致整个应用挂掉。

扩展性不够：无法满足高并发情况下的业务需求。

优点：

数据库服务简单，每个专用数据库只关注一个业务功能。

每个微服务可由不同团队开发。每个微服务配套一个数据库，因此可由不同的开发团队进行开发，可大大提升开发效率。

数据库可根据不同的微服务类型进行选择，例如需要大型的数据管理时使用oracle数据库，若只管理少许数据时可使用Mysql数据库，甚至是SQLlite数据库，根据需求去选择数据库。

各个服务之间相互独立，若某一个或者几个服务发生阻塞时，不会对其他的服务造成影响，在一定程度上保证系统全局大部分功能的正常运行。

缺点：

运维开销

更多的服务也就意味着更多的运维，产品团队需要保证所有的相关服务都有完善的监控等基础设施，传统的架构开发者只需要保证一个应用正常运行，而现在却需要保证几十甚至上百道工序高效运转，这是一个艰巨的任务。

小结

数据库模式。

参考资料和推荐阅读

1.链接: 参考资料.